Re: Storing scan results

[Adam Jones <ajones1 () gmail com>]

On 6/20/05, "Grodås, Ole Morten" <omgrodaas () fih mil no> wrote:
> Hi,
> Adam
>
> I have to agree that adding db support to nmap will be a problem. After reading your mail I got another Idea that 
> might work around the db problem.
>
> Having the GUI Frontend read xml output from nmap and saving it in a db is a good solution except when you want to 
> run regular scans from cron.d. This problem can be solved by making a small nmap2db command line tool, using the same 
> xml to db code that is used in the GUI Fronted
> You could then run nmap commands like this:
>
> nmap [scan options] target | nmap2db -localdb
> Or
> nmap [scan options] target | nmap2db -h [hostname] -u [username] -p [password] -d[database]

I think it would be following in the nmap "tradition" to provide a
command line alternative to the GUI client for as many purposes as is
reasonable. I like that idea, and would recommend that it be able to
read xml files as well.

> My opinion is that if you want the GUI to have advanced search, sort and compare functons the best solution will be 
> to save results in a database

After a scan log has been loaded it would be able to provide the
majority of those features without resorting to a database. For me
program weight has always been one of the defining points separating
nmap from the larger "vulnerability engines" like nessus. Introducing
a database as a required component, even for an optional GUI client
seems to go against the idea and implementation method. I agree that
more can be done with a database than without, but a lot of people
just want a clickety-click view of their scans without having to set
up a database server to do it.

> You talk about the problems with a static database structure. I my opinion this is not a big problem. Adding new 
> metadata will of course be more problematic, but this is not something that happens very often in nmap. I have 
> created suggestion on the database design, A MLU diagram can be found her:
> http://home.no.net/grodaas/nmap/pic/db.gif

Problems with adding new metadata were exactly my argument against a
database implementation at all. I think your database tables are a
good start for a standardized database, but people writing their own
solutions will already have a database structure in mind, or possibly
even designed. A scan analysis system with its own database structure
sounds like a good project, but better tools can be made for those
that already have something at least halfway written.

-Adam


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