@josef said in Snort OpenAppID log flooding: @bmeeks Ahhh - thank you. You have helped me greatly! This simple suppression rule has solved my problem threshold gen_id 1, sig_id 0, type limit, track by_src, count 1, seconds 60 Now I will only get 1 log per source IP to the same application within 60 seconds. The gui should perhaps be updated because it says "Valid keywords are 'suppress', 'event_filter' and 'rate_filter'." But actually threashold is also a valid keyword. Thanks!! I will add "threshold" to the tip. I'm working on the Snort 2.9.17 update over the next few days. Note that gen_id 1, sig_id 0 will apply that threshold to all of your general rules. Probably not an issue for you, but just wanted to make sure you realize that. GID 1 is the ID for all the rules in all the user-configurable categories. There are some specialized GID values for the built-in Snort rules like HTTP_INSPECT and others. This is all explained in the official documention when looking up GID (Generator ID). This was why I asked the Snort team to consider creating that special GID for OpenAppID so those rules could be easily distinguished from all the other general text rules. But so far that feature has not been incorporated.

@cool_corona the problem is not suricata, could be a temporary problem on pfsense repo or you have no internet working ( DNS or connectivity problems ) or you have routing issue if you still have the problem read this https://docs.netgate.com/pfsense/en/latest/troubleshooting/upgrades.html

@kiokoman Ugh, thank you! Working now!

@idontknowmeiguess said in Snort not downloading rules (pfSense 2.4.5-RELEASE-p1 & Snort 2.9.16.1): @bmeeks SUCCESS! Disabling DNSBL was the solution. I thought that disabling pfBlockerNG would disable DNSBL at the same time, so I never checked it, well that's egg on my face. Thank you for your help and patience, now it's time to see why DNSBL is blocking Snort updates. DNSBL is somewhat separate from pfBlockerNG. What pfBlockerNG does is modify the configuration files for the unbound DNS daemon and then starts it with the new configuration. It will run with that configuration until it is changed again. I pretty much guarantee you that one of the IP lists you are using is the cause of the problem. As I mentioned, some of those lists are very poorly maintained and consequently wind up with bogus data in them (meaning perfectly safe and legitimate IP address segments get marked as "bad" when they really are not).

@justme2 said in Filter and "not dropped": @bmeeks Actually, was thinking: Services -> <IDS/IPS Engine> -> Alerts The ability to remove drops while doing regular spot checking and see what triggered an alert (not a "drop") - has become more interesting. For: Services -> <IDS/IPS Engine> -> Interfaces -> <Interface> -> Rules, a means to reduce the list via a valid action type would be most appreciated. Thanks! Oh, I see. It's not hard to add the feature to that page either. I'll put that on the TODO list as well.

@bmeeks hmm, this is pushing me more towards thinking I need to do a fresh install. Thanks for trying that!

At the moment there is no easily installable package for exporting the pcap files. Some users have installed the filebeat package manually. There are several links to be found on Google about doing this. Of course you could always write your own shell script to copy the files off to another system and use cron to execute it periodically. There is a cron package you can install on pfSense to enable easy management of scheduled tasks within the GUI. As for filtering the ALERTS tab, I assume you mean that the alert entries prior to them being suppressed are still visible. Adding a filter for that is probably a good idea, so I will put that on my TODO list for a future upgrade of the package. The alert entries will eventually "roll off" once the alert log is rotated. I assume you have enabled automatic log file management on the LOGS MGMT tab. That feature is off by default, but when enabled it will auto-rotate logs and other files like pcaps when they reach a certain size. It will also prune files from disk based on a retention policy you can configure there. So when log management is enabled, those old suppressed alerts will disappear from the ALERTS tab view when the current alert log file is rotated and a new empty file created in its place.

@slu you can also try this patch: https://redmine.pfsense.org/issues/10836

@tman222 said in Snort 2.9.17: Hi @bmeeks - are you planning on including this updated binary in the next version of the Snort package? Thanks in advance. Yes, I generally stay up-to-date with the latest binary. I wait a little bit initially to see if any major bugs get reported upstream before proceeding with the update. I should get the new binary out before the end of this month.

