Nmap Development mailing list archives

Re: Extremely long scan times... (Martin's defeat_ratelimits patch)


From: Fyodor <fyodor () insecure org>
Date: Thu, 20 Apr 2006 16:32:41 -0700

On Fri, Mar 17, 2006 at 11:15:10PM +0100, Martin Mačok wrote:
On Fri, Mar 17, 2006 at 03:18:05PM -0600, Jones, David H wrote:

So, to make a short question long, is there any way to force nmap to
ignore these ICMP messages, or to disable the automatic throttling
and just push through it?

http://Xtrmntr.org/ORBman/tmp/nmap/nmap-3.95-defeat_ratelimits.patch

Applies to all 3.95 and newer releases...

Many people find that patch useful, and I've been contemplating adding
it to the base distribution for a while now.  I'm pretty conservative
about changing the core port scanning engine.  But it is a short
patch, and is effective at what it does.  But I have a few concerns:

o There is a chance of reducing accuracy, since the patch causes Nmap
  to rely on no-response cases (which can occasionally be caused by
  dropped packets) rather than the more certain ICMP errors.  Also, it
  will cause some issues when Nmap is updated to tell why it
  classified a port a certain way.  Some of the filtered ports will
  say "due to ICMP unreachable message" while others will say "no
  response" for the same target host.  Neither of these are huge
  issues, but I'd like to implement this patch for -T4 and higher at
  first.  Most people who will need this will be using at least -T4
  anyway.  Maybe we can make it the default behavior later.  This
  change just takes an extra 'o.timing_level > 3' conditional.

o These ICMP unreachables don't always slow down a scan.  When send
  rate limiting isn't in effect, they usually make the scan faster.  Yet
  this patch ignores the fast ones too.  Maybe a test should be added
  which tests if probe->tryno == 0 and still takes timing values in that
  case.

o The new --defeat_rst_ratelimit patch should be changed to the
  new-style --defeat-rst-ratelimit (it is probably best to support both,
  as most Nmap options do) and documented in the Nmap man page XML
  source at http://www.insecure.org/nmap/data/nmap-man.xml .

Martin, do you think you could make these changes, test them, and
resubmit the patch?  If you won't have time, let me know and I'll see
what I can do.

Thanks,
Fyodor



_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev

Current thread: