I want to scan a range of network with nmap to discover hosts but I know that depending on the scan, it can affect the integrity of OT (Operational Technology) devices, industrial devices like PLCs (Programmable Logic Controllers).
For this, I use the following command:
nmap -sn -n --scan-delay 1s <ip range>
I don't know if in this command these are the parameters that will supply my desired output.
Is there any way to improve it?
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:
--data-length can mitigate this, but it will affect all other packets, leading to more unusual cases like TCP SYN with data.-PA) is not allowed by RFC.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 -sS.
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).
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.
The --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:
-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.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 --scan-delay and --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.
Good luck!