New Snort pkg 2.5.5 – Read Before you Update to Understand Changed Defaults

bmeeks

Snort 2.9.4.1 pkg version 2.5.5

New or Changed Features

Note: in cases where defaults were changed, this means defaults on a new install where no "saved settings" were brought back from a previous installation. If you had something "off" in your saved settings, it will remain "off" when this new version is installed regardless of what the new default setting is. Depending on what parameter you have set to "off", you may be impacted by changes #6 and #7.

1. Added stability, reliability and logging to Rule Updates performed from the UPDATES tab or scheduled via cron jobs.

2. Enabled VIEW LOG button on UPDATES tab so that logged information from rule update runs can be viewed. Log is limited to 1024K in size, and automatically clears when the limit is reached.

3. Added support for the new Snort GPLv2 Community Rules. This rule set is a free download and contains current community-authored detection rules for Snort. Note that this rule package is a subset of the Snort VRT rule package available to paid VRT subscribers. If you have a paid subscriber account, then there is no real benefit to installing the GPLv2 Community Rules along with the Snort VRT rules.

4. Added a user configurable setting to protect the Snort preprocessor text rules files from being over-written by an automatic or manual rule set update. This setting defaults to OFF, since most users will want the latest preprocessor rules updates. This setting would be useful if you maintain customized sensitive-data rules, for example.

5. Made the Snort package compliant with the PBI install process when it detects installation on a 2.1-BETA or higher platform. The detection key is the FreeBSD version on the platform. Versions equal to or greater than 8.3 perform a PBI-compliant installation with all configuration files in /usr/local/snort-{arch}/etc/snort/ where {arch} is "i386" for 32-bit platforms or "amd64" for 64-bit platforms.

Key Change in Former Default Behavior – read and understand before you upgrade
6. Changed a formerly automatic and somewhat hidden feature into a user-configurable setting. Snort on pfSense has the ability to examine your enabled preprocessors and compare them to your selected and enabled rules. When it finds an enabled rule with a dependency on a disabled preprocessor, it can disable the rule. Doing so allows Snort to start without "missing preprocessor" errors. Formerly this action was automatic and hidden from the user. It is now user-configurable on a per-interface basis on the PREPROCESSORS tab. If enabled, the actions taken by this feature are logged in the /var/log/snort directory in separate files named for each interface. The feature now defaults to OFF. If you want the old behavior from the previous Snort version, you must set this feature to ON.

Enabling this feature will make your Snort installation less effective, but some users may accept the risk in order to avoid the hassles of selecting preprocessors. Use this feature AT YOUR OWN RISK! It is recommended you leave it at the default OFF setting. If you enable the Auto-Rule Disable feature, be sure to check the log file in /var/log/snort to see what rules were disabled. You may be surprised! The log file will be obvious and have the interface's name in the filename.

Note – the change in #6 above can impact you with "http_inspect" if you formerly had it disabled
7. Toggled the default state of the HTTP_INSPECT preprocessor to ON from its former default of OFF. This was done because so many of the Snort and Emerging Threats rules require the HTTP_INSPECT preprocessor to be enabled. Because this preprocessor can generate a considerable number of false positives in many setups, the HTTP_INSPECT_NO_ALERTS option was also defaulted to ON in this version. This combination allows the HTTP_INSPECT preprocessor to normalize HTTP traffic for the rules that need it, yet suppresses all the alerts from the preprocessor.

If you want to enable the HTTP_INSPECT alerts, toggle the HTTP_INSPECT_NO_ALERTS option to OFF on the PREPROCESSORS tab in the HTTP_INSPECT section.

8. Improved the process for installing, removing and reinstalling the Snort package. The package should now correctly handle either a package GUI components reinstall, or a package delete and install operation.

9. Default for new clean installs now enables the Auto-Flowbit Resolution feature on the CATEGORIES tab. It is highly recommended that all users enable this feature for optimum threat detection. If a flowbit-required rule produces unwanted alerts, add the GID:SID to the Suppression List. As per the note above, if you previously had this option disabled and reinstalled with "save settings on", then it will remain disabled. The recommendation is that you enable the Auto-Flowbit Resolution feature.

Bug Fixes

1. Fixed GUI crash when deleting the final remaining Snort interface on the SNORT INTERFACES tab.

2. Fixed bug that caused the three preprocessor rules files; "decoder.rules", "preprocessor.rules" and "sensitive-data.rules"; to not be correctly copied to the interface's configuration sub-directory. This bug impacted FreeBSD 8.3 systems using the PBI package.

