@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

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