@bmeeks

Thank you very much.

Your assistance is fantastic. I took your advice and I am able to download the information. Thank you very much.

@hebein said in Suricata blocks IP in friendly List:

Hi, thanks for your reply. I has to manually restart suricata, the reload after saving the settings did not do the job. Now it works fine :)

When you make changes to a Pass List, you must completely restart the Suricata service as the Pass List contents are only read during startup. When you add a rule SID or an IP to a Suppress List, then the live reload should be sufficient (no need to physically restart the Suricata instance).

Hi sorry for the late response. I figured, searching was best-- if I put a bounty, would you consider writing and maintaining as part of your package icap support with configuration options in the GUI? The goal would be able to add/write custom bro scripts that can be executed from the pipeline of traffic tunneled to Bro from the Squid package(s). https://www.zeek.org/brocon2016/slides/fernandez_icap.pdf

@bmeeks Thanks for summarizing it. Should the link I gave above changes in the future, the answer will be preserved here. Well done! :)

@occamsrazor said in Sudden Flurry of 1:2260002 Broke Mail Server:

I also had a bunch of these the last few days. One of the blocks cut my Whatsapp access. I guess relatively safe to suppress these??

Yes, I would suppress or perhaps temporarily disable the problematic rule. If it suddenly started and otherwise worked fine in the past, I would suspect a recent rules update from the rule vendor (either Snort VRT or Emerging Threats guys). You could check their web sites for any info on the particular SID or to see if others are reporting problems with a recent update.

Would not be the first time a rule was updated by the vendor and wound up false triggering.

@delumerlino said in Snort/Suricata: a rule for blocking RDP attacks:

am searching for a rule for limit RDP burst. I have a lot of connection retries from unknown IPs registered in Windows events.
Due to connection from mobile, I cannot limit the firewall rule only from some IPs.
Is there a way to limit the retries with Snort or Suricata? for example, 3 retries in 5 minutes should be enough...

Have a look here:-

http://manual-snort-org.s3-website-us-east-1.amazonaws.com/node27.html

@lluisclava said in Suricata Disabled by user rule, in blocked hosts again:

Dear bmeeks,

Thanks for your answer.

Yes, I cleared all the blocked hosts and checked the rule is disabled on WAN and LAN side. And keeps blocking again and again....
Any idea?

What kind of rules do you think it's important to enable on WAN and what's in LAN??

Thanks again!

If you are a home user, enable zero rules on the WAN. Do not even put Suricata (or Snort) on the WAN if you are a home user. Nothing but useless noise alerts/blocks on your WAN so long as you leave pfSense configured with the default "deny all inbound" rule intact. And by the way, it is extremely wasteful of firewall resources to run the same rules on the WAN and LAN. What would be the point of that?

If you have a disable rule still blocking, then the most likely cause of that is you have multiple instances of Suricata running on the same interface. When that happens, one of the instances will not respond to any GUI changes.

Execute this command from a CLI session on the firewall:

ps -ax | grep suricata

You should not see any duplicate output lines. You should see only one unique line per configured instance (for you, likely one for LAN and one for WAN). If you see duplicates, then go to the GUI INTERFACES tab for Suricata and stop all the configured interfaces. Return to the CLI session and repeat the command above and see if any Suricata processes remain. If you see any, kill them with this command:

kill -9 <pid>

where <pid> is the process ID of each still running instance.

Now go back to the INTERFACES tab and manually start your configured instances.

@Bob-Dig said in Suricata v4.1.5 Release Notes (now available for pfSense-2.4.4 RELEASE):

@bmeeks Suricata runs here on the LAN Interface so I thought it would be blocked first. Thanks for your clarification.

Look at the SRC. I suspect that is one of your LAN hosts, so that traffic hits Suricata on the LAN interface before the firewall sees the traffic. In this case your LAN host was attempting to communicate with the external host at 192.2.128.131. The external host is going to be blocked by the firewall, but Suricata is seeing the communication attempt before the firewall does because this is traffic inbound to the LAN interface from your LAN host destined for that remote IP on the Internet. However, the traffic is going to be blocked by the firewall. You can tell by noting the red X beside the destination IP.

