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

[J Marlow <joshmarlow () gmail com>]

On Wed, May 27, 2009 at 12:26 AM, David Fifield <david () bamsoftware com> wrote:
> 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

Hi all,

I've committed a change that fixed this bug.  The use of the command
is unchanged, but here is a usage example.  jmac is a machine with OS
X installed on it.

sudo nmap -sS -vv --defeat-rst-ratelimit jmac

Here is the output:

Starting Nmap 4.85BETA9 ( http://nmap.org ) at 2009-05-28 19:11 EDT
NSE: Loaded 0 scripts for scanning.
Initiating ARP Ping Scan at 19:11
Scanning 192.168.1.20 [1 port]
Completed ARP Ping Scan at 19:11, 0.00s elapsed (1 total hosts)
Initiating SYN Stealth Scan at 19:11
Scanning jmac (192.168.1.20) [1000 ports]
Discovered open port 111/tcp on 192.168.1.20
Discovered open port 22/tcp on 192.168.1.20
Discovered open port 1023/tcp on 192.168.1.20
Discovered open port 24800/tcp on 192.168.1.20
Discovered open port 2049/tcp on 192.168.1.20
Discovered open port 1022/tcp on 192.168.1.20
Discovered open port 1021/tcp on 192.168.1.20
Completed SYN Stealth Scan at 19:11, 3.44s elapsed (1000 total ports)
Host jmac (192.168.1.20) is up (0.060s latency).
Scanned at 2009-05-28 19:11:23 EDT for 4s
Interesting ports on jmac (192.168.1.20):
Not shown: 595 closed ports, 398 filtered ports
PORT      STATE SERVICE
22/tcp    open  ssh
111/tcp   open  rpcbind
1021/tcp  open  unknown
1022/tcp  open  unknown
1023/tcp  open  netvenuechat
2049/tcp  open  nfs
24800/tcp open  unknown
MAC Address: 00:1B:63:C1:F5:ED (Apple)

Read data files from: /usr/local/share/nmap
Nmap done: 1 IP address (1 host up) scanned in 4.17 seconds
           Raw packets sent: 1656 (72.862KB) | Rcvd: 607 (24.374KB)

As you can see, we no longer have the "Increasing send delay..." message.

Cheers,
Josh

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