@bmeeks: @Nixus: Hi everyone, Is it possible to get a list of the force-disabled rules from [Force-disable this rule and remove it from current rules set.] in the Alerts tab? No, that is currently not an available feature.  It would make a good future enhancement, though.  I will put it on my TODO list for a future update. Bill Thanks! That would be a really nice feature! :)

Thanks, I did try that, and just tried it again as well.  I removed snort, manually removed the cached package, reinstalled.  I then updated the rules, created a LAN interface, and started it.  No other settings were changed and it crashed

Removed and reinstalled snort, issue is resolved. Perhaps a simple restart would have done the trick as well.

@The: Hi @bmeeks Thank you so much again for the explanation, I actually added Suricata to watchdog service after noticing this issue, but as you mentioned it doesn't really know how Suricata service work so I was noticing the CPU usage is much higher everytime I manually restart Suricata from the interface tab, I removed it from watchdog now. Thanks. I will fix the GUI issue with showing the status correctly on the INTERFACES tab.  Probably will be sometime next week, though, before I can get it put together and posted. Bill

@Beerman: Will it also fix the Problem with the "Host Attribute Table"? See: https://forum.pfsense.org/index.php?topic=135137.0 Thx! :) I will have to re-test and see. Bill

@Wroxc: OK seems like /tmp was full. Resolved my issue by increasing the /tmp size to 300MB since i have plenty of ram Yep, Snort and RAM disks are not friends!  I don't recommend that configuration, but if you do, make sure you have at least 300 MB configured for /tmp and the same or more for /var if that is also a RAM disk.  Snort downloads and extracts rule updates into /tmp, and all the logs are on /var. Bill

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