pihole-FTL: block IP's from lists

Feature Requests
1

I know pihole only can process lists, using specifically formatted DNS /URL entries. These lists are added to /etc/pihole/adlists.list.

There are several lists on the web with only IP addresses, such as, but not limited to, the talos list, the firehole list, ...

I was wondering if pihole-FTL could be modified to check these IP's, right before returning the resolved address to the client, replacing it with the appropriate IP address for blocking, if found on the list.

Example

  • assume ssl.google-analytics.com isn't on any blocklist. Pihole-FTL would resolve and return 172.217.17.72 to the client, since the domain is NOT on any list.

  • before returning the address 172.217.17.72 to the client, a check should be made if that address is on the IPgravitylist

  • if that address is on the IPgravitylist, pihole-FTL should return 0.0.0.0 OR :: OR the pihole IP address, depending on the blocking mode.

  • there could be an IPlists.list, same format as /etc/pihole/adlists.list

  • there should be parsing logic, to ensure the resulting IPgravitylist contains only valid IP addresses.

  • The resulting IPgravitylist could be a new table in the database, ensuring searches are fast enough to avoid performance loss.

Currently, I'm using these IP lists on my pfsense box, using the IP list feature of pfBlockerNG. The result of using these list, is a firewall rule that simply blocks the IP's. The downside of this method is a noticeable delay in pageloads, as the request simply times out. Pihole-FTL responding with a appropriate address to the request, could eliminate this timeout.

I haven't been able to find any network wide product, capable of producing a valid DNS response, based on both DNS and IP lists. This would be a first...

@DL6ER: I've already asked this question to Simon several weeks ago, but did NOT get a reply. Apparently, there isn't much going on in the dnsmasq development, since v2.80.

2

I'm going to say no. This is not a function of a DNS server.

3

That may be correct, but pihole is NOT a DNS server, it just happens to use a dnsmasq fork, a DNS server, to achieve it’s goals. Pihole is, as the home page says A black hole for Internet advertisements . I would assume that any means to achieve the goal of pihole are worth considering. Pihole isn’t my DNS server, unbound is.

2 Likes
5

Ummm, yeah, Pi-hole is a DNS server.

6

I wouldn't say this and I know you're also not saying this as you already said

I thought about your idea and I can see some value in it is you understand Pi-hole as a security product. However, my personal understanding is that it should not be misunderstood as such a thing as it is too easy to simply circumvent the Pi-hole without us being able to even notice.

You may lock port 53 to the outer world, then they may simply use a different port. You may do deep packet inspection, then they simply encrypt their content by using DoH to a hard-coded IP range. You may xyz, ...
This is just to highlight that there are always ways to circumvent the local DNS server and - even when I think such a feature could be implemented in FTL - we shouldn't do it as it can easily lead to a deceptive feeling of safety and leak to a risky handling of network security.

But I'm open for more discussions, maybe you can convince us regardless of what I wrote above.

7

Commenting on this: This is not the first period of prolonged silence on the dnsmasq mailing list. I'm aware of the limitations a single man project has, however, dnsmasq has proven to be worth it and the reasoning before we start diverging need to be really good.

8

Validating input to be a valid IP address is not a trivial task.

Adding a feature like this to FTL would diverge it from the upstream dnsmasq code and truly create a new fork of dnsmasq that would be incompatible with future updates from Simon. This will add a very large burden on the Pi-hole team for something that can easily be handled by a firewall.

12

If your goal is to prevent users from being able to access 172.217.17.72 then just use something like IPTables and create an IP set of addresses you do not want clients to access. There doesn't need to be any wait for the client to time out if you reject the traffic with the proper flags, similar to the IPTables rules that we found worked for blocking HTTPS requests while preventing the client from pausing for timeouts.

13
14

Without having the illusion this is ever going to happen, clear to me as of the first response, I would like to argue your quoted statement.

The default adlists.list, suggested during the pihole installation contains https://mirror1.malwaredomains.com/files/justdomains and https://zeustracker.abuse.ch/blocklist.php?download=domainblocklist

Do you really assume people see the word malware and abuse, and don't assume they have at least some protection against these, making it a security product in their minds?

The reason I would like pihole to take some action (implement something more than it currently is - innovate) is the fact that you can read almost anywhere the advertisers are fighting back, making it a losing battle with the current functionality of pihole.

Another feature request, made recently, is to, somehow, find a way to block recently created domains. May be not easy to implement, but could be a way to make pihole a more effective and attractive product, changes to the web interface may generate a WOW effect for some users, but since the introduction of regex, nothing has really changed.