3. Fixed a few issues with HTML formatting on the GUI pages.

Supermule

Thanks SOOOOO much Bill!!

bmeeks

@Supermule:

Thanks SOOOOO much Bill!!

You are welcome. A shout out to the pfSense team for being quick to review the code submission and approve it!

Bill

Topper727

Good job.. I seen the changes worked good. Nice explanation of fixes. I like knowing what to expect when I get updates on packages or pfsense itself.

kilthro

Thanks so much Bill! Removed prior version then installed this one (did keep settings and all carried over fine). So far so good. This writeup was very clear and should help address any questions on the changes.

kilthro

Bill since the upgrade the auto rule update has not completed successfully. The update log looks ok with no errors. The only thing that appears in the sys log is snort[43971]: Could not remove pid file /var/run/snort_em21407.pid: No such file or directory. I did completely remove snort and install manually. Did not use reinstall . I did keep settings from previous install though. My next step is to clean reinstall without keeping settings. But before I do is there anything else I can check/change/remove? I really don't want to have to set up snort again from scratch.

bmeeks

@kilthro:

Bill since the upgrade the auto rule update has not completed successfully. The update log looks ok with no errors. The only thing that appears in the sys log is snort[43971]: Could not remove pid file /var/run/snort_em21407.pid: No such file or directory. I did completely remove snort and install manually. Did not use reinstall . I did keep settings from previous install though. My next step is to clean reinstall without keeping settings. But before I do is there anything else I can check/change/remove? I really don't want to have to set up snort again from scratch.

This error:

snort[43971]: Could not remove pid file /var/run/snort_em21407.pid: No such file or directory.

is harmless and is a warning only. It's a byproduct of the restart process deleting the PID file during stopping of Snort before the pkill command gets to it. This is done to be 100% sure an existing leftover PID file does not interfere with subsequent starts of Snort. So long explanation to say that error has nothing to do with the rules updating successfully or not.

Look at the Update Log using the new button on the UPDATES tab. If you see nothing alarming in there, things are probably OK. You can double-check by looking at the timestamp on the file snort.rules in the rules directory for your interface.

If you like, post the contents from the View Update Log window and I will review them. You get there by clicking the VIEW LOG button on the UPDATES tab.

Bill

kilthro

Thanks for the explanation Bill.

I have checked the update log within Snort and all appears fine there. Everything shows successful. However, Snort does not restart. Even in the system log it says that its restarting on my wan interface. There is no fatal error or anything else displayed showing that it could not restart. When i got into snort and click enable it starts up just fine. So I am at a loss on why its not restarting. In the previous versions if it failed to restart usually there was a fatal error displayed in the system log saying why it errored out.

I just vpned in and grabbed the update log as well as the same time frame on the sys log. Maybe something fatal with a rule? Not sure… I have not changed any other settings to make this fail. Not sure if you need any other settings that are enabled.

System log
Apr 17 00:04:02 php: : The Rules update has finished.
Apr 17 00:04:02 php: : Snort has restarted with your new set of rules…
Apr 17 00:04:00 SnortStartup[36366]: Snort SOFT START For Wan(1407_em2)…
Apr 17 00:04:00 snort[43971]: Could not remove pid file /var/run/snort_em21407.pid: No such file or directory
Apr 17 00:04:00 snort[43971]: Could not remove pid file /var/run/snort_em21407.pid: No such file or directory
Apr 17 00:03:59 kernel: em2: promiscuous mode disabled
Apr 17 00:03:59 snort[43971]: *** Caught Term-Signal
Apr 17 00:03:59 snort[43971]: *** Caught Term-Signal
Apr 17 00:03:58 SnortStartup[26068]: Snort STOP For Wan(1407_em2)…
Apr 17 00:03:55 php: : Building new sig-msg.map file for WAN...
Apr 17 00:03:43 php: : Resolving and auto-enabling any flowbit-required rules for WAN...
Apr 17 00:03:38 php: : Updating rules configuration for: WAN ...
Apr 17 00:03:38 php: : EmergingThreats rules file update downloaded succsesfully
Apr 17 00:03:36 php: : There is a new set of EmergingThreats rules posted. Downloading...
Apr 17 00:03:35 php: : Snort VRT rules are up to date...
Apr 17 00:03:35 php: : Snort MD5 Attempts: 1

