Operation Technology, Industrial Control systems (ICS and SCADA), medical devices, embedded devices, and specialized communications systems can be frighteningly fragile, especially considering the degree of trust that is placed in them and the serious consequences that follow when they are brought down. Nmap and other non-standard network software can cause problems, partially because they operate at the edge cases of the RFC standards for TCP/IP, and partially because they are designed to reach out and touch things in ways that system designers have not considered.
With the understanding that every interaction with these systems carries a degree of risk, here are some guidelines on what Nmap options are the most and least likely to cause disruptions, organized by scan phase.
Often overlooked, this phase is where target addresses are chosen. Usually these are specified directly on the command line, but it can be safer to put your targets in a text file and use
-iL to pass them to Nmap. This is especially helpful if your targets are being provided by someone else, as it eliminates the possibility of fat-fingering an address. You can also use
--excludefile option to exclude known out-of-scope addresses from your scan.
Nmap sends several different kinds of probes to determine if a target is listening. Most of these are pretty harmless, but when scanning sensitive systems it may be best to explicitly choose your host discovery methods with
-P* options. In particular:
- switches may have difficulty with large numbers of ARP requests
- Nmap's ICMP datagrams are sent without any data by default, which is unusual. Adding
--data-length can mitigate this, but it will affect all other packets, leading to more unusual cases like TCP SYN with data.
- The default host discovery sends raw TCP SYN and ACK probes to port 443 and 80. Unsolicited ACK (
-PA) is not allowed by RFC.
Reverse DNS resolution
Here you don't need to worry. Reverse-DNS is performed between Nmap and your configured DNS servers, and does not result in traffic being sent to the target IP directly. Specifying
-n will skip this step for a small speed boost, but it won't have an effect on the target.
Port scanning is problematic. Leaving aside the more esoteric scan options (
-sA/W/M/N/F/X) which are explicitly RFC-abusive, simply doing a raw SYN scan can bring down targets which allocate resources for incoming TCP connections that never happen. This is known as a SYN flood. Always make sure that the system you are scanning from will send a TCP RST packet in response to an unsolicited ACK, since Nmap itself does not bother to reset its half-open connections. In some cases, this is still not sufficient, because Nmap's crafted TCP packets are just unusual enough to cause targets to freak out.
TCP Connect scan (
-sT) uses the OS's native socket operations to attempt to open connections. This slightly slower method can reduce some of the unusualness of your scan, but at the cost of completing a full TCP connection to each open port, and then immediately closing it. Rob Graham notes that some older Unix-like systems handle reset connections in a way that can cause the service on the port to crash. So consider which part of your target is more fragile: if the OS or TCP stack, then use
-sT; if the service or application, then use
In your question you are using the
-sn option, which turns off port scanning. This is, of course, the safest option, but it does not provide any port scan data (duh).
Version detection, OS detection, and NSE script scanning
Here be monsters. Version detection sends a bunch of unsolicited data to target services to elicit unique responses. OS detection does the same thing to the TCP/IP stack. NSE scripts can do either, and in more creative, complicated, and intense ways. While these are some of the most fun and interesting features of Nmap, I recommend strongly against using them on potentially fragile targets in an operational environment.
--traceroute option is probably pretty safe, simply because it does not send any type of probe that either host discovery or port scan did not already send. The exceptions are:
- If you did a TCP Connect scan (
-sT), traceroute may still send raw TCP packets, because it needs to manually decrement the TTL field. It prefers to send packets to closed ports, though, to reduce the issues discussed earlier regarding SYN flooding.
- Because it decrements the TTL, it will end up sending a probe to the target that arrives with a TTL of 0 or 1. This is an unusual case, and though it is well specified in the RFC, unusual cases are where things break most.
Inigo Montoya: But, I promise I will not kill you until you reach the top.
Man in Black: That's VERY comforting, but I'm afraid you'll just have to wait.
Inigo Montoya: I hate waiting.
If there's one thing that can be counted on to make a target unresponsive, it's too much traffic. Nmap tends to be better than many scanners in this regard because it reduces speed when it detects packet drops, but sometimes that's not enough. Using the
-T2 (2.5 packets per second) or
-T1 (4 packets per minute) options can be helpful in these cases, or you can manually tune the values with
--max-rate. In any case, slow it down and get ready to wait.
I periodically search Twitter for mentions of Nmap crashing devices, which I retweet with the #KilledByNmap hashtag. There is also a little-maintained list of fragile devices started by some folks at SANS called the Network Scanning Watch List.