Suricata inline drops traffic but alerts are not always generated
-
We are still having problems with suricata after switching to inline mode with 3.1.2. ETPro rules is used and we have added all ETPro and Suricata categories to dropsid.conf. My understanding was that all drops would result in an alert in this mode but that seems incorrect. From time to time there is traffic being blocked to hosted services and checking the alert.log does not show the external/internal ip with the problem. Shutting down suricata on that interface solves the problem. Enable again and the problem is back. This is a big problem if we cant trust the alert log.
My question: Dropsid.conf is supposed to change alert rules to drop. Is there rules with noalert that has drop applied to it in this configuration?
Why isn't all dropped traffic generating an alert? Any idea what rules could be causing this? Is there an easy way to find noalert rules? -
Noone else running inline who has seen this? Adding a external problematic ip to the suppresslist solves the problem but why are there no alerts !? We notice blocks sometimes with FTP traffic, TLS traffic and HTTP traffic but no alerts when it happens. We got lots of alerts of other traffic so alerts i surely working and blocking things.
This is our dropsid.conf
# ET-Pro categories shown below will have all rules changed from "alert" to "drop" etpro-activex.rules,etpro-attack_response.rules,etpro-botcc.portgrouped.rules,etpro-botcc.rules,etpro-chat.rules,etpro-ciarmy.rules,etpro-compromised.rules,etpro-current_events.rules,etpro-deleted.rules,etpro-dns.rules,etpro-dos.rules,etpro-drop.rules,etpro-dshield.rules,etpro-exploit.rules,etpro-ftp.rules,etpro-icmp.rules,etpro-icmp_info.rules,etpro-imap.rules,etpro-inappropriate.rules,etpro-info.rules,etpro-malware.rules,etpro-misc.rules,etpro-mobile_malware.rules,etpro-netbios.rules,etpro-p2p.rules,etpro-policy.rules,etpro-pop3.rules,etpro-rbn-malvertisers.rules,etpro-rbn.rules,etpro-rpc.rules,etpro-scada.rules,etpro-scada_special.rules,etpro-scan.rules,etpro-shellcode.rules,etpro-smtp.rules,etpro-snmp.rules,etpro-sql.rules,etpro-telnet.rules,etpro-tftp.rules,etpro-tor.rules,etpro-trojan.rules,etpro-user_agents.rules,etpro-voip.rules,etpro-web_client.rules,etpro-web_server.rules,etpro-web_specific_apps.rules,etpro-worm.rules # Suricata built-in categories shown below will have all rules changed from "alert" to "drop" decoder-events.rules,dns-events.rules,http-events.rules,smtp-events.rules,tls-events.rules -
First after the update, I didn't noticed any alerts. But after discussing with @bmeeks, and after he fixed the pass list, the alerts started to appear, but now thing I noticed, they're are only 10 % of what they used to appear ( or to be triggered in the alerts tab or log), but I don't know if this is an issue. Maybe you can play some more with the pass lists…? And also try to read @bmeeks release notes, where he explains about the different behavior about pass lists for inline or legacy mode.
If you read it, then I don't have more insight
-
At this point we can reliably recreate blocked traffic that is dropped in suricata and when we disable a specific category it starts to flow. But there is still no alerts in the log for that traffic or from that IP. But trying to find the offending rule when there is no alert and 1000+ rules in the category is next to impossible.
Disable a category at a time to find the right one is not a nice way to find a offending rule.
The only thing I can think of is the rules with "noalert" in them. @BMeeks Could these rules be the culprit? Can we get dropsid to take these rules into account and not add a drop to them ?