With a fresh install of Suricata and the default rules enabled, a large amount of traffic that is not a security concern is alerted/blocked, via the ET Open ruleset. Examples:
Rules in emerging-policy.rules, which the classification.conf file describes as “Potential Corporate Policy Violations”. This includes rules for non-security-related activity that a corporate employer might “potentially” not want employees to engage in, like connecting to Facebook:
alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"ET POLICY FACEBOOK user id in http_client_body, lookup with fb.com/profile.php?id="; flow:established,to_server; content:".facebook.com|0D 0A|"; http_header; content:"&__user="; http_client_body; threshold: type limit, count 1, seconds 600, track by_src; classtype:not-suspicious; sid:2014102; rev:3; metadata:created_at 2012_01_06, updated_at 2012_01_06;)
It also includes the following rule which will generate a Priority 1 alert on any APT traffic
alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"ET POLICY GNU/Linux APT User-Agent Outbound likely related to package management"; flow:established,to_server; http.user_agent; content:"APT-HTTP|2F|"; reference:url,help.ubuntu.com/community/AptGet/Howto; classtype:targeted-activity; sid:2013504; rev:6; metadata:created_at 2011_08_31, updated_at 2020_04_22;)
So Suricata will block APT traffic by default. On a Linux server this could prevent scheduled updates from installing security patches.
There’s also a number of other rules categories that alert/block traffic that is not at all security related:
emerging-chat.rules - use of chat clients
emerging-games.rules - online games, World of Warcraft traffic etc
emerging-inappropriate.rules - porn sites etc
emerging-p2p.rules - general filesharing apps
Would it be sensible to have the above rules (and emerging-policy.rules) disabled by default, so that they are opt-in as opposed to opt-out?
Ah okay! I haven’t set up drop rules yet. I’m actually experimenting with a setup in IDS mode where alerts are monitored with ELK and alert entries in fast.log are processed by fail2ban rules, categorised by priority. Priority 1 alerts get an immediate ban and Priority 2 alerts get a ban after multiple alerts in a given time window, and Priority 3 alerts are ignored.
I was just surprised that connections to Facebook and other non-security rules in the “policy-violation” category are given the same “priority” as signatures for known trojans:
With the deprecation of unified2, and the upcoming support for suricata-update to merge classification.config from remote rulesets, I think Suricata could soon only ship the classifications it uses in the engine provided rules.