Using pfBlockerNG (And Block Lists) On pfSense

Using pfBlockerNG (And Block Lists) On pfSense

In a previous post, I talked about implementing blocklists (aka IP reputation lists, ban lists, blacklists, etc.) generically on nearly any firewall to improve your security. The examples I used were on pfSense and OPNsense. I also discussed the methodology and some background as well so if you’re just coming into the conversation, it might be worth a read beforehand. (Previous Post: Using Firewall Block Lists)

There were some downfalls to the previously discussed approach such as the URL download (via aliases) only allowed updates every 1 day as the shortest timeframe. In addition, the “list” had to be in a very specific format so I originally wasn’t able to use known, high-quality lists with “split fields” like the original formats provided by DShield (Internet Storm Center) or Emerging Threats. Yes, I realize I could easily script this up to get rid of both of these limitations, but why if you don’t need to? 😉

If you are using pfSense, there is a really cool plug-in called pfBlockerNG that gets around many of these issues. pfBlockerNG is a free package originally written by some other folks, but now maintained by @BBcan177 (on Twitter). I’ve been pretty harsh on pfBlocker over the years because it was primarily a way to blacklist countries based on IP ranges; I didn’t agree with this approach because it doesn’t work for most businesses and it would inevitably block much needed customer traffic at some point and it was a PITA to troubleshoot. While that particular functionality still exists in the package, I won’t talk about it here. Keep in mind this feature may be useful depending on your use case.

Instead, I’ll talk about using IPv4 blocklists in pfBlockerNG. At this point, I’m assuming you have already installed the package. If not, go do so and I’ll wait here…

After installing the package, you will need to enable it from the main page. Change the settings on the main screen as necessary. Items worth noting include that I would check the interfaces to verify all of your networks are there and the “kill states” is checked.

Next, go to the IPv4 section and we are going to add some fairly well-known lists. I already discussed the ban list from Binary Defense in the last blog. The IP banlist updates every 5 minutes and while we won’t update every 5 minutes, we are going to set it up to update every hour as shown below. The other difference is that we will set the list action to “deny both” to create firewall rules blocking traffic in both directions to offending IP addresses. Note: the header/label (BD_IPs for this example) is simply used as a  placeholder. The label should, however, have something signifying which list it originates from. I’ll explain this a bit more later.

https://www.binarydefense.com/banlist.txt

Great! So we did the same thing as the previous post did with aliases, but now we are updating once an hour instead of once a day. What else can we do?

The big change is that we can add other lists in various formats. In addition to a huge, clean list of IP addresses like the banlist.txt from Binary Defense, we can also add list formats such as those used by Emerging Threats and DShield. Both of these include CIDRs (196.63.0.0/16), which would would block huge swaths of IP addresses vs. single IP addresses.

For what it is worth, you may have also seen previously that you can tie multiple blacklists to a single alias. So you may be asking, why am I separating them here? Based on experience, the free Emerging Threats lists only only update every few days so to avoid unnecessary calls to their servers, once a day should suffice.

The one “block” list from Emerging Threats already includes the aforementioned CIDRs from DShield so we don’t need to include that list separately (as shown below).

https://rules.emergingthreats.net/fwrules/emerging-Block-IPs.txt

Information from that feed header
*Those DShield CIDRs are also listed at the bottom of that feed

# Emerging Threats fwip rules.
#
# Raw IPs for the firewall block lists. These come from:
#
# Spam nets identified by Spamhaus (www.spamhaus.org)
# Top Attackers listed by DShield (www.dshield.org)
# Abuse.ch
# More information available at www.emergingthreats.net

 

The URL for the other list is below.

https://rules.emergingthreats.net/blockrules/compromised-ips.txt

After we add both URLs, the identifying headers/labels, change list action to ‘deny both,’ and update frequency to ‘once a day’ we are ready to go.

Click ‘save’ and if you followed my naming conventions, your aliases under IPv4 should look similar to mine below.

Update – firehol_level3 – 19 March 2017

I was notified of the numerous ban lists on http://iplists.firehol.org/ shortly after this write-up (and the related one on using firewall blocklists). Overall, the site has great explanations on the in’s and out’s of the various lists. Their comparisons/metrics include what percent of one list is included in another list, which ones might yield false positives, how an IP address would get added to a list, etc. After testing in a few environments for several weeks, I found the firehol_level3 list to be extremely effective and I haven’t yet experienced a false positive.

You configure firehol_level3 much in the same way the Binary Defense list was configured above, i.e. deny both, update every hour, etc. I also chose to update from the GitHub feed (vs. the firehol.org site) to avoid bandwidth costs for someone providing a free/low-cost service. Note: There are other feeds there that might be useful on the site as well. I chose the firehol_level3 feed because of what is included and what should be a fairly limited number of false positives.