Snort update log
Starting rules update… Time: 2013-04-16 00:03:01
Downloading Snort VRT md5 file...
Checking Snort VRT md5 file...
Snort VRT rules are up to date.
Downloading EmergingThreats md5 file...
Checking EmergingThreats md5.
There is a new set of EmergingThreats rules posted. Downloading...
Done downloading EmergingThreats rules file.
Extracting and installing EmergingThreats.org rules...
Installation of EmergingThreats.org rules completed.
Copying new config and map files...
Updating rules configuration for: WAN ...
Restarting Snort to activate the new set of rules...
Snort has restarted with your new set of rules.
The Rules update has finished. Time: 2013-04-16 00:05:27

Starting rules update... Time: 2013-04-17 00:03:01
Downloading Snort VRT md5 file...
Checking Snort VRT md5 file...
Snort VRT rules are up to date.
Downloading EmergingThreats md5 file...
Checking EmergingThreats md5.
There is a new set of EmergingThreats rules posted. Downloading...
Done downloading EmergingThreats rules file.
Extracting and installing EmergingThreats.org rules...
Installation of EmergingThreats.org rules completed.
Copying new config and map files...
Updating rules configuration for: WAN ...
Restarting Snort to activate the new set of rules...
Snort has restarted with your new set of rules.
The Rules update has finished. Time: 2013-04-17 00:04:02

bmeeks

@kilthro:

I have checked the update log within Snort and all appears fine there. Everything shows successful. However, Snort does not restart. Even in the system log it says that its restarting on my wan interface. There is no fatal error or anything else displayed showing that it could not restart. When i got into snort and click enable it starts up just fine. So I am at a loss on why its not restarting. In the previous versions if it failed to restart usually there was a fatal error displayed in the system log saying why it errored out.

That's really weird that it starts manually but not after an auto-update. Give me your pfSense version (2.0.x or 2.1-BETA) and which rule sets you have enabled for download. I assume from the log info that you have Snort VRT and Emerging Threats enabled. Do you have the paid VRT subscription or the free registered user account?

Just so I'm clear on your manual start method, do you go to the Snort Interfaces tab and click the icon there, or are you using the Services option from the pfSense menu?

Bill

kilthro

@bmeeks:

That's really weird that it starts manually but not after an auto-update. Give me your pfSense version (2.0.x or 2.1-BETA) and which rule sets you have enabled for download. I assume from the log info that you have Snort VRT and Emerging Threats enabled. Do you have the paid VRT subscription or the free registered user account?

Just so I'm clear on your manual start method, do you go to the Snort Interfaces tab and click the icon there, or are you using the Services option from the pfSense menu?

Bill

Bill I am currently on pfsense 2.0.2-release (i386) built on Friday Dec 7 (I have not upgraded to the newer version released within the past week)

I have a paid subscription to Snort VRT. I do have Snort VRT and Emerging Threats enabled. I do not have the Snort GPLv2 enabled.
All rule categories are enabled with the exclusion of the snort_p2p.rules and the snort_p2p.so.rules.

I do have a list of suppression ids that I do not want to kick up as an alert.

When I do the manual start I go to the Service menu up top > Snort. Then on the interface tab click the Green Arrow. Then snort starts just fine with no issue turning the green arrow to a red box with an X in it. Nothing else has been touched/changed in between the failed start to starting snort successfully.

I really wish there was a retry option or monitor option. If snort fails to start or when a check is done lets say every 30 min and it finds that snort is not running that it will try to restart it.

bmeeks

@kilthro:

Bill I am currently on pfsense 2.0.2-release (i386) built on Friday Dec 7 (I have not upgraded to the newer version released within the past week)
…

When I do the manual start I go to the Service menu up top > Snort. Then on the interface tab click the Green Arrow. Then snort starts just fine with no issue turning the green arrow to a red box with an X in it. Nothing else has been touched/changed in between the failed start to starting snort successfully.

I really wish there was a retry option or monitor option. If snort fails to start or when a check is done lets say every 30 min and it finds that snort is not running that it will try to restart it.

You are not the first to request some sort of Snort monitor. That's something I can ponder on incorporating for a future update.

As for your more immediate problem, first make sure that you do a package GUI components reinstall to be sure you have the very latest update. Go to Available Packages and click either the pkg or xml icons to reinstall the GUI components.

Here's another thing you can try to help me troubleshoot. It requires editing a file. Here are the steps:

1. From the menu, choose Diagnostics and then Edit File.
2. Browse to /usr/local/etc/rc.d/snort.sh and click it to open the file.
3. Scroll down and find this section:

	restart)
		rc_stop
		rc_start
		;;

