Internal IP addresses being leaked

Help
1

After upgrading from 4.4 to 5.0 suddenly my Pi Zero running only PiHole is making reverse DNS queries for every other host that contacts it (presumably making a DNS request), and therefore it's requesting upstream values like 1.0.168.192.in-addr.arpa. This basically provides an internal network map of all the host IPs on my network to my ISP and anyone else listening between me and the DNS provider of my choice. It didn't do this before the upgrade to version 5.0.

Is this a new bug? I've created a wildcard block for 168.192.in-addr.arpa for now so the requests stopped being sent outside my network.

2

PTR requests are normal, and Pi-hole will make these routinely to identify clients on your network. If the clients are known to Pi-hole (i.e. mapped locally), then they are answered locally. If they are not answered locally and you have not checked the option boxes to not forward these to the upstream resolver, they are forwarded.

image
image1171×186 25.3 KB

This is not the case. Everybody has clients on private IP ranges behind their LAN. The fact that you have a client at IP 192.168.0.8, for example, is not providing anything of interest to anybody. I could give you the IP's of all 40 clients on my network and it would be of no value to you, since the clients are hidden behind my router.

This is not how you keep them from leaving your network. See above.

Please post the token generated by

pihole -d

or do it through the Web interface:

Tools > Generate Debug Log

I'll look through your configuration for any problems.

Also, please post the output of ip neigh

5

Your debug log does not show it. What is the setting for "never forward reverse lookups for private IP ranges?"

grep DNS_ /etc/pihole/setupVars.conf

6

The method of uploading your debug log to our private server, where it is accessible only by the token you provide, and by the nine people on this planet with access to that server, and for 48 hours only, is to protect your privacy. From your debug log, there is no indication of your public IP, so any private IP ranges are of no consequence.

Posting a sanitized version on a public forum is much less private.

8

There is no entry in that configuration file regarding reverse lookups. The requested grep only returns the lines below

PIHOLE_DNS_1=9.9.9.10
PIHOLE_DNS_2=149.112.112.10

Looking at the web admin interface under Settings->DNS->Advanced DNS settings, the checkboxes for "Never forward non-FQDNs" and "Never forward reverse lookups for private IP ranges" ARE both selected.

9

In this case, none of your internal IP information should be leaving your network.

10

Sigh. I know that none of my internal IP information should be leaving my network based on the configuration but it was; that is why I submitted this to you. I know nothing is leaving now after I set up custom block rules. When I first updated to version 5.0 this pi-hole WAS making requests upstream for each host on my internal network that made DNS requests via it. I saw the actual DNS requests go across my firewall from the pi-hole to Q9 for XXX.0.168.192.in-addr.arpa.
This is beginning to feel adversarial and not cooperative. I've detailed for you the problem I'm seeing. Perhaps I'll find time to set up a separate test network with nothing sensitive on it and create a PCAP for you.

12

Unless there is something unusual about your Pi-hole setup, there is no need for the regex you have created. Pi-hole is based on dnsmasq (which is embedded in pihole-FTL) and the entire suite of dnsmasq commands is available. Per the dnsmasq documentation (Man page of DNSMASQ), the feature of interest is:

-b, --bogus-priv

Bogus private reverse lookups. All reverse lookups for private IP ranges (ie 192.168.x.x, etc) which are not found in /etc/hosts or the DHCP leases file are answered with "no such domain" rather than being forwarded upstream. The set of prefixes affected is the list given in RFC6303, for IPv4 and IPv6.

This is what you are toggling when you select the "Never forward reverse lookups for private IP ranges" checkbox.

If the domain is locally mapped, then Pi-hole will answer it. If the domain is not mapped, then NXDOMAIN is the return. Example - the IP in question does not exist on my network and is not mapped locally:

dig -x 192.168.0.202

; <<>> DiG 9.11.5-P4-5.1+deb10u1-Raspbian <<>> -x 192.168.0.202
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 34215
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;202.0.168.192.in-addr.arpa.	IN	PTR

;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue May 26 19:31:31 CDT 2020
;; MSG SIZE  rcvd: 55

The transaction looks like this in /var/log/pihole.log with DNS_ BOGUS_PRIV=true

May 26 19:31:31 dnsmasq[26056]: query[PTR] 202.0.168.192.in-addr.arpa from 127.0.0.1
May 26 19:31:31 dnsmasq[26056]: config 192.168.0.202 is NXDOMAIN

The request doesn't leave the network and the reply is the expected NXDOMAIN.

Similar dig for a client on my network and mapped in /etc/hosts:

dig -x 192.168.0.110 +short
SmartThings-hub.

From the pihole.log, these transactions:

May 26 19:44:58 dnsmasq[30825]: query[PTR] 110.0.168.192.in-addr.arpa from 127.0.0.1
May 26 19:44:58 dnsmasq[30825]: /etc/hosts 192.168.0.110 is SmartThings-hub

If you disable the regex you have created, do you see PTRs for local IP's leaving your network?

And what is the output of this - verifying the configuration file contents:

cat /etc/pihole/setupVars.conf

and the permissions on that file:

ls -lha /etc/pihole/setupVars.conf

13

We'll need the debug log to help you. We can ferret out information bit by bit to try and track down what may be happening, but the amount of effort that requires on our part very quickly exceeds the patience and desire to assist.

If you would like our help then you will have to give us the information to help you.

Edit: There is absolutely zero need to sanitize RFC1918 address space.

14

What I'm trying to figure out is if the web admin interface showing the checked boxes is matching the setup Vars file, and if not, why not. I don't know the configuration of your system, thus the request for the debug log and follow-up questions.

15

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.