Re: massping migration and you

[Brandon Enright <bmenrigh () ucsd edu>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Okay, a correction, comments, and test results below.  This should be a lot
more to your liking.


On Thu, 30 Aug 2007 23:34:45 -0600
David Fifield <david () bamsoftware com> wrote:

> On Fri, Aug 31, 2007 at 04:57:16AM +0000, Brandon Enright wrote:
> > On Thu, 30 Aug 2007 21:08:36 -0600 plus or minus some time David Fifield
> > <david () bamsoftware com> wrote:
> > > Which is all the more puzzling because I thought your --min-hostgroup
> > > option might be the source of the speed discrepancy. Just for the heck
> > > of it, can you try a scan using --min-parallelism 2048 instead?
> >
> > This made an impressive difference:
> >
> > Nmap finished: 186368 IP addresses (13174 hosts up) scanned in 1901.990
> > seconds Raw packets sent: 1630152 (65.206MB) | Rcvd: 41809 (2.022MB)
> >
> > real    31m42.005s
> > user    0m6.297s
> > sys     0m25.964s
>
> Well, that's good, as long as hosts weren't missed. A parallelism of
> 2048 is awfully high, though. Does anyone else have ideas why the speeds
> aren't matching up? Is anyone experiencing the same thing?

Okay well it turns out I screwed up the test above.  Instead of doing
'./nmap' I just did 'nmap' which means it was a test of the old massping()
code.  Good news though, I've repeated the test with a bunch of different
values for --min-parallelism with *excellent* results.

I will include more comprehensive results below.  For the test above with
- --min-parallelism using 2048, this was the result:

Nmap done: 186368 IP addresses (15804 hosts up) scanned in 258.023 seconds
               Raw packets sent: 1398404 (55.937MB) | Rcvd: 51659 (2.426MB)

real    4m18.043s
user    1m45.858s
sys     0m35.164s


With the default parallelism used with -T5 the new ultrascan() code is much
slower and more conservative that the massping() code was.  It can be made
to be MUCH faster though (see above!).  I wasn't able to make massping() go
any faster so ultrascan() really seems to be showing it's power and
flexibility.

> > I've always been under the impression that --min-parallelism was only
> > used on a per-host basis so I thought setting it to anything above the
> > number of ports being probed per host was useless.  Clearly that isn't
> > the case.
>
> With ultra_scan, parallelism is the size of the congestion window, which
> is the total number of active probes allowed for the current host group.
> If one host has sent all its probes, probes from other hosts will be
> sent until the congestion window is filled.

Makes sense.  Thanks for clarifying.

> > Say I normally scan a single host with --min-parallelism 128.  If I scan
> > two hosts at once can I safely set it to 256?  How fairly balanced
> > between hosts is this value?  If I'm scanning a /24 I may want this to
> > scale into the thousands.  At what point is Nmap/ultrascan() going to
> > thrash?  Is there a reasonable point of diminishing return?
>
> Parallelism shouldn't depend on the number of hosts. If you say
> --min-parallelism 128, then the congestion window will not drop lower
> than 128. Those 128 (or more) probes can be directed at one host or a
> thousand, it doesn't matter. I don't think you'll gain from increasing
> the parallelism with the number of hosts. The only thing to watch out
> for is not to make it too high with too few targets, because then each
> target will be fielding a lot of probes at once.

Which is why I've always kept it to 128.  Single host scan test scans I've
done suggest that most machines can't handle much more than 128 and that
increasing it further hurts results without speeding up the scan much.

> > Thanks for your help.  Let me know if there is anything else you'd like
> > me to try.
>
> Can you do one of your scans like
>
>       nmap -n -d2 --packet-trace | grep -B 3 DROPPED
>
> I want to know what the nature of the drops is. There are conditions
> under which a good response can be counted as a drop. We're looking for
> output like
>
>       RCVD (4.2070s) TCP xxx.xxx.xxx.xxx:80 > yyy.yyy.yyy.yyy:38710 SA
> ttl=119 id=10597 iplen=44  seq=3589141442 win=65535 ack=75965513 <mss
> 1460> We got a TCP ping packet back from xxx.xxx.xxx.xxx port 80 (trynum
> 1460> = 1) ultrascan_host_probe_update called for machine xxx.xxx.xxx.xxx
> 1460> state HOST_UP -> HOST_UP (trynum 1 time: 462422)
>       Ultrascan DROPPED probe packet to xxx.xxx.xxx.xxx detected
>
> Where the important part is the HOST_UP -> HOST_UP (as opposed to
> UNKNOWN -> HOST_UP). Those should probably not be counted as drops, and
> if they are, we need to fix the code.
>
> David Fifield

Okay.  For all the following scans, I used -n -d2 --packet-trace (and other
options).  I did get some DROPPED where HOST_UP -> HOST_UP, and
interestingly, the only the medium parallelism scans produced a few.

Here is the template for the scans I ran:

$ time sudo ./nmap -sP -P A135,139,445,3389 -n -vv -d2 -T5 --packet-trace
- --min-parallelism X --max-parallelism Y --excludefile <a file> a.b.0.0/16
c.d.0.0/16 e.f.0.0/16


First the DROPPED HOST_UP -> HOST_UP results:

minX: 64, maxY: 64
2

minX: 128, maxY: 128
6

minX: 256, maxY: 256
8

minX: 512, maxY: 512
6

minX: 768, maxY: 768
1

No other scan produced any HOST_UP -> HOST_UP drops


Now onto the time per scan and host up results.  Don't read too much into
the number of hosts detected as up for each scan.  Not all of these scans
were done in the order presented here.

minX: 64, maxY: 64
Nmap done: 186368 IP addresses (16341 hosts up) scanned in 1946.401 seconds
            Raw packets sent: 1387364 (55.495MB) | Rcvd: 307916 (14.778MB)

minX: 96, maxY: 96
Nmap done: 186368 IP addresses (16193 hosts up) scanned in 1189.917 seconds
            Raw packets sent: 1388503 (55.541MB) | Rcvd: 157883 (7.388MB)

minX: 128, maxY: 128
Nmap done: 186368 IP addresses (16374 hosts up) scanned in 904.527 seconds
            Raw packets sent: 1388383 (55.536MB) | Rcvd: 182033 (8.432MB)

minX: 256, maxY: 256
Nmap done: 186368 IP addresses (16203 hosts up) scanned in 562.084 seconds
            Raw packets sent: 1391273 (55.651MB) | Rcvd: 99340 (4.618MB)

minX: 512, maxY: 512
Nmap done: 186368 IP addresses (15995 hosts up) scanned in 325.174 seconds
            Raw packets sent: 1397238 (55.890MB) | Rcvd: 49749 (2.340MB)

minX: 768, maxY: 768 (first scan)
Nmap done: 186368 IP addresses (15896 hosts up) scanned in 291.363 seconds
            Raw packets sent: 1398309 (55.933MB) | Rcvd: 28323 (1.391MB)

minX: 768, maxY: 768 (second scan)
Nmap done: 186368 IP addresses (15818 hosts up) scanned in 306.481 seconds
            Raw packets sent: 1397579 (55.904MB) | Rcvd: 22422 (1.081MB)

minX: 1024, maxY: 1024
Nmap done: 186368 IP addresses (15836 hosts up) scanned in 280.396 seconds
            Raw packets sent: 1399156 (55.967MB) | Rcvd: 44582 (2.103MB)

minX: 1536, maxY: 1536
Nmap done: 186368 IP addresses (15792 hosts up) scanned in 268.300 seconds
            Raw packets sent: 1397614 (55.905MB) | Rcvd: 39950 (1.891MB)

minX: 2048, maxY: 2048
Nmap done: 186368 IP addresses (15804 hosts up) scanned in 258.023 seconds
            Raw packets sent: 1398404 (55.937MB) | Rcvd: 51659 (2.426MB)

minX: 3072, maxY: 3072
Nmap done: 186368 IP addresses (15739 hosts up) scanned in 253.534 seconds
            Raw packets sent: 1398951 (55.958MB) | Rcvd: 49609 (2.390MB)


To get and idea of the trade-off between speed and accuracy, I started two
additional scans at the same time.  One with a parallelism of 256 and the
other with 2048.  Here are those results:

256:
Nmap done: 186368 IP addresses (15505 hosts up) scanned in 653.847 seconds
            Raw packets sent: 1395793 (55.832MB) | Rcvd: 245905 (11.801MB)

2048:
Nmap done: 186368 IP addresses (15279 hosts up) scanned in 311.655 seconds
            Raw packets sent: 1402726 (56.109MB) | Rcvd: 154293 (7.459MB)



I think the moral of the story is that if you want to reach (or far
surpass) the speed of the old massping() code, --min-parallelism is your
friend.  Of course this comes at an accuracy trade-off.  Also, even with
- -T5, the new ultrascan() code is dismally slow at host-discovery without a
- --min-parallelism of at least 32-64.


Brandon

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFG2JbRqaGPzAsl94IRAjt/AKCQZ30P9mA1UTKf+Nk8UiuqKp/5PQCbBek+
ax6Uhdcgg76edg2NYaFJEmw=
=7Hth
-----END PGP SIGNATURE-----

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