Service discovery and port scanning

Objective 2.2 in this course covers enumeration techniques — CompTIA describes it as performing DNS enumeration, service discovery and directory enumeration. Lesson 9 took DNS; this takes service discovery.

Why this matters

Port scanning is the most recognisable thing a tester does and the most misunderstood. A scan does not tell you what is running; it tells you what answered, how it answered, and what a tool inferred from that. The gap between those two statements is where wrong findings come from.

It is also the technique most likely to cause an outage, which makes it the one where professional judgement shows.

The lesson

Host discovery before port discovery

Scanning every port on every address in a large range wastes the window. Host discovery narrows it first — which hosts are there at all.

The catch is that host discovery uses its own probes, and hosts can be up while refusing them. A host that ignores echo requests but serves a web application is "down" to a careless scan and very much up to an attacker. Conversely, a firewall answering on a host's behalf makes empty addresses look alive.

So: know which probes your discovery used, and when a range matters, be prepared to skip discovery and scan directly. "No hosts up" is a claim about your probes, not about the network — and stating it as the latter in a report is the kind of overreach lesson 6 warns about.

TCP and UDP scanning, and why UDP results lie

TCP has a handshake, so a scan gets a clear answer: a connection attempt is accepted, refused, or dropped. Those three map cleanly onto open, closed and filtered.

UDP has no handshake, and that changes everything. A probe to a closed UDP port should draw an ICMP port-unreachable, but that message is frequently rate limited or dropped by a firewall. So silence means any of: the port is open and the service did not reply to that particular payload, the port is closed and the rejection was lost, or a firewall ate the probe.

Consequences a tester has to internalise:

• UDP scans are slow, because the scanner must wait out timeouts it cannot distinguish from answers.
• UDP results carry more uncertainty, and a finding based on a UDP scan alone should say so.
• Service-specific probes are far better than blind ones. A payload a service will actually answer turns silence into evidence.

Important services live on UDP — name resolution, network management, time, VPN — so skipping UDP entirely leaves real attack surface unexamined.

Service and version detection, and its error bars

Version detection sends probes and matches the responses against a fingerprint database. It is inference, and it is wrong often enough to matter:

• Banners lie. Some are edited deliberately to mislead scanners.
• Backported patches are the big one. Distributions routinely fix vulnerabilities without changing the version string, so a banner showing an old version may be fully patched. Reporting a CVE on banner evidence alone is how a report gets dismantled in a meeting.
• Proxies and load balancers answer on behalf of something else, so you are fingerprinting the middlebox.
• Non-standard ports are common, and a service is identified by how it answers, not by its port number.

Which is why lesson 18 exists: a version is a lead, and a finding needs the condition demonstrated.

Reading a filtered result correctly

Scanners usually report open, closed, or filtered — and the third is the informative one.

Closed means something answered and refused: a host is there and reachable. Filtered means nothing came back, so a firewall dropped either the probe or the reply. Both are findings of a sort — a host that returns closed on every port has told you it exists, which a filtered host has not.

The pattern worth reading is the shape across the range. A handful of open ports, everything else closed, suggests host-level filtering with a reachable host. Everything filtered except a few open suggests a network firewall with a default-deny. That difference changes what you test next and it belongs in the report, because it describes their segmentation better than an asset list does.

Scanning your own lab and comparing against what you built

This is the exercise that turns scanning from ritual into skill, and it needs the lab from lesson 2 rather than anyone else's network.

Build a host where you know the truth — which services you installed, which ports you opened, which versions are present. Then scan it and compare:

• Did the scan find everything you know is there?
• Did version detection get the versions right?
• What did a UDP scan report, against what is actually listening?
• Add a host firewall and rescan — watch closed become filtered.
• Change a service to a non-standard port and see whether detection still identifies it.

You learn the tool's error bars against ground truth, which is the only way to know how much to trust it on a network where you do not have the answers. And it is the difference between "the scan says X" and "I know what the scan means".

What to take into the exam

• "No hosts up" is a statement about your probes.
• TCP gives clean answers; UDP silence is ambiguous, slow, and needs service-specific probes.
• Version detection is inference — backported patches defeat banner-based findings, which is why exploitability must be demonstrated.
• Closed means a host is there and refusing; filtered means something dropped it. The pattern across a range describes their filtering.