Re: max-scan-delay not honored?

[Filippo Solinas <allanon-ph () users sf net>]

On Fri, 10 Mar 2006 10:44:29 -0800, Fyodor wrote:

| > # nmap -P0 -sS -vv --packet-trace -p 0-4,80,81-85 -r
| > # --max-parallelism 1 --max-scan-delay 100 --max-retries 0 X.Y.Z.100
| > 
| 
| Here you have told Nmap to send only one probe at a time
| (--max-scan-delay 100).  So it needs to wait for each to finish before
| it starts the next one.  Otherwise it would be violating your
| parallelism restriction (the way Nmap interprets --max-parallelism).
| So if you want it to scan faster, you need to decrease the max
| round-trip-time (so Nmap doesn't wait as long to finish each probe) or
| increase the number of probes allowed in parallel.

I know, but serializing sometimes is necessary to scan heavily
rate-limited networks while preserving accuracy. In this case,
scanning 5 (or more) ports in parallel leads to false negative;
less than 5 leads to an excessive slow scan. So I would expect
and prefer more fine grained control over serial (and parallel)
scan.

Moreover, with "--max-parallelism 2", --max-scan-delay 100 seems
to be not honored as well:

SENT (1.0720s) TCP 10.0.0.10:57477 > X.Y.Z.100:2 S ttl=41 id=50478 iplen=44 seq=2366825438 win=2048
SENT (1.0720s) TCP 10.0.0.10:57477 > X.Y.Z.100:3 S ttl=50 id=61342 iplen=44 seq=2366825438 win=3072
SENT (2.0720s) TCP 10.0.0.10:57477 > X.Y.Z.100:4 S ttl=48 id=14443 iplen=44 seq=2366825438 win=1024
SENT (2.0820s) TCP 10.0.0.10:57477 > X.Y.Z.100:80 S ttl=40 id=63133 iplen=44 seq=2366825438 win=1024

But I suppose the way Nmap interprets the send-delay with
--max-parallelism is not the way I do :)

And also with "--max-rtt-timeout 500", --max-scan-delay 100 seems
to be not honored as well:

SENT (1.0820s) TCP 10.0.0.10:63685 > X.Y.Z.100:2 S ttl=48 id=35815 iplen=44 seq=2773645138 win=1024
SENT (1.5930s) TCP 10.0.0.10:63685 > X.Y.Z.100:3 S ttl=49 id=62855 iplen=44 seq=2773645138 win=2048
SENT (2.1020s) TCP 10.0.0.10:63685 > X.Y.Z.100:4 S ttl=55 id=22461 iplen=44 seq=2773645138 win=4096
SENT (2.6130s) TCP 10.0.0.10:63685 > X.Y.Z.100:80 S ttl=57 id=7575 iplen=44 seq=2773645138 win=2048

And we can't set max-rtt-timeout to 100 when rtt is about 150 ms.

So it's a question of compromise.. but a more fine grained control
over both serial and parallel scan would be the best solution, IMHO.

Cheers,

        ph.



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