Disable default suricata rules?

Is there a way to disable the default suricata rules? The ones found in /usr/share/suricata/rules/ ?

I found suricata-used-rulesfiles.yaml, but it very clearly says “#Autogenerated file. Any custom changes will be overwritten!”

Thanks
-Dan

Can’t you find the rule.
When you use the customize rule set
On the IPS page

Not as far as I can tell. I can only find the 3rd party rules in the UI under “customize ruleset”, but not the default ones.

If there are ‘default rules’ and the config file is ‘autogenerated’, there should be a settings file ( under directory /var/ipfire ) which is the source for the generation.

The IPS logs helped me find the rules that where blocking services at home.

If I may ask what you IPS log looks like?

If there are ‘default rules’ and the config file is ‘autogenerated’, there should be a settings file ( under directory /var/ipfire ) which is the source for the generation.

Not that I can find. I see a file called “subscripted-used-rulesfiles” in /var/ipfire/suricata, but it doesn’t have any of the default rules listed (only the 3rd party rules). Is there another file that I’m missing?

(In the screenshot from hvacguy, I don’t see any default rules listed either – only “emerging-*” rulesets)

Here’s an example:

Date: 06/23 14:04:01 Name: SURICATA HTTP Request unrecognized authorization method
Priority: 3 Type: Generic Protocol Command Decode
IP info: x.x.x.x:50434 → y.y.y.y:80
References: none found SID: 2221034

As far as I can tell, this is triggered from a default suricata rule – which I would like to disable.

What core version are you on?

I see this about the IPS.

Hi there,
dzenc beat me to it. I too am wondering how to disable the default suricata rule sets. Normally I run Emergingthreats.net Community Rules, but for debugging purposes, I am currently running no rule sets, and the WUI complains about this. However, the IPS logs are filling up fast. All logged events look like this:
image

I have also verified that the change in behavior of suricata occurred in the upgrade from CU 167 to 168. No SURICATA IKEv2 (and the like) events prior to CU168 update. The update from 167 to 168 seems to have awaken the suricata baked in rule-sets. If one looks at some of the documentation, such as https://tools.emergingthreats.net/docs/ETPro%20Rule%20Categories.pdf which I found in the IPfire IPS wiki, one can find that a number of ET rules sets are by default included in suricata 5.0 or later. Some of these are Adware-PUP, Coinmining, Current Events and Malware to name a few.

I have not had time to fully decipher where everything is but here are a few places to begin looking:
/usr/share/suricata/
/usr/share/suricata/rules/
/etc/suricata/
/var/ipfire/suricata

Based on a examination of these directories, it would appear that suricata has more rule set built in than just the ET rule sets. Hopefully we can figure out how to turn off some of these. My plan is to dig into this on the weekend. When my android phone is on the net work, if fills up the IPS log to the point of making the log useless.

PZ

3 Likes

The IPFire ids-functions.pl has a code section that searches through the application layer protocols being used in your IPFire and looks for the related rulesets for that protocol in /usr/share/suricata/rules/

These are then included into the /var/ipfire/suricata/suricata-used-rulesfiles.yaml file. In my case two of the default rules are not included, presumably because those application layer protocols are not being used.

The IPFire code deciding which of these application layer protocol default rules should be included is in lines 1457 to 1483 in /var/ipfire/ids-functions.pl or you can find the file in the IPFire git repository in the tree under config/cfgroot/ids-functions.pl

My view would be to be careful about deciding to remove some of the Application Layer Protocol checks that have been put in place by the IPFire developers. If you have a lot of errors in place then maybe you have some applications that are doing incorrect things and that need to be fixed. Or there could be false positives, which then should be fixed.

If you have data showing that these are incorrect errors then you could raise a bug about them.

5 Likes

Thanks for the detailed info. I was able to review the code and decided that the simplest answer was to remove/rename the offending rules files in /usr/share/suricata/rules and force the yaml to be rebuilt. But there really needs to be a GUI method to do this, because this is now broken in 168.

To respond to your comment about leaving them alone: I don’t know if they are valid or invalid rules but, they are all trivial things like “SURICATA HTTP Request unrecognized authorization method” spewing out constantly and filling the logs. There’s nothing actionable from this message in terms of intrusion prevention (it’s more likely an imperfect use of the HTTP protocol than an attempted intrusion) and, worse, it’s filling up my IDS logs to the point that actually useful information is not visible.

Before core 168, my IDS logs would indicate an occasional real attempted attack - maybe once or twice a day - with an actual attack signature triggered. This was useful information and I could see the IDS was working properly. Now I can not locate these attacks because my logs are filled with trivial protocol errors, obscuring the real and useful information. It’s fine if this is the default behavior (no, really it’s not, but that’s for others to decide), but IMHO, there NEEDS to be a way to disable these rules individually or collectively so that the important events are clearly visible.

Again, this is new to 168, so something broke that used to work.

1 Like

I don’t think CU 168 broke something in IPS. IPS just flags more illegal proceedings of the smartphone OS.
With filling up the logs, you are right. But this should be discussed more deeply. As you found the rules are not false, but are trigged by faulty devices.
To manage this per GUI, it would be nice to group these annoying cases. These group(s) could be enabled or disabled. Not all users go such deep in analysis like you, but should be able to manage these messages also.
This needs to be documented in wiki also. This possible for each member of the IPFire community with knowledge about the topic.

BTW: these changes were introduced by core developpers. These can be reached for discussion mainly in the development mailing list.

3 Likes

I have the same problem as dzenc. The log is flooded with legitimate connections, all with priority 3. Mail-traffic, kerberos, dns-queries, printer-queries, etc.

I’m not really familiar with suricata now, but is it possible, that priority 3 means just monitoring, because this connections are not blocked. All real attack-rules (Emergingthreatst Community Rules) are logged with priority 2. So wouldn’t it be enough, if we could set which priority should be logged?

1 Like

Hi all,

thanks for raising this issue and the lively discussion.

To be honest, the value of Suricata’s own IPS rules is rather limited to me as well. Even very small networks are already way too noisy to investigate on IPS hits generated by those.

@stevee: What is your opinion on that front? Do you see a better balance between making use of Suricata’s own rules and keeping the IPS logs relevant to NOC/SOC/IZ security folks?

Thanks, and best regards,
Peter Müller

1 Like