To give my thoughts on how to implement my proposal (ain't gonna happen, I would fork if I could, but not smart enough)

  • sooner or later, pihole-FTL has an answer ready to send to the client, the original host that made the request.
  • code: If result in IPgravitylist then send 0.0.0.0 else send result.

Of course, I don't know the first thing about the source code, it's probably a lot more complicated than this, but this is how a project manager would approach the issue.

In conclusion: if you want pihole to remain relevant, you're gonna have to do something to get new users to install it. Changes to the web interface may convince some manager types, but this isn't going to have a long term effect.

1 Like
15

Well, yes, they will have a certain protection. I just wanted to highlight that this should not be stretched too much. If they happen to request a blocked domain from Pi-hole, then they will get the blocked reply. Instead of blocking based on an IP, I'd argue that the corresponding host name should instead be on a blocking list. I can see that this might be less effective, because

however, regex is a certain hindrance for them.

When you filter on the replied IPs in addition, we can easily run into numerous additions problems as

Look at server politics run by most major hosting providers. Ad content can easily live on the same server as the legit content, a web server can host dozens or even hundreds of pages from the same IP as you very well know. They just decide what to respond with based on the host name you used to connect to it.

That is not and should not be our first goal (well, I should say it is not my goal). If you ask for personal opinion, here it comes: I want to make a software that is useful for our users and obviously also for myself.
If the software becomes less "relevant", then that is fine as long as it still serves the purpose of those who use it.

  • We are not selling anything any licenses and we are not going to do this in the future.
  • We do not run the project as a business.
  • None of the developers is basing their daily food on the project.
  • We do not have to do anything possible to stay in the minds of managers.

in some way, this is already implemented in development as I added the support for massive whitelists. And with massive I really mean dozens or hundreds of million domains if you like. Combined with a all-blocking regex, this seems to come close to the idea in this feature request, although it is more based on the idea of allowing only legit domains instead of blocking young ones. This approach has its own drawbacks but I will go to this feature request you linked and comment there tonight.

Just to summarize this: You see, we are still evolving. It is just not happening like a manager would maybe do it - we focus more on sustainability than on "WOW effect".

16

This is the only technical opposition I've heard so far, that does make sense. Maybe, I'll run in to it some day. As explained in the first entry of this topic, I've added the IPs of the lists I've mentioned to pfBlockerNG, they are now all blocked on the firewall, so whatever is behind them, doesn't get trough. The bad thing is the timeout. I'll have to consider this in the future, whenever I cannot go where I want, but so far, that hasn't occurred yet.

17

I've offered you a solution to combat the timeout. It's up to you to implement it or not.

We've had no slowdown in adoption of Pi-hole, in fact things are picking up!

19

I can definitely see how being able to block hostnames based off their IP could be useful (Microsoft Telemetry IP blacklists, anyone?), but I do have to agree with others that it really does fall outside the purview of Pi-hole being a DNS server.

If it could be implemented in a way that would be very easy to add back when upstream dnsmasq gets updated, that'd be awesome, but I honestly doubt that'd be the case.

Ultimately, I'm of the opinion that IP blocking should be handled at the firewall because you can never be sure whether DNS resolution comes into play when it comes to this sort of thing.

3 Likes
20

I found a feature request, referring an alarming new type of malware, using DOH to attack. Since the pihole documentation offers a guide to implement it, I assume it is well within pihole's scope.

The feature request (already rejected as usual) refers a github page, containing lists with DNS entries, and, more relevant here, IPv4 and IPv6 lists, that could be used in the suggested IPlists.list.

I was wondering if this would count as a good enough reason, making pihole users, using DOH, implemented per pihole's guide, resistant to these attacks?

P.S. I've relayed this information to Simon, hoping he will consider the feature request.

21

That's not the way to engender the developers to be likely to explore your requests.

23

firefox: network.trr.uri, setting: https://mozilla.cloudflare-dns.com/dns-query

if the normal (pihole) DNS service isn't going to resolve this, how will the client get the IP address?

browser: https://mozilla.cloudflare-dns.com/dns-query, results in empty page. https://mozilla.cloudflare-dns.com/ provides an explanation for using 1.1.1.1

nslookup mozilla.cloudflare-dns.com results in

Addresses:  2606:4700::6810:f9f9
          2606:4700::6810:f8f9
          104.16.248.249
          104.16.249.249

Both the IPv4 and IPv6 addresses are on the list, provided in the IP lists on the DOH GitHub page.

edit
You might argue, adding the hosts lists (doh-hosts.txt) to adlists.list would protect, using the current functionality of pihole. Unfortunately, the domain mozilla.cloudflare-dns.com isn't on the list (already reported). It looks like the browsers are simply creating a domain in their zone, pointing to one of the IP addresses, capable of providing DOH services
/edit

You might want to do the research, before telling me I'm wrong.

2 Likes
27

To be honest and complete, this article (uk isp group names mozilla internet villain for supporting dns over https) on reddit, comments here, appeared today, a rather pro DOH opinion is expressed here.

I still believe unbound, as a recursive DNS server, is the better option (this may change in the future), provided your ISP doesn't interfere with regular DNS requests, going to servers, other than their own. The idea is simple, divide and conquer. Visiting the website of iRobot will of course give iRobot the option to collect my data, but Samsung will never know, and vice versa, nobody gets a complete history of whatever DNS requests I'm making.