Splunk for Snort - Only partial alert data shown

[JBowl0101]

Greetings!

I am hoping you can help me resolve a problem I'm having with my setup of Splunk for Snort. I have several Snort 2.9.0.3 sensors, that send data via Splunk Light Forwarder to a central Splunk server. That central Splunk server (4.2.3) has Splunk for Snort installed.

The Snort instances are set to log to /var/log/snort/alert_full. I have in input on the light forwarder set to read that file with input type snort_alert_full. I get data from the light forwarders, but it appears to be only the first line of an alert - I don't see, for example, src and dst IP. A raw message I get looks like this:

[**] [1:2406338:271] ET RBN Known Russian Business Network IP TCP (170) [**]
[Classification: Misc Attack] [Priority: 2]

and that's all I get. As a result, I can't do most of the useful things in Splunk for Snort. If I look at the output file from snort by hand, it has all the normal fields. If I turn off forwarding and view the events in Splunk, I get the same truncated message.

If I send the logs over via syslog, all the data shows up, but is of type "syslog" so it's not parsed by Splunk for Snort. I'm too much of a Splunk noob to know how to change that. 🙂

Any assistance on what I'm doing wrong would be greatly appreciated. Thanks!

• Jason

[JBowl0101]

Installing Splunk for Snort on my Snort/Light Forwarder box fixed it.. thanks very much! I didn't realize it was required for the source machine, but it appears that it alters how the light forwarder parses input data.

I appreciate your time, it's a big help to us.

• Jason

[Ayn]

Awesome! 🙂

As mentioned in previous answer/comment, the app does indeed alter how the source data is parsed, but only if any parsing takes place on the forwarder to begin with - and thst's only the case if it's not configured as a Light Forwarder.

I'm the author of the Splunk for Snort app, so it's nice to see that it's put to use. If you have any comments, questions or suggestions regarding the app, just let me know and I'll be happy to listen.

[JBowl0101]

Thanks for the detailed response, I appreciate it.

Please forgive my ignorance on this. I have two questions in response:

1) Should I be installing Splunk for Snort on the light forwarder boxes? I assumed it would not need it since it was just forwarding, but your mention of an included props.conf file makes me wonder if it's required.

2) I see a props.conf for each app, as well as a system one. Which of those would be the appropriate place to insert the lines you mentioned?

Many thanks,

Jason

[Ayn]

I see you already solved your problem, but yeah, installing the app on your forwarders will indeed make things work as that will include the props.conf settings you need. You don't need the app if you're configuring the forwarders as pure Light Forwarders, since in that case they'll just forward logs without doing (almost) any pre-processing so line breaking will take place on the indexer instead.

[Ayn]

The way your events break implies that the forwarders are breaking up events according to Splunk's default rules. Splunk for Snort includes custom rules for telling Splunk how to break up events instead of the default ones which, among other things, specify that Splunk should break and start a new event as soon as it sees a timestamp. Now, looking at a typical alert in alert-full format, it looks something like this:

[**] [1:100000160:2] COMMUNITY SIP TCP/IP message flooding directed to SIP proxy [**]
[Classification: Attempted Denial of Service] [Priority: 2]
08/02-22:08:23.517375 192.168.1.36:40544 -> 192.168.1.4:9000
TCP TTL:64 TOS:0x0 ID:3636 IpLen:20 DgmLen:40
***A**** Seq: 0x9D91EFFB  Ack: 0x6BF0501C  Win: 0x2328  TcpLen: 20

And as you see the third line starts with a timestamp. This is where Splunk breaks the event unless the custom line breaking rules are in place.

Most likely your forwarders are not running as pure Light Forwarders, instead they are breaking events before forwarding them to your indexer, and in doing that they are breaking the Snort events according to default rules. You could solve this either by making sure they're running as Light Forwarders, or see to that the following settings exist in props.conf on your forwarders:

SHOULD_LINEMERGE = true
BREAK_ONLY_BEFORE = \[\*\*\] \[\d+\:\d+\:\d+\]
TIME_PREFIX     = (?=\d+/\d+)
TIME_FORMAT     = %m/%d-%T.%6N

(taken from SplunkforSnort/default/props.conf so you could just copy that one and put it somewhere as well)