Having upgraded a testing machine to Core Update 162 (testing), I observe Suricata to emit _only_ logspam galore: [root@maverick ~]# grep "SURICATA " /var/log/suricata/fast.log | cut -d\[ -f 3-5 | sort | uniq -c | sort -n -r 572047 1:2210059:1] SURICATA STREAM pkt seen on wrong thread [**] [Classification: (null)] 550 1:2260002:1] SURICATA Applayer Detect protocol only one direction [**] [Classification: Generic Protocol Command Decode] 359 1:2221020:1] SURICATA HTTP response field missing colon [**] [Classification: Generic Protocol Command Decode] 41 1:2210044:2] SURICATA STREAM Packet with invalid timestamp [**] [Classification: Generic Protocol Command Decode] 30 1:2221001:1] SURICATA HTTP gzip decompression failed [**] [Classification: Generic Protocol Command Decode] 5 1:2200074:2] SURICATA TCPv4 invalid checksum [**] [Classification: Generic Protocol Command Decode] None of these messages actually indicates a serious incident, and there seem to be no actual IDS hits. Aside from the latter, I am opening this so we can fix the logspam before releasing C162.
This comes from the rules that are shipped with suricata and which I think we should enable by default. They report any internal event. Why would we not be interested in that? Invalid checksums and otherwise bad packets are interesting, or not? > SURICATA STREAM pkt seen on wrong thread This seems to happen when your hardware doesn't support ntuple which will dramatically impact the performance of the IPS.
(In reply to Michael Tremer from comment #1) > This comes from the rules that are shipped with suricata and which I think > we should enable by default. They report any internal event. > > Why would we not be interested in that? Invalid checksums and otherwise bad > packets are interesting, or not? While I am tempted to say "yes" in the first moment, I think these are relatively minor events. In production, you won't go after a source emitting TCP packets with broken checksums, unless you have a near-perfect network. Therefore, I would vote for silencing these ("priority: 3") by default, so users can focus on more actionable IDS hits. > > SURICATA STREAM pkt seen on wrong thread > > This seems to happen when your hardware doesn't support ntuple which will > dramatically impact the performance of the IPS. True, my testing hardware features some cheap Realtek NICs. However, I think we should silence these log messages, since they do not carry any useful information, fill the logs, and make finding actual events pretty hard. Does this sound reasonable?
(In reply to Peter Müller from comment #2) > (In reply to Michael Tremer from comment #1) > > This comes from the rules that are shipped with suricata and which I think > > we should enable by default. They report any internal event. > > > > Why would we not be interested in that? Invalid checksums and otherwise bad > > packets are interesting, or not? > > While I am tempted to say "yes" in the first moment, I think these are > relatively minor events. In production, you won't go after a source emitting > TCP packets with broken checksums, unless you have a near-perfect network. > > Therefore, I would vote for silencing these ("priority: 3") by default, so > users can focus on more actionable IDS hits. Can we make this configurable? I consider these hints very useful for debugging, but we might not need all of them in production. Indeed. > > > SURICATA STREAM pkt seen on wrong thread > > > > This seems to happen when your hardware doesn't support ntuple which will > > dramatically impact the performance of the IPS. > > True, my testing hardware features some cheap Realtek NICs. However, I think > we should silence these log messages, since they do not carry any useful > information, fill the logs, and make finding actual events pretty hard. > > Does this sound reasonable? I didn't have anything that caused more than a few of these.
On the two systems I am testing (upgraded to 162) there are no IPS rule hits logged only the 'SURICATA STREAM' warnings. System1 NICs: Realtek and USB dongle pci: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 usb: D-Link Corp. (r8169, usbnet ax88179_178a) System2 NICs: Intel and Intel pci: Intel Corporation 82579LM Gigabit Network Connection (Lewisville) (rev 04) pci: Intel Corporation 82574L Gigabit Network Connection (e1000e, e1000e)
I suppose we can count this as a blocker for the release then. Thanks for your feedback.
Stefan want's to implement a solution using threshold.conf.
Patch has been send to the mailing list: https://patchwork.ipfire.org/project/ipfire/patch/20211208171805.309048-1-stefan.schantl@ipfire.org/
https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=65d5ec52ce288bdffd9e989581e3b638dc948210
This commit is now merged into master, hence setting to ON_QA...
https://blog.ipfire.org/post/ipfire-2-27-core-update-162-released