We are using Suricata and all appears to be good, except there appears to be a large number of alerts where 95% of the events appear to be pretty benign, for example “dns requests to .cloud” domains, etc. Can anyone offer any advice on how to tune these alerts to reduce some of the more low level signatures?
You can deal with this in multiple ways, including:
- categorizing those “less critical” rules as informational that no one needs to act on them but rather use them to assist in the investigations.
- disabling those rules completely.
- reducing non relevant alerts using bypass rules, rules transformations, thresholds…etc.
All of the above depends on what you are protecting, if it is a tightly controlled server farm then those alerts are interesting, but not as much if the network is user’s workstations browsing internet.
Thank you for your reply. I guess I am looking for an approach more than anything… for example we have been disabling those rules manually but its not really manageable due to the quantity… I assume recategorization would be much the same process?
The suricata rulesets already have builtin categories (aka: calsstype), you can use this to decide what to remove, also you can use other metadata in the rules to do the same, however, if you are using plain text files to manage the rules, that would be a bit hard.
I believed it is better to think of rules tuning to be a continuous process without a finishing line rather than a one time job, this is because both the rules and networks are constantly evolving.
Full disclosure - I work on the Emerging Threats team for Proofpoint.
I love the use of “benign” here. Big difference between a benign alert and a False Positive (FP).
I like to think of rules in a few different ways.
Alerting Rules
Some rules are good for having someone look at the event, apply context and determine if an “incident” has happened. Think categories like MALWARE, EXPLOIT, ATTACK RESPONSE. These rules are largely high confidence and should be reviewed. There will be False Positives or in some cases benign alerts, but should be few enough to manage, and where real FPs happen please provide feedback and let the rule authors know.
Example: If you get an alert saying RecordBreaker in the msg, chances are high you’ve got that in your environment.
Hunting
Some rules are good for looking at “odd” things. These include the HUNTING category. These “odd” things that might be of interest, but will likely take more time to investigate, heck they might be normal in your environment and need tuned
Example: assume a single host has been trigging a rule. After review, the “odd” thing occurring there is due to an authorized software. In this case, I’d either add a suppression or add a modification to the rule which negates that single host. (Keep in mind you can create custom host variables in the config, and use them in rules too).
Informational Rules
Other alerts are good for just general network knowledge and "retrospective analysis. This includes the INFO and POLICY categories. These alerts can let you know things that TeamViewer activity is happening, or based on the UA, that must be an Ubuntu box, or that your domain controller is running out of date Java running on that machine (idk why you’d have Java on a DC, but it’s just an example). Or if you find out that Qakbot is running on your environment, you might be able to use some of those POLICY/INFO rules to see what alerts triggered and how you can pivot off those alerts to find more infected hosts, etc.
In some cases, I use INFO rule as hunting. A great example I’ve been working with recently are DYNAMIC_DNS signatures. There have been enough APT based malware that uses free/public dynaminc dns domains for C2 severs, that I really started to dig into them. You’ll find users checking out home cameras, setting up their own VPNs, and even APT malware.
These rules, I generally don’t want a human to review them every time they occur, but I might want them logged so they are there should I ever need them.
I use disabling a rule as a last resort, and instead would much rather tune them or log them all while keeping them out of a human’s process. Maybe they are good for a weekly review or some automated statistically analysis that can alert you when things go “out of baseline”.
If you happen to find a rule that needs disabled because it’s really an FP. Please, reach out to the signature authors and let them know! Everyone can benefit that way. In some cases we might just suggest a local tune, but in others it might make sense for a global tune.
If you’re working with ET rules, you can submit feedback on our discourse instance or via our feedback portal.
I agree with this 100%. At a previous role we reviewed each new rule, modifications, disable of a rule and determined on which sensors to have it enabled, disabled, or locally modify as needed. This was a daily process.
I recently gave a talk on this subject at Suricon 2022! Check it out on the youtube. I also go over what I call “High Level Ruleset Flows”. I suggest matching rulesets to the “high level flow” and to a lessor degree, even curating your traffic with packet brokers, bpf filters, etc to allow for a tuned ruleset. There is no need to watch for exploits impacting WordPress when all you’re doing is monitoring traffic of network users going to the internet. Unless you care about “outbound” exploit attempts, which could be an entire conversation in itself.
2 Likes
Great, thanks for the reply… I think there is a lot to unpack here and will be a gradual journey, but for a quick win I think I would like to start by removing some of the classifications we are not interested in. What is the best way to do this? e.g. can we do it from the classification.config or do we need to hit the actual rules?
1 Like
is it possible to supress classifications in disable.conf ??
#config classification: not-suspicious,Not Suspicious Traffic,3
#config classification: unknown,Unknown Traffic,3
#config classification: non-standard-protocol,Detection of a non-standard protocol or event,2
#config classification: protocol-command-decode,Generic Protocol Command Decode,3
#config classification: misc-activity,Misc activity,3
#config classification: misc-attack,Misc Attack,2
#config classification: icmp-event,Generic ICMP event,3
#config classification: external-ip-check,Device Retrieving External IP Address Detected,2
This is with suricata-update correct?
Hi Lewis,
Yup you should be able to put an entry like this in your disable.conf
re:classtype:protocol-command-decode
You can then check your ruleset in /var/lib/suricata/rules/suricata.rules assuming thats where you configured your rules.
You can see a few other options at 7.1. Rule Management with Suricata-Update — Suricata 6.0.9 documentation
thank you… will it disable rules that were previously enabled?
Hi Lewis,
After you make that addition to the disable.conf file and run suricata-update it will disable all rules that match that string. The only way to override that is to place the specific rule SID in the enable.conf file.
What I usually do in these cases is pick a signature that matches what I want to disable. I look at the current suricata rules and check that its current enabled. Add the regex entry to the disable file, run suricata-update then check the rules file and that entry should now be commented out with a pound sign.
didnt seem to work… I put the following in disable.conf
re:“not-suspicious”
re:“Not Suspicious Traffic”
re:“unknown”
re:“Unknown Traffic”
re:“bad-unknown”
re:“Potentially Bad Traffic”
re:“rpc-portmap-decode”
re:“Decode of an RPC Query”
re:“shellcode-detect”
re:“Executable code was detected”
re:“tcp-connection”
re:“A TCP connection was detected”
re:“non-standard-protocol”
re:“Detection of a non-standard protocol or event”
re:“protocol-command-decode”
re:“Generic Protocol Command Decode”
re:“misc-activity”
re:“Misc activity”
re:“misc-attack”
re:“Misc Attack”
re:“icmp-event”
re:“Generic ICMP event”
re:“policy-violation”
re:“Potential Corporate Privacy Violation”
re:“external-ip-check”
re:“Device Retrieving External IP Address Detected”
but after running suricata-update I still see rules in suricata.rules that have these strings?
I tried that before, same issue.
Hi Lewis,
Three things to try:
- Check that you don’t have any of the rules you are looking to disable in your enable.conf
- Remove the double quotes. Not sure if you included them for making a post here, but the example I posted above is exactly how the entry shows in my disable.conf.
So in your disable.conf you would have:
re:classtype:not-suspicious
re:classtype:Not Suspicious Traffic
re:classtype:unknown
re:classtype:Unknown Traffic
re:classtype:bad-unknown
re:classtype:Potentially Bad Traffic
re:classtype:rpc-portmap-decode
re:classtype:Decode of an RPC Query
re:classtype:shellcode-detect
re:classtype:Executable code was detected
re:classtype:tcp-connection
re:classtype:A TCP connection was detected
re:classtype:non-standard-protocol
re:classtype:Detection of a non-standard protocol or event
re:classtype:protocol-command-decode
re:classtype:Generic Protocol Command Decode
re:classtype:misc-activity
re:classtype:Misc activity
re:classtype:misc-attack
re:classtype:Misc Attack
re:classtype:icmp-event
re:classtype:Generic ICMP event
re:classtype:policy-violation
re:classtype:Potential Corporate Privacy Violation
re:classtype:external-ip-check
re:classtype:Device Retrieving External IP Address Detected
- Try adding each entry one by one and re-running suricata-update. Its possible the double quotes are needed for some entries with spaces but it may be interfering with others that don’t need the quotes.
Thank you for your reply.
- I dont have an enable.conf
- removed quotes but and it is partially working… I see 8594 rules disabled however if I look at suricata.rules and grep for “not-suspicious” most are disabled but there are a few such as
alert tcp $EXTERNAL_NET $HTTP_PORTS → $HOME_NET any (msg:“ET WEB_CLIENT Oracle Java 6 Object Tag launchjnlp docbase Parameters Flowbits Set”; flow:to_client,established; content:“NtDllImageBase|22|”; nocase; content:“getModuleInfos|28|”; distance:0; content:“|27|ntdll.dll|27|”; nocase; within:50; flowbits:set,NtDll.ImageBase.Module.Called; flowbits:noalert; classtype:not-suspicious; sid:2012085; rev:2; metadata:affected_product Web_Browsers, affected_product Web_Browser_Plugins, attack_target Client_Endpoint, created_at 2010_12_22, deployment Perimeter, signature_severity Major, tag Web_Client_Attacks, updated_at 2016_07_01;)
which are not.
In this particular case, note the “flowbits:set,NtDll.ImageBase.Module.Called;” this rule is a dependency of rules that use this flowbit via isset (sid 2012100). suricata-update will re-enable disabled flowbit rules to ensure a non “broken” group of flowbit rules.
1 Like
got it, thank you very much for the explanation.
1 Like