Re: --defeat-rst-ratelimit behavior when scanning OS X

[David Fifield <david () bamsoftware com>]

On Tue, May 26, 2009 at 12:16:16AM -0500, J Marlow wrote:
> David asked me to look into the behavior of the --defeat-rst-ratelimit
> option when scanning OS X systems.
> I did a SYN scan against with the --defeat-rst-ratelimit option and get:
>
> Increasing send delay for 10.0.0.2 from 0 to 5 due to 218 out of 725
> dropped probes since last increase.
>
> Or something to that effect.  It seems to be slightly sporadic (not
> all runs show an increase, but some do).
> So --defeat-rst-ratelimit appears to be broken...sometimes.  Has
> anyone else encountered this before?

I started digging into this. I don't think --defeat-rst-ratelimit has
*ever* worked. It was introduced in r3355:

------------------------------------------------------------------------
r3355 | fyodor | 2006-05-15 16:37:31 -0600 (Mon, 15 May 2006) | 1 line

Added Martin Macok ratelimit patch with minor changes
------------------------------------------------------------------------

In http://seclists.org/nmap-dev/2006/q2/0191.html, it says "The only
thing I changed (besides documenting --defeat-rst-ratelimit) is to
remove the PORT_CLOSEDFILTERED stat which used instead of closed and
filtered when --defeat-rst-ratelimit was specified." I suppose from this
that an earlier --defeat-rst-ratelimit patch used closed|filtered for
received RSTs and no-responses. That was changed before the patch was
integrated, but the logic still referred to PORT_CLOSEDFILTERED:

  /* If we are in --defeat-rst-ratelimit mode, we do not care whether we got RST back or not
   * because RST and "no response" both mean PORT_CLOSEDFILTERED. Do not slow down */
     !(o.defeat_rst_ratelimit && newstate == PORT_CLOSEDFILTERED && probe->tryno > 0)) { /* rcvdtime is interesting */

Changing it to PORT_CLOSED makes it work. I think we also need to add
!noresp_open_scan to keep it from taking effect for UDP in a -sSU scan.

David Fifield

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