This post https://forum.pfsense.org/index.php?topic=87247.msg479068#msg479068 lists most of the domain names involved with MS updates. This post explains you cant whitelist a domain in snort https://forum.pfsense.org/index.php?topic=88914.msg491573#msg491573 Possible work arounds. If you have WSUS the windows update server that downloads their updates and then push them to the workstations saving MS bandwidth, perhaps you could exclude the snort check during a certain period of time? If you dont have WSUS, and the workstations download the updates direct, perhaps having those updates carried out at a certain time of day and then having snort disable itself or the rules in question might also be an option. You might be able to find a cron job to disable snort or some of its rules for a period of time. Alternatively maybe you could create a route where all MS updates pass through and snort doesnt check that route? I havent tried any of the above, they are just some ideas which might help.

I'm not logging to ramdisk, its logging to disk, I had in the past (several reboots ago) logged to ramdisk but abandoned that idea due to the fact the ramdisk at the time couldnt do a ramdisk for /tmp and normal disk for /var. I also figured as theres 9 options each with a max of 10Mb, I figured a 100Mb directory limit should be enough, I could disable that 100MB directory limit option so theres a 100GB plus for the logs to use, just to be on the safe side and see what it does? Edit. And I havent pulled this yet https://forum.pfsense.org/index.php?topic=101441.0 as I'm still trying to get a secure email server working.

I should know soon if the pcap issue is related to my other post with some sort of file truncation or not.

@sticcino: The command line for finding Snort processes is like this: ps -ax | grep snort Do not include the "u" in the command arguments.  This will show the running Snort processes.  You are running the command with the "-aux" argument and that causes no Snort processes to display.  Run it with just the "-ax" argument. As @doktornotor posted, Snort and Suricata are professional-grade IDS packages.  They are not "install and forget" packages.  They require constant vigilance and careful tuning in busy networks to identify false positives and weed them out with selective disabling of rules and the use of pass lists.  Remember also, when creating a PASS LIST, you must go to the INTERFACES tab in Snort and assign the new Pass List to the interface.  If you do not, then Snort does not use the Pass List.  Finally, don't forget to restart Snort on an interface when you change a Pass List.  The lists are only read and processed during start up of Snort. Why don't you run Snort in just IDS mode for a few weeks (that is with blocking not enabled) to get a good feel for the types of alerts that fire in your network?  That will help you identify potential false positives so you can selectively disable those rules. Bill

I have imported this scheme into mysql https://github.com/firnsy/barnyard2/tree/master/schemas and after i connected barnyard2 to the db then the size grow from 0-7,8 but after that the db remained at 7.8 mb. I haven't installed Snorby yet because i wanted to make sure the db was 100% working.

Yes. So install it.

In the same place where you installed it. Simply click the reinstall button.

Not yet known.  That will be up to the pfSense core developers.  I'm just a volunteer package maintainer for Snort and Suricata… :).  It has been posted here and elsewhere this is a planned feature, but no specific version/timetable has been given. Bill

I just went through several firewalls and I don't see any errors downloading the VRT rules, but I notice the date is August of 2015.  On my dev firewall I forced an update and now even those rules are gone :( We have not moved our 30+ firewalls to 2.2 due to the issues reported by early versions of 2.2 and VPN - I guess we need to look at this pronto, I did not realize we were running on an usnsupported version :(

Awesome ! thanks everyone for the help with that an explaining what the enable, disable order does. glad to hear I got the syntax right with GID:SID off to do some more tinkering with my SNORT set up :-)

You need to examine the ALERTS tab to see which specific rules are triggering alerts resulting in blocks.  You then evaluate the rule in your environment to determine if it is a false positive.  If you determine it is, you can either suppress the alert using the icons on the ALERTS tab; or you can disable the rule completely (again using the icons on the ALERTS tab is the best way). Bill

Thanks…my issue is either pfblockerng or one of the suricata blocking rules apparently.

Usually caused when pfSense does a "restart all packages" command in response to the events that trigger that (change in WAN IP is one, but there are others).  Snort takes a long time to start. Bill

Hi. I did some investigations on the root cause of Snort failing e.g. for PPPoE connections with a provider-side forced DHCP renew. The problem is that /etc/rc.start_packages (invoked indirectly by /etc/rc.newwanip) does refresh the Snort configuration file (/usr/pbi/snort-<platform>/etc/snort/snort_<…>/snort.conf), however, Snort does not read it immediately as it does in case of modifications via the GUI). In order to reload the configuration, we need to send SIGHUP to the running Snort instance (the Snort executable that comes with pfSense is capable of reloading without restarting, see also /usr/local/pkg/snort/snort.inc (function snort_reload_config)). A workaround without changing the PHP files would be to introduce an additional shell script placed in /usr/local/etc/rc.d. snort_pids="$(pgrep snort | xargs)" if [ ! -z $snort_pids ]; then     /usr/bin/logger -p daemon.info -i -t SnortReload "Snort RELOAD for all interfaces... (${snort_pids})"     kill -HUP $snort_pids fi barnyard2_pids="$(pgrep barnyard2 | xargs)" if [ ! -z $barnyard2_pids ]; then     /usr/bin/logger -p daemon.info -i -t SnortReload "Barnyard2 RELOAD for all interfaces... (${barnyard2_pids})"     kill -HUP $barnyard2_pids fi This script reloads all running Snort an Barnyard instances. Note: this is not the optimal solution if running Snort for multiple interfaces, but only one configuration changed. Tested on pfSense 2.2.4-RELEASE (amd64), Snort 3.2.8.</platform>

thanks will try to fix this way

@dgall: My problem is I did go thru the blocks and alerts at the beginning and  and made it so everything I wanted to pass thru did . A year later with out touching any of the settings its starting to block all kinds of websites while I dont mind going in and changing a few things here and there in PFsense but  I dont have time to stop from what I am doing in the shop 5 or 6 times a day because another website is blocked. We have people online looking at all kinds of websites for research and purchasing different things This does happen occasionally, as new potential threats are added to the rulesets through updates. As bmeeks mentioned, you could either run a generally more permissive ruleset, or disable blocking and have a look at what's going on every so often. Good security does need proper maintenance, as new threats are always emerging.

Same here. After Update to 2.2.4-RELEASE (amd64/i386)  Snort (3.2.8)  goes Up to 100% CPU and also the Memory is going high. I changed also for a test the settings (Search Method aso. ..)  But nothing happen - after a short time the CPU and Mem going high. I thought that is a Hardware-Problem, so i switched to the second-system (carp). But there goes the CPU/Mem also high. At the 2.2.2 the problem was not visble.

Look in /var/log/snort and then the subdirectory for the interface.  You will should see a file in there showing you which rules got "auto-disabled" due to missing preprocessor dependencies. You should not be hitting this error unless you have done something funny with your rules (like enabling some default-disabled rules pertaining to sensitive data). Bill

OK, thanks for your help.  I'll give it a try.