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.

You have an eight-core CPU, so as @ntct says, increase the Stream Memcap value on the FLOW/STREAM tab to at least 256 MB and try to start again.  Keep increasing the value in 4 MB or 8 MB chunks until Suricata starts.  You can then try backing it down if you wish until it breaks, then bump it up slightly.  Some changes in the Suricata binary in a recent revision caused an increase in needed stream memory when using high core-count CPUs.  The old default of 32 MB is too low.

Bill

They did reply to my bug report that it was resolved as well. Was just able to test it today to confirm that it is indeed resolved. Thanks for the follow-up bmeeks

NogBadTheBad and ecfx thank you for your instant reply.

The site of Emerging Threats is very useful.

No, Suricata on pfSense can't do that (block the X-Forwarded-For address).

Bill

See this post, https://www.linkedin.com/pulse/qisniff-sniffs-quantum-injection-mayur-agnihotri, for details about the attack and the mention of the tool (qisniff).  Here is the link to the tool itself:  https://github.com/zond/qisniff

Bill

@Preacher22:

Is there a central location some place where these sorts of concepts are documented?

Unfortunately not – at least I've never found one.  There is at least one thread here on the pfSense forum that contains suggestions from other experienced users on which rules can safely be either disabled or their alerts suppressed.  You will have to search for "suppress list", for example, in the IDS/IPS sub-forum.

Bill

I posted to redmine. I will see what kind of answers I get.

Right, that's what I thought. If you use the pass list to create a 'sub-alias', that gets used in the Suricata Interface Inspect and Protect drop downs for Legacy and Inline.

I apologize, I didn't even notice the flaw. I have this anti-torrenting setup on my VPN interface, I want to allow torrenting on my WAN because I know the traffic inside my network and who's doing what, my dad and I are the main torrenters. However, I give VPNs out to friends who torrent and I'd rather have them off, just because I don't know what they're downloading.

@micropone:

Crash report begins.  Anonymous machine information:

amd64
11.1-RELEASE-p6
FreeBSD 11.1-RELEASE-p6 #421 r313908+a5b33c9d1c4(RELENG_2_4): Tue Dec 12 09:20:59 CST 2017    root@buildbot2.netgate.com:/builder/ce/tmp/obj/builder/ce/tmp/FreeBSD-src/sys/pfSense

Crash report details:

PHP Errors:
[13-Dec-2017 16:03:42 America/Los_Angeles] PHP Warning:  filesize(): stat failed for /usr/local/etc/suricata/suricata_18353_em0/rules/suricata.rules in /usr/local/pkg/suricata/suricata_generate_yaml.php on line 855
[13-Dec-2017 16:03:42 America/Los_Angeles] PHP Warning:  filesize(): stat failed for /usr/local/etc/suricata/suricata_18353_em0/rules/flowbit-required.rules in /usr/local/pkg/suricata/suricata_generate_yaml.php on line 857
[13-Dec-2017 16:03:42 America/Los_Angeles] PHP Warning:  filesize(): stat failed for /usr/local/etc/suricata/suricata_18353_em0/rules/custom.rules in /usr/local/pkg/suricata/suricata_generate_yaml.php on line 859
[13-Dec-2017 16:03:42 America/Los_Angeles] PHP Warning:  filesize(): stat failed for /usr/local/etc/suricata/suricata_57646_em1/rules/suricata.rules in /usr/local/pkg/suricata/suricata_generate_yaml.php on line 855
[13-Dec-2017 16:03:42 America/Los_Angeles] PHP Warning:  filesize(): stat failed for /usr/local/etc/suricata/suricata_57646_em1/rules/flowbit-required.rules in /usr/local/pkg/suricata/suricata_generate_yaml.php on line 857
[13-Dec-2017 16:03:42 America/Los_Angeles] PHP Warning:  filesize(): stat failed for /usr/local/etc/suricata/suricata_57646_em1/rules/custom.rules in /usr/local/pkg/suricata/suricata_generate_yaml.php on line 859

