@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!

@opoplawski said in Suricata-6.0.6 Update Release Notes - (initially for 2.7.0-DEVEL testing only): Looks like 6.0.9 is out now. Does it address any of the issues that were added with 6.0.6? I'm hoping that it contains a fix for an issue I'm seeing with 6.0.4 and would like to see the pfSense package updated if possible. Thank you for your work on this package. Suricata 6.0.8 is currently available on the 2.7.0 CE DEVEL branch (and the 23.01 Plus development branch). I'm holding off any changes in the RELEASE branch until I see if the next pfSense release happens in January as hoped. If the next pfSense release misses the anticipated launch date by a wide margin, then I will see about backporting a newer Suricata binary into the current 2.6 and 22.05 branches. I have been experimenting with 6.0.9, but there is an open Suricata Redmine Issue with netmap that I am monitoring. It was opened by the OPNsense developer and is currently being investigated. I wanted to see how that was resolved before updating Suricata past 6.0.8 in pfSense.

@bmeeks hey bill. I’m using https as to trigger on the tls protocol. Is there a better way to trigger this? And yes I’m sourcing traffic from a host in the DMZ going outbound to the internet.

current status: the sid range has been approved, see here. PR to add ruleset to suricata-intel-index/index.yaml at master · OISF/suricata-intel-index · GitHub, no response yet... Further attemp to block DoH, using suricata: a discussion on the pi-hole forum, regarding SVCB queries, read here. TLDR; My opinion, SVCB data can be used by “rogue” applications to bypass the system configured DNS server, therefore, I would like to add a suricata rule that blocks SVCB (type 64) DNS queries. question on the suricata forum, here, no replies yet. question (issue on the stamus ( authors of "The Security Analysts Guide to Suricata") forum, here, no replies yet. What I've come up with myself (sid is test - custom): alert dns any any -> $EXTERNAL_NET 53 (msg:"SVCB query (DoH)"; content:"|00 01 00 00 00 00 00|"; content:"|00 00 40 00 01|"; fast_pattern; distance:3; classtype:external-ip-check; sid:1000002; rev:1; metadata:affected_product Any, attack_target Client_Endpoint, updated_at 2022_12_28;) more details on what this rule implies here. any ideas, comments? edit command to trigger the rule: dig @94.140.15.15 _dns.resolver.arpa svcb +short wireshark capture in zip: svcb query.zip /edit

@marc05 Still running 2.5.2 since 2.6 is unstable and VLANs are not working as it should