The Ultimate Guide to Port Scanning: How to Audit, Diagnose, and Secure Server Ports

Every device connected to the internet relies on port sockets to transmit and receive packets. If you run a web server, custom database, API endpoint, or VPS server instance, understanding which ports are open is a vital aspect of server health and network security. An open port is a potential entry point for connections, and if the service listening on that socket is misconfigured or unpatched, it becomes a major target for malicious actors. This comprehensive guide explains how port scanning works, how to audit your server like a security engineer, and how to configure firewalls to protect your infrastructure.

Quick Answer

To secure your server ports: audit your IP address using a port scanner to identify open listener sockets. Bind internal services to localhost (127.0.0.1) so they cannot be reached externally, close unused applications, and configure firewall drop rules (like UFW or iptables) to filter all unsolicited traffic on unapproved ports.

What Do Port States Mean?

When you run a scan using an online Port Scanner or a command-line tool like Nmap, ports will return one of three primary states. Knowing these states is essential for diagnosing exposure:

• Open (Listening): A service is actively accepting connections on this port. For example, a web server listening on port 443 is ready to handle incoming SSL/TLS handshakes. This is normal for public services but dangerous for administrative portals.
• Closed (Not Listening): The port is accessible (not blocked by an intermediate firewall), but no service is currently running or listening on it. The server receives the packet and immediately returns a TCP RST (reset) response.
• Filtered (Blocked): A firewall, router, cloud security group, or network policy is dropping incoming packets before they can reach the server. The port scanner receives no response and notes the port as filtered. This is the safest state for non-public ports.

Critical Ports to Inspect and Audit

While there are 65,535 possible ports, certain standard ports carry the highest risk when exposed to the public internet. Use this reference table during your security audits:

Port	Service	Security Implication & Recommended Action
21	FTP	High Risk: Transmits passwords in cleartext. Replace immediately with SFTP (port 22).
22	SSH	Medium Risk: Target of brute-force attacks. Disable password auth, enforce SSH keys, and restrict access by IP.
80 / 443	HTTP / HTTPS	Low Risk: Required for web traffic. Ensure you are redirecting port 80 to 443 and audit certificate chains.
1433 / 3306 / 5432	SQL Databases	Critical Risk: Exposed databases face constant SQL injection probes. Bind to localhost or secure via VPN.
8080 / 8443	Alt Web Server	High Risk: Frequently used for unhardened staging sites or legacy admin panels. Block at firewall level.

Steps to Close Exposed Sockets

If your audit reveals sensitive ports are listening publicly, apply these three security best practices:

1. Bind Services to Localhost: By default, database servers (like MySQL or PostgreSQL) can listen on interface 0.0.0.0 (meaning all network interfaces). Change their configuration files (e.g., my.cnf or postgresql.conf) to bind exclusively to 127.0.0.1. This ensures only local apps running on the same machine can connect.

2. Configure a Host-Based Firewall: Enable a firewall to drop all unapproved traffic. For Linux systems, you can restrict SSH access to a specific IP address using UFW (Uncomplicated Firewall):

# Set default policies to deny incoming connections
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Allow standard web traffic
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# Restrict SSH (Port 22) to your specific office IP
sudo ufw allow from 198.51.100.12 to any port 22 proto tcp

# Enable the firewall
sudo ufw enable

3. Disable Unused Services: If you are no longer using an application, stop the process and disable its boot initialization script to remove the listening socket completely.

Interlinking & Troubleshooting

If your port scanner shows that a port is open but you cannot connect, use our Ping & Traceroute Guide to verify if there is network-level packet loss or routing drops. Furthermore, if you are exposing port 443 (HTTPS), check your TLS certificate configuration with our SSL Certificate Guide to ensure your secure handshake succeeds without intermediate chain errors.

FAQ

Q: Does port scanning damage my server?

A: No, a standard TCP handshake scan is completely harmless, but aggressive scans can create log clutter. Running standard audits on your own infrastructure is a standard compliance requirement.

Q: What is the difference between TCP and UDP scans?

A: TCP scans establish a three-way connection handshake, making them fast and highly reliable. UDP is connectionless, making it much slower and harder to verify because intermediate firewalls drop incoming UDP packets silently without returning error codes.

Q: Why does a port show as closed instead of filtered?

A: A closed status means your server received the request and actively rejected it because no service was listening on it. A filtered status means the request was dropped by an intermediate firewall before reaching the server.