This has been fixed in the upcoming Snort 4.1.6_6 package which should show up in the new pfSense Plus 23.01 RC and the pfSense 2.7.0 CE branches.

@bmeeks Just in case anyone following this cares :), I am now only running port scan rules on my WAN interface, and leaving everything else in my LAN interface. This was easy to do because I run everything from SID files, so I just downloaded my custom Enable and Disable files, copied them as "EnableWAN" and "DisableWAN," whittled down the contents from each that pertained to "emerging-scan"...configured them in the List Assignments area, clicked the Rebuild boxes, hit Save, and I was off to the races. Only extra thing I had to do was in the "WAN Categories" tab - I had to hit "Unselect All" and "Save" to disable the (now-manually-checked remnant) rulesets that had been previously enabled by the old SID files. The one category in my "EnableWAN" file stayed enabled with the special little "A" icon. Everything really is much more "sane" now - I am getting the port scanning protection I want on the WAN; I have more sane "Blocks"; and I have better Alert information logs for the LAN. All that, and using much less RAM (usually was running at 31-35%; now at 21-22%) Thanks again!

@troutpocket said in Suricata unable to initialize: @bmeeks That's wild... because I only ever installed it via the WebUI! I have ripped it out again and rebooted the router again and installed it (from the WebUI) again... and now it starts up. False alarm. I guess I have a different problem on my hands. Yeah, that ipfw error is definitely not from a standard package installation. Or else someone manually edited the suricata.yaml file for the interface and uncommented that IPS divert option (or copied over one not from a normal pfSense installation that had that option enabled).

@michmoor FIXED. What i did? Unselect the option to send to syslog. Clicked Save. Then i received the following message EVE Output to syslog requires Suricata alerts to be copied to the system log, so 'Send Alerts to System Log' has been auto-enabled. Tested again...Works. Alerts received in the logging server as well as email notification.

@cybersec_s said in Colbaltstrike Alert on Suricata: @bmeeks whew! Thank you for clarifying this The suricata.log file is where Suricata writes its startup messages, and any pertinent errors that occur. That log file is recreated each time Suricata is started. That is not where alerts and blocks are logged, though. Those are written to individual files located in subdirectories under /var/log/suricata/ for each configured interface. But it is far easier to view the alerts and blocks using the GUI tools available on the ALERTS and BLOCKS tab in Suricata.

@nogbadthebad Thank you. I beleived this was an alert I could disable or supress but didn't want to do it until I know more about the alert. thank you. My Google searches did not result in good explinations.

@cybersec_s said in Suricata found disabled: @steveits Thanks for your reply. I figured out my issue. I'm using my device in transparant mode and had it configured incorrectly. I have the WAN and LAN ports bridged and also had IP's on both ports. once I removed the IP's and placed one on the Bridge(for local gui access) the service stayed active asfter a reboot. Be warned that Suricata (or Snort) does not like bridged interfaces. The service may start, but actual performance there may be questionable. Officially from upstream, off-norm interfaces such as bridges, LAGGs, etc., are not supported by Suricata.

@bmeeks Thank you very much for the detailed resonse ! Perfect exactly what I needed Thank you again ! Brilliant help !

@SteveITS @bmeeks Thanks. I will add this great info to my documentation.

@michmoor said in Blog suricata-vs-snort - Snort 3.0?: @bmeeks This is extremely insightful here. Thanks for the added detail that im glad i know about now. So the way i see it, the IPS is only 'useless' on pf from the standpoint of lack of integration with any MITM process. In a perfect world with unlimited resources if there can be some integration then the IPS component would be of more value. As it stands, its pretty useless (no disrespect to you of course), and this is more in line with what you have been saying for quite some time about its usefulness. Correct. But it's not just pf. The same is true with many other operating system configurations. My point in my other postings about the "usefulness" of IPS is that on the perimeter it is becoming less and less effective due to the encryption. Thus having it on the firewall inspecting traffic flowing between hosts is not really doing a whole lot unless the payload data is cleartext.

