Nmap Development mailing list archives
Re: New Nmap options for IDS interaction
From: Theo Dzierzbicki <auxeras () gmail com>
Date: Tue, 2 Mar 2010 22:34:17 +0100
Can you mock up some command lines showing how the new options would be used? I think that would help me understand your proposal.
Certainly. Let's try to explain the uses cases more clearly. Objective : avoid detection by IDSs during a port scan. Example IDS rules ( taken directly from "Nmap Network Scanning" ) : o first use case : fixed time scale detection. The IDS watches for 'scanner-fixed-threshold' probe packets to any host in the network in 'scanner-fixed-window' seconds ( both defaulting to 15 in Snort defaults ) ---> Current solution : Single target : $ nmap --scan-delay 1075 $target Not just 1000 ( 1s ). Nmap would send 15 probes in 14s ( no delay before 1st probe, so counting from zero ) and would trigger the alarm. Multiple targets ( same network ) : $ for target in $(cat target_list); do nmap --scan-delay 1075 $target sleep 2 done; You can't just do a "nmap --scan-delay 1075 --max-hostgroup 1 -iL target-list", because after finishing scanning a host, nmap won't wait '--scan-delay' seconds before starting to send probes to the next host, and you will trigger the alarm. Of course, you could just raise '--scan-delay' to at least 1155, but you would have to be careful about scanning at least 15 ports per host, otherwise you're caught. Besides, if you choose to use the shell script instead of the calculation method, be careful to randomize manually the list of hosts, because nmap won't be able to do the job for you as usual, and a linear scan of 192.168.1.1 - 192.168.1.2 -... will probably be flagged too. I don't know about you, but to me this starts to make a lot of maths for a simple scan of a host list. ---> Proposed solution : $ nmap --scanner-threshold 14 --scanner-window 15 { target || -iL target_list } Forcing nmap to send no more than 14 probe packets in a window of 15 seconds. End of story. o second use case : sliding time scale detection. Mostly the same principle as the above, only addition : each time the IDS sees a probe, it re-increases the window by a factor ( Snort defaults : factor = 0.5, scanner-window = 20, scanner-threshold=40 ). illustration by an example : you send your first probe, triggering the mecanism. You then wait 10s, then send your second probe. The window, which was decreased to 10s, is reaugmented to 15s. ---> Current solution : Single target : $ nmap --scan-delay 20001 One probe every 20.01s . Not so bad. But maybe a little bit frustrating knowing you could be quicker. Multiple targets ( same network ) : $ for target in $(cat target_list); do nmap --scan-delay 20001 $target sleep 2 done; Exact same problems as above, but even slower. ---> Proposed solution : $ nmap --scanner-threshold 39 --scanner-window 20 --scanner-delay 20 { target || -iL target_list } Forcing nmap to send no more than 39 probes in a 20s window, and to wait 20s after sending the last probe before resuming. Again, way simpler ( and even quicker this time ). If the two rules were present ( as in the default Snort configuration ), you would end up with someting like : $ nmap --scanner-threshold 14 --scanner-window 15 --scanner-delay 20 { target || -iL target_list } Et voila ! Both alarms are avoided. Of course IDS do not have only two rules. There is other behaviors to avoid if you really don't want to trigger anything, but for simple port scanning, these two types of rules seem to be the worst ennemies. The main advantage I would see in these options is that as they are formuled in the same terms that the IDSs rules, they are way more natural for interaction with them. You don't have to torture yourself wondering how not to minimize your '--scan-delay' waste. Just focus on trying to guess the level of paranoia of the network admins, "as usual". Obviously the same logic applies on the admin side. You configure Snort with scanner-window=10 scanner-threshold=10, you launch Nmap on one of your hosts with --scanner-window 10 --scanner-threshold 10, you trigger your own alarm, everything works, next problem. I should probably have tried this explanation first. Is it clearer this way ?
Look in the file scan_engine.cc. The structs ultra_timing_vals, send_delay_nfo, and rate_limit_detection_nfo control most timing. Search for variables with those types and see where they are used an modified. ultrascan_adjust_timing is noteworthy.
Duly noted. I'm starting to investigate right away. Cheers, Theo _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://seclists.org/nmap-dev/
Current thread:
- New Nmap options for IDS interaction Theo Dzierzbicki (Feb 28)
- Re: New Nmap options for IDS interaction David Fifield (Mar 01)
- Re: New Nmap options for IDS interaction Theo Dzierzbicki (Mar 02)
- Re: New Nmap options for IDS interaction David Fifield (Mar 16)
- Re: New Nmap options for IDS interaction Theo Dzierzbicki (Mar 02)
- <Possible follow-ups>
- Re: New Nmap options for IDS interaction Theo Dzierzbicki (Mar 09)
- Re: New Nmap options for IDS interaction David Fifield (Mar 16)
- Re: New Nmap options for IDS interaction David Fifield (Mar 16)
- Re: New Nmap options for IDS interaction David Fifield (Mar 16)
- Re: New Nmap options for IDS interaction David Fifield (Mar 01)