SNORT
-
Honestly I was pissed off enough I removed the package yesterday. Interestingly enough, when I was doing a detailed report for Snort on exactly what was happening, I discovered under the rules that not a single rule was checked! I don't know how they all went away, but they were gone. Yet Snort was still enforcing the non-existent rules. So, I stand by what I said. The gui is not properly following the configuration settings. Force-disable should equal "disabled"! That is NOT what was happening. I found myself every few days running packet traces to find out why someone could not reach a web site. Then once the IP address was found, remove the block, again.
I have not seen this behavior where disabled rules still fire either on my personal firewall running on actual hardware, nor on the numerous VMware virtual machines I test with. What version of pfSense and Snort package are you running? You can see the Snort package version under SYSTEM > PACKAGE MANAGER.
Will you be willing to share the Snort portion of your config.xml file with me via PM? I can import it into a virtual machine and test. If you are willing to share it, I can give you instructions for pulling out the sections I need related to Snort and how to sanitize so as to remove critical passwords without killing its utility for my troubleshooting effort.
A fantastic concept to be sure, but when it isn't running right, can be very frustrating. Even Snort folks backed away from my detailed report saying that Pfsense must be doing something wrong.
In your case I don't think it is anything wrong with the Snort binary itself. Also, to be fair, it must not be a significant bug in the pfSense GUI implementation or else there would be a ton of other irritated folks posting here with the same issue. So let's approach this is a rational manner and try to troubleshoot what's wrong in your specific setup. I understand you may be frustrated, but your approach thus far sounds like you do not even want to even consider that perhaps you have done something wrong within your specific setup that is causing your issue. You just say Snort must be broken. If Snort was as broken as your rant suggests, then this forum and the upstream Snort mailing list would be flooded with users complaining about the same thing.
Also, my opinion is that when you turn a service off, it should run a script to remove Snort rules so that it is "off". My analogy would be it is like when you turn your car off. Turn the key to off, but that isn't enough. The motor still runs until you raise the hood and disconnect the battery.
Some other users will likely disagree there a bit. They want the blocks to stay. Some, in fact, want the blocks to even survive a firewall reboot (they currently do not and likely never will). One problem with adding the feature you suggest is that within the snort2c table I talked about, there is no way for the GUI code to easily know which Snort interface put a given IP address in there. There are a good many users who run Snort on multiple firewall interfaces. Each interface runs totally independent of the others in terms of configuration, but they all share the same single snort2c table for implementing the blocking of IP addresses. So if say the LAN interface was stopped, Snort running on the LAN does not easily know which IP addresses in the table it should clear when stopping. You have to assume that an admin running multiple Snort instances on different firewall interfaces would want only the instance he was shutting down to clear its inserted IP addresses. He would not likely want the entire table cleared if only a single interface was shutting down.
If you want to stop Snort from continuing to block after shutting it down (remember it's really the firewall blocking at that point and not Snort), you can go to the BLOCKED tab and click the button to clear all blocked hosts. This works whether Snort is running or not. If you have already uninstalled the Snort package and a block remains, you can go to DIAGNOSTICS > TABLES in the pfSense menu, select the snort2c table in the drop-down, and then clear that table using the clickable button on the page. Either of these two methods will remove any remaining Snort-blocked IP address from the firewall's blocking rules.
The better option for removing blocked hosts is to utilize the automatic cron task I mentioned. This is configured on the GLOBAL SETTINGS tab. That task, when enabled, runs independent of Snort. So whether Snort is running or not, the cron task will still execute every 5 minutes. It will automatically clear hosts from the blocked table that have not seen activity within the configured interval. I suggest setting that interval to 1 hour at most, and even shorter is fine.
-
I have not seen this behavior where disabled rules still fire either on my personal firewall running on actual hardware, nor on the numerous VMware virtual machines I test with. What version of pfSense and Snort package are you running? You can see the Snort package version under SYSTEM > PACKAGE MANAGER.
It was the latest version of both Pfsense and Snort. The box was built from scratch about a month ago because there were just too many unexplained instances of things not doing what they were supposed to do and I decided there may have been some corruption creep. Within the last year or so they made a switch that put 2 directories into a ram drive. So if there is no UPS and it loses power, you have a 70/30 chance of corruption. I learned this the hard way. Those little boxes used to be bullet proof. You could just pull the plug or the power could go out and they would stand right back up. All of a sudden I noticed that wasn't the case about a year ago or so. I finally figured out what it was, but have since added a long overdue newer UPS that supports what I needed to make an orderly shutdown.
Will you be willing to share the Snort portion of your config.xml file with me via PM? I can import it into a virtual machine and test. If you are willing to share it, I can give you instructions for pulling out the sections I need related to Snort and how to sanitize so as to remove critical passwords without killing its utility for my troubleshooting effort.
Absolutely! I can forward the report I sent Snort if you are willing to look at it. I am most happy to be proven wrong. If nothing else, it may present an opportunity to put something in the help files to help folks. ?
In your case I don't think it is anything wrong with the Snort binary itself. Also, to be fair, it must not be a
I would concur. I think it "may" be how it is implemented in Pfsense, or as you suggested a simple misconfiguration on my part.
The better option for removing blocked hosts is to utilize the automatic cron task I mentioned. This is configured on the GLOBAL SETTINGS tab. That task, when enabled, runs independent of Snort. So whether Snort is running or not, the cron task will still execute every 5 minutes. It will automatically clear hosts from the blocked table that have not seen activity within the configured interval. I suggest setting that interval to 1 hour at most, and even shorter is fine.
I will admit I do not recall seeing this option.
And you are right, it was more like a rant. For that I apologize. Old age and pain can bring that on. ;)
I'll poke around and see if I can PM you within this app and if so will send you my report and look for your instructions on sanitizing the xml file you desire.
LS
-
You can try first just sending me a list of SIDs (and the GIDS if you are disabling any preprocessor rules) of disabled rules. I can start testing there.
I do not mean to say there can't be a bug in the Snort GUI. There certainly have been before, but I try to gauge the magnitude of a bug by the posts to this sub-forum. There were several changes required in the PHP GUI code as a result of pfSense adopting PHP 7.2 with the last release.
-
Hi
i run on latest pfsense with installed pagages:
squid
snort
pfBlockerNG
Lightsquid
bandwidthdand updated snort from 3.2.9.6_1 to 3.2.9.8_4
I get errors, here is my log. hope sombody can give me a hand:
Upgrading pfSense-pkg-snort...
Updating pfSense-core repository catalogue...
pfSense-core repository is up to date.
Updating pfSense repository catalogue...
pfSense repository is up to date.
All repositories are up to date.
Checking integrity... done (0 conflicting)
The following 1 package(s) will be affected (of 0 checked):Installed packages to be UPGRADED:
pfSense-pkg-snort: 3.2.9.6_1 -> 3.2.9.8_4 [pfSense]Number of packages to be upgraded: 1
[1/1] Upgrading pfSense-pkg-snort from 3.2.9.6_1 to 3.2.9.8_4...
[1/1] Extracting pfSense-pkg-snort-3.2.9.8_4: .......... done
Removing snort components...
Menu items... done.
Services... done.
Loading package instructions...
pfSense-pkg-snort-3.2.9.6_1: missing file /usr/local/share/licenses/pfSense-pkg-snort-3.2.9.6_1/APACHE20
pfSense-pkg-snort-3.2.9.6_1: missing file /usr/local/share/licenses/pfSense-pkg-snort-3.2.9.6_1/LICENSE
pfSense-pkg-snort-3.2.9.6_1: missing file /usr/local/share/licenses/pfSense-pkg-snort-3.2.9.6_1/catalog.mk
pfSense-pkg-snort-3.2.9.6_1: missing file /usr/local/www/snort/snort_download_rules.php
pkg-static: Fail to rename /var/db/snort/sidmods/.disablesid-sample.conf.WevUUm19O5CM -> /var/db/snort/sidmods/disablesid-sample.conf:No such file or directory
Failed -
Hi
i run on latest pfsense with installed pagages:
squid
snort
pfBlockerNG
Lightsquid
bandwidthdand updated snort from 3.2.9.6_1 to 3.2.9.8_4
I get errors, here is my log. hope sombody can give me a hand:
Upgrading pfSense-pkg-snort...
Updating pfSense-core repository catalogue...
pfSense-core repository is up to date.
Updating pfSense repository catalogue...
pfSense repository is up to date.
All repositories are up to date.
Checking integrity... done (0 conflicting)
The following 1 package(s) will be affected (of 0 checked):Installed packages to be UPGRADED:
pfSense-pkg-snort: 3.2.9.6_1 -> 3.2.9.8_4 [pfSense]Number of packages to be upgraded: 1
[1/1] Upgrading pfSense-pkg-snort from 3.2.9.6_1 to 3.2.9.8_4...
[1/1] Extracting pfSense-pkg-snort-3.2.9.8_4: .......... done
Removing snort components...
Menu items... done.
Services... done.
Loading package instructions...
pfSense-pkg-snort-3.2.9.6_1: missing file /usr/local/share/licenses/pfSense-pkg-snort-3.2.9.6_1/APACHE20
pfSense-pkg-snort-3.2.9.6_1: missing file /usr/local/share/licenses/pfSense-pkg-snort-3.2.9.6_1/LICENSE
pfSense-pkg-snort-3.2.9.6_1: missing file /usr/local/share/licenses/pfSense-pkg-snort-3.2.9.6_1/catalog.mk
pfSense-pkg-snort-3.2.9.6_1: missing file /usr/local/www/snort/snort_download_rules.php
pkg-static: Fail to rename /var/db/snort/sidmods/.disablesid-sample.conf.WevUUm19O5CM -> /var/db/snort/sidmods/disablesid-sample.conf:No such file or directory
FailedAre you by chance using a RAM disk for /tmp? This kind of issue can happen when you run out of free space in the /tmp tree. Packages need a lot of free space to download dependencies and such and then unzip them for installation. If you are using a RAM disk, then try bumping up the volume size to at least 256 MB.
Is this repeatable? Do you get the same error if you retry the package installation?
-
@bmeeks thanks for answer.
I run on PC Engines APU2, pfsens version:
2.4.4-RELEASE-p1 (amd64)
built on Mon Nov 26 11:40:26 EST 2018
FreeBSD 11.2-RELEASE-p4I have an SSD disk on 60 gbyte
So i assume there is enough space, but i dont know if it is a RAM disk for /tmp
My installation is pretty close to standard.
I have tryed to update, i have not done a uninstall + install.And snort is not running after failed update. Any other tips?
-
Your installation errors are happening well before the Snort package is ready to start. Actually, it's the pkg utility that is logging those errors and they appear to be from the uninstallation of the existing package. Notice the package version numbers in the errors.
Try this.
-
Remove the Snort package completely if it shows up under SYSTEM > PACKAGE MANAGER on the Installed Packages tab. You will not lose your previous configuration if Save Settings is checked on the GLOBAL SETTINGS tab of Snort.
-
After removing the package, then go back to SYSTEM > PACKAGE MANAGER and install the package from the Available Packages tab. See if that works.
If you still have problems, post back. The pkg utility will first uninstall any previous version before installing an upgrade. It appears something is amiss with your previous version (at least within the database where pkg stores installed packages information).
-
-
@modesty
Try changing the tmo directory from ram to HD. Go to system/advanced/misc. Scroll down to RAM disk settings. If use ram disk is clicked. Uncheck it, reboot and try again. -
Hi, and thanks!
Uninstal+install did it. Snort is running:
PS I did not use RAM disk, and i dont use.
-
Hi, and thanks!
Uninstal+install did it. Snort is running:
PS I did not use RAM disk, and i dont use.
Happy you got it fixed. When I first read your installation error message I did not pay enough attention to the version information. Somehow the original install files (or at least some of them) from your 3.2.9.6_1 package version got deleted by something other than the pkg utility. That utility keeps a database of what files it copied to where during a package installation sequence. When upgrading that package later on, the pkg utility first removes the old version's files and then copies over the new ones. In your case, it could not find the old version files and was aborting the upgrade process.
-
Snort is running and i get a lot of alerts :
Is there a analyze tool i can use, preferably a open source (free) so i can start understanding what is happening outside my router?
I am no TCP/IP expert so a graphical tool would be the best in the beginning.
Thanks up front.
-
-
@bmeeks
Hi. I only run windows + pfsense so Graylog is not for me.
Can it be that there is no opensource log analyzer for snort logs? -
@bmeeks
Hi. I only run windows + pfsense so Graylog is not for me.
Can it be that there is no opensource log analyzer for snort logs?For pretty much all of the open source stuff out there for log consolidation and analysis, you are going to need a Linux box to host the software. I suggest a VMware host and then one or more Linux virtual machines. If you are a Windows shop, then Hyper-V can be your host and you can run the Linux VMs on it.
The new fad these days is JSON logging, so most of the tools that ingest log files are tending toward accepting that format natively. However, some can still take plain text logs. You just might have to fiddle around with regular expressions and other minutia to get it working.
