Snort stops by itself
-
Lately the Snort interfaces have begun to stop at random. This means that I no longer can trust the intrusion detection system pfSense has to offer. I have to manually enable Snort again and again.
-
Try setting the memory setting to "AC-BNFA-NQ" on all interfaces.
Do you see anything in the error logs?
-
Try setting the memory setting to "AC-BNFA-NQ" on all interfaces.
Do you see anything in the error logs?
I'm not sure how to read more than the last 50 system log entries. I use the "Status" menu and "System Logs".
-
In Status:System Logs:Settings:
There is an option "GUI Log Entries to Display"
You can also scroll down at the bottom of the "System Logs" and type "snort" into the filter box.
-
In Status:System Logs:Settings:
There is an option "GUI Log Entries to Display"
You can also scroll down at the bottom of the "System Logs" and type "snort" into the filter box.
Thanks for the tip. I can't find any "error" messages in the logs. There are logs about updates. One entry says "Snort has restarted with your new set of rules…". But Snort was not running on the WAN interface, only on WLAN, LAN and DMZ. I had to manually start Snort on my WAN interface.
-
@Ip:
In Status:System Logs:Settings:
There is an option "GUI Log Entries to Display"
You can also scroll down at the bottom of the "System Logs" and type "snort" into the filter box.
Thanks for the tip. I can't find any "error" messages in the logs. There are logs about updates. One entry says "Snort has restarted with your new set of rules…". But Snort was not running on the WAN interface, only on WLAN, LAN and DMZ. I had to manually start Snort on my WAN interface.
Search the logs for "snort exited on signal 11"
Maybe Bill might offer some more help?
-
Try setting the memory setting to "AC-BNFA-NQ" on all interfaces.
Do you see anything in the error logs?
Snort just stopped on my WAN interface. In the logs I read: "kernel: pid 86892 (snort), uid: exited on signal 11"
-
From the shell try this command
ps aux | grep snort
And see if you have any duplicate pids. There should only be one per running interface.
Did you make any recent changes?
-
@Ip:
Try setting the memory setting to "AC-BNFA-NQ" on all interfaces.
Do you see anything in the error logs?
Snort just stopped on my WAN interface. In the logs I read: "kernel: pid 86892 (snort), uid: exited on signal 11"
I'm puzzled by this. I believe you guys when you say you have the problem, but I have thus far not seen it manifest itself in any of my test VMs nor on my production firewall. Unfortunately "signal 11" means the process tried to use memory outside of its assigned address space (a SEGFAULT error). When this happens the offending process will just be croaked and never even gets a chance to log an error.
It's weird that it seems to happen during rules updates, though. Are you changing any of the default rules in the categories you are using? By that I mean are you forcing some default "disabled" rules to the "enabled" state? I don't, and have not seen the problem, so just investigating any potential connection there.
Bill
-
From the shell try this command
ps aux | grep snort
And see if you have any duplicate pids. There should only be one per running interface.
Did you make any recent changes?
The command "ps aux | grep snort" gives me a list with 4 lines ending "/usr/pbi/snort-a" and I run Snort on four interfaces (WAN, LAN, WLAN and DMZ).
I have always been using "Snort VRT Oinkmaster Configuration". The only recent changes I can think of are upgrades. I run package version 2.9.6.0 pkg v3.0.9 (the most recent one).
-
@Ip:
Try setting the memory setting to "AC-BNFA-NQ" on all interfaces.
Do you see anything in the error logs?
Snort just stopped on my WAN interface. In the logs I read: "kernel: pid 86892 (snort), uid: exited on signal 11"
I'm puzzled by this. I believe you guys when you say you have the problem, but I have thus far not seen it manifest itself in any of my test VMs nor on my production firewall. Unfortunately "signal 11" means the process tried to use memory outside of its assigned address space (a SEGFAULT error). When this happens the offending process will just be croaked and never even gets a chance to log an error.
It's weird that it seems to happen during rules updates, though. Are you changing any of the default rules in the categories you are using? By that I mean are you forcing some default "disabled" rules to the "enabled" state? I don't, and have not seen the problem, so just investigating any potential connection there.
Bill
The last time it happened was not during rules update. I was writing a reply and looking at the Snort menu screen.
As far as I can remember the only changes I have made are disableing rules, not enable. I have changed search method from default AC-BNFA to AC on the WAN interface. Now I run AC-BNFA-NQ on all four interfaces.
-
Ok, from the responses here I understand that this is a well known and very serious problem with Snort and pfSense. A IDS that turns off randomly is obviously a very serious problem. This bug has to be corrected before pfSense can be trusted and used with confidence.
-
I had a similar issue, but it was solved by using the AC-BNFA or AC-BNFA-NQ memory setting. It was a result of snort rules updates causing the process to attempt to allocate more memory than was available.
-
Sometimes Snort stops on the LAN interface. Never on the WAN.
-
I have had this happen quite regularly. I've narrowed it down to the fact that I have a constant connection on a VPN. When the VPN connection goes down and reconnects, snort is restarted, even though it is not tied to the VPN interface. I'm guessing it's because of the check_reload_status process.
Edit
To be more specific, an OpenVPN client is on PFSense, connected to an external OpenVPN server.Edit 2
It could also be due to the reloading of rules depending on how you have updates set. Here's some log snippets showing what I believe to be the above issue, though:Jun 17 17:18:47 kernel: ue0: promiscuous mode enabled Jun 17 17:16:11 SnortStartup[96556]: Snort START for WAN(34137_ue0)... Jun 17 17:16:07 SnortStartup[94480]: Snort STOP for WAN(34137_ue0)... Jun 17 17:16:05 check_reload_status: Syncing firewall Jun 17 17:16:04 check_reload_status: Syncing firewall Jun 17 17:16:02 check_reload_status: Reloading filter Jun 17 17:16:02 check_reload_status: Restarting OpenVPN tunnels/interfaces Jun 17 17:16:02 check_reload_status: Restarting ipsec tunnels Jun 17 17:16:02 check_reload_status: updating dyndns VPNI Jun 17 17:16:00 kernel: ue0: promiscuous mode disabled Jun 17 17:16:00 kernel: pid 18641 (snort), uid 0: exited on signal 11 Jun 17 17:15:57 php: rc.start_packages: No pfBlocker action during boot process. Jun 17 17:15:57 php: rc.start_packages: No pfBlocker action during boot process. Jun 17 17:15:57 php: rc.start_packages: No pfBlocker action during boot process. Jun 17 17:15:57 php: rc.start_packages: No pfBlocker action during boot process. Jun 17 17:15:55 php: rc.start_packages: The command '/usr/local/etc/rc.d/cron.sh stop' returned exit code '1', the output was '' Jun 17 17:15:51 php: rc.start_packages: Restarting/Starting all packages. Jun 17 17:15:49 check_reload_status: Reloading filter Jun 17 17:15:49 check_reload_status: Starting packages Jun 17 17:15:49 php: rc.newwanip: pfSense package system has detected an ip change 0.0.0.0 -> 10.159.1.10 ... Restarting packages. Jun 17 17:15:47 php: rc.newwanip: Creating rrd update script Jun 17 17:15:42 php: rc.newwanip: rc.newwanip: on (IP address: 10.15.4.10) (interface: VPNI[opt1]) (real interface: ovpnc2). Jun 17 17:15:42 php: rc.newwanip: rc.newwanip: Informational is starting ovpnc2. Jun 17 17:15:40 check_reload_status: rc.newwanip starting ovpnc2 Jun 17 17:15:40 kernel: ovpnc2: link state changed to UP Jun 17 17:15:39 check_reload_status: Reloading filter Jun 17 17:15:39 kernel: ovpnc2: link state changed to DOWN Jun 17 17:11:19 kernel: ue0: promiscuous mode enabled Jun 17 17:08:44 SnortStartup[12975]: Snort START for WAN(34137_ue0)... -
I had a similar issue, but it was solved by using the AC-BNFA or AC-BNFA-NQ memory setting. It was a result of snort rules updates causing the process to attempt to allocate more memory than was available.
Now I use AC-BNFA-NQ on all interfaces and Snort has not stopped yet.
-
@Ip:
I had a similar issue, but it was solved by using the AC-BNFA or AC-BNFA-NQ memory setting. It was a result of snort rules updates causing the process to attempt to allocate more memory than was available.
Now I use AC-BNFA-NQ on all interfaces and Snort has not stopped yet.
Dont tell jflsakfja ,that he was right! Please. :) Glad that its solved now.
-
I have had this happen quite regularly. I've narrowed it down to the fact that I have a constant connection on a VPN. When the VPN connection goes down and reconnects, snort is restarted, even though it is not tied to the VPN interface. I'm guessing it's because of the check_reload_status process.
Edit
To be more specific, an OpenVPN client is on PFSense, connected to an external OpenVPN server.Edit 2
It could also be due to the reloading of rules depending on how you have updates set. Here's some log snippets showing what I believe to be the above issue, though:Jun 17 17:18:47 kernel: ue0: promiscuous mode enabled Jun 17 17:16:11 SnortStartup[96556]: Snort START for WAN(34137_ue0)... Jun 17 17:16:07 SnortStartup[94480]: Snort STOP for WAN(34137_ue0)... Jun 17 17:16:05 check_reload_status: Syncing firewall Jun 17 17:16:04 check_reload_status: Syncing firewall Jun 17 17:16:02 check_reload_status: Reloading filter Jun 17 17:16:02 check_reload_status: Restarting OpenVPN tunnels/interfaces Jun 17 17:16:02 check_reload_status: Restarting ipsec tunnels Jun 17 17:16:02 check_reload_status: updating dyndns VPNI Jun 17 17:16:00 kernel: ue0: promiscuous mode disabled Jun 17 17:16:00 kernel: pid 18641 (snort), uid 0: exited on signal 11 Jun 17 17:15:57 php: rc.start_packages: No pfBlocker action during boot process. Jun 17 17:15:57 php: rc.start_packages: No pfBlocker action during boot process. Jun 17 17:15:57 php: rc.start_packages: No pfBlocker action during boot process. Jun 17 17:15:57 php: rc.start_packages: No pfBlocker action during boot process. Jun 17 17:15:55 php: rc.start_packages: The command '/usr/local/etc/rc.d/cron.sh stop' returned exit code '1', the output was '' Jun 17 17:15:51 php: rc.start_packages: Restarting/Starting all packages. Jun 17 17:15:49 check_reload_status: Reloading filter Jun 17 17:15:49 check_reload_status: Starting packages Jun 17 17:15:49 php: rc.newwanip: pfSense package system has detected an ip change 0.0.0.0 -> 10.159.1.10 ... Restarting packages. Jun 17 17:15:47 php: rc.newwanip: Creating rrd update script Jun 17 17:15:42 php: rc.newwanip: rc.newwanip: on (IP address: 10.15.4.10) (interface: VPNI[opt1]) (real interface: ovpnc2). Jun 17 17:15:42 php: rc.newwanip: rc.newwanip: Informational is starting ovpnc2. Jun 17 17:15:40 check_reload_status: rc.newwanip starting ovpnc2 Jun 17 17:15:40 kernel: ovpnc2: link state changed to UP Jun 17 17:15:39 check_reload_status: Reloading filter Jun 17 17:15:39 kernel: ovpnc2: link state changed to DOWN Jun 17 17:11:19 kernel: ue0: promiscuous mode enabled Jun 17 17:08:44 SnortStartup[12975]: Snort START for WAN(34137_ue0)...Thank you for the information. I don't have a VPN but Snort will stop anyway. I will try AC-BNFA-NQ from now on. So far no problem.
-
@Ip:
I had a similar issue, but it was solved by using the AC-BNFA or AC-BNFA-NQ memory setting. It was a result of snort rules updates causing the process to attempt to allocate more memory than was available.
Now I use AC-BNFA-NQ on all interfaces and Snort has not stopped yet.
Dont tell jflsakfja ,that he was right! Please. :) Glad that its solved now.
It will be our little secret :-X I really hope that it works in the long run ;)
-
I had a similar issue, but it was solved by using the AC-BNFA or AC-BNFA-NQ memory setting. It was a result of snort rules updates causing the process to attempt to allocate more memory than was available.
Interesting that this seems to be working for people. I will try switching as well, but even with AC I still have gigs of RAM free, so can't imagine its a memory allocation issue unless it's related to a bug.
Thanks,
Ben
