New Nmap options for IDS interaction

[Theo Dzierzbicki <auxeras () gmail com>]

Hi everyone,

I send this mail to ask for comments about some ideas I had about adding new
nmap timing options for IDSs.

I am following this list for about two months now ( but this is my first
post ), and I've read "Nmap Network Scanning". One thing that annoyed me was
the recommended approach about IDS evasion (Chapter 10.5 : "Subverting
IDSs").
Having to use a shell script to restart Nmap for each host you want to port
scan. Maybe some options should be implemented to address this situation.

o New options ideas :

So basically if I understood well, the way packets should be sent to avoid
detection by an IDS is something like :
- Send no more than X packets in a time t1
- Then wait at least until t2 before sending anything again.

An ASCII scheme to sum up a bit ( you will probably have to copypaste it in
a terminal to actually see something ) :

|----|----|----|----|----|-----------------|----|----|----|----|----|-----
...

|_t0_|
|___________t1___________|
                         |________t2_______|


Anyway :
 t0 => delay between each packet ( --scan-delay )
 t1 => time lapse in which to send packets
 t2 => delay before we can send packets again
 X  => number of packets to send per iteration

Simply put, three valid combinations of options :
- A number of packets X per interval t1, and delay t2 (--scan-delay t0
implied)
- A delay between packets t0, a time to send them t1, a delay t2 ( X number
of
packets implied )
- A number of packets X to send with a delay t0 between them, then wait for
delay t2 ( t1 to send packets implied )

Sorry for the pseudo-mathematical notation, but I find it clearer this way.
I haven't thought of meaningful names as of now.

Adding these options would give nmap "rules" just like the IDS rules ( using
the same parameters ).
Nmap would become more straightforward in interacting with IDS ( testing or
evading ) if they spoke the same language.

o Main implications ( problems I can envision, using all my inexperience ) :

- Conflict with some other timing options ( --min/max-rate ),
not-yet-obvious
behavior with others ( --host-timeout, --min/max-parallelism )
- Take in account the fact that some probes will need to be sent in sequence
without interruption ( NSE scripts ). Maybe this can be ignored, as it
probably
means version detection scripts, and like stated in the book this will be
logged anyway.

o Miscellaneous questions :

- What do you think about the idea ( useful/feasible ) ? Any misconceptions
/
oversights ?
- From what I've read in the HACKING file, and what I've seen on the list,
it
seems the right place to ask questions about technical points / feature
development is precisely the list. Correct ?
- If the idea is welcomed, maybe please a pointer to get me started with the
implementation ? I would do it gladly but I'm a newbie with the codebase
( Subliminal message : for now. The GSoC is near :) ... )

Cheers,
Theo Dzierzbicki
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/