I am using the Sophos integration to read UTM logs from a local file. Each of the log messages has a format similar to the following examples. It's important to note that utm-2 (the firewall's hostname) is included in the header of every message.
2021:07:27-20:50:52 utm-2 ulogd[27536]: <payload>
2021:07:27-20:50:52 utm-2 httpproxy[18317]: <payload>
2021:07:27-20:51:02 utm-2 dhcpd: <payload>
When these messages are ingested into Elasticsearch, the field event.code contains utm-2 ulogd, rather than the expected ulogd. Further, the expected source/destination/network fields are not filled in, likely because the message ID was parsed incorrectly.
Examining the source code of the pipeline, the likely culprit is Line 2722, which was intended to match line headers that do not contain a hostname. However, the pattern hdr1 is more general than hdr2 and will always match my log lines, even though hdr2 is a more accurate match.
I am using the Sophos integration to read UTM logs from a local file. Each of the log messages has a format similar to the following examples. It's important to note that
utm-2(the firewall's hostname) is included in the header of every message.When these messages are ingested into Elasticsearch, the field
event.codecontainsutm-2 ulogd, rather than the expectedulogd. Further, the expected source/destination/network fields are not filled in, likely because the message ID was parsed incorrectly.Examining the source code of the pipeline, the likely culprit is Line 2722, which was intended to match line headers that do not contain a hostname. However, the pattern
hdr1is more general thanhdr2and will always match my log lines, even thoughhdr2is a more accurate match.