@wangel said in Suricata spawning 2 processes ?: @bmeeks Very Very interesting. At least .... I'm not alone!? LOL I bought an Intel Nic, because everyone says "they are the best to use with pfsense" ... which I don't doubt, just, I do want to use inline mode to take that load off my cpu. Is there a recommended card ? I need a 4 port nic. I guess the "hang up" is a hit or miss thing. I have another 4 port Intel NIC that I could try. It's the PRO/1000 ET(2) The only difference is the ET(2) has IPSec offloading and SRV-IO. With netmap, any type of offloading on the NIC is a bad idea. It seldom works right. And the Inline IPS Mode uses the FreeBSD netmap device for the traffic drop mechanism. I'm not 100% sure the issue is restricted to only certain Intel NICs. Several of the OPNsense users were running virtualized, if I recall correctly, and were still having the issue. With FreeBSD, the older the NIC the better supported it is likely to be. The upcoming pfSense Plus 23.01 release uses FreeBSD 14.0-CURRENT, so it will have the best support for newer hardware. The current release versions of pfSense are based on FreeBSD 12.3-STABLE.

Are you using Inline IPS Mode or Legacy Blocking Mode? With Inline IPS Mode there is no blocking of all traffic for an IP address. Only individual packets trigger a rule will be dropped, but other traffic that does not trigger a rule is passed. With Legacy Blocking Mode, any alerting rule will potentially result in the IP address(es) from the packet that triggered the rule being added to a built-in pfSense packet filter table called snort2c. Once an IP is placed in that table, hidden built-in firewall rules within pfSense will block all traffic to/from that IP address. Inline IPS Mode does not place an IP address in the snort2c table, therefore it won't show up on the BLOCKS tab as that tab simply shows the current contents of the snort2c table. To find alerts that resulted in dropped packets when using Inline IPS Mode, look on the ALERTS tab for entries printed in red. Pass Lists are how you "whitelist" an IP with Legacy Blocking Mode, but there are several steps that must be performed in the correct sequence. First, create the Pass List and make sure the address or network is added to it. Save the list. Next, go to the INTERFACE SETTINGS tab and select the correct Pass List in the Pass List drop-down selector and then save that change. Finally, you must restart Snort on the affected interface in order for the running daemon binary to pick up the Pass List assignment. This part of your message is confusing: This website got blocked by snort and we added it to the pass list and it seems like snort is ignoring it's entry on the pass list. The website does not appear to be in the blocklist either. With Legacy Mode Blocking, Snort cannot block anything without putting the IP in the snort2c table. And any IP in that table will show up when you view the BLOCKS tab. It may very well be that Snort is not the cause of your problem if the website's IP is not showing on the BLOCKS tab -- either that or you are not looking for the correct IP. Be aware that many websites are behind CDNs and thus may be using a large number of IP addresses that can change every few minutes. Some CDNs have TTL values in DNS set to as low as 2 minutes, and many others have it set to 5 minutes. That means a given IP might only be valid on your box for 5 minutes or less before it changes again with the next client that performs a DNS lookup.

@keyser this is how I got mine working. Forwarded logs to Elk.

@stewart said in Suricata Feodo Botnet and ABUSE.ch SSL Blacklist: @bmeeks So enabling them just adds the options in the categories view? That's good to know. It also sets them to be automatically downloaded/updated during the periodic rules update cron task. But it does NOT mean they are automatically used to inspect traffic. That only happens when you enable them on the CATEGORIES tab by checking the box, or they are pulled in by conf settings on the SID MGMT tab.

@youngy said in Setting drop (block) for Snort IPS policy rules in Suricata with Legacy Mode: @bmeeks Many thanks for the time and effort you put in to these packages. I have created a Pull Request containing this new feature. It is awaiting review and merge by the Netgate developer team: https://github.com/pfsense/FreeBSD-ports/pull/1212. This change will initially be only in the new 2.7.0 CE and 23.01 development snapshots, but will go to general release at the same time those new versions do. So far as I know (and I have no inside knowledge), that is scheduled to be this month or perhaps early February for the new pfSense release.

Jonathan, thanks for reporting! This disruption was due to an internal automation failing - we've fixed that problem and added some further alerting around failure points. We pushed the rules after the fixes were made on Saturday morning. I'm glad we caught this post, and I'd also like to invite everyone to interact with us on twitter @et_labs and to join our Discourse. Thanks again!

@bmeeks said in pass list: u will also need to manually remove the blocked IP from the BLOCKED HOSTS tab using the buttons there. Simply adding and IP to a Pass List will not remove any previous or existing blocks. Legacy Mode Blocking works by sending an IP address to be blocked to the pfSense firewall engine. Once the IP is sent over and blocked, Snort does nothing further with that IP address. So, that means stopping Snort or adding the IP to a Pass List will not remove the block. Only clearing the IP from the pf firewall engine's snort2c table will remove the bloc thanks again! happy 2023!