This is a weird bug to me. A minimal and working snort.conf is attached. I am running snort in inline mode using a standard AMD64 hardened setup and typical userspace redirections; /sbin/iptables -A INPUT -i eth0 -p tcp --sport 80 -j QUEUE /sbin/iptables -A INPUT -i eth0 -p tcp --dport 80 -j QUEUE /sbin/iptables -A OUTPUT -o eth0 -p tcp --dport 80 -j QUEUE and everything works or so it seems. As you can see from the attached snort.conf, there are only two rulesets loaded: local.rules and web-cgi.rules. Everything works when the first one is empty (the default) and the latter contains the default rules shipped with the snort (syncing with oinkmaster does not change the picture). Now when I move the first rule from the web-cgi.rules (or any rule from any ruleset; or write my own rule) so that cat local.rules # $Id: local.rules,v 1.11 2004/07/23 20:15:44 bmc Exp $ # ---------------- # LOCAL RULES # ---------------- # This file intentionally does not come with signatures. Put your local # additions here. # First sid from web-cgi.rules for a demonstration. alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-CGI HyperSeek hsx.cgi directory traversal attempt"; flow:to_server,established; uricontent:"/hsx.cgi"; content:"../../"; content:"%00"; distance:1; reference:bugtraq,2314; reference:cve,2001-0253; reference:nessus,10602; classtype:web-application-attack; sid:803; rev:11;) everything works until I uncomment the web-cgi.rules from the snort.conf so that only local.rules gets loaded: ... # Load (defaults to empty) local ruleset. include $RULE_PATH/local.rules # Webservers and clients. # include $RULE_PATH/web-cgi.rules ... in which case restarting /etc/init.d/snort gives a nasty segfault: Jul 26 10:19:51 zap *** stack smashing detected ***: snort - terminated Jul 26 10:19:51 zap snort[20002]: segfault at 00000000c5d82f5f rip 00002e7ba09b025f rsp 00007b88a8a8bc58 error 4 Jul 26 10:19:51 zap grsec: From 192.168.4.100: signal 11 sent to /usr/bin/snort[snort:20002] uid/euid:0/0 gid/egid:0/0, parent /sbin/runscript.sh[runscript.sh:19999] uid/euid:0/0 gid/egid:0/0 Jul 26 10:19:51 zap grsec: From 192.168.4.100: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /usr/bin/snort[snort:20002] uid/euid:0/0 gid/egid:0/0, parent /sbin/runscript.sh[runscript.sh:19999] uid/euid:0/0 gid/egid:0/0 Jul 26 10:19:51 zap grsec: From 192.168.4.100: signal 11 sent to /usr/bin/snort[snort:20002] uid/euid:0/0 gid/egid:0/0, parent /sbin/runscript.sh[runscript.sh:19999] uid/euid:0/0 gid/egid:0/0 Jul 26 10:19:51 zap grsec: From 192.168.4.100: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /usr/bin/snort[snort:20002] uid/euid:0/0 gid/egid:0/0, parent /sbin/runscript.sh[runscript.sh:19999] uid/euid:0/0 gid/egid:0/0 The same behavior was tested to apply both to 2.6.1.3-r1 and 2.6.1.4. I have no idea what is going on in here; please request more information and try to reproduce.
Created attachment 126043 [details] emerge --info
Created attachment 126045 [details] snort.conf
Addition: this happens also with all current versions of libpcap (0.9.4, 0.9.5 and 0.9.6).
amd64: someone to verify / help?
Have you tried with snort-2.7.0.1? (maybe, you can try using same ebuild on your local overlay...)
snort-2.6.1.4 with libpcap-0.9.7 works for me, but (In reply to comment #0) > Jul 26 10:19:51 zap *** stack smashing detected ***: snort - terminated /me blames hardened
(In reply to comment #6) > > Jul 26 10:19:51 zap *** stack smashing detected ***: snort - terminated > /me blames hardened Erm, heh, good catch :) Please retry with vanilla gcc to verify this is a hardened issue
It seems amd64 has nothing to do here... CC us back if there's further testing and if it's arch specific and not just hardened doing shit.
There is a new ebuild for snort-2.8.4 at the following bug... #266288 You should upgrade to this version and try again.
(In reply to comment #9) > There is a new ebuild for snort-2.8.4 at the following bug... > > #266288 > > You should upgrade to this version and try again. > bug#266288
Reopen if still an issue with 2.8.4
