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:
- [Branch] --ignore-after Jay Bosamiya (Jul 30)
- Re: [Branch] --ignore-after Jacek Wielemborek (Jul 30)
- Re: [Branch] --ignore-after Jay Bosamiya (Jul 30)
- Re: [Branch] --ignore-after Fyodor (Aug 13)
- Re: [Branch] --ignore-after Fyodor (Aug 16)
- Re: [Branch] --ignore-after Jay Bosamiya (Aug 18)
- Re: [Branch] --ignore-after Daniel Miller (Sep 17)
- Re: [Branch] --ignore-after Jay Bosamiya (Sep 18)
- Re: [Branch] --ignore-after Daniel Miller (Sep 18)
- Re: [Branch] --ignore-after Fyodor (Aug 16)
- Re: [Branch] --ignore-after Jacek Wielemborek (Jul 30)