@luke404 said in feeding pfSense traffic to IDS running on a different host: We would like to keep our pfSense systems small and tidy and that's why I'd like to run the IDS on a different host. Have you considered using something like sguil or security onion to collect alerts from your sensors?

@fireodo I am reading those now again... but I just figured something out... It is only when there is an update downloaded from Snort OpenAppID Detectors My snort was updating every 12 hours, now daily, but the update that causes the issue is the exact same time as theSnort OpenAppID Detectors MD5 Signature date/time

Discussion continues here.

@peter_apiit said in Problem download Rules in Snort: I uninstall pfblokerng solved the problem. That's what I suspected. When you install packages like pfBlockerNG and then subscribe and activate a bunch of feeds for it to block things from, you open yourself up to lots of potential issues. As I mentioned in other threads, those IP lists (feeds to use the pfBlockerNG term) are frequently poorly maintained by their creators. By that I mean they contain IP address subnets that house perfectly legitimate services. Like half the world probably uses Amazon Web Services (AWS) infrastructure, and thus its IP subnets, to host a service. So when some IP List or Feed you activate in pfBlockerNG does a very poor job of policing the list of IP addresses it uses and just plops an entire AWS subnet on the list without carefully and critically checking what they've done, then legitimate stuff gets blocked when it shouldn't be. I am not a fan at all of loading up a bunch of IP address feeds and blocking everything on those lists. Not a very good way to manage your firewall in my personal opinion. Unless you are diligent and examine the lists carefully and review blocks very frequently in order to whitelist stuff, then you will get nuisance blocks often. What happened to you is a perfect example of what I'm talking about.

@darvin said in Problems downloading custom rules in Suricata: @bmeeks Snort has the same problem... Edit file /usr/local/pkg/snort/snort_check_for_rule_updates.php Modify line 476: Remplace /md5 with .md5 Both need an update fix. Update: (Snort AppID Open Text Rules) Edit file /usr/local/pkg/snort/snort_check_for_rule_updates.php Modify line 451: Remplace /md5 with .md5 Okay. Thanks!

@bmeeks "created some kind of fancy shell script" I'm not smart enough for that But thanks for the suggestion. The other potential option is to use a lookup table on the backend log server. I am using Graylog and it has the ability to do that, so it would create a new column and populate the category based on the SID match in the lookup table.

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