Snort and Suricata are way too memory hungry to run on a system with only 256 MB RAM and no swap.

It will vary by location (LAN vs WAN) of the IDS sensor.  Snort and Suricata both see packets from the WAN before they hit the packet filter, so no port translation has yet taken place on inbound (from Internet to your firewall) traffic.  When on the LAN, the IDS is seeing stuff after NAT translation to local addresses/ports. So think of a series circuit on the WAN side.  You have your NIC, then the IDS, and then the firewall.  So the IDS sees traffic before the firewall does and thus no firewall rules have been evaulated (to say block stuff) and NAT has not yet happened.  This is why the IDS will still alert even for inbound traffic the firewall will later block due to a rule. Now to get even more technical, Snort (and Suricata when running in the legacy mode) actually use libpcap to get a copy of the packets coming through the circuit from NIC to packet filter.  The IDS operates on this copy while the actual original packet continues through.  If the IDS decides the traffic is malicious, it inserts the offending IP address into the packet filter (firewall) and then kills any states that may have been established when that original packet went on through while the IDS was evaluating the copy. Bill

I will look into this one.  There were lots of changes in the ALERTS tab code for the Bootstrap and inline IPS updates.  Looks like something got messed up with the intermixing of HTML and PHP code. Bill

A new package version has been posted that fixed this issue.  It is package version 3.0_5. Bill

@vbentley: Hopefully, in response to CVE-2016-1345 https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20160330-fp it will get bumped to 2.9.8.2 Snort on pfSense is NOT compiled with the "–enable-file-inspect" flag, so it should not be vulnerable according to the security bulletin. Updates to the pfSense binaries for Snort and Suricata only happen after those updates are posted in FreeBSD ports. Bill

I don't use any commercially provided VPN's so I'm not entirely certain where your problem is. However, perhaps terminating your side of the VPN on a new pfSense interface (LAN2/OPT1 whatever) introducing an additional hop may help if you want specific Snort rules (or none) for this interface only.

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.