request for new UDP port state [was: Nmap 3.20 Released!]]

[Florin Andrei <florin () sgi com>]

[ This message was redirected from the nmap-hackers to nmap-dev list
  -- Fyodor ]

On Tue, 2003-03-18 at 20:00, Fyodor wrote:
> I am pleased to announce the Nmap version 3.20 is now available!  This
>
> o Added --ttl option, which sets the outgoing IPv4 TTL field in
>   packets sent via all raw scan types (including ping scans and OS
>   detection).

This is awesome. This will allow for manual probing for "stealth"
firewalls that sit in between (increase the TTL step-by-step and see if
something changes _before_ you reach the target).
Automation is good, but it's always better to also have a manual tool
handy. Thank you.

> o Added --packet_trace option, which tells Nmap to display all of the
>   packets it sends and receives in a format similar to tcpdump.

Kewl!

> For a much more comprehensive list of changes, see the CHANGELOG at
> http://www.insecure.org/nmap/data/CHANGELOG .

Ok, now i'll start the nitpicking. :-) I'll actually reiterate an older
request, hopefully now in a fashion that's clearer.

I'm still missing an option to actually tell me whether an UDP port has
sent back a reply, or it's completely unresponsive. I guess i'm having
an issue with it because (quote from "man nmap"):

###########################
If we receive an ICMP port unreachable message, then the port is closed.
Otherwise we assume it is open.
###########################

It's the assumption that bugs me. I believe it leads to at least three
situations where the results provided by nmap are less than optimal:

1. While scanning machines over reliable networks (LANs, good WANs and
VPNs, very good Internet connections) it's difficult to tell apart
filtered UDP ports from open UDP ports.

Example: I'm scanning another system over the LAN:

[root@my-system root]# nmap -sU -p 100-120 some-host
Starting nmap 3.20 ( www.insecure.org/nmap/ ) at 2003-03-19 12:16 PST
Interesting ports on some-host (x.y.z.k):
(The 19 ports scanned but not shown below are in state: closed)
Port       State       Service
111/udp    open        sunrpc
115/udp    open        sftp
Nmap run completed -- 1 IP address (1 host up) scanned in 15.345 seconds

According to the scan, both portmap and sftp are running. But wait! If i
actually go to some-host and look at the local packet filter, i notice
this:

[root@some-host root]# iptables -L INPUT -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
DROP       udp  --  0.0.0.0/0            0.0.0.0/0          udp dpt:115

To be able to distinguish between the two situations (open port and
filtered port), i must fire up tcpdump (or use the cool --packet_trace
option, thanks Fyodor!) and re-do the scan on those ports that are
reported to be open, and see which ones actually reply and which ones
don't.
Needless to say, that's a loss of time that could be avoided when i
_know_for_a_fact_ that the network is reliable and no assumption is
needed.

2. Beginners are mislead into believing their systems have lots of UDP
ports open.
I came across this thing several times, while googling out there for
random stuff. Repeatedly, on many different mailing lists, you see
not-so-knowledgeable people being worried about "i'm having way to many
UDP ports open!". I'll give you just one example, but you can google
yourselves for more if you wish so:

http://lists.insecure.org/lists/pen-test/2001/May/0073.html

3. It's difficult to create reliable automated tools to survey your
network and let you know when something has changed with the list of
open ports.
Suppose you write a script based on nmap to periodically poll all your
systems, remember the "good" state, and page you when a new port was
opened. This happens over your internal (reliable) network, so there's
no packet loss (you can overcome the 0.0001% packet loss by repeating
the scan when something changed, so that you don't get paged because of
a shaky Ethernet cable).
With the present behaviour (no response is assumed to mean "open"), nmap
cannot detect UDP ports that were previously filtered, but now are
wide-open. This has the potential for creating dangerous situations
(false sense of security, and all that). It may not be such a problem on
a very small network, it's surely a big problem on medium and large
networks.

Possible solution:

I believe a good solution to this would be the creation of a new port
state, at least for UDP. Quoting from the man page:

#####################################
The state is either ?open?, ?filtered?, or ?unfiltered?.
#####################################

I believe a new state should be created, named 'no response' or
something like that. The behaviour for UDP scans should be like this
(i'm faking here a possible man page entry):
"No Response means just that: no response has been received by nmap on
that port; in case of UDP that could mean the port is firewalled, but
also could simply mean the response was lost, because UDP is an
unreliable protocol; when in doubt, repeat the scan."
This will remove the assumption that nmap now forces upon the user. Let
the user decide, not the software.

In any case, _always_ assuming that unresponsive UDP ports are "open" is
a long shot even for UDP, even for bad Internet connections. I believe
this behaviour _might_ be desireable only when running over particularly
bad Internet connections (but even then i'd prefer the decision to be
left upon me); in all other cases, it's suboptimal and potentially
causing too much time being spent needlessly (repeat the scan with
tcpdump).

I am not sure of the usefulness of the "no response" state for scans
other than -sU. _Maybe_ it would be useful for SYN scans and the like
(which are essentially in the same situation as UDP scans, since there's
no reliability mechanism involved such as when using -sT), but maybe
not. I have no idea and, honestly, i'm only worried about -sU.
I am only sure that it would _not_ be useful (actually, it would be
redundant) for -sT.

I'm not saying that the default behaviour of -s (or just -sU) should be
changed (although i somewhat believe that's the right thing to do). I'd
be happy at least with having an --expert-mode switch or something like
that to turn on the 'no response' state should i wish so.

Thank you for your attention and sorry for the rather lengthy diatribe.

Keep up the good work!

-- 
Florin Andrei

"People complain about software bugs because it's cool." - Bill Gates


----- End forwarded message -----

---------------------------------------------------------------------
For help using this (nmap-dev) mailing list, send a blank email to 
nmap-dev-help () insecure org . List run by ezmlm-idx (www.ezmlm.org).