Nmap Development mailing list archives
Re: [RFC] --exclude-ports option for Nmap
From: Jay Bosamiya <jaybosamiya () gmail com>
Date: Thu, 12 Jun 2014 00:33:11 +0530
List, With respect to the warnings for the --exclude-ports option: Daniel Miller wrote:
[...] I don't think this is necessary, because it will involve retooling the portspec parsing code. It can be added later; perhaps a TODO comment in the code would be sufficient. On the other hand, I lean against warnings of any kind involving port exclusions because the user should be able to figure it out
Fyodor wrote:
[...] I'm not sure I'd even show a warning, as excluding ports which would otherwise be scanned is a main purpose of this option. I also wouldn't give a warning if people try to exclude a port which wasn't going to be scanned, as they might just be doing that for safety/paranoia/policy reasons.
I guess I completely scrap the idea of warnings then. We could just make the documentation very clear, and this should be enough. There is some confusion with respect to point number 2 in my original mail. Jay Bosamiya wrote:
2. How does it interact with --top-ports? More specifically, how many ports does "--top-ports 2 --exclude-ports 80" scan? 1 or 2? I think that it should scan 2 ports excluding port 80 (i.e. it should scan ports 23 and 443). This seems to be the logical way that anyone would read the command too.
Fyodor wrote:
Yes, that sounds like the way to go. As you go through the top port lists, you'd call the function to check if the port is excluded first.
Daniel Miller wrote:
I tend to think the opposite: --top-ports 2 --exclude-ports 80 should only scan port 23, not 23 and 443, since --top-ports 2 would not normally scan 443. But I am willing to be persuaded by use cases for the other way around. You will have to be careful of edge cases: --top-ports 65535 --exclude-ports 1-10 will not scan 65535 ports.
Initially, the biggest reason I thought that we should scan exactly N ports for "--top-ports N --exclude-ports A,B,C" in all cases (except for edge cases) is that it reads more naturally (at least to me). However, as I thought about it, I came up with a use case [1] that clearly illustrates the reason we should keep it with exactly N ports. I also decided that I could ask some folks as to what the command really reads as [2]. With respect to the long option name: Daniel Miller wrote:
[...] perhaps we should consider what long option name gets used. The functions that handle this kind of parsing and choosing are also used for the IP Protocol scan (-sO), so it could fairly be called --exclude-protos. We don't have this problem with -p simply because it is a 1-letter option. Suggestions, anyone?
I'm not so sure, but how about --exclude-p ? This basically comes from the reasoning that we use --exclude for hosts since hosts have no option name before them, so we use --exclude-p for the things that have -p before them. This could be quite debatable actually, but it is a triviality in relation to the rest of the code. I will code in the option as --exclude-ports for now (only because of the subject of the thread), but we could decide the exact name anytime later before we commit it. Cheers, Jay References/Links: [1] Hypothetical Scenario: If I am a network admin who scans my network daily (thoroughly) and hourly (just for top ports) to see if any services/ports have opened up inadvertently/maliciously. I would have a limited time span for which I can run the hourly scan and my top-ports number is limited by this. I would have written a script that runs "--top-ports N" and would look for any new additions that pop up. Now that an exclude-ports option is there in Nmap, I'd just add all the ports that I know to be open (since I know which services I've installed) to the exclude-ports list and make the script run with a "--exclude-ports A,B,C" tagged along (to be able to scan more ports that should not be open in the same amount of time). Now, due to some new software that I have installed, there is a new port opened. Then I'd add a ",D" to the list and be done with it. This would basically scan the same number of ports but would actually be a more informative scan. On the other hand, if I had to make it "--top-ports N+4 --exclude-ports A,B,C,D" then I had to either waste time checking that D is actually in the top ports list (and then change to N+4) or I would forget about changing it to N+4 which basically means that the time taken by the scan is lesser (and time that could've been used to check for one more rogue service goes to waste). [2] http://english.stackexchange.com/questions/177252/how-to-interpret-top-n-except-a-b-c _______________________________________________ Sent through the dev mailing list http://nmap.org/mailman/listinfo/dev Archived at http://seclists.org/nmap-dev/
Current thread:
- [RFC] --exclude-ports option for Nmap Jay Bosamiya (Jun 03)
- Re: [RFC] --exclude-ports option for Nmap Jacek Wielemborek (Jun 05)
- Re: [RFC] --exclude-ports option for Nmap John (Jun 06)
- Re: [RFC] --exclude-ports option for Nmap Jay Bosamiya (Jun 06)
- Re: [RFC] --exclude-ports option for Nmap John (Jun 06)
- Re: [RFC] --exclude-ports option for Nmap Daniel Miller (Jun 10)
- Re: [RFC] --exclude-ports option for Nmap Fyodor (Jun 10)
- Re: [RFC] --exclude-ports option for Nmap Jay Bosamiya (Jun 11)
- Re: [RFC] --exclude-ports option for Nmap Daniel Miller (Jun 11)
- Re: [RFC] --exclude-ports option for Nmap Jay Bosamiya (Jun 11)
- Re: [RFC] --exclude-ports option for Nmap Jacek Wielemborek (Jun 05)