Every service on the internet lives on a port. A web server listens on 443. Mail may listen on 25 or 587. SSH listens on 22. A port scanner is the tool that knocks on those doors and reports which ones answer. It's the single most fundamental technique in network security — the first step of almost every assessment, and the first thing you should run against your own infrastructure.
What a port actually is
An IP address gets traffic to a machine. A port gets it to a specific service on that machine. There are 65,535 TCP ports and 65,535 UDP ports per address. At any moment, a server might have a handful of them open — each one a program waiting for connections — and every open port is part of your attack surface.
Port scanning is the systematic process of connecting to those ports and classifying what happens. The result is a map: which ports are open, which services are behind them, and often which software versions are running.
How a scan works
Most port scanning is TCP, and there are two workhorse techniques.
Connect scan. The scanner does exactly what a normal client does: completes a full TCP three-way handshake (SYN, SYN-ACK, ACK) and then hangs up. If the handshake completes, the port is open. This is simple and reliable, needs no special privileges, and is loud — every connection is a real connection that firewalls and services will log.
SYN scan (half-open). The scanner sends the SYN, waits for the SYN-ACK, and never completes the handshake — it answers with RST instead. The port was still classified (SYN-ACK means open), but the connection was never established, so most services never log it and it's faster. This is Nmap's default when run with administrator privileges, and it's why nmap is so closely associated with the phrase "port scanner" — our Nmap tutorial walks through it in detail.
UDP is messier. Many UDP services stay silent when probed, so UDP scanning is slower and produces more "open or filtered" ambiguity. It's also frequently skipped — which is exactly why UDP-exposed services get forgotten about.
Open, closed, filtered
A scan result classifies each port into one of three states:
- Open — something is listening and answered. This is your attack surface.
- Closed — nothing is listening, and the host actively said so (it sent a RST). Useful information: the host is alive, that door just doesn't exist.
- Filtered — no answer came back at all. A firewall or filtering device dropped the probe silently. This is the ambiguous one: a filtered port might be protected by policy, or the probe might have been lost. Firewalls that respond with ICMP "unreachable" messages let scanners distinguish filtered from a fourth state, "unfiltered," but silence is the common case.
The distinction matters because "filtered" is what a well-configured firewall looks like, and "closed" on a fresh host tells you the host is reachable and responsive — useful when diagnosing why a "dead" target might still have services on unusual ports.
From ports to vulnerabilities
A port scan by itself finds no vulnerabilities. It finds exposure. The vulnerability work starts with what's listening:
- Version detection. Nmap's service detection probes open ports to fingerprint the application and version behind them. A known-vulnerable version of something internet-facing is a finding regardless of whether anyone has exploited it.
- CVE and exposure checks. Once you know what's running, template-driven scanners like Nuclei check for known issues against those services. (See our open source CVE scanner guide for how that layer works.)
- Application-level testing. A port scan that finds 443 open says nothing about the web application behind it. That's DAST territory — tools like OWASP ZAP — and it's a different layer of the stack.
This is why the standard assessment pipeline is: map with a port scan, fingerprint the services, then point the specialized scanners at what you found. Our Nmap vs Nuclei vs ZAP comparison breaks down how the three layers fit together.
Is port scanning legal?
The scan itself is just network traffic, but scanning systems you don't own or don't have permission to test is — depending on jurisdiction — at best rude and at worst criminal. The working rule: scan only assets you own or have written authorization to test. If you're scanning your own infrastructure, or a client's under an engagement letter, you're fine. If you're not sure whether you have permission, you don't.
Cloud providers additionally prohibit scanning certain ranges (their own metadata services, for example) even within your account, and corporate networks usually have explicit policies. Get the authorization in writing first.
Run one against your own attack surface
The fastest security win available is knowing what's actually exposed. Internal asset inventories drift; firewall rules accumulate; a test server from last year is still listening on 8080. A periodic external port scan from a clean network — the same view an attacker has — is how you catch that drift.
For a quick check, our free online port scanner probes the 13 most commonly exposed service ports on any target you own, straight from the browser.
You can install Nmap and do it yourself (the cheat sheet has the commands), or run a hosted scan that maps the ports, fingerprints the services, follows up with CVE checks, and hands you a report. VulnScanners runs exactly that pipeline — Nmap first, then Nuclei and ZAP against what the map shows. Point it at a target you own and see your external surface the way an attacker sees it.