Re: massping migration and you

[Brandon Enright <bmenrigh () ucsd edu>]

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

On Thu, 30 Aug 2007 10:43:15 -0600 plus or minus some time David Fifield
<david () bamsoftware com> wrote:
> > Nmap done: 186336 IP addresses (11554 hosts up) scanned in 9040.909
> > seconds
> >
> > real    150m40.914s
> > user    21m38.227s
> > sys     2m26.036s
>
> Wow, that's alarming. Your scan is one I would expect the migrated host
> discovery to do well at. Although I've never tested it on such a large
> group of hosts.

Actually, this is exactly the results I was expecting.  I've always been
very impressed by how fast massping() was.

There are many times when I want to know all machines with a particular
port open on our public /16s and private /12.  I always scan
with -T5 as a base template and generally add --max-retries 1 and
- --min-hostgroup 2048.

I used to do these scans with -P0 because in my own twisted logic "it's
much faster to only send 1 or 2 SYNs than to have to ping/send other probes
first before sending the SYNs.  By the time you've determined the host is
up, you could have already determined if the port is up."

Of course, when I actually tested it, it was between 5x and 10x faster to
use -P A<short list of ports> before sending the single port probes.

I always attributed this to the speed over reliability of massping() versus
the reliability over speed for ultrascan().  I don't have real test results
handy but I can run some scans to illustrate this if you're interested.

> Can you send me the times from scanning just one of your /16 address
> spaces? Maybe there's something that's making the scan scale
> non-linearly. Also, please try it again with -T4. That increases the
> congestion window recovery speed, which will help if you're getting lots
> of drops.

Okay, I ran:

./nmap -d2 -v -v -n -T4 --min-hostgroup 2048 -P A135,139,445,3389 -sP
- -oA davidT4 --excludefile <a file> a.b.0.0/16

./nmap -d2 -v -v -n -T5 --min-hostgroup 2048 -P A135,139,445,3389 -sP
- -oA davidT5 --excludefile <a file> a.b.0.0/16

The T4 scan resulted in:

Nmap done: 57344 IP addresses (11756 hosts up) scanned in 872.919 seconds
               Raw packets sent: 386696 (15.468MB) | Rcvd: 193498 (9.045MB)

And had 21 drops.


The T5 scan resulted in:

Nmap done: 57344 IP addresses (11750 hosts up) scanned in 782.803 seconds
               Raw packets sent: 386958 (15.479MB) | Rcvd: 159281 (7.454MB)

And had 106 drops.


> ultra_scan is much more cautious in the face of drops than massping was.
> Are you getting many? You can find out by running with -d2 and grepping
> the log file for "DROPPED".

I know hitting drops and timeouts unnecessarily can severely hurt
performance.  It seems to me that for 57k scanned hosts, even 106 drops is
a drop in the bucket for total probes sent.

> Thanks for testing!
>
> David

I've always been under the impression that timing options like -T# didn't
affect "ping scans" at all.  Did it used to or does it only now affect them
because of the migration to ultrascan()?

I'm going to re-run my 3 /16 net scans with -T4 and -T5 to see if that puts
us back into the 25 minute range.

Also, I've re-run the scan that crashed yesterday many times and it hasn't
crashed again.  I'll keep trying.

Brandon

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

iD8DBQFG1wWSqaGPzAsl94IRAkzpAJ9QgP8rI3SLs87lH9d12CwfcXpCQwCeLe1c
PT4cgrUAbCsNINmgR4uSWOg=
=23kE
-----END PGP SIGNATURE-----

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