Changelog
28Feb2017 – Originally posted
19Mar2017 – Added firehol_level3 section
15Feb2018 – Added outbound/LAN rule section

This guide is primarily for anyone using a firewall other than pfSense. If you are using pfSense, I would strongly suggest following my guide written specifically for pfSense (and pfBlockerNG). That guide replicates/mirrors much of the work below and also adds to it. 

https://linuxincluded.com/using-pfblockerng-on-pfsense/

IP reputation lists (aka IP blacklists, ban lists, block lists, etc.) are fairly plentiful and some are better (more IPs and less false positives) than others. Now before I get hate mail stating blacklists don’t work, the truth is blacklists are extremely helpful. Would I use them as my sole line of defense? No way! However, when used with multiple layers of security, blacklists prove to be extremely useful. In addition, in many cases a blacklist can actually help reduce resource utilization and/or logs on your firewall.

One blacklist I found that seemed to work extremely well was from Binary Defense. As stated, there are numerous other lists you can use and keep in mind that you can even use multiple lists if needed. If you click the link below, you’ll see it is nothing more than a list of “bad” IP addresses. Based on feedback from their folks and information I discovered in my own testing, the banlist.txt file updates every 5 minutes.

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

In this example, I’ll be using a pfSense firewall. I followed extremely similar steps on an OPNsense firewall and it worked the exact same. Many commercial firewalls have almost identical capabilities so don’t think you can’t utilize this methodology just because you’re not using one of the aforementioned firewall packages.

Creating Aliases

So how do we go about adding it to our firewall? Surprisingly, it’s much easier than you would expect. First, go to aliases (Firewall -> Aliases), click ‘Add’, give the alias a name, provide a description, and then type in (or copy/paste) the previous link in the URL table field. Unfortunately, the minimum update frequency is only one day (/1) so we can’t take advantage of the every 5 minutes timeframe when the list is actually updated; we’ll come back to this topic later on a different, yet related post if you use pfSense. (Next post: Using pfBlockerNG (And Block Lists) on pfSense)

Inbound/WAN rule

Next, go to the rules (Firewall -> Rules), select the WAN tab, and add a rule similar to the one below using the alias name you previously configured. You don’t necessary need to log the packets, however, I would strongly recommend it so you can troubleshoot a little easier if needed.

Settings
Action -> Block
Interface -> WAN
Protocol -> Any
Source -> Single host or alias -> BanList
Log -> <Add check>
Description -> <Something to help you remember the rule>

After clicking save and apply, your rule should look similar to the one below. Also, make sure the rule is higher in the list than others, e.g. VPNs, NAT rules to web servers, etc.

Outbound/LAN rule

If you only want to block inbound on your WAN interface, then you can skip this section. This rule essentially keeps your internal networks (such as your LAN segment) from communicating with known bad, external IP addresses. Once again, go to the rules (Firewall -> Rules), but this time select the LAN tab. Add a rule similar to the one below using the alias name you previously configured. Similar to the explanation above, you don’t necessary need to log the packets, however, I would strongly recommend it so you can troubleshoot a little easier if needed. Also, if you need this block on several internal network segments, I would suggest using a floating rule instead so you don’t have to duplicate it on each of the internal networks.

Settings
Action -> Block
Interface -> LAN
Protocol -> Any
Destination -> Single host or alias -> BanList
Note: The WAN rule above uses the source address while the LAN rule uses the destination address
Log -> <Add check>
Description -> <Something to help you remember the rule>

Tables

At this point you should be able to hover over the ‘BanList’ in the firewall rules and see if it has IP addresses associated with it. Another way to see all of the IP addresses tied to the alias is by going to Diagnostics, Tables, and then selecting ‘BanList” from the dropdown.

firehol_level3 list add-on

I was notified of the numerous ban lists on http://iplists.firehol.org/ shortly after this write-up (and the related one on using pfBlockerNG on pfSense). 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 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

Is it working *and* blocking?

So now you know IP addresses are populating the alias. But how do you know it is actually blocking something? You can simply look at the number of bytes the rule has processed or you can take a peek at your firewall logs. I chose the latter for completeness and it didn’t take long… Literally less than a minute. Taking a glance at the first few blocked entries on the WAN interface, I came across the following traffic. Keep in mind that this blocked traffic does not show if you don’t log all blocked packets.

Now going back to the banlist.txt, I was able to find the same IP address there. Long story, short… Success!

End all, be all? No. Another line of defense and improving your security? Absolutely! If you added the outbound/LAN blocking rule, you could also use your logs for primitive threat hunting. For example, if a machine on the network is trying to communicate with a known bad IP address, you might have bigger issues!