When you select and enable an IPS Policy, that overrides manual selection of Snort VRT rules – hence the red mouse cursor.  Those checkboxes are disabled by design when using an IPS Policy.  This is because the chosen policy is determining which of those grayed-out categories and rules to use. Bill

This is a bug within the Suricata binary itself.  It has been reported to Suricata upstream and will be fixed in the next release, I think.  It is only a warning and will not affect operation. Some changes were made to a section of code in the 3.2.x series, but one line got missed when those changes were made.  You can find the bug report and details on the Suricata Redmine site. Bill

Thank you that's very good to know for the future!

Currently the GUI package builds a snort.conf file configured for alerting and capturing packets related to those alerts.  It was never intended to use Snort like Wireshark on pfSense, so that capability is not part of the standard snort.conf generation. Bill

thanks Bill you tha MAN

@Ghostdragon97: That did the Trick. Thanks for the help! All rules updated just fine. Glad you got it going.  The /tmp directory is where the tar.gz files from the rules update are downloaded and then unzipped.  From there they get copied to /usr/local/etc/snort/rules.  You need enough free space on /tmp to hold the tar.gz rules package and then the unzipped contents as well.  I included /var because that's where log and alerts files go.  That volume can fill up on you as well. Bill

https://forum.pfsense.org/index.php?topic=91844.msg508332#msg508332

There once was a web site out there where you could do that (match a GID:SID with category).  I'm not sure it exists or is maintained anymore.  I no longer have the URL. You can open a CLI prompt on the firewall and use grep to find a GID:SID within the rules.  To search all the available categories, grep all the *.rules files in this directory for Snort: /usr/local/etc/snort/rules/ If you have Suricata instead, then search the files in this directory: /usr/local/etc/suricata/rules/ Bill

thanks I got it working…. and yes I red X'ed it...

@bmeeks: Some guesses on my part – Something on your laptop was maybe trying to swap some AFP share info with FreeNAS.  That would not really be unexpected if you also use the laptop at home on the LAN. When you are home and everything is within your LAN, Snort will not necessarily be seeing NAS-to-laptop traffic as everything would be switched at layer 2 by your network switch.  So no alerts then if Snort and firewall does not see the traffic. When you are on the road, Snort sees everything on the VPN as it comes in from the WAN and gets sent on to the LAN. As for the alert itself, it could very well just be some kind of false positive in your setup.  Maybe some fragmentation is/was happening on the VPN side ??? Bill You are right of course that snort would not see this traffic if I was home.  The alert must be a false positive.  I'll suppress it. Thanks for all the work you do on the snort package.

Thanks a alot, Bill  ;)

Yep, the current pfSense release versions and the 2.4-BETA have supported versions of Snort.  As soon as FreeBSD ports updates to a new Snort version, I try to get it submitted to the pfSense team for inclusion in the current release.  It is often times not possible to backport a new Snort to older pfSense versions due to changes in other dependent libraries.  Best to try and keep your pfSense installs in sync with the current release. Bill

I'm also happy to report that transferring a sample .ISO file of a few gigabytes over HTTP with pattern matcher being set to AC resulted to 15-20M/s speeds with my connection. With HyperScan I'm seeing 24-29+M/s which is very close to the line speed. I'm on a 250/50 fiber. [image: fiber.PNG] [image: fiber.PNG_thumb]

Figured it was now a good time to try out Suricata :)

@nagaraja: Hey Bill, for the infos i got, the only address snort is able to understand and whitelist, is only the URL address record inside URL alias. In other terms http://myserverip:port/list.something instead of the list content. I  also think this could be bad for snort since it allows numeric values only Thanks for your quick reply Yes, if the text URL got written into the actual passlist/whitelist file produced for the Snort binary that would cause errors.  However, the code in the binary plugin that parses the pass list entries will discard any non-numeric values and print an error to the system log.  So it should not cause the entire pass list to be ignored.  Just the offending line or lines would be ignored. Bill

Yes, it should be possible.  For that particular AppID feature, I was not the author of the code.  Another contributor from Brazil added that code and maintains the rules.  It is part of a University, I believe.  All that to say I have not examined that part of the code since the original pull request and I don't remember exactly how the URLs are handled. I will add it to my TODO list. Bill

Something is really hosed up someplace.  Snort just should never do that, and I can't imagine any scenario under which that could happen.  Snort is not autonomous.  Are you sure your firewall is not haunted …  ;D. You can carefully examine the system log to see when (and if) Snort is restarting.  Do these "rule changes" coincide with restarts logged in the system log?  Is it possible someone else has access to your firewall and is making changes? I would suggest completely removing the package and then reinstalling it.  If that does not do it, then uncheck the box on the GLOBAL SETTINGS tab for saving settings and remove the package again and reinstall it.  Of course this second method will cause a loss of all previous settings, but it's possible that may be necessary to wipe out whatever corruption must exist someplace. Bill

@bmeeks: The "Save Settings" option is checked by default. Bill Smart Decision!  ;D

Thanks Bill!