Nmap in depth

Objective 2.3 in this course covers reconnaissance tools — CompTIA names Nmap, Wireshark and Shodan specifically. Because CompTIA names them, they are examinable by name, and this lesson is the applied lab for the objective.

Why this matters

Nmap is named in CompTIA's own scope bullet, so expect questions that assume you have used it rather than read about it — which scan type suits a situation, what a particular result means, what a given flag costs you.

It is also the tool where the difference between a practitioner and a button-presser is most visible. The defaults are reasonable and will get you a result; knowing why you would deviate is the skill.

The lesson

Scan types, and choosing one on purpose

Each scan type is a different question asked of the target.

• Connect scan completes the full handshake. It is the most reliable and the most logged, since the application sees a real connection. It needs no special privileges.
• SYN scan sends the first packet of the handshake and never completes it. Faster, and historically "stealthy" — which is largely obsolete: modern logging and monitoring see it plainly. Prefer it for speed and courtesy to the application, not for stealth.
• UDP scan, with all the ambiguity from lesson 10.
• ACK scan is for mapping firewall rules rather than finding services: it tells you whether a port is filtered, not whether it is open.
• The odd flag combinations (null, FIN, Xmas) rely on specification behaviour that many stacks no longer follow. They are examinable, and in practice they mostly tell you what stack you are talking to.

The exam angle: match the scan to the question. "Which ports are reachable through the firewall" is an ACK question. "What is actually listening" is a SYN or connect question.

Timing templates and what they cost you in accuracy

Nmap's timing templates trade speed against reliability and stealth, and the trade is real in both directions.

Fast templates shorten timeouts and raise parallelism. On a congested link or a slow device, a shortened timeout means a slow-but-open port is recorded as filtered — the scan gets faster by being wrong. Aggressive settings are also what take fragile devices down, which is lesson 8's availability risk.

Slow templates are for two situations: fragile targets, and networks where you genuinely need to stay under a rate threshold.

The judgement: a fast scan of a big range to find live hosts, then a careful scan of what you found. And when a result matters to a finding, re-run it at a slower timing to confirm, because a single fast scan is not evidence.

The scripting engine, and reading a script before running it

Nmap's scripting engine covers everything from banner grabbing to vulnerability checks to brute forcing — and that range is exactly why the category you run matters.

Some categories are safe reconnaissance. Others are intrusive: they attempt exploitation, authentication, or actions that change state on the target. A category selected carelessly can take you outside your authorisation without any decision being made — which is scope creep by default setting, and lesson 3 says authorisation does not stretch.

So:

• Know what category you are invoking, and prefer naming scripts explicitly over broad categories on a client's network.
• Read the script first. They are readable, and reading one tells you what it actually sends, which is what you will need when the client asks.
• Never run anything described as intrusive or as a denial-of-service check unless the scope names it in writing.

This is the same instinct as lesson 24's "read an exploit before running it".

Output formats that feed the next tool

A scan is an input to the rest of the engagement, so write it to a file every time — not just to the terminal.

• Normal output is for a human.
• Grepable output is legacy but convenient for quick shell pipelines.
• XML output is the one that matters: structured, and what other tools ingest.
• All formats at once is usually the right call, because re-running a scan to get a different format wastes the window and produces a slightly different result.

Two habits that make the report easier: keep the exact command line with the output, and keep the timestamp. Both are required by lesson 8's activity log, and the command line is what makes a finding reproducible.

Interpreting a scan of a host whose configuration you already know

This is the applied lab for objective 2.3, and like lesson 10 it runs against the lab from lesson 2, where you know the truth.

Take a host you built. Before scanning, write down what you expect — the services, ports, versions, and what the host firewall should do. Then scan and compare, and treat every disagreement as something to explain rather than something to accept:

• A port you know is open reported filtered → timing too fast, or the firewall.
• A version reported wrongly → fingerprint limits, backporting, or a proxy.
• A service found on a port you did not open → something you did not know was installed, which is the finding pattern in miniature.
• Run the same scan with different timing and compare. Differences between two runs of the same scan are the error bars, measured rather than assumed.

Writing the expectation down first is what makes it an experiment rather than a demonstration. It is also the habit that stops you reading a scan to confirm what you already believe.

What to take into the exam

• Match the scan type to the question: ACK for filtering, SYN or connect for what is listening.
• Faster timing buys speed by losing accuracy; confirm findings at slower timing.
• Script categories can be intrusive — naming scripts beats invoking categories, and the scope must permit anything intrusive in writing.
• Save XML output with the exact command and timestamp; it is what makes a finding reproducible.