Port Checking Guide:
Network Security Auditing

Every Open Port Is a Door

Your server has 65,535 TCP ports and 65,535 UDP ports. Each one is a potential entry point. Port 80 serves HTTP. Port 443 serves HTTPS. Port 22 accepts SSH connections. Port 3306 waits for MySQL queries. Port 5432 listens for PostgreSQL. Port 6379 responds to Redis. Port 27017 handles MongoDB. You need some of these open to provide services. The rest should be closed — invisible to the outside world, rejecting any connection attempt with a RST packet or, better yet, dropping the packet silently at the firewall so the would-be attacker doesn't even know a server exists there.

A port checker tells you which of your ports are visible from the outside. You specify a hostname and a list of port numbers. It attempts a TCP connection to each one. If the connection succeeds, the port is open — a service is listening. If the connection is rejected, the port is closed — no service. If nothing comes back, the port is filtered — a firewall is blocking the attempt. This is the same probing an attacker does during reconnaissance. Check your own ports before they do.

Well-Known Ports and What Should (and Shouldn't) Be Open

Port 80 (HTTP) and 443 (HTTPS). These should be open on any public web server. Port 80 typically redirects to 443. If port 443 is closed, your SSL certificate is useless. If port 80 is closed, browsers that try HTTP first (all of them, by default) get connection refused before they see the redirect. Note: you don't need both if you have HSTS preloading, but keeping port 80 open with a redirect is safer for users who haven't visited your site before.

Port 22 (SSH). Should be accessible only from your IP address or your VPN's IP range. Never open SSH to the entire internet — automated scanners constantly probe port 22 and attempt brute-force logins with common username/password combinations. Even with key-based authentication, exposing SSH to the internet generates noise in your logs and increases the attack surface. Use a VPN, a bastion host, or IP-based firewall rules to restrict SSH access.

Ports 3306 (MySQL), 5432 (PostgreSQL), 6379 (Redis), 27017 (MongoDB). These should NEVER be exposed to the public internet. Ever. Database ports are for internal communication between your application server and your database server — they belong on private subnets, not the public internet. Unsecured Redis instances exposed to the internet are routinely compromised by automated attacks. Unsecured MongoDB instances have been the source of major data breaches. Check your cloud provider's firewall rules (AWS Security Groups, GCP Firewall Rules) to confirm these aren't open to 0.0.0.0/0 unless absolutely necessary and properly authenticated.

Ports 21 (FTP), 25 (SMTP), 110 (POP3), 143 (IMAP). These are legacy protocols. FTP sends passwords in cleartext — use SFTP (which runs over SSH on port 22) instead. SMTP on port 25 is for mail server-to-server communication, not client submission — clients should use port 587 (submission) or 465 (SMTPS). If you're not running a mail server, these ports should be closed. If you are running a mail server, ensure only the necessary ones are open and that they're properly authenticated and monitored.

How Port Checking Works

TCP port checking uses the TCP three-way handshake: the client sends a SYN packet to the target port, and the server responds. If the server responds with SYN-ACK, the port is open — a service accepted the connection. If the server responds with RST (reset), the port is closed — no service is listening. If no response comes back within the timeout, the port is filtered — a firewall is dropping the packets, making it impossible to determine whether a service exists behind it.

Browser-based port checking is limited. Browsers can only attempt HTTP/HTTPS connections, not raw TCP connections. Our port checker tests ports by attempting HTTP connections to each one. For ports that don't speak HTTP (like 22, 25, 3306), the connection attempt still reveals whether something is listening even if it can't complete an HTTP transaction. A connection that succeeds (TCP handshake completes) but then times out on the HTTP response means the port is open but running a non-HTTP service. A connection that fails immediately means the port is closed or filtered.

For comprehensive port scanning — all 65,535 ports — use nmap from the command line. nmap -sS target.com performs a SYN scan (also called half-open scanning) that identifies open ports without completing the TCP handshake, making it faster and less detectable than a full connection scan. Nmap also probes each open port to identify the service and version, giving you a complete picture of your attack surface. Browser-based checking is for quick verification of specific ports; nmap is for thorough audits.

Port Auditing as a Security Practice

Run a port audit on every server you manage, on a schedule. New services get deployed. Default configurations include ports you forgot about. Development servers that were meant to be temporary accidentally become permanent. A quarterly port audit — check all your servers' exposed ports and confirm each one is intentional and necessary — catches configuration drift before attackers do. Document which ports should be open and why. If you can't explain why a port is open, close it. The principle of least privilege applies to network access too: open only what you need, to only who needs it, and monitor for changes.