Snort 2.9.5.6 pkg v3.0.4 Update – Release notes and change log
-
Bill,
Since I have upgraded to this snort version, my firewall has experienced two kernel panics (pulled from log) and rebooted itself. Prior to going from previous version number to this one ( I do keep updated as much as I can) the firewall has never once panicked on me or rebooted. Nothing else has been touched. No other packages updated or core components updated. I am on the most recent build of pfsense. Would this package cause this for some strange reason or are the two not related and its just more of of a coincidence?
The first time was the next day after i updated earlier in the week. Then it did it again at 3:45 am this morning..
I can list out full packages and hardware if you need it.. I am just scratching my head at this one..Also when i idid the upgrade, i did a full remove, kept settings though and then installed most recent package and the settings were restored.. I am going to do a full remove again and re-install …
I dont see anything else in the log that i can tell that would tell me what caused this. I did upload both crash dumps to the pfsense. I deleted the first one but kept the second one on my hard drive. Not sure if it would be any help if it is related to the updated snort...
Also upon the reboot i get this error / alert. Never seen it before.
There were error(s) loading the rules: pfctl: DIOCADDRULE: Device busy - The line in question reads [0]:
Just thought I would ask and see if it could be this package now or something un-related..
Is this error written out to the console, or did you pull it from the system log (or both)?
I think the error message you posted would be happening before Snort is even loaded on a reboot. I'm not saying Snort couldn't be at fault, but I don't think it is in this case. There have been no other user reports of this particular problem here on the Forum. If someone else reading this thread has experienced a similar issue, please speak up.
Are you running something in addition such as pfBlocker or URL aliases that might be downloading new "rules" for insertion into the pf firewall? Could be that a corrupt "rule" has been downloaded by one of those (if you are using them). If you are game, you can do these two things in this order, one at the time, for troubleshooting purposes:
1. Disable "block offenders" for Snort. That removes all Snort writes to the pf firewall tables.
2. Disable Snort entirely by unchecking the "enable" checkboxes for each interface (or just stop it manually).
If you still get a kernel panic (or that error message), then we know Snort is not the cause. If you do not get any further panics, then that would indicate Snort might be involved. In that case, post back here.
Bill
-
Thanks bill. I do use pfblocker.
Here are the other packages I have just for reference. I did a clean removal of snort and then installed it. If I get another Panic then I will do as you mention to see if I can isolate it. I am on the 386 version too… Havent migrated over to 64 bit yet.. maybe I should lol.. When I removed snort I did reboot to make sure nothing was running and still got that pfctl: DIOCADDRULE: Device busy so I know that part is not snort.. Just got to isolate whats caused the panics.. Just strange this system has been up with no issues for approx 2 years and before that first panic 183 days straight... I will keep you posted on what i find out, if anything. Thanks for your time!The panic error message was from the sys log. I do not have a monitor hooked up atm for console readout.. I am sure it would have been gone from the reboot anyways.
AutoConfigBackup 1.21
Backup 0.1.5
Dashboard Widget: Snort 0.3.7
File Manager 0.1.3
LCDproc-dev lcdproc-0.5.6 pkg v. 0.9.7
mailreport
nmap nmap-6.25_1 pkg v1.2
nut 2.6.4 pkg 2.0
OpenVPN Client Export 1.2.4
pfBlocker 1.0.2
phpSysInfo 2.5.4
RRD Summary 1.1
Service Watchdog 1.5
System Patches 1.0 -
Thanks bill. I do use pfblocker.
Here are the other packages I have just for reference. I did a clean removal of snort and then installed it. If I get another Panic then I will do as you mention to see if I can isolate it. I am on the 386 version too… Havent migrated over to 64 bit yet.. maybe I should lol.. When I removed snort I did reboot to make sure nothing was running and still got that pfctl: DIOCADDRULE: Device busy so I know that part is not snort.. Just got to isolate whats caused the panics.. Just strange this system has been up with no issues for approx 2 years and before that first panic 183 days straight... I will keep you posted on what i find out, if anything. Thanks for your time!The panic error message was from the sys log. I do not have a monitor hooked up atm for console readout.. I am sure it would have been gone from the reboot anyways.
AutoConfigBackup 1.21
Backup 0.1.5
Dashboard Widget: Snort 0.3.7
File Manager 0.1.3
LCDproc-dev lcdproc-0.5.6 pkg v. 0.9.7
mailreport
nmap nmap-6.25_1 pkg v1.2
nut 2.6.4 pkg 2.0
OpenVPN Client Export 1.2.4
pfBlocker 1.0.2
phpSysInfo 2.5.4
RRD Summary 1.1
Service Watchdog 1.5
System Patches 1.0pfctl is the FreeBSD binary that allows manipulation of the firewall tables directly. It can be used to insert rules, remove rules, get status of rules, etc. From first glance at that error message, it appears to result from pfctl trying to load something invalid. It's hard to see, but is it saying the rule was "*:"?
A package like pfBlocker routinely downloads updated lists of IP addresses and then generates new firewall rules designed to block the IPs. It then uses pfctl to insert the new or updated rules into the firewall. These tables are persisted and reloaded on a reboot. Could be pfBlocker that is choking on one of its downloaded rules files, and as a consequence it might be in turn choking the pfctl utility.
The above is just a theory, though… :)
Bill
-
The pasting of the error didnt come out right. I added spaces to see if it wouldnt try to convert it to an emoticon
There were error(s) loading the rules: pfctl: DIOCADDRULE: Device busy - The line in question reads [ 0 ] :
Your theory is sound. It pulls rules daily from iblocklist.com so its possibly that one of the lists messed something up. Shouldnt i get that though when it reloads the rules. lets say I make FW rule changes etc and that provokes a reload or when I update my manual list in pfblocker it always reloads them and I never get the error. I noticed it with the recent reboots only..
Anyhow.. I was not intending to derail the topic.. I appreciate the insight.
-
The last few builds of snort I've installed have had some real issues with CPU usage on my machines. Has anyone else seen snort burn 100% of a CPU core, per instance, even when idle?
This always happens on startup of snort for the first 30 seconds or so but after that it should settle down. Right now snort has been disabled on all 3 of my boxes (1 at home, 2 at work) it runs my CPUs at 100% all the time and I end up with poor throughput as a result.
-
The last few builds of snort I've installed have had some real issues with CPU usage on my machines. Has anyone else seen snort burn 100% of a CPU core, per instance, even when idle?
This always happens on startup of snort for the first 30 seconds or so but after that it should settle down. Right now snort has been disabled on all 3 of my boxes (1 at home, 2 at work) it runs my CPUs at 100% all the time and I end up with poor throughput as a result.
Using 100% of a CPU is definitely not right. Check and make sure you have only one instance of Snort per interface it's enabled on using this command –
ps -ax | grep snort
Assuming you do not have Barnyard2 enabled, you should see exactly one Snort process per interface. Each will have a UUID along with the physical interface name in the command-line arguments. If you have Barnyard2 enabled, you will also see one Barnyard2 process per interface.
If the command above shows the correct number of interfaces, then I would start disabling some rules to see if maybe one is consuming CPU time. You can also enable the Preprocessor Stats on the Preprocessors tab. This will give you statistics for all the preprocessors and may help identify a problem area.
Bill
-
The last few builds of snort I've installed have had some real issues with CPU usage on my machines. Has anyone else seen snort burn 100% of a CPU core, per instance, even when idle?
This always happens on startup of snort for the first 30 seconds or so but after that it should settle down. Right now snort has been disabled on all 3 of my boxes (1 at home, 2 at work) it runs my CPUs at 100% all the time and I end up with poor throughput as a result.
Using 100% of a CPU is definitely not right. Check and make sure you have only one instance of Snort per interface it's enabled on using this command –
ps -ax | grep snort
Assuming you do not have Barnyard2 enabled, you should see exactly one Snort process per interface. Each will have a UUID along with the physical interface name in the command-line arguments. If you have Barnyard2 enabled, you will also see one Barnyard2 process per interface.
If the command above shows the correct number of interfaces, then I would start disabling some rules to see if maybe one is consuming CPU time. You can also enable the Preprocessor Stats on the Preprocessors tab. This will give you statistics for all the preprocessors and may help identify a problem area.
Bill
Barnyard2 is off and I do have one process per interface. I'll try enabling stats and see if that tells me what it's doing.
EDIT: Question. Where exactly would I find the stats it's collecting?
-
I have been noticing Memory increasing at times also. CPU usage has usually been fairly low thou.
Looks like I had two dead snort process's on my box. Those are both on my WAN interface.
ps -ax | grep snort
30859 ?? SNs 7:06.60 /usr/pbi/snort-amd64/bin/snort -R 44200 -D -q -l /var/log/snort/snort_bce044200 –pid-path /var/run --nolock-pidfile -G 44200 -c /usr/pbi/s
34575 ?? SNs 6:37.28 /usr/pbi/snort-amd64/bin/snort -R 9739 -D -q -l /var/log/snort/snort_em09739 --pid-path /var/run --nolock-pidfile -G 9739 -c /usr/pbi/snort
47151 ?? Ss 27:02.58 /usr/pbi/snort-amd64/bin/snort -R 44200 -D -q -l /var/log/snort/snort_bce044200 –pid-path /var/run --nolock-pidfile -G 44200 -c /usr/pbi/s
63296 ?? Ss 26:48.10 /usr/pbi/snort-amd64/bin/snort -R 44200 -D -q -l /var/log/snort/snort_bce044200 --pid-path /var/run --nolock-pidfile -G 44200 -c /usr/pbi/s(After shutting down Snort from the Interface GUI.)
ps -ax | grep snort
47151 ?? Ss 27:04.42 /usr/pbi/snort-amd64/bin/snort -R 44200 -D -q -l /var/log/snort/snort_bce044200 –pid-path /var/run --nolock-pidfile -G 44200 -c /usr/pbi/s
63296 ?? Ss 26:49.93 /usr/pbi/snort-amd64/bin/snort -R 44200 -D -q -l /var/log/snort/snort_bce044200 --pid-path /var/run --nolock-pidfile -G 44200 -c /usr/pbi/spkill snort
This killed the two dead processes.
I restarted Snort on the Interface GUI and all seems ok now. Memory down 20-30%
ps -ax | grep snort
69121 ?? Ss 0:08.67 /usr/pbi/snort-amd64/bin/snort -R 44200 -D -q -l /var/log/snort/snort_bce044200 –pid-path /var/run --nolock-pidfile -G 44200 -c /usr/pbi/s
91224 ?? Ss 0:00.63 /usr/pbi/snort-amd64/bin/snort -R 9739 -D -q -l /var/log/snort/snort_em09739 --pid-path /var/run --nolock-pidfile -G 9739 -c /usr/pbi/snort -
Is this on 32/64bit versions or only on 64bit?
I havent had issues at all running 32 bit.
-
Is this on 32/64bit versions or only on 64bit?
I havent had issues at all running 32 bit.
My systems are all 64-bit.
-
Mine is 64bit. I have a 32bit at another site that doesn't seem to have this issue.
-
Barnyard2 is off and I do have one process per interface. I'll try enabling stats and see if that tells me what it's doing.
EDIT: Question. Where exactly would I find the stats it's collecting?
There will be a log in /var/log/snort/snort_xxx with the collected information. You can get to it by using Diagnostics…Edit File. Each configured Snort interface has its own uniquely named subdirectory in the /var/log/snort directory. The physical interface name is part of the directory name, so that should make it easier to find.
Bill
-
I am too see higher cpu (see attached rrd image) 64 bit 2.1.1 atom d525 and 4G ram seems i get a spike of 100% anytime i hit 5Mbps on cable modem and its worse the worse the cable modem latency gets (been dealing with modem dropping to 1 channel for more than a year) i also upgraded to snorts subscribers rules running balanced policy
![status_rrd_graph_img (6).png](/public/imported_attachments/1/status_rrd_graph_img (6).png)
![status_rrd_graph_img (6).png_thumb](/public/imported_attachments/1/status_rrd_graph_img (6).png_thumb) -
think i found another bug. I have 2 sensors for my WAN, one for blocking and another just for alerting. I've disabled my alerting interface but it still is starting when the service/router is restarted. If I re-save the disabled sensor, it brings it down
-
think i found another bug. I have 2 sensors for my WAN, one for blocking and another just for alerting. I've disabled my alerting interface but it still is starting when the service/router is restarted. If I re-save the disabled sensor, it brings it down
I think I know what the problem is and will fix it in the next release. I have the new 2.9.6.0 package almost ready. Thanks for the bug report.
Bill