RE: [RFC] Ndiff

["Thomas Buchanan" <TBuchanan () thecompassgrp net>]

> -----Original Message-----
> From: nmap-dev-bounces () insecure org 
> [mailto:nmap-dev-bounces () insecure org] On Behalf Of Michael Pattrick
> Sent: Sunday, June 15, 2008 2:56 PM
> To: nmap-dev () insecure org
> Subject: [RFC] Ndiff
>
> Hey everyone,
>
>
> Nmap could use a program that intelligently compare XML output files,
> instead of just doing the type of diff that Zenmap currently uses, we
> could be parsing the files and outputting an intelligent diff that
> better reflects the differences in network state. This diff file could
> then be used by Zenmap or a third party program for visualization.


Michael,

I agree that this would be a very welcome new program / feature for
Nmap.  A couple of questions come to mind, if you don't mind?

1.  What attribute (or set of attributes) will uniquely determine a
specific host?  For directly connected hosts, it seems like MAC address
is a pretty obvious choice.  For hosts one or more layer 3 hops away, IP
address seems logical, but in certain situations this could lead to a
lot of churn.  One example: a branch office on the Wide Area Network
that you scan on a weekly basis, which consists primarily of DHCP
connected workstations.  They get powered off over the weekend, or their
leases expire, however they get new addresses, this leads to a lot of
false positives for new, changed, or deleted hosts.  In situations like
this, it might be helpful to be able to specify alternate attributes to
track hosts by, for example, reverse DNS name.  If this is possible,
then the tool would need a way to indicate that a host's address has
changed, even though its ports and services may not have.

2.  In your example for host 10.9.8.7, how does the XML indicate the
previous state of a new port?  In the text output, it indicates port 53
went from filtered to open, which is nice to know, but I don't see this
information in the corresponding XML.

By the way, this information might be difficult to retrieve in certain
situation, for example, if a host has a large number of closed ports, as
well as a number of filtered ports, you may not know by looking at
Nmap's XML output whether a specific port is closed or filtered.  Here's
an example from one of my recent scans:
Text output:
All 65535 scanned ports on host100.test.local (192.168.1.100) are
filtered (65509) or closed (26) because of 65509 no-responses and 26
resets

XML output:
...
<ports><extraports state="filtered" count="65509">
<extrareasons reason="no-responses" count="65509"/>
</extraports>
<extraports state="closed" count="26">
<extrareasons reason="resets" count="26"/>
</extraports>
</ports>
...
There's no way to tell from this scan if port 53, for example, is one of
the closed ports, or one of the filtered.  So in that case, a diff tool
wouldn't be able to specify.  But where it is possible, I think it's
useful information.

Anyway, best of luck in getting this tool going.  I look forward to
further progress.

Thomas

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