Port and service scanning

Authorization first — scanning is reconnaissance, not a free read

Before any of the mechanism below, the rule that opens this whole track still holds: a port scan is only legitimate against a system you own or are explicitly authorized to test. In MITRE ATT&CK terms, scanning is Active Scanning under the Reconnaissance tactic (TA0043) — and “active” is the operative word. Unlike reading a target’s public DNS records, a scan sends packets to the target and waits for replies, which means it touches infrastructure you don’t control and leaves evidence on it. Pointing a scanner at a host you have no authorization for is unauthorized access in nearly every jurisdiction, regardless of how gentle the scan is. Everything here is framed for a CTF box, a deliberately vulnerable VM you deployed, or an in-scope engagement — never a real target “just to see what’s open.”

We learn it defensively: if you understand exactly what a scan reveals and exactly what it leaves behind, you can both reduce what your own systems expose and recognize the scan in your logs when someone runs it against you.

How a port scan works: the TCP handshake, weaponized as a question

A port scan is just the TCP three-way handshake used as an interrogation. To open a normal connection a client sends SYN, the server replies SYN-ACK if the port is listening, and the client finishes with ACK. A scanner exploits the middle of that exchange: it sends a SYN, and the reply alone tells it the port’s state, before any connection is fully established.

• SYN-ACK back → the port is open: something is listening.
• RST (reset) back → the port is closed: the host is reachable but nothing is listening there.
• Nothing back (after retries/timeout) → filtered: a firewall is silently dropping the probe, so you can’t tell open from closed.

The classic default, a SYN scan (often called a “half-open” or “stealth” scan), sends the SYN, reads the reply, and then sends RST to tear down the half-built connection before the handshake completes. Historically this mattered because a connection that never fully opened often wasn’t written to the application’s own logs. The contrast is a connect scan, which completes the full three-way handshake using the OS’s normal connection call — more reliable and the fallback when the scanner lacks the privilege to craft raw packets, but louder, because a completed connection is exactly what application logging records.

From open port to named service: fingerprinting and banners

An open port number is a weak guess. Port 22 usually means SSH and 5432 usually means PostgreSQL — but services run on non-standard ports all the time, and “open” alone tells you nothing about which software or which version is listening. Turning a port number into a confident identification is service fingerprinting, and it has two flavors.

The cheap one is banner grabbing: many services announce themselves the moment you connect. Open a raw TCP connection to an SSH port and it greets you with a version string like SSH-2.0-OpenSSH_7.4; an SMTP server answers with a 220 line naming the mail software; a misconfigured web server returns a Server: header. You read the banner the service volunteers and you know what it is — no cleverness required, because the service told you.

The deeper one is active fingerprinting (nmap’s -sV service/version detection). When a banner is missing, lies, or is ambiguous, the scanner sends a sequence of crafted probes and matches the pattern of responses — timing, exact byte sequences, error behavior, protocol quirks — against a database of known service signatures. It can also infer the OS from subtle differences in how the TCP/IP stack itself responds (TTL values, window sizes, option ordering), because no two stacks behave identically. This is more accurate than trusting a banner, but it is also far louder: instead of one connection it fires dozens of unusual probes per port, which is exactly the anomalous traffic an IDS is tuned to notice.

What the defender sees — and why scanning is two-sided

This is the half newcomers forget: while you are reading the target, the target is reading you. Every probe is a packet with your source IP, and the defensive stack is built to notice exactly the patterns a scan creates.

• The firewall / connection logs record the flood: many SYNs to many ports from one source in a short window. A run of RST-terminated half-open connections (the SYN-scan signature) or a fan-out across the whole port range is a textbook scanning fingerprint.
• An IDS/IPS (Snort, Suricata, or a cloud equivalent) has rules tuned for precisely this — a threshold of distinct ports touched per source per interval — and can alert, rate-limit, or block the source IP outright.
• Version detection is even more visible: the unusual, non-protocol-conforming probes that -sV and OS detection send don’t look like any normal client, so they light up signature-based detection far more than a plain port sweep.

The defensive lessons fall straight out of this. Reduce what’s exposed in the first place (close ports, bind services to internal interfaces, put a firewall in front so most probes get filtered, not answered). Strip or genericize banners so a successful connection volunteers nothing — though remember that’s only hiding the label, not the service, so it slows an attacker rather than stopping them. And monitor for the scan signature so you detect reconnaissance early, because in the kill chain recon is the first stage, and catching an attacker there is the cheapest place to break the chain.