Hi everyone,
is there any way to have PiHole block domains that resolve to lists of IPs? Basically resolve each domain and match the A records against an IP blocklist.
ControlD has this feature, and the only reason I ask is because Im too poor to pay for Control D, so I wish Pihole supported this.
That is essentially how Pi-hole works. All domain names lead to IP's. Pi-hole blocks domain names, and thus blocks the matching IP's.
Well, not exactly. Yes I can load in a whole bunch of domain lists, and block them from resolving. What Im asking is the ability to also load IP lists (in cidr notation) and have Pihole also match the resolved IPs from domains that were not blocked by domain lists, against these IP lists. If there is a match (A record is in the "bad IPs" list), block it.
I wanna use the Spamhaus DROP lists (and a few other IP intelligence feeds) to do additional blocking on top of domain lists. DROP - Don't Route or Peer lists - The Spamhaus Project
Hope that explains it better.
Pi-hole will not do that.
A firewall or router (with the correct software) can block IP's.
Sure, but why can't Pi-Hole support this, it's clearly possible and a good security feature imo. Im no developer but matching 1-5 IPs that most DNS records resolve to against a list of IPs seems rather trivial.
Asked and rejected in july 2019, see here, read the arguments...
edit
I now use pfsense + pfBlockerNG (the IP part only) to achieve IP address based blocking.
/edit
Hmm, maybe Im daft, but I didnt see any real arguments against why its a bad idea except for multiple domains sharing an IP, which to me is not a deal breaker or a problem. Its rare for an IP to be hosting a bunch of legit site and distribute malware at the same time. If that exists, Im willing to bite the bullet and this is entirely user configurable. Most domain blocklists are full of stuff that shouldn't be blocked but is, I don't see how this is any different.
I was really hoping not needed to run more software, but looks like this is the only option....
Hi folks,
Control D guy here, someone linked me to this thread. Funny enough, your thread (pihole-FTL: block IP's from lists) was the reason why we added this feature.
Is it bulletproof and prevents malicious software running on your network from resolving malicious domains that point to bad IPs, through a hardcoded resolver/DoH? Nope, but the same is true for "malware domain" blocklists most people run on their Pi-Hole. To us, it just seemed like a no-brainer addition that takes advantages of many existing IP threat intelligence feeds. Can you bet your life on it, absolutely not. Is it still useful? We thought so.
Mind you, there IS a performance hit if you need to parse the A/AAAA records against IP blocklists (especially if they're in CIDR notation since this is not a O(1) lookup), but the difference is ~1ms, so we felt it was worth it.
read this document about blocking (o)DoH, daily generated IPv4 and IPv6 lists on GitHub, RPZ file also available for use with unbound (how to), knot-resolver, bind, ...
To be fair, 2019 was quite a while ago and things have vastly changed since then. Both in mindset of the team and capabilities with improved codebase.
That FR is 3 years old now and it's still open. I don't think it's fair to say the idea was rejected since we move FRs to not-implemented and close them down if they are truly dead.
I mean you CAN totally do all of this, but that defeats the whole point of Pi-Hole's simplicity. Not a lot of people run pfSense as their router, and the barrier to entry is a LOT higher than installing Pi-Hole.
edit
quote removed
/edit
A solution for unbound (tested) and probably bind and knot-resolver (not tested) users:
I already mentioned response policy zones here (just a few entries above this one). I've been using this feature to block domains, however, reading up on this, it turns out you can use rpz to block IP's
an example (test only, remove after testing !!!)
create a response policy zone source file (/var/www/html/ip.rpz) like this:
$TTL 30
@ SOA pi.hole. hostmaster.pi.hole. 2207240509 300 1800 604800 30
NS localhost.
;
32.30.154.239.213.rpz-ip CNAME .
32.31.154.239.213.rpz-ip CNAME .
create another rpz entry (see the doc I've made) entry in the unbound config file:
rpz:
name: iprpz
zonefile: zonefiles/ip.zone
url: http://127.0.0.1/ip.rpz
rpz-action-override: nxdomain
rpz-signal-nxdomain-ra: yes
rpz-log: yes
rpz-log-name: iprpz
restart unbound (once unbound knows about the zone, you can reload the zone with sudo /usr/sbin/unbound-control auth_zone_transfer "iprpz")
dig the domain (remember example, remove after test!): dig tweakers.net
result in the unbound log:
Jul 27 15:49:29 unbound[19920:0] info: rpz: applied [iprpz] 213.239.154.30/32 rpz-nxdomain fdaa:bbcc:ddee:2::5552@55159 tweakers.net. A IN
my alerting:
you never mentioned the source of your IP blacklist(s). I've been using talos (warning: there is a limit of the number of downloads in a given time) and firehol. I download (refresh) these lists once a day, currently using them in pfblockerng (pfsense).
according to this article, there are a few methods you can use to convert the IP addresses in these lists into a valid rpz file entry. Maybe a linux expert can even recommend a better way.
This implies of course you need to download the talos, firehol, ... list(s), and use them to create a valid rpz file; I'm sure your system has some spare resouces (night) to perform this task.
thoughts...
Heya,
I can't speak to any of the above, as we use a custom built DNS server + blocklist parser. We don't work with RPZ files or have any upstream dependencies.
While doing IP matching, you have to perform a DNS lookup and wait for the results, this can add anywhere from 1ms (cached) to 1s (full recursive lookup) of latency. The matching behavior adds about ~1ms of latency on top of that with these sources that we currently have in production.
"https://www.spamhaus.org/drop/drop.txt",
"https://www.spamhaus.org/drop/edrop.txt",
"https://www.spamhaus.org/drop/dropv6.txt",
"http://lists.blocklist.de/lists/dnsbl/all.list",
"https://feodotracker.abuse.ch/downloads/ipblocklist.txt",
"https://rules.emergingthreats.net/blockrules/compromised-ips.txt",
"https://raw.githubusercontent.com/ktsaou/blocklist-ipsets/master/firehol_level1.netset",
"https://raw.githubusercontent.com/firehol/blocklist-ipsets/master/firehol_level2.netset",
"https://snort.org/downloads/ip-block-list"
This list will be expanded when our lists are open sourced in the next little while, however they will be published in a flat file format (line per CIDR). Converting them to RPZ format is pretty trivial, probably a ~50 line script would do the job.
Can you share that conversation with me?
done...
I just read that private thread. I really don't think it's fair to @DL6ER to distill all of what he said to a one sentence quote that takes everything out of context.
I've asked you before and I'm reminding you again, if you publicly post things from private conversations with developers then the likelyhood of the developers continuing to discuss things in private with you will vastly decrease. Please don't do this.
Sorry for that, I just assumed this argument would reflect the "why not" as good and short as possible, thus avoiding people, including me, getting their hope up to ever see this request being part of pihole. I therefore presented an alternative, which, by the look of it isn't a good alternative (increased latency)...
quotes will not happen again (quote removed)...
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.