Snort 2.9.6.2 pkg v3.1.4 – Bug Fix Update Release Notes
-
Same problem here on my Hardware1 (see sig), I had to reinstall I think four or five times before Snort was there again in the menu. Yet: posed another serious problem popped up:
1. The reinstalling was done 3 times yesterday, then I went to bed and tried it again today. It seemed to have worked.
2. I had to shut all hardware down this afternoon. When booting again, I found WAN and WAN2 were offline.
3. It turned out, after this reboot, Snort had blocked the WAN/WAN2 external IP's because of 122:3, ping sweep (so: not before the reboot, then it found everything ok after the install finally worked. Only after rebooting with this new Snort package suddenly it started blocking WAN/WAN2).
4. I disabled Snort on WAN/WAN2, cleared the block lists and WAN/WAN2 were online again. I noticed CPU load 100% in the dashboard (normally around 8%).
5. 'top' in the CLI showed me 'fetch' consuming 100% of CPU (no clue what 'fetch' is fetching, it seems you can not see this, at least: man fetch doesn't tell me).
6. I uninstalled Snort all together, in the dasboard CPU now is 52%, yet in the CLI 'top' still shows 100% usage for 'fetch'.Being the eternal noob that I am I have no clue whatsoever ???
-
Yes, no link in Services menu and snort is also not listed in Status->Services
Those two depend on the information being in the same place in config.xml in order to display, so if one is missing the other will be as well.
Do you have any customized partition sizes? In particular, how much free space is showing for the /tmp and /var areas? There were some similar issues a while back caused by users running out of free space in those directories. Of course those were NanoBSD installs. I am assuming since you said your installation was on an "old server" that you have conventional disk storage and not CF.
If you want me to troubleshoot further, I will need your config.xml file. If you want to proceed, send me a PM with your e-mail address. I will reply and you can send me the config.xml file for analysis.
Bill
-
@Hollander:
Same problem here on my Hardware1 (see sig), I had to reinstall I think four or five times before Snort was there again in the menu. Yet: posed another serious problem popped up:
1. The reinstalling was done 3 times yesterday, then I went to bed and tried it again today. It seemed to have worked.
2. I had to shut all hardware down this afternoon. When booting again, I found WAN and WAN2 were offline.
3. It turned out, after this reboot, Snort had blocked the WAN/WAN2 external IP's because of 122:3, ping sweep (so: not before the reboot, then it found everything ok after the install finally worked. Only after rebooting with this new Snort package suddenly it started blocking WAN/WAN2).
4. I disabled Snort on WAN/WAN2, cleared the block lists and WAN/WAN2 were online again. I noticed CPU load 100% in the dashboard (normally around 8%).
5. 'top' in the CLI showed me 'fetch' consuming 100% of CPU (no clue what 'fetch' is fetching, it seems you can not see this, at least: man fetch doesn't tell me).
6. I uninstalled Snort all together, in the dasboard CPU now is 52%, yet in the CLI 'top' still shows 100% usage for 'fetch'.Being the eternal noob that I am I have no clue whatsoever ???
Did you have any suspicious messages in your system log? Could you post the contents of the log from the time of one of the failed install attempts?
Fetch is not a process that Snort would be using directly. The Snort package uses a pfSense system call to download rule updates. If you have two WAN connections, I would start looking for something strange with CARP. Still having high CPU with Snort gone means Snort is not the problem.
I think, judging by your other posts, that you might also be a pfBlocker user. Perhaps it is stuck attempting to fetch some updates ?? I am not a fan of using those two together on the firewall. pfBlocker can be very resource intensive (to wit you have to increase the state table entries to an astronomical number in order for it to work).
Bill
-
Hi Bill ;D
The system log in the GUI shows so much information in 2000 lines yet nothing back to the install. Could you perhaps hint this noob as to what to grep from what log in the CLI, so I can get you the information you would want to see?
As to your other remarks:
-I have two WANs with failover, but no CARP. It is too scary for me :P ( ;D )- I also don't have pfBlocker (used it once, but it gave too many problems).
- I do have BB's lists, to which if I am correct JFL also contributed. They never gave problems in the past.
I did found out that the usual suspect was the problem: the reboot. I've concluded that many times when you run into a less obvious problem a reboot solves all problems. I just did, and CPU in the GUI is 6% now, around where it always was.
So what remains is Snort, after yesterday's update blocking my WAN-IP's due to the sweep (122:3), causing off line for both my internet connections.
If you would be so kind as to hint me on what I need to grep in the CLI, I will post back the logs you want to see.
Did I say already that you are one of the ultimate heroes?
;D :-*
-
No problems on 46 firewall running both 2.1.4 and 2.1.5 64bit
-
@Hollander:
Hi Bill ;D
The system log in the GUI shows so much information in 2000 lines yet nothing back to the install. Could you perhaps hint this noob as to what to grep from what log in the CLI, so I can get you the information you would want to see?
As to your other remarks:
-I have two WANs with failover, but no CARP. It is too scary for me :P ( ;D )- I also don't have pfBlocker (used it once, but it gave too many problems).
- I do have BB's lists, to which if I am correct JFL also contributed. They never gave problems in the past.
I did found out that the usual suspect was the problem: the reboot. I've concluded that many times when you run into a less obvious problem a reboot solves all problems. I just did, and CPU in the GUI is 6% now, around where it always was.
So what remains is Snort, after yesterday's update blocking my WAN-IP's due to the sweep (122:3), causing off line for both my internet connections.
If you would be so kind as to hint me on what I need to grep in the CLI, I will post back the logs you want to see.
Did I say already that you are one of the ultimate heroes?
;D :-*
Well, the best fix for the port sweep rule is to disable it. It has a reputation for being both overly sensitive and not sensitive enough if that is confusing enough… ;D. What I mean is that there are many types of scans it will not detect, and there is a lot of innocent stuff that it thinks is a scan. All in all it's not a very useful preprocessor in my opinion. I have mine set to low sensitivity and I created an Alias with all my networks and external DNS forwarders in it. I then assigned that alias to the Ignore Scanners option in the preprocessor. Even then it occasionally fires false positives. I may soon disable it on my own box.
By the way, if yours is blocking your actual WAN IPs, then you must not have those in your Pass List. They should not get blocked. Since you have two, you might have to create a special Alias with all of your protected networks in it and then assign that alias to the pass list.
Bill
-
To share my experience with Snort disappearing from the Services menu.
To upgrade I just selected "Reinstall Snort's GUI Components", since the binary was not changing.
Upon doing so Snort disappeared from the Services menu.
I then did a "Reinstall Snort Package" and everything came back as expected.
I've done just the GUI Components before, with no ill affect.
2.1.5-RELEASE (amd64)
-
To share my experience with Snort disappearing from the Services menu.
To upgrade I just selected "Reinstall Snort's GUI Components", since the binary was not changing.
Upon doing so Snort disappeared from the Services menu.
I then did a "Reinstall Snort Package" and everything came back as expected.
I've done just the GUI Components before, with no ill affect.
2.1.5-RELEASE (amd64)
Thanks for the information and hint. I will test this in my lab a bit more thoroughly to see if something shows up. I have just started click the PKG icon to reinstall the package instead of clicking the XML icon to just reinstall GUI components.
Bill
-
@Hollander:
Hi Bill ;D
The system log in the GUI shows so much information in 2000 lines yet nothing back to the install. Could you perhaps hint this noob as to what to grep from what log in the CLI, so I can get you the information you would want to see?
As to your other remarks:
-I have two WANs with failover, but no CARP. It is too scary for me :P ( ;D )- I also don't have pfBlocker (used it once, but it gave too many problems).
- I do have BB's lists, to which if I am correct JFL also contributed. They never gave problems in the past.
I did found out that the usual suspect was the problem: the reboot. I've concluded that many times when you run into a less obvious problem a reboot solves all problems. I just did, and CPU in the GUI is 6% now, around where it always was.
So what remains is Snort, after yesterday's update blocking my WAN-IP's due to the sweep (122:3), causing off line for both my internet connections.
If you would be so kind as to hint me on what I need to grep in the CLI, I will post back the logs you want to see.
Did I say already that you are one of the ultimate heroes?
;D :-*
Well, the best fix for the port sweep rule is to disable it. It has a reputation for being both overly sensitive and not sensitive enough if that is confusing enough… ;D . What I mean is that there are many types of scans it will not detect, and there is a lot of innocent stuff that it thinks is a scan. All in all it's not a very useful preprocessor in my opinion. I have mine set to low sensitivity and I created an Alias with all my networks and external DNS forwarders in it. I then assigned that alias to the Ignore Scanners option in the preprocessor. Even then it occasionally fires false positives. I may soon disable it on my own box.
By the way, if yours is blocking your actual WAN IPs, then you must not have those in your Pass List. They should not get blocked. Since you have two, you might have to create a special Alias with all of your protected networks in it and then assign that alias to the pass list.
Bill
Thanks Bill ;D
Some way or the other, there is a serious problem. I never had this before, it all just started after the last update :-[
I tried to install Snort again this morning (having uninstalled it yesterday due to the problems), and 'boom': CPU back to 100% again, due to 'fetch' (in 'top' in the CLI). The CPU was so much 100% it appears, that Snort even hung at 79% executing a PHP-script (let I do it's thing for 2 hours, then rebooted the box).
After the reboot tried a new Snort install. This time it finished the install, yet: same problem, no Snort in the GUI. CPU in the GUI 54% (normally around 10), 'fetch' still 100%.
Uninstalled it again in Packages. Rebooted: CPU back to low, no 'fetch' to be seen in 'top'.
Yet, and I know this is weird: now WAN1 is constantly offline. ISP says no problems on their end.
Could it be there are some remains of Snort still doing nasty things?
[b]Is there a way for me to manually, in the CLI, check for remains I can remove? (I would like to keep my config, if possible).
Thank you for all the Great Work, Bill ;D
-
@Hollander:
Thanks Bill ;D
Some way or the other, there is a serious problem. I never had this before, it all just started after the last update :-[
I tried to install Snort again this morning (having uninstalled it yesterday due to the problems), and 'boom': CPU back to 100% again, due to 'fetch' (in 'top' in the CLI). The CPU was so much 100% it appears, that Snort even hung at 79% executing a PHP-script (let I do it's thing for 2 hours, then rebooted the box).
After the reboot tried a new Snort install. This time it finished the install, yet: same problem, no Snort in the GUI. CPU in the GUI 54% (normally around 10), 'fetch' still 100%.
Uninstalled it again in Packages. Rebooted: CPU back to low, no 'fetch' to be seen in 'top'.
Yet, and I know this is weird: now WAN1 is constantly offline. ISP says no problems on their end.
Could it be there are some remains of Snort still doing nasty things?
[b]Is there a way for me to manually, in the CLI, check for remains I can remove? (I would like to keep my config, if possible).
Thank you for all the Great Work, Bill ;D
Hollander:
I don't believe Snort has anything to do directly with that "fetch" process hanging up. Here is how to eliminate Snort from the equation.
1. Delete the Snort package by clicking the X icon in Installed Packages.
2. Open a CLI session and execute this command to be sure all Snort processes are dead and gone:
ps -ax |grep snort
It should show no running Snort processes. The only thing it should display is one line showing the grep command you executed. Check that all the Snort code is going by looking for this directory (it should be totally missing):
/usr/pbi/snort-amd64
3. Now reboot your box and see if you have problems. Reboot it twice even to be sure.
4. If you see the issues you describe with CPU utilization, then Snort can't be the problem if all the above steps produced the expected result.
My guess at the moment is maybe your configuration has gotten corrupt somehow, so even though you reinstall Snort, if it pulls in the same corrupt configuration then it would still have problems.
Bill
-
Thanks Bill ;D
ps -ax came back empty, and the directory is gone too: both good.
CPU is normal at 4% now. I just tried again: install Snort: CPU back to 100% due to fetch. I know that if you say it isn't Snort then it isn't Snort, yet it's a weird coincident that keeps on repeating itself. So I had to uninstall Snort again.
I am eagerly awaiting until JFL will find the time to write the SuricataTutorialNG (NG = BB ;D ), so I can try to replace Snort with Suricata.
-
Could it be that Snort cannot connect to the Snort or ET Download servers and it timing out? Do you run Squid? Maybe try to see if you can download the tarballs manually? I would have to look at the code to see the exact path required for Snort and/or ET.
-
@Hollander:
Thanks Bill ;D
ps -ax came back empty, and the directory is gone too: both good.
CPU is normal at 4% now. I just tried again: install Snort: CPU back to 100% due to fetch. I know that if you say it isn't Snort then it isn't Snort, yet it's a weird coincident that keeps on repeating itself. So I had to uninstall Snort again.
I am eagerly awaiting until JFL will find the time to write the SuricataTutorialNG (NG = BB ;D ), so I can try to replace Snort with Suricata.
You have something wrong in your configuration someplace. I don't know what it may be, though. I have never seen that behavior with any of VM testing over the last two years. Are you using IPv4 or IPv6 addresses?
Bill