Tag Archives: agent

Follow up on Sguil securtiy

Posted on by

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.

One idea that came up was a proxy, in two forms. A Sguil proxy filtering the Sguil agent-server protocol is one of them. This would be positioned between the Sguil server and the agent to prevent the attacker going after the server directly. The proxy would be able to filter on the communications and could maybe trottle the rate of events to protect agains DoSsing the server. Maybe it could also block an agent completely is it’s sending malformed commands. Such a proxy could be positioned on the border of a monitored and management network.

David Bianco suggested a different proxy-like setup in which the actual sensor would receive the raw data over the network in some (secure) way from the webserver. This way the sensor talking to the Sguil server wouldn’t have run on the webserver. I think this is a good idea for the webservers. It does add complexity, because there will have to be some form of communications between the sensor and the webserver. At the same time this could simplify things as a single sensor box can deal with multiple webservers. In this case the credentials of the agent won’t be stored at the webserver, which is another plus. With this idea, much relies on how the webserver-sensor communications would be implemented.

Both ideas won’t be able to prevent an attacker owning the webserver to insert bogus data. Also in both cases the proxy can and probably will get a target itself.

Even though the risk increases with agents running on webserver, it also exists on other types of sensors. If a hole is found in Snort, Snort_inline, Sancp or other tools Sguil uses, the effects could be the same.

More ideas and suggestions are welcome!

Thoughts on Sguil security

Posted on by

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.

Securing Sguil is therefore very important. Sguil has a number of defenses. It separates agent and client access so an agent cannot issue commands a client only should issue. The clients need to authenticate to the server and Sguil provides the option to do both the agent-server and the client-server communications over SSL. Finally Sguil also has the option to only allow certain ipaddresses to connect. This can be set both for agents and clients separately.

With my Modsec2sguil agent, a part of these defenses go overboard. Modsec2sguil is likely to be run on webservers directly, and therefore the separation of a monitored network and a management network is no longer possible. Webservers tend to get hacked a lot more often than IDS systems, so this is an additional risk. A user getting access to the webserver is able to see that there is a Sguil agent active and will be able to connect to the Sguil server directly.

When all security of Sguil is in place the only thing this attacker will be able to do is act as an agent to Sguil. No authentication is required (or possible). The risk here is that the attacker can send bogus events to flood the analyst and Sguil itself. Possibly even DoSsing the server. By sending malformed data, the attacker could also try to crash the server.

So what can be done about it? Well I really can’t think of much other than to add authentication for agents in addition to the clients. This would provide an extra hurdle for the attacker because he has to get the right credentials. However, these credentials will have to be in the agent configuration on the sensor, so if the attacker manages to escalate his privileges he will get access to the credentials and this defense will fail. Still, it’s another layer of defense, so I think it’s better than nothing.

I’m very much interested in hearing other opinions about this!

Modsec2sguil 0.7 released

Posted on by

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!

Download it here: http://www.inliniac.net/files/modsec2sguil-0.7.tar.gz