Project

General

Profile

Actions

Bug #2581

closed

Snort unexpectedly terminates / signal 11 error

Added by Anonymous over 12 years ago. Updated over 10 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
Snort
Target version:
Start date:
08/07/2012
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Affected Version:
2.1
Affected Plus Version:
Affected Architecture:
i386

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

Actions #1

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

Actions #2

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.

Actions #3

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.

Actions #4

Updated by David Gessel over 11 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.

Actions #5

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

Actions

Also available in: Atom PDF