The traffic flow when using an IDS/IPS is always like this for inbound traffic:

Physical NIC --> IDS/IPS --> firewall (rules)

This is the same for any interface (LAN, WAN, DMZ, etc.).

For outbound traffic (i.e., traffic leaving your firewall the flow chain looks like this:

firewall (rules) --> IDS/IPS --> Physical NIC

Thank you for your help.

I won't open a new topic, but I do have a similar problem with a I5 5250U processor. I have enabled Snort for WAN (igb0) with the Inline IPS Mode and selected the Connectivity mode. In addition I added Malware mobile Malware and Trojan in the conf file. I checked the Malware and Trojan, everything has been selected to Block status.
Only 2 further packet are installed, pfblocker and acme. When checking my line speed with active snort, I received something like 400.000 MBits, without snort full I was back to 1000000MBits. During speedtest and active and inactive snort the cpu load was about 80%
Looks like that the Inline Mode is eating some speed.

@Bob-Dig said in Problem with NORD-VPN-Client and Suricata:

Ok, that looks to complicate for me.

It's not that hard, but in your case an easier solution would be to disable those ET User-Agent rules. Or at least disable those particular ones triggering on the Microsoft traffic. Lots of those rule categories are going to generate false positives. This is particularly true in a home network. And even with most small business networks those kinds of rules serve to generate more trouble than protection.

Look at the alerts you posted in the screen capture. They are just from normal Microsoft telemetry data the OS sends home to the mothership. All in all it's harmless. You can attempt to block it, but it's going to cause issues and likely break stuff in strange ways within Windows.

@v0id said in snort crash:

@bmeeks Think the core problem is too many hosts in pfBlocker and TLD option activated. 4GB of ram should be not enough for 6 milion hosts

That's one reason I'm not a fan of loading up tons of IP blocklists. It chews up a ton of CPU processing time and uses valuable RAM. There are more efficient ways to have a secure system in my opinion.

If you really want to run all this stuff on your firewall, then you need more horsepower (larger CPU and lots more RAM). Then you will need to customize the php.ini file settings for maximum memory allocated to PHP processes. Just be aware that any change you make to that file will be automatically overwritten each time you update pfSense. Again, lots of trouble for not much gain in my view.

If you want to block ads on your network, look at something like pi hole running on a virtual machine. Just let your firewall do its normal thing by blocking all unsolicited inbound traffic. But don't bog it down maintaining huge IP block lists. Just my humble $0.02 worth.

Don't use upgrade in suricata, the step should be

stop suricata deinstall suricata reinstall suricata suricata will autostart by itself

@Bob-Dig said in [SOLVED] Which IP to Block? Both! but does it work?:

@bmeeks Thanks. Next Time I will look there first.
🖖

I did not mean to imply not to ask questions here. Your query is welcomed. I simply posted the link so you could follow the status if you were interested. The formal bug reporting site is the pfSense Redmine site here: https://redmine.pfsense.org. You can register an account and report bugs and track their resolution there. You can also post here on the forum and ask about an issue.

Forgot to mention in my other post that you can also configure Barnyard2 in Snort and then use it to send Snort data out to a syslog receiver. So in that manner Barnyard2 could send your alert data from Snort to Aanval.

First of all, you will need to enable the emerging-p2p rules category on the CATEGORIES tab. I assume you have done that. Then you enable blocking for the interface on the INTERFACE SETTINGS tab. After making any change on the INTERFACE SETTINGS or CATEGORIES tabs, you would need to restart Suricata in order for it to see the changes.

You might fare better blocking some of the newer P2P stuff using the Layer 7 DPI capabilities provided by Snort's OpenAppID feature. However, blocking P2P is getting harder at the packet level because many clients now attempt to hide or disguise their traffic so it appears as normal HTTPS traffic.

A tool such as pfBockerNG-devel can be useful. It uses lists of host IP addresses for various categories of network traffic. You subscribe to various lists and then have them populate firewall aliases. You then use those aliases in blocking rules. There is a separate sub-forum here in the Packages section for pfBlockerNG.