Re: Storing scan results

[Adam Jones <ajones1 () gmail com>]

I think the better way to handle it is to make sure that any changes
to nmap assist in the XML to database conversion. Although I like the
idea of a database as an output format unless you standardize on one
table structure you will be going beyond the scope of what (IMO) nmap
does. A database upload tool that allows arbitrary structure and
supports whatever metadata or key relationships the user desires is a
huge project in and of itself. There is no easy way to allow the user
to tell nmap exactly how to store the data in tables, and maintain the
relationships correctly, and collect whatever other data is necessary
to perform the database work.

The other end of the spectrum is using a standard table structure,
much the way that nmap xml output is standardized. The problem here is
that xml can be said to be inherently transformable, where a database
is a more rigid structuring of data. A standard xml document is no big
deal, you are generally a small matter of xsl work away from the
correct document, especially when you consider that another xml file
can be used to supply metadata.

To that end I think the best way to handle this is to make nmap as
database friendly as possible. I would vote against having the tool
perform uploads to the database, as on one end we could not provide
enough support, and on the other there are better tools for the job. 
Possibly nmap could have flags added to specify xsl translations after
the scan has finished. This would let nmap spit out data pre-formatted
into the most convenient structure for whatever database people are
working with.

On 6/15/05, "Grodås, Ole Morten" <omgrodaas () fih mil no> wrote:
> Hi Anthony
>
> While I do see that perl is well suited language to use for this XML to database conversion. It is my opionion that 
> this should be handled by nmap and written in C++. I think it will be a mistak to make nmap dependet on perl only for 
> simplifying this convertion. Including this as a function in nmap will give us a standardized way to save scanresults 
> in databases. You then have the opportunity to use whatever tool you would like to do analysis on this results.
>
>
>
> -----Original Message-----
> Fra: Anthony Persaud [mailto:apersaud () gmail com]
> Sendt: 15. juni 2005 17:59
> Til: soc () insecure org; nmap-dev () insecure org; Grodås, Ole Morten
> Emne: RE: Storing scan results
>
>
> For administrators, who end up writing scripts in perl (for
> crons..etc) to store and analyze nmap scans - there is an Nmap::Parser
> Perl module that will either take parse the xml output file from nmap
> (parsefile()), or perform a scan of its own and parse it
> (parsescan()).
>
> You can use this module, to manipulate the data however you want. I
> have written an initial script (quick n' dirty), that will be
> available in the next release of the module. (Fully documented, and
> more features etc..)
>
> It uses SQLite as the database interface and stored (or updated) the
> entries of the table with IP,MAC,Status,Hostname,Open TCP Ports,
> Filtered TCP Ports, OS Family, OS Gen and time of scan.
>
> Hopefully others can find this useful. (Note that this is the initial
> version of the script, but it should work) For more info:
> http://www.nmapparser.com or
> http://search.cpan.org/~apersaud/Nmap-Parser/
>
> Regards,
>
> Anthony Persaud
>
>
>
>
>
> _______________________________________________
> Sent through the nmap-dev mailing list
> http://cgi.insecure.org/mailman/listinfo/nmap-dev


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