Uptime 21 Days 16 Hours 14 Minutes 42 Seconds no more problems after I disabled suricata... :(

Thank you for the advice @bmeeks. I'll keep that in mind.

Even though the title for this Sticky Post says it is for Snort, the concepts and most of the screenshots are applicable to Suricata. There are some examples in there of using SID MGMT. Also, if you are using the Snort Subscriber Rules in your configuration, you could opt to enable an IPS Policy (IPS-Connectivity is a good starter policy).

@albgen said in could not update suricata: @bmeeks what about how to check which process is using ram the most? Should i check with standard freebsd command line or any specific way from pfsense itself? While installing a package in the GUI you would need to use a CLI method via a direct console session or an SSH session. If you change "screens" in the GUI and access a different menu option while a package install is happening it can blow up the PHP session that was installing the package.

Thanks guys its now working.

@bmeeks said in pfsense sync pf table snort2c to another firewall by scan loop, but what if use barnyard2 ?: standard Snort binary package from FreeBSD ports clear Snort it not ready solution. need load rules by subcribes, by other apps ... barnyard2 for read raw log from snort, for barnyard2 ideally need to have sql.... for visualize alerts need other app... ip list etc .... On other office many years used pfsense as main gw with snort as you say. And will to say that 8G RAM not so much if enabled barnyard2 with snort and multiple interfaces on snort.

Also forgot to mention that if you have a Snort Subscriber Rules subscription (either paid or free), then you do not need to use the Snort GPLv2 rules. The rules in there are already within the Snort Subscriber rule set. So you would just be duplicating rules if you use the Snort GPLv2 Community Rules and the Snort Subscriber rules. The GPLv2 rules are just public free versions of some of the Snort Subscriber rules.

I have created a pull request: https://github.com/pfsense/FreeBSD-ports/pull/702 But since I have no idea how to test it, I guess some other person has to do that part.

Sorry, but I can't help you with Squid or SquidGuard. Never used either package on pfSense. Your Snort rules look OK, but you might be a little tight on memory.

Installing games and game launchers, especially if from sources other than an official retail outlet, would give me pause. But then I am almost officially an "old fart" now and games don't interest me anymore ... . Back to your problem --- It's really hard to say if all of those are false positives. I will say that in general the ET Policy rule category is not terribly useful on a home network because it will generate alerts for lots of things that are perfectly normal for home networks. That ET Policy set is primarily aimed at the corporate IT world where things like Windows updates and other similar things are tightly controlled and usually distributed from in-house servers on the company network (think Microsoft's old SMS and later WSUS architecture). So these rules are designed to trigger on traffic that would indicate a user was downloading or installing some EXE file or DLL or ZIP file from the web instead of official company infrastructure. Well, in a home network that's exactly what Windows needs to do in order to get security updates -- download EXE and DLL files from the web. So the ET Policy rules are likely to false positive there. So the ET Policy rules in your alerts are most likely false positives. I would suggest you disable the rule set entirely in your configuration or else turn off several of those alerting rules. The other alerts from ET Shellcode might not be benign. The fact you mentioned you installed new games and game installers means some kind of adware or malware may have slipped in as well (unless you bought the games from a big-name retailer, but even that's not guaranteed safe). Definitely would be worried if I obtained the games from a torrent or other P2P method or purchased them at a substantial discount off retail from some web site. One thing to start with is to research all of the IP addresses in the alerts that are not your own. You can use web tools such as the ARIN IP Lookup to find the IP space owner and what country the IP is registered in. You can also search Google using the IP addresses as the search term to see if any negative reviews turn up. If the IP addresses in those Shellcode alerts are registered to the maker of your games, then I wouldn't panic as much as I would if I found the IP addresses instead were going to some "more often than not" hostile country known for malware.

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