Nmap’s host discovery is often thought of as just "pinging" hosts, but it’s actually a sophisticated, multi-pronged attack on the network to see who’s home.
Let’s say you have a network segment, 192.168.1.0/24, and you want to know which IPs are actively responding. You’d typically run nmap -sn 192.168.1.0/24.
Here’s what’s happening under the hood, and why it’s so effective:
Nmap doesn’t just send ICMP echo requests like a basic ping. It tries a variety of probes, sending them to the target IPs. The order and type of probes depend on whether you’re scanning a local network or a remote one, and what Nmap "guesses" about the network.
On a local network (like your 192.168.1.0/24 example), Nmap’s default behavior is aggressive:
-
ARP Request: Nmap sends an ARP request for each IP address in the target range. ARP is how devices on a local Ethernet segment find each other’s MAC addresses. If a host is up and on the same segment, it will reply with its MAC address. This is the fastest and most reliable method on local networks.
- Diagnosis: You can see this if you run
tcpdump -i eth0 -nn arpon your scanning machine while Nmap is running. You’ll see ARP requests for IPs that are up. - Fix: If ARP isn’t working (e.g., you’re scanning across a router or a different subnet where ARP won’t cross), Nmap will fall back to other methods.
- Diagnosis: You can see this if you run
-
If ARP fails or isn’t applicable (e.g., scanning a remote subnet), Nmap tries TCP SYN/ACK probes:
- TCP SYN/ACK Scan: Nmap sends a TCP packet with the SYN and ACK flags set to a common port (default is 80 for remote scans, but it can vary). If the host is up and a firewall doesn’t block it, the host will send back a TCP RST (reset) packet. This RST packet indicates the host is alive.
- Diagnosis:
tcpdump -i eth0 -nn 'tcp[tcpflags] & (tcp-syn|tcp-ack) != 0'will show these outgoing SYN/ACK packets. You’ll see RST packets coming back from active hosts. - Fix: If you see no RST packets, it could be a firewall dropping them. Try
nmap -Pn -sT -p 80 192.168.1.0/24. The-Pntells Nmap to skip host discovery and assume all hosts are up, then try a TCP connect scan to port 80. If you get a SYN/ACK and then a RST, the host is alive.
- Diagnosis:
- TCP SYN/ACK Scan: Nmap sends a TCP packet with the SYN and ACK flags set to a common port (default is 80 for remote scans, but it can vary). If the host is up and a firewall doesn’t block it, the host will send back a TCP RST (reset) packet. This RST packet indicates the host is alive.
-
ICMP Echo Request (the classic "ping"): If the TCP SYN/ACK probe doesn’t elicit a response, Nmap sends an ICMP echo request (type 8). A live host will typically respond with an ICMP echo reply (type 0).
- Diagnosis:
tcpdump -i eth0 -nn icmpwill show you the ICMP echo requests and replies. - Fix: If hosts aren’t responding to ICMP, it’s often because firewalls are configured to drop these packets. This is why Nmap doesn’t rely solely on ICMP.
- Diagnosis:
-
ICMP Timestamp Request: If the previous methods fail, Nmap might try sending an ICMP timestamp request (type 13). A host that is up will respond with an ICMP timestamp reply (type 14), which includes the host’s current time.
- Diagnosis: Again,
tcpdump -i eth0 -nn icmpwill show these. - Fix: Like echo requests, these can be blocked by firewalls.
- Diagnosis: Again,
-
UDP Probe: As a last resort, Nmap can send a UDP packet to a port (default is 31337). If the port is closed, the host will send back an ICMP "port unreachable" message (type 3, code 3). If the port is open, no response is sent. The ICMP message is the key here.
- Diagnosis:
tcpdump -i eth0 -nn 'icmp[icmp_type] == 3 and icmp[icmp_code] == 3'will show these ICMP port unreachable messages for closed ports. - Fix: If you suspect UDP probes are being blocked or not working, explicitly try TCP probes with
nmap -Pn -sS -p 22 192.168.1.0/24(using a common port like 22 for a SYN scan).
- Diagnosis:
Crucially, Nmap uses the combination of these probes. It doesn’t wait for all of them to fail. If it gets a response from any of these probes, it marks the host as up.
Common Pitfalls and Solutions:
- Firewalls: This is the #1 reason host discovery fails. Firewalls can block ARP, ICMP, TCP SYN/ACK, or UDP probes.
- Diagnosis: The most telling sign is if Nmap reports hosts as down that you know are up, especially if you can ping them manually from a machine that isn’t being filtered.
- Fix: Use
nmap -Pnto skip host discovery and scan ports directly. If you can scan a port on the target, it’s alive. Example:nmap -Pn -sT -p 80 192.168.1.50.
- Network Segmentation/Routers: ARP only works on the local L2 segment. If you’re scanning a range that includes IPs behind a router, Nmap won’t use ARP for those.
- Diagnosis: Nmap might correctly discover hosts on your local subnet but miss others on different subnets within the scanned range.
- Fix: Nmap will automatically fall back to IP-based probes (TCP, ICMP, UDP) when scanning across routers. Ensure your scanning machine has a route to the target subnets.
- Non-Standard Host Behavior: Some systems might be configured not to respond to common discovery probes for security reasons.
- Diagnosis: If a host is definitely up (e.g., you can SSH into it) but Nmap says it’s down, this is likely the cause.
- Fix: Use
nmap -Pnand scan specific ports you know should be open.
- Rate Limiting: On very large or sensitive networks, excessive probing can trigger security devices or overwhelm routers.
- Diagnosis: You might see sporadic discovery failures or even network instability.
- Fix: Use Nmap’s timing options to slow down.
nmap -T3 -sn 192.168.1.0/24(default is T3, try T2 for slower).
After fixing your host discovery issues, the next problem you’ll likely encounter is understanding why certain ports appear closed when they should be open, which usually leads into firewall-specific port scanning techniques.