Snort 2.9.6.2 pkg v3.1.4 – Bug Fix Update Release Notes
-
Snort 2.9.6.2 pkg v3.1.4 Update
This update corrects a bug in the code for periodically checking for posted updates to Snort rules. This is a minor update for the GUI package only. The underlying binary remains at version 2.9.6.2.
Bug Fix:
1. When an update to any of the configured Snort rule sets is detected and downloaded (VRT or Emerging Threats), Snort is sent a start command instead of a restart command for all interfaces. This leaves the Snort binary process still using the older rules until a manual restart is performed or the firewall is rebooted.
-
Updated & now I no longer have snort under services. It doesn't appear to start for me. Was not having any problems before. :(
With package reinstall it says
Starting Snort using rebuilt configuration…
Please wait while Snort is started...
Then it just stays in a loading state. I have no snort under services like I did previously. Any help?
System logs indicate that snort is running in the background & memory usage seems to indicate this as well, but I have no snort tab to configure anything. It looks like it pulled info from the previous install for what to run.
-
After updated, Snort service is not listed in the running services. I then restarted Snort, but only the instance on LAN is showed while the one on WAN is not.
I am on 2.2Beta 04NOV
-
I have the same problem since last update. (3.1.3)
No Snort tab in menu.
Snort service is not listed in service status.But snort is working correctly and i have still the Snort Alerts dashboard.
I can also access the Snort tab via the address …pfsense/snort/snort_interfaces.php
I was thinking that it is related to the 64bit version and that it will be corrected in the next version.
Unfortunately the problem persist in 3.1.4Pfsense 2.1.5-RELEASE (amd64)
Snort 2.9.6.2 pkg v3.1.4thanks for any suggestion.
-
Sorry to say I have no suggestion but on my 2.1.5 32bit I uninstalled, and reinstalled (box ticked to keep Snort settings) the whole package without issue.
-
I have the same problem since last update. (3.1.3)
No Snort tab in menu.
Snort service is not listed in service status.But snort is working correctly and i have still the Snort Alerts dashboard.
I can also access the Snort tab via the address …pfsense/snort/snort_interfaces.php
I was thinking that it is related to the 64bit version and that it will be corrected in the next version.
Unfortunately the problem persist in 3.1.4Pfsense 2.1.5-RELEASE (amd64)
Snort 2.9.6.2 pkg v3.1.4thanks for any suggestion.
What type of install are you running: full install to a disk, or a NanoBSD install to a CF card?
Bill
-
After updated, Snort service is not listed in the running services. I then restarted Snort, but only the instance on LAN is showed while the one on WAN is not.
I am on 2.2Beta 04NOV
Did you look in the system log for any relevant messages? My first suspicion is Snort encountered a problem starting on the WAN. Many times this is due to one or more disabled preprocessors. If this is the case, there will be a message in the system log containing the keywords "fatal error".
Bill
-
Updated & now I no longer have snort under services. It doesn't appear to start for me. Was not having any problems before. :(
With package reinstall it says
Starting Snort using rebuilt configuration…
Please wait while Snort is started...
Then it just stays in a loading state. I have no snort under services like I did previously. Any help?
System logs indicate that snort is running in the background & memory usage seems to indicate this as well, but I have no snort tab to configure anything. It looks like it pulled info from the previous install for what to run.
To be sure an older PHP include file is not being cached, completely remove the Snort package by clicking the "X" icon on the Installed Packages tab. Then reinstall it. Post back if you continue to have issues.
Bill
-
After updated, Snort service is not listed in the running services. I then restarted Snort, but only the instance on LAN is showed while the one on WAN is not.
I am on 2.2Beta 04NOV
Did you look in the system log for any relevant messages? My first suspicion is Snort encountered a problem starting on the WAN. Many times this is due to one or more disabled preprocessors. If this is the case, there will be a message in the system log containing the keywords "fatal error".
Bill
No messages with Fatal Errors, I also check preprocessors they are ticked and alert system shows both LAN and WAN activities. I will check later on today and I will report back.
UPDATE
With version
| 2.2-BETA (amd64)
built on Tue Nov 04 14:39:06 CST 2014
FreeBSD 10.1-RC4 |Everything is running as supposed to be.
161 processes: 5 running, 116 sleeping, 40 waiting
Mem: 170M Active, 882M Inact, 767M Wired, 18M Cache, 825M Buf, 6045M Free
Swap: 500M Total, 500M FreePID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND
11 root 155 ki31 0K 64K CPU3 3 16.8H 100.00% [idle{idle: cpu3}]
11 root 155 ki31 0K 64K RUN 2 16.8H 100.00% [idle{idle: cpu2}]
11 root 155 ki31 0K 64K CPU1 1 16.7H 100.00% [idle{idle: cpu1}]
11 root 155 ki31 0K 64K CPU0 0 995:44 100.00% [idle{idle: cpu0}]
62872 root 22 0 217M 33152K piperd 0 0:00 0.68% php-fpm: pool lighty (php-fpm)
4078 root 20 0 279M 130M nanslp 1 7:24 0.49% /usr/local/bin/ntopng -s -e -i igb1 -i igb
12 root -60 - 0K 640K WAIT 2 5:32 0.00% [intr{swi4: clock}]
6445 root 20 0 14664K 2280K select 2 0:54 0.00% /usr/sbin/syslogd -s -c -c -l /var/dhcpd/v
73186 root 40 20 665M 281M bpf 0 0:53 0.00% /usr/local/bin/snort -R 32316 -D -q -l /va 23809 root 20 0 12460K 2140K select 3 0:39 0.00% /usr/local/sbin/apinger -c /var/etc/apinge
0 root -16 0 0K 416K swapin 0 0:37 0.00% [kernel{swapper}]
73397 root 40 20 665M 278M bpf 0 0:34 0.00% /usr/local/bin/snort -R 48968 -D -q -l /va 4078 root 20 0 279M 130M nanslp 0 0:32 0.00% /usr/local/bin/ntopng -s -e -i igb1 -i igb
5 root -16 - 0K 16K pftm 0 0:31 0.00% [pf purge]
1406 root 20 0 24068K 4484K kqread 3 0:29 0.00% redis-server: /usr/pbi/ntopng-amd64/local/
4078 root 20 0 279M 130M nanslp 2 0:28 0.00% /usr/local/bin/ntopng -s -e -i igb1 -i igb
12 root -92 - 0K 640K WAIT 0 0:25 0.00% [intr{irq257: igb0:que}]
15 root -16 - 0K 16K - 0 0:25 0.00% [rand_harvestq] -
Hi bmeeks,
to your question: i have a full install to a disk on a old server HW.
It is actually overkill with 10GB RAM and it is not doing much but i left it as it was.
I haven't found any errors in log and snort is clearly running and blocking alerts as it should.
i also reinstalled it few times without effect.Because the snort alert dashboard tab is still there i can easily access the Snort service site by the link on the title
and can manage snort witch also works properly. -
Hi bmeeks,
to your question: i have a full install to a disk on a old server HW.
It is actually overkill with 10GB RAM and it is not doing much but i left it as it was.
I haven't found any errors in log and snort is clearly running and blocking alerts as it should.
i also reinstalled it few times without effect.Because the snort alert dashboard tab is still there i can easily access the Snort service site by the link on the title
and can manage snort witch also works properly.I'm not sure what could have happened. The presence of the "snort" link under SERVICES is handled by the pfSense package installer code. That is one of the last things it does as it saves the final new configuration for the package. The Snort package itself has no control over that.
Perhaps there is some subtle corruption in the <packages>section of your config.xml file. pfSense reads that section to determine what menu entries to display under the SERVICES item. So just to be sure I understand your problem, under SERVICES on the pfSense menu you do not have a choice for "Snort". Is that correct?
Bill</packages>
-
Yes, no link in Services menu and snort is also not listed in Status->Services
-
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 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
