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…

Hi, may i know how do I access the file? through shell script? Kindly provide some guides. Thanks

@NogBadTheBad: Thats HTTP inspection doing that. View the following page on your pfSense router :- Services -> Snort -> Alerts and select the WAN interface and write down the SID number, you get more details about the alert here. Then goto  :- Services -> Snort -> Edit Interface -> WAN -> WAN Rules and select pulldown preprocessor.rules. You can serach for the SID there. BTW I see these all the time :- 09:03:42 2 TCP Potentially Bad Traffic 172.16.2.41 52863 17.120.225.104 993 137:1 (spp_ssl) Invalid Client HELLO after Server HELLO Detected IMO you'd be better running SNORT on the LAN interface rather than the WAN interface as you'll see the client IP address rather than the WAN IP address. It also looks like you've got a double NAT going on as your WAN IP address is in RFC1918 address space. Thank you Nogbadthebad for responding with good insight. I plan to move soon; so, in the mean time, I am using my neighbor's WIFI, with permission of course, via a WIFI repeater that has an Ethernet port. My setup is PFSense for WAN and Mikrotik for LAN…so, even when I move; that's my official home network. So, Snort will always on WAN...in fact, that's exactly I got pfSense machine because although the Mikrotik is robust, I wanted to use pfSense to complement it to bring about, hopefully, the ultimate UTM. That's why I might have double NAT although only the Mikrotik has NAT enabled. I checked the SID...it's the same 137:1.

I have followed all the recommendations in the tuning guide and I still get a ton of bad pkt errors. Using an intel i350. Also tried Intel i219. Is anyone else using the i350 successfully?

I have the same problem, I was about to make a post for this then I came across this. If there's a solution for this that'd be great, works fine on every interface except my OpenVPN too.

I have a SG2440, pfSense 2.4.2…4g of RAM...now I am up to 92% of RAM usage. CPU seems fine...thanks for sharing what you are running seems like you run a lot and a rock solid configuration. I googled your HP Pavilion a6242n...you are running that with 3G of RAM? I have to assume you added more... I am running pfBlocker and Snort...but it looks like Snort is taking up most of the resources. I have a lot of rule running but struggled to find rules that are more for management and rules for threats...I understand there is some overlap but are there rules I just don't need for my use? Looking at your setup...I like the sound of Squid antivirus but struggled with just setting up the antivirus part, is this possible?

@FireBean: Then why was it even suggested? There is no way to get Snort to tag traffic in a sense for the FIREWALL to drop the traffic in the propper queue? No, not without rewriting the binary.  It's an IDS/IPS, not a traffic shaper.  The Level 7 inspecting part you saw in the blog post is about inspecting traffic against specific applications for alerting on it or blocking it, not for shaping it.  So the OpenAppID feature of Snort would allow it to identify and drop Facebook traffic or other social media apps, for example. Bill

@bmeeks: On the CATEGORIES tab for a Snort interface you will see a column over on the far right labelled Snort SO Rules if you have Snort VRT rules enabled on the GLOBAL SETTINGS tab.  All the categories under that vertical column are the shared-object rules.  If you don't have the VRT rules enabled, then the column is hidden.  So if you are only using Emerging Threats rule, the column is hidden. Give Suricata a try.  It should work better, but there may still be some issues with ARM hardware.  I've seen some posts with issues in other packages related to ARM hardware.  There are some compiler settings that will likely need tweaking by the pfSense team in order to get all the packages to compile properly for ARM hardware.  There are apparently some byte-alignment issues to contend with in ARM land that Intel land is happy with. ARM is not a clone of Intel like the AMD processors.  With Intel or AMD, it's pretty much identical in terms of instruction set and memory access requirements.  ARM is a completely different CPU platform and has its own instruction set and a different set of memory access requirements. Bill Thanks Bill. Suricata does the trick.

Are you guys by chance modifying and then saving the example files provided on the SID MGMT tab?  They are really intended as examples.  If you edit them to customize the content I suggest saving your changed file with a new name and selecting that name in the corresponding drop-down selectors at the bottom of the page. The pkg tool used in FreeBSD (and by extension, pfSense) attempts to keep track of all the files it copied/created when installing a package.  It will then attempt to delete all those files when the package is uninstalled or upgraded.  However, if a file has been modified by something outside of the pkg installer routines (as in you, the user, made a change and saved a modified version of the file), then pkg will not remove it.  This might cause issues on the next upgrade of the package. I have run the package install/uninstall/upgrade process many times in my test virtual machine environment and I've never encountered this error.  I have had pkg leave some files hanging around after an uninstall if I had modified those files myself, though. Edit:  adding some extra information to my original reply This error is being thrown by the pkg manager utility that installs all the packages for pfSense.  This is all way before any of the actual Suricata package itself is ready to run, so the error is coming from the pkg-static utility.  It's like it is not installing everything. Bill

@gsiemon: Bill,  Thankyou for the quick response. While appending suricata-4.0 seems to work, on closer inspection of the ET Mailing list entry I think it would be better to base the Rules URL on the full Suricata version number.  They give the following examples: Suricata 4.0: https://rules.emergingthreatspro.com/$oinkcode/suricata-4.0.0/ Suricata 3.2.3: https://rules.emergingthreatspro.com/$oinkcode/suricata-3.2.3/ Suricata 2.0.11: https://rules.emergingthreatspro.com/$oinkcode/suricata-2.0.11/ Reference: https://lists.emergingthreats.net/pipermail/emerging-sigs/2017-October/028424.html Perhaps a longer term fix is to append the current package version number to the URL? Greg Thank you for the update and the link to the mailing list.  I will look into this.  For now, the issue should be fixed with the new package update released today. Bill

The code originally threw up an error when an FQDN alias was used.  Maybe that logic got lost when the GUI code was converted over to the Bootstrap interface in pfSense.  I will need to dig into it and see why the error is not flagged when saving the Pass List edit with an FQDN alias. One possibilty is that if the aliases are nested (meaning actual IP addresses mixed in with an FQDN alias) the code is getting tripped up.  Just out of curiosity, have you tried using a single FQDN alias (in other words, no mixed IP addresses in with it) to see if that generates an error when saving the edited Pass List? Bill

There is a sticky : Using Snort VRT Rules With Suricata and Keeping Them Updated https://forum.pfsense.org/index.php?topic=124054.0