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

[Martin Mačok <martin.macok () underground cz>]

On Thu, Apr 20, 2006 at 04:32:41PM -0700, Fyodor wrote:

> 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.

I accept this and I know that the code makes some "blind" assumptions
about the code outside the scope of the code it is directly changing.
But I don't think this could be changed without actually implementing
that functionality in some way so I don't think it is worth changing
the patch in the meantime... (and I also think that there are more
places in Nmap code that makes similar-style "blind" assumptions).

>   Maybe we can make it the default behavior later.  This
>   change just takes an extra 'o.timing_level > 3' conditional.

OK with me, implemented.

> 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.

OK with me, implemented. Are you sure that those ICMP errors can't be
coming back too fast (say, from a firewall in front of the target with
a very slow link between the firewall and the target)?

> 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 .

Previous patch already implemented that ;-)

I haven't updated the manpage because I think my english sucks a bit.
Anyone feel free to copy/paste/polish from the head of the patch.

Everything is at
http://Xtrmntr.org/ORBman/tmp/nmap/

On Fri, Apr 21, 2006 at 08:52:03AM -0500, Jones, David H wrote:

> One thing I did have to change in the patch was the default display
> of closed|filtered for non-responsive ports

This is only a case when --defeat-rst-ratelimit is in use. In this
mode the scanner really doesn't know which port is filtered and which
is closed so telling anything else than "closed|filtered" would be
false in some cases.

Anyway, last time I came across such RST-limiting it wasn't Solaris
box but some firewall/IPS that switched from ICMP (ratelimited) to
sending some occasional RST back after some time. This technique made
Nmap extremely slow unless using --defeat-rst-ratelimit against it.

Martin Mačok
ICT Security Consultant


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