@serbus said in Snort v3.2.9.10_3 Release Notes (for pfSense-2.4.5 installs only): Hello! Not sure, but I think the minutes might need to be padded... $snort_rules_upd_time = "00:" . str_pad(strval(random_int(0,59)), 2, "00", STR_PAD_LEFT); John Oops! You may be right. It didn't show up in my quick testing because the random function returned two-digit minutes for me.

No, that feature is not available. You would have to roll-your-own by creating your own custom Suricata output plugin module and compiling it into the Suricata binary.

@bmeeks I'm not even going to waste my time on realtek, tomorrow I'm ordering the intel PRO/1000 PT 4-port. Think that's a mighty fine investment. Also, I just upgraded back to 2.4.5 and the suricata package is back to running. I'm glad I at least reported my problem, and mentioned where I found answers. Often times when looking around the web for issues similar to mine I see the thread die with "nevermind I found a fix". Also, thanks for the quick response, @bmeeks

@bmeeks said in Suricata Rule Update - 404 Error: @ccb056 said in Suricata Rule Update - 404 Error: Unfortunately its still not working I think I will try backing up the pfsense config, and re-staging the firewalls Thanks for your help Bill The last thing you could try, short of a full reinstall is this: https://docs.netgate.com/pfsense/en/latest/install/upgrade-troubleshooting.html#forced-pkg-reinstall. This worked for some users in another thread having Suricata issues. However, their problem was a failure to start due to missing libraries. However, as that link states, a full reinstall from media is usually the best solution. What has happened is the update of the packages prior to update of the base OS left things in a confused state for the pkg utility. Bill - Perfect ! I ran through the forced pkg reinstall and my issue is now resolved. Thanks again!

@bmeeks Bill, you're AWESOME!

pkg install -f luajit-openresty-2.1.20190912_2 forced re-install of the package solved the issue. apparently the package was registered as installed while in reality it wasn't [1/1] Reinstalling luajit-openresty-2.1.20190912_2... [1/1] Extracting luajit-openresty-2.1.20190912_2: 100% [2.4.5-RELEASE][root@firewall-2.dotOne.nl]/root: suricata -V This is Suricata version 5.0.2 RELEASE

This is a very interesting case study, and analysis...thank you all for sharing!

@eSht: User @stephenw10 (a Netgate employee) has posted a potential method for enabling the 2.4.4 pfSense package repo here: https://forum.netgate.com/topic/151709/2-4-5-update-caution. You can give this a try. Just this time, snapshot your virtualized firewalls before proceeding so if things go way South you can quickly recover.

@JonSmizza said in snort started... or has it?: @bmeeks said in snort started... or has it?: Just please don't use RAM disks with the IDS/IPS packages. Remove those RAM disks and put those directories back on a physical disk and I bet all of your Snort issues go way. Thank you @bmeeks. I was actually wondering if my RAM disks were the issue. I originally started with larger allocations, then reduced them. Which would explain why I was unable to reinstall snort. I've disabled the RAM disks, rebooted, reinstalled snort and now everything is fine. Cheers! Glad you got everything back up ... . Please help me spread the word, "No RAM disks when using Snort or Suricata!".

It is common for the Snort Subscriber Rules to generate errors in Suricata. Search this forum here for other posts about this. Suricata is not Snort. It does not process nor understand all of the Snort rule directives and keywords. For those it does not understand or support, it spits out an error like you see and discards that rule (so that rule is not loaded). Not all the Snort rules will fail, but several hundred will fail (I forget the actual number). Exactly how many fail for you depends on which particular categories and rules you enable (or that get enabled by choosing a Snort IPS Policy). Emerging Threats has an optimized Suricata ruleset. The Suricata package loads those optimized ET rules when you enable ET rules. Unfortunately, the free ET rules are more limited. The paid ET rules (ET-Pro) which are up-to-date are way more expensive than the Snort rules. Last I checked the ET-Pro rules were $832 per year per device. Compare that to the Snort Subscriber Rules which cost $30 per year for an individual (non-business subscription). There is no corresponding individual subscription for ET-Pro. Your flowbit errors are likely due to the failure of other dependent rules to load. You can't do anything about this when you run Snort rules with Suricata. This is one of the limitations of Suricata in my view for small non-business users. The only affordable rules packages are not complete in their coverage. Even when you use Snort Rules, several of them won't load in Suricata. You may be better served to switch to Snort and use the paid Snort Subscriber Rules; unless you have the coin to pay Proofpoint $832 a year for an Emerging Threats Pro subscription.

@bmeeks Thanks for the relpy, i tried the reinstall and the install finished normaly :/. I will try do check out the sync and reinstall again maybe it helps. bolvar

Hi, I post this information on this thread because we talk about pass list improvement. When I check "VPN Addresses" to create a custom HOME_NET list, IPv4 network is OK but IPv6 network of my OpenVPN is not added.

@bmeeks said in Sort 4 Not Downloading VRT Rules: They really serve no purpose with most of today's hardware (solidstate disk drives and other forms of modern non-volatile memory I must say this point is well-taken.

I set something up with ELK quite a long time ago as an experiment. It worked, but to get it working I did a wholesale "copy and paste" operation on the log filters from someone's Google page. That was several years ago. I suggest using a Google search to see if you can locate some recent examples of using ELK to parse Snort data from syslog logs. These filters are highly dependent on the precise content of the log data and the layout of the various "fields".

@NogBadTheBad Thank you for the re-assurance. I can take off my tin foil hat as you say and not waste a month compulsively re-installing pfSense which probably would be from a source with a mismatching checksum anyway.