• Support
  • Forums
  • Blogs

Disable NIDS rules the correct way

BenGjerstadBenGjerstad

New Life Form
Hello,

For the last 4 months I have been clearing out the false positives from the NIDS rule set. I did this by writing new rules in local.rules and commenting out the old. After every update I would re-comment out the rules like this:

sed -i -r '/2015744/ s/[0-9]*/#&/' /etc/suricata/rules/emerging_pro-info.rules
sed -i -r '/2016847/ s/[0-9]*/#&/' /etc/suricata/rules/emerging_pro-info.rules
sed -i -r '/2014520/ s/[0-9]*/#&/' /etc/suricata/rules/emerging_pro-info.rules
sed -i -r '/2014473/ s/[0-9]*/#&/' /etc/suricata/rules/emerging_pro-info.rules

sed -i -r '/2002878/ s/[0-9]*/#&/' /etc/suricata/rules/emerging_pro-policy.rules
sed -i -r '/2000419/ s/[0-9]*/#&/' /etc/suricata/rules/emerging_pro-policy.rules
sed -i -r '/2014297/ s/[0-9]*/#&/' /etc/suricata/rules/emerging_pro-policy.rules
sed -i -r '/2010066/ s/[0-9]*/#&/' /etc/suricata/rules/emerging_pro-policy.rules
sed -i -r '/2006380/ s/[0-9]*/#&/' /etc/suricata/rules/emerging_pro-policy.rules
sed -i -r '/2012887/ s/[0-9]*/#&/' /etc/suricata/rules/emerging_pro-policy.rules
sed -i -r '/2019401/ s/[0-9]*/#&/' /etc/suricata/rules/emerging_pro-policy.rules

sed -i -r '/2812237/ s/[0-9]*/#&/' /etc/suricata/rules/emerging_pro-current_events.rules
sed -i -r '/2002157/ s/[0-9]*/#&/' /etc/suricata/rules/emerging_pro-chat.rules
sed -i -r '/2003068/ s/[0-9]*/#&/' /etc/suricata/rules/emerging_pro-scan.rules
service suricata restart

Now, that 5.4 has the Auto update feature, this is not possible to maintain because I would need to run this daily, after the updates are complete. I might be able to find a way to create a script to fire off to run these commands after the update is complete, but then I have to ask, what is the correct way to remove the false positives in the NIDS system? I thought that there was an ignore file where I could place the list of rules to ignore, but I can not find any documentation on that feature. 

I have messed around with the policy section before, but it never seems to work like I want. 

For example: 
sid 2812237
Our team goes to this a website every day for public record info. It is not a phishing site. The rule is too Generic to handle this one site. In fact that is the name of the rule "Generic Phish". I still want to know if other sites generate this rule so the fix was to add content:!"Host|3a 20|thesite.net|0d 0a|"; to the NIDS rule. 
I have never been able to make this work in Policy. I think I have to add the site as an external asset and then set the priority to 0, but it never works. Last time I messed with the Policy I noticed that the order matters- when I put the rule on top it will execute, but on the bottom it is ignored. So I guess only one policy will take effect and then no more rules are processed on that event. I am guessing one of the settings will allow more rules to be processed but I have no clue which one. The point is, Policy is not as simple as "process this rule but not if host is this domain". 

Also, I don't understand why there is a way to edit HIDS rules in the Web UI but not the NIDS rules. 

TL;DR
What is the correct way to handle NIDS rules? 

Share post:

Best Answer

Answers

  • Thank you for this info. I was afraid that was the answer. Since your post I have been creating polices to discard events. I found that in addition to what is posted, I need to also turn the logger to 'no' so that the event does not show up on the reports. I think that detail was why I thought that my rules were not working. 

    The directions listed will disable the whole rule....but they do not explain how to disable the rule for 1 host or for a range of hosts. I assume that I have to add the host as an asset and mark it as external. Is that correct?

    Also, I am still not sure why order of the policies is required. Currently, our first policy is to email our team when an account lockout happens. If this policy is not on top, then the email is never sent. What setting keeps the policy on top from sending down to the policies below it?

    Thank you. 
  • edited August 10
    Once a policy matches an event, it executes that policy therefore it doesn't continue to read additional policies. That is why you are seeing that behavior.  Nothing is keeping it from sending down except the fact that it has already matched a policy with that event and doesn't need to continue down the list of policies.  You cannot apply multiple policies to the same event.  You will need to figure out how you want your multiple policies to behave, but you should put the more specific policies at the top and the more generic policies at the bottom.  You can also direct a policy to a single IP address or group by choosing that asset.
  • This can be done be adding it to the threshold.config file.  This will keep the rule from every even firing for this signature for the specified range, keeping the events out of the raw logs as well.  Below is an example, you would have to either add the source IP or you could us destination IP/range as well.  You can find more information by just Googling Suricata Threshold options.  You can do a lot tuning using the threshold.config file.  AlienVault does not go into this aspect much but is something that should be part of every implementation tuning.  I have actually been working on a gui for this that runs inside an iframe on my dashboard.  So that it can be updated without having to console in.  Still a work in progress but something that some clients have found very helpful.

    suppress gen_id 1, sig_id 2812237, track by_src, ip 217.110.97.128/25


Sign In or Register to comment.