@nogbadthebad Thats was i think, because the .onion is encrypted too. Thank you very much for your help, appreciated.

@bmeeks Thanks for your insights!

If the Alias exists on the child, then Snort should see it and be able to use it. Are the interface names the exact same on the two firewalls? Snort expects sync'd boxes to be absolutely identical in every way including interface assignments and names. All the XMLRPC Sync does is copy over the relevant piece of the config.xml file for Snort to the child firewall or firewalls.

@bmeeks Thank you for your reply Yes, using IPS Aparently, I do have sufficient memory available dmesg | grep memory real memory = 8589934592 (8192 MB) avail memory = 8125104128 (7748 MB) real memory = 8589934592 (8192 MB) avail memory = 8125104128 (7748 MB) Found the option and enabled it. forced an update of the rules No more unbound restart, No more unbound errors. Will keep monitoring this for a few days, but given your unambiguous answer, very confident this is solved. Hope some other users will benefit from this to. Thank you so much for providing this solution. As always, thanks for your time and effort.

@molykule That's the behavior it is supposed to do ... did you checked the log when it stops? Are you using the Snort subscriber rules?

@w4rh0und I think it should also be icmp $External_net any -> ... this may help you: https://suricata.readthedocs.io/en/suricata-6.0.0/rule-management/adding-your-own-rules.html

@dwighthenry61 said in Snort Package v4.1.3 Update -- Release Notes: @bmeeks I upgraded to the latest version of PfSense+ 21.02.2-RELEASE (arm) built on Mon Apr 12 07:50:07 EDT 2021 so now I can install Snort and see it on the Services list. Trouble now however is that after configuring it won't start. Look at the post immediately above yours and you will see why. Nothing has changed on that front. Snort nor Suricata will run on the SG-3100 hardware (or any ARM 32-bit appliance). This issue is unlikely to get fixed, so if you want to run an IDS/IPS package, you will want to get something besides 32-bit ARM hardware to run it on.

@impatient said in LAN traffic graph stops working if Suricata inline mode is enabled: @nollipfsense Not on either of mine. This is a graph image with Suricata on WAN and Snort on LAN both with in-line mode. [image: 1618719332864-screen-shot-2021-04-17-at-11.10.28-pm.png]

Make sure you have disabled all NIC offloading options such as checksums and segmentation on the SYSTEM > ADVANCED > NETWORKING tab.

@pzanga said in seeing fewer alerts than I would expect with Snort on WAN: @bmeeks No worries. I appreciate the fact you took the time to help with this, and we did find an answer and I learned some things. So, if this is working as designed I will just run with it as is. I guess my last question would be "how significant is the lack of SO rules in terms of Snort's functioning as an IDS/IPS (i.e. are there significant threats that are potentially being missed)?". Well, the SO rules do cover certain unique threats. Whether you actually have exposure to them is something you would have to investigate. But since you can't use them anyway, with your ARM hardware, no sense worrying about it unless you change hardware to an Intel/AMD platform.

@bmeeks I still run into the same thing after restarting it. I can't keep restarting it because it seems to happen again immediately.

ok, thank you!

There is an XML SYNC tab in the Suricata GUI. It will sync the configuration to multiple slaves. The one caveat is that the slave devices need to have the exact same physical interfaces and layout. So that means the hardware needs to be pretty much identical: same NIC types, and the same NIC ports defined as WAN, LAN, etc., needs to be the same on all devices.

@murzik said in Snort alerts problem.: @bmeeks Even so, the question remains, why traffic was blocked without alert being generated? I don't know unless it has something to do with the way Snort works internally (I'm talking about the binary and not the PHP GUI package). When you run with Inline IPS Mode, that is totally under the control of the Snort binary. Perhaps the thresholding is only being applied to the logging side and not the alerting side. Granted that would not be logical, so it might also be a bug in the Snort binary itself. That question would have to be asked over on the Snort mailing list thread. But to get a good answer, you would not need to mention pfSense at all. Just say you are running Snort using Inline IPS Mode on FreeBSD and "blah blah blah". If you mention pfSense, they will just refer you back to here, and hence you enter a loop. Legacy Mode Blocking uses a custom output plugin I wrote, but it hooks itself into Snort as a Logging plugin. So ostensibly that should mean my custom plugin only gets alerts that have "fired". It should not be seeing rules that have not met their thresholds, and thus should not block. Just set that rule to ALERT (if using Inline IPS Mode) and you're set. If using Legacy Mode, disable that particular rule if the blocks are a nuisance.

@bmeeks Thanks. Yes, I have zero experience with Snort or Suricata. My assumption was just that - it'd likely be difficult at best to setup for this type of traffic. If it's not well suited, that's all I need to know. Not opposed to diving into if it would be beneficial though.

@giacomo-si said in SURICATA - pfsense 2.5, the system cannot block automatically the hosts: quick way to prevent false alarms You can suppress the rule for an IP address on the alerts tab, via the [+] icon. Suggest not blocking by default until you have the rules/alerts configured as you want them.

@bmeeks Good evening. My knowledge of cyber security is pretty small. I just want to learn from this forum. Yes, it is apparent what is the correct answer. Thanks a lot.

@bmeeks The last time there was only a small dlink green switch in between if I remember correctly. So nothing special and I think nothing wrong either.

We always disable ALL stream-events.rules or it will block lots of traffic on false positives. Also ensure "Disable hardware checksum offload" (System->Advanced->Networking) as that triggers stream errors as I recall.