Seccubus on Ubuntu - The Missing Manual

My tool of choice for vulnerability scanning has always been Nessus, going all the way back to when it was properly OpenSource and the 'Experimental Checks' checkbox was a sure fire way to crash your target. Since going full commercial it's only gotten better and the current interface is very clean and polished. The biggest downside being that each scan is treated as a stand-alone unit so the application itself can't do any kind of trending or inter-scan analysis. The company does provide a tool that does exactly this but monies. Compared to many tools it's still somewhat cheap, but I can still think of many places I would rather spend the funds.

In past work we did a bit of custom development to perform the tasks; they're kind enough to provide a REST API to the scanners, and XML reports means we can do XML->CSV for aggregate reporting. Every now and then we would look for more of a platform tool to do the task. For some time I hoped InProtect would be that tool but it died on the vine and never quite made it to useful.

Lately I've been looking at a tool called Seccubus. Much like InProtect tries to fill that management and reporting platform niche without costing a good sized fraction of an FTE. In theory this will give me single web interface to schedule the scans of hosts and track how the state of the host changed over time. Or, even better, let me quickly carve up a whole big whack of systems looking for specific things. Since I'm a team of one I could, in theory, take care of this myself using the same methods we've done in the past and not worry about fancy tools. Excel is still pretty nifty for sorting and aggregating data. Seccubus really drew my eye for two reasons.

  1. It supports more than just Nessus (Nikto, Skipfish, and Nmap)
  2. It's actually under active development

Even if the interface never gets as slick as the commercial tools knowing a group of people are actually making code commits tells me I don't have to worry as much about picking up a tool and having to internally maintain it when they get disappear.

Unsurprisingly the documentation is pretty rough. Most of it is dated 2011 and lacking in some pretty substantial areas. The install docs date from a time when version 2 was still in beta and don't address .deb packages at all. In a perfect world the packages are complete enough that installation instructions are "Run apt-get install seccubus and go to the webpage.". Unfortunately I found it to be not quite so simple.


My test system is running Ubuntu 14.04, which works well enough since they give me a nice .deb to install from. What they don't do is provide any documentation as to the pre-reqs. The deb file does contain most of the necessary pre-reqs but not all.

aptitude install apache2 mysql-server ruby libalgorithm-diff-perl libjson-perl libxml-simple-perl libhtml-tree-perl libapache2-mod-perl2
dpkg -i seccubus_2.10.B194_all.deb

Database Configuration

The deb package will copy out all the files but it won't do any of the database set up for us.

mysql -u root -p << EOF
create database seccubus;
grant all privileges on seccubus.* to seccubus@localhost identified by 'seccubus';
flush privileges;
mysql -u seccubus -pseccubus seccubus < /var/lib/seccubus/structure_v5.mysql
mysql -u seccubus -pseccubus seccubus < /var/lib/seccubus/data_v5.mysql

It may be somewhat smart to set a different password for the MySQL seccubus user, but when you do make sure to change it in the /etc/seccubus/config.xml file as well.

Web Server Setup

The package drops an attempt at a virtual host config in /etc/apache2/conf.d/seccubus.conf. This doesn't get loaded automatically, and it also places it in a janky URI. I'm using this host as a dedicated instance so the only web app being served here is Seccubus. To make it easy on myself I edited /etc/apache2/sites-available/000-default.conf to be:

<VirtualHost *:80>

  ServerAdmin webmaster@localhost
  DocumentRoot /opt/seccubus/www/

  LogLevel info

  ErrorLog ${APACHE_LOG_DIR}/error.log
  CustomLog ${APACHE_LOG_DIR}/access.log combined

  <Location />
    Allow from all
    Require all granted
    # Allow from
    AddHandler cgi-script .pl
    Options ExecCGI


# vim: syntax=apache ts=4 sw=4 sts=4 sr noet

Additionally, we need to enable a couple of modules or else the web application will not throw any visible errors but will only be partially functional.

a2enmod perl
a2enmod cgi

Points to Note

The Seccubus application has no internal authentication or user management. I think it goes without saying that given the sensitivity of the information you'll be storing you should get some. Since Apache has many easy to use authentication backends you should look there. Which also means setting up HTTPS so you're passing credentials, or scan results for that matter, in clear-text.

Since there is no user management we're also stuck with access == kingdom keys. Unlike the commercial tools or InProtectRIP it's impossible to restrict access to allowed subnets or designate reporting users.

All in all the application has some nice starting points but feels very much like an early work in progress. I think it'll work fine for my uses, but I'm a lone security guy with a couple of sysadmins. I feel as if there's quite a lot of work to be done before I'd suggest it for enterprise use. In my opinion the minimum features to make it out of test lab, or my scale, are task granularity for user permissions and assigning network scopes to specific scanners. I want to be able to grant read only access to report viewing, specifically only for those hosts you're responsible for. I want to be able to allow admins to initiate scans of their own equipment using settings I've vetted. I want to be able to place a scanner in a remote site and assign that site's network block to the remote scanner so we don't flood the up-link with scans.

The largest stumbling block I ran into was that the application didn't seem to function correctly in my installation of Chrome (running 38.0.2125.111 on Mac OSX 10.10). I haven't gotten far enough along to know if this is an application bug or a browser issue. I'm including the note as a heads up rather than a warning.