Nmap’s continuous monitoring is less about real-time alerts and more about detecting drift from a known good state.
Here’s how you can use Nmap to track network changes over time, simulating a continuous monitoring setup:
# Initial scan of a small subnet
nmap -oG initial_scan.gnmap 192.168.1.0/24
# Later, perform another scan
nmap -oG subsequent_scan.gnmap 192.168.1.0/24
# Compare the two scans to find differences
grep -vE 'Up|Down' initial_scan.gnmap > initial_hosts.txt
grep -vE 'Up|Down' subsequent_scan.gnmap > subsequent_hosts.txt
comm -23 initial_hosts.txt subsequent_hosts.txt # Hosts that disappeared
comm -13 initial_hosts.txt subsequent_hosts.txt # Hosts that appeared
This basic approach highlights new devices or devices that have gone offline. For more detailed change detection, you’d typically script this process with more sophisticated diffing and reporting.
The core problem Nmap continuous monitoring aims to solve is the "unknown unknowns" on your network. Devices get added, removed, or change their network identity (IP address, open ports) without explicit notification. This can lead to security vulnerabilities (unpatched rogue devices), misconfigurations, or simply a loss of inventory. Nmap, when run periodically, acts as a network census taker, allowing you to spot deviations from previous censuses.
Internally, Nmap works by sending various types of packets to target hosts and analyzing the responses (or lack thereof). For a simple host discovery scan (like -sn or the implicit discovery in a port scan), it might use ARP requests on a local network, ICMP echo requests (ping), or TCP SYN packets to common ports (like 80 or 443). The presence or absence of a response, and the type of response, tells Nmap whether a host is up and potentially what services it’s running.
When you run Nmap periodically, you’re essentially taking snapshots of your network’s "state" at different points in time. By comparing these snapshots, you can infer changes. The grep -vE 'Up|Down' is a simple way to filter out the status lines in the "grepable" output (-oG) and focus on the host entries themselves. comm is a powerful utility for comparing sorted files line by line. comm -23 shows lines unique to the first file (hosts that were present initially but are now gone), and comm -13 shows lines unique to the second file (hosts that have appeared since the initial scan).
The real power comes when you automate this. You could set up a cron job that runs Nmap daily or weekly, saves the output, and then runs a script to compare it against the previous day’s or week’s scan. This script could then email you a report of any new hosts, disappeared hosts, or changes in open ports on existing hosts.
Leveraging Nmap’s XML output (-oX) and an XML parsing tool (like xmllint or a scripting language with XML libraries) provides a more structured way to compare scan results. You can parse the XML to extract specific information like IP addresses, MAC addresses, and open ports for each host, then compare these structured data points programmatically. This is far more robust than text-based diffing.
To detect changes in services or ports, you’d move beyond simple host discovery and perform a port scan. For instance, nmap -sV -oG scan_with_services.gnmap 192.168.1.0/24. Comparing the output of such scans over time would reveal if a new port has opened, a previously open port has closed, or if the service version detected on a port has changed.
The most surprising true thing about Nmap’s continuous monitoring is that its primary strength isn’t in providing real-time alerts like a dedicated Intrusion Detection System (IDS). Instead, its utility lies in its ability to provide a highly detailed, periodic audit trail of your network’s composition and open services, making it excellent for detecting drift and unexpected additions or removals over longer timeframes. It’s a detective, not a siren.
When you’re comparing scans of the same subnet over time, if a host has changed its IP address but its MAC address remains the same (within a local network segment), Nmap might report it as a new host if you’re only comparing IP addresses. However, if you’re using the grepable output (-oG) or XML output and look for matching MAC addresses, you can identify IP address changes more reliably. This is crucial for tracking devices that might be using DHCP and have acquired a new IP.
The next logical step is to integrate these Nmap scan comparisons into a larger monitoring or SIEM system, where the diff reports can be correlated with other network events.