Planet SoC

For my readers that don’t know what Nmap is, you wont understand the following. I’ve been gun preparations to start coding an Nmap diff utility (codename Ndiff), and one of my tasks was to propose a possible format for the diff files, enjoy the following.
Hey everyone,
David said it better then I can:
On Sun, Jun 15, 2008 at 3:02 PM, David Fifield <david@bamsoftware.com> wrote:
> The real problems is that Zenmap’s comparison doesn’t answer the
> questions a users wants answered: Are there new hosts on the network?
> Did any machines go down? Any new ports? Web server still running?
> Zenmap just gives you a jumble of colored text and asks you to figure it
> out.
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.
Here is a partial example of how the differences could be represented
in XML. The new tags <addhost> <delhost> <chghost> are used to express
changes in the host state. Inside the *host tags <chg(state/service)
is paired with <old(state/service) to show what has changed, both <add
and <del (port/state/service) are unpaired because their changes are
obvious.

1. <nmapdiff startdate="12/4/07" starttime="13:31:42" enddate="12/4/08" endtime="21:04:26" >
2.      <chghost>
3.           <address addr="10.9.8.7" addrtype="ipv4" />
4.           <addport protocol="tcp" portid="53">
5.                <addstate state="open" />
6.                <addservice name="domain" product="ISC BIND" version="9.2.1" method="probed" conf="10" />
7.           </addport>
8.           <chgport protocol="tcp" portid="80"> <state state="open" />
9.                <chgservice name="http" product="Apache httpd" version="2.0.39" conf="10" method="probed" />
10.                <oldservice name="http" product="Microsoft ISS" version="11" conf="10" method="probed" />
11.           </chgport>
12.      </chghost>
13.  
14.      <addhost>
15.           <address addr="192.168.2.1" addrtype="ipv4" />
16.           <addport protocol="tcp" portid="21"> <addstate state="open" />
17.                <addservice name="ftp" product="ftpd" version="1" method="probed" conf="10" />
18.           </addport>
19.           <addport protocol="tcp" portid="8080"> <addstate state="open" />
20.                <addservice name="http" product="Apache httpd" version="2.0.39" conf="10" method="probed" />
21.           </addport>
22.      </addhost>
23.  
24.      <delhost>
25.           <address addr="192.168.2.100" addrtype="ipv4" />;
26.           <delport protocol="tcp" portid="21"> <delstate state="open" />
27.                <delservice name="ftp" product="ftpd" version="1" method="probed" conf="10" />
28.           </delport>
29.           <delport protocol="tcp" portid="8080"> <delstate state="open" />
30.                <delservice name="http" product="Apache httpd" version="2.0.39" conf="10" method="probed" />
31.           </delport>;
32.      </delhost>
33.  
34.      <runstats>
35.           <addhost address="192.168.2.1" reason="reset"/>
36.           <delhost address="192.168.2.100"/>
37.      </runstats>
38. </nmapdiff>
39.  

The differences could also be outputted in a more readable format such as:

1. 12/4/07 - 13:31:42 -> 12/4/08 - 21:04:26
2.      10.9.8.7:
3.           Port 53/tcp is now open, was filtered
4.           Port 53/tcp is now listening with ISC BIND
5.           Port 80/tcp is now listening with Apache httpd, was Microsoft ISS
6.      192.168.2.1:
7.           Host 192.168.2.1 has come online.
8.           Port 21/tcp is now listening with ftpd
9.           Port 8080/tcp is now listening with Apche httpd
10.  

There is also the matter of the language I would implement this in,
Ive given it some thought and heres what I’m thinking:
PERL
Pros:
- Many parsers and applications for Nmap’s XML format already written
in this language.
Cons:
- Nmap would have to list PERL as an optional requirement.
Python:
Pros:
- Easy integration with Zenmap
- Nmap already relies on Python for Zenmap, no extra dependencies.
Cons:
- It seems that the only Nmap XML parser(xml-expert) is dead.
- I’m not particularly fond of python.
C++:
Pros:
- Easy integration with Nmap/Zenmap
- Possible future integration for XML parsing with Nmap, resuming
scans and etc.
Cons:
- I couldn’t find any prior work, so I would probably end up working
with LibXML2
As you can see, there are still a lot of unresolved details, I would
appreciate any input on this. Here are some of the requirements that
David gave me:
* It must read Nmap XML files. (It is explicitly not a requirement to
read any other type of output file.)
* It must compare two output files at a time.
* It must show which hosts have come up or gone down.
* It must show when a port has changed state.
* It must support comparing output files coming from different scans
(different Nmap options or different target specifications).
* It must allow output in English text.
* It must allow output in XML, with a format and DTD to be determined.
Cheers,
Michael