Suricata IPS blocks SSL traffic without alert log
-
Hi. I found that suricata in IPS inline mode blocks SSL traffic with certificates signed by corporate internal CA. But there are no alert events regarding blocking.
Empirically i found that these VRT rules affect SSL traffic.31484 SERVER-OTHER OpenSSL TLSv1.2 ChangeCipherSpec man-in-the-middle exploitation attempt
31483 SERVER-OTHER OpenSSL TLSv1.1 ChangeCipherSpec man-in-the-middle exploitation attempt
31482 SERVER-OTHER OpenSSL TLSv1.0 ChangeCipherSpec man-in-the-middle exploitation attempt
31481 SERVER-OTHER OpenSSL SSL ChangeCipherSpec man-in-the-middle exploitation attempt2.3.2-RELEASE-p1
suricata security 3.0_9Are anybody have the same issue?
-
As I understand there are "flowbits:noalert;" so these rules don't generate alerts.
-
Im seeing this also since moving to inline mode. SSL/TLS traffic is being blocked but nothing in alert log. Im running ET Pro rules. Stopping Suricata on wan solves it. It breaks connections to emailservers among other things. Outlook hangs on start.
Any idea on where to look??
-
use this regexp in dropsid management to eneble drop for all rules except "noalert flowbit".
pcre:^.?.?alert((?!flowbits\x3a\s*?noalert).)+.(sid\x3a\s*?.?.?.?.?.?.?;).+$
-
this rules (noalert) used for marking traffic only and shouldn't blocked.
-
Just to clarify, does inline mode refer to promiscuous mode?
If so, does that mean in promiscuous mode - even with squid properly intercepting SSL traffic - suricata will not be able to inspect the encrypted data?
Is this and will this always be the nature of promiscuous mode? Does suricata have to be inline after squid somehow?
-
Not exactly. Inline refers to the packets' flow (working inline vs. working on a copy of a packet).
-
So if Suricata is working inline. Is that inline before or after squid would be touching the packets?
-
Not exactly sure what's the question here, obviously depends on the interface. If you have FPs, disable the offending rules.