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

@denis_ju said in Alerts from "Signal Android App"!: I spoke for Vodafone Albania not in France. I do not understand this statement after reading your first. I would check out all destination IPs in the above image before disabling ... do a whois and reverse IP ... you can use Google to look up each ET Trojan above ... welcome to IDS/IPS.

@gspatton I think the point with enabling Snort on LAN is that you have control of what kind of traffic is going out from the network. Let say you have critical tools on LAN and multiple developers with access to those servers. They can misconfigure or install some malicious software. IPS/IDS will detect it once such application tries to connect to the Internet and based on rules configured on IPS/IDS will block such traffic. At least that how I see it. Most important you will know something is not right and start further investigation. Can you use other tools for that - sure, but IPS might actually save your bacon :)

@nogbadthebad Thank you for all the help! I finally got what I needed, although I'm not sure what to do with it. I was concerned about Snort alerts for DNS lookup for .to top level domains, because we seem to get rather a lot of them. .to domains have plenty of legitimate uses, but one of our important clients is convinced that most .to domains are in use for malware purposes, which may or may not be accurate. Having now had the opportunity to examine numerous .to DNS requests, I'm concerned because blocking them seems to also be blocking some important access. (The first one I looked at was yelp.to.)

@rogerboomhouser said in Snort no long running: GUI, status>system thanks, for the info, and now my is working to.

The rule has been fixed.. if you force update the rules now, Snort is happy again.