Re: [RFC] --exclude-ports option for Nmap

[Daniel Miller <bonsaiviking () gmail com>]

Jay,

My thoughts are inline below:


On Fri, Jun 6, 2014 at 5:24 AM, Jay Bosamiya <jaybosamiya () gmail com> wrote:

> I think that this point may require some clear explanation.
>
> > 1. How does it interact with -p? More specifically, what does "-p 80
> > --exclude-ports 80" do (since user specifically included it as well as
> > excluded it)?
> >       I think that we should follow a "exclude has higher priority than
> > include" ideology and NOT scan 80 in this case.

I agree--exclude should take priority over include.


> (a) "-p 80 --exclude-ports 80" causes an error and Nmap quits (because
> no ports to scan)

Yes.


> (b) "-p 80,81 --exclude-ports 80" causes a warning and only port 81 is
> scanned (because 80 is specified individually, not in a range)

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 (except for 10


> (c) "-p 79-81 --exclude-ports 80" causes NO warning and only ports 79
> and 81 are scanned (because 80 is in a range)

This now becomes the same as (b)


> (d) "-p 80 --exclude-ports 1-100" causes an error and Nmap quits
> (because no ports to scan)

This is probably the exact same code path as (a)


> (e) "-p 80,1000-1200 --exclude-ports 1-100" causes a warning and only
> ports 1000-1200 are scanned (because 80 is specified individually and
> then excluded)

Same as (b)


> (f) "-p 80-120 --exclude-ports 1-100" causes NO warning and only ports
> 101-120 are scanned

Yes.

A couple more:

(g) "-p 20-30 --exclude-ports 80-90" (disjoint) should probably cause no
warning, since the ports will not be scanned, just as requested.

(h) "-sSU -p 80 --exclude-ports U:80" should cause an error, because there
are no UDP ports available to scan, but the user requested a UDP scan.
Obviously this means that --exclude-ports should take the same format as -p


> From your original message:

> 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.
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.


> 3. How should the arguments for it be taken? Similar to -p, or only
> individual ports should be taken?
>         I think that we should allow for ranges of ports to also be
> specified, very similar to the way we take input for -p (kind of like
> "--exclude-ports 80-90,666"). This would make it very easy for users to
> use this option.

Yes, additionally it should take T: and U: and the other modifiers. This
probably means just reusing the existing parser (getpts in nmap.cc).


> 4. Should there be a one-letter flag for it? If so, what should it be?
>         I don't think that it needs a one-letter flag but this depends on
> how
> much it will be used.

I would not advocate for a 1-letter flag, but 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?

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