same error for me also Starting rules update…  Time: 2016-07-12 11:06:35 Downloading Snort VRT rules md5 file snortrules-snapshot-2983.tar.gz.md5... Snort VRT rules md5 download failed. Server returned error code 403. Server error message was: 403 Forbidden Snort VRT rules will not be updated. Downloading Snort OpenAppID detectors md5 file snort-openappid.tar.gz.md5... Snort OpenAppID detectors md5 download failed. Server returned error code 403. Server error message was: 403 Forbidden Snort OpenAppID detectors will not be updated. Downloading Snort GPLv2 Community Rules md5 file community-rules.tar.gz.md5... Snort GPLv2 Community Rules md5 download failed. Server returned error code 403. Server error message was: 403 Forbidden Snort GPLv2 Community Rules will not be updated. 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. Extracting and installing Emerging Threats Open rules... Installation of Emerging Threats Open rules completed. Copying new config and map files... Updating rules configuration for: WAN ... Updating rules configuration for: LAN ... Restarting Snort to activate the new set of rules... Snort has restarted with your new set of rules. The Rules update has finished.  Time: 2016-07-12 11:07:08 snort security 3.2.9.1_14

@battles: Thanks.  I was trying to individually suppress a rule for my isp address in Services / Snort / Alerts, and upon clicking the + button, I got this error: The following input errors were detected: Suppress List 'wansuppress_57828044c1f52' is defined for this interface, but it could not be found! Wonder what this is about? Maybe a previously created/assigned suppress list that was later deleted.  Go to the INTERFACE SETTINGS tab for the Snort interface and set the SUPPRESS LIST to "default" and save the change.  Now go back to the ALERTS tab and try the suppress action again.  When you click the suppress icon on the ALERTS tab, it will auto-create a Suppress List file for the interface and assign it if one does not already exist.  If one is defined in the config.xml, then it will use that one instead.  In your case, one was defined in the config.xml for the interface but the actual content was not in the config.xml file.  This usually means the old list was deleted. Bill

Looks like snort 3.2.9.1_14 just became available which contains snort-2.9.8.3.  I was able to download my Snort VRT rules and start Snort.

Thanks a lot for your advice. So I send an e-mail to Voleatech, Germany, they said that the update is not in the official update catalogue yet, and promised to look the issue. Very soon I got an another email that the issue will be resolved soon. And now the latest package is available, and I just upgraded. Everything is working well now. Many thanks!

Thank you.  If possible, that would be great to add in the next update.

@Tantamount: @Wisiwyg: Thank you Bill. I just took a quick look at freshports - no update as of this post. Looks like koobs@freebsd.org is the maintainer. Hopefully s/he will have a chance to look it over soon. I emailed koobs back on the 5th  (nice fellow) and he said that after some more QA it'll be committed shortly. He mentioned this patch if one didn't want to wait – looks like there's been some activity since his email.  Apparently it's not as simple as compiling from source into a package: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210490 Yeah, there are some other fixes required to integrate Hyperscan into Suricata on FreeBSD.  The FreeBSD maintainer will get it worked out.  I will keep an eye on the progress and start working on the pfSense Suricata package as soon as FreeBSD ports is updated.  I also have to be sure the special patch we apply on pfSense for the legacy mode blocking works on the new version, so that adds a little extra time to the cycle. Bill

