Port Scanning Explained: What Open Ports Reveal About a Host

Every open port on a server is a door. A port scanner knocks on all 65,535 of them to find which are unlocked, and the answer reveals more about a host than almost any other single check: what services run, what they might be exposing, and where an attacker will probe first. This post explains what a port scan reveals, how TCP connect scanning works, and how to do it responsibly.

What a Port Scan Reveals

A scan classifies each port as open, closed, or filtered, and that state is a report on the host. An open port tells you a service is listening and accepting connections — a webserver on 443, SSH on 22, a database on 3306. Closed means the port is reachable but nothing is listening. Filtered usually means a firewall dropped the probe without answering. The pattern across all three is what matters: a host exposing 22, 3306 and 3389 publicly is advertising an attack surface that should probably be on a VPN, while a host with only 443 open is a disciplined, minimal deployment.

How TCP Connect Scanning Works

The simplest reliable technique is the TCP connect scan. The scanner completes a real three-way handshake against each port, the same way a browser does:

1. Send SYN to the port.
2. Receive SYN-ACK: the port is open and accepting connections.
3. Send ACK to complete the handshake, then close.

A closed port responds with RST instead of SYN-ACK. A filtered port sends nothing, so the scanner waits until it times out. This is trivial to run from any host, which is why nc does it with one line:

nc -z -v scanme.example.com 22 443 8080

Stealthier variants like SYN half-open scans skip the final ACK so no full connection is logged, but they require raw sockets and root. The tradeoff matters for analysts: a connect scan is slower and more visible but works everywhere, which is why it is the right default for a routine TCP port scan.

Common Ports Worth Knowing

The value of knowing these ports is triage speed. When a scan comes back, you should be able to look at the open list and immediately name each service, judge whether it belongs on the internet, and pick which one an attacker would hit first.

Interpreting Results and Scanning Responsibly

An open port is not a vulnerability by itself. A hardened SSH server on 22 with key-only auth is fine; a MySQL on 3306 with a weak root password is a disaster. The scan defines the surface; your job is to decide which doors should not exist. The standard remediation is to close or firewall anything not needed, move administration services behind a VPN, and watch the exposed ones.

Follow-up work often starts where the scan leaves off. A banner grab on an open port — connecting and reading the first line the service sends — reveals the version string, which an analyst then checks against known vulnerabilities. Combined with the base scan, that tells you not just that a service is exposed but whether the exposed version is current. If a port answers only from certain source addresses, the scan results also hint at network-level filtering you should reconcile with your firewall rules.

Responsible scanning is a prerequisite, not an afterthought. Only scan hosts you own or have written authorization to test; unsolicited scanning can violate law and provider terms, and aggressive scans can trip intrusion-detection and rate-limiters. When you do scan your own infrastructure, use a proper tool rather than a hammer: check the common ports reference to build your target list, then run a measured port scanner against your own servers on a maintenance window.

Next step: run a port scanner against your own server, note every unexpected open port, and close or firewall the ones that do not need to be public.

More posts →