Now edit that section so it looks like this:

	restart)
		rc_stop
		sleep 3
		rc_start
		;;

4. Click Save to save the edited file.

Let the next auto-update happen and see if Snort restarts. You will need to wait for an actual rule update to happen (that is, some new rules are posted). You can force this by simply deleting the two MD5 files in /usr/local/etc/snort. This will cause a re-download and update of both VRT and ET rules the next time the rule update job runs.

Let me know how this works for you.

Bill

judex

For Snort monitoring you could use a script like that


#!/bin/sh
SERVICE=snort
if P=$(/usr/bin/pgrep $SERVICE)
then
        /bin/echo "$SERVICE is running, PID is $P"
else
        /usr/local/etc/rc.d/snort.sh start
fi

and let it run every minute via cron. I used that a long time ago, when Snort shut down from time to time.
These days I just have shut downs after upgrades and no solution yet (the logs say snort was started after upgrade and nothing else, but I find it stopped). That is why I am reading here. (2.0.3 amd64, Snort PVer. 2.5.5)

Best wishes, Judex

kilthro

@bmeeks:

As for your more immediate problem, first make sure that you do a package GUI components reinstall to be sure you have the very latest update. Go to Available Packages and click either the pkg or xml icons to reinstall the GUI components.

Here's another thing you can try to help me troubleshoot. It requires editing a file. Here are the steps:

1. From the menu, choose Diagnostics and then Edit File.
2. Browse to /usr/local/etc/rc.d/snort.sh and click it to open the file.
3. Scroll down and find this section:
	restart)
		rc_stop
		rc_start
		;;
Now edit that section so it looks like this:
	restart)
		rc_stop
		sleep 3
		rc_start
		;;
4. Click Save to save the edited file.

Let the next auto-update happen and see if Snort restarts. You will need to wait for an actual rule update to happen (that is, some new rules are posted). You can force this by simply deleting the two MD5 files in /usr/local/etc/snort. This will cause a re-download and update of both VRT and ET rules the next time the rule update job runs.

Let me know how this works for you.

Bill

Bill for the reinstall/install piece, I have completely removed Snort (uninstalled it with just leaving settings within snort there) then went into available packages tab and installed it. I have done this twice with the same effect. Wouldn't this make sure all components are installed?

I changed the file via telnet. Its easier from my phone to do that then messing with the browser. :-D

I will post back after the auto update runs and let you know if it works or not.

Thanks for your help.

bmeeks

OK. Let me know if the time delay helps out any. The restart of Snort has been a sore spot for quite a while even before I started modifying the code a bit. I know Ermal tried a few different tricks about this time last year when he was making some significant updates to the Snort code.

It seems quite sensitive to the number of active rules users have. At least I've noticed that on my test virtual machines. The more rules, the longer the startup time for sure. I think that may be playing into the "randomness" of this issue among users. By that I mean it impacts some, but not others. Several things could be at play here. Number of active rules, capability (speed) of the underlying hardware, etc.

Bill

kilthro

Bill,

The auto update ran this morning at 12am and the same thing happened and Snort did not restart properly. I went and started it manually and it started up just fine. I pasted the logs again just incase you wanted to check em out.

SYS log
Apr 18 00:06:08 php: : The Rules update has finished.
Apr 18 00:06:04 php: : Building new sig-msg.map file for WAN…
Apr 18 00:05:52 php: : Resolving and auto-enabling any flowbit-required rules for WAN...
Apr 18 00:05:48 kernel: em2: promiscuous mode disabled
Apr 18 00:05:48 kernel: pid 44849 (snort), uid 0: exited on signal 4
Apr 18 00:05:48 php: : Updating rules configuration for: WAN ...
Apr 18 00:05:41 php: : EmergingThreats rules file update downloaded succsesfully
Apr 18 00:05:39 php: : There is a new set of EmergingThreats rules posted. Downloading...
Apr 18 00:05:39 php: : Snort Rules Attempts: 1
Apr 18 00:04:48 php: : There is a new set of Snort VRT rules posted. Downloading...
Apr 18 00:04:48 php: : Snort MD5 Attempts: 2

