Nmap Development mailing list archives

Re: [Branch] --ignore-after


From: Jay Bosamiya <jaybosamiya () gmail com>
Date: Thu, 18 Sep 2014 20:00:21 +0530

Hi Dan, List,

I realize why you feel that the idea of percentage calculation done over
the *number of ports scanned so far* as opposed to the *total number of
ports intended to be scanned* might be better, however, I propose the
following example to show why the idea of percentages becomes redundant
then.

Assuming the case of calculation done over *number of ports scanned so
far*; let us assume the case of ports being scanned in the order
1,2,3,4,5,6... (for simplicity) and let's assume 90%,90. Then, if any 90
in the first 100 are open, then we bail and all is good. However, what
if the first 100 ports are closed and all the rest are open?
We'd end up bailing on the 900th open port.
Now, let's take the case of random port ordering (as Nmap does by
default). In this case, we would end up bailing soon on hosts that have
a large number of common ports open (since Nmap "cheats" by placing
common ports first) and would bail only after a long time on hosts that
have common ports closed but almost all uncommon ports open. Also, even
if we scan the same host, due to randomization, the bailing out would be
very "random" since it'd have different number of ports seen open before
bailing. This basically gets rid of reproducibility in a scan.
For example: take ports 1-91 open and scan order 1,2,3,4,5,...,1000 then
Nmap would bail. However, if scan order just got reversed, then Nmap
would not bail. This just doesn't seem right.

On the other hand, if we take calculation done over *total number of
ports intended to be scanned* set with a very very low percentage value
(I'm actually leaning towards 1%,60 or even lower for -T5 now) then we
have an extremely reproducible scan each time (independent of the order
of ports scanned). Also, we bail at the moment we see 60 open ports for
any scan (upto a total ports intended = 6000) and linearly interpolate
to 655 for a 65536 port scan. This doesn't seem to be a lot of wasted
effort since no one (IMHO) calls for a full scan unless there is mainly
only uncommon ports open. Also, if a large number of uncommon ports are
open, only then can we say that something like portspoof might be
running; however, we would want to say this with a fair amount of
certainty that we would be able to replicate the result.

I hope that the examples make it clear why I switched back to the
calculation done over *total number of ports intended to be scanned*.
However, if any of you still feel that *number of ports scanned so far*
is better, I'd love to have a discussion on the same.

Cheers,
Jay

PS: Currently I feel the defaults should be -T4 = 2%,80 and -T5 = 1%,60

-T4:

-T5:

On Wednesday 17 September 2014 08:35 PM, Daniel Miller wrote:

I'm just now realizing that an idea I had early on got dropped. I
think it might solve a bit of this problem, so I'll elaborate again:

First, consider the problem of the -p- scan (or any other large scan).
With a default -T5 of 10%,60 (numbers don't matter at this point, but
this is a likely starting place), your algorithm would need to scan
6554 open ports before it decided to bail on the scan. That's a lot of
wasted effort, and that's why you are suggesting lower and lower
percentage values (we started with 80% and 90%, if you remember).

Instead, I propose that the percentage calculation be done over the
*number of ports scanned so far* as opposed to the *total number of
ports intended to be scanned*. This would probably require an extra
variable to be kept around for each host, but that's negligible. This
would allow a default like 90%,90 to scan at minimum 90 ports
regardless of scan size. What happens on a host that reports every
port as open is this: as soon as the 90th port is found open, the
percentage calculation is done. 90/90 ports are open, which is 100% >
90%, so the host is ignored. The purpose of setting a percentage less
than 100% is to allow for some dropped packets at the higher timing
levels.

I believe this method would allow for earlier ignoring while still
keeping with the spirit of detecting portspoof hosts. It also
simplifies the discussion of defaults; no matter how many ports are
scanned, the ignore decision gets made at the same point in the scan
(immediately after the n+1 port is scanned).

We would need to decide what it means when a user does --ignore-after
50 (I think this would be the same as 50,0%; that is, 50 open ports
regardless of how many closed/filtered ports) or --ignore-after 70%
(probably the same as 70%,.7*total_ports; this is equivalent to -F
--ignore-after 70%,70 or -p- --ignore-after 70%,45875 for the default
scan).

Thoughts?

Dan

_______________________________________________
Sent through the dev mailing list
http://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/


Current thread: