Pfsense Snort


PfSense – Snort package failing to update bo April 5, 2020 No Comments Tried to upgrade Snort and was receiving failures, particularly missing files dealing with Apache and various others. PfSense Part 11: Configuring Snort in pfSense This video is a step by step guide, demonstrating how to Configuring Snort in pfSense This video tutorial outli.

  1. Suricata Versus Snort
  2. Pfsense Snort Setup

Thanks to the Snort package and OpenAppID, pfSense® is now application-aware.

This layer 7 functionality arrives through an upgraded version of the Snort package for pfSense software. Maintained by Bill Meeks, the Snort package has been available for many years and is one of our most popular packages. Thanks to his continued efforts, as well as those of Demair Ramos, OpenAppID is now part of the Snort package.

What is OpenAppID?

Introduced in 2014 by Snort author and Sourcefire founder Martin Roesch, OpenAppID is an application-focused detection language and processing module for Snort. Quoting the original blog post by Martin Roesch:

“OpenAppID puts control in the hands of users, allowing them to control application usage in their network environments and eliminating the risk that comes with waiting for vendors to issue updates. Practically speaking, we’re making it possible for people to build their own open source Next-Generation Firewalls.”

It is important to remember that OpenAppID provides application identification and not threat detection. We strongly recommend reading the entire blog post by Martin found here.

OpenAppID consists of a set of LUA libraries for detecting applications, as well as the application detectors themselves. To enable OpenAppID in the Snort package for pfSense, Bill Meeks has integrated all the necessary AppID stubs and LUA scripts to enable OpenAppID to function. However, in order to employ these signatures, it is necessary to create text rules similar to any other custom Snort rule, with the difference being the “appid” keyword in the rule. The appid keyword can be embedded in any rule to match only on traffic already identified as a specific application.

These rules reference the various application IDs provided by the VRT (Vulnerability Research Team) in your rules. In order to actually use OpenAppID you need to get the App ID stubs from VRT and then create text rules that reference the App ID’s. However, the actual application detection rules for analyzing traffic are not provided by Cisco or Snort.

This is where, once again, our community shines. A pfSense user and community member named Demair Ramos created a large collection of text rules that use the AppIDs provided by VRT. Demair even hosted the rules he created on his university’s server in Brazil, but this server has limited bandwidth, and implements geo-blocking to preserve the same. Working with Bill, Demair and our developer Renato Botelho do Couto created a new ‘mirror’ of this rulebase on our infrastructure, and Bill has changed the Snort package for pfSense to use them, and pfSense-package-snort v3.2.9.5_4 or later has the updated changes.

Using Snort and Application ID

In pfSense, OpenAppID can successfully detect, and if configured to do so, block over 2600 different services like Facebook, Netflix, Twitter, and Reddit. The package can be installed from the pfSense Package Manager and configured via the existing Snort GUI. Those familiar with snort should find the interface for working with OpenAppID detectors and rules familiar and easy to use.

We have recently updated our Snort guide for pfSense and added a brand new section covering Application ID, which can be found here.

Our plan for OpenAppID is not limited to pfSense, we intend to enable it for our upcoming advanced platforms that use Cisco’s VPP and DPDK. More on this subject in the future.

We would like to express our sincere gratitude to our contributors Bill Meeks and Demair Ramos for making pfSense application aware, as well as thank Cisco’s Martin Roesch for his vision and work enabling true NGFW functionality for pfSense software.

Being honest, this PfSense firewall nearly drove me to madness when I first got it. It’s not because the thing isn’t incredibly powerful, or that the interface isn’t surprisingly intuitive, it’s that I’ve been inpatient, and haven’t been using the included tools to properly diagnose problems. I was interested in “click this button to fix everything right now” type solutions, which you won’t find in devices like this.

That being said, there is a certain sense of frantic urgency which arises when one’s network is crippled, and there’s an angry user, namely you, trying to update MacOS, and the internet doesn’t feel like helping. Like in any such situation, you blame the newest piece of equipment in the building, and you’re partly right. You really should take the time to read the documentation cover to cover, but for when you’re in that frantic state, here’s how I ended up unblocking MacOS updates.

I’m going in detail here because the process is more or less the same for unblocking anything else (in this case Snort was the culprit, but where separate services only report IPs, not block them, this guide should work anyway, you just may have to put the alias you create elsewhere).

1.) Check the dashboard for the offending IPs.

By default, upon installing snort, there’s an active log of blocked IPs at the bottom of your dashboard (this was not of my dashboard at the time, I took this just now to show what you’re looking for. DO NOT OUTRIGHT TRUST THESE IPs):

2.) Check these IPs with a reverse DNS lookup to ensure they should be whitelisted.

In our case, Apple owns 17.x.x.x, so it could be as simple as that, but there are likely ads/trackers in that range we want to continuing blocking. I just let a couple Macs update to see what came through, and sure enough, I caught a bunch of Apple IPs with strange looking domains.

Suricata Versus Snort

3.) Create an alias with these IPs.

You can go Firewall > Aliases > IP to add them. I went ahead and made an alias called “Apple Update” with the IPs I caught, and where Snort only takes raw IPs, I noted their corresponding domain lookups from earlier. If you’re reading this looking for an immediate fix as opposed to learning the process, this screenshot should be all you need. I don’t think this is all of them, but it was enough to work for me. They follow a pretty simple pattern to regex if you want to open it up more:

Pfsense snort vs suricata

4.) Whitelist this alias in Snort.

This is important- Snort is not itself responsible for blocking these IPs- all it does is identify and report them. By adding this whitelist, you’re only telling Snort to stop reporting them. You will still get alerts unless you also suppress, and you will need to hit “clear” in Services > Snort > Blocked for it to take effect. To add the alias, head to Services > Snort > Pass Lists, and add the alias you just created:

Hit “clear” for it to take effect:

Pfsense Snort Setup

…and you should be good to go. This was one of the first times I was left totally stranded support-wise and had to engineer a solution truly solo, but this general workflow has continued to serve me well. It’s better to know where to look for issues, use the diagnosis tools you’re given, and make small exceptions to the rules only when and where necessary, as opposed to madly Googling the issue and finding a nuclear option out of frantic desperation. If this happens to you for one thing, it will likely come up again- managing black/whitelists like this is a very manual process you can assume you’ll be doing fairly often, but in my opinion, that’s a fair price to pay for vastly superior security to your typical home network.