Monitoring Changes on Your Network over Time Using PBNJ
Joshua D. Abraham
Using Nmap to scan your network has become a security
standard. With the addition of OS detection and service version detection,
Nmap's features have expanded to the point where it is one of the most useful
security tools available today. Nevertheless, it is widely understood that Nmap
has several limitations, the chief one of which is the manner in which Nmap
processes information about changes. To be frank, it simply doesn't. When you
perform an Nmap scan of your network, what Nmap does do is present you with a
"snapshot in time "of your network.
The brilliance of Nmap is its capability to perform this
task quickly, reliably, and with precision. But as we all know, the only
constant in life is change. So when there are changes on your network and you
run your next scan, as far as Nmap is concerned, there is no history; there is
only the current scan.
Nmap does not provide a convenient method of monitoring
changes on the network so, until recently, the only way to actually determine
whether anything had changed was to perform another scan and compare the
results by hand. This is a very time-consuming process that is tedious and
prone to all the typical errors of such tasks. Sure, the *nix wizards would
just whip up a quick shell or Perl script to show the changes between two
scans, but again, this is still only comparing two snapshots in time.
A better solution is to store a history of the changes in a
common location, a database, as opposed to dealing with flat files created on
an ad hoc basis. This is exactly what PBNJ does: it parses, correlates, and
stores in a database all the information it harvests from Nmap about the
changes taking place on your network.
|