SQL Comes to Nmap: Power and Convenience

When you're using Nmap to check the security of many hosts, put MySQL to work keeping track of trends and changes.

We get Listing 3, showing the open ports information for target, when we use the following query:

mysql> select target_ip, d, t, port, protocol,
    -> state, runid from portstat
    -> where target_ip = ''
    -> order by d, t;

If you match the four lines of output with the section for in Listing 1, you can see the relationship immediately. As shown here, the portstat table alone can provide all the port scan information from Nmap. Of course, if you've done a number of scans, the above query shows all the results for found in all the scans.

Let's say that two days, or a week or a month later, you scan your network again and want to compare the two results visually. A quick look through the runlist table shows that runid 102 corresponds to two days after the first scan. Armed with that information, you enter the query:

mysql> select target_ip, d,t,port, protocol,
    -> state from portstat
    -> where target_ip = ''
    -> and runid = 102 order by d,t,port;

You easily can compare the results of Listings 4 and 5 to pick out the differences. Obviously, a program could compare the two result sets and summarize the differences for you.

Going back to the poor man's port scan results, the hoststat table contains information for each live host. It keeps a simple count of open ports in the open_ports column. To find the open port information for our target host, we query:

mysql> select ip,d,t,open_ports, ports_scanned,
    -> runid from hoststats where order by ip, d,t;