Our central OPNsense does IPS. During the Log4Shell analysis I realized that some JSON datagrams are not received by the syslog server (I guess to large for UDP, will try it with TCP).
But, the other point creates more concerns: if external hosts send Log4Shell http requests to my targets, Suricata finds the patterns (great) and block the requests. The OPNsense creates a syslog message with the malicious request for Splunk/Graylog. The outgoing syslog message is blocked, since Suricata finds the pattern again and blocks the request, which generates a new syslog message.
We have also a Reverse Proxy in the DMZ. The unencrypted local requests are blocked by Suricata (also great). If it catches log4shell https requests and puts it into the access log, the Splunk Forwarder sends the request to Splunk. Suricata finds the patterns, blocks them and generate a new syslog message. 93% of all log4shell connections are done by OPNsense->Syslog or RP->Syslog.
Isn't the pattern "1 request yields to 3 requests" a melting pot for DoS scenarios.
Don't get me wrong, Suricata does its job very well, but I have to find a way to exclude/trust connections. How do you solve this problem at your side?
I've had to add a pass rule from the IPS internal interface to my syslog receiver because of this.