FYI regarding nmap-payloads, Snort evasion, etc.

[Daniel Miller <bonsaiviking () gmail com>]

List,

I ran across this while testing scan types against Snort IDS. Two of the 
payloads (xdmcp for 177/udp and Amanda for 10080/udp) trigger two 
default rules (sid:1867 and sid:634) when directed from external to 
internal addresses.

After some thought, I considered implementing an option to turn off 
payloads, listing it under IDS evasion methods. However, after digging 
in the code, I found out that using --data-length 0 would have the exact 
same effect (as far as I am aware).

A few more notes from my testing (which is far from complete):

* Nmap's ICMP echo request is detected specifically as Nmap because it 
contains no data. Setting --data-length 48 works to simulate ping from 
Linux.

* The --scan-delay option slows down EVERYTHING. ARP ping, dns 
resolution, version detection, you name it. (Haven't tested NSE scripts).

* To evade the low (default) sensitivity portscan detection built into 
Snort, --scan-delay 15.5s works pretty well. That's VERY SLOW! (and 
generic. There are different thresholds for different scan types.)

* Host detection can be done a little faster with -PY, since anything 
not TCP, UDP, or ICMP is lumped into a single tracker with higher 
detection thresholds (lower sensitivity). It's not as accurate as some 
other detection types, but (unlike -PO50 or others) it's less likely to 
be alerted on.

* There are detection rules for 161,T:705,U:162 that will trigger on any 
traffic at all. May want to avoid these ports.

Note that this testing was with default rules on Snort. There are no 
guarantees that I even set it up correctly, so YMMV. My basic takeaway 
was that if you really need to avoid IDS, plan on doing lots of separate 
scans. My current best effort involves 3 separate invocations of nmap 
just to do host discovery, then 1 for name resolution (on up hosts 
only), and 2 separate scans for ports.

Hope it was helpful!
Dan
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/