Snort 2.9.6.2 pkg v3.1.4 – Bug Fix Update Release Notes
-
@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 snortIt 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
