@gsiemon: Bill,  Thankyou for the quick response. While appending suricata-4.0 seems to work, on closer inspection of the ET Mailing list entry I think it would be better to base the Rules URL on the full Suricata version number.  They give the following examples: Suricata 4.0: https://rules.emergingthreatspro.com/$oinkcode/suricata-4.0.0/ Suricata 3.2.3: https://rules.emergingthreatspro.com/$oinkcode/suricata-3.2.3/ Suricata 2.0.11: https://rules.emergingthreatspro.com/$oinkcode/suricata-2.0.11/ Reference: https://lists.emergingthreats.net/pipermail/emerging-sigs/2017-October/028424.html Perhaps a longer term fix is to append the current package version number to the URL? Greg Thank you for the update and the link to the mailing list.  I will look into this.  For now, the issue should be fixed with the new package update released today. Bill

The code originally threw up an error when an FQDN alias was used.  Maybe that logic got lost when the GUI code was converted over to the Bootstrap interface in pfSense.  I will need to dig into it and see why the error is not flagged when saving the Pass List edit with an FQDN alias. One possibilty is that if the aliases are nested (meaning actual IP addresses mixed in with an FQDN alias) the code is getting tripped up.  Just out of curiosity, have you tried using a single FQDN alias (in other words, no mixed IP addresses in with it) to see if that generates an error when saving the edited Pass List? Bill

There is a sticky : Using Snort VRT Rules With Suricata and Keeping Them Updated https://forum.pfsense.org/index.php?topic=124054.0

@jonspeegle: I can't find anything that explains why this is not working. I'm going to setup a test lab to see if I can duplicate. Could there possible be a bug with the snort implementation in pfsense? I'm not going to say that is impossible, but it would have to be assumed as unlikely since other rules are firing for you.  If I understood you correctly, once you fixed the HOME_NET issue, you have only that single rule that is not firing the same on both sensors. If it is a bug, it could be in either place (the DMZ sensor may be incorrectly triggering, or the pfSense sensor my be incorrectly missing it). Does the other sensor use libcap?  I know that's what Snort is using on pfSense. Bill

thanks. it helped with torrents :)

It should not have blocked your WAN IP, but if it does that anyway, you can manually remove the block two ways.  On the BLOCKS tab you can clear individual or all blocks.  Under DIAGNOSTICS > TABLES from the pfSense menu select the snort2c table in the table name drop-down and clear its contents.  That will remove all blocks inserted by Suricata. I also recommend folks go to the GLOBAL SETTINGS tab and set the "clear blocks" interval to something 1 hour or less.  That way a cron job will run at that interval and remove blocks that have seen no action during the configured interval. In your case I'm guessing the power loss and subsequent reboot of your firewall cleared out the snort2c table since that table lives in RAM only.  Blocks from Suricata or Snort are automatically cleared when the firewall reboots. Bill

Thank you for the quick update

Thank you for the quick update

still open … and keeps crashing. Either remove bro-ids from options of barnyard2 or try to fix it. Last would more the sufficient way. Thanks

@bmeeks: My own Snort VRT rules last updated on November 21.  So probably nothing to worry about.  Either nothing has been needed on the rule creation front for a while, or the Snort VRT folks took a long holiday for Thanksgiving in the U.S. …  :) You can follow the Snort VRT rules releases here:  https://www.snort.org/downloads/#rule-downloads Bill Thank you. As it turns out, yes, I was simply being impatient: Starting rules update…  Time: 2017-11-29 04:30:00 Downloading Emerging Threats Open rules md5 file emerging.rules.tar.gz.md5... Checking Emerging Threats Open rules md5 file... There is a new set of Emerging Threats Open rules posted. Downloading file 'emerging.rules.tar.gz'... Done downloading rules file. Downloading Snort VRT rules md5 file snortrules-snapshot-2990.tar.gz.md5... Checking Snort VRT rules md5 file... There is a new set of Snort VRT rules posted. Downloading file 'snortrules-snapshot-2990.tar.gz'... Done downloading rules file. Extracting and installing Emerging Threats Open rules... Installation of Emerging Threats Open rules completed. Extracting and installing Snort VRT rules... Installation of Snort VRT rules completed. Copying new config and map files... Updating rules configuration for: WAN ... Updating rules configuration for: LAN ... Restarting Suricata to activate the new set of rules... Suricata has restarted with your new set of rules. The Rules update has finished.  Time: 2017-11-29 04:32:20 Thank you again for all your very informative help.

Thankyou ! Will be using it to teach myself some things

@kejianshi: I looked into that, of course, but it was very automatic.  Anything I'd have wanted to add was already there. Yeah, it was… Since I turned NAT off and made into IP Public, I should put that IP in HOME_NET list.

@EWBtCiaST: Bill, Thanks for the reply. I don't think that's the problem as I'm in the U.S. and I was just able to download the rules using a test virtual machine with the same public IP as the one that doesn't work. Are you running any other blocking packages?  pfBlockerNG, for example.  Some of the IP lists there have blocked access to rules downloads for folks using them.  Do you have a proxy of some sort in use? The download process is just a simple call to the curl() functions in PHP with the rules URL.  The exact same code is used for all the rules downloads, so if one works that means the underlying code is good.  Otherwise, no downloads would work. Bill

Related: https://forum.pfsense.org/index.php?topic=139273.15

@drewsaur: Removing the quotation marks was the trick. Thanks. Not sure why the examples in the files include them!!! To separate them from the other text, but perhaps it would be useful to add a disclaimer in the examples that the quotation marks should not be included. You put only exactly what you are searching for after the pcre: keyword in the SID management conf files. Bill

Bill, Snort has been working fine for the last few weeks. I haven't received any notifications from the watchdog service for snort. I'll post back here if anything comes up again, but it seems solid now. Thanks for the fix! Raffi

Incredible explanation - beyond awesome - Thank you…