@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

@wexi Not sure it is the same problem. The pass list IS being obeyed. It is just that it seems to only handle IP addresses and not ranges (or at least in some circumstances). I fail to see how your post is related. Are you having the range problem as well?

So, after several updating the Nov, 242022 snapshot instance wasn't changing the result with Suricata. I completely deleted the instance and installed Dec, 232022 snapshot and restored from backup...glad to report all is good.

All three LEDs blinking blue means it never finished booting. So really you need to connect to the console to see where it stopped and why. Steve

@steveits said in Snort is blocking on some alerts not others: @gfunk said in Snort is blocking on some alerts not others: DMZ VLAN for my cable box and FIOS router, which I guess I could add that interface to Snort IIRC Snort and Suricata will see the VLAN packets anyway so no need to add it as a separate interface. This is correct. Be sure "promiscuous mode" is enabled and just put the instance on the VLAN parent physical interface. This is especially critical when using the Inline IPS Mode mode of operation.

@michmoor Depends on the setup but often not.

Well, for anyone that might run across the same issue. I know my problem is a larger ruleset for the interfaces on Suricata, so when I try to rebuild multiple interfaces it pushed PHP over the arbitrary 512G memory limit. I found a solution from others with log sizes causing their problem and a solution listed above to increase memory. I wasn't thinking, so their solution didn't work for me because I was changing the wrong .inc file. My error was for /usr/local/pkg/suricata/suricata.inc and not /etc/inc/config.inc, which is why it wasn't acting like it increased the memory limit. Once I changed the 512M in suricata.inc to 1024M, I was able to rebuild all of the interfaces at the same time without the error triggering. This is probably more of a "hack" solution, but I don't want to modify my SID management files just to fit the memory when I have more than enough memory to spare and it isn't taking that much extra for Suricata to go from 512M to 1G. One thing to note for anyone trying this is to make sure to write a script or a cron job to sed the suricata.inc periodically in case there was a package update that overwrote the system. Here is my cron job: sed -i'.inc' -e 's/ini_set("memory_limit", "512M");/ini_set("memory_limit", "1024M");/g' /usr/local/pkg/suricata/suricata.inc This seems to have solved my issue, but I'll keep an eye out and modify this response in case it occurs again under the same circumstances.

Thank you both for taking the time to review the problem and for not making me feel stupid for asking my question. You both have made some good suggestions here. I'm going to take them all into consideration and figure out what my next steps. Thanks again!

@bmeeks I will delete and create a new entry there, thanks for pointing me out to the right direction.

@michmoor Snort has a checkbox "Enable Packet Captures" to automatically capture packets, that create alerts. I thought I would have a look at the DNS query packet (i.postimg.cc) and enabled the checkbox & restarted Snort for the interface. When entered the "bad" URL into browser, to my surprise PC's IP was not blocked. I reverted the checkbox and restarted Snort and PC will still not get blocked. So seems like Snort behavior is back to normal for now. Strange.

@audax10 said in Suricata blocking google.com: As far as I understand, Legacy Mode blocks the host, while Inline blocks (drop/reject) the triggered rules. This is a big difference. I noticed that Google Maps connects to the same host as "ET INFO Android Device Connectivity Check" rule. So when the host is blocked rather than the rule specification, we will probably block more than we need. Is it correct @bmeeks ? Yes, Inline IPS Mode is much more selective as it drops individual packets instead of entirely blocking a host by its IP address. However, when using Inline IPS Mode, you must change the action of rules that you wish to block traffic from ALERT to DROP. Otherwise, they will just generate alerts and not drop or block the traffic. Rule actions are default set to ALERT. In Legacy Mode, any alert is interpreted as a block. But that is NOT the case when using Inline IPS Mode. In that mode rule actions are interpreted literally! So if the action is ALERT, that's all that happens. To block traffic in Inline IPS Mode, the rule action must be changed to DROP. Changing to Inline IPS Mode without also changing rule actions via SID MGMT or some other means will result in nothing being blocked. The easiest way to manage this is to use the SID MGMT tab features. You can also alter the action of individual rules on the RULES tab and on the ALERTS tab once Inline IPS Mode is enabled. If you are new to this, you should read through this long Sticky Post first: https://forum.netgate.com/topic/143812/snort-package-4-0-inline-ips-mode-introduction-and-configuration-instructions. While a little of the information in that thread is probably dated by now, the majority of it is still applicable.

@stormgate said in Snort and VoIP: @steveits Thank you so if my Vlan assignments are ix1.50, ix1.30 etc... then my common interface would be assigned ix1 for the Snort interface. [image: 1670534421742-snort.png] I will answer for Steve -- "yes, this will be sufficient". Just remember that the same rules are being applied for all of the VLANs on that physical interface. But usually that is fine.

The Snort package offers the OpenAppID feature which can be useful blocking social media sites. You will want to be sure your NIC hardware (the specific driver, actually) fully supports the FreeBSD netmap kernel device. Netmap is used for Inline IPS Operation in Snort, and if you use OpenAppID you definitely want the ability to selectively drop individual traffic flows rather than simply block an entire IP address with Legacy Mode Blocking. The official Netgate Snort package documentation can be found here: https://docs.netgate.com/pfsense/en/latest/packages/snort/setup.html. Setting up OpenAppID is at the bottom of the linked page.

@fartypants said in Snort keep blocking IPs on suppress list!: Just wanted to say thanks to BMeeks for suggestion re- run-away snorts above. Been smacking my head against a similar-but-different problem for days, and that's what it was. Whodathunkit? Si. Multiple, but duplicate, Snort (and Suricata) processes can happen from either of these things: Something causes the WAN IP to change rapidly or the WAN interface cycles down and back up repeatedly. This causes a built in pfSense script to fire that restarts all packages. Because Snort and Suricata both can take a while to start, rapid back-to-back execution of "restart all packages" can result in multiple instances of Snort or Suricata running on the same interface. Configuring the Service Watchdog package to monitor Snort or Suricata. Service Watchdog does not understand how the Snort and Suricata packages work, thus it cannot properly monitor them. It also does not understand that both packages will stop and restart themselves when doing rule updates. Service Watchdog simply sees the Snort or Suricata daemon stop, so it immediately restarts it. Service Watchdog does not know that Snort (or Suricata) are in the process of restarting themselves from a rules update, so when it issues its own "start" command you can wind up with two or more processes running on the same physical interface. Service Watchdog should never be configured to monitor either of the two IDS/IPS packages!

If I understand your post correctly, you have devices on your internal networks (LAN) that communicate with a database server located elsewhere on the Internet (accessible via your WAN). If this true, then you need to simply add the IP address of the remote DB server to a Pass List by creating a list on the PASS LIST tab, accepting the default checked options, adding the IP address of the remote DB to the list using the controls at the bottom of the EDIT LIST screen, then save the new list. Now go to the INTERFACE SETTINGS tab in Snort for your WAN (since your are running Snort on that interface) and select the newly created Pass List in the drop-down selector there. Save that change and restart Snort on the interface. You do NOT need to be changing the HOME_NET nor EXTERNAL_NET variable settings. Changing those is almost never required. And changing them from the defaults without a full understanding of what they are for and how they work will result in a setup that will NOT trigger rules properly. The fact you altered them in an attempt to solve the problem you describe indicates you may not understand what those parameters are actually for. They define the networks to be protected (HOME_NET) and the networks that are assumed hostile (EXTERNAL_NET). The default setup puts every address/network not defined in HOME_NET in EXTERNAL_NET. Literally, in the PHP code, $EXTERNAL_NET is defined as !$HOME_NET (the leading '!' character indicates a logical NOT operation).