|
Written by David Torre
|
|
Page 1 of 2 Benefits of Storing Nessus Scan Results in MySQLWe all know that vulnerability management goes far beyond merely pointing an automated scanner at predefined targets and reporting back on the findings. Information security professionals are often stretched to the max, so whenever something can be automated it warrants further investigation. The tasks associated with vulnerability scanning play a major role in an overall vulnerability management program, but these activities must not be monotonous or mundane. Instead, I’ll show you how to put the boring stuff on autopilot, and create an infrastructure that supports standardized reporting and alerting through your existing enterprise tools.
While an example of email alerting will be provided, it is important to note that this article does not attempt to build a reporting system for you. Instead, it demonstrates how to build an infrastructure that supports reporting so that you may utilize existing enterprise reporting tools such as Cognos, Business Objects, and others.
Nessus Scheduling and MySQL Storage Requirements
In this article, I assume you have access to a UNIX or UNIX-like server with Nessus version 4.2.0 or greater installed. I also assume that the server has a relatively recent version of the MySQL database server and standard MySQL command line client utilities such as mysql and mysqlimport. Microsoft Windows users may be able to port these instructions over to Windows environments with the help of Cygwin and MySQL for Windows.
On the Nessus server, we will run the scans as the UNIX “root” user, and use the following directory structure for storage:
/root/nessus_scans - Where the scan data will live.
/root/nessus_scans/configs - Scan scripts and target files.
/root/nessus_scans/cron - Master bash scripts.
/root/nessus_scans/reports - Reports / general SQL scripts.
Nessus ArchitectureIf you are reading this article, you’re probably quite familiar with Nessus architecture. However, let us recap the basic building blocks to be used in our system:
- Client- The Nessus client used to be a fat GUI client, but is now fully web-based.
- Server – The system performing the actual scanning
- License – Professional or Home Feed. Unless you are scanning your home network, buy the ProFeed.
- Targets – What to scan. We will be using stand-alone text files to store targets in CIDR format.
- Policies – How to scan. We will be using policy files in the .nessus.v1 format.
- Scan– The activity of scanning one or more targets using a specified policy.
- Reports – Results of the scanning activity. We will be pulling data from .nbe reports and storing in MySQL.
Nessus Scanning Process FlowA crontab entry will schedule a specific shell script to run, which initiates a scan. When the scan completes, an NBE results file is generated. Each scan (and associated collection of targets) will have its own MySQL table named after the scan. When the scan is complete, the table named after the scan is truncated, and the newest results are added. In other words, the SQL table (for example, dmz_hosts) is “refreshed” each time the scan is run.
Creating the MySQL Tables to Store Nessus ResultsAs mentioned in the previous section, we will have one database, and multiple tables—one for each scan. For example, if we want to scan our internal networks (192.168.1.0/24 and 192.168.2.0/24) as well as our DMZ (10.1.0.0/16) then we would create one database and two tables—mycompany_internal and mycompany_dmz. The database and tables are created below:
#Step1 Create our database, and grant permissions.
mysql -u root -p
#(enter root password)
use mysql;
create database nessus_420;
create user nessus;
grant ALL on nessus_420.* to nessus@localhost identified
by 'your_dbuser_password_here';
#Step2: Select our database, and start creating tables within it
use nessus_420;
CREATE TABLE mycompany_internal (
vuln_idx INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
recType varchar(60),
domain varchar(60),
fqdn varchar(100),
service varchar(60),
nessusId INT,
severity varchar(16),
synopsis TEXT
) TYPE=MyISAM;
CREATE TABLE mycompany_dmz (
vuln_idx INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
recType varchar(60),
domain varchar(60),
fqdn varchar(100),
service varchar(60),
nessusId INT,
severity varchar(16),
synopsis TEXT
) TYPE=MyISAM;
NOTE: In you anticipate very large numbers of rows in your tables, consider implementing indexes and sticking with the MyISAM storage engine.
At this point, we have a database named “nessus_420” with two tables: mycompany_internal and mycompany_dmz. We also have a specific database user named “nesssus” with full access to the nessus_420 database which helps us avoid using the MySQL “root” user account. In the next section, I will show you how to create scans files, schedule them from cron, and finally store the results in MySQL.
<< Start < Prev 1 2 Next > End >>
|
|
Last Updated on Friday, 16 April 2010 09:26 |
Add comment
|
|
Feed Entries 
White Papers 
