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

@v0id said in Snort 3.2.9.9_1 configuration problem: Thanks, I have ideas clearer now :) Last question: Is it better snort or suricata? Before tryied suricata also, and didn't have much problems in configurations, found it working good and easy to configurate. Read suricata works on multi thread, but doesn't support all snort VRT rules. Ever heard good reviews about snort, but still working on single thread. Also read Cisco is working on Snort++ that will be multi thread. What should I use for keep a very good level of security? There is zero difference between the two in terms of security. And the multithreaded thing is sort of not really all that important unless you are pushing like 10 gigabits/sec of traffic. There have been several tests in the past at more typical user Internet speeds (1 gigabit/sec and under) where Snort and Suricata tested out as more or less equals in packets per second performance under real world conditions. It is true that some Snort rules have keywords that Suricata does not recognize, but there is a Suricata-optimized set of Emerging Threats rules that can sort of make up for that. The downside is that those more current ET rules require you to purchase a very expensive ET-Pro subscription. Otherwise, the free ET-Open rules are at least 30 days old and do not contain all of the threat detections contained in the ET-Pro rules. In the end it simply comes down to what you like. Suricata is multithreaded if that is important to you, and it offers built-in EVE JSON logging and does, in general, offer better logging options than Snort. However, Snort offers the Layer 7 DPI feature called OpenAppID which Suricata lacks.

@Abstract3000 said in Snort Web Application Attack on WordPress from Cloudflare Alert: Thanks for the Heads up, I did look into the vulnerability prior to posting and I saw it effects versions 4.9... which I am at the latest version 5.2 thanks to (Auto Update) set on. Though I'm wondering if this was a deliberate attack attempt, or a false positive, and can Snort not see beyond Cloudflare to the IP address (Spoofed or Not) forwarded over from cloudflare? Thanks for your time & consideration. Snort generally can only see the actual IP addresses in the packet's IP header. There are options for the HTTP_INSPECT preprocessor for handling xff (X-Forwarded-For) headers, but those are primarily for logging options. You can create a customized HTTP engine on the PREPROCESSORS tab of Snort with unique settings for certain parameters including the xff options. You should first create a firewall alias containing the HTTP server you are protecting, then use that alias when defining the custom HTTP_INSPECT engine.

probably this solution https://github.com/sonertari/SSLproxy

@TMC1 said in Block Sender (not Recipient) for just 1 or more Rule(s) in SNORT?: Is there a way to set 1 Alert/Block Rule to block only the Sender - without setting the Global IDS setting. We have a couple of rules that we'd like to block the Sender IP on, but not the Recipient - while for most/all of them, we want to block both; is there a method to do this? Any input is appreciated! No, the blocking is not that granular. The setting for which IP to block (SRC, DST or BOTH) is global. Depending on exactly what you are wanting to do, you could perhaps create one or two custom rules that only trigger for that one Sender IP you wish to block. But that also is dependent on exactly what traffic you want to trigger on.

@gwaitsi Glad you figured it out however, don't knock yourself like that...we all make misconfiguration...that's how we learn. Congrats!

One of the primary concerns is being able to get the data ("out" of the firewall) into a data engine for event correlation. One of many examples would be Splunk. Currently, Barnyard2 provides syslog capability that enables simplified separation of the event streams (ability to prescribe specific facility and destination for output separate from the firewall's syslog and without having to clog the firewall's logs with IDS/IPS logging data). Sounds like the upcoming changes could become a step backwards if it makes it more difficult to get the data out of the firewall, despite improvements in logging format, no? In reviewing the Suricata documentation a bit more, it appears to offer the ability to tailor output (directly?) to syslog - including the ability to modify the output format as to match a required SEIM input format. FWIW - have been involved in the administration of a couple firewalls over many years that are on FreeBSD (currently 12.0-p10), using PF with Snort, Barnyard2, etc. and those utilize the PostgreSQL output plugin - which has been available from the FreeBSD ports for many years. Somewhat surprised that the output plugin wasn't included for Barnyard2 in PFSense, while MySQL was included. Including a small perl script that may be helpful to sort suppress lists, as these can often be a quagmire to wade through when looking to manage via the file itself as they can become quite huge and being able to see suppressed items in a logical order makes it a bit easier. sort-suppress.pl.gz

I'm quite confused by the four different enablesid-sample.conf file screencaps you posted. Are those all in the same file, or did you actually post four different versions? The SID MGMT logic is not meant to work the way you are doing it. It is not designed to enable every single rule in every category. It's never been tested for that -- might work, or might not. Why are you doing this anyway? That most definitely is not the correct way to configure an IDS.

[image: 1567927397808-capture.png]

@heliop100 said in snort not keeping blocked hosts on reboot: @bmeeks said in snort not keeping blocked hosts on reboot: Why do you need to keep the offenders blocked as long as possible? Do yo I want to block torrents downloads, As the seeds keep changing, torrents slow down, but not stops. As the blocked hosts list grows, the download speed slow down. After the pfsense reboot the process need to begin from scratch again. Thanks I fail to see a connection between persistent blocks and the action you describe. Explain to me how you think that persistent blocks make a difference in your scenario. A block is a block, it does not matter if it just happened or if it happened three months ago. If you have blocking enabled and "kill states" enabled, the torrent from that specific seeder will stop. Will the client perhaps try and find another seeder, sure, but then that seeder will be blocked if the rule is there to trigger on the packets. No IDS I am aware of has persisent blocks. In fact, an IPS does not even have the capability of persisting a block for any period of time. An IPS performs real-time drops of packet data, but there is no persisted block. Persistent blocks that hold across a firewall reboot is not a design feature of the Snort package and no such feature is ever planned. There is no need for it.