Sguil

In the discussion about my post about Sguil security there have been a number of ideas and general thoughts. I’d like to write about them here to we can further discuss them. There seems to be consensus on that when a sensors is rooted, there is nothing we can do to prevent injection of bogus data as long as it isn’t malformed. Having the agent authenticate itself is a solution, but it relies on the agent credentials to remain secret. So when a webserver is rooted the attacker will have access to the credentials as they will be stored on the webserver itself. So this approach does provide an extra layer of defense but local roots aren’t uncommon, so it remains risky. It may still be worth the effort though. ...

Sguil is build using a server and sensors. Traditionally the sensors are passive monitoring agents running Snort and a few other tools. Best practice was (and still is) to separate the management network of these sensors and server from the monitored network(s). This way it would be fairly hard for an attacker to get a shot at the Sguil server. Sguil of course, would be a extremely interesting target for hackers. It contains so much info about the monitored network. Also, it has realtime access to all network traffic. A hacker may also be interested in shutting Sguil down to avoid detection. ...

Recently I wrote about the idea to log all HTTP transactions into Sguil using my Modsec2sguil agent. I’ve implemented this in the current 0.8-dev5 release and it works very well. All events go into Sguil smoothly and I’ve not experienced slowdowns on the webserver. I’ve been running it for almost a week now, like to share the first experiences here. I find it to be quite useful. When receiving an alert, it is perhaps more interesting to see what else was done from that ipaddress than to see what was blocked (unless you are suspecting a false positive of course). One area I find to be useful is when I’m creating rules against comment spam on this blog. By seeing all properties of a spam message I can create better rules. For example on broken user-agents or weird codes inserted into the comment field of Wordpress. ...

Modsec2sguil is currently configured to send alerts to Sguil. ModSecurity can be configured to log any event or transaction, including 200 OK, 302 Redirect, etc. Modsec2sguil distinguishes between alerts and other events by only processing HTTP codes of 400 and higher. Since 0.8-dev2 there is a configuration directive to prevent certain codes, such as 404, from being treated as an alert. Now I have the following idea. Since ModSecurity can log all events with details of request headers, response headers and POST message body, it may be interesting to just send all these events to Sguil. They should not be appearing as alerts, but having them in the database can perhaps be interesting. I know using flow data and full packet captures the same data can be accessed, but having it in the database makes querying it a lot easier and longer available. ...

I just uploaded a new version of Modsec2sguil. I’ve been working on it the last weeks to get it updated to Sguil 0.7. The scripts are changed all over the place. This is because in the 0.7 framework, my scripts would no longer be a replacement for Barnyard only talking to the sensor_agent on the localhost, instead now it would become a full agent talking to the Sguil server directly. ...

Today I finally restored my server that used to host my blog, mail server and sguil server. The sguil server was still at 0.6.1 so this was a good time to see how a migration procedure would work (the earlier 0.7.0 test were done with a newly setup server). I haven’t been able to find documentation about this procedure, but it looks very straightforward, so I think I did it all right. ...

A short time ago I wrote about how the Sguil 0.7-CVS client can be installed on Ubuntu Feisty. Since then there has been a change to Sguil that changes the requirements a bit. Because of this the standard tcllib package in Feisty is no longer usable. It provides tcllib 1.8 while Sguil now needs 1.9. Luckily, we can use the tcllib package from the upcoming Ubuntu release called ‘Gutsy’. It can be found here: http://packages.ubuntu.com/gutsy/interpreters/tcllib ...

I just got a new workstation that I’m setting up today with Ubuntu Feisty 7.04. When setting up the Sguil client from CVS I needed to install the following packages (including dependencies, but apt-get takes care of that): tcl8.4 tclx8.4 tcllib tk8.4 iwidgets4 After this it ran but looked horrible because of some ugly font that was used. I found that for my use the following fonts look good: ...

Sguil 0.7 is getting shape quite nicely. One of the most interesting new features is the splitting up of different types of agents and the option to create ’net groups’. This are groups of agents that Sguil considers part of the same network. You can use this to spread the agents over multiple servers, but still use it from Sguil as if it was one single sensor. For example, this way you can easily create a Snort sensor and a separate full content logging capture server. When you request the full content for a Snort event in Sguil, it will know that it needs to request the packet data from the capture server. This way you can also have multiple Snort agents without the need for capturing the same sancp and full content data over and over again. ...

I’ve just released version 0.7 of Modsec2sguil, the set of perl scripts to feed ModSecurity alerts to the Sguil NSM system. The main change of this release is that it adds support for alerts produced by ModSecurity 2.x, while 1.9.x remains to be supported. Next to this the conversion between ModSecurity’s severity and Snort’s priority was fixed, so alerts should show up in the right pane in Sguil again. Please give this release a try and let me know how it works for you! ...