Snort 2.9.5.6 pkg v3.0.4 Update – Release notes and change log
-
An update to the Snort package has been posted. The binary is updated to version 2.9.5.6 and the GUI package to version 3.0.4. This version introduces three new features and fixes four bugs as described below.
Installation Notes: as usual, best results are achieved by removing and then re-installing the Snort package because of the binary version update. Just be sure to check the box near the bottom of the page on the GLOBAL SETTINGS tab to save Snort settings when uninstalling. This is especially critical for installs on 2.0.x and older versions of pfSense!
If you use barnyard2 for logging to a database, you most likely need to perform this task as posted on the Snort.org blog for the barnyard2 v2-1.13 update included in this Snort package upgrade.
UPGRADE REQUIREMENTS
If you are upgrading to barnyard2 2-1.13 (build 327) or above from a previous version and using output database.
You will need to delete every row in your sig_reference table. (DELETE FROM sig_reference;)
The table will be re-populated at startup, and has no impact on historical data.
New Features
-
An additional reverse DNS lookup icon has been added to the ALERTS and BLOCKS tab entries. The new icons mimic the functionality available for the firewall logs view on pfSense 2.1 and higher. The new DNS lookup icons are only available on pfSense 2.1 or higher. NOTE – For older pfSense versions, the legacy behavior with the single icon remains.
-
The ALERTS tab now features a "Rule Disable" icon in the SID column alongside the "Add to Suppress List" icon. Clicking the "Rule Disable" icon will force-disable the rule and prevent traffic being evaluated against the rule. Note this will result in the rule being completely removed from the enforcing rule set; as opposed to suppressing the alert, which simply prevents future alerts but the rule still inspects traffic.
-
The Snort GUI now provides the ability to manage all rules including the decoder and preprocessor rules on the RULES tab. Users can force-disable (or force-enable) any rules from the decoder.rules, preprocessor.rules and sensitive-data.rules files. Snort now generates a single enforcing rules file (snort.rules) that contains all the rules including the preprocessor rules that were formerly loaded separately from a different sub-directory. A beneficial side-effect to this is that now the sid-msg.map file is complete and contains the preprocessor rules. This is helpful with third-party logging tools such as Barnyard2 that depend on the sid-msg.map file.
Bug Fixes
-
A potential bug in the Spoink output plugin used to insert IP blocks in pfSense is fixed. The bug could have resulted in Snort occasionally failing to insert an IP into the block table.
-
When removing a blocked IP address using the X icon beside the alert on the ALERTS tab, the user is not always returned to the same interface selection upon the page reload.
-
When toggling the enable/disable state of a rule on the RULES tab, the rule never toggles back to its default state.
-
When clearing custom rules by manually deleting the content and saving a blank page, the custom rules are not cleared.
Security Fixes
- A potential XSS issue is fixed in the View Logs pop-up dialog.
Bill
-
-
Like I mentioned in the thread for the previous update, pfSense Package manager still shows the version as 2.9.5.5 pkg v3.0.4. Other than that the package installed properly and the new version of Snort seems to be up and running.
-
Like I mentioned in the thread for the previous update, pfSense Package manager still shows the version as 2.9.5.5 pkg v3.0.4. Other than that the package installed properly and the new version of Snort seems to be up and running.
Ermal merged the change early this morning (U.S. Eastern Time), but not everything appears sync'd yet. I will drop him a note.
Bill
-
Thanks for the Updates, just updated Snort to 2.9.5.5 pkg v3.0.4 and awaiting the new Snort 2.9.5.6 pkg v3.0.4 to hit the repository!
-
Thanks for the Updates, just updated Snort to 2.9.5.5 pkg v3.0.4 and awaiting the new Snort 2.9.5.6 pkg v3.0.4 to hit the repository!
It is there already, the package name is just incorrect on the Package Manager page. You can reinstall the package to get the new binary.
-
Thanks for the Updates, just updated Snort to 2.9.5.5 pkg v3.0.4 and awaiting the new Snort 2.9.5.6 pkg v3.0.4 to hit the repository!
It is there already, the package name is just incorrect on the Package Manager page. You can reinstall the package to get the new binary.
Yep, this was a particularly difficult merge because of binary dependencies for the old 2.0.x *.tbz packages. We had to do more than the normal amount of manual edits, and the <version>tag got missed in the package manager XML file. That will get fixed shortly.
But the correct binary is posted, so if you install "Snort 2.9.5.5" you will actually get the newest 2.9.5.6 stuff. As I said, though, give it a little bit and everything should get matched back up. jimp just posted the fix.
Bill</version>
-
OK. Things are finally matched up now, so under System…Packages you should see "Snort 2.9.5.6 pkg v3.0.4".
Note: if you installed the earlier package that said "Snort 2.9.5.5 pkg v3.0.4", then you have the new code but just the wrong marker. You can safely just reinstall the package to get the correct version number noted in your packages database.
Bil
-
OK. Things are finally matched up now, so under System…Packages you should see "Snort 2.9.5.6 pkg v3.0.4".
Note: if you installed the earlier package that said "Snort 2.9.5.5 pkg v3.0.4", then you have the new code but just the wrong marker. You can safely just reinstall the package to get the correct version number noted in your packages database.
Bil
Ok kool..
I'm gonna keep the version that I have now and watch if I see any new versions over the next day then re-install if necessaryUPDATE!
The new package (Available: 2.9.5.6 pkg v3.0.4 , Installed: 2.9.5.5 pkg v3.0.4) is now shown in the package manager, I have reinstalled and updated to the new one, will report back if I experience any major issues.Thanks Again!
-
The "Installed Packages" dashboard widget correctly showed the update available under the new version and after install the new version is showing. Thanks Bill!!
Rick
-
An update to the Snort package has been posted.
New Features
Bug Fixes
Bill
New Features
All new features work for me. I think the "Disable Rule" icon should have a prompt asking to continue, as it could be hit by accident.
The new Setup is very slick. Fantastic work Bill!! ;DBugs
1 & 3 - I never had an issue with
2 & 4 - Fixes worked as expected. ;D -
@BBcan17:
An update to the Snort package has been posted.
New Features
Bug Fixes
Bill
New Features
All new features work for me. I think the "Disable Rule" icon should have a prompt asking to continue, as it could be hit by accident.
The new Setup is very slick. Fantastic work Bill!! ;DBugs
1 & 3 - I never had an issue with
2 & 4 - Fixes worked as expected. ;DThank you. You are right, I need to add an "are you sure" dialog for the rule disable icon when clicked. Will put that in the next update when 2.9.6.0 is posted. Should be toward the middle or end of March.
Bill
-
I get this error and Snort does not start:
snort[36042]: FATAL ERROR: Failed to load /usr/pbi/snort-amd64/lib/snort/dynamicrules/web-misc.so: /usr/pbi/snort-amd64/lib/snort/dynamicrules/web-misc.so: invalid file format
Edit: the above was after updating a running Snort. I uninstalled and then installed and then it started up without errors.
-
I get this error and Snort does not start:
snort[36042]: FATAL ERROR: Failed to load /usr/pbi/snort-amd64/lib/snort/dynamicrules/web-misc.so: /usr/pbi/snort-amd64/lib/snort/dynamicrules/web-misc.so: invalid file format
Could be a problem with one of the Snort VRT rule updates. That indicates a Shared Object rule, and those come down precompiled by the Snort VRT in the Snort rules tarball. For now, disable (uncheck) that rule set on the CATEGORIES tab and see if that will fix the problem.
I will test in one of my VMs as well.
UPDATE: I tested this in a VM and could not reproduce the problem. All of the Snort web-*.so rules loaded fine for me. Try forcing a new rules download on your end and see if that helps. Here's how:
1. Go to Diagnostics…Edit on the pfSense menu.
2. Browse to /usr/pbi/snort-amd64/etc/snort and open the snort rules snapshot MD5 file located there.
3. Make any kind of change in the content (for example, just change the last 3 digits to zeros) and save the change.
4. Now go to the Rules Update tab and download the rules again. Altering the content of the MD5 file should force a new set of Snort rules to come down.
I am using the Snort paid subscriber rules. If you still have the issue after downloading the rules update again, and you are using the free registered user Oinkcode, you might need to contact the Snort VRT at snort.org and let them know.
Bill
-
Bill, sorry but before I saw your reply I unchecked the Save configuration option and uninstalled Snort. I re-installed and all is running fine. I have a paid Snort subscription. Thanks!
-
Bill, sorry but before I saw your reply I unchecked the Save configuration option and uninstalled Snort. I re-installed and all is running fine. I have a paid Snort subscription. Thanks!
OK. Glad it worked out for you. Something in that file must have gotten corrupted during the original download and install. As I said, that file is actually part of the downloaded rules tarball from snort.org.
Bill
-
New Features
- The ALERTS tab now features a "Rule Disable" icon in the SID column alongside the "Add to Suppress List" icon. Clicking the "Rule Disable" icon will force-disable the rule and prevent traffic being evaluated against the rule. Note this will result in the rule being completely removed from the enforcing rule set; as opposed to suppressing the alert, which simply prevents future alerts but the rule still inspects traffic.
Nice one! Thank you very much for this.
@bmeeks:- The Snort GUI now provides the ability to manage all rules including the decoder and preprocessor rules on the RULES tab. Users can force-disable (or force-enable) any rules from the decoder.rules, preprocessor.rules and sensitive-data.rules files. Snort now generates a single enforcing rules file (snort.rules) that contains all the rules including the preprocessor rules that were formerly loaded separately from a different sub-directory. A beneficial side-effect to this is that now the sid-msg.map file is complete and contains the preprocessor rules. This is helpful with third-party logging tools such as Barnyard2 that depend on the sig-msg.map file.
Does this mean I can finally get rid of the double decoding attack alert (I thought IIS was banned from industry use by now…)? And does this mean smaller suppress lists? Even less power wasted evaluating useless rules? THANK YOU!!!
On the downside, I have to post an update to the blueprint now :P -
@jflsakfja:
Does this mean I can finally get rid of the double decoding attack alert (I thought IIS was banned from industry use by now…)? And does this mean smaller suppress lists? Even less power wasted evaluating useless rules? THANK YOU!!!
On the downside, I have to post an update to the blueprint now :PYep. The user now has total control of the decoder and preprocessor rules via the RULES tab. Just select them in the drop-down list and disable away as you desire.
I have a plan for the future to continue improvements with rules management including the ability to use PCREs to selectively enable/disable rules. In short, I plan to incorporate the functionality of the enablesid.conf, disablesid.conf and/or modifiysid.conf files afforded by PulledPork and Oinkmaster.
Bill
-
Hi Bill,
Could you take a look at the attached png file?
The Alerts page is showing alerts for the "Disabled Rules". Is this normal?
Would that mean that all of the rules are loaded into memory? Memory is not an issue for me, however, I never noticed that before.
If this is Normal, than I guess atleast I'm seeing the alerts that are not being blocked?
![Alert Page.png](/public/imported_attachments/1/Alert Page.png)
![Alert Page.png_thumb](/public/imported_attachments/1/Alert Page.png_thumb) -
@BBcan17:
Hi Bill,
Could you take a look at the attached png file?
The Alerts page is showing alerts for the "Disabled Rules". Is this normal?
Would that mean that all of the rules are loaded into memory? Memory is not an issue for me, however, I never noticed that before.
If this is Normal, than I guess atleast I'm seeing the alerts that are not being blocked?
You are probably seeing "history". The view on the ALERTS tab is simply the first "nnn" records read from the alerts log. The "nnn" value is the numeric setting on the tab for how many alerts to show. So the alert should have happened in the past, you disabled the rule, but the original entry is still in the alerts log and will be read and shown in the list. To see if my theory is correct, reduce the number of alerts to display to something like 3 or 4 and see if the disabled ones disappear. If not post back.
The new code should be disabling the rule, performing an enforcing rules file rebuild for the interface, and then doing a "live rule reload" for the interface all when you click the X. From that point forward, you should get no new alerts from the disabled rule. But because of the history aspect in the logs as I described above, you might see them listed on the tab (but with the lighter-colored icon to show the rule is disabled). Depending on how many alerts you get per unit time, and the setting of how many alert log entries to display, the alerts from disabled rules should eventually disappear from the tab.
Bill
-
You are probably seeing "history".
So the alert should have happened in the past, you disabled the rule, but the original entry is still in the alerts log and will be read and shown in the list. To see if my theory is correct, reduce the number of alerts to display to something like 3 or 4 and see if the disabled ones disappear. If not post back.
These are fresh events. See attached png files. Those rules have been disabled for a long time now.
![Alert Page.png](/public/imported_attachments/1/Alert Page.png)
![Alert Page.png_thumb](/public/imported_attachments/1/Alert Page.png_thumb)
![Alert Page 2.png](/public/imported_attachments/1/Alert Page 2.png)
![Alert Page 2.png_thumb](/public/imported_attachments/1/Alert Page 2.png_thumb)