i too am having same issue. i will also wait to see if it resoles for itself

@Bill: OK. Required a bit of extra shell action. After removing package, hunted down leftover bits in the filesystem. rm -rf /usr/local/etc/snort rm -rf /usr/local/lib/snort_dynamicrules rm /var/cache/pkg/*snort* Also grep'ed globally to find references to snort. In config.xml I found that it still had stuff about snort and there were two sqlite databases that contained references. I didn't bother with those, but I did open up config.xml and found all the basic setting properties in there. So removing doesn't really remove. That's not cool. But I left it there not wanting to break anything. I did notice that there was a space in front of my oinkcode though! :) When reinstalling the package, I made sure to remove that and when I did the update it went fine. You can remove Snort and have it clean up after itself.  The default is to "save settings" because most folks want to remove and reinstall or update the binary while keeping their existing configuration settings.  On the GLOBAL SETTINGS tab is a checkbox option to save settings when uninstalling the package.  The box is checked by default, but you can uncheck the box and when you remove Snort it will remove all traces of itself from the config.xml file.  That of course means any and all of your previous Snort configuration settings are gone. The directories you found are being left because of a bug in the uninstall code.  That should be fixed in the latetst package version.  The only exception would be if you manually modified any files in those directory trees. Bill

No, I don't believe the binary supports text wildcards.  You can use very large network blocks by specifying a large subnet mask when you suppress by IP, but that trick does not work for text.  The only supported options for suppression are "by IP" and "by GID:SID". Bill

akong, try adding the following custom rule. Change the sid value if it conflicts with any of your existing sid values. alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"AnyDesk";flow:from_client;appid:anydesk; sid:1000055 ; classtype:misc-activity; rev:1;)

@NogBadTheBad: Got a reply back from the ET guys :- it has slightly changed per https://marc.info/?l=emerging-sigs&m=151182236202050&w=2 … But what you are seeing looks to be a mistake. I've forwarded to the responsible party. The slight change in the URL linked by @NogTheBad will be included in the next Snort GUI update which should be out in a few days.  I had already made that change and tested over this past weekend, so I was a bit perplexed when the URL suddenly changed again and stopped working today …  ???.  Glad the ET guys got it fixed up. Bill

@senseii: Is there a way to use pfSense as an IPS. I set up as ISP Modem>pfSense as Firewall>Switch/LAN. I  use snort as an IDS on Security Onion port mirroring a couple computers. I'm wondering if it would be a good idea or makes sense to use a package to make pfSense an IPS. https://doc.pfsense.org/index.php/Main_Page Start there.

Thanks. Wonder how many IP’s this hosting server has?

@wgstarks: Did a little research regarding the use of snort rules packages in suricata. I found that any snort rules package should work with the exception that incompatible rules will just generate an error. Not sure what the best practice is though? Should i just use the rules for the most up to date version of snort? Or maybe its better to use an older version with better compatibility? I would use the current Snort rules package.  I think that is 2.9.11 (or something close). Bill

At the risk of reviving an old thread… You can compare the md5 checksum in your snort updates page against the md5 checksums on the download page at snort.org.

@dales: Maybe I misunderstood the initial question, but in addition to the info Bill provided, I think you will need to adjust the pass list.  The default list includes the LAN, so even with BOTH selected in the blocking setup, the LAN IP won't get added to snort2c. That is correct in regards to the default pass list.  I forgot to mention that it will default white list LAN hosts.  You can stop that behavior if you want by creating a custom pass list and assigning it to the interface.  The default pass list setup will stop LAN hosts from communicating with bad external hosts if DST is blocked, or it will keep bad hosts from talking to LAN hosts if SRC is blocked.  Using the default of BOTH is the best of both worlds, especially when using the default pass list where all LAN hosts are white listed. So with BOTH selected as "Which IP to block", a bad external host is flagged and blocked whether it is the source or destination of malicious traffic (as detected by Snort).  Now with the block in place, no other LAN host can communicate with that bad external host.  However, any LAN host can still talk out to any other external host. Bill

No worries, at least I can do, from time to time, to post when a new version is available. Please let us know, as you always do, in a release note, what will change(if something is customized further in pfSense), when the new version will be ready. Thank you for maintaining Suricata also.

Hi! Thanks for introducing me to the High Availability of Snort. I will look in to it, although I will not be able to do any coding for that, cause of the lack of expertise. The high availability would only be required in pfsense for systems which have a tightly limited failure gap (let it be downtime, lost packets or dropped connections). The community of the paid version (if such) is probably already looking in to this. Thanks again!

Mine updated fine. Try reinstalling the package.

You are almost certainly hitting a Netmap compatibility problem.  Could be the higher interrupt rates that come with higher traffic rates, but also could be other buffer-related problems.  Netmap on FreeBSD, and then Netmap on FreeBSD within Suricata, are both still maturing technologies.  Translated to plain English that means expect some bugs to still be present. I have tested Suricata inline mode with em0 virtual NICs on VMware Workstation VMs and it works, but I have not tried high traffic rates.  I don't really have a good way of simulating realistic loading in my simple home lab.  I have not tested Inline IPS Mode on ESXi virtual machines. Bill

I had this issue with pfSesne 2.4.2 and had no luck fixing the issue with any of the suggestions. Though I do think I have now found out why the WAN interface went down. As I had set up Snort previously, access to checkip.dyndns.org was noted in the Alerts tab. Enabling a suppression list for the following IP addresses seems to have corrected my connection issues. suppress gen_id 1, sig_id 2014932, track by_src, ip 91.198.22.70 suppress gen_id 1, sig_id 2014932, track by_src, ip 216.146.38.70 suppress gen_id 1, sig_id 2014932, track by_src, ip 216.146.43.70 suppress gen_id 1, sig_id 2014932, track by_src, ip 216.146.43.71

what type of alias are you using? seems like you use URL(IPs). try to add the ip to a host-type-alias or use a network-type-alias.

should be easy: in the snort settings you can create a passlist and assign a pfsense-alias to it. then you have to assign that passlist to the snort-settings of the interface. after that you have to restart snort on that interface.