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

[ithilgore <ithilgore.ryu.l () gmail com>]

J Marlow wrote:
> Hi all,
> 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?
> Thanks,
> Josh
>
> _______________________________________________
> Sent through the nmap-dev mailing list
> http://cgi.insecure.org/mailman/listinfo/nmap-dev
> Archived at http://SecLists.Org


By taking a very quick look at the relevant code, we can see the following:

The only place that o.defeat_rst_ratelimit is actually used is at scan_engine.cc
here:

  /* Do not slow down if we are in --defeat-rst-ratelimit mode and the new
     state is closed|filtered. We don't care if it's closed|filtered because
     of a RST or a timeout because they both mean the same thing. */
  if (rcvdtime != NULL
      && o.defeat_rst_ratelimit && newstate == PORT_CLOSEDFILTERED) {
    if (probe->tryno > 0)
      adjust_timing = false;
    adjust_ping = false;
  }

  if (adjust_timing) {
    ultrascan_adjust_timing(USI, hss, probe, rcvdtime);

        ...
  }


The message about "Increasing send delay ... due to ... dropped probes since
last increase." is generated from ultrascan_adjust_timing(). Consequently, I can
assume that this happens because adjust_timing gets false only after that
particular probe has been resent at least once (probe->tryno > 0). I don't know
if that was helpful but might be worth taking into account.


-- ithilgore



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