Re: New Nmap options for IDS interaction

[David Fifield <david () bamsoftware com>]

On Wed, Mar 10, 2010 at 12:54:55AM +0100, Theo Dzierzbicki wrote:
> Hello again,
>
> It's been a week since I started to work on this possibles options, and
> I'm having some trouble with the implementation, so I thought that even
> if the options are NOT yet working correctly, this could be a good time to
> report and ask for some advices.
>
> The attached patch states my current progress.
>
> I dived in the scan_engine.cc file as you told me, and tried to modify
> the sendOK() function. This function happens to be a different method
> for the three classes HostScanStats, GroupScanStats and UltraScanInfo.
>
> For a "global" timing option, change a HostScanStats method seemed
> inappropriate, and the UltraScanInfo::sendOK method is only called by
> the waitForResponses function, so I choose to modify GroupScanStats::sendOK.
>
> I simply added a counter that increments for any sends we allow in a
> given window --ids-window, with a condition that returns false when a given
> --packet-threshold number of send have been reached. When the window
> ends the count is reseted to 0, and we start sending again.
>
> The values of the window start and the packet count cannot be retained in
> GroupScanStats, or else when completing a group the information would be lost.
> I then added fields in the ultra_scan_performance_vars structure to hold them.
>
> The main problem I encounter is that I cannot control precisely the
> number of packets sent. When testing with tcpdump it appears that the
> number of packets per window is often not exactly --packet-threshold,
> although never too far from it ( between -2 and +10 globally ).
>
> I did not yet check every function that seemed likely to send packets to see
> if it could send more than one probe without asking again. Is it possible ?
> If yes, then sendOK is probably not the right place for this change.
> Maybe an advice about where to go then ?

You shouldn't be increasing your packet_count variable in sendOK. When
that function is called it doesn't guarantee that a packet is sent. I
think you want to do it here, in sendNextScanProbe:

static void sendNextScanProbe(UltraScanInfo *USI, HostScanStats *hss) {
  probespec pspec;

  if (get_next_target_probe(USI, hss, &pspec) == -1) {
    fatal("%s: No more probes! Error in Nmap.", __func__);
  }
  hss->numprobes_sent++;
  USI->gstats->probes_sent++;

sendOK is the right place to enforce the limit. There are three sendOK
functions. This change should probably be in GroupScanStats::sendOK.

> Second question, apart from the fact that it is not working yet, is it
> something wrong with the patch ? It happens to be my first attempt at
> patching, so comments would be really welcomed in case of silly mistakes ...

It looks good to me and it applied cleanly. Just use a more descriptive
name than "nmap.patch".

> Last question : when looking at debugging output, I saw messages looking
> like "Current sending rates : XX packets / s", coming from timing.cc. Do
> you think it is worth a look in this case ? Anyway it is much shorter
> than scan_engine.cc and its 5500+ lines, so I might end up skimming
> through it just out of curiosity :) ...

That code (PacketRateMeter) is used to enforce --min-rate and
--max-rate. The rate information is interesting on its own, so it's
included in the output (if debugging is on, I think). This might not be
suitable for IDS evasion because it only maintains a long-term average
rate. (Here "long-term" is a few seconds.) It might increase above a
maximum specified rate to keep up the average.

David Fifield
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/