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.

For what it's worth, rebooting my pfSense box seems to have stopped this for now.

Added to that : for all this to work, you have to install certs on every client device, certs being used so that client device can use and trust pfSense as a proxy, so pfSense can do the real MITM job.

All this, on paper, is pure dynamite. In reality, its far better then that.

Problem is solved. The service provider gave an incorrect IP. I did not notice

@teamits I did that...twice. It blew right through with no issues.

It happens after some time. And I cant see anything in the logs.

Only way to circumvent it, is to set the Remove Blocked Hosts Interval to anything else than Never.