@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

This seems to be back:

Downloading Snort GPLv2 Community Rules md5 file community-rules.tar.gz.md5... Snort GPLv2 Community Rules md5 download failed. Server returned error code 404. Server error message was: 404 Not Found

It looks like the Snort v2.9 community rules have been removed again?

d6c6e1dc-b86a-42d9-a0f6-fa59488f4fec-image.png

Having the same issue, as I understood from the bug report it seems to be more of an PHP issue now. Too bad Netgate did not warn us before upgrading.

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

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.

Yeah...in general I try to observe a vendor forum for a while before jumping in, especially on a ".0" release. As helpful as beta testers are, "the world" will always find more bugs. And yes I know this is 2.5.0 but there were six versions of 2.4.x before that (0-5). All I can say is over the last 10 years or so pfSense releases have been pretty good. I don't really recall any long term issues as they are pretty good about "p1" patches.

My "bystander" guess is that since the SG-3100 issues seem to appear with packages then it's not a core pfSense flaw and thus wasn't found in 2.5.0 testing...however since it's apparently a PHP issue then it is going to take a PHP and then pfSense update to fix it.

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