Sguil: renaming a sensor

This might be a no-brainer for some, but today I wanted to rename a sensor in Sguil, and decided to write the steps down.


  1. backup the db
  2. stop sancp on the sensor
  3. stop barnyard on the sensor
  4. stop sensor_agent on the sensor
  5. stop snort on the sensor
  6. stop log_packets on the sensor
  7. stop sguild on the server

Steps on the Sguil server

Update the sensor name in the database.

# mysql -p
mysql> use sguildb;
mysql> UPDATE sensor SET hostname = “newname” WHERE hostname = “oldname”;
Query OK, 1 row affected (0.04 sec)
Rows matched: 1 Changed: 1 Warnings: 0

Rename the directory for the rules display

mv /sguild_data/rules/oldname /sguild_data/rules/newname

Steps on the sensor

Change the hostname in /etc/sensor_agent.conf

set HOSTNAME newname

Change the hostname in /etc/barnyard/barnyard.conf

config hostname: newname

Change the hostname in /usr/sbin/


Change the directory where sancp writes its files, for my Debian system in /etc/default/sancp


Change the Snort prefmonitor stats file location in /etc/snort/snort.conf

preprocessor perfmonitor: time 300 file /snort_data/newname/snort.stats pktcnt 10000

Rename the sensor directory

mv /snort_data/oldname /snort_data/newname


  1. start sguild on the server
  2. start on the sensor
  3. start sancp on the sensor
  4. start snort on the sensor
  5. start sensor_agent on the sensor
  6. start barnyard on the sensor

That should be all!

UPDATE: forgot about sancp, snort stats and

Sguil: adding support for ModSecurity alerts, continued

After the successful test with the Perl script to add ModSecurity alerts to Sguil, I have been working on a more robust implementation, also in Perl. Let me first describe the basic setup. The setup works with two scripts. The first places links to event files into a special queue directory. The second reads the links from that directory, parses them and sends the alerts among these events to Sguil. After that, the links are removed.

In ModSecurity there is a logging method called concurrent. What it does is that it creates a directory structure based on date and time. For each event a file is created in the directory structure, with the details of the event. It also writes a logfile called index, that adds one line for every event, with location of the file in the date/time directory layout.

ModSecurity also supports using a external script to take care of this indexing task, which is what the script modsec-auditlog-collector in the ModSecurity source tarball does. I have modified this Perl script to create a link to the actual event file in a special queue directory. The links all have a name like: modsec.log.-timestamp-, like Snort uses with unified logging. I have chosen to use links because I think it might be faster than copying, but I have yet to benchmark that.

The second script takes care of processing the links and communicating with Sguil. It basically has the following workflow. It gets a list of all the files in the queue. Each file in the queue is parsed, then it is checked whether it is an alert. If so, the data is preprocessed to make sure it is what Sguil expects. Next it is send to Sguil. Finally, all the files are removed.

ModSecurity has a different rule syntax than Snort and sees a different type of data. Snort sees packets, and thus knows about TCP checksums, sequence numbers, etc. ModSecurity works on a higher level, so it has no access to that data. One thing that ModSecurity alerts do include is the action taken: blocked or redirected and with what HTTP code. If available the rule msg is used for the Event Message, otherwise the ModSecurity message with (a part of) the rule that matched. Below is a screenshot that shows both, and also the HTTP code.

Sguil and Mod_Security msg view

The current implementation acts as a drop-in replacement of Barnyard. This way no changes to Sguil are necessary. Currently this means that Barnyard cannot run on the same sensor, although multiple instances of sensor_agent on a host could fix that. Sguil author Bamm Visscher suggested I can try to connect to the Sguil server directly instead of via the sensor_agent to fix this. I will probably have a look at that later.

Another issue is the way the alert data is presented in the Sguil interface. Currently I attach the entire alert file to the alert that is being send to Sguil, as the packet payload. However the Sguil packet payload view is not very usable for this kind of data, as can be seen on the screenshot below.

Sguil and Mod_Security payload view

So here is room for much improvement. Ideally Sguil would be able to show the uri, the post payload if applicable, useragent, etc. I’ve never worked with TCL/TK, but I did use Perl/TK in the past, so that might help me a little if I decide to give it a shot.

I expect a public beta version to be ready some time next week, although I have not yet decided how to release it. I could create a project on SourceForge or just have a simple webpage. I just haven’t decided yet. Stay tuned…

ModSecurity: rule for latest Tikiwiki vulnerability

A few days ago a new vulnerability was reported in Tikiwiki 1.9.x, the software I use for the Vuurmuur Wiki. Luckily, the Community rules quickly had a rule for detecting the attack. Because I also run ModSecurity on the webserver, i wanted to have protection there as well. This rule should block the attack:

SecFilterSelective POST_PAYLOAD “jhot.php” “log,deny,status:403,msg:’LOCAL tikiwiki jhot.php attempt’”

Let’s see if I ever get a hit on it. An update for Tikiwiki as been released, so that should fix the issue completely.

Vuurmuur: connection killing getting shape

The main new feature of the 0.5.72 release of Vuurmuur will be the ability to kill existing connections from vuurmuur_conf. It will use the conntrack tool for this. Below is a screenshot of how it works.

Vuurmuur-conf killing a group of connections.

Currently it works only for TCP connections and UDP pseudo connections. From the connection manager IPAdresses can also be added to the blocklist. All existing connections for this IP will be killed on that action. I have yet to extend this to hosts blocked manually.