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.

Created a PR to get this removed from the 2.1.x packages feed, since the package is useless now.

https://github.com/pfsense/pfsense-packages/pull/1065

That worked.  I was able to delete the Suricata package.  I'm left with what's causing my package downloads to fail, but will create a different topic for that after a 7 GB CentOS download completes in a few hours, if that is successful.

Thank you!

What strikes me - people who wrote this really don't seem to have ever run a recursive resolver? Because, exactly as described, you end up with all root DNS servers blocked, plus whole slew of others => totally broken DNS.  Anyone can kill DNS for everyone on the network merely by resolving a bunch of blacklisted domains. If you wanted to prevent damage, you'd block the actual traffic to hosts in that domain. Not block completely innocent DNS servers.

Perhaps you should just stop updating the rules until upstream guys come back to senses. Already reported by someone else as well with different .so - see https://forum.pfsense.org/index.php?topic=98920.0

Bill, you can also use Suricata 2.1beta4. Been using it on linux boxes for months, w/0 trouble. More stable and feature rich than 2.0.8, including CIDR IP Rep, etc..

Considering inline operation in IPS mode. Its now a real must. Malware as small as 20kb get pass the snort hybrid mode of pfsense…

F.

@bmeeks:

@Music:

Will you also be upgrading it to snort 3.0?

No, not in the near-term.  No upgrade on pfSense until Snort 3.0 goes full production and is not ALPHA or BETA software.  Also will not happen until the FreeBSD ports maintainer for Snort updates the package here.  Finally, there is a distinct possibility that Snort 3.0 will lose the ability to block offenders on pfSense.  I have not investigated this in detail, but I do know that the Snort team is deprecating the output plugins API that the custom blocking module for pfSense depends on.  If the API hooks the current blocking module depends on are not in Snort 3.0, then blocking won't work.

Bill

oh when that happens it will become kinda useless.

Multithreathed option in snort would be nice that it might run smoother/faster etc when you have more then 1 core in the box you use.

Yeah, we are telling you to pick one and use it… Other than that, you still provided ZERO information to debug any issues.

@MilesDeep:

Snort.  So to disable the rule means to force allow the traffic?

That's one way of looking at it.  The actual effect is that rule is removed from the list that traffic is evaluated against.  Since the rule is not evaluated against traffic, it can't "fire" and trigger an alert.  This is a per-interface setting, so if you run Snort (or Suricata) on multiple interfaces you can have a rule enabled on one and disabled on another.

Bill

Did you by chance disable all the logging options on the INTERFACE SETTINGS tab for that Suricata interface?  Can you post a screenshot of the Logging Settings from that screen?

Bill

I update it on 2.1.5 and works great

Hi,

NOT a single problem on pfsense x64 v2.15 & Suricata and now updated to pfsense x64 v2.2.4 and Suricata 2.1.6.

Never mind.  It looks like the versioning is correct.

Thanks for explaining the downloads.

"Services: Suricata 2.0.8 RELEASE pkg v2.1.6 - Intrusion Detection System"