Re: New Nmap options for IDS interaction

[Theo Dzierzbicki <auxeras () gmail com>]

> 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/