Using Firewall Block Lists

Using Firewall Block Lists

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.

pfsense block outbound

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!

6 thoughts on “Using Firewall Block Lists

  1. Nice work! But I encounter a problem:

    A WAN rule does (at least with OPNsense) not prevent inside clients from accessing the banlist-IPs. You would need to create a floating rule blocking as destination the banlist instead.

    With the WAN rule you only block requests from banlist IPs to some destination inside the firewall.

    1. That is correct. The WAN rule only blocks outside IPs from the WAN IP (or forwards), not the internal network(s) going outbound. I’ll update the documentation in the next few days to include something similar to what you’re describing because I think that is a nice addition. One other change you might consider (and what I’ll ultimately add to the guide above) is to create two separate rules, i.e. one with your alias as the source and one as the destination. You could still use floating rules if you’d like and/or if you are selecting multiple internal networks, however, one (source) rule on WAN and one (destination) rule on LAN would work too. At any rate, thanks for the feedback!

  2. Nice Articale!

    But I have multiple VLANs and I followed steps above but default DNS address to host is not assigning 10.10.10.1 I am able to ping 10.10.10.1.

    let’s say VLAN 9 has in range 172.1.x.x while nslookup it’s 172.1.x.x and not 10.10.10.1.

    unable to filter internet traffic.

    1. I use VLANs extensively with this solution and it works very well. Considering you are able to ping the virtual IP (10.10.10.1), I’m assuming your settings under Firewall -> pfBlockerNG -> DNSBL configuration has the correct interfaces selected for the permit firewall rules. Nonetheless, I would still double-check it. Your local machine is querying your standard firewall internal IP address and not the 10.10.10.1. For example, if your firewall is 172.16.1.1, then your DNS server on your local machine should also be 172.16.1.1. The virtual IP is only seen when you are pinging a domain found on a DNS blacklist. Likewise, an nslookup using 172.16.1.1 as the lookup server should provide 10.10.10.1 as the return address for any domain found on a blacklist. Hope that helps!

  3. Thank you bro problem resolved, I have select VLAN9 in permit firewall rules.

    One other question, it is possible to block all the site everything on the internet and allow only a few sites.

    for example, block everything with Pfngbloker and allow only a few sites which is mentioned in DNSBL Whitelist only.

    Allow only DNSBL Whitelist sites else everything blocks, it’s possible to achieve?

    Thanks

    1. You could do it with pfBlockerNG, but you couldn’t run separate configs for different VLANs which I suspect would be an issue. A really rudimentary solution would be to use aliases and firewall rules. This may not work well in this day and age with automatic updates, javascript calls to diff sites, etc. That said, I would at least give it a shot. Although I haven’t used either package recently, some time ago we regularly used the squid and squidguard packages for this exact functionality. I would recommend doing a little reading on them and then throwing them in a test environment. I’ll forewarn you that it would involve working with certificates, root stores, etc. I wouldn’t be at all surprised if this method had issues with TLS 1.3 either. Hope that helps! If you come up with some other solutions, I’d be interested in hearing about them.

Leave a Reply

Your email address will not be published. Required fields are marked *