Snort - Unable to Select Subscriber Ruleset
-
Hello everyone. I recently installed Snort on my SG-3100 pfSense firewall, and the install/tuning process has been going relatively well (once I realized that it was better to enable Snort on the physical LAN interface instead of the multiple LAN sub-interfaces that I'm running) except for one issue that has stumped me: in the Categories page where you select rulesets, the category column for 'Ruleset: Snort SO Rules' is completely empty and I don't understand why.
I paid the $30 fee for the 'Snort Subscriber Ruleset', pfSense has successfully downloaded this ruleset, I generated an Oinkcode in my Snort.org account, then configured the Oinkcode in the Snort config, and have performed manual updates of the rulesets. Based on the documentation I've read, this should be all that is necessary to enable the subscriber ruleset, but it doesn't appear to be working.
Here is a list of tshooting steps I've performed so far:
- Verified Snort.org account shows active subscription status.
- Verified 'Snort Subscriber Ruleset' is downloaded successfully (confirmed via the 'Updates' tab).
- Generated a new Oinkcode in my Snort.org account.
- Verified (via the 'Global Settings' tab) that the Oinkcode in my Snort config is an exact match to the Oinkcode displayed in my Snort.org account.
- Verified no leading/trailing whitespace in the Oinkcode.
- Disabled/Re-enabled the 'Enable Snort VRT' checbox.
- Disabled/Re-enabled 'Use IPS Policy' checkbox.
- Performed manual update of rules (i.e. 'Update Rules' and 'Force Update' buttons in 'Updates' tab).
- Re-installed Snort package (version 4.1.6_17) in pfSense.
- Verified that my SG-3100 is running the latest version of pfSense Plus: 24.03
- Rebooted my SG-3100.
The issue persists - the category column for 'Ruleset: Snort SO Rules' is completely empty.
Are there other tshooting actions that can help to solve this issue?
-
The SO (shared object) rules in Snort are distributed as precompiled binary rules. They are completely different from the other distributed rules. The source code that produces the SO rules is proprietary. The SO package is compiled by the Snort VRT (Vulnerability Research Team) and added to the Snort rules Gzip archive. Unfortunately they only compile the SO rules for AMD64 processors now. Your SG-3100 is a 32-bit ARM processor. It cannot run the AMD64 code compiled into the SO rules, therefore the Snort GUI package hides and does not load those rules when the system processor is anything other than an AMD64 CPU.
TLDR -- the SO rules are only compatible with Intel/AMD 64-bit CPUs. They do not work with ARM processors; therefore the GUI package does not allow selection of the SO rules when the system CPU is anything other than a 64-bit Intel compatible device.
-
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!