@joelesler: Hi.  Joel Esler here, I work for Talos (was VRT) and and the Program Manager for the ruleset.  (Note: I don't hang out in these forums all the time, so if I miss your reply, I'm sorry. That being said.  It's impossible for us to track the 1,000s of platforms that Snort is built into.  We tried, and we just couldn't keep it up.  We established the EOL policy, probably close to 13 years ago now…  and we've stuck by it. Its great to have your support in this forum. Bill Meeks the Dev/Maintainer of the Snort package has been doing a phenomenal job on what little free time he has available :) We're all just thrilled that out of the 1000's of platforms that use Snort, that you registed for an account here… It is this ( 1 of a 1000 ), that we here; really care about hehe…. Keep of the great work, and we're looking forward to 3.0 ...

What file specifically are you looking at on the LOGS tab?  Only the file named alert will be used by the ALERTS tab.  If you are looking at older history alert logs (those will have a timestamp in their name), then that data will not be displayed on the ALERTS tab.  It may simply be your box rotated the alert log when it reached the rotate size limit and no new alerts have come in since then. The above is just a guess, though.  Reply back with the exact log file name you are looking at where you see alerts. Bill

Troubleshooting this one may be tricky given its sort of random nature. Suricata could be running out of memory, but it should log some kind of error before just stopping. It might be you have traffic triggering an obscure rule with a bug in it that causes a crash, but I would say that is unlikely because with all the people using Suricata and various rules you would expect others to have the same problem with the rule. It could be a hardware problem (most likely with a flaky memory chip) that manifests itself only during high resource utilization. When you say it runs for a "short period", just how long is that?  Seconds, minutes or maybe an hour or two? Which logs are you looking at for errors?  Suricata has its own log you can view on the LOGS tab.  Some info (although limited) will be in the pfSense system log. Bill

@jimp: Looks like the port update was only put into devel (pfSense 2.4) and RELENG_2_3 (pfSense 2.3.2) and not RELENG_2_3_1. Should be fixed up at some point today unless there's a reason it was kept out of there that I am not seeing. @jimp is correct.  Renato is working on getting the new package into RELENG_2_3_1 as well, but I think he had some other more pressing fires to fight earlier today.  He and I have swapped e-mails and he said he will get the update posted. Bill

Snort uses DAQ and libpcap as its data acquistion layer on the physical interfacd.  It puts the physical interface into promiscuous mode so that it see all traffic hitting the interface.  That's why Snort is seeing your PIA traffic without being explicitly configured for it. In terms of the available interfaces in the drop-down box on the Snort Interface configuration tab, it simply queries pfSense for all the configured interfaces and displays them.  Probably not the best implementation, but for now Snort just thinks any interface returned by the system is an actual physical one.  So it doesn't really understand that your PIA tunnel really runs on the WAN but should be treated as distinct. Bill

Thanks Bill!

My problems began about June 17th after my pfSense upgrade, which I believe is before any Snort EOL took place, correct? Thank you for keeping Snort up to date and providing support, Bill.  I'm not about to blame you for anything.  I just wish I could find a smoking gun in the logs to point me to a solution.  I'll try the next version of Snort when it comes out but I don't think it's a rules issue at this point.  I would be happy to be proven wrong, though. -Justin

Sorry guys … my fault for being late submitting the update pull request.  The Snort 2.9.8.3 update was a little late getting into the FreeBSD ports tree, and then I missed my own deadline posting the update for review by the pfSense team.  I did not get the update posted until very late this past Friday evening.  The updated package is posted to the DEVEL tree of pfSense and should be in the RELEASE tree in a day or two.  The Independence Day holiday weekend here in the U.S. is another contributor to the delay. Once the updated 3.2.9.1_14 package appears, then Snort will work again.  That update includes the new 2.9.8.3 Snort binary and will use the 2.9.8.3 rules.  Suricata will work with any VRT rules version, but the Snort binary is locked to only matching rules versions.  This is a decision made by the Snort developers. Bill

This will be fixed soon.  An updated package pull request has been posted and is waiting to be merged into the RELEASE pfSense package repository.  The updated package is already in the DEVEL tree. The July 4 holiday weekend here in the United States has slowed things down a little bit.  It was ultimately my mistake for letting the EOL date of the Snort VRT rules sneak up on me.  I was not timely in getting the 2.9.8.3 update for the Snort binary out there.  The rules for the 2.9.8.0 version that is currently in pfSense RELEASE went EOL on July 1. Bill

@AsgardianFW: Bill, Thanks for the reply.  I have dug deeper into the issue and I'd like your opinion.  I can narrow the problem down to 3 rules in emerging-dos: 1:2014384 - ET DOS Microsoft Remote Desktop (RDP) Syn then Reset 30 Second DoS Attempt 1:2014385 - ET DOS Microsoft Remote Desktop (RDP) Syn/Ack Outbound Flowbit Set 1:2014386 - ET DOS Microsoft Remote Desktop (RDP) Session Established Flowbit Set When I disable #2, then everything appears to be back to normal (i.e., I can make normal RDP connections with no delay). When I enable #2 but disable #1 and #3 then I can get RDP connections to work, but the connection process is very slow. If I enable #2 with either #1 or #3, then RDP connections fail again. So, I will certainly disable #2 for now.  But should I drop this issue until 3.1 finally makes it into pfSense (3.1 does seem to be in stable release mode, but not certain how long it takes to make it all the way into pfSense) or should I attempt to debug further what makes that rule so bad?  I guess it is Netmap related as I don't get this problem in "Legacy" mode. Thanks. Rather than spending a ton of time debugging, I would be tempted to wait for the next Suricata update to go RELEASE and get into the FreeBSD ports tree.  Once it is posted in ports, I can submit an update request to the pfSense team.  There are several Netmap fixes in the next Suricata release, but I don't know if this particular issue you have identified is one of them or not.  I have not closely followed all the back and forth with the issues and fixes on the Suricata redmine site. Bill

Yes, this is the plan when the next 3.x update hits FreeBSD ports. Bill

try snort_p2p work well for me

Configured as well as SNORT