SNORT



  • There seems to be a bug with how your gui interfaces with Snort.
    I contacted Snort with a very detailed bug report. Within 30 seconds they responded (so they couldn't have read the whole thing) and replied back: You may want to reach out to PfSense guys on this one. We make the engine, this seems like their implementaion of it.

    The basic problem is that if I "force-disable" a rule IE: SID 119:4, it shows it is disabled but it still blocks traffic using that rule. This was a problem 5 years ago, 3 years ago, and 1 year ago. Supposedly they have fixed it. But yet, here were are with it still happening. Let me know if you plan to pass the buck back to Snort before I provide anymore detail. Otherwise, I'll dump a huge load of data on you. ;)

    Later: I stopped Snort. Checked the processes to make sure it was no longer running. It is STILL blocking sites. So apparently when the GUI stop button is clicked, it stops the process but does not fix the rules, so it is still functioning from the last settings. I had to remove the package to get it to quit, or try to figure out yet again, why the gui doesn't do as it should.



  • You apparently do not understand how Snort works on pfSense. Snort can't block anything on its own. It works in conjunction with the firewall to implement a block. Simplifying things a bit with this explanation, but each time a Snort alert is triggered the firewall is asked to create a custom firewall rule to block all further traffic to/from the offending IP address. You also have the option within the GUI of blocking only the SRC, only the DST or BOTH IP addresses in the offending packet.

    The custom firewall rule is actually implemented by writing the IP address to be blocked into a pf (packet filter firewall) table called snort2c. This table is created by the pfSense code at bootup. It lives near the top of the pf filter chain. You can view the current contents of this table using DIAGNOSTICS > TABLES from the pfSense menu. All IP addresses listed in that table are being blocked by the firewall. The IP addresses get put there upon command from Snort. When you view blocked hosts on the BLOCKED tab, that GUI code is actually just reading the contents of that snort2c table and showing the IP addresses to you.

    So when you just stop Snort, it does not remove the IP addresses from that snort2c table. They will remain until one of three things happen: (1) you manually clear the table; (2) a cron task implemented by Snort runs to clear IP addresses that have seen no activity in the interval specified (you set this interval in the GUI on the GLOBAL SETTINGS tab); or (3) the firewall is rebooted.

    There is a configurable option under General Settings on the GLOBAL SETTINGS tab that will cause Snort to clear out the snort2c table when the package is removed. This is also the same area where you can configure if, and how often, that cron task runs to clear blocked hosts.

    The only time I have ever seen Snort continue to alert on a disabled rule is when there are multiple instances of Snort running, and one or more of the sessions is in a sort of zombie state where it does not realize the configuration has changed. Either a device reboot or manually terminating the extra Snort processes will fix this.

    I run Snort on my personal firewall, and I have several disabled rules, and they never alert or block for me. This is not a widespread problem or there would be a lot of posts here about it. There are many Snort package users on pfSense.



  • @bmeeks

    I'm sure you are right. I've only used it for 3 years. And no there were NOT multiple instances running.



  • @lshantz said in SNORT:

    @bmeeks

    I'm sure you are right. I've only used it for 3 years. And no there were NOT multiple instances running.

    There is one other possibility I forgot to mention, and that is Auto-Flowbit rules. It is possible for the auto-flowbits resolution process to enable some rules behind your back, but that code now does make one last run through the user's force-disabled rules as the last step in building the auto-flowbit rules. In times past the GUI code did not make that last pass and some user disabled rules were getting turned back on. That should not be happening now.

    If you know the exact rule that is disabled but still firing, you can search for it in the active rules file. Open a CLI session with the firewall and grep the snort.rules file in /usr/local/etc/snort/snort_xxxx/rules/snort.rules (where xxxx is a random GUID and the physical interface name. See if the rule (hunt by SID) is present in that file. Also search the autoflowbits.rules file as well in the same sub-directory.



  • @bmeeks

    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.

    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.

    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.



  • @bmeeks said in SNORT:

    I run Snort on my personal firewall, and I have several disabled rules, and they never alert or block for me. This is not a widespread problem or there would be a lot of posts here about it. There are many Snort package users on pfSense.

    BTW... do a search on google for snort force-disable and tell me a lot of people have not had the same problem. ;)



  • @lshantz said in SNORT:

    @bmeeks

    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.



  • @bmeeks said in SNORT:

    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
    bandwidthd

    and 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



  • @modesty said in SNORT:

    Hi

    i run on latest pfsense with installed pagages:
    squid
    snort
    pfBlockerNG
    Lightsquid
    bandwidthd

    and 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

    Are 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-p4

    I have an SSD disk on 60 gbyte
    0_1544612724134_521a16a8-a639-46b8-94bb-24c8267ce271-image.png

    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.

    1. 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.

    2. 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:
    0_1544653843401_f0ccd729-ef8c-4602-b690-14fd515f6ff8-image.png

    PS I did not use RAM disk, and i dont use.



  • @modesty said in SNORT:

    Hi, and thanks!

    Uninstal+install did it. Snort is running:
    0_1544653843401_f0ccd729-ef8c-4602-b690-14fd515f6ff8-image.png

    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.



  • @modesty
    There was a tool called Snorby, but it is no longer maintained. Some users here are experimenting with a tool called Graylog available here. Other folks use ELK, but to be honest ELK works better with Suricata using the EVE log options in that package. You can learn about ELK here.