nmap Network Discovery: Safe Scanning for Sysadmins

Every network administrator eventually needs an inventory that the documentation does not provide: which hosts are alive, which ports are listening, and which services are running on them. nmap answers those questions, but it also generates traffic that intrusion detection systems treat exactly like an attack, and it can crash fragile embedded devices. This guide covers the scan types that are appropriate for production management networks, the timing controls that keep scans from melting switches, and how to interpret results without over-trusting them.

Starting with host discovery

# ICMP echo plus TCP SYN to common ports - the default discovery sweep
nmap -sn 10.10.10.0/24

# Skip discovery and treat everything as up (for firewalled subnets)
nmap -Pn -p 22,80,443 10.10.20.0/24

# ARP discovery on the local L2 segment (fastest and most accurate)
nmap -sn -PR 192.168.1.0/24

On a directly connected subnet, ARP-based discovery is authoritative: a host that answers ARP exists, regardless of host firewall rules. Across routers, ICMP is frequently filtered, which is why -Pn exists — but skipping discovery on a /22 will probe every address and can take hours.

Choosing a scan technique

# A practical inventory scan of a management network
nmap -sS -sV --version-light -p 22,23,80,443,161,830,3389,5900 10.10.10.0/24 -oA mgmt-scan

# UDP services worth checking on network gear
nmap -sU -p 123,161,514,1900 10.10.10.0/24

Timing control: how to scan without causing an incident

# Polite timing for production
nmap -T2 --max-rate 50 --max-retries 2 10.10.10.0/24

# Scan a full subnet but never more than 20 concurrent probes
nmap --min-parallelism 5 --max-parallelism 20 -p 1-1024 10.10.20.0/24

-T4 and -T5 are aggressive enough to trigger IDS alarms and to overload cheap embedded devices — printers and IP cameras regularly lock up during -T5 scans. For network equipment, -T2 with an explicit --max-rate is the responsible default. Also remember that switch control planes rate-limit ICMP and ARP: a scan that saturates a CPU management path can drop routing adjacencies on older chassis.

Scan etiquette in production

• Get written authorisation. Port scanning networks you do not own is a legal problem, not just a policy one.
• Notify the security team with the source IP, target range and time window before scanning.
• Exclude sensitive subnets — medical devices, industrial control systems and SCADA equipment do not tolerate unexpected probes.
• Scan from a dedicated management host, not from a router or firewall whose performance matters.
• Record the exact command line in your inventory documentation so the results are reproducible.
• Never run --script vuln against production systems without a change window; some scripts are intrusive by design.

Reading the output critically

nmap -sV -oA scan-20260921 10.10.10.15
grep -E "open|filtered" scan-20260921.nmap

Three interpretations to keep in mind:

• filtered means a firewall dropped the probe silently — the port may well be open behind it.
• closed means the host answered with a reset; that is a definitive statement about the host, not about the path.
• open|filtered (common with UDP) means no response was received at all; on UDP you often need application-level confirmation.

Turning scans into an asset inventory

nmap -sS -Pn -p- --open -oX full-scan.xml 10.10.30.0/24
python3 -c "
import xml.etree.ElementTree as ET
t = ET.parse('full-scan.xml')
for h in t.iter('host'):
    ip = h.find(\"address[@addrtype='ipv4']\").get('addr')
    ports = [p.get('portid') for p in h.iter('port') if p.find('state').get('state')=='open']
    print(ip, ','.join(sorted(ports, key=int)))
"

A monthly full-range scan with XML output, diffed against the previous month, is one of the cheapest ways to detect shadow IT and accidental service exposure. Feed the diff into your change process — a new open port on a production subnet should always have a corresponding ticket.

nmap finds hosts and ports; it does not tell you which interface is dropping packets or which neighbour entry is stale. Pair it with the OS-level tools covered in the related articles below for a complete picture.

Interpreting service and version detection results

Version detection is the most misread part of an nmap report. A banner claiming a version does not mean the service is patched to that level, and a vendor-supplied appliance often reports a version string the vendor invented. Treat -sV output as a hypothesis:

nmap -sV --version-all -p 22,443 10.10.10.15
nmap -sV --script=banner -p 22 10.10.10.15

For asset inventory this distinction matters less than for vulnerability management. Inventory needs "there is a service here and it belongs to this team", which the banner answers. Vulnerability management needs the exact build, which requires authenticated inspection rather than a network scan.

Scanning across firewalls and segments

Networks are rarely flat, and a scan that works in the lab can produce a wall of filtered results in production. Adjust the technique rather than increasing the aggression:

• From a management segment that can reach everything, scan with -Pn and rely on port responses rather than ICMP.
• Behind a firewall that drops SYNs, -sA tells you which ports are filtered without generating completed connections.
• For UDP services, accept that results are probabilistic and confirm important findings with a purpose-built client (for example snmpwalk for SNMP).
• Scan the same range from two vantage points — network segmentation means the answer depends on where you ask.

# Two-vantage comparison
nmap -sS -Pn -p 22,80,443,161 --open -oG - 10.10.40.0/24 | awk '/Ports/{print $2}' | sort > /tmp/from-mgmt.txt
ssh admin@edge-host "sudo nmap -sS -Pn -p 22,80,443,161 --open -oG - 10.10.40.0/24" | awk '/Ports/{print $2}' | sort > /tmp/from-edge.txt
diff /tmp/from-mgmt.txt /tmp/from-edge.txt

A diff between two vantage points is one of the fastest ways to discover an unexpected open management interface that only some segments can reach — exactly the kind of finding that matters before an audit.

Keeping scans legal and welcome

Documentation is part of the scan. For each scan, record the authorisation reference, the operator, the source IP, the exact command, the target scope and the time window. This single habit turns a contentious conversation into a trivial one, and it is what compliance auditors ask for first.

Related articles

For host-level diagnosis use Linux network troubleshooting command scenarios and the structured approach in Linux network connectivity troubleshooting method. Socket and capture-level verification is covered in Linux network troubleshooting with ss, netstat and tcpdump.

原文链接：https://nmap.org/book/man.html