Snort 2.9.5.5 pkg. v3.0.0 – Update Released
-
Getting this when trying to start Snort on 2.0.3
nort[26427]: FATAL ERROR: The dynamic detection library "/usr/local/lib/snort/dynamicrules/web-misc.so" version 1.0 compiled with dynamic engine library version 1.17 isn't compatible with the current dynamic engine library "/usr/local/lib/snort/dynamicengine/libsf_engine.so" version 2.1.
Dec 11 16:40:00 snort[26427]: FATAL ERROR: The dynamic detection library "/usr/local/lib/snort/dynamicrules/web-misc.so" version 1.0 compiled with dynamic engine library version 1.17 isn't compatible with the current dynamic engine library "/usr/local/lib/snort/dynamicengine/libsf_engine.so" version 2.1.OK, on 2.0.3 you will need to do the whole "remove with "X" icon and then reinstall" procedure. As a further precaution, you can manually delete the entire snort directory under /usr/local/lib before reinstalling. The 2.1 releases with PBI don't have this issue.
Bill
-
:D Thanks man!
-
:D Thanks man!
Doing the complete remove and reinstall should fix it. The problem is caused by the Snort shared-object rules. The Snort VRT tags them with a "version", and so the new ones are tagged with 2.9.5.5 instead of 2.9.4.6. With the old package management system in 2.0.3 of pfSense, I am a bit handicapped with a Snort update because the Package Manager code does not actually discriminate between a GUI reinstall and a package reinstall. You have separate icons for each task (the XML and PKG icons), but they actually both call the same piece of code that just copies down the GUI files. They don't physically remove the binaries and reinstall those. Only the "X" package remove icon does that.
Because of this limitation in 2.0.3, the un-install code in my Snort package can't delete this directory safely. This is because it has no way of knowing if the user clicked the XML icon or the PKG icon. If the directory is removed when only the GUI components are being reinstalled, then Snort is broken badly. The directory can only be safely removed when the Snort binary is being removed and reinstalled.
I updated the original post at the top of this thread to warn others on 2.0.x of pfSense to perform a remove first, then an install, of Snort. Users on 2.1 of pfSense can simply click the PKG icon to update Snort. The new PBI process in 2.1 takes care of the remove and install automatically.
Bill
-
Just updated Snort to the new version on a pfSense 2.1 32-bit system. Worked without any issues!
Thanks Bill! ;D
-
Just updated Snort to the new version on a pfSense 2.1 32-bit system. Worked without any issues!
Thanks Bill! ;D
Good to hear and thanks for the positive feedback. Things definitely work much smoother with package upgrades on the new PBI platform of pfSense 2.1. All the 2.0.x holdouts need to give it up and just upgrade to 2.1… ;D
Bill
-
Thanks.
2.1 x64, no problem. -
Will do when it works :D
Just updated Snort to the new version on a pfSense 2.1 32-bit system. Worked without any issues!
Thanks Bill! ;D
Good to hear and thanks for the positive feedback. Things definitely work much smoother with package upgrades on the new PBI platform of pfSense 2.1. All the 2.0.x holdouts need to give it up and just upgrade to 2.1… ;D
Bill
-
Been looking forward to this. In the wan Preprocessor tab under the frag3 engine configuration. I add a new engine and click the aliases button and choose one from the list but it doesn't seem to save the selection. If i type in the alias it does save. Can you do a quick check to make sure its just not me :)
-
Bill,
Earlier you noted there were some issues with Snort that were dependent on a pfSense core update. Are any of those issues being covered by this update or are we still waiting for the pfSense update?Thank,
Rick -
Been looking forward to this. In the wan Preprocessor tab under the frag3 engine configuration. I add a new engine and click the aliases button and choose one from the list but it doesn't seem to save the selection. If i type in the alias it does save. Can you do a quick check to make sure its just not me :)
I just did this on my production firewall this morning and had no issues. I clicked the Up Arrow icon to add an Alias as a new Frag3 target. Select an Alias and then click SAVE. You should return to the Preprocessors tab. Now click the "e" icon to open the Frag3 Engine Details window where you can choose other parameters. Click SAVE at the bottom of that window when finished, then finally click SAVE at the bottom of the Preprocessors window.
Did you use the Up Arrow icon from the Preprocessors tab, or did you click the + (plus) icon to add a new engine from scratch?
Update: I just tried it both ways and it worked each way (that is, using the Up Arrow icon to add an Alias entry, or using the + icon to create a new blank engine and choosing an Alias using the Aliases button on the details edit screen).Bill
-
Bill,
Earlier you noted there were some issues with Snort that were dependent on a pfSense core update. Are any of those issues being covered by this update or are we still waiting for the pfSense update?Thank,
RickStill waiting on a pfSense update for that. I believe you are talking about the premature clearing of the Snort block table upon a firewall filter_reload() process. That is something totally outside the realm of the Snort package.
Bill
-
Bill,
Yep, that was it… thanks for the quick reply! :)I was just wondering, since this is such a comprehensive update, if you had "found something" since then that was a fix rather than depending on a core pfSense or 8.3 correction.
Rick
-
Bill,
Yep, that was it… thanks for the quick reply! :)I was just wondering, since this is such a comprehensive update, if you had "found something" since then that was a fix rather than depending on a core pfSense or 8.3 correction.
Rick
No. There appears to be a misconception among folks with the way Snort works on pfSense. Snort itself does not "block" anything directly. It analyzes copies of network packets, and when a packet matches a signature, Snort fires an "alert". This "alert" is written to the log file and then passed to a FreeBSD packet filter utility which is asked to insert the offending packet's IP address into the firewall block table. The packet filter engine of FreeBSD is the firewall. The packet filter table used by Snort is called the "snort2c" table. This table is totally managed by the packet filter engine of FreeBSD and not by Snort. Snort does not clear the table. All it can do is ask the packet filter engine to insert an offending IP. Once it does that, Snort is done and no longer can interact with the block table. Even the regular automatic clearing is actually done by a cron job that calls the pfctl utility of the packet filter. That utility clears the packet filter tables. You could insert your own IPs into that block table completely outside of Snort and they would still be blocked just as if Snort had placed them there.
With the upgrade to pfSense 2.1 and the move the FreeBSD 8.3, something changed in the way the FreeBSD code handles the packet filter tables on something called a filter_reload() function call. Now that call clears all the block tables of IP addresses – including Snort's. Snort can't stop it from doing that. A number of internal events (not Snort related events) can trigger that filter_reload() function. When it is triggered, the block table is cleared. No change in the Snort code can fix this.
As has been posted in a number of threads, the premature clearing of the block table is not a problem. This does not mean Snort never blocks again. Folks give me the impression with all the questions about this that they think if the block table is cleared, Snort never blocks anything else. That is not the case. On the next offending packet from a host, the host's IP will be inserted into the block table and it will get blocked again. I think folks panic because they look at the Block tab and don't see tons of IP addresses listed. The premature clearing is a nuisance, but not a showstopper.
Snort never knows the block table has been cleared, so there is no way for it to "re-populate it" as some folks have suggested. Besides, why should Snort waste time figuring out what is missing and what should be put back into that table?
Bill
-
I used the plus arrow then hit the alias tab. When i select the alias, it refreshes the page but it doesnt take me out of the alias window. Its not a big deal anyway , could just be my browser :)
Been looking forward to this. In the wan Preprocessor tab under the frag3 engine configuration. I add a new engine and click the aliases button and choose one from the list but it doesn't seem to save the selection. If i type in the alias it does save. Can you do a quick check to make sure its just not me :)
I just did this on my production firewall this morning and had no issues. I clicked the Up Arrow icon to add an Alias as a new Frag3 target. Select an Alias and then click SAVE. You should return to the Preprocessors tab. Now click the "e" icon to open the Frag3 Engine Details window where you can choose other parameters. Click SAVE at the bottom of that window when finished, then finally click SAVE at the bottom of the Preprocessors window.
Did you use the Up Arrow icon from the Preprocessors tab, or did you click the + (plus) icon to add a new engine from scratch?
Update: I just tried it both ways and it worked each way (that is, using the Up Arrow icon to add an Alias entry, or using the + icon to create a new blank engine and choosing an Alias using the Aliases button on the details edit screen).Bill
-
I have updated one of my 2.1 Release (x64) to the new Snort 2.9.5.5 pkg v.3.0.0 routers today.
No issues with the installation. No missing data from my previous install. Everything seems to be functioning 100%
Thanks Bill and all the SNORT team for their efforts.
ps - a GUI snort disablesid.conf editor would be nice. Esp. when you want to update several different pfSense boxes.
-
I used the plus arrow then hit the alias tab. When i select the alias, it refreshes the page but it doesnt take me out of the alias window. Its not a big deal anyway , could just be my browser :)
Updated Reply: After thinking about this some more after posting the initial response below, I suspect it is a browser issue with the new session variable code in the Alias import page. I tried to get fancy there using session variables to save the calling page (that is, the page where the imported Alias will be returned to), but I may have gotten too fancy and created something that is not 100% browser agnostic. Tell me the Browser type and version you are using and I will see if I can reproduce and then find a fix.
Initial Reply:
Yeah, it might be something with the browser. I used IE10 and IE11 for most of my testing, but did install Chrome and Firefox in a couple of VMs for some testing in the past. I don't recall offhand if I tested the new Alias import with Chrome or Firefox, though. What browser are you using?Bill
-
@BBcan17:
I have updated one of my 2.1 Release (x64) to the new Snort 2.9.5.5 pkg v.3.0.0 routers today.
No issues with the installation. No missing data from my previous install. Everything seems to be functioning 100%
Thanks Bill and all the SNORT team for their efforts.
ps - a GUI snort disablesid.conf editor would be nice. Esp. when you want to update several different pfSense boxes.
Thank you for the positive feedback, and that is a good idea. Supermule also suggested some time back a sort of "template" system for Snort where you could create a set of configuration templates and then assign one to a specific pfSense box or group of boxes. The template would have all the settings preset. I have that idea in my list of future enhancements. I could probably incorporate your disablesid.conf idea into the same template design. I'm thinking maybe this would be an add-on package for Snort much like the Snort Dashboard Widget is today.
Bill
-
I am using the latest firefox version 26. But its not a big deal since i can make it work the other way. I did check with internet explorer and it does work correctly.
And thanks again for all the work that you put into adding separate engines. Its much easier and cleaner then how i was adding them manually. :)
-
Smooth transition. I'm amazed at how much this package has progressed in such a short time. Great job Bill.
-
I am using the latest firefox version 26. But its not a big deal since i can make it work the other way. I did check with internet explorer and it does work correctly.
And thanks again for all the work that you put into adding separate engines. Its much easier and cleaner then how i was adding them manually. :)
I will see if I can fix it for Firefox. There are some other potential issues with the way I did the session state according to Ermal, so I will research a better way to accomplish the goal. I will also be sure the final result works in IE, Firefox and Chrome.
Glad you can use the multi-engine feature. That was a GUI feature I had been thinking about adding for quite some time.
Bill
