Nmap Development mailing list archives
RE: Extremely long scan times... (Martin's defeat_ratelimits patch)
From: "Jones, David H" <Jones.David.H () principal com>
Date: Fri, 21 Apr 2006 08:52:03 -0500
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
Current thread:
- Re: Extremely long scan times... (Martin's defeat_ratelimits patch) Fyodor (Apr 20)
- Re: Extremely long scan times... (Martin's defeat_ratelimits patch) Martin Mačok (Apr 21)
- Re: Extremely long scan times... (Martin's defeat_ratelimits patch) Martin Mačok (May 14)
- <Possible follow-ups>
- RE: Extremely long scan times... (Martin's defeat_ratelimits patch) Jones, David H (Apr 21)