Follow up on Sguil securtiy

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!

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