Nmap Development: Re: New option: --min-rate for minimum-rate scanning

From: eldraco <eldraco_at_gmail.com>
Date: Thu, 3 Apr 2008 11:14:19 -0300

Hi list, I was trying --min-rate parameter, so here are my results...

First of all, the "Overall sending rates" are not written in the output file,
if we can have them there it would be wonderful!

xx.xx.xx.xx target it's 9 hops away into Internet.

--min-rate parameter Tests
--------------------------

Rtt estimation to target xx.xx.xx.xx

hping3 -S -p 110 xx.xx.xx.xx
HPING xx.xx.xx.xx (eth0 xx.xx.xx.xx): S set, 40 headers + 0 data bytes
len=46 ip=xx.xx.xx.xx ttl=54 DF id=0 sport=110 flags=SA seq=0 win=5840
rtt=41.4 ms
len=46 ip=xx.xx.xx.xx ttl=54 DF id=0 sport=110 flags=SA seq=1 win=5840
rtt=42.4 ms
len=46 ip=xx.xx.xx.xx ttl=54 DF id=0 sport=110 flags=SA seq=2 win=5840
rtt=31.2 ms
len=46 ip=xx.xx.xx.xx ttl=54 DF id=0 sport=110 flags=SA seq=3 win=5840
rtt=45.8 ms
len=46 ip=xx.xx.xx.xx ttl=54 DF id=0 sport=110 flags=SA seq=4 win=5840
rtt=57.7 ms
len=46 ip=xx.xx.xx.xx ttl=54 DF id=0 sport=110 flags=SA seq=5 win=5840
rtt=36.1 ms
len=46 ip=xx.xx.xx.xx ttl=54 DF id=0 sport=110 flags=SA seq=6 win=5840
rtt=43.4 ms
len=46 ip=xx.xx.xx.xx ttl=54 DF id=0 sport=110 flags=SA seq=7 win=5840
rtt=55.9 ms
len=46 ip=xx.xx.xx.xx ttl=54 DF id=0 sport=110 flags=SA seq=8 win=5840
rtt=31.8 ms
len=46 ip=xx.xx.xx.xx ttl=54 DF id=0 sport=110 flags=SA seq=9 win=5840
rtt=42.6 ms

--------------------------------------
1- Test one: Standard Nmap
nmap -sS -F -n -v xx.xx.xx.xx -oN test1-normal -d

Just open ports:

9/tcp open discard syn-ack
13/tcp open daytime syn-ack
22/tcp open ssh syn-ack
23/tcp open telnet syn-ack
37/tcp open time syn-ack
53/tcp open domain syn-ack
79/tcp open finger syn-ack
110/tcp open pop3 syn-ack
111/tcp open rpcbind syn-ack
113/tcp open auth syn-ack
515/tcp open printer syn-ack
1024/tcp open kdm syn-ack
8080/tcp open http-proxy syn-ack

Overall sending rates: 158.87 packets / s, 6990.42 bytes / s.
1 IP address (1 host up) scanned in 8.545 seconds

Note: No open ports missed

----------------------------------------------
2 - Test two: nmap with --max-retries 0
nmap -sS -F -n -v xx.xx.xx.xx -oN test1-normal-max-retries-0 -d --max-retries
0

Just open ports:

Overall sending rates: 324.29 packets / s, 14268.56 bytes / s.
1 IP address (1 host up) scanned in 4.081 seconds

Note: Two open ports missed

----------------------------------------------
3- Test three: With --min-rate 500 alone
nmap -sS -F -n -v xx.xx.xx.xx -oN test3-min-rate-500 -d --min-rate 500

Just open ports:

Overall sending rates: 478.74 packets / s, 21064.44 bytes / s.
1 IP address (1 host up) scanned in 5.117 seconds

Note: No ports missed

-----------------------------------------------
4- With --min-rate 500 and --max-retries 0
nmap -sS -F -n -v xx.xx.xx.xx -oN test3-min-rate-500 -d --min-rate
500 --max-retries 0

13/tcp open daytime syn-ack
22/tcp open ssh syn-ack
23/tcp open telnet syn-ack
37/tcp open time syn-ack
53/tcp open domain syn-ack
79/tcp open finger syn-ack
110/tcp open pop3 syn-ack
111/tcp open rpcbind syn-ack
113/tcp open auth syn-ack
8080/tcp open http-proxy syn-ack

Overall sending rates: 497.00 packets / s, 21868.05 bytes / s.
1 IP address (1 host up) scanned in 2.705 seconds

Note: 3 open ports missed. Sometimes six ports missed, sometimes five.

-----------------------------------------------
4- With --min-rate 1000
nmap -sS -F -n -v xx.xx.xx.xx -oN test3-min-rate-1000 -d --min-rate 1000

