Nmap Development mailing list archives
Re: New Nmap options for IDS interaction
From: David Fifield <david () bamsoftware com>
Date: Tue, 16 Mar 2010 12:27:31 -0600
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/
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)