Nmap: Make --top-ports and -p a union instead of an intersection

[dmiller-nmap]

Currently, --top-ports selects the most popular ports from the nmap-services file or from the list of ports given on the command line. If any of the ports given on the command line are not listed in the nmap-services file, they will not be scanned. This seems like a very unusual interaction and not one that users are probably relying on. The only useful combination of these was probably my hacky Perl script to approximate the --exclude-ports option before that was added two years ago. Of course, because I missed the part about not scanning ports that are not in the file, it doesn't even work as advertised.

I propose that --top-ports and -p should be allowed to _add_ to each other, so that all the ports specified in -p will be scanned in addition to all of the ports that would usually be scanned with the --top-ports option chosen.

Some examples:

• --top-ports 10 -p 12354
  
  
  
  • currently scans: nothing, scan phase skipped.
  
  
  • proposed: 21-23,25,80,110,139,443,445,3389,12354 (11 ports)
  
  
• --top-ports 10 -p 21,22,23
  
  
  
  • currently scans: 21-23
  
  
  • proposed: 21-23,25,80,110,139,443,445,3389 (10 ports)
  
  

An alternative implementation would be to scan the _n_ --top-ports left after the -p ports have been chosen. This would make the number of scanned ports more predictable, but I don't favor it. The first example would be unchanged, and the second would scan 13 ports: 21-23,25,53,80,110,135,139,143,443,445,3389.

[dmiller-nmap]

This should be discussed thoroughly by devs and users, both here and on the nmap-dev mailing list, before implementing.

[fyodor]

Your proposal sounds like a good one to me. The current behavior seems a bit bizarre and I suspect that it wasn't intentionally designed this way. We probably just didn't think about or test the interaction between these two options sufficiently.

[p-l-]

I agree with @dmiller-nmap proposal, --top-ports and -p should both add ports to scan. From a user perspective, this is what I would expect.

[p-l-]

OK I have a use case where it is handy that --top-ports and -p work as an intersection: suppose I want to scan the top 1000 TCP ports (the default) plus the port 161/udp. For now, I do: -p U:161,T:- --top-ports 1000.

How else could I do? Or maybe --top-ports should accept protocol modifiers? --top-ports T:1000,U:10 would be great! With such an option, I could do -p U:161 --top-ports T:1000, which is easy to understand.

[djcater]

I have often wanted to do what your first proposal suggests: scan for common ports and a handful of specific ones. E.g. top 1000 TCP plus a couple of non-standard ports that I know are likely to be open on the target based on a company policy for example (like moving SSH to a particular port). --top-ports=1000 -pXXXXX,YYYYY is what would be intuitive to me, without caring much whether the custom ports are already in that top 1000 or not.

Having protocol modifiers for top ports would also be useful as mentioned above (--top-ports=T:1000,U:20). In both cases, I think a union is more intuitive than an intersection.

[ghost]

Hello guys, I opened a PR aiming to fix this issue. Note that the protocol modifiers are now working (only for -p not for --top-ports), and I am going to commit the last changes right now to the mentioned PR. You can find some tests here on the result aiming to show how those two options are mixing up.
Waiting for you comments!