Overlap Running Multiple Rule Sets?
-
Hi all,
I've got a quick question running multiple rule sets on an IDS/IPS. Assuming one has Snort VRT, Snort Community, and ET Open rules configured, is there a fair a bit of overlap expected? For example, the Snort VRT and ET Open rule sets both have multiple rules for trojan detection - would these overlap (i.e. Snort could check the same rule twice)? Since the free version of the Snort VRT rules is delayed by 30 days I wasn't quite sure how much overlap there might be. Would it still make sense to run both? Thanks in advance for your thoughts and insight.
-
If you have a Snort Subscriber Rules account (either free or paid), then you do not need the Snort GPLv2 Community Rules. Those rules are already included in the Snort Subscriber Rules package.
As for overlap between Emerging Threats and Snort, yes there is considerable overlap. If your firewall is cramped on RAM, I would run just the Snort Subscriber Rules with the IPS Connectivity Policy and that's it. If you have extra RAM, you could choose to run maybe the ET-Malware, ET-Mobile_Malware and ET-Trojan rules. But that's about where I would stop.
The best deal going for home users is to pay the $29.99/year Snort Subscriber Rules fee and use just those rules. Set an IPS Policy and you should be good. This is for Snort.
If you are a Suricata user, then the Snort rules will not all load correctly in Suricata and you are better off with the Emerging-Threats rules as there is a subset of those written specifically for Suricata. The Suricata package specifically loads those rules. The ET folks are major Suricata supporters. The downside of the ET-Open free rules is that they are old. The current rules from them are very expensive (as in many hundreds of dollars per year). The "other" FreeBSD firewall distro has struck a deal with Emerging Threats (a.ka. ProofPoint) that lets their Suricata users have access to the current ET rules, but only if they agree to send all their detection data and metrics to ProofPoint. So kind of a Microsoft or Apple telemetry agreement.
-
Thanks @bmeeks, I really appreciate that insight. I just wanted follow up on a couple things:
-
Looking at the explanation of the rule sets on the Snort website, if I understand right they do recommend running both the community and VRT rules if you are registered user (and hence subject to the 30 delay) in order to stay current). Would you agree with that? https://www.snort.org/faq/what-are-the-differences-in-the-rule-sets
-
Let's say if I was to run the Snort Balanced policy, also enabling the ET Open rules would then end up being mostly redundant, correct? However, if I was to run just the Snort Connectivity policy, then I could also enable some ET Open rules to increase rule coverage, correct?
-
Ideally though, the best option would be to use the Snort rules if one is a Snort user and get the paid VRT rules, if possible, to make sure everything is up to date. In that case, one could essentially forego the other rule sets. Is that correct?
Thanks again for all your help.
-
-
@tman222 said in Overlap Running Multiple Rule Sets?:
Thanks @bmeeks, I really appreciate that insight. I just wanted follow up on a couple things:
- Looking at the explanation of the rule sets on the Snort website, if I understand right they do recommend running both the community and VRT rules if you are registered user (and hence subject to the 30 delay) in order to stay current). Would you agree with that? https://www.snort.org/faq/what-are-the-differences-in-the-rule-sets
If you don't have the paid Snort rules, then yes you can include the Community Rules. For $30/year, I really see no point to just stay a "registered user" if you are serious about using an IDS/IPS package, though.
- Let's say if I was to run the Snort Balanced policy, also enabling the ET Open rules would then end up being mostly redundant, correct? However, if I was to run just the Snort Connectivity policy, then I could also enable some ET Open rules to increase rule coverage, correct?
As I said earlier, it is really determined by the RAM you have and CPU horsepower. There is really no pressing need for ET rules when using Snort. It's akin to having a Chevrolet car and then wanting a Dodge as a different vehicle in the driveway. They are both automobiles and can get you to work each day. While I can see some logic in using ET-Open rules with Snort, realize that in reality you are essentially getting a second set of free Snort Community Rules as the ET-Open rules are dated just like the Snort Registered rules. So no harm in running them if you have RAM and CPU to spare, but certainly not a requirement to make you materially more secure.
- Ideally though, the best option would be to use the Snort rules if one is a Snort user and get the paid VRT rules, if possible, to make sure everything is up to date. In that case, one could essentially forego the other rule sets. Is that correct?
Yes, this is my recommendation. Buy the $30/year Snort Subscriber Rules package, select either IPS Policy - Connectivity or IPS Policy - Balanced and be happy. I ALWAYS recommend folks start with IPS Policy - Connectivity first! Run with that policy for many weeks until you get your feet thoroughly wet with administering an IDS. Jumping directly to "Balanced" is going to result in false positives and blocks of stuff you want to use. That will frustrate both you and your network users. Start with "Connectivity". That policy is plenty secure but won't generate a bunch of false positives.
No matter which IPS Policy you choose, or whether you run Snort or ET rules, you will need to tune the HTTP_INSPECT preprocessor rules by disabling a bunch of them. In fact, on my box, I disabled them all. Do that in SID MGMT by putting the GID:SID range in a
disablesid.conffile and assigning that file to each interface. Here is my file --# Disable the HTTP_INSPECT preprocessor rules on LAN for now 119:1-119:35,120:1-120:28Those rules will alert like crazy on most web site and streaming traffic, resulting in nuisance blocks.
Lastly, realize the limitations of any IDS/IPS. It can't see into encrypted packets. And the vast majority of all network traffic today is encrypted. So the IDS/IPS is losing its "teeth". Instead, make sure you keep all of your endpoint devices updated with all of the latest security patches!
-
Thanks @bmeeks - that makes a lot of of sense!
My apologies for taking this into a slightly different direction, but I was reviewing the "Detection Performance Settings" and a couple things caught my eye:
-
For "Search Method" I currently have AC-BNFA-NQ selected which I think is one of the recommended settings. I have read that AC or AC-NQ has the best performance but also uses a lot of memory and thus has not been recommended in the past. If the firewall a significant memory (e.g. 16GB), would this mode be ok to try or would it still cause issues?
-
Is there any benefit to enabling "Search Optimize"?
Thanks again for all your help.
-
-
@tman222 said in Overlap Running Multiple Rule Sets?:
Thanks @bmeeks - that makes a lot of of sense!
My apologies for taking this into a slightly different direction, but I was reviewing the "Detection Performance Settings" and a couple things caught my eye:
-
For "Search Method" I currently have AC-BNFA-NQ selected which I think is one of the recommended settings. I have read that AC or AC-NQ has the best performance but also uses a lot of memory and thus has not been recommended in the past. If the firewall a significant memory (e.g. 16GB), would this mode be ok to try or would it still cause issues?
-
Is there any benefit to enabling "Search Optimize"?
Thanks again for all your help.
Never change the Pattern Matcher setting. Don't really know why the Snort developers even offer the other settings. None of them work better than the default, and some of them basically don't work at all as your box will immediately consume all of its RAM and crash with several of the alternative settings selected. Search the threads here long enough and you will find folks who ignored this advice and ran their box out out RAM by fiddling with the Pattern Matcher.
The defaults are defaults for a good reason ... they work well in just about every single setup
.
-
-
@bmeeks - thanks again for the advice, I think I'm all set (for now).
I'm looking forward to the pfSense 2.5 including the Netmap related host stack networking changes - will plan to give Snort inline mode another try then (or before if I can find some time to get a machine put together to run the 2.5 development snapshots) to see if throughput will increase.
-
Hi @bmeeks - I have an idea / request for a feature that came to mind last night:
Do you think it might be possible to add download capability under the interface Rules section for the "Selected Category's Rules" table (e.g. as a CSV file, or similar)? I don't know easy or difficult it would be to implement this, but I think it would be very helpful to be able to take this data and load into another tool for further analysis of a given rule set (especially if it's larger one) and to aid in the process of selectively disabling / enabling some rules over others (i.e. using SID Management).
Thanks in advance for your consideration, I really appreciate it.
-
@tman222 said in Overlap Running Multiple Rule Sets?:
Hi @bmeeks - I have an idea / request for a feature that came to mind last night:
Do you think it might be possible to add download capability under the interface Rules section for the "Selected Category's Rules" table (e.g. as a CSV file, or similar)? I don't know easy or difficult it would be to implement this, but I think it would be very helpful to be able to take this data and load into another tool for further analysis of a given rule set (especially if it's larger one) and to aid in the process of selectively disabling / enabling some rules over others (i.e. using SID Management).
Thanks in advance for your consideration, I really appreciate it.
You can view the content of any of the category files by simply clicking on the name on the CATEGORIES tab. You can view individual rules by clicking on the corresponding line on the RULES tab while displaying a category. From the dialog that opens you can easily copy and paste to anyplace of your choice.
So I don't see the advantage of adding extra complicating code to download a CSV. You can also use WinSCP, for example, and directly manipulate the files on the firewall. The raw rules file reside in
/usr/local/etc/snort/rules.
-
@bmeeks said in Overlap Running Multiple Rule Sets?:
@tman222 said in Overlap Running Multiple Rule Sets?:
Hi @bmeeks - I have an idea / request for a feature that came to mind last night:
Do you think it might be possible to add download capability under the interface Rules section for the "Selected Category's Rules" table (e.g. as a CSV file, or similar)? I don't know easy or difficult it would be to implement this, but I think it would be very helpful to be able to take this data and load into another tool for further analysis of a given rule set (especially if it's larger one) and to aid in the process of selectively disabling / enabling some rules over others (i.e. using SID Management).
Thanks in advance for your consideration, I really appreciate it.
You can view the content of any of the category files by simply clicking on the name on the CATEGORIES tab. You can view individual rules by clicking on the corresponding line on the RULES tab while displaying a category. From the dialog that opens you can easily copy and paste to anyplace of your choice.
So I don't see the advantage of adding extra complicating code to download a CSV. You can also use WinSCP, for example, and directly manipulate the files on the firewall. The raw rules file reside in
/usr/local/etc/snort/rules.Thanks @bmeeks - I see what you mean now. You're right, if you work with the Categories tab it would be just as easy to take a closer look at the different categories and disable/enable as needed using SIG Management. I've got one quick follow up question: What is the different between the "Ruleset: Snort Text Rules" and "Ruleset: Snort SO Rules" columns? I assume the latter refers to "Subscriber Only"? Thanks again.
-
@tman222 said in Overlap Running Multiple Rule Sets?:
@bmeeks said in Overlap Running Multiple Rule Sets?:
@tman222 said in Overlap Running Multiple Rule Sets?:
Hi @bmeeks - I have an idea / request for a feature that came to mind last night:
Do you think it might be possible to add download capability under the interface Rules section for the "Selected Category's Rules" table (e.g. as a CSV file, or similar)? I don't know easy or difficult it would be to implement this, but I think it would be very helpful to be able to take this data and load into another tool for further analysis of a given rule set (especially if it's larger one) and to aid in the process of selectively disabling / enabling some rules over others (i.e. using SID Management).
Thanks in advance for your consideration, I really appreciate it.
You can view the content of any of the category files by simply clicking on the name on the CATEGORIES tab. You can view individual rules by clicking on the corresponding line on the RULES tab while displaying a category. From the dialog that opens you can easily copy and paste to anyplace of your choice.
So I don't see the advantage of adding extra complicating code to download a CSV. You can also use WinSCP, for example, and directly manipulate the files on the firewall. The raw rules file reside in
/usr/local/etc/snort/rules.Thanks @bmeeks - I see what you mean now. You're right, if you work with the Categories tab it would be just as easy to take a closer look at the different categories and disable/enable as needed using SIG Management. I've got one quick follow up question: What is the different between the "Ruleset: Snort Text Rules" and "Ruleset: Snort SO Rules" columns? I assume the latter refers to "Subscriber Only"? Thanks again.
SO refers to Shared Object. Those are proprietary rules for various exploits that are created from C source code and compiled as shared libraries for a series of operating systems. FreeBSD is one such supported system. So some of these are rules where the authors, for various reasons, wanted to keep the detection mechanism secret, so the text rules are not always published. Plus, since these are compiled source code, they can do more complex things in terms of detection.
-
Thanks @bmeeks. So using a combination of SID Management and IPS Policies I could, for instance, run the IPS Balanced policy but auto-disable some of the categories that are represented if the attack surface is not relevant (e.g. let's say rules pertaining to IIS servers), and then just run the remainder (of the policy rules). Are you aware of a good source that explains the different rule categories? Thanks again.
-
@tman222 said in Overlap Running Multiple Rule Sets?:
Thanks @bmeeks. So using a combination of SID Management and IPS Policies I could, for instance, run the IPS Balanced policy but auto-disable some of the categories that are represented if the attack surface is not relevant (e.g. let's say rules pertaining to IIS servers), and then just run the remainder (of the policy rules). Are you aware of a good source that explains the different rule categories? Thanks again.
You would have to disable by GID:SID values instead of categories if you use an IPS policy. Rules in a policy are auto-selected based on policy metadata embedded within each rule. Unless I was really short on RAM, I would not bother with such granularity if using a policy-based approach.
Documentation of everyone's rules, both Snort and Emerging Threats, is basically non-existent. You have to learn to read the rule syntax for yourself and then learn about the various exploits. In short, you have to become a blackhat hacker of a sort so that you fully understand the exploits and how they work, then you learn to use the Snort rule syntax and that combination makes you an IDS security admin. It is a very technical field with few truly qualified folks; and the good ones can command very high compensation.
-
@bmeeks said in Overlap Running Multiple Rule Sets?:
@tman222 said in Overlap Running Multiple Rule Sets?:
Thanks @bmeeks. So using a combination of SID Management and IPS Policies I could, for instance, run the IPS Balanced policy but auto-disable some of the categories that are represented if the attack surface is not relevant (e.g. let's say rules pertaining to IIS servers), and then just run the remainder (of the policy rules). Are you aware of a good source that explains the different rule categories? Thanks again.
You would have to disable by GID:SID values instead of categories if you use an IPS policy. Rules in a policy are auto-selected based on policy metadata embedded within each rule. Unless I was really short on RAM, I would not bother with such granularity if using a policy-based approach.
Documentation of everyone's rules, both Snort and Emerging Threats, is basically non-existent. You have to learn to read the rule syntax for yourself and then learn about the various exploits. In short, you have to become a blackhat hacker of a sort so that you fully understand the exploits and how they work, then you learn to use the Snort rule syntax and that combination makes you an IDS security admin. It is a very technical field with few truly qualified folks; and the good ones can command very high compensation.
Thanks @bmeeks - even if using a policy approach, wouldn't disabling a couple thousand rules (if they aren't relevant) help performance since there is less work for the CPU to do? Or am I overestimating the relative impact if the rule set is already quite large (e.g. let's say 10000+ rules).
I think this is a fascinating area and have enjoyed digging into the different categories and rules to try to learn more and optimize my setup. Thanks again for all your help along the way.
