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.
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.
So how do we go about adding it to our firewall? Surprisingly, it’s much easier than you would expect. First, go to aliases, 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. (Next post: Using pfBlockerNG (And Block Lists) on pfSense)
Next, go to the rules and add a rule similar to the one below using the alias name you previously configured. Note: you don’t necessary need to log the packets, however, I would strongly recommend it so you can troubleshoot a little easier if needed.
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.
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.
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 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.
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 a minute or less. 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!