It's not the answer you want to hear, but you have to make that decision yourself. When the IDS detects an intrusion, what you do about it is your decision. Generally, I trust my IDS and act on what it reports. If the intrusion can be safely blocked without breaking any services then it stays blocked. If blocking breaks stuff then I usually capture the traffic in wireshark and take my time to check what is actually happening. If I can't block the intrusion because it is from a provider I will contact their sysadmin. Usually, when evidence is presented to the sysadmin the intrusion stops. If it doesn't stop, chew whoever is insisting on using the provider by letting them know how much it is costing to deal with the provider's bad behaviour and insist on a compensatory discount at contract renewal or change of provider.

@coachmark2: Do we think that this is something to do with this bug or is it the HP 7506 not passing some sort of traffic between the two boxes that needs to be passed? That has nothing to do with this. Worst case, this causes the config sync to fail to happen, so nothing changes on the secondary. Also not likely it has anything to do with your network. Rough guess, maybe you're setting the CARP IP to the same IP as the LAN IP of the secondary, or something similar where the presence of the VIP breaks the IP of the secondary. Start a new thread describing what you're doing and what you're seeing.

The problem was the /tmp and /var space.  Due to NanoBSD implementation, defaults were in place 40Mb and 60Mb.  However, the box I'm running it on is running AMD G-T40E dual core w/ 4G RAM.  I increased the size of the /var and /tmp to 500 MB each and reinstalled SNORT packages.  Took SNORT a bit over 5 minutes to start up, but it's been running with out issues with Balanced IPS policy and Emerging Threat rules enabled.

Hi Howard: I responded in another thread on this issue.  This one may take some time to fix. Bill

This bug is fixed in the new Suricata 3.0 package available for pfSense 2.3-BETA. Bill

Thanks for the update. Is this something that might be examined during the development or in a subsequent release? Is there something I can configure locally? Best Regards, Howard

@crester: Hello. After the new campaign of radsonware I have received few custom.rules to add to snort (from intel security, see bellow) Also, make sure you check the new track/blocklist from abuse.ch https://ransomwaretracker.abuse.ch/blocklist/ F.

@Kryptos1: Hello Bill, Thank you for the reply. I found where the snort configuration files were. If someone modifies the suppress list texts with a text editor, what would be the command to restart/reload snort so that text file is reread and loaded? I'm trying to learn and document all the commands necessary to manage snort/pfsense remotely over ssh. Chris There is a shell script (/usr/local/etc/rc.d/snort.sh) that you can execute to restart Snort. Just call that script with one of these arguments:  start, stop or restart.  I suspect restart is the one you want to use.  The shell script will impact all of the configured Snort interfaces. Bill

The last supported version of Snort for 2.1.x hasn't been supported by Cisco for signature updates in quite some time and hence the package was removed, since it could no longer function. There are no known stability issues with IPsec in 2.3. There is still a status problem we're working on where sometimes the status pages hang, but it doesn't affect functionality. Starting a thread on what you were seeing there would be your best bet.

I found several other errors this past Friday in the new Suricata GUI code.  They result in some parts of SID MGMT working incorrectly.  There are also problems with saving changes to a few things on the FLOW/STREAM and APP PARSERS tab.  I have a comprehensive fix almost ready to post that addresses these and a few other cosmetic issues. Sorry for the bugs, but converting a package to Bootstrap is a major change.  In the rush to completion we missed some things in testing. Bill

By the way, this parameter (max-synack-queued) is now configurable in the GUI for an interface on Suricata 3.0 in pfSense 2.3-BETA. Bill

Your IP address definitions are incorrect.  The error message is essentially telling you what's wrong.  You have "not this IP" ranges that are more general than your "this IP" ranges.  What you need to do is invert your ranges.  Make your "this IP" range more inclusive than your "not this IP" range.  Posting your rule with the actual IP address ranges might help us troubleshoot this with you.  The rule is on line 2256 of the file /usr/pbi/snort-amd64/etc/snort/snort_15257_igb4/rules/snort.rules Bill

Awesome . I will give that a try tonite and test it out.  Thanks for the quick reply.

ok, solved my problem. Mine was related to network memory buffers (mbuf) as descriped here: https://doc.pfsense.org/index.php/Tuning_and_Troubleshooting_Network_Cards#mbuf_.2F_nmbclusters This seems to be a "known bug"  respectively demand for manual tuning of standard pfsense settings if you have many CPU-cores AND many NICs on your machine (mine has 8 cores and 5 NICs). After setting it to a Million (1.000.000), everything is fine again, no more suricata crashes (despite the fact that suricata does not handle all VRT-rules, but "that´s another roadworks", as we say in Germany  ;) ).

NanoBSD uses RAM disks for storage.  The default sizes are almost never large enough to provide space for downloading, extracting and installing the vendor rule packages.  When you run out of RAM disk space, very strange things happen.  Lots of times the installation becomes corrupt to the point a reinstall is required. I do not recommend running either Snort or Suricata on NanoBSD installations.  There are just too many issues with disk space.  The forums here have plenty of posts from NanoBSD users with these kinds of problems.  My advice is to go back to a conventional hard disk.  If you absolutely don't want to do that, then you can try increasing the size of the /tmp and /var partitions to at least 150 MB each (and preferably a lot more!).  Even doing that, be prepared for the occasional weirdness with either of these packages on NanoBSD installs. Bill

The IPS Policy selection is shown on the RULES tab so you can see which exact rules have been auto-selected by the chosen policy.  You may already know this, but I will repeat it for the benefit of others who may read this thread.  The Snort VRT tags each of their rules with policy keywords (connectivity, balance or security).  Some rules may have all the keywords associated with them, or just one or two.  The IPS Policy option in the Snort package on pfSense examines all the Snort VRT rules and pulls out only the rules marked with the policy keyword you select.  So it is true that the rules in IPS Policy are actually in all of the other category files. Now on to your question.  You can disable the rules in either place (in the actual Category or when viewing the IPS Policy option).  Rules are recorded for user-defined enable/disable states by their GID:SID number, and those are stored in the config.xml of the firewall.  The last thing Snort processes when building the final rules package for an interface is the list of manual user rule state overrides.  So when you click on the rule icons on the RULES tab to force enable or force disable a rule, that rule's GID:SID is recorded in the firewall's Snort configuration along with the state you toggled it to (enabled or disabled).  Snort will then honor your setting for that rule when building the final rules package file (which by the way, is called snort.rules).  The snort.rules file is built by the Snort GUI package code, and will contain only the rules actually being used for the interface.  Rules you have disabled will not be in the snort.rules file.  Conversely, rules you have explicitly enabled will be in the snort.rules file. I will also mention that not all rules are enabled in a given category.  This is the way the Snort VRT ships them.  Some rules are commented out (disabled) by default.  Those are displayed in gray on the RULES tab.  You can leave them default disabled, or you can click the toggle icon to force them to the enabled state if you want to use them.  Now here is the tricky part:  when you choose to use the IPS Policy option, any rule tagged with a matching policy keyword (connectivity, balanced or security) is going to be sucked into the final snort.rules file and will get enabled even if it was default disabled in the category file it was pulled from.  So when using IPS Policy, all rules shown will be enabled and used unless you explicitly click the toggle icon to disable one or more of them. Bill