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

[R Andersson <listbox () pole-position org>]

Florin Andrei wrote:
> 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"):

This is something I thought a lot about too, without finding the 
canonical solution. I have a couple of experimental patches, some 
submitted to this list, that deals with this in different ways. One 
displays a text before the normal port table, saying what "open", 
"closed" etc. mean in this particular scan (i.e. the text varies with 
the scan type(s) used). Another focuses on ICMP, telling the user 
exactly what ICMP was received, and who sent it (if it was an 
intermediate router). Another small patch adds a "Note: no ICMP 
unreachables seen from the host." if that is the case. That little piece 
of info is of great value when evaluating the results.

> 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

There are other unclear mappings between states and what was really 
received or not, when using the more obscure TCP scan types. In some 
cases you simply can't translate the response (or lack of response) to a 
state unless you know what OS the target runs. This collides with the 
fact that nmap is state-oriented - not only in its output but through 
the entire program. I have no idea why, possibly "historic reasons". I 
played with the idea of making nmap fully "response-oriented" but I'm 
not sure this is in nmap's scope. Anyway, that would make nmap just care 
about responses until it's time to present the results. Only then the 
responses would be translated to states (with or without hints about 
guessing), or optionally the responses could be shown as-is, or 
whatever. Hey, we could even tailor the response-to-state translation to 
what result an OS detection gave us! 8^)

/R


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