Snort 2.9.4.1 pkg v. 2.5.5 Issue(s)
-
I'm not sure if this is by design or not, but applying firewall rules (filter reload?) will erase Snort blocked list.
-
I'm not sure if this is by design or not, but applying firewall rules (filter reload?) will erase Snort blocked list.
That does make sense. I had not thought of that. Snort actually uses some of the same pf tables to perform its inline blocking (using a third-party output plugin for Snort called Spoink). So when the firewall rules refresh, I would assume the tables are cleared.
Once the Spoink plugin writes the IP address from an alert into the table, it does not check on it anymore. It's a "post and forget" type of operation from Snort's point of view. There is a completely separate cron task that fires based on your configured time, and this task is the one that actually clears the pf table where the blocks were inserted. The Spoink plugin only fires on the initial alert from Snort. It does not do any kind of "state keeping" whereby it periodically scans the Snort log or anything like that. It just intercepts that initial alert, then posts the required IP address in the pf table for blocking.
-
Snort was killed again after rules update!
Apr 18 00:05:44 php: : The Rules update has finished.
Apr 18 00:05:44 php: : Snort has restarted with your new set of rules…
Apr 18 00:05:42 SnortStartup[800]: Snort SOFT START For Internet(36256_em0)…
Apr 18 00:05:42 snort[27180]: Could not remove pid file /var/run/snort_em036256.pid: No such file or directory
Apr 18 00:05:42 snort[27180]: Could not remove pid file /var/run/snort_em036256.pid: No such file or directory
Apr 18 00:05:41 kernel: em0: promiscuous mode disabled
Apr 18 00:05:41 snort[27180]: *** Caught Term-Signal
Apr 18 00:05:41 snort[27180]: *** Caught Term-Signal
Apr 18 00:05:40 SnortStartup[63434]: Snort STOP For Internet(36256_em0)…
Apr 18 00:05:40 php: : Building new sig-msg.map file for WAN...
Apr 18 00:05:38 php: : Resolving and auto-enabling any flowbit-required rules for WAN...
Apr 18 00:05:36 php: : Updating rules configuration for: WAN ...
Apr 18 00:05:36 php: : EmergingThreats rules file update downloaded succsesfully
Apr 18 00:05:33 php: : There is a new set of EmergingThreats rules posted. Downloading...
Apr 18 00:05:33 php: : Snort GPLv2 Community Rules file update downloaded succsesfully
Apr 18 00:05:31 php: : There is a new set of Snort GPLv2 Community Rules posted. Downloading...
Apr 18 00:05:30 php: : Snort VRT rules are up to date...
Apr 18 00:05:30 php: : Snort MD5 Attempts: 2
Apr 17 00:03:07 php: : The Rules update has finished.
Apr 17 00:03:07 php: : Emerging Threat rules are up to date...
Apr 17 00:03:07 php: : Snort GPLv2 Community Rules are up to date...
Apr 17 00:03:06 php: : Snort VRT rules are up to date...
Apr 17 00:03:06 php: : Snort MD5 Attempts: 1And then manually started
pr 18 12:00:44 php: /status_services.php: The command '/usr/local/etc/rc.d/snort.sh stop' returned exit code '1', the output was ''
Apr 18 12:00:42 SnortStartup[51714]: Snort STOP For Internet(36256_em0)…Another FW got killed. Same error.
Apr 18 00:03:41 php: : The Rules update has finished.
Apr 18 00:03:41 php: : Snort has restarted with your new set of rules...
Apr 18 00:03:39 SnortStartup[4528]: Snort SOFT START For Internet(9626_em0)…
Apr 18 00:03:39 snort[54662]: Could not remove pid file /var/run/snort_em09626.pid: No such file or directory
Apr 18 00:03:39 snort[54662]: Could not remove pid file /var/run/snort_em09626.pid: No such file or directory
Apr 18 00:03:38 kernel: em0: promiscuous mode disabled
Apr 18 00:03:38 snort[54662]: *** Caught Term-Signal
Apr 18 00:03:38 snort[54662]: *** Caught Term-Signal
Apr 18 00:03:37 SnortStartup[3264]: Snort STOP For Internet(9626_em0)…
Apr 18 00:03:37 php: : Building new sig-msg.map file for WAN...
Apr 18 00:03:35 php: : Resolving and auto-enabling any flowbit-required rules for WAN...
Apr 18 00:03:33 php: : Updating rules configuration for: WAN ...
Apr 18 00:03:32 php: : EmergingThreats rules file update downloaded succsesfully
Apr 18 00:03:29 php: : There is a new set of EmergingThreats rules posted. Downloading...
Apr 18 00:03:29 php: : Snort GPLv2 Community Rules file update downloaded succsesfully
Apr 18 00:03:27 php: : There is a new set of Snort GPLv2 Community Rules posted. Downloading...
Apr 18 00:03:26 php: : Snort VRT rules are up to date...
Apr 18 00:03:26 php: : Snort MD5 Attempts: 1 -
Confirmed:
Apr 17 12:06:12 php: : The Rules update has finished. Apr 17 12:06:12 php: : Snort has restarted with your new set of rules...Apr 17 12:06:10 kernel: em0: promiscuous mode enabled Apr 17 12:06:10 SnortStartup[65474]: Snort START For WAN(54477_em0)... Apr 17 12:05:40 snort[71072]: Could not remove pid file /var/run/snort_em054477.pid: No such file or directory Apr 17 12:05:40 kernel: em0: promiscuous mode disabled Apr 17 12:05:40 snort[71072]: *** Caught Term-Signal Apr 17 12:05:39 SnortStartup[63404]: Snort STOP For WAN(54477_em0)... Apr 17 12:05:38 php: : Building new sig-msg.map file for WAN... Apr 17 12:05:30 php: : Resolving and auto-enabling any flowbit-required rules for WAN... Apr 17 12:05:22 php: : Updating rules configuration for: WAN ... Apr 17 12:05:21 php: : EmergingThreats rules file update downloaded succsesfully Apr 17 12:05:12 php: : There is a new set of EmergingThreats rules posted. Downloading... Apr 17 12:05:12 php: : Snort VRT rules are up to date... Apr 17 12:05:12 php: : Snort MD5 Attempts: 2
This one looks OK, but the next one does not:
Apr 18 12:07:19 php: : The Rules update has finished. Apr 18 12:07:18 php: : Building new sig-msg.map file for WAN... Apr 18 12:07:09 php: : Resolving and auto-enabling any flowbit-required rules for WAN... Apr 18 12:07:02 php: : Updating rules configuration for: WAN ... Apr 18 12:07:01 kernel: em0: promiscuous mode disabled Apr 18 12:07:01 kernel: pid 65246 (snort), uid 0: exited on signal 4 Apr 18 12:06:52 php: : EmergingThreats rules file update downloaded succsesfully Apr 18 12:06:50 php: : There is a new set of EmergingThreats rules posted. Downloading... Apr 18 12:06:49 php: : Snort Rules Attempts: 1 Apr 18 12:06:10 php: : There is a new set of Snort VRT rules posted. Downloading... Apr 18 12:06:10 php: : Snort MD5 Attempts: 3
It happens when there is a new Snort ruleset, not when the ET rules are updated.
-
Supermule and gogol:
Thank you for your detailed reports with the logs. I think I spotted a clue. I will need to investigate it a bit, but the clue I see is in Supermule's log entries. Notice it says "Snort SOFT START". That is not what I expected. The rules update procedure asks for a complete shutdown and restart of Snort by calling the /usr/local/etc/rc.d/snort.sh script with the restart argument. In the shell script, that causes Snort to be stopped and then restarted. The STOP part is happening, but the restart is getting hosed, and I need to see why.
The logic in the shell script tries to be smart on starting Snort. If it sees the process is already running, it issues a SIGHUP command to the running process signalling Snort to reload its rules and other configuration settings. If there is no running Snort process detected, it just cold-starts Snort.
So here is what I think is going on. The STOP signal is caught by the running Snort process and it begins the shutdown process. However, the START command is issued before STOP has completetly finished cleaning up the PID files. So START sees the not-yet-cleaned up PID file and thinks Snort is still running. Thinking there is a running Snort process, it just issues the SIGHUP soft restart instead of the hard START. That clue comes from the "SOFT START" part of the log entry. That line only gets printed when the script tries the SIGHUP approach.
I need to test out my theory in my VM world a bit, and this may take me a few days. In the interim, try the fix I posted earlier of adding a sleep 3 command between the rc_stop() and rc_start() calls in the shell script.
Bill
-
Thanks Bill!
Looking forward to see what you come up with.
-
Thanks Bill!
Looking forward to see what you come up with.
If you want to try a quick experiment, follow the instructions here: http://forum.pfsense.org/index.php/topic,61001.msg330160.html#msg330160
Try fiddling with the sleep time. Maybe try a little longer. If my theory is correct, it's a timing issue.
Bill
-
Ok, I added the sleep 3 timer and will wait and see.
Snort is not very consistent with restarting, because I also have a SOFT RESTART in my logs:Apr 16 12:04:13 php: : The Rules update has finished. Apr 16 12:04:13 php: : Snort has restarted with your new set of rules... Apr 16 12:04:11 SnortStartup[77296]: Snort SOFT START For WAN(54477_em0)... Apr 16 12:04:10 snort[38532]: Could not remove pid file /var/run/snort_em054477.pid: No such file or directory Apr 16 12:04:09 snort[38532]: *** Caught Term-Signal Apr 16 12:04:08 SnortStartup[75228]: Snort STOP For WAN(54477_em0)... Apr 16 12:04:08 php: : Building new sig-msg.map file for WAN... Apr 16 12:03:59 php: : Resolving and auto-enabling any flowbit-required rules for WAN... Apr 16 12:03:52 php: : Updating rules configuration for: WAN ... Apr 16 12:03:51 php: : EmergingThreats rules file update downloaded succsesfully Apr 16 12:03:48 php: : There is a new set of EmergingThreats rules posted. Downloading... Apr 16 12:03:48 php: : Snort VRT rules are up to date... Apr 16 12:03:48 php: : Snort MD5 Attempts: 1
I have an N270 Atom processor and I know it takes some time for Snort to startup, so maybe you are right that it might be a timing issue for slower processors.
Thanks again. -
I have done that. Waiting update but restarte Snort since I edited the file.
Apr 18 14:45:17 php: /status_services.php: The command '/usr/local/etc/rc.d/snort.sh stop' returned exit code '1', the output was ''
Apr 18 14:45:15 SnortStartup[52848]: Snort STOP For Internet(36256_em0)…
Apr 18 14:45:15 php: /status_services.php: The command '/usr/local/etc/rc.d/snort.sh stop' returned exit code '1', the output was ''
Apr 18 14:45:14 snort[43724]: Could not remove pid file /var/run/snort_em036256.pid: No such file or directory
Apr 18 14:45:14 snort[43724]: Could not remove pid file /var/run/snort_em036256.pid: No such file or directory
Apr 18 14:45:14 kernel: em0: promiscuous mode disabled
Apr 18 14:45:14 snort[43724]: *** Caught Term-Signal
Apr 18 14:45:14 snort[43724]: *** Caught Term-Signal
Apr 18 14:45:13 SnortStartup[51967]: Snort STOP For Internet(36256_em0)…Done it on only one of the FW's so that I can compare.
-
I have done that. Waiting update but restarte Snort since I edited the file.
….
Done it on only one of the FW's so that I can compare.
How about making this change instead of simply adding the sleep command ??
In the same file, find this section:
case $1 in start) rc_start ;; stop) rc_stop ;; restart) rc_stop rc_start ;; esac
and change it to read as follows:
case $1 in start) rc_start ;; stop) rc_stop ;; restart) rc_start ;; esac
Report back after the next update and let me know if it helps. This will allow the restart to just use the SOFT START command and not attempt to STOP Snort.
Bill
-
Ok, I added the sleep 3 timer and will wait and see.
Snort is not very consistent with restarting, because I also have a SOFT RESTART in my logs:…
I have an N270 Atom processor and I know it takes some time for Snort to startup, so maybe you are right that it might be a timing issue for slower processors.
Thanks again.You can also try the fix I posted a bit earlier in this reply: http://forum.pfsense.org/index.php/topic,60994.msg330447.html#msg330447
Actually, this may work better than adding the sleep command.
Bill
-
Done :)
I have done that. Waiting update but restarte Snort since I edited the file.
….
Done it on only one of the FW's so that I can compare.
How about making this change instead of simply adding the sleep command ??
In the same file, find this section:
case $1 in start) rc_start ;; stop) rc_stop ;; restart) rc_stop rc_start ;; esac
and change it to read as follows:
case $1 in start) rc_start ;; stop) rc_stop ;; restart) rc_start ;; esac
Report back after the next update and let me know if it helps. This will allow the restart to just use the SOFT START command and not attempt to STOP Snort.
Bill
-
And to flesh out my theory a bit more, SOFT START simply causes a running Snort process to refresh its configuration. It will not start a process that is no longer running. So continuing from my explanation earlier, during the restart process following a rules update, the STOP command stops the running process. The START command, though, sometimes erroneously sees the PID file not yet removed and thinks Snort is running. So instead of a hard start of a new Snort process, it just tries to refresh the one that is in the process of shutting down. Therefore at the end of the line, Snort is left stopped. This is why you guys can manually start Snort with no problems. There is no real "problem" like bad rules or something, it's simply that the process was stopped for the rules update and not restarted (because of the SOFT START snafu). At least that is my theory.
I did add the STOP command prior to the START command in the RESTART part of the shell script. The old version had the rc_start() call only.
Bill
-
If this fixes it, what I want to do is make the change in the rules update code itself and not alter the shell script. Ermal and I agree that the proper sequence for "restart" in the shell script should be "STOP and then START". This is the standard methodolgy. I can instead alter the rules update PHP code so that it calls the shell script with just the START argument. That will emulate the old behavior of attempting a SOFT START on a running process.
Bill
-
Allright. Will report back tomorrow when rules have been updated. :)
-
Allright. Will report back tomorrow when rules have been updated. :)
Thanks. Hopefully you can report back "good news"… :D
I have not seen this behavior on my system, nor in testing. But if my theory is correct, this is most likely a load and hardware capability related issue. So lightly loaded hardware (few rules and/or lots of CPU horsepower) can get Snort stopped and cleaned up quick enough for things to progress as expected. But heavily loaded hardware (lots of rules and/or medium to low CPU horsepower) might get caught up in the timing issue I described.
That's my theory for now. Getting feedback from you guys actively having the issue will help me nail it down.
-
This is my test box that got killed last night under updating the rules.
NO load what so ever on the box and running server class hardware with 4GB of RAM and 2 CPU's.
-
This is my test box that got killed last night under updating the rules.
NO load what so ever on the box and running server class hardware with 4GB of RAM and 2 CPU's.
I've done a bit more research on this and I think I'm on to the cause. Turns out that the pkill command does not wait for the "kill" to finish before returning, so this means the STOP process may well not have finished before the START part of the script gets called. This leads to the condition I described earlier. Snort has a history of being a bit unreliable for starting/stopping on pfSense. I've got some ideas on how to make the whole thing more robust, but I will have to run them by Ermal for his concurrence. So it may be a few days before a fix is posted.
If I am right in my theory on the cause, then the last suggested workaround I posted should fix it in the interim.
Bill
-
-
I had those start issues after updates and added "sleep 3" to the start script yesterday. Since then snort started fine after an update where all 3 ruletypes were new and also after an update where no new rules got downloaded.
Looks good!
Greets, Judex