Bug #2581
closedSnort unexpectedly terminates / signal 11 error
0%
Description
On the latest build (see details) I can't get snort to stay up. It seems to always exit with a signal 11 error.
I was able to fix the issue by replacing the binary in /usr/pbi/snort-i386/bin with a previous version of the binary (from the backup that was generated during the update process).
--
2.1-BETA0 (i386)
built on Tue Aug 7 08:03:45 EDT 2012
FreeBSD pfsense.pvt 8.3-RELEASE-p4 FreeBSD 8.3-RELEASE-p4 #1: Tue Aug 7 09:03:11 EDT 2012 root@FreeBSD_8.3_pfSense_2.1.snaps.pfsense.org:/usr/obj./usr/pfSensesrc/src/sys/pfSense_wrap.8.i386 i386
Updated by Anonymous over 12 years ago
Well, the file replacement doesn't seem to work either. Snort just died again. Here's the error message from the syslog ...
Aug 7 19:26:44 kernel: em0: promiscuous mode disabled
Aug 7 19:26:44 kernel: pid 60685 (snort), uid 0: exited on signal 11
Aug 7 19:26:44 kernel: pid 25101 (snort), uid 0: exited on signal 11
Updated by Jim Pingle over 12 years ago
- Status changed from New to Closed
Sig 11 is almost always hardware, but not always. If it was a widespread issue, people would have been seeing it for some time now as the snort binaries haven't been updated in a few weeks.
Unless it's repeatable by others and/or on different hardware, there probably isn't anything wrong here. Check your ram, fans, psu, etc.
Updated by Cimpean Andrei almost 12 years ago
Hello, It's not a hardware issue, I tested on several pc-s Intel and AMD processors, It seems to be a rule issue, When I put these two rules
#tcp
alert tcp !$HOME_NET any -> $HOME_NET ![27000:30000,9987] (flags: S; msg:"Possible TCP DoS"; flow: stateless; threshold: type both, track by_src, count 200, seconds 1; sid:10001;rev:1;)
#udp
alert udp !$HOME_NET any -> $HOME_NET ![27000:30000,9987] (msg:"Possible UDP DoS"; flow: stateless; threshold: type both, track by_src, count 300, seconds 1; sid:10002;rev:1;)
when the alert is triggerd snort is exiting on signal 11.
Those 2 rules were verry important to me, can you plese tell me an alternative to them or can you please solve this problem?
With the old snort package in pfsense those 2 rules worked just fine.
Thank you.
Updated by David Gessel almost 12 years ago
I get sig 11 (segmentation fault) failures as well.
Mar 23 17:04:42 kernel: em1: promiscuous mode disabled Mar 23 17:04:42 kernel: pid 60907 (snort), uid 0: exited on signal 11 Mar 23 17:04:37 php: /snort/snort_download_rules.php: The Rules update has finished... Mar 23 17:04:37 php: /snort/snort_download_rules.php: Snort has restarted with your new set of rules... Mar 23 17:04:15 SnortStartup[61096]: Snort START For snort rules(30698_em1)... Mar 23 17:04:15 kernel: em1: promiscuous mode enabled
( Snort 2.9.4.1 pkg v. 2.5.4 on 2.1-BETA1 (i386) built on Fri Mar 22 22:56:09 EDT 2013 )
Sig 11 is almost never a hardware issue. It means the program tried to access a memory location that was not assigned. It could happen with bad memory that isn't properly detected as bad by the mobo, but actual memory failures are far less frequent than programmatic memory access errors. Snort seems particularly prone to these, and it seems most common with rule set changes. In some versions I've found re-editing the rule set or reinstalling snort solves the problem. Currently the first restart attempt after an update results in a seg fault. Seg faults also occur randombly.
Updated by Dmitry Aleksandrov over 10 years ago
Hi All. I found that snort builded for pfsense have one nasty future. All your rulse must have classtype specified. Available classes are http://manual.snort.org/node31.html#SECTION00446000000000000000
In your example:
alert tcp !$HOME_NET any -> $HOME_NET ![27000:30000,9987] (flags: S; msg:"Possible TCP DoS"; flow: stateless; threshold: type both, track by_src, count 200, seconds 1; sid:10001;rev:1;)
gives "exited on signal 11"
but modified string
alert tcp !$HOME_NET any -> $HOME_NET ![27000:30000,9987] (flags: S; msg:"Possible TCP DoS"; flow: stateless; threshold: type both, track by_src, count 200, seconds 1; sid:10001;rev:1; classtype: denial-of-service; )
should works fine