Snort - Unable to Select Subscriber Ruleset
-
Ah, I was confusing the Shared Object rules with the Subscriber rules. I'm glad it was a simple misunderstanding, though I do wish that the documentation was more clear about this; I regret all the time I spent troubleshooting a non-issue. Lol.
Thank you so much for taking the time to clarify this; I appreciate your help!
There is an outstanding question though - what is the recommended method to verify that the Subscriber Ruleset is indeed applied as expected?
-
@foss-lab-76 said in Snort - Unable to Select Subscriber Ruleset:
There is an outstanding question though - what is the recommended method to verify that the Subscriber Ruleset is indeed applied as expected?
If you want to see all of the actual rules being loaded and used by the Snort instance on an interface, choose to edit the interface in the Snort GUI and click the RULES tab. In the drop-down selector at the top of the page choose "Active Rules". That will load up and display all of the individual rules Snort is using for that interface. If you have lots of rules enabled, note that it will take quite a bit of time for all of them to load and display in the GUI, though.
A shortcut is to open and view the file
/usr/local/etc/snort/snort_xxxx/rules/snort.rulesfrom a command-line session where_xxxxrefers to the specific physical interface name and random UUID. -
@foss-lab-76 said in Snort - Unable to Select Subscriber Ruleset:
Ah, I was confusing the Shared Object rules with the Subscriber rules.
The Shared Object rules are a special subset of rules available from the Subscriber Rules package. As mentioned, they are pre-compiled binary libraries that are loaded and processed by the Snort binary. That's why they only work on Intel/AMD CPUs. Think of them as just another "category" of rules available in the Snort Subscriber Rules package.
-
The 2100 also has this issue as it is ARM also. I went through this whole process wondering about it too until Bill set me straight
-
@bmeeks said in Snort - Unable to Select Subscriber Ruleset:
@foss-lab-76 said in Snort - Unable to Select Subscriber Ruleset:
There is an outstanding question though - what is the recommended method to verify that the Subscriber Ruleset is indeed applied as expected?
If you want to see all of the actual rules being loaded and used by the Snort instance on an interface, choose to edit the interface in the Snort GUI and click the RULES tab. In the drop-down selector at the top of the page choose "Active Rules". That will load up and display all of the individual rules Snort is using for that interface. If you have lots of rules enabled, note that it will take quite a bit of time for all of them to load and display in the GUI, though.
A shortcut is to open and view the file
/usr/local/etc/snort/snort_xxxx/rules/snort.rulesfrom a command-line session where_xxxxrefers to the specific physical interface name and random UUID.Cool, thank you! My goal is to verify that I'm getting the latest rules included in the Subscriber Ruleset. Looking at the rule details as you described doesn't seem to help with this; is there another method to verify this?
-
@foss-lab-76 said in Snort - Unable to Select Subscriber Ruleset:
Cool, thank you! My goal is to verify that I'm getting the latest rules included in the Subscriber Ruleset. Looking at the rule details as you described doesn't seem to help with this; is there another method to verify this?
I don't think I fully understand your question. If you have a valid Snort Oink code for a paid Snort Subscriber Rules home user subscription ($29.99 USD annually), then you are getting their most up-to-date rules each time the Snort package on pfSense downloads and installs a rules update. If you don't understand how that works, then you must be a very new IDS/IPS admin. If you are not paying the $29.99 annual subscription, then you are only getting new rules in the updates after they have been available for the paying customers for at least 30 days. Or looking at it from a different perspective, the "free" rules are at least 30 days old.
You can configure the interval which the Snort package uses to check for updates. The Snort VRT usually updates their rules package about twice a week, so checking once every 24 hours is more than enough to catch those updates. You also must manually select the rules you want to enable. By default no rules will be enabled except those dealing with information-only traffic anomalies. These rules do not detect malicious threats. Do you know how to review the vulnerabilities in your protected networks and then enable the necessary rules from the list available in the Snort Subscriber Rules package to protect those vulnerabilities? Unless you properly configure Snort and then select the necessary rules to mitigate the vulnerabilities in your network, simply installing the package on pfSense is worthless in terms of improving security.
For any given category listed in the Snort rules package, it is common for quite a number of the rules to be commented out and thus those rules will not be loaded by Snort. Rules can be commented out by the rule authors for many reasons: (1) the rule is for a threat that is considered very old and not likely to be exploited any longer; (2) the rule may be prone to false positives in most environments; (3) the rule may address a threat that only impacts a tiny fraction of networks, etc.
-
@bmeeks said in Snort - Unable to Select Subscriber Ruleset:
@foss-lab-76 said in Snort - Unable to Select Subscriber Ruleset:
Cool, thank you! My goal is to verify that I'm getting the latest rules included in the Subscriber Ruleset. Looking at the rule details as you described doesn't seem to help with this; is there another method to verify this?
I don't think I fully understand your question. If you have a valid Snort Oink code for a paid Snort Subscriber Rules home user subscription ($29.99 USD annually), then you are getting their most up-to-date rules each time the Snort package on pfSense downloads and installs a rules update. If you don't understand how that works, then you must be a very new IDS/IPS admin. If you are not paying the $29.99 annual subscription, then you are only getting new rules in the updates after they have been available for the paying customers for at least 30 days. Or looking at it from a different perspective, the "free" rules are at least 30 days old.
You can configure the interval which the Snort package uses to check for updates. The Snort VRT usually updates their rules package about twice a week, so checking once every 24 hours is more than enough to catch those updates. You also must manually select the rules you want to enable. By default no rules will be enabled except those dealing with information-only traffic anomalies. These rules do not detect malicious threats. Do you know how to review the vulnerabilities in your protected networks and then enable the necessary rules from the list available in the Snort Subscriber Rules package to protect those vulnerabilities? Unless you properly configure Snort and then select the necessary rules to mitigate the vulnerabilities in your network, simply installing the package on pfSense is worthless in terms of improving security.
For any given category listed in the Snort rules package, it is common for quite a number of the rules to be commented out and thus those rules will not be loaded by Snort. Rules can be commented out by the rule authors for many reasons: (1) the rule is for a threat that is considered very old and not likely to be exploited any longer; (2) the rule may be prone to false positives in most environments; (3) the rule may address a threat that only impacts a tiny fraction of networks, etc.
I really appreciate you taking the time to post this detailed response. You have been extremely helpful!
Indeed, you have accurately determined that I am very new to IDS/IPS. I did pay the $29.99 subscription price and I did understand at the time of purchase that this should provide me the most up-to-date rules each time that the Snort package on pfSense downloads and installs a rules update.
My experience as an IT professional and as an individual consumer has taught me well the value of validating things, whether its a device configuration for a work project or a feature for a product that I purchased for my family.
In this case my goal is simply to validate that the Snort package is indeed downloading the latest rules as it should be after I upgraded to the Subscriber Ruleset, because just like any software product there's a possibility of an issue which could prevent this expected outcome from occurring. A documented version ID for rules, or a procedure to compare new-vs-old rule hashes would help to solve for this; I haven't found clear information to confirm if either of these exists or not.
-
@foss-lab-76 said in Snort - Unable to Select Subscriber Ruleset:
In this case my goal is simply to validate that the Snort package is indeed downloading the latest rules as it should be after I upgraded to the Subscriber Ruleset, because just like any software product there's a possibility of an issue which could prevent this expected outcome from occurring. A documented version ID for rules, or a procedure to compare new-vs-old rule hashes would help to solve for this; I haven't found clear information to confirm if either of these exists or not.
You can see the downloaded and in-use rules file MD5 hash on the UPDATES tab in the Snort package GUI. If your paranoia demands, you can then compare the MD5 hash to that posted on the official Snort rules web site
. You can also review the update log file from that tab to see exactly what Snort did during the update process. If you have not previously done so, visit the UPDATES tab in the package and note the type of information available there and review the log file linked there.The Snort VRT does not publish any type of "rules version" information. They simply provide an MD5 hash of the entire archive. When the archive is changed, that hash is updated. The Snort package on pfSense downloads the posted MD5 hash file, compares the hash to what is stored locally (obtained from the last succesful rules update), and downloads the rules archive anew from the rules website if the stored MD5 hash differs from the one posted by the Snort VRT. At the end of a successful update, the stored MD5 hash is modified appropriately.
-
@bmeeks said in Snort - Unable to Select Subscriber Ruleset:
You can see the downloaded and in-use rules file MD5 hash on the UPDATES tab in the Snort package GUI. If your paranoia demands, you can then compare the MD5 hash to that posted on the official Snort rules web site. You can also review the update log file from that tab to see exactly what Snort did during the update process. If you have not previously done so, visit the UPDATES tab in the package and note the type of information available there and review the log file linked there.Referring to my legitimate interest to perform validation as 'paranoia' seems a bit uncalled for, though it seems that you probably meant this as a joke, and I sincerely appreciate your patience + continued assistance
I was aware of the MD5 hashes shown on the 'Updates' tab, but as you pointed out this must be compared to the hash of the newest update in order to make a meaningful determination, and neither the 'Update' tab or the log messages show this comparison.
@bmeeks said in Snort - Unable to Select Subscriber Ruleset:
The Snort VRT does not publish any type of "rules version" information. They simply provide an MD5 hash of the entire archive. When the archive is changed, that hash is updated. The Snort package on pfSense downloads the posted MD5 hash file, compares the hash to what is stored locally (obtained from the last succesful rules update), and downloads the rules archive anew from the rules website if the stored MD5 hash differs from the one posted by the Snort VRT. At the end of a successful update, the stored MD5 hash is modified appropriately.Thank you for this summary. I found this MD5 listing on the snort.org website which lists the MD5 hashes of the respective rule archive files. There are no publication dates listed on this page, but the archive files do contain a number designation of some kind; the archive file with the largest number value is snortrules-snapshot-31470.tar.gz with a corresponding hash value of: 979979cee970ce26ba7de4e5bf7afaaa
In comparison, the 'Snort Subscriber Ruleset' MD5 hash shown on the Updates tab of my Pfsense firewall is 789c881480ddd17c31b29e4839b7747e which corresponds to archive file snortrules-snapshot-29200.tar.gz
This info could be interpreted a couple different ways, but this seems to indicate that the Snort package on my pfSense firewall is stilll running the older 30-day ruleset and not the latest one despite my attempts to correct this. Are you able to confirm this?
-
@foss-lab-76: I did intend the quip to be a joke.
You are new to IDS/IPS, so I will try to explain, but it seems you really should spend some time on your own doing some Google research on Snort and its rules in general. Also learn about the two major Snort versions and their differences.
The Snort package on pfSense is based on the 2.9.x branch of the Snort binary. This is an old version that runs single-threaded. It will eventually go EOL (end-of-life) as the Snort team (now Cisco/Talos) has produced a Snort3 binary branch and that is their intended path. Snort3 is multithreaded.
Currently nobody is interested in rewriting the Snort package on pfSense to be compatible with Snort3. Suricata is instead the preferred way forward on pfSense. At some point, once the 2.9.x branch of Snort goes EOL, Snort will cease to exist as a package on pfSense. I am the volunteer package maintainer for Snort and the creator/maintainer for Suricata on pfSense. I tried on two different occasions to create a Snort3 package and gave up in frustation because of the massive amount of rewrite required for essentially very little gain compared to Suricata. So far, no one else has stepped up to attempt a Snort3 package creation for pfSense.
The number you see in the rules files refers to the binary version that particular rules package is designed for. You cannot use Snort3 rules with the 2.9.x binary. If you were to try that, it would totally break the Snort installation on pfSense.
The correct rules for the pfSense Snort package will always have 29200 in them as that number indicates the rules are for the 2.9.2 version branch of the binary.
The version number in the rules filename has zero to do with the age of the included rules. What determines the age of rules you receive is whether your Oink code is associated with a "paid account" or the "free account". The Oink code is supplied as part of the rules download URL by the package, and the Snort rules website reads the Oink code and sends back the matching file version (current or 30-day old rules).
-
@bmeeks I have conducted some research, and had seen various mentions of Suricata, but my research time has been limited recently and I had not yet realized the things that you just graciously clarified to me.
Part of my research included posting an inquiry in this forum. Thank you so much for helping me out, as well as others in a similar position to mine who may find this message thread. You have demonstrated the value of the pfSense community
At my next opportunity I will work on transitioning my pfSense config to Suricata; I have read/watched that the pfSense package for Suricata is very similar to the one for Snort, so I can hopefully apply most of what I've learned thus far with Snort.
Thank you again!
-
@bmeeks said in Snort - Unable to Select Subscriber Ruleset:
I am the volunteer package maintainer for Snort and the creator/maintainer for Suricata on pfSense. I tried on two different occasions to create a Snort3 package and gave up in frustation because of the massive amount of rewrite required for essentially very little gain compared to Suricata.
Oh wow, I am even more humbled now. Thank you for your contributions to the Snort and Suricata projects!
