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

["Jones, David H" <Jones.David.H () principal com>]

I think it would be a great addition to the scanning engine, we already have several uses for it currently.  One thing 
I did have to change in the patch was the default display of closed|filtered for non-responsive ports (I believe it 
was... Been a while now) because we scan a lot of filtering devices that just drop packets in to the bit bucket.  Doing 
a scan of all ports, well, that just generated a *lot* of data, and it became kind of useless unless I was dumping to a 
file then grepping for results.  I don't have the changes I made in front of me, but it was a quick fix... I can dig it 
up if needed. 


David Jones
Principal Financial Group
I/S Information Security
711 High Street
Des Moines, IA 50392-0257

Email:  jones.david.h () principal com
Phone:  515.362.2224   

-----Original Message-----
From: nmap-dev-bounces () insecure org [mailto:nmap-dev-bounces () insecure org] On Behalf Of Fyodor
Sent: Thursday, April 20, 2006 6:33 PM
To: nmap-dev () insecure org
Subject: Re: Extremely long scan times... (Martin's defeat_ratelimits patch)

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


-----Message Disclaimer-----

This e-mail message is intended only for the use of the individual or
entity to which it is addressed, and may contain information that is
privileged, confidential and exempt from disclosure under applicable law.
If you are not the intended recipient, any dissemination, distribution or
copying of this communication is strictly prohibited. If you have
received this communication in error, please notify us immediately by
reply email to Connect () principal com and delete or destroy all copies of
the original message and attachments thereto. Email sent to or from the
Principal Financial Group or any of its member companies may be retained
as required by law or regulation.

Nothing in this message is intended to constitute an Electronic signature
for purposes of the Uniform Electronic Transactions Act (UETA) or the
Electronic Signatures in Global and National Commerce Act ("E-Sign")
unless a specific statement to the contrary is included in this message.


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