Snort stops working after snort update (newest 2.0 RELEASE)
-
I am not sure what you guys are doing to get snort to work… I still cant get snort to log and or block.
Reinstalling does not fix problem.
To get it to run, I uninstalled snort
then I installed snort
I uncheck Keep snort settings after deinstall, save
I click Reset, save
I uninstalled snort againAfter that, I installed snort and started from scratch.
It is working, but it did not restart after the last automatic update, same problem as pfsenseddc mentionned:
the2011-11-06 00:05:38 Daemon.Info xxx SnortStartup[54021]: Snort Startup files Sync... 2011-11-06 00:05:38 Daemon.Info xxx SnortStartup[55697]: Snort already running, soft restart 2011-11-06 00:05:38 Daemon.Info xxx SnortStartup[55926]: Snort Soft Reload For 18203_pppoe0... 2011-11-06 00:05:39 Daemon.Notice xxx snort[17907]: 2011-11-06 00:05:39 Daemon.Notice xxx snort[17907]: --== Reloading Snort ==-- 2011-11-06 00:05:39 Daemon.Notice xxx snort[17907]: 2011-11-06 00:05:39 Daemon.Notice xxx snort[17907]: PortVar 'HTTP_PORTS' defined : --- 2011-11-06 00:06:13 Daemon.Notice xxx snort[17907]: Warning: 'ignore_any_rules' option for Stream5 UDP disabled because of UDP rule with flow or flowbits option 2011-11-06 00:06:13 Daemon.Error xxx snort[17907]: http_inspect: Changing decompress_depth requires a restart. 2011-11-06 00:06:14 Daemon.Notice xxx snort[17907]: Reload via Signal HUP does not work if you aren't root or are chroot'ed. 2011-11-06 00:06:14 Kernel.Info xxx kernel: pppoe0: promiscuous mode disabled 2011-11-06 00:06:16 Daemon.Notice xxx snort[17907]: =============================================================================== 2011-11-06 00:06:16 Daemon.Notice xxx snort[17907]: Packet I/O Totals: --- 2011-11-06 00:06:16 Daemon.Notice xxx snort[17907]: +-----------------------[filtered events]-------------------------------------- 2011-11-06 00:06:16 Daemon.Notice xxx snort[17907]: | gen-id=1 sig-id=2013479 type=Both tracking=src count=20 seconds=360 filtered=5 2011-11-06 00:06:16 Daemon.Notice xxx snort[17907]: | gen-id=1 sig-id=2002911 type=Threshold tracking=src count=5 seconds=60 filtered=3 2011-11-06 00:06:16 Daemon.Notice xxx snort[17907]: | gen-id=1 sig-id=2001219 type=Threshold tracking=src count=5 seconds=120 filtered=2 2011-11-06 00:06:16 Daemon.Notice xxx snort[17907]: | gen-id=1 sig-id=2001972 type=Both tracking=src count=20 seconds=360 filtered=1 2011-11-06 00:06:16 Daemon.Notice xxx snort[17907]: | gen-id=120 sig-id=3 type=Suppress tracking=none filtered=158 2011-11-06 00:06:18 Daemon.Notice xxx snort[17907]: Snort exitingMaybe you can spot this behaviour by looking at the Status: RRD Graphs / System / Processor
the graph will show almost no User Nice utilisation after restart or update. -
Hi,
When one triggers 'Update rules' the snort is restarting using SIGHUP - according to code at file /usr/local/pkg/snort/snort.inc, line 1278.
But when you look at system.log you see following entries:(...) Nov 6 08:26:09 pfsense SnortStartup[31407]: Snort Startup files Sync... Nov 6 08:26:09 pfsense SnortStartup[33474]: Snort already running, soft restart (...) Nov 6 08:26:40 pfsense snort[20195]: Reload via Signal HUP does not work if you aren't root or are chroot'ed. (...) Nov 6 08:26:43 pfsense snort[20195]: Snort exitingI guess that is the reason why manual stop/start works, but automatic one doesn't.
Kind regards,
–
John@pfsenseddc: Yes, that is more or less what I discovered and wrote in the bug report:
http://redmine.pfsense.org/issues/1982 -
@Seb:
(…)
Yes, that is more or less what I discovered and wrote in the bug report:
http://redmine.pfsense.org/issues/1982
(...)Below is ugly but quick fix that works for me (output from command: diff /usr/local/pkg/snort/snort.inc /usr/local/pkg/snort/snort.inc_org):
1278,1281c1278 < # developer sar:20111031 - SIGHUP doesn't work if snort is running chrooted or if php is not running as root < # before: # /bin/kill -HUP \${snort_pid} < /bin/kill \${snort_pid} < sleep 10 --- > /bin/kill -HUP \${snort_pid}You probably need to restart the pfsense after modification or/and modify /usr/local/etc/rc.d/snort.sh manually also.
Regards,
–
John -
@Seb:
(…)
Yes, that is more or less what I discovered and wrote in the bug report:
http://redmine.pfsense.org/issues/1982
(...)Below is ugly but quick fix that works for me (output from command: diff /usr/local/pkg/snort/snort.inc /usr/local/pkg/snort/snort.inc_org):
1278,1281c1278 < # developer sar:20111031 - SIGHUP doesn't work if snort is running chrooted or if php is not running as root < # before: # /bin/kill -HUP \${snort_pid} < /bin/kill \${snort_pid} < sleep 10 --- > /bin/kill -HUP \${snort_pid}You probably need to restart the pfsense after modification or/and modify /usr/local/etc/rc.d/snort.sh manually also.
Regards,
–
JohnGood job guys, glad this got figured out. Hopefully this is reflected in the package code soon.
-
How many users are having this issue? I've been running snort for a while now with no issues at all. It auto updates everyday and starts right after. Anyone running pfSense 2.1-dev have is having this issue? I'm running the same package as you guys (unless your running snort-dev; which doesn't work) but I'm using 2.1 code for IPv6 support.
-
How many users are having this issue? I've been running snort for a while now with no issues at all. It auto updates everyday and starts right after. Anyone running pfSense 2.1-dev have is having this issue? I'm running the same package as you guys (unless your running snort-dev; which doesn't work) but I'm using 2.1 code for IPv6 support.
Cino,
Everybody on 2.0-Release is having this issue. They must be applying code changes to 2.1 and is probably why it works.
The latest snort fully broke my system making me go away from it. And unless there is money on the plate… fixes will not come around any time soon.
We should start thinking about a bounty. -
Everybody on 2.0-Release is having this issue.
I wouldn't say everyone on 2.0-release. That's like when I get call from someone in the call center saying that all the computers are down but in fact its only few.
I know of few other users that have snort working on 2.0. Some functions do not work like barnyard2 but overall its working for them. Strange tho…is it not working for both i386 and amd64?
-
Everybody on 2.0-Release is having this issue.
I wouldn't say everyone on 2.0-release. That's like when I get call from someone in the call center saying that all the computers are down but in fact its only few.
I know of few other users that have snort working on 2.0. Some functions do not work like barnyard2 but overall its working for them. Strange tho…is it not working for both i386 and amd64?
I disagree. You cant compare the two that's a bad analogy ;)
If the code is broken than the code will be broken across the board…. well most of it.
Yes architecturally might be different causing the code to change but the broad majority will be i386/x86_64 where the code can not be that much different... in any case I tested both and had the same issue.
I am not sure about embedded. -
x86_64? Don't you mean amd64? If i remember x86_64 didn't go anywhere and Intel ended up using the Amd64 architecture for 64bit processes… thats off topic now
The binaries are different between them and I remember during testing, there where issues with amd64 at first. Let me fire up a new test VM and see if i can reproduce what your seeing
If the code that pfsenseddc gave is the fix to the issue, and other users can confirm them. Open a ticket so it can be added.. Looking at the change, its just adding a delay to the restart process.
-
Cino - I can tell you that this problem is isolated to certain hardware; the Intel P3 w/ 512mb RAM that I run Snort with pfSense 2.0 is more stable with updates, than my Dell PE 1750 Xeon w/ 3gb RAM, which doesn't support 64bit. The Xeon always seems to take time to start and stop the service, so a delay in the process after updates might be the fix. I don't know… I'm willing to try anything that could help. I am getting tired of manually doing updates twice in a row to get the service to run.
Thanks!
-
@Seb:
(…)
Yes, that is more or less what I discovered and wrote in the bug report:
http://redmine.pfsense.org/issues/1982
(...)Below is ugly but quick fix that works for me (output from command: diff /usr/local/pkg/snort/snort.inc /usr/local/pkg/snort/snort.inc_org):
1278,1281c1278 < # developer sar:20111031 - SIGHUP doesn't work if snort is running chrooted or if php is not running as root < # before: # /bin/kill -HUP \${snort_pid} < /bin/kill \${snort_pid} < sleep 10 --- > /bin/kill -HUP \${snort_pid}You probably need to restart the pfsense after modification or/and modify /usr/local/etc/rc.d/snort.sh manually also.
Regards,
–
JohnI put this in the package so just reinstall and try out.
-
Cino,
I stand corrected. Thanks for the info.
-
(…)
Looking at the change [that pfsenseddc made] , its just adding a delay to the restart process.
(…)The ten seconds delay probably does not matter. The important part is replacing 'kill -HUP' with 'kill [-TERM]'.
Regards,
–
John -
All been working ok for me since the update.
Thank You.
-
I reinstalled, I saw the 10 sec delay in the snort.inc file.
BUT nothing is logged nothing is blocked, Blocked list show N/A
Found strange behaviors in the process …
This appeared just after the reinstall in the snortglobal/rule section of the config file
It disappeared after a save in the processor tab …
So I cleared the Alerts, I cleared the Blocked.
I removed snort, I installed snortThis disappeared from the cron section of the config file after the install
<minute>*/15</minute> <hour>*</hour> <mday>*</mday> <month>*</month> <wday>*</wday> <who>root</who> <command></command>/usr/bin/nice -n20 /usr/local/sbin/expiretable -t 10800 snort2cI did a save and it reappeared in the cron section
I started snort and voila I have Alert and Blocked ip ::)
So on my side Reinstalling snort does not work. maybe I should clear the Blocked and Alert before doing a reinstall.
I will see if the updates works at midnight. Bummer it fails …. exiting, manual start is ok.
The next thing to see if snort block the WAN IP when the IP change.
I looked at my log when the last IP was changed and snort started or restarted 3-4 times until it settled blocking the WAN IP. I check and the Whitelist file is updated correctly after the IP change. However snort block it, exited and restarted. Now with the 10 seconds delay, this might not happen.
I had to stop and start Snort manually after removing the WAN IP from the Blocked list.
So when it start, could snort filter from the block list with the whitlist?
One question ... why use KILL -HUP ? Any reason why not stop and start snort instead?
-
One question … why use KILL -HUP ? Any reason why not stop and start snort instead?
1. When one use stop/start sequence to restart Snort the performance and statistics counters (displayed at syslog when sending SIGUSR1 to Snort) are gone and cleared.
2. Be careful if you want to call /usr/local/etc/rc.d/snort.sh to stop/start/restart Snort - especially in /usr/local/pkg/snort/snort.inc handler. The file snort.sh is automatically generated by snort.inc so it can be easy to get unpredictable behavior while Snort is starting.Regards,
–
John -
(…)
Looking at the change [that pfsenseddc made] , its just adding a delay to the restart process.
(…)The ten seconds delay probably does not matter. The important part is replacing 'kill -HUP' with 'kill [-TERM]'.
Regards,
–
JohnThe only change that ermal made was to add a the 10 sec delay… "kill -HUP' with 'kill [-TERM]" was not added to the package
https://github.com/bsdperimeter/pfsense-packages/commit/cecd19f0a2843d104465b792018c005d113b5ed5
-
(…)
Looking at the change [that pfsenseddc made] , its just adding a delay to the restart process.
(…)The ten seconds delay probably does not matter. The important part is replacing 'kill -HUP' with 'kill [-TERM]'.
Regards,
–
JohnI guess this is why I still have the issue with it not restarting after updates even after reinstalling Snort. When I manually make that edit it seems to work fine. They only added the 10 second delay not the kill line.
-
Reinstall the package at least the reloading should be correct now and snort should not exit anymore as reported here.
-
It seems that compiling snort with –enable-reload will allow snort to reload on receiving a SIGHUP without requiring it to be running as root.
http://groups.google.com/group/pulledpork-users/browse_thread/thread/00acf6e138df1a07
I run my snort instances as -u snorty.. sending a HUP from root works fine
for me and has, it is much cleaner now though than the –enable-reload
option has been added (and I configured with that) into snort.On Tue, Jan 26, 2010 at 5:00 PM, William wil...@gmail.comwrote:
It doesn't seem to matter if I am root or not when I send the HUP.
What seems to make a difference is whether or not snort itself is
running as root or as another user (eg. started as snort -u
someotheruser). If it is NOT running as root, then snort will respond
with the "Reload via Signal HUP..." message and not re-read its
config.
I posted a similar question to the Snort users list and someone from
Sourcefire explained the reasoning (snort needs to open pcap again,
which requires root privileges)/wil...@gmail.com
