Home
Help
Search
Login
Register
OPNsense Forum
»
English Forums
»
Intrusion Detection and Prevention
»
What determines which rules are enabled
« previous
next »
Print
Pages: [
1
]
Author
Topic: What determines which rules are enabled (Read 6198 times)
networkguy
Newbie
Posts: 12
Karma: 0
What determines which rules are enabled
«
on:
January 25, 2018, 06:30:32 pm »
I added snort rules into the IDS and have enabled any of the ET or snort VRT groups that contain malware, virus, trojan, or anything else that sounds like it is something i wouldn't want running on my network. When i went to the rules and do a search on malware i find that of the groups i enabled only some rules are enabled and not all of them.
What dictates which rules are enabled?
Is the best approach to just enable the group and not the individual rules that are shown disabled?
I am currently not blocking and just running as an IDS. Once I have removed the false alarm rules I will probably convert to an IPS. Right now all the alarms show as alerts. Do these all get changed to drop once I change to IPS or do i need to go and change the rule behavior for each rule?
Lastly, when an ip gets blocked does that get added to a group in the firewall or is it just located under the alerts section of the IDS. Does the clear log button on the alert tab clear the block for the ip and if so how do you clear a block for one particular ip instead of the entire log file?
Logged
SecAficionado
Newbie
Posts: 42
Karma: 4
Re: What determines which rules are enabled
«
Reply #1 on:
January 27, 2018, 11:43:58 pm »
Hi networkguy,
TL;DR only the most generic and most critical rules are turned on by default.
Not all rules are enabled by default because, as you can imagine, running all of them all the time would create a major bottleneck on your network, or require very expensive hardware to check for things that are very unlikely to occur. This philosophy is also applied at the category level, and when VRT publishes the rules, they only enable the "hottest" rules at the time. The assumption is that each network admin will decide how aggressive or hands-off they want to be with their traffic.
Unfortunately, the above also means that managing the rules is almost a full time job, even for a small network. For example, there are rules to cover recent exploits that are critical for some customers, but they are "too noisy" for others. These rules are usually included but turned off, with the idea that those whose traffic or application is so important, will turn those rules on, no matter how many false positives they get. Conversely, for the average network, the same rule may block so much legitimate traffic that it is not worth enabling it. Depending on how important some rules are, they may get tweaked a few times to reduce the noise, to the point they may get turned on by default in future releases.
So, there is no easy answer. Each rule can be very important for a particular network, or part of a network, and it can also be an unnecessary hassle for other networks. There is no universal way to determine one rule's usefulness, only your priorities and goals as network administrator.
The only way you can decide which rules to turn on or off is to follow Snort's blog, and their users mailing list in order to read the general discussions about rules and why they are introduced. And ultimately, turning each rule on in your own network and seeing how it works. If you find that a rule causes more trouble than it's worth, turn it off, or tweak it to your own needs (except for the SO rules, which Suricata does not use, they are open source).
Sorry, I wish there was an easy/better answer, but this is the only way to manage IDS/IPS rules, by actively configuring them, checking logs, and analyzing your traffic regularly.
On the flip side, once you get a handle on your network's needs, the job gets a bit easier, because you know what you are looking for.
Logged
Print
Pages: [
1
]
« previous
next »
OPNsense Forum
»
English Forums
»
Intrusion Detection and Prevention
»
What determines which rules are enabled