Snort 2.9.4.6 Pkg v 2.5.9

turker

Thank you so much.
The problem has been solved.

Atom D2500
4GB RAM
Pfsense 2.1

WAN+LAN+VLAN running smoothly.

Supermule

Does the name SNORT KING sound rude Bill? :D

maverick_slo

Morning all!

Rebooted 3 times no more snort issues.
Running smooth with AC-STD now.

Thanks man!

gogol

Thanks Bill, finally.

I booted a VM and have only 1 snort process now but still with the -E argument. Can you explain a bit what you changed or what was happening?

I am on 2.1 RELEASE.

/root(1): ps auxwwww | grep snort
root   57580  0.0 12.6 527956 260680  ??  Ss    1:13PM   0:11.61 /usr/pbi/snort-i386/bin/snort -R 4082 -E -q -l /var/log/snort/snort_em04082 --pid-path /var/run --nolock-pidfile -G 4082 -c /usr/pbi/snort-i386/etc/snort/snort_4082_em0/snort.conf -i em0
root   77957  0.0  0.1  3468  1240   0  S+    1:14PM   0:00.00 grep snort

bmeeks

Thanks for the testing and quick feedback guys. I will bundle this fix up with a few other bug hotfixes I've been holding and submit a GitHub Pull Request for the pfSense Core Team to review and hopefully approve and merge. The new package version will be 2.6.0 when it gets pushed to the Packages Repository. It will still use the 2.9.4.6 Snort binary.

I have a fully functional package based on the Snort 2.9.5.3 binary with a lot of new GUI features in the works. One of these new features is support for multi-engine configurations for the frag3, stream5_tcp and http_inspect preprocessors. There are also some new GUI configurable options for the SDF Sensitive Data preprocessor and a few others. I still need to do a bit more testing with this version before I release it.

Bill

bmeeks

@gogol:

Thanks Bill, finally.

I booted a VM and have only 1 snort process now but still with the -E argument. Can you explain a bit what you changed or what was happening?

I am on 2.1 RELEASE.
/root(1): ps auxwwww | grep snort
root   57580  0.0 12.6 527956 260680  ??  Ss    1:13PM   0:11.61 /usr/pbi/snort-i386/bin/snort -R 4082 -E -q -l /var/log/snort/snort_em04082 --pid-path /var/run --nolock-pidfile -G 4082 -c /usr/pbi/snort-i386/etc/snort/snort_4082_em0/snort.conf -i em0
root   77957  0.0  0.1  3468  1240   0  S+    1:14PM   0:00.00 grep snort

I don't know about the -E argument. What I changed in the code was to shorten the match argument list supplied to the pgrep utility. The shell script, when called with the start argument, first tries to see if there is any running Snort process for the interface. If it finds one, it sends that instance a SIGHUP (soft restart) signal instead of starting a totally new process. This prevents multiple Snort instances on the same interface.

The code described above has always been there, but was not working 100% due to a bug in the behavior of pgrep. I was using pgrep -xf [the complete command line]. The "-xf" argument tells pgrep to match exactly the entire command line list of arguments. Turns out that pgrep will silently fail to match very long arguments lists when given the "-x" exact-match parameter. Snort has a very long command line argument list. So the hunt for a running process on a given interface silently failed, and a second process would get started. This only happened on a reboot with a slow starting Snort configuration. The shell script also looks for a PID file in /var/run, and if one is found uses the PID in there to send the SIGHUP to the correct process. During a reboot, the PID file is generally not present; so the shell script falls back to the pgrep method to find the correct process. This problem is compounded by the fact pfSense itself launches two processes that each issue a restart all packages command. So during the reboot the Snort shell script gets called twice a few hundred milliseconds apart.

The fix was to change the pgrep parameters and match argument for both the stop and start routines in the shell script. The new code uses pgrep -f snort -R uuid where uuid is the unique number identifying the interface.

fragged

Should this fix multiple Snort processes being left over after rules updates? With my setup Snort takes a while to fully load all rules. For me Snort always launches correctly on boot up, but there might be multiple processes running after a few days of uptime.

bmeeks

@fragged:

Should this fix multiple Snort processes being left over after rules updates? With my setup Snort takes a while to fully load all rules. For me Snort always launches correctly on boot up, but there might be multiple processes running after a few days of uptime.

Yes, it should help with that as well. The same pgrep bug was in the STOP part of the script, also. Just make sure that any existing "extra processes" are killed manually, or else just reboot the box.

Bill

AhnHEL

Thank you for the fix Bill, when will this go Gold? v2.6.0?

bmeeks

@AhnHEL:

Thank you for the fix Bill, when will this go Gold? v2.6.0?

The code update has been submitted via a GitHub Pull Request. Here is a link to the request:

https://github.com/pfsense/pfsense-packages/pull/514

There are a few other fixes and new features included with the multiple processes bug fix.

The changes need to be reviewed, approved and merged by the pfSense Core Team before the new version shows up in the Package Repository.

Bill

shinzo

Hello Bill, was wondering if u fixed the typo in the snort.inc. It was "{$stream5_no_reassemble_async}$stream5_dont_store_lg_pkts" on line 3137, it was talked about on page 5 so like 100 years ago. :)

UPDATE

Nevermind just saw it was updated thanks again!

Derf

Looks like the 2.6.0 package has made it's way to the repository! :D
Let's test…

maverick_slo

Yep!

So far so good :)
Just updated 2 production boxes :)

bmeeks

@Derf:

Looks like the 2.6.0 package has made it's way to the repository! :D
Let's test…

Yep, the Core Team guys approved and merged the update earlier today. I also made a tweak to the Snort binary to fix the error message "SMTP: changing file_depth requires a restart" when attempting a soft-restart of Snort. I see the 2.1 PBI version of the new binary package has built already, but I did not see the 2.0.3 TBZ version posted yet. It should build and post soon, though.

So when you do the Snort update, I recommend a package remove and then re-install so you will pick up the new binary as well. You just want to check http://files.pfsense.org/packages/8/All/ and make sure the newest September 27 version of snort-2.9.4.6.tbz has been built and shows up.

Bill

maverick_slo

Hi!

snort-2.9.4.6.tbz is June version on the link u posted?

Regards,
M

bmeeks

@maverick_slo:

Hi!

snort-2.9.4.6.tbz is June version on the link u posted?

Regards,
M

UPDATE #2 (9:22 AM September 28): The updated Snort binary for 2.0.3 pfSense installs is now available in the files repository.

UPDATED INFO (9:30 PM September 27): I received a note back from the pfSense guys. There are some issues with getting the 2.0.3 binary packages rebuilt. The issues are generic with the Ports tree and not specific to Snort. It could be later this weekend or even early next week before the 2.0.3 binaries get rebuilt. If you have a 2.1 install, you are golden because the PBI packages are good to go.

If you want the new Snort GUI fixes, then go ahead and reinstall the Snort package now. Just click the PKG or XML icons. They both will do the same thing in terms of reinstalling the GUI PHP code. I will post back later when the new Snort binaries for 2.0.3 pfSense are built and posted.

**Original Post follows –- **
Yeah, I think maybe those rebuild overnight. I will e-mail the Core Team guys and have one of them check it out. The new binary is not a huge deal, but if you use the SMTP preprocessor and sometimes saw the message about "SMTP: changing file_depth requires a restart", then the updated binary will fix that (and allow Snort to soft-restart correctly).

It won't hurt anything to do a package reinstall by clicking the PKG or XML icon, then later when the new binary is posted you can do the remove and re-install then. The major bug fixes and new features are all in the GUI code anyway.

Bill