Re: Nmap's default ports

[Fyodor <fyodor () insecure org>]

On Sun, Jul 30, 2006 at 04:14:37AM -0700, doug () hcsw org wrote:
> work on is to discover the popularity of different internet
> services and to

Hi Doug.  I definitely think this sort of port popularity survey would
be useful in making Nmap scans more efficient.

> add an Nmap option, say, --top-ports which will
> cause Nmap to scan the N most common ports.

Souds useful.  Of course the "top ports" you are likely to see depends
on target selection, filtering policies, etc.  But if we gather solid
empirical data covering a diverse set of scans, we should come up with
reasonable results.

> services should be used as guidelines for Nmap's current default
> scanning behaviour and the -F scanning behaviour. For example,
> Nmap could by default scan --top-ports 1000 and -F could scan
> --top-ports 200 (could also differ between TCP and UDP).

I tend to lean toward having some popularity threshold (e.g. ports
that we have seen open at least once, or at least 10 times, or
whatever) rather than a fixed number of ports.

> o -F (fast scan) really isn't that much faster than a normal default
>   scan (with 4.20, TCP: 1239 vs 1680, UDP 1016 vs 1487). The default scan
>   perhaps (?) scans too many ports as well. There are probably services listed
>   in the nmap-services file that are so uncommon that they definitley
>   shouldn't be scanned for by default.

This is definitely a big problem.

> o By some registration fluke, both TCP and UDP ports are registered for
>   many protocols even if the service only ever uses one protocol.
>   HTTP and many others that exclusively use TCP have listed UDP ports and
>   protocols like NTP that only use UDP have listed TCP ports.
>   This probably means that, often, many ports are being needlessly scanned.

Yep.

> o How do we know which services are the most common? Are services consistent
>   across countries? Regions? ISPs? Organisations? Will the currently most-popular
>   ports be the most popular forevermore? Probably not. Any decision made on the
>   "commonness" of different services will have to be arbitrary.

I don't know that I'd call it arbitrary.  We can develop a standard
method of collecting this empirical data.  We may need to enhance the
port frequencies with additional data every year to reflect changes.

> o People are used to Nmap's current behaviour. Changing this will probably
>   confuse and irritate many users.

I think most users who get confused and irritated by changes stopped
upgrading Nmap years ago and still use version 2.53 :).  I still get
bug reports from them.

> Worse yet, people unaware of the change
> might unknowingly miss certain important services.

If we do it right, the important services will still be scanned by
default.  And we may find some new services which weren't in the old
nmap-services.

> An addition to the nmap-services file that includes frequency information.
> Perhaps like so:
>
> ...
> domain            53/tcp    602     # Domain Name Server
> domain            53/udp    21933   # Domain Name Server
> http              80/tcp    87621   # World Wide Web HTTP
> http              80/tcp    0       # World Wide Web HTTP

Looks good (though you meant 80/udp on that last linke, I think).

> We leave nmap-services alone (or possibly eliminate it) in favour of another
> file, nmap-frequencies. This file could be an ordered list of port frequencies.
> Perhaps like so:
>
> # TCP:
> http              80/tcp     # World Wide Web HTTP
> ssh               22/tcp     # Secure Shell Login
> ftp               21/tcp     # File Transfer [Control]

I think it is important to have the actual frequency numbers in there
so that we can add more empirical scan data at any time.  We can't do
that if we just have an ordered list.  Also, I think the frequency
file should avoid redundant information (already in nmap-services)
like the service name and comments.  It just needs to be a list of
port+protocol+freqency.

I'm leaning toward just augmenting nmap-services as in your first
example.

Cheers,
-F


_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev