In one sentence
Port scanning is the act of probing a host to learn which network ports are open and what service answers on each, so you can build a map of a target's attack surface — the reachable doors — before deciding which ones are worth pushing on.
Why it matters
You cannot attack — or defend — a service you do not know is listening. A port scan turns "some server at this IP" into "TCP 22, 443 and 3389 are open, and 3389 is RDP facing the internet". That inventory is the first move in almost every engagement: for an attacker it is target selection, for a defender it is the reality check against what the asset register claims is exposed. The gap between the two — the forgotten management port, the dev service that was never firewalled — is where incidents start.
It pairs naturally with passive OSINT: OSINT tells you which hosts exist without touching them, and scanning confirms what is actually live and reachable on each. Together they draw the external attack surface. The crucial mindset, though, is that a scan reports exposure, not vulnerability — an open port is a question ("why is this reachable?"), not yet a finding.
States, scan types and etiquette
A scanner sends probes and classifies each port into one of a few states:
- Open — a service accepted the connection. Closed — reachable but nothing is listening. Filtered — a firewall dropped the probe, so the state is unknown (often
open|filtered). - Scan types trade stealth for reliability: a TCP connect scan completes the handshake (loud, no privileges needed); a SYN scan sends SYN and never finishes (quieter, needs raw sockets); UDP scans are slow and unreliable because there is often no reply.
- Service and version detection goes further: it grabs banners to say "OpenSSH 9.6 on 22", which is what makes the result actionable — a version is what you match against a CVE.
Ports fall in ranges: well-known (0–1023), registered (1024–49151) and dynamic/private (49152–65535). And the etiquette matters as much as the technique: scanning hosts you do not own or have explicit authorisation to test is, in many jurisdictions, unlawful. Active scanning is also noisy — it shows up in the target's logs (ATT&CK T1046), which is exactly why defenders watch for it.
Try it yourself hands-on
Turn a raw Nmap run into a prioritised exposure list — and use the tools to reason about scope before you ever scan.
- Run your authorised scan with output to XML (
nmap -sV -oX scan.xml target), then open the Nmap XML Parser and load the file (or click Load sample). It flattens every host and port into a searchable table with state, service and version — all in your browser, nothing uploaded. - Read the Severity hint column. It is a deliberate exposure heuristic, not a vulnerability verdict: it flags management and legacy protocols — RDP, SMB, RPC, telnet, FTP, IPMI, MySQL — as higher risk because those are the ports that should almost never face the internet. Filter to High and you have your "why is this reachable?" list in seconds. Export it as Markdown for the ticket.
- For any single port you do not recognise, the Port Lookup gives the usual service, a firewall recommendation and a secure alternative — so "5432 open to the world" becomes "that's PostgreSQL; it should be behind the VPN".
- Before scanning a range, size and sanity-check it with the CIDR Calculator so you scan exactly the network you were authorised to and no neighbour's.
Result: a scan result read as a prioritised exposure map — management ports first — instead of a wall of open-port noise.
Common misreadings
- Open ≠ vulnerable. A patched, well-configured service on an open port is fine. Scanning finds reachability; you still need a version + CVE + reachability check to call it a risk.
- Filtered is not "safe". It means a firewall hid the answer, not that nothing is there. Do not treat unknown as closed.
- Authorisation is not optional. Active scanning touches the target and is logged; scan only assets you own or have written permission to test, and keep to the agreed scope.