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_at_insecure.org . List run by ezmlm-idx (www.ezmlm.org).
Received on Dec 21 2002
Intro