@JeGr said in Can/is Snort using JA3 hashes?: @bmeeks said in Can/is Snort using JA3 hashes?: If JA3 support is critical to your customer, perhaps Suricata might be a better fit for them ??? That was the answer I was looking for. As Surricata didn't have (or still don't?) support for OpenAppID rules we set up Snort at the time in the past as the Netgate blog about support for OpenAppID was posted. The request about JA3 popped out of nowhere a few days ago so if that's something they absolutely want - then yes, we'd have to switch. Would take time though to test it out first, roll out on the cluster and train the team using it that is currently struggling coming to terms with Snort. There are other options depending on their requirements. For instance, if they simply wanted to monitor/alert on JA3 hashes and not block, they could install Suricata on a separate machine (bare metal or VM) and connect it to a SPAN port on a managed switch. If you don't have both packages blocking in Legacy Blocking Mode, and you have the CPU horsepower and RAM, it is certainly possible to run both packages on the same pfSense instance. In that case you would run Suricata with a very stripped-down rule set concentrating solely on the JA3 hashing stuff. So in a setup like this you might configure Snort to use Inline IPS Mode (assuming your NIC hardware supports it) and Suricata to use Legacy Blocking. Or you could flip that scenario. The only caveat here is that you can't run Inline Mode and Legacy Blocking Mode on the same physical interface. So you would need to monitor the traffic on another matching interface. For example, Suricata JA3 on WAN and Snort OpenAppID on LAN (or vice versa). You could always run one in alert-only mode and the other package in blocking mode. Functionally within the GUI, both packages are very, very similar. In fact, the majority of the Suricata PHP code is a copy-and-paste from the Snort GUI code. So the look and feel is the same.

@bmeeks got ya !!

@teamits said in Snort blocking speedtest: @bmeeks said in Snort blocking speedtest: https://docs.netgate.com/pfsense/en/latest/packages/snort/setup.html That page shows putting it on the WAN interface in several examples...I don't suppose you could convince them to use LAN throughout? Yeah, that part and the screenshots that accompany it are quite ancient. At one time I had "edit" access to the doc wiki. I can check if I still do and maybe make some adjustments based on current recommendations.

Crowdstrike Falcon is something that you would load on an endpoint, PC or MAC, not on pfSense. Users don't login or manipulate data on pfSense, so I don't see the relevance.

@bmeeks said in 10G Throughput with Snort: That would be like the legendary Bill Gates quote from 1981 where he reportedly uttered "640K ought to be enough for everybody". this is a good quote, I heard it a long time ago :)- MS + Bill G + DOS :) I was almost 20 at the time...and I was past these, - the historical summary (you know, I enjoyed these at the time): (and now I can barely turn my head when the world is rushing) https://hu.wikipedia.org/wiki/Intel_8088 https://hu.wikipedia.org/wiki/Sinclair_Spectrum https://hu.wikipedia.org/wiki/Commodore_64 (of which there are two more in the attic) https://en.wikipedia.org/wiki/IBM_Personal_Computer_XT https://hu.wikipedia.org/wiki/Pentium_III https://en.wikipedia.org/wiki/MMX_(instruction_set) and https://en.wikipedia.org/wiki/Simons%27_BASIC https://en.wikipedia.org/wiki/Windows_3.1x https://hu.wikipedia.org/wiki/Windows_95 https://hu.wikipedia.org/wiki/Windows_98 How about this? https://www.theregister.com/2020/11/19/nvidia_q3_2021/ https://www.theregister.com/2020/09/29/esxionarm_is_real_and_vmware/ https://www.theregister.com/2020/10/15/nvidia_ai_supercomputer_italy_2022/ this world will leap enormously

Snort is now working after updating my hardware to the latest version of pfsense. Thanks folks!

I don't necessarily disagree, but nonetheless I am a little cautious when it comes to removing existing features still supported by the underlying binary.

Thanks for the link Bill. Read it all and will keep in mind to check every 30 days for any Snort rule updates. I changed the 2.9.15.1 version of the Snort rules to snortrules-snapshot-29170.tar.gz. Suricata updated with no issues.

@bmeeks thanks, I'll have to pay attention to that and see. I am currently putting the finishing touches on building my own box, and am going to restore a backup from my SG-3100 (where I customized things for the rules), so I will look closely at that once I get suricata installed on the new box (it's not connected to the internet yet while I build it, so it's not able to re-install suricata yet). Thanks again.

@marklark said in Suricata rules without Internet access: @Yordano Background: I'm using the GUI for Suricata through the pfSense virtual firewall (FreeBSD instance). Has anyone tried to use the ETOpen custom URL option to "download" a the ruleset via a "file://" URL? It seems like a reasonable work-around, but doesn't work. Where would I look to see errors? Thank you very much! The internal code within the PHP GUI is expecting HTTP or HTTPS urls only in that field and sets the options for curl with that in mind. The assumption was the user would have an internal web host to download from when using the Custom URL option. Any errors would be logged on the UPDATES tab in the log file available for viewing there.

Sounds like you have Suricata on WAN, which is before the NAT happens. If you move it to LAN, then 1) you'll see the internal IPs, and 2) it should scan less traffic as it will only see packets making it through the firewall.