Filename: /var/crash/minfree
2048

this happens after I reinstall the whole package

What type of hardware is this?  Those errors indicate problems within the file system.  Another possibility, if you have recently upgraded your hardware and imported an old config, is the interface names have changed (the em1 part of the error path).  So for example if your NIC driver is now say igb1 instead of em1, then you will get this error.  To fix it you will need to either delete the interface and recreate it from scratch, or manually go into your config.xml file and change all the instances of the strings "em0" and "em1" to match whatever the new name is for your physical interfaces.

I have this error:

Dec 14 10:25:30 php-fpm 57060 /snort/snort_interfaces.php: The command '/usr/local/bin/snort -R 20090 -D -q –suppress-config-log -l /var/log/snort/snort_igb020090 --pid-path /var/run --nolock-pidfile -G 20090 -c /usr/local/etc/snort/snort_20090_igb0/snort.conf -i igb0' returned exit code '1', the output was ''
Dec 14 10:25:30 snort 91420 FATAL ERROR: /usr/local/etc/snort/snort_20090_igb0/rules/snort.rules(3803) Rule options must be enclosed in '(' and ')'.
Dec 14 10:25:29 snort 91420 AppInfo: AppId 4115 is UNKNOWN
Dec 14 10:25:29 snort 91420 AppInfo: AppId 503 is UNKNOWN
Dec 14 10:25:29 snort 91420 AppInfo: AppId 503 is UNKNOWN
Dec 14 10:25:29 snort 91420 AppInfo: AppId 503 is UNKNOWN
Dec 14 10:25:29 snort 91420 AppInfo: AppId 503 is UNKNOWN
Dec 14 10:25:29 snort 91420 AppInfo: AppId 4126 is UNKNOWN
Dec 14 10:25:29 snort 91420 Invalid direct client application AppId, 4126, for 0x809fc83e0 0x8045ae180
Dec 14 10:25:29 snort 91420 AppInfo: AppId 4387 is UNKNOWN
Dec 14 10:25:29 snort 91420 AppInfo: AppId 4385 is UNKNOWN
Dec 14 10:25:29 snort 91420 AppInfo: AppId 4043 is UNKNOWN
Dec 14 10:25:29 snort 91420 AppInfo: AppId 4109 is UNKNOWN
Dec 14 10:25:29 snort 91420 AppInfo: AppId 4387 is UNKNOWN
Dec 14 10:25:29 snort 91420 AppInfo: AppId 4387 is UNKNOWN
Dec 14 10:25:29 snort 91420 AppInfo: AppId 4385 is UNKNOWN
Dec 14 10:25:29 snort 91420 AppInfo: AppId 473 is UNKNOWN

@michal:

Hello everybody

Is it possible to configure pfsense+suricate to make a e-mail alert when some signature rule is met? Means no watchdog, but e-mail alert when selected signature is detected.

Best regards
Michal

No, this capability does not exist.  Sounds like you need a third-party alert correlator on separate server if you want that level of functionality.

Bill

@cyberzeus:

Hi Bill,

Yeah - really strange.  I considered the clog aspect as well but if that were part of this, then you would expect there to be skew consistent across the whole file which I do not see.

I do think the 5m delay for the block resulting from the 12:00 related syslog message is due to the rules updating - I figure maybe the BLOCK_THIS IPC message somehow got head-of-line blocked due to Snort grinding through rule updates.  I believe Snort is single-threaded and if so, then this might make even more sense.  Would be curious to hear your comments on that possibility…

In any event, still doesn't explain the different timestamps on the syslog messages... scratches head

Snort is indeed single-threaded … at least the 2.x and older versions.  The new 3.0-ALPHA is multi-threaded, but it's not released as stable yet and is not in the FreeBSD ports collection.

Bill

Please see my post: https://forum.pfsense.org/index.php?topic=141319.0 for help fixing it in the short term. I am hoping someone knows who the maintainer is to file a proper bug report to get it fixed.

This is of course making the assumption you are using the openappid rules…