Home page logo

nmap-dev logo Nmap Development mailing list archives

Re: Storing scan results
From: Adam Jones <ajones1 () gmail com>
Date: Mon, 20 Jun 2005 18:00:21 -0500

On 6/20/05, "Grodås, Ole Morten" <omgrodaas () fih mil no> wrote:

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
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:

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.


Sent through the nmap-dev mailing list

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]