update log
Starting rules update… Time: 2013-04-18 00:03:01
Downloading Snort VRT md5 file...
Checking Snort VRT md5 file...
There is a new set of Snort VRT rules posted. Downloading...
Done downloading rules file.
Downloading EmergingThreats md5 file...
Checking EmergingThreats md5.
There is a new set of EmergingThreats rules posted. Downloading...
Done downloading EmergingThreats rules file.
Extracting and installing EmergingThreats.org rules...
Installation of EmergingThreats.org rules completed.
Extracting and installing Snort VRT rules...
Using Snort VRT precompiled SO rules for FreeBSD-8-1 ...
Installation of Snort VRT rules completed.
Copying new config and map files...
Updating rules configuration for: WAN ...
The Rules update has finished. Time: 2013-04-18 00:06:08

This is what the log looks like when i toggle manually I never see the promiscuous mode enabled line when it attempts the auto update and then restarts.

Apr 18 04:58:22 kernel: em2: promiscuous mode enabled
Apr 18 04:58:22 php: /snort/snort_interfaces.php: Interface Rule START for Wan(em2)...
Apr 18 04:57:47 php: /snort/snort_interfaces.php: Toggle(snort starting) for WAN(Wan)...

bmeeks

@kilthro:

Bill,

The auto update ran this morning at 12am and the same thing happened and Snort did not restart properly. I went and started it manually and it started up just fine. I pasted the logs again just incase you wanted to check em out.

OK. I discovered a clue in another user's post on the Snort 2.5.5 Issues Thread about the possible cause of this. I'm researching to be sure about the cause, then can issue a fix.

Bill

kilthro

Bill for what its worth, this problem also happens with the manual rules update. I disabled auto update so it wouldnt run last night. Then I manually did the rules update this morning and same behavior happened.

Supermule

Good catch! I posted some logs from last night regarding the soft start issue in Snort. Both FW's killed Snort after update despite one of them had the fix from Bill.

bmeeks

@kilthro:

Bill for what its worth, this problem also happens with the manual rules update. I disabled auto update so it wouldnt run last night. Then I manually did the rules update this morning and same behavior happened.

Did you have the change in the snort.sh file that removed the call to rc_stop() in the restart section of the file? The restart of Snort is called from within the GUI code that does the rules update, and it will call the restart script if the update is done manually or automatically.

Ermal reminded me of something else when I consulted him on this. A SOFT START of Snort will fail when a rule update contains updates to SO (Shared Objects) rules. That is one set of changes Snort cannot "refresh" without shutting down and restarting.

Bill

kilthro

@bmeeks:

@kilthro:

Bill for what its worth, this problem also happens with the manual rules update. I disabled auto update so it wouldnt run last night. Then I manually did the rules update this morning and same behavior happened.

Did you have the change in the snort.sh file that removed the call to rc_stop() in the restart section of the file? The restart of Snort is called from within the GUI code that does the rules update, and it will call the restart script if the update is done manually or automatically.

Ermal reminded me of something else when I consulted him on this. A SOFT START of Snort will fail when a rule update contains updates to SO (Shared Objects) rules. That is one set of changes Snort cannot "refresh" without shutting down and restarting.

Bill

The only thing I have done is edit the sleep as you requested.. I didnt see any thing mentioned removing the rc_stop… Did I miss that in a post?

Yea I know about the failed starts every now and then with the so rules.. Even prior to updating it would fail every once and a while and it was due to that.. not often but it would happen..

So what exactly do i need to remove and I will give that a shot? Is this being discussed in another thread too?

bmeeks

@kilthro:

So what exactly do i need to remove and I will give that a shot? Is this being discussed in another thread too?

It's from this post: http://forum.pfsense.org/index.php/topic,60994.msg330447.html#msg330447

That version of an interim fix may still get tripped up with the SO rules update issue. That one is just endemic to Snort. Snort is supposed to restart itself under those circumstances, though.

I am working on a permanent fix based on what I currently think is happening. Plan on revamping how the shell script works for these restarts (especially the stops). More feedback from folks having the problem is always welcome!

Bill

kilthro

@bmeeks:

@kilthro:

So what exactly do i need to remove and I will give that a shot? Is this being discussed in another thread too?

It's from this post: http://forum.pfsense.org/index.php/topic,60994.msg330447.html#msg330447

That version of an interim fix may still get tripped up with the SO rules update issue. That one is just endemic to Snort. Snort is supposed to restart itself under those circumstances, though.

I am working on a permanent fix based on what I currently think is happening. Plan on revamping how the shell script works for these restarts (especially the stops). More feedback from folks having the problem is always welcome!

Bill

Ahh.. let me make those changes and I will see if that fixes it. well as much as it can. Thanks

kilthro

Bill,
I am going to keep my replies going forward in the topic you linked so everything is together. As you can see in that post there I am having to redo the tests for you.