The rule files contain disabled rules starting with “#”: #alert tcp $EXTERNAL_NET …
those are rules usually giving false positive alerts and I prefer not to have them active.
However suricata-update command is adding also those disabled rules in suricata.rules file.
Is there a way that suricata-update will ignore those rules?
Are you able to provide an example of a rule, or the SID if a public rule that this is happening to? Rules may get enabled due to flowbit dependency resolution, however, such rules should also get “noalert” added to them.
For example rule 2100408 - located at emerging-icmp_info.rules with definition: #alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:“GPL ICMP_INFO Echo Reply”; icode:0; itype:0; classtype:misc-activity; sid:2100408; rev:6;metadata:created_at 2010_09_23, updated_at 201
0_09_23;)
In addition, putting 2100408 in the disable.conf does not disable this rule and my logs are flooded with it and there is no way to disable it.
This should stay disabled by default. Do you have any enable.conf settings that might be turning this rule on? When running suricata-update look at the first bit of output. You’ll see something like:
Yes the rule is loaded from emerging-icmp_info.rules which is ok.
The problem is that it is commented(i.e. starts with
“#alert” and not “alert”) but still suricata-update is enabling it.
Does suricata-update distinguish between commented and not commented rules in the rule files?
What I’m getting at is maybe there is a rule file, perhaps in /etc/suricata/rules or something that is getting picked up where this rule exists in a non-commented out state, so I’m trying to help determine why.
On a fresh install, without any configuration files this is what I get some suricata-update:
Yes, you are right, I opened enable.conf on other machine. Now on the correct machine I see it contains group:emerging* which explains everything.
Thank you very much for the fast answers and detailed explanations.