Home page logo

nmap-dev logo Nmap Development mailing list archives

Re: Design decisions
From: R Anderson <listbox () pole-position org>
Date: Sun, 22 Dec 2002 00:43:32 +0100

Fyodor wrote:

On Thu, Dec 19, 2002 at 10:58:38PM +0100, R Anderson wrote:
>1. I have a working patch that adds intermediate ICMP's received, per
>the schema proposal, to XML output.

Sounds cool -- I have wanted this sort of behavior for a while.  Does
it work with all the "raw" scan types (where reasonable)?  Is it
generic enough to store the reason for a port state (eg host
unreachable, admin prohibited by firewall, RST, etc) and the souce IP
that gave us the packet?

Currently it works with all types except connect(), ftp bounce and idle scan. It stores the ICMP type, code and source IP to new elements in the portlist structure.

>- Always include the filtered ports that have extra info. This is
>sensible, right?

But in many cases the "extra info" will be available and the same for
every closed or filtered port except for a handful in other states.
Perhaps the "ignored" tag could include the state as well as the
reason information for the one "ignored" (eg most common)
state/reason.  Then you could list the ports wich don't match that
state AND reason.

Hmm. My first version was based on Guillaume Valadon's DENY-REJECT patch (thank you Guillaume for getting me started!). It adds all the different ICMP unreachables as new states, inherently leading to the behaviour you describe. However I felt it wasn't logical. Either the states should describe the actual answers we got (RST, port unreachable, no answer, other ICMP's) or it should be a guess of the port's logical state (open, closed, filtered [with more or less detail on how it's filtered]) - like nmap's current behaviour. Guillaume's patch mix those two approaches.

So I rewrote the whole thing from scratch again, this time adding ICMP type, code and source IP as new elements to the port list, and leaving the states as it is. I am still not sure which is best. Do we want a scanner that tells us all known facts, or do we want a scanner that translates the technical mumbo-jumbo, possibly with some information loss, to something an ordinary luser can understand? Personally I want all information, that's why I started complaining about the ICMP information loss in the first place. But I'm not sure it will fit in your official stock nmap. Maybe we could add new options like "--executive_summary" and/or "--show_deep_geek_info" :-)

Maybe the "states" should (internally) reflect the actual answers, while still presenting the educated guess in the output.

All this ends up in a couple of decisions not yet made. I'm still thinking.

>2. If I want to include non-intermediate ICMP in the XML output (eg. a
>strange message from the target itself, perhaps on just some ports), how
>should I encode it? By leaving out the "srcipaddr" or by filling it in
>with the target address? I prefer leaving the srcipaddr property out. Or
>should we modify the schema a little?

What schema are you referring to?  One of my old XML proposals?  The
DTD?  Something else?

I mean the XML output proposal at http://lists.insecure.org/lists/nmap-dev/2000/Jul-Sep/0012.html. Is there any newer or better place to look? It includes this:

<filteredby></packet proto="ICMP" type="3" code="3" name="ICMP port unreachable" srcipaddr="" ip_v="4"></filteredby>


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

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]