Home page logo

nmap-dev logo Nmap Development mailing list archives

Re: --defeat-rst-ratelimit behavior when scanning OS X
From: J Marlow <joshmarlow () gmail com>
Date: Thu, 28 May 2009 18:44:08 -0500

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 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
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 [1 port]
Completed ARP Ping Scan at 19:11, 0.00s elapsed (1 total hosts)
Initiating SYN Stealth Scan at 19:11
Scanning jmac ( [1000 ports]
Discovered open port 111/tcp on
Discovered open port 22/tcp on
Discovered open port 1023/tcp on
Discovered open port 24800/tcp on
Discovered open port 2049/tcp on
Discovered open port 1022/tcp on
Discovered open port 1021/tcp on
Completed SYN Stealth Scan at 19:11, 3.44s elapsed (1000 total ports)
Host jmac ( is up (0.060s latency).
Scanned at 2009-05-28 19:11:23 EDT for 4s
Interesting ports on jmac (
Not shown: 595 closed ports, 398 filtered ports
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.


Sent through the nmap-dev mailing list
Archived at http://SecLists.Org

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]