29 — Recon and Scanning Tools
Level: Intermediate · Time: ~20 min · Prerequisites: Lesson 28 — The Open-Source Security Arsenal
Why this matters
Before anybody attacks anything, they look. They find out which addresses you own, which names resolve, which subdomains exist, which services answer on which ports, and which versions those services run. That reconnaissance phase decides everything that follows: the attacker who knows you run an unpatched appliance on an unusual port does not need to be clever. The defender's problem is simpler and more uncomfortable — most organisations have never done this to themselves, so they do not know what the internet already knows about them.
This lesson teaches the tools from the attacker's side because that is how you read them: nmap output in particular is a language you have to be fluent in, and the last third of the lesson is the half that pays — what a scan looks like in your own logs, why you should not chase every scan from the internet, and why a scan from inside is the one worth investigating. The most valuable two hours a beginner can spend with these tools is pointing them at their own footprint.
The mental model: passive, active, and the line between them
| Passive reconnaissance | Active scanning | |
|---|---|---|
| What it does | collects information that is already public, or that someone else collected | sends traffic to the target to make it answer |
| Does the target see it? | not directly — though search engines, certificate logs and the DNS see your queries | yes, definitively, in connection logs, firewall logs and IDS alerts |
| Legally safer? | usually, but not automatically lawful | never lawful without authorisation |
| Typical output | names, subdomains, technology hints, published documents, contact lists, exposed metadata | live hosts, open ports, service versions, operating system, and the raw material for a vulnerability scan |
Two honest notes before the tools. First, "passive" does not mean "unregulated": in France, collecting information about systems you have no relationship with can still breach law or contract, and any collection of personal data is a processing activity with its own obligations. Second, the law follows authorisation, not technique. Both halves of this lesson are aimed at your own address space, your own lab, or a target you hold written permission to test.
The defender's version of reconnaissance is the same work with the arrow reversed: look at your own footprint before somebody else does, because everything listed here under "what an attacker can find" is a list of things you can still fix.
Passive reconnaissance: what an attacker can see about you
| Technique | Open-source tooling | What it reveals |
|---|---|---|
| Registration and ownership lookups | whois, RDAP queries |
who owns a domain or an address block, registration dates, contact records, name servers |
| DNS enumeration and reverse lookups | dig, host, dnsrecon, fierce |
which names exist, which servers they point to, whether a range has meaningful reverse records |
| Subdomain discovery from certificate transparency | crt.sh and the transparency log APIs |
subdomains you have forgotten, including staging, test and internal-facing names that leaked into a public certificate |
| Public footprint mapping | Amass, Subfinder, theHarvester, SpiderFoot | the join of everything above: names, addresses, mail servers, technologies, and sometimes people |
| Search engines and web archives | search operators, the Internet Archive | old pages, exposed directories, job adverts that name your exact firewall and version, cached copies of removed content |
| Metadata in published documents | exiftool |
author names, internal file paths, software versions and sometimes usernames embedded in PDFs and Office files on your own website |
| Web technology fingerprinting | whatweb, wafw00f |
which products and versions sit behind a name — and whether a web application firewall is present |
Two commands show the shape of the whole family. Both are read-only and both are legitimate against your own domain:
# Registration and name server data for a domain you own
whois example.com | head -30
dig +short NS example.com
dig +short AXFR example.com # zone transfer — it should fail, and if it succeeds that is a finding
# The subdomains your own certificates have published to the world (query crt.sh for %.example.com)
# and metadata nobody meant to publish, in a document on your own website
exiftool -Author -Creator -LastModifiedBy -Producer ./public-report.pdf
[!TIP] Run the certificate transparency query for your own domain first. Every certificate issued for a name under it is recorded publicly, which means your staging host, your old VPN portal and the appliance you decommissioned three years ago may all still be there — and a name is only removed by removing the certificate, not by deleting the DNS record. If a name in that list surprises you, it is a finding.
The useful habit is to build a small, boring external footprint document for your organisation: every domain, every certificate-derived hostname, every public address, every technology you can identify, and every published document that leaks something. Keep it, review it quarterly, and reduce it. That document is what stops you being surprised, and it is also what you take to a meeting when you need to explain why a test server must be switched off.
Active scanning with nmap
nmap is the industry standard and the output language you must be able to read. Four questions it answers, and one it does not.
| Task | Flags | What you should know |
|---|---|---|
| Host discovery | -sn (no port scan), -Pn (skip discovery), -PS/-PA/-PU for TCP SYN, TCP ACK and UDP probes |
on your own LAN nmap uses ARP and gets a definitive answer; across a firewall, ICMP and probes are often dropped, so -Pn is how you find hosts that exist but do not answer pings |
| TCP connect scan | -sT |
uses the operating system's own connect call, needs no special privilege, and is logged normally by the target because it completes a full handshake |
| SYN (half-open) scan | -sS |
needs elevated privilege and never completes the handshake, so it is faster and leaves a different trace — a SYN followed by a reset, with no data |
| UDP scan | -sU |
slow and unreliable by nature: silence from UDP means either closed or filtered, so nmap has to infer and often reports open|filtered |
| Service and version detection | -sV, --version-intensity |
sends probes and matches responses to a signature database; the higher the intensity, the slower and the more it sees |
| Operating system detection | -O, --osscan-guess |
infers the platform from TCP/IP behaviour, which is an educated guess and should be treated as a hint |
| Timing | -T0 paranoid through -T5 insane, plus --max-rate and --scan-delay |
the trade is always speed against accuracy and noise: aggressive timing can drop packets and produce false "closed" results, and fills logs fast enough to trigger rate limiting |
| The scripting engine (NSE) | -sC (the default set), --script <name>, --script vuln, --script-args |
useful for specific, targeted checks such as cipher enumeration or SMB dialect negotiation. It can tell you a service should be vulnerable; it cannot prove that it is |
| Output | -oN normal, -oX XML, -oG greppable, -oA all three |
XML is what you feed to a report or another tool; the greppable format is what you feed to grep |
And the output itself, which is a fixed shape you should be able to read at a glance:
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 9.6p1 Ubuntu (protocol 2.0)
80/tcp open http nginx 1.24.0
443/tcp open ssl/https nginx 1.24.0
3306/tcp filtered mysql
8080/tcp closed http-proxy
open means something answered. closed means the host replied and nothing is listening — evidence the host is alive. filtered means no answer at all, usually a firewall, and it is the state people misread: it tells you nothing about whether a service is running behind it. open|filtered is nmap admitting it cannot tell.
Here is a realistic set aimed at your own network — a lab, a home network or an estate you administer:
# 1. Who is alive on my own subnet (no port scan — fast and quiet)
sudo nmap -sn 10.20.0.0/24
# 2. Every TCP port on one host, with versions and the default script set
sudo nmap -sS -sV -sC -p- -O -oA host01 10.20.0.10
# 3. The same check without privilege: slower, more visible, still useful
nmap -sT -sV --top-ports 1000 10.20.0.10
# 4. The UDP half of the estate — expect this to take a long time
sudo nmap -sU --top-ports 50 -oA host01-udp 10.20.0.10
# 5. A firewalled host that ignores pings is still worth scanning
sudo nmap -Pn -p 443,8443,8080 --reason 203.0.113.10
# 6. Targeted checks rather than a general sweep
sudo nmap -sV --script ssl-enum-ciphers -p 443 203.0.113.10
sudo nmap -p 445 --script smb-protocols 10.20.0.10
# 7. A polite, slow scan during working hours; and a fast sweep for coverage
sudo nmap -T2 --max-rate 100 -p- 10.20.0.10
sudo masscan 10.20.0.0/24 -p1-65535 --rate 5000
# 8. My own external address space, scanned from outside, to see what the internet sees
sudo nmap -sS -sV -Pn --version-light -oA external-audit 203.0.113.0/28
High-speed scanners such as masscan and ZMap earn their place at scale: they can cover the whole IPv4 space in an hour. They trade detail for speed — no version detection, no scripting, and results that often need re-scanning to confirm — so they are for finding where to look, not for telling you what is there.
The defender's half: what a scan looks like, and how to shrink the surface
A scan is not invisible; it has a shape. Learn the shape and you can write a detection for it, and then decide whether it deserves attention.
| Evidence | Where you see it | Why it looks that way |
|---|---|---|
| Many destination ports from one source in seconds | firewall logs, Zeek conn.log, router flow records |
that is what a port scan is; the port order may be sequential, or randomised to defeat naive rules |
| Connections that open and carry no data | proxy, web and connection logs | the scan is asking whether something answers, not asking it anything |
| Half-open connections — SYN, then reset | firewall and IDS logs; Zeek records S0 for a SYN with no reply |
-sS never completes the handshake, so the target's own application logs may record nothing at all |
| One source touching many hosts | firewall and flow logs | a sweep looking for anything that answers |
| Many sources touching one host | firewall logs, with many distinct addresses | distributed probing, often from rented infrastructure |
| Bursts of 400-class answers from one client | web server access logs | a scanner enumerating paths, files and administrative interfaces |
| Immediate reset after connect, with regular timing | connection logs | a machine, with a fixed rate and no human pause |
| Protocol probes for services you do not run | IDS alerts, Zeek protocol logs | the scanner is testing every known product, not targeting yours |
Then the policy that turns all of this from noise into signal:
- Do not chase every scan from the internet. Your public address space is scanned continuously, by researchers, by botnets and by nothing at all. Alerting on it is how a team learns to ignore alerts.
- Know which systems are allowed to scan you, from where, and when. Your own vulnerability scanning (Lesson 27) and monitoring belong on an allowlist. Everything outside it is worth a look.
- Treat an internal scan as a finding. Workstations do not port-scan servers. Internal scanning usually means either an unmanaged tool, a compromised host doing reconnaissance, or somebody about to test something in production without telling anyone.
- Make the scanning footprint small in the first place. Every service you close is something no scan can find. Closing the port is cheaper than monitoring it forever.
Reducing your own attack surface with the same tools is the point of the lesson, and it takes four habits: scan your external address space from outside, from a machine you own on another network, and compare the result with your asset inventory; scan your internal networks on a quarterly schedule with authorisation, and close everything you cannot justify; verify that a service removed from configuration is genuinely no longer listening; and check that segmentation actually holds by scanning from the network you expect to be blocked — a guest WiFi client should find nothing but its own gateway.
Your ten-command self-audit this weekend
| # | Command or check | What it tells you |
|---|---|---|
| 1 | ip a and ip r |
what I am, and which gateway carries me out |
| 2 | sudo nmap -sn 192.168.1.0/24 |
every device on my LAN, including the one I forgot |
| 3 | sudo nmap -sS -sV --top-ports 100 192.168.1.1 |
what services my router exposes to the inside |
| 4 | nmap -sT -p- 127.0.0.1 compared with ss -tulpn |
whether the machine listens on anything I did not know about |
| 5 | sudo nmap -sS -sV -Pn --top-ports 1000 <my public address>, run from a machine on another network |
what I actually expose to the internet |
| 6 | nmap --script ssl-enum-ciphers -p 443 <my public host> |
whether my TLS configuration is current or a decade old |
| 7 | nmap -sn 192.168.1.0/24 from a guest WiFi device |
whether guest isolation really works — it should find nothing |
| 8 | arp-scan --localnet |
duplicate addresses and devices that answered ARP but nothing else |
| 9 | A certificate transparency query for my own domain | subdomains I had forgotten were public |
| 10 | A review of my firewall deny log, grouped by source and destination port | whether anything is aimed at me specifically, rather than scanning the whole internet |
[!WARNING] Authorisation is not a formality. nmap and every other tool in this lesson may be pointed only at systems you own or have written permission to test — in your own lab, on your own home network, or within a signed scope that names the hosts, the dates and a contact. Port scanning a third party's systems is treated as attempted unauthorised access in France under the provisions protecting automated data processing systems, and in most other jurisdictions, and "it was only a scan" is not a defence. If you want to practise scanning against something realistic, build the lab in Lesson 37 and scan that.
Attack it / Defend it
| The attack | How it works | The control that stops it |
|---|---|---|
| Port scanning | sweeping ranges for services that answer | close unused ports, default-deny firewalls, and alerting on scans that target you specifically |
| Service and version fingerprinting | banner and behaviour matching identifies products and versions | minimise banners and version disclosure, and keep the product patched regardless |
| Host and network sweep | discovering the shape of your estate before attacking it | segmentation, egress and ingress filtering, and monitoring for internal sweeps |
| Subdomain enumeration | certificate transparency and DNS reveal forgotten hosts | inventory names, remove what you no longer need, and avoid issuing certificates for internal-only names |
| Metadata mining | published documents leak paths, usernames and software versions | strip metadata before publication, and review what your website serves |
| Technology fingerprinting | headers and behaviour disclose your stack and whether a WAF sits in front | response header hygiene, and assume disclosure — patch on schedule |
| Scripting-engine checks | targeted probes test for specific known weaknesses | patch the specific flaw, and do not rely on a WAF to hide it |
| Scanning from inside | a compromised host maps the internal network | internal scanning detection, segmentation, and no workstation-to-server port probing |
| Scanning noise as cover | the scan is real and the flood of alerts makes it unremarkable | allowlist authorised scanners and alert on everything else; tune the noise down before the event |
| Using your published footprint | job adverts, conference slides and status pages name your exact versions | keep public information minimal, and treat published technology details as public disclosure |
Key takeaways
- Reconnaissance is the cheapest phase of an attack, and the only phase you can largely remove. Every name, port and version you take out of the public picture is work the attacker has to do elsewhere.
- Passive does not mean lawful. Authorisation, not technique, decides whether the work is legitimate.
- Read nmap output fluently.
open,closed,filteredandopen|filteredmean four different things, and the difference changes your conclusion. - A scan has a shape, and that shape is what you detect — many ports, no data, half-open connections, machine timing.
- Internet scans are background noise; internal scans are findings. Write the allowlist, then alert on what is not on it.
Check yourself
- A service shows as
filteredon port 3306 for one host andclosedfor another. What does each state tell you about whether a database is running? - Why does an
-sSscan often leave nothing in the target application's own log, and where would you see it instead? - Name three artefacts an attacker can find about you without sending a single packet to your network.
- One internal workstation was seen connecting to 1,024 ports across three servers in two minutes. Why is this worth investigating rather than dismissing as a scan?
- You have permission to audit your own external footprint. Describe how you would establish what the internet sees without scanning anything you do not own.