https://raw.githubusercontent.com/firehol/blocklist-ipsets/master/firehol_level3.netset

Firewall Rules

If you go to the firewall rules section of your firewall, you should see two (or three) separate rules added automatically on the WAN side. Similar rules should have been added to the LAN side as well… Remember we are blocking in both directions.

WAN

LAN

As previously described, you can once again hover over either of the rules to see if the IP addresses/ranges have been pulled back by the firewall cron entry we setup a short time ago. You can also go to the diagnostics, table, pfB_[your list name] to look at all of the IP addresses and ranges for that particular alias/list.

The update page for pfBlockerNG also tends to be pretty solid if you need some assistance troubleshooting, e.g. why something won’t update. You can also force updates, see when the next run time is, etc. as well.

Last, but not least… Is it working? The alerts page on pfBlockerNG shows you timestamps for blocked IPs, what interface it was on, what rule triggered the block or reject, etc.

Note in the example above I’m seeing blocks on the WAN side. If you’re seeing blocks on the LAN, that means an internal machine is attempting to contact a known malicious IP address and to quote Mr. Mackey, that would be really bad, mmm kay?

In all seriousness, keep an eye out for blocks on the LAN side as that can be a fantastic indicator that one of your internal machines is compromised.

13 thoughts on “Using pfBlockerNG (And Block Lists) On pfSense

  1. Love this article! Very informative. Unfortunately for a few reasons I have migrated from pfSense to OPNsense and the pfBlockerNG plugin is not an options it seems.

    I know it’s asking a great deal but would you consider putting out the script to smooth out the limitations on OPNsense?

    thank you for your time!

    1. Thanks for the feedback! I’m not the author of pfBlockerNG, but I’ve often wondered the same because of their similarities. Maybe the author will provide this plug-in for OPNsense in the future? In the meantime, you can utilize the previous write-up on using simple blocklists; as discussed, there are limitations to this technique such as the update timeframe, however, it is definitely better than nothing!

  2. So do you use firehol3 in addition to the previously mentioned EmergingThreats and BinaryDefense, or is firehol3 inclusive enough that you don’t think those other two are necessary?

    1. Yes, I use firehol3 in addition to the others and it performs quite well. Make sure you don’t use firehol1 unless you change the interface rules as firehol1 includes private IP ranges. I’ll make some updates to the pfBlockerNG article when the new version is released too, so stay tuned!

    1. Mark, happy to hear you found it useful! I don’t recall on firehol2, but I know firehol4 was expected to have a large number of false positives (their words, not mine). This is the sole reason I didn’t use it, i.e. I would rather let something pass than errantly block it. It really just depends on your environment and your tolerance for false positives. Firehol3 seemed to be the sweet spot for me, but your mileage may vary. Test it out and let me know!
      In regards to other lists, I’m now utilizing roughly 60 lists and I will be performing another post on it very, very soon. With the 2.X branch of pfBlockerNG it would be ridiculously difficult to replicate my current setup IMO simply because of the amount of configuration. That being said, BBcan177 (the author of pfBlockerNG) has knocked it out of the park on the new version 3.0 that I’m currently beta testing. I expect 3.X to get released in the next month and it has a ton of new features beyond *just* config. As soon as it is released, check back here and I’ll have a write-up on the new config process as well as which lists I’m using/testing. I’ll include some of the gotchas I encountered along the way too.

    1. Not a shameless plug at all! I was in the process of writing a post on DNSBL services when I started beta testing version 3 of pfBlockerNG so I held off on it for the time being. I’ll write a config guide on DNSBL as soon as the new version is released. FWIW, I double-checked and SquidBlackList is already listed as one of the “pre-configured” Ad feeds. 😉

  3. Came across your article recently while trying to garner info on using pfBlockerNG effectively. I’m curious as to whether you configure any other feature in PFB other than the IPv4 blocking you illustrated so nicely above? (I have added these to our system – thanks!)

    I’ve been using the GeoIP lists in PFB to block (deny_inbound) most countries. This works, but has limitations of control in that blocking USA sources (we’re in UK) also blocks a lot of legitimate inbound email – and it’s apparently not the “recommended” configuration. It results in having to manually make our own whitelists for customers using 3rd-party USA or European email scanning hosts (like messagelabs.com or similar).

    1. I typically didn’t use country block for that same reason, i.e. users travel and so it was a constant source of angst. I also use DNSBL quite extensively to block ads (malicious especially). Since this post, I’ve added several feeds to the IP blocklists. Adding quality blocklists and DNSBL is made significantly easier in the yet unreleased version of pfBLockerNG, which I have been testing for some time. As soon as the new version is released, I will have corresponding posts to ease implementation. Take care!

Leave a Reply

Your email address will not be published.