Snort for Splunk via rsyslog

[caine256]

I have a central syslog server forwarding snort alerts to my Splunk system via rsyslog. These snort alerts are currently the only data being received by Splunk. The input is configured as syslog and everything is fine in the normal Splunk Search. I really want to use Snort for Splunk, but it isn't parsing anything correctly with the type "syslog."

I manually changed the type to "snort_fast_alert", at which point the IP sections began working, but then the sources of the alerts became the central syslog server rather than the original source of the alert.

The last attempt I had was to simply change the source name to "snort" and leave the sourcetype as "syslog", but still no love from Snort for Splunk. I really need information/aggregation/analysis of the snort alert message field.

I've been Googling this for a while now and cannot seem to find an answer to this seemingly common configuration issue. How can I parse snort alerts received via syslog into Snort for Splunk?

Thanks much!

[Ayn]

Right - it wasn't actually the problem I was thinking of - the problem with not getting proper field extractions is that you specified the wrong sourcetype, "snort_fast_alert" instead of "snort_alert_fast".

The issue you will encounter though is what you've already discovered - that once you change the sourcetype from syslog to pretty much anything else, Splunk will no longer set the host that is specified in the event but rather just set it to wherever it got the event from. This is because Splunk has special rules for rewriting the host field for the sourcetype syslog. You can make the same rules apply to the snort_alert_fast sourcetype by specifying the following in a props.conf:

[snort_alert_fast]
TRANSFORMS = syslog-host

[Ayn]

No, you can't change any data in the index. If it's really important to have the correct host it's possible to overwrite the host value at search-time though, but the original host data will stay the same.

[caine256]

One last question, if you will, on the point that the "host" field will be incorrect. Could this be corrected with a transform? Read the original source hostname and replace the "host" field? Thanks!

[Ayn]

It really doesn't matter very much where you put it - Splunk will merge all configuration settings from all those files (more information on that here: http://docs.splunk.com/Documentation/Splunk/5.0/admin/Wheretofindtheconfigurationfiles )

Generally settings that are 'local' to your specific installation would go into a directory called local rather than default. I'd put it in /opt/splunk/etc/apps/SplunkforSnort/local/props.conf.

[caine256]

Fantastic! Thanks for the info. I'm a complete splunk newb...and there are about 10 props.conf files under splunk. Which would this most likely be:

/opt/splunk/etc/apps/SplunkforSnort/default/props.conf
/opt/splunk/etc/apps/learned/local/props.conf
/opt/splunk/etc/apps/legacy/default/props.conf
/opt/splunk/etc/apps/sample_app/default/props.conf
/opt/splunk/etc/apps/search/default/props.conf
/opt/splunk/etc/apps/search/local/props.conf
/opt/splunk/etc/system/README/props.conf.example
/opt/splunk/etc/system/README/props.conf.spec
/opt/splunk/etc/system/default/props.conf

Thanks!

[caine256]

Hi Ayn,

Thanks for the response. Below are a few sample alerts from suricata in snort fast.log format.

Jul 18 19:19:51 server1 suricata[88343]: [1:2001219:18] ET SCAN Potential SSH Scan [Classification: Attempted Information Leak] [Priority: 2] {TCP} 1.2.3.4:33835 -> 4.3.2.1:22
Jul 18 19:19:45 server1 suricata[88343]: [1:2016292:3] ET TROJAN RevProxy ClickFraud - hello [Classification: A Network Trojan was detected] [Priority: 1] {TCP} 1.2.3.4:30180 -> 4.3.2.1:443

Thanks!

[Ayn]

Could you paste some sample data? I've a fairly good idea what is going wrong but would like to verify. There's a long overdue update to Splunk for Snort coming (though I've been saying that for far too long now - ahem) and I plan to include support for Snort's syslog logs as well in that update.