Pi-Hole - New version leaking ??

bingo600

@johnpoz said in Pi-Hole - New version leaking ??:

@bingo600 said in Pi-Hole - New version leaking ??:

Btw: My debian is a "Clean Deb10 VM" , think NTP is the only other stuff installed , besides pihole.

I run it on a pi, and really only thing installed on the thing is pihole.. So pretty sure its pihole wanting to resolve the IPs it has seen.. And not something else on the device..

One way to check would be to turn off pihole just before the hour, and see if queries are still made..

My arpa lookup's were consistant with the "Last TOP Clients"
And my bind servers.

My gut says Pi-Hole ....

If i stop Pi-Hole ... Then my Phone & MMedia vlan can't resolve.
My wife loves her Phone ...
That scares me more than a "Disaster at work" ...
She's the Boss i'm the most scared off ...

johnpoz

@bingo600 Well I was only thinking of killing it for couple of minutes - right at the hour mark.. ;)

Bob.Dig

@bingo600 said in Pi-Hole - New version leaking ??:

Wonder if someone FSCK'ed up : 127.0.0.1 vs 1.0.0.127

If I do a port test it seems not open, on 1.1.1.1 it is. So maybe it is that.

bingo600

@bob-dig said in Pi-Hole - New version leaking ??:

@bingo600 said in Pi-Hole - New version leaking ??:

Wonder if someone FSCK'ed up : 127.0.0.1 vs 1.0.0.127

If I do a port test it seems not open, on 1.1.1.1 it is. So maybe it is that.

Where did 1.1.1.1 come from ???
Do you mean another Cloudflare DNS or ??

Edit:
Ahh ... You mean 1.0.0.127:53 is not open , but 1.1.1.1 is

johnpoz

This has been corrected in the pihole software

https://github.com/pi-hole/FTL/pull/1196

Interesting issue - great documentation of the problem by @bingo600 and then clarification of it happening.. Then quick response by the pihole developers.. This is a perfect example of how quick and fast things can be tracked down when something goes wrong.. When sufficient information on exactly what is happening with proof of it happening that can be recreated by someone else..

Not related to pfsense in anyway ;) But perfect example of tacking down and fixing an issue.. Thanks @bingo600 for bringing it up here.. Win win for everyone, both pfsense users that use pihole (I think there are quite a few) and the overall pihole community as well all win with such detailed information being provided.

bingo600

@johnpoz

I just made it home to test at 14:00 CEST , and can verify the fixed version, doesn't send data to 1.0.0.127 anymore.

Yep ... Quick response from pihole maintainers.
Btw: I just asked how2 revert back to the master branch on our piholes.

I'm a bit ?? about the Cloudflare part confusing him.
I was just providing that info for pointing to the IP block owner, well maybe he never used whois ...

/Bingo

johnpoz

@bingo600 said in Pi-Hole - New version leaking ??:

I'm a bit ?? about the Cloudflare part confusing him.

hehehe - yeah, I see his point though - it wasn't really pihole asking cloudflare - it was just that the reverse of 127.0.0.1 (1.0.0.127) falls into the cloudflare public space..

If it would of been doing it with the local address 10.0.0.42 vs loopback, it would of looked like someone else ip space 42.0.0.10..

bingo600

@johnpoz

To revert pihole

pihole checkout master

And when mentioning Cloudflare i also gave the correct ip on the same line.
Pihole asking 1.0.0.127 - Cloudflare for RFC1918 arpa info

Well maybe i'we spend to much time on IP's & whois

johnpoz

@bingo600 Yeah I know how to revert - but thanks for posting that.. Did it actually make it to master already.. We can can go back to master?

bingo600

@johnpoz

Naah i doubt it's in master yet.

I would expect them to close the issue first ... Or is that me ???
I would think it was better they did it.

It's not in master yet

/Bingo

johnpoz

@bingo600 I hear yeah, and agree you did post the actual IP, etc. I got where you were coming from for sure. It was good info to provide - but possible the "cloudflare" mention got them thinking something else other than it was just reverse of 127.0.0.1

If clouldflare actually listened for dns and used that 1.0.0.127 it could of been more confusing ;) But you are correct that IP does fall to their space - and it could be leveraged on the public internet for sure.

edit: What is funny to think about is there has to be lots and lots of piholes out there - in the millions I would guess. And all of them started doing queries to 1.0.0.127? With this latest version - could of gotten the cloudflare guys scratching their heads. If they happen to notice the uptick in traffic to that IP.

Or has this been happening before, I was not blocking dns traffic on that vlan - because the only thing on that vlan is my pihole and my ntp server.. Which I directly control and setup and trust they wouldn't be trying to do doh or use some other dns that I didn't setup, etc. So I wouldn't have noticed that traffic unless it had been brought up.. So was this happening before? Or just something that came out of the lastest update to pihole?

bingo600

@johnpoz

I think Cloudflare might have lots of "interesting" traffic going to that 1.0.0.127 ip.
And that it was not a coincidence that they "just got" the /24 where "Reverse loopback was pointing".
Prob. better them than many others ...

/Bingo

johnpoz

@bingo600 yeah thinking the same thing - see the edit on my other post.

edit: To the ownership of that before nonused space - yeah prob lots of interesting traffic going to that space. 1.1.1.1 use to be a common IP to use in setting up stuff - cisco wireless even suggested if not defaulted to using that for what should of been just internal consumption, etc.

Bad practice to use non assigned space internally.. Just grabbing public space and trying to use it internally has always been bad idea, even if the space wasn't actually being used at the time.. Or you didn't think you would ever need to go to that space.. I can almost promise you there are many places using DOD space internally for their own use.. Since when would they ever need to actually go to those IPs ;)

bingo600

@johnpoz said in Pi-Hole - New version leaking ??:

So was this happening before? Or just something that came out of the lastest update to pihole?

I have never seen pihole not behave nicely before.
But in our trade the "tinfoil hat" can sometimes be a bit "heavy"
So since i knew pihole was only supposed to query my two binds's , i set up a "deny all others".

For me it started friday at 18:00 , and i had just updated pihole to latest at 17:32.

But at the same time Debian was also pulling in a few packets , so it was like hmmmm .....

Then i did a trace on pfSense , and saw the arpa adresses queried was consistant with my pihole "Top Clients" , and now it pointed at pihole.

I was 90% sure the Debian OS would not want to reverse lookup those ip's.
But i did have to check first, if i had installed bind on the pihole , and where resolv.conf was pointing (it was localhost).

When no bind , it could only have been pihole resolving for localhost.

On afterthought bind & dnsmasq would have been fighting for UDP 53 , and hopefully one of them would have "barfed" loudly in syslog.

Re: Cisco 1.1.1.1 captive portal .. Yupp would also be a good one to have.
And is has Cloudflare as owner too

/Bingo

bingo600

@johnpoz said in Pi-Hole - New version leaking ??:

I can almost promise you there are many places using DOD space internally for their own use.. Since when would they ever need to actually go to those IPs ;)

Murphy is going to bite your "behind" if you do that ...
Just wait ...

ISTR back in the oooleee days.
HP made a lot of teaching material , for their HP UX.
Where they used some of their "Public ip's" as setup examples.
I can't remember what Blok they has , it was an A.

But so many sysadms were using HP's ip addesses at their sites (100%) example , that HP refrained for using them (the ones used in examples) for public servers.

/Bingo

bingo600

@bingo600

PI-Hole released a new version yesterday.
Seems like the fix is working.

I had no "DENY's at 07.00" this morning

/Bingo