Snort stops working after snort update (newest 2.0 RELEASE)

Cino

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.

mentalhemroids

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!

eri--

@pfsenseddc:

@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

I put this in the package so just reinstall and try out.

serialdie

Cino,

I stand corrected. Thanks for the info.

pfsenseddc

@Cino:

(…)
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

serialdie

All been working ok for me since the update.

Thank You.

RonpfS

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 snort

This 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 snort2c

I 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?

pfsenseddc

@RonpfS:

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

Cino

@pfsenseddc:

@Cino:

(…)
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

The 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

bdwyer

@pfsenseddc:

@Cino:

(…)
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

I 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.

eri--

Reinstall the package at least the reloading should be correct now and snort should not exit anymore as reported here.

dhatz

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

eri--

Well i fixed the FreeBSD package used on pfSense to compile snort with the proper flags to restart on reload error rather than exit since the present binary will just plain exit on reload errors.

I honestly do not think that it will really work properly reloading not as root user so i am not reverting that change.

Tomorrow the binary should be updated and the fixes done today should fix the report.

Cino

@ermal:

Well i fixed the FreeBSD package used on pfSense to compile snort with the proper flags to restart on reload error rather than exit since the present binary will just plain exit on reload errors.

I honestly do not think that it will really work properly reloading not as root user so i am not reverting that change.

Tomorrow the binary should be updated and the fixes done today should fix the report.

@ermal

I believe the snort_interfaces.php needs to be updated to correctly display snort status. With the changes you just made, snort stated but snort_interfaces.php page states that its not started. The services page, does show that snort is running and i see the process running in the background.

Also, snort isn't auto-starting anymore upon reboot. nothing in my log or on the console

Unless the new binary is needed for the changes you made to resolve the 2 issues i noticed.

As a side-note… With changes made to the 2.1 code to use pbi I notice that that my box didn't download snort binaries this afternoon. Example: I uninstalled snort, noticed that snort-2.8.6.1 and snort-2.9.0.5 where still listed under pkg_info. I manually deleted them using pkg_delete.. Rebooted the box, installed snort and did a rule update. Looked at my log and only had 4 snort entries. I looked to see if the binaries where under /usr/local/bin... Nothing, so i added snort package via pkg_add -r http://files.pfsense.org/packages/8/All/snort-2.9.0.5.tbz and then was able to get snort to start...

just wondering if I should do the same tomorrow to get the new binaries.

As always, thanks for all your support on the snort package

Edit:

When i run /usr/local/etc/rc.d/snort.sh restart
i'm seeing these errors:


ls: /tmp/snort.sh.pid: No such file or directory
rm: /tmp/snort.sh.pid: No such file or directory
rm: /var/run/snort*: No such file or directory
ls: /tmp/snort.sh.pid: No such file or directory
rm: /var/run/snort_39737_em3.pid: No such file or directory

When i run /usr/local/etc/rc.d/snort.sh start
just:


ls: /tmp/snort.sh.pid: No such file or directory

i thought the pid and such were stored at '/var/log/snort/run'?

eri--

Those errors are harmless.
That code is not very trustworthy but no time to make it proper use pidfiles.

The chnages i made has nothing in relation to what you report on snort_interfaces.php.

Cino

i'll have to do some more testing and look over the code because i can't seem to get snort_interfaces.php to show that snort is running..

like i said, i can't get snort to run when type "/usr/local/etc/rc.d/snort.sh" start but i able to get it to start running "/usr/local/etc/rc.d/snort.sh start_real"
Would this be the reason why it wont auto-start on reboot?

eri--

Try again reinstalling.

Seems the code generated for the snort.sh was as always full of surprises :)

RonpfS

Removed snort, installed snort
this vanished

		 <minute>3</minute>
			<hour>0</hour>
			<mday>*/1</mday>
			<month>*</month>
			<wday>*</wday>
			<who>root</who>
			<command></command>/usr/bin/nice -n20 /usr/local/bin/php -f /usr/local/pkg/snort/snort_check_for_rule_updates.php >> /tmp/snort_update.log 
		 <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 snort2c

I save in the Global settings it showed up again like this

		 <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 snort2c 
		 <minute>3</minute>
			<hour>0</hour>
			<mday>*/1</mday>
			<month>*</month>
			<wday>*</wday>
			<who>root</who>
			<command></command>/usr/bin/nice -n20 /usr/local/bin/php -f /usr/local/pkg/snort/snort_check_for_rule_updates.php >> /tmp/snort_update.log

I ran Update and snort started, trigger Alerts and Blocks IP ;o) ;D
maybe if I ran Update first, the crontab entry might have reappeared.

However, the Snort Interface shows a GREEN arrow, RED Wan,
the If settings show a start button.
But snort is running as root in System Activity
Snort is showed running under Services. Stopping snort under Services requires a refresh to update the status to not running
You also have to refresh Dashboard to see the updated snort status. Starting snort in Dashboard failed

I started Snort under Services: Snort work ok.

During all that time, the Snort Interface ALLWAYS shows a GREEN arrow, RED Wan

The midnight update went fine and snort reloaded without problem. ::)

Cino

that seem to do it! thanks again.

I trying to figure out why i'm not seeing it up. You didn't make any changes to the page(and snort_interfaces_edit.php) but they are not reporting status correctly.

I'm wondering because root is running snort is it failing the few checks i see not idk.

Cino

@RonpfS Every time you reinstall snort, save the global settings page for it to re-create the cron job.. This has been normal practice since snort was fixed a few months back.

I'm having the same issue with the snort_interface.php showing the status of snort.