Re: Another look at Nmap XML

[sitney () gmail com]

> > * Hostname PTR resolution status - If a rDNS record cannot be
> > resolved, let -oX know about that. This omission causes Nmap::Parser
> > to choke and spit out an error (eest on freenode recently submitted a
> > patch to correct this after we identified the issue). Also, the
> > hostnames  order when displayed in HTML (user and PTR) are often
> > reversed inconsistently. May require a minor XSLT tweak.
>
> The fact that rDNS resolution failed is arguably already represented by
> the absence of a hostname element. Scanning a target with no rDNS
> produces this:
>
> <host starttime="1277780978" endtime="1277780981"><status state="up" reason="user-set"/>
> <address addr="1.2.3.4" addrtype="ipv4"/>
> <hostnames>
> </hostnames>
> <ports><extraports state="filtered" count="100">
> <extrareasons reason="no-responses" count="100"/>
> </extraports>
> </ports>
> </host>

Yes. The absence of a hostname element provides a clue that an rDNS lookup failure occurred if the original scan target 
was an IP address. However, if the original scan target is a hostname, then even this clue is erased:

<host starttime="1277788024" endtime="1277788043"><status state="up" reason="reset"/>
<address addr="207.46.197.32" addrtype="ipv4" />
<hostnames>
<hostname name="microsoft.com" type="user"/>
</hostnames>
</host>

> Would you prefer that this be shown in another way? Can you provide an
> example of what the XML would look like?

Yes. In the case where a hostname is the original scan target, include a line for type="PTR". So in the above case, the 
output would look like this:

<host starttime="1277788024" endtime="1277788043"><status state="up" reason="reset"/>
<address addr="207.46.197.32" addrtype="ipv4" />
<hostnames>
<hostname name="microsoft.com" type="user"/>
<hostname name="" type="PTR"/>
</hostnames>
</host>

You may decide to insert a value between the "" such "no PTR" or "rDNS failure" Something (or nothing) to indicate that 
the rDNS lookup failed will be an improvement. If this suggestion is adopted, then you will need to reexamine the way 
rDNS failures are presented when the scan target is an IP address, for consistent output, perhaps:

<host starttime="1277780978" endtime="1277780981"><status state="up" reason="user-set"/>
<address addr="1.2.3.4" addrtype="ipv4"/>
<hostnames>
<hostname name="" type ="user"/>
</hostnames>

> > * # of IPs - If a hostname has multiple IPs, standard output will
> > indicate how many there were and Nmap proceeds scanning the first one
> > found. This number is omitted from -oX. Ideally, all the IPs for a
> > hostname will be listed in -oX, but at the very least, please include
> > the # of IPs found. This is often an indicator of a load balancer
> > which is a useful piece of information.
>
> You are right that this isn't shown in the XML. What do you think the
> output should look like? Part of me just wants to stuff all the
> addresses into the host element:
>
> <host starttime="1277781472" endtime="1277781474"><status state="up" reason="syn-ack"/>
> <address addr="74.125.19.147" addrtype="ipv4"/>
> <address addr="74.125.19.104" addrtype="ipv4"/>
> <address addr="74.125.19.103" addrtype="ipv4"/>
> <address addr="74.125.19.99" addrtype="ipv4"/>
> <hostnames>
> <hostname name="google.com" type="user"/>
> <hostname name="nuq04s01-in-f147.1e100.net" type="PTR"/>
> </hostnames>
>
> That's not so good once we add the planned option to scan all the
> addresses associated with a name--would we repeat all the addresses in
> each host element?

I think starting with an address count, similar to standard output, would be a great start. When discussing the option 
to scan all the addresses associated with a name, how all the addresses are output to xml should be factored into your 
discussion. For now perhaps introduce a new element which would apply to your example:
<address total="4" addrtype="ipv4"/>

This would close the gap as far as what standard output sees and what is included in xml.

> > At the bottom of the html output screen, offer a "click to download in
> > .csv format" button. This will get most users outputting to XML
> > knowing that they can easily download a greppable file from their
> > browser, and some will undoubtedly see the power of Nmap XML output
> > and find ways to stick with it.
>
> Can you explain more about how this will work? Is the ".csv format" the
> same as grepable output?

Maybe the bottom of the screen is not the right location, but right at the top. Yes. Show the greppable otuput.

In the HTML output, the top of the page has #links to each line. This is not a high priority feature to dominate the 
very first thing one sees in IMHO. We all know how to use the find feature on an html page. Perhaps use that valuable 
real estate for greppable output and I strongly believe this will encourage tons of users to start outputting to xml.

> > I am not an XSLT expert by any stretch, but I may take this challenge
> > up myself and see if I can't update the stylesheet with this
> > functionality and contribute to Nmap in some positive way(s).
>
> I hope you decide to give this a try. A good easy thing to start with
> would be consistent ordering of user/PTR names. "user" names didn't
> exist when the XSLT was last updated, and it appears to be just sorting
> the names alphabetically.

Yes. I will work on a XSLT variant that does what I just suggested. And yes, I would order it "user" then "PTR" (or "no 
PTR") as the case may be.

Cheers,
Blake

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/