Re: RPi 4 | pihole web interface forbidden
Post by MichaIng » Fri Dec 06, 2019 5:53 pm
@dima
Glad you found it. X-Frame-Options: DENY is just a security header which denies to add the web page as frame into another website. But the direct access is not affected by this.
Yeah we check for local IP by comparing with the pattern for reserved local IPs. Using any other IPs for local networks means that you break access to those on www, hence there is high likely a host out there that you cannot reach anymore, since you local LAN host duplicates it and takes priority probably from within local network > > . Always use 192.168./10. or 172.[16 to 31].* for local networks, the first pattern is most common. 10.* is mostly found for VPNs, 127.* btw. is reserved/resolved as loopback to the localhost itself.
Any way to stop DietPi from doing this? I’m not sure it needs to be done and is restrictive for no real reason?
“Hardcoded” is probably a bid too “hard”. Of course the config can be changed or overwritten with a custom file. Nathanio Which webserver do you use?
But actually we block public access to the blocking page only, which you should usually not enable, since it only works on non-HTTPS content anyway, which should not be much (hopefully) anymore nowadays. And since one usually does not want to make the private DNS resolver public to www, the blocking page has no meaning there and has been reported as info leak only (although I actually wanted to verify that with current Pi-hole 5.1).
The admin panel is by default not blocked. You are asked interactively (if not installed automated) if you want that and commands are provided to switch the choice.
On Apache:
a2ensite dietpi-pihole-block_public_admin # block
a2dissite dietpi-pihole-block_public_admin # unblock
systemctl reload apache2 # afterwards to load the change
On Nginx:
mv /etc/nginx/sites-dietpi/dietpi-pihole-block_public_admin.{off,on} # block
mv /etc/nginx/sites-dietpi/dietpi-pihole-block_public_admin.{on,off} # unblock
systemctl reload nginx # afterwards to load the changes
On Lighttpd:
lighty-enable-mod dietpi-pihole-block_public_admin # block
lighty-disable-mod dietpi-pihole-block_public_admin # unblock
systemctl reload lighttpd # afterwards to load the changes
But really, you should not use public IP ranges for your private network. Not only will you not be able to access the resources behind those IP, but also I’m not sure how network programs handle incoming requests from those hosts if the IP range is by netmask taken as the local network. Information might be leaked or access granted that you never wanted. E.g. Pi-hole/dnsmasq has this feature to allow DNS requests from all origins or only local network (“at most one hop away”) and the question is how this is checked. I was digging into it once for another reason but forget the details . But in theory when the local network member is derived from the own IP + netmask/CIDR then those public hosts will have access to your Pi-hole.
Yes yes, the chance that one of this relatively small share of hosts tries to access your server may be small, same for the outgoing broken requests, but why accepting this potential issues and security risks when you can simply (?) switch to a range that never any public host can have?
> . Always use 192.168./10. or 172.[16 to 31].* for local networks, the first pattern is most common. 10.* is mostly found for VPNs, 127.* btw. is reserved/resolved as loopback to the localhost itself.
. But in theory when the local network member is derived from the own IP + netmask/CIDR then those public hosts will have access to your Pi-hole.