If you are also interested in pfBlockerNG (DNSBL) for ad and
malvertising blocking, I have a walk-through on it here! 
–> Blocking Ads & Malvertising on pfSense Using pfBlockerNG (DNSBL) <–

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 an amazing 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 many years ago 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 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 is really, really ridiculously bad!

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.