Home page logo

nmap-dev logo Nmap Development mailing list archives

Storing scan results
From: "Grodås, Ole Morten" <omgrodaas () hsbs mil no>
Date: Wed, 15 Jun 2005 10:43:14 +0200

To me it looks like there are a lot different opinions on how to organize and store search results. I have some ideas 
and some arguments for my ideas. 

Comments and other ideas are most welcome  

After some consideration I have found the following to be a good solutions. 

1. Support for exporting/importing scans in XML files.
2. By default, scans are saved in a local db, using a db libary. SQLite looks promising. Small, scalable, fast, mature, 
cross platform and supports multiple programs accessing the database at the same time
3. Support for remote SQL server.

My little idea.
A database interface is created. By default it is using the local db library, but it also supports SQL servers. The 
interface is written in a modular way. That way nmap can access it for saving results, the GUI can access it for 
displaying results. And it can easily be removed if some one really does not want it.
For example nmap could be configured to run like this:

nmap -db -scanoptions target

Why and when is this useful? Example: An administrator wants to run regularl scans of the network to check for 
vulnerabilities. He can easily add this command to cron.d and when he wants to do an analysis on the results he can us 
the GUI. 

This can be done with XML files in a directory structure too. And it can even be done without changing nmap. The 
problem arises when you start doing a lot of scans or are scanning large networks. For example doing one or more daily 
scans over some time on a large network. As fare as I know, parsing that amount of data from XML files will lead to 
performance problems. 

Another important advantage of exclusively using databases is that you can use SQL queries. This will significantly 
reduce the amount of code necessary to make search, sort and compare functions

NOTE: SQLite operator parser has support for REGEXP. There is no function to back up this operator in the standard 
build, but users can add their own using sqlite3_create_function(). There are working REGEXP functions for SQLite but I 
believe it might be a good idea to build our own using libpcre. MySQL has built inn support for REGEXP.

Sent through the nmap-dev mailing list

  By Date           By Thread  

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