CYBER-03-004-P · Primer — Ports, Services, and Reconnaissance

The idea in one sentence

Every service you run listens on a numbered port, and anyone who can reach that number can knock on it, learn what's behind it, and start planning an attack — so the single most reliable way to be safer is to run fewer services and let fewer people knock.

Why it exists

A single IP address isn't one door — it's 65,536 of them. A machine can hold many conversations at once (a web server, a mail server, a database, an SSH login) all sharing the same IP, so the operating system needs a way to route each incoming packet to the right program. That routing number is the port. RFC 6335 defines the layout: system / well-known ports 0–1023 (HTTP on 80, HTTPS on 443, SSH on 22), registered / user ports 1024–49151 (databases, app servers), and dynamic / ephemeral ports 49152–65535 that clients grab temporarily and IANA never assigns.

A program that has claimed a port and is waiting for connections is called a listening service. Here's the uncomfortable truth that makes this whole topic matter: a port is only interesting to an attacker if something is listening on it. An open port with a live service is a door someone can walk up to. And they don't need your permission — or a login — to find out which doors exist. The act of methodically discovering them is called reconnaissance, and it is almost always the first move in a real attack, precisely because it's cheap, quiet, and legal-feeling.

This exists because the mechanism that lets legitimate clients reach your service is the exact same mechanism that lets strangers inventory it. You cannot serve traffic without being reachable, and being reachable means being discoverable. So the question is never "can they find my services?" — they can. It's "how few did I leave for them to find, and how little did each one tell them?"

How it works

Reconnaissance moves through a few predictable stages, each answering a sharper question than the last.

Discovery — "is anything alive here?" Before scanning ports, an attacker maps which hosts respond at all (a ping sweep, or probing a known port across a range of addresses). This trims a huge address block down to the machines actually worth poking.

Port scanning — "which doors are open?" This leans on how TCP starts a connection. RFC 793 defines the three-way handshake: the client sends SYN, an open port replies SYN-ACK, and the client finishes with ACK. A scanner exploits the reply:

• A connect scan completes the full handshake, then hangs up. Simple, needs no special privileges — but the target's application often logs the completed connection.
• A SYN scan (Nmap's default, sometimes called half-open) sends SYN, reads the reply, and — if it sees SYN-ACK (open) — immediately sends RST to abort before the connection fully forms. It's faster and quieter, because the app never sees a finished connection to log. A closed port answers with RST; a filtered port (blocked by a firewall) usually stays silent, which is itself a clue.

Fingerprinting — "what's behind each open door, and how old is it?" An open port only gives a number; the attacker wants the software and version. Two techniques do this. Service/version detection (nmap -sV) sends probes and reads the reply — including banner grabbing, where many services announce themselves on connect (SSH-2.0-OpenSSH_8.9, an HTTP Server: header). OS fingerprinting (nmap -O) doesn't trust banners at all; it sends crafted packets and studies the subtle quirks in how the host's TCP/IP stack builds its responses, then matches them against a database to guess the operating system.

Enumeration — "what can I do with it?" Now the attacker has a list: this host runs OpenSSH 8.9 on 22, nginx 1.18 on 443, a database on 5432. This inventory is your attack surface — the complete set of reachable, identifiable services. Each named version can be looked up against public vulnerability databases in seconds. Recon turns an anonymous IP into a shopping list.

The defensive lever falls straight out of the mechanism. Every stage feeds on reachable listening services, so you shrink the surface by attacking that phrase from both ends: run fewer services (uninstall or disable anything you don't need — a service that isn't listening can't be found or exploited), and make each remaining one reachable by fewer people (bind it to localhost instead of all interfaces, put it behind a firewall or security group that allows only trusted sources, require a VPN). The door an attacker never reaches is the door they can't open.

The one gotcha

Closing a port at the firewall is not the same as not running the service — and forgetting that is how "quiet" boxes get breached. A firewall that drops traffic to port 5432 makes your database look filtered from the outside, but the service is still listening on the machine, still binding, still exploitable by anything that gets inside the network — a compromised neighbor, a container on the same host, an attacker who already has a foothold. Defense that only lives at the network edge is a single wall around a soft interior. The stronger habit is to remove the listener itself wherever you can: don't just block port 5432, bind the database to 127.0.0.1 so it only accepts local connections, and uninstall services you're not using so there's no listener to block in the first place. Filtered means "hidden for now." Not-listening means "gone." Aim for gone.

See it — one SYN, and the door tells on itself

sequenceDiagram
    autonumber
    participant A as Attacker scanner
    participant P as Open port (service)
    participant C as Closed port
    Note over A: Goal - map doors<br/>without a full connection
    A->>P: SYN (probe port 22)
    P-->>A: SYN-ACK (I am open)
    A->>P: RST (abort - never<br/>finish the handshake)
    Note over A,P: Half-open - app often<br/>logs nothing
    A->>C: SYN (probe port 23)
    C-->>A: RST (I am closed)
    Note over A: Silence instead =<br/>firewall-filtered
    A->>P: Probe banner<br/>(nmap -sV)
    P-->>A: "OpenSSH_8.9" -<br/>now look up its CVEs

The one-line takeaway

Anything listening on a reachable port will be found, fingerprinted, and looked up — so your real security lever is running fewer services and exposing each to fewer people, not hoping nobody scans you.

Where you'll meet it

You'll meet this the first time you spin up a cloud VM, leave the default security group wide open, and discover from the logs that automated scanners found your SSH port within minutes — the internet is scanned continuously, and you are not too small to notice. You'll meet it running nmap against your own laptop and being startled by how many services are quietly listening. In a pentest or a CTF, recon is the opening move: scan, fingerprint, enumerate, then attack the oldest software you found. And in interviews, "how would you reduce a server's attack surface?" is a staple — the answer that lands names the mechanism: disable unneeded services, bind to localhost where possible, restrict reachability with firewalls and security groups, and keep the software that must stay exposed patched, because the version banner is the first thing an attacker reads.

Named concepts: ports and listening services, port scanning and fingerprinting, attack-surface enumeration, reducing exposed services