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

@bmeeks That's exactly what I did, except it overwrote the first file instead of creating a 5th. I'm not sure why. I can still change the names back and can get it to reproduce the same problem. Thanks for the help. At least I'm now able to add the extra conf files that I needed.

I've added it to my TODO feature list for Suricata.

Yeah, that's not supposed to happen. I will put it on my TODO list of bugs to fix. In the meantime, here is how to disable the feature if you want to stop using it. The steps below turn off the functionality of SID MGMT. Click the checkbox so the page info is displayed on the SID MGMT tab. Down at the bottom of the page, make sure all of the drop-down selectors for the Enable SID List, Disable SID List and Modify SID List are set to "none". Now click Save. If you want to immediately rebuild the rules for each configured interface, click the Rebuild checkbox beside each interface before clicking Save. This will remove the list assignment and thus no SID MGMT settings will be used.

This issue is now corrected in the latest version of the Snort package (v3.2.9.9_1 for pfSense-2.4.4_3 and v4.0_6 for pfSense-2.5-DEVEL).

@haroldye said in Snort can not update. it gose unknow all the time: Thank you very much You are welcome. Sorry for the confusion. I just posted a notice in the IDS/IPS forum so if others run into this they will know what's going on.