Hi,
the CEF spec found here: https://community.microfocus.com/cfs-file/__key/communityserver-wikis-components-files/00-00-00-00-23/3731.CommonEventFormatV25.pdf
it says:
CEF uses syslog as a transport mechanism. It uses the following format, comprised of a syslog
prefix, a header and an extension, as shown below:
Jan 18 11:07:53 host CEF:Version|Device Vendor|Device Product|Device
Version|Device Event Class ID|Name|Severity|[Extension]
The CEF:Version portion of the message is a mandatory header. The remainder of the message
is formatted using fields delimited by a pipe ("|") character. All of these remaining fields should be
present and are defined under “Header Field Definitions” on the next page.
so, everything between the version and extensions is not mandatory.
However, when I read the code (not a golang expert) and how I understand it, the decode_cef preprocessor seems to expect them all to exist, and that's also what I see from the results I get.
I've a problem parsing CEF2 messages from sentinelone:
My filebeat is setup like this:
- type: tcp
enabled: true
max_message_size: 10MiB
host: "0.0.0.0:8001"
ssl:
enabled: true
certificate: /etc/filebeat/cert.crt
key: /etc/filebeat/key.key
processors:
- rename:
fields:
- {from: "message", to: "event.original"}
- decode_cef:
field: event.original
running filebeat in debug, I see the following as part of event.original:
<14>2021-12-13 12:21:29,646 sentinel - CEF:2|SentinelOne|Mgmt|suser=foo@bar.com|rt=2021-12-13 12:21:22.039732|deviceAddress=1.2.3.4|deviceHostFqdn=somehost.sentinelone.net
The parsed data that filebeat then looks like:
"cef": {
"device": {
"vendor": "SentinelOne",
"product": "Mgmt",
"version": "suser=foo@bar.com",
"event_class_id": "rt=2021-12-13 12:21:22.039732"
},
"name": "deviceAddress=1.2.3.4",
"version": "2"
}
I'm currently with filebeat 7.15.1.
Do I understand something wrong with the CEF SPEC, and actually S1 send bogus CEF messages? Maybe there's an option to get filebeat to be not so strictly expecting all fields?
Sebastian