Overall sending rates: 866.24 packets / s, 38114.44 bytes / s.
Nmap done: 1 IP address (1 host up) scanned in 4.909 seconds

Note: No ports missed

-----------------------------------------------
5- With --min-rate 1000 with --max-retries 0
nmap -sS -F -n -v xx.xx.xx.xx -oN
test3-min-rate-1000--max-retries0 -d --min-rate 1000 --max-retries 0

13/tcp open daytime syn-ack
22/tcp open ssh syn-ack
23/tcp open telnet syn-ack
53/tcp open domain syn-ack
79/tcp open finger syn-ack
113/tcp open auth syn-ack

Overall sending rates: 841.68 packets / s, 37033.96 bytes / s.
1 IP address (1 host up) scanned in 1.654 seconds

Note: 7 ports missed. Sometimes 6

-----------------------------------------------
6- With --min-rate 10000
nmap -sS -F -n -v xx.xx.xx.xx -oN test3-min-rate-10000 -d --min-rate 10000

22/tcp open ssh syn-ack
23/tcp open telnet syn-ack
53/tcp open domain syn-ack
79/tcp open finger syn-ack
110/tcp open pop3 syn-ack
111/tcp open rpcbind syn-ack
113/tcp open auth syn-ack
515/tcp open printer syn-ack
8080/tcp open http-proxy syn-ack

Overall sending rates: 2162.30 packets / s, 95141.17 bytes / s.
1 IP address (1 host up) scanned in 4.068 seconds

Note: 4 ports missed! first time I've got missed ports without --max-retries
0. Sometimes just two ports missed

-----------------------------------------------
7- With --min-rate 100000
nmap -sS -F -n -v xx.xx.xx.xx -oN test3-min-rate-100000 -d --min-rate 100000

9/tcp open discard syn-ack
13/tcp open daytime syn-ack
22/tcp open ssh syn-ack
23/tcp open telnet syn-ack
37/tcp open time syn-ack
53/tcp open domain syn-ack
79/tcp open finger syn-ack
111/tcp open rpcbind syn-ack
113/tcp open auth syn-ack
515/tcp open printer syn-ack
8080/tcp open http-proxy syn-ack

Overall sending rates: 2126.00 packets / s, 93543.92 bytes / s.
1 IP address (1 host up) scanned in 4.085 seconds

Note: 2 ports missed!

Note that despite using --max-retries 100000, I can't send faster than 2100 or
so packets/s. This is because of my slow internet connection I guess!. My
real download speed is something like 600kbps and my real upload speed is
something like 150kbps

Cheers

sebas

El Monday 31 March 2008 14:05:59 David Fifield escribi�:
> On Mon, Mar 31, 2008 at 04:12:44AM +0000, Brandon Enright wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On Sun, 30 Mar 2008 20:44:15 -0600 or thereabouts David Fifield
> > <david_at_bamsoftware.com> wrote:
> > ...snip...
> >
> > > That is true, but if the Linux hosts finish faster (for whatever
> > > reason) and then the Windows hosts have to finish scanning at a
> > > slower rate, that will bring the overall average down. If you run
> > > with -d and use the run-time interaction feature by hitting Enter
> > > during a scan, you can see a live estimate of the current scanning
> > > rate. You might see it really fast at the beginning and slow down at
> > > the end.
> > >
> > > > I'm happy to try any patch, Nmap command, or network size (up to
> > > > when Nmap runs out of memory at around /17) so feel free to ask or
> > > > patch away.
> > >
> > > Would you run the tests again with "--max-retries 0"? That will
> > > eliminate the doAnyOutstandingRetransmits slowdown.
> >
> > Here we go again, this time with --max-retries 0 like so:
> >
> > nmap --min-rate 100000 --min-hostgroup 256 --max-retries 0 -P0 -n -d -v
> > -p- <targets>
> >
> > These are all local machines. Multiple scans against other machines
> > were consistent with these so I've only included these three scans:
> >
> > Linux Box:
> > Overall sending rates: 89643.44 packets / s, 3944311.23 bytes / s.
> > Final times for host: srtt: 165 rttvar: 2 to: 100000
> >
> > Windows Box:
> > Overall sending rates: 18712.29 packets / s, 823340.93 bytes / s.
> > Overall sending rates: 18712.29 packets / s, 823340.93 bytes / s.
> >
> > Nothing:
> > Overall sending rates: 14538.09 packets / s, 639675.90 bytes / s.
> > Final times for host: srtt: -1 rttvar: -1 to: 1000000
> >
> > Local /25:
> > Overall sending rates: 15573.42 packets / s, 685230.30 bytes / s.
> >
> > doAnyOutstandingRetransmits was certainly a factor. It seems something
> > else though is taking up most of the time.
>
> There are actually a ton of places where the entire list of outstanding
> probes is traversed. This is especially true because there are a lot of
> places where list::size is called (grep scan_engine.cc for "listsz ="),
> and in libstdc++ list::size is O(n):
>
> http://gcc.gnu.org/onlinedocs/libstdc++/manual/bk01pt07ch16.html#sequences.
>list.size
>
> Maybe the Linux boxes are sending resets for closed ports, which drops
> the probes out of probes_outstanding and keeps the list small. If the
> Windows boxes drop the request, the probes have to time out and they
> stay in the list a long time, making it longer. That would also make
> sense when scanning addresses that aren't connected.
>
> Can you send the output of
>
> nmap --min-rate 100000 --min-hostgroup 256 --max-retries 0 -P0 -n -d3 -p- |
> grep -E "^(\*\*TIMING| )"
>
> for scans against a fast Linux host, a slow Windows host, and the
> unconnected netblock? (Of course you can just run the grep against a -d4
> log.) You could send the raw log file but it's likely to be big.
>
> For me, running such a command against a reset-sending Linux host gives
>
> **TIMING STATS** (1.0050s): IP, probes
> active/freshportsleft/retry_stack/outstan ding/retranwait/onbench,
> cwnd/ccthresh/delay, timeout/srtt/rttvar/ Groupstats (1/1 incomplete):
> 50/*/*/*/*/* 99.05/75/* 100000/70/4 192.168.0.X: 50/63585/0/50/0/0
> 99.05/75/0 100000/70/4
> **TIMING STATS** (1.0180s): IP, probes
> active/freshportsleft/retry_stack/outstan ding/retranwait/onbench,
> cwnd/ccthresh/delay, timeout/srtt/rttvar/ Groupstats (1/1 incomplete):
> 50/*/*/*/*/* 99.56/75/* 100000/68/0 192.168.0.X: 50/63535/0/50/0/0
> 99.56/75/0 100000/68/0
> **TIMING STATS** (1.0340s): IP, probes
> active/freshportsleft/retry_stack/outstan ding/retranwait/onbench,
> cwnd/ccthresh/delay, timeout/srtt/rttvar/ Groupstats (1/1 incomplete):
> 50/*/*/*/*/* 100.07/75/* 100000/69/1 192.168.0.X: 50/63485/0/50/0/0
> 100.07/75/0 100000/69/1
>
> while running it against a packet-dropping Windows host gives
>
> **TIMING STATS** (1.0040s): IP, probes
> active/freshportsleft/retry_stack/outstan ding/retranwait/onbench,
> cwnd/ccthresh/delay, timeout/srtt/rttvar/ Groupstats (1/1 incomplete):
> 636/*/*/*/*/* 76.01/75/* 100000/372/567 192.168.0.Y: 636/62535/0/687/51/0
> 76.01/75/0 100000/231/314
> **TIMING STATS** (1.0120s): IP, probes
> active/freshportsleft/retry_stack/outstan ding/retranwait/onbench,
> cwnd/ccthresh/delay, timeout/srtt/rttvar/ Groupstats (1/1 incomplete):
> 650/*/*/*/*/* 76.01/75/* 100000/372/567 192.168.0.Y: 650/62485/0/686/36/0
> 76.01/75/0 100000/231/314
> **TIMING STATS** (1.0220s): IP, probes
> active/freshportsleft/retry_stack/outstan ding/retranwait/onbench,
> cwnd/ccthresh/delay, timeout/srtt/rttvar/ Groupstats (1/1 incomplete):
> 650/*/*/*/*/* 76.01/75/* 100000/372/567 192.168.0.Y: 650/62435/0/700/50/0
> 76.01/75/0 100000/231/314
>
> where the fourth number in the "*/*/*/*/*/*" part of the per-host line
> is the number of outstanding probes. You can see it trends much higher
> against the Windows host. Be aware that -d4 will probably slow down the
> scan too.
>
> I think we can reduce the negative effect of having a lot of outstanding
> probes through code changes.
>
> Anyone following this conversation, please note that these issues only
> matter at really high packet rates. If you use reasonable arguments to
> --min-rate (or don't use that option at all) it won't affect you.
>
> David Fifield
>
> _______________________________________________
> Sent through the nmap-dev mailing list
> http://cgi.insecure.org/mailman/listinfo/nmap-dev
> Archived at http://SecLists.Org

-- 
Ing. Sebasti�n Garc�a
http://minsky.surfnet.nl:11371/pks/lookup?op=get&search=0x3E42ED27F864EDE6
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org

Received on Apr 03 2008