Pi-Hole - New version leaking ??
-
@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..
-
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 infoWell maybe i'we spend to much time on IP's & whois
-
@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?
-
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
-
@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?
-
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
-
@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 ;)
-
@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
-
@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
-
PI-Hole released a new version yesterday.
Seems like the fix is working.I had no "DENY's at 07.00" this morning
/Bingo