Looking for some guidance on Sourcefire Parsing

Hey Logstash Pros,

We have found an interesting issue when ingesting our Sourcefire logs into Logstash. When we ingest the syslog message, Kibana adds a field "Error_Processing_Payload" which replicates the 'Message' field and have not been able to find anything during research. (See attached screenshot).

We were able to capture the TCPDump and it doesn't seem to be the Sourcefire in this instance.

cpdump: listening on ens160, link-type EN10MB (Ethernet), capture size 262144 bytes
19:43:27.346352 IP (tos 0x0, ttl 63, id 36430, offset 0, flags [DF], proto UDP (17), length 349)
X.X.X.X.XXXX > X.X.X.X.XXXX: [udp sum ok] SYSLOG, length: 321
Facility console (14), Severity info (6)
Msg: Mar 19 19:43:27 XXXXX XXXXX: [1:34061:6] "SERVER-IIS Microsoft IIS Range header integer overflow attempt" [Impact: Potentially Vulnerable] From "XXX-XXXXX" at Thu Mar 19 19:43:25 2020 UTC [Classification: Attempted Denial of Service] [Priority: 2] {tcp} X.X.X.X.XXXX (netherlands)->X.X.X.X:XXXX (unknown)
0x0000: 3c31 3138 3e4d 6172 2031 3920 3139 3a34
0x0010: 333a 3237 2050 5244 4954 4d32 3420 5346
0x0020: 494d 533a 205b 313a 3334 3036 313a 365d
0x0030: 2022 5345 5256 4552 2d49 4953 204d 6963
0x0040: 726f 736f 6674 2049 4953 2052 616e 6765
0x0050: 2068 6561 6465 7220 696e 7465 6765 7220
0x0060: 6f76 6572 666c 6f77 2061 7474 656d 7074
0x0070: 2220 5b49 6d70 6163 743a 2050 6f74 656e
0x0080: 7469 616c 6c79 2056 756c 6e65 7261 626c
0x0090: 655d 2046 726f 6d20 2243 4e58 2d53 4652
0x00a0: 3122 2061 7420 5468 7520 4d61 7220 3139
0x00b0: 2031 393a 3433 3a32 3520 3230 3230 2055
0x00c0: 5443 205b 436c 6173 7369 6669 6361 7469
0x00d0: 6f6e 3a20 4174 7465 6d70 7465 6420 4465
0x00e0: 6e69 616c 206f 6620 5365 7276 6963 655d
0x00f0: 205b 5072 696f 7269 7479 3a20 325d 207b
0x0100: 7463 707d 2031 3639 2e31 3937 2e31 3038
0x0110: 2e36 3a33 3334 3332 2028 6e65 7468 6572
0x0120: 6c61 6e64 7329 2d3e 3130 2e31 3230 2e33
0x0130: 312e 3636 3a38 3020 2875 6e6b 6e6f 776e
0x0140: 29
E..].N@.?..0
dF*
d...m...IM.<118>Mar 19 19:43:27 XXXXXX SFIMS: [1:34061:6] "SERVER-IIS Microsoft IIS Range header integer overflow attempt" [Impact: Potentially Vulnerable] From "XXX-XXXX" at Thu Mar 19 19:43:25 2020 UTC [Classification: Attempted Denial of Service] [Priority: 2] {tcp} X.X.X.X:XXXX (netherlands)->X.X.X.X:XXXX (unknown)

Could anyone help shed some light on this situation for us?

Thanks.

What does the configuration of your logstash pipeline look like?

Hey Badger,
Our Pipelines specific to Sourcefire are as follows:

  • Preprocess syslog
    if [syslog-sourceip] == "x.x.x.x" {
    mutate {
    add_tag => [ "cisco" ]
    add_field => { "type" => "sourcefire" }
    }
    }

  • Then moves on to a modified 6202_cisco_firewall.conf

filter {
if "cisco" in [tags] {
syslog_pri {}
grok {
patterns_dir => ["/usr/share/logstash/patterns"]
match => {"message" => ["%{CISCOFW106100}",
"%{CISCOFW313001_313004_313008}",
"%{CISCOFW710001_710002_710003_710005_710006}",
"%{CISCOFW113019}",
"%{CISCOFW113004}",
"%{CISCOFW106014}",
"%{CISCOFW113005}",
"%{CISCOFW113039}",
"%{CISCOFW106001}",
"%{CISCOFW106016}",
"%{CISCOFW106006_106007_106010}",
"%{CISCOFW713048}",
"%{CISCOFW106017}",
"%{SOURCEFIRE}"
]
}
}
mutate { add_tag => "conf_file_6202" }
}

  • Thirdly we have 9702_output_cisco.conf

output {
if "cisco" in [tags] {

stdout { codec => rubydebug }

elasticsearch {
  hosts => elasticsearch
  index => "logstash-cisco-%{+YYYY.MM.dd}"
  template_name => "logstash-cisco"
  template => "/logstash-cisco-template.json"
  template_overwrite => true
}

}
}

Our grok pattern looks like this

Sourcefire Firewall Logs ==

DATESTAMP_SOURCEFIRE %{DAY} %{MONTH} %{MONTHDAY} %{TIME} %{YEAR} %{TZ}
SOURCEFIRE [%{INT:ids_gid}:%{INT:ids_sid}:%{INT:ids_rev}]\s%{DATA:ids_message}\s[Impact:\s%{DATA:ids_impact}]\sFrom\s"%{DATA:ids_node}"\sat\s%{DATESTAMP_SOURCEFIRE:ids_timestamp}\s[Classification:\s%{DATA:ids_classification}]\s[Priority:\s%{INT:ids_priority}]\s{%{DATA:ids_protocol}}\s%{IPV4:ids_src_ip}:%{POSINT:ids_src_port}.->%{IPV4:ids_dst_ip}:%{POSINT:ids_dst_port}.
#== End Sourcefire ==

Hope that's what you were asking for

I can only suggest that there might be an issue with one of the grok patterns. I would try removing all except the one that you think matches this message and see if the duplicate field goes away. If it does then work through the patterns until you find the one that causes the issue.

Will do -I will post with my findings as I have yet to see this elsewhere.

Hey @Badger,
We tried removing the entire grok and replacing it with %{GREEDYDATA:Message} - This produced the same issue
We also removed the {SOURCEFIRE} from 6202_Cisco_Firewall.conf - This produced the same result.
If we remove the pattern from the 6202 config, it should produce an entirely different output which leads me to believe it is something other than grok.
Would you have any other ideas?

Thanks.

No, I do not.