September 30, 2010

Seccubus (Now on Lighttpd!)

Posted in Uncategorized at 3:36 pm by dgcombs

Vulnerability management is hard work. Even when you have something like Nessus to scan systems and point out vulnerabilities, the job is not done until the fix is applied[PDF]. That division of labor is often the source of even more hard work.

Nessus does an excellent job of combing through a long list of vulnerabilities and prioritizing ones that it sees. However, once Security exports the reports to HTML for the IT group that must remediate the vulnerability, it quickly becomes a very small and quiet needle in a haystack full of end-users overflowing with urgency. What I needed was a way to provide a checklist for IT to simplify the process of sorting through the vulnerabilities: which do we patch, which do we ignore and which were falsely identified?

Part of resolving a network problem may be to remove a critical access control list that restricts logins to specific locations. In the heat of the moment and in the dead of night, a network engineer's mind might be focused more on replacing his head on a pillow than replacing that access list on a router. What I needed was a way to identify these routers before hackers did.

Some of our hosts are accessible from outside the network perimeter. Yes, full-on change management is a really good way to make sure they haven't been compromised. But in a time-constrained real world, keeping an eye on open ports and other changes in the scanning target is a pretty good start for an audit tool. What I needed was a simple way to check for modifications to the system fingerprint.

Nessus scans can do all that but comparing this month's scan with last month's scan is not a task for the faint of heart. And identifying a false positive so it isn't re-re-reported next month is not simple either. Enter Seccubus with a tag line of Easy Automated vulnerability scanning and reporting. After checking through the documentation, I had to agree, it might just be a good fit. The only potential problem was that the documentation called for an install of Apache on the scanning machine. In my case, this system is not a dual-Xeon multi-core monster. I felt something a consuming a little less resources might be suitable for a smaller scale implementation. I checked a Hacker News Poll and found that the top two web servers were Apache (no surprise there) and Nginx.

I looked at Nginx (pronounced "engine-x") for a bit. Reading the Seccubus documentation, I realized that the web server would have to support CGI (Common Gateway Interface), specifically in the form of PERL scripts. But Nginx supports FastCGI, an extension of CGI. There is a workaround wrapper which can be used to execute CGI scripts from within Nginx. But the configuration for Nginx looked daunting out of the box. Then I noticed another winner in the Hacker News Poll was an old friend, Lighttpd. It is simple (a win for my little gray cells), lightweight (a win for my server) and supports CGI. Plus, you gotta love that name.

The standard directory that comes with the Seccubus download installs executable PERL scripts and the SeccubusWeb PERL module into the default WWW directory. I really wanted to separate the executables from the web application itself. And, since I'm a creature of habit, I moved things around a bit like so:

/var

++++/www

++++++++/htdocs

++++++++/cgi-bin

++++++++/res

 
I put all the HTML documents (index.html) and favicon.ico in htdocs.
I put all the PERL scripts into cgi-bin.
I put the JavaScript functions and CSS files in res.

Of course, I had to sort things out in the HTML and PERL now. I looked through the index.html file and updated the location of the CSS and JavaScript documents

<LINK HREF='res/sbp.css' TYPE='text/css' REL='stylesheet'>

<LINK HREF='res/layout.css' TYPE='text/css' REL='stylesheet'>

and

<SCRIPT src=res/ajax.js language='javascript' type='text/javascript'></SCRIPT>

<SCRIPT src=res/cookie.js language='javascript' type='text/javascript'></SCRIPT>

Then I went through the remainder of the file and updated all the references to the PERL scripts like so

AjaxRequestAndUpdate("/cgi-bin/getHelp.pl?topic=" + HelpTopic, "txtHelp");

In the CGI-BIN directory, I reviewed the PERL scripts. While SeccubusWeb.pm seems to be the workhorse for the other scripts, getScanInfo.pl and getFindings.pl call other scripts most often. Inside each of these three files, I found references back to PERL scripts which had to be updated.

<td><a target='_blank' href=cgi-bin/get_report.pl?scan=$scan&date=$key&type=html>html</a></td>

and

<form … action=cgi-bin/bulk_update.pl method=post>

I was still getting errors even though the web portion was working quite well. I had a hunch this was due to permissions issues. When I checked, the default install of Seccubus is running as user seccubus while the default install of Lighttpd is running as user www-data. I might have fixed this using group permissions and leaving both running as their own user, but I reasoned with myself (and won!) that the sole purpose of this web installation was to show Seccubus data. For that reason, I updated the Lighttpd configuration file, /etc/lighttpd/lighttpd.conf to run as user seccubus.

server.username = "seccubus"

Finally, I reconfigured Lighttpd to run CGI scripts from the CGI-BIN directory and properly serve the CGI-BIN and RES directories.

alias.url += ( "/res/" => "/var/www/res/",

                "/cgi-bin/" => "/var/www/cgi-bin/"

)

$HTTP["url"] =~ "^/cgi-bin/" {

       cgi.assign = ( ".pl" => "/usr/bin/perl" ) 

}

Extra Credit:
It is often said that a list of system vulnerabilities are one level more critical than the vulnerability itself. For that reason, it makes sense to restrict access to the web server providing the information to only those who need it. Lighttpd does not implement the Apache-like .htaccess/.htpasswd feature which would restrict access by user. However, it does allow access to be restricted by network IP. It is better than nothing. But Seccubus itself provides a mechanism to restrict access to specific scan information. It does this by relying on the environment variable REMOTE_USER. It would be awesome if this feature were based on some sort of login. In my tests, the scan of the Nessus/Seccubus server itself were hidden from me even though I put my credentials in the .allow file.

I now have a working Seccubus install that executes Nessus for me on a regular schedule. The Nessus provides a detailed analysis of each system it scans. Seccubus provides a checklist of vulnerabilities for IT management to work from, an early warning system for Network Engineering when they leave off an important ACL and an unapproved change notification. I'm ready for that next audit!

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: