All Apps and Add-ons

Splunk Add-on for Cisco Sourcefire: Why is the wrong year extracted from events?

ramsanga
Explorer

I am currently investigating issue where "_time" has year extracted from last octet from the syslog source IP. The logs are from sourcefire and sending syslog without year.

the raw syslog from two source DCs

Feb 4 10:52:22 SIGIPSDC01 ipsdetect00: [119:31:1] http_inspect: UNKNOWN METHOD [Impact: Currently Not Vulnerable] From "SIG-IPS-DE-01/SIGIPS3D01" at Wed Feb 4 10:52:21 2015 UTC [Classification: Unknown Traffic] [Priority: 3] {tcp} 203.19.222.5:26118->23.23.154.127:80

Feb 4 10:50:51 SIGIPSDC02 ipsdetect00: [119:31:1] http_inspect: UNKNOWN METHOD [Impact: Currently Not Vulnerable] From "SIG-IPS-DE-01/SIGIPS3D01" at Wed Feb 4 10:50:51 2015 UTC [Classification: Unknown Traffic] [Priority: 3] {tcp} 203.19.222.5:26118->23.23.154.127:80

These logs are forwarded by heavy forwarder and actual logs from search head looks like:

_time
2/4/14 9:50:51.000 PM Feb 4 21:50:51 10.0.12.14Feb 4 10:50:51 SIGIPSDC02 ipsdetect00: [119:31:1] http_inspect: UNKNOWN METHOD [Impact: Currently Not Vulnerable] From "SIG-IPS-DE-01/SIGIPS3D01" at Wed Feb 4 10:50:51 2015 UTC [Classification: Unknown Traffic] [Priority: 3] {tcp} 203.19.222.5:26118->23.23.154.127:80

_time
2/4/13 9:52:22.000 PM Feb 4 21:52:22 10.0.12.13 Feb 4 10:52:22 SIGIPSDC01 ipsdetect00: [119:31:1] http_inspect: UNKNOWN METHOD [Impact: Currently Not Vulnerable] From "SIG-IPS-DE-01/SIGIPS3D01" at Wed Feb 4 10:52:21 2015 UTC [Classification: Unknown Traffic] [Priority: 3] {tcp} 203.19.222.5:26118->23.23.154.127:80

This issue occurs only if last octet of source syslog device ends with .10 or .11 or .12 or .13 or .14 or .15

0 Karma

jaivijay_rio
Explorer

I have the exact same issue with cisco sourcefire logs where splunk assumes a random year on the timestamp.
There is no year information in the logs.

0 Karma

jcoates_splunk
Splunk Employee
Splunk Employee

We've filed a bug for this and will address.

jcoates_splunk
Splunk Employee
Splunk Employee

following up... this was discovered to be a Splunk configuration issue that we can't address well from within the Add-on, so we've updated the documentation: http://docs.splunk.com/Documentation/AddOns/latest/Sourcefire/Troubleshooting#Data_truncation_issues

0 Karma
Get Updates on the Splunk Community!

Splunk Lantern | Spotlight on Security: Adoption Motions, War Stories, and More

Splunk Lantern is a customer success center that provides advice from Splunk experts on valuable data ...

Splunk Cloud | Empowering Splunk Administrators with Admin Config Service (ACS)

Greetings, Splunk Cloud Admins and Splunk enthusiasts! The Admin Configuration Service (ACS) team is excited ...

Tech Talk | One Log to Rule Them All

One log to rule them all: how you can centralize your troubleshooting with Splunk logs We know how important ...