Re: Design decisions

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

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="10.3.7.4" ip_v="4"></filteredby>

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