APT traffic blocked

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 :warning:

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?

In alert case it doesn’t block but just alert. Did you convert those rules to drop?

I agree that in IPS those rules do more harm but since converting rules from IDS to IPS mode is done on purpose I would recommend that the user decides what rules he wants active.

Have you looked at suricata-update? One of its features is using a configuration file to specify which rules should be disabled – which can be done on a per-file basis: https://suricata-update.readthedocs.io/en/latest/update.html#example-configuration-to-disable-rules-disable-conf

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:

config classification: policy-violation,Potential Corporate Privacy Violation,1

And APT traffic is in the “targeted-activity” category, described as “Targeted Malicious Activity was Detected” in classifications.conf and marked as Priority 1:

config classification: targeted-activity,Targeted Malicious Activity was Detected,1

Well that is something that’s better addressed to Proofpoint that provide the ET Ruleset. I don’t think it’s ideal to use that priority as an indicator for fail2ban rules.

To some extent the priorities are set by Suricata though, right?

Can I propose changing the alert level for the policy-violation category in /etc/suricata/classification.conf from 1 to 3, as none of the rules in that class represent actual threats?

Even just from the monitoring side of things, it’d be nice to not have harmless traffic marked as “Priority 1”.

I’ll rethink my setup a bit :+1:

Thanks for the feedback.

That’s based on https://rules.emergingthreats.net/open/suricata-5.0/classification.config so I would rather have it changed on ET side and we sync that again. But that’s open for discussion I would say, maybe others have thoughts as well about that :slight_smile:

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.