pfSense: Using pfBlockerNG (And Block Lists)
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 https://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.
список для pfblocker. Обязательно поставьте галку удалять дубликаты.
IPv4:
https://voipbl.org/update
https://rules.emergingthreats.net/fwrules/emerging-Block-IPs.txt
https://pfblockerlists.smallbusinesstech.net/hackerlist.txt
https://www.myip.ms/files/blacklist/csf/latest_blacklist.txt
https://raw.githubusercontent.com/firehol/blocklist-ipsets/master/snort_ipfilter.ipset
https://raw.githubusercontent.com/firehol/blocklist-ipsets/master/cta_cryptowall.ipset
https://raw.githubusercontent.com/firehol/blocklist-ipsets/master/blocklist_de_sip.ipset
DNSBL: