Nextcloud, Pi-hole and the default page

Have some feedback, questions, suggestions, or just fancy a chat? Pop it in here.
Post Reply
anubis
Posts: 4
Joined: Tue Dec 25, 2018 11:00 pm

Nextcloud, Pi-hole and the default page

Post by anubis » Sat Jun 29, 2019 4:37 pm

I have a pretty basic setup running on my NanoPi with DietPi 6.24.1, Nextcloud (nginx), Pi-hole, Certbot and PiVPN installed.
When using my internal IP http://192.168.x.x I get the usual Pi-hole default page
opera_yvVPRBsZ1a.png
When I use my https://subdomain.domain.tld I get this page which exposes my internal IP. It also happens with URL/pihole. Is this supposed to happen or is it a misconfiguration on my side? Can someone confirm this on his setup?
Ep21m4FpEq.png
Ep21m4FpEq.png (8.96 KiB) Viewed 1151 times

The other question is, if there is a way to set URL/nextcloud to my default page instead of Pi-hole? I've tried to change the web root to /nextcloud in the nginx config, but I couldn't get it to run without breaking Pi-hole web pages. I don't mind reverting the settings after every update as long I get my desired result ;)
Are there any news on this issue? https://github.com/MichaIng/DietPi/issues/1608
Sounds like it would be the perfect solution to my second request.
Last edited by anubis on Sun Jun 30, 2019 8:45 am, edited 2 times in total.

User avatar
MichaIng
Legend
Posts: 1588
Joined: Sat Nov 18, 2017 5:21 pm

Re: Nextcloud, Pi-hole and the default page

Post by MichaIng » Sat Jun 29, 2019 8:10 pm

@anubis
Pi-hole requires it's admin and blocking page to be related to the webroot. So if you change webroot to /nextcloud, the Pi-hole admin/blocking page sub dirs need to be at least linked from there. And in case of Nextcloud AFAIK this conflicts with their .htaccess and rewrite rules, but could be tested.
But all this is not very recommended. If you have different websites (including Pi-hole web UI) I would stay with sub directories. Also the feature request you linked would only allow this when a single webserver application is installed and be reverted when you install multiple ones. Otherwise application internal rules can conflict/break each other.

About the internal IP leak, that is indeed not intended! I will check if some some official Pi-hole webserver configs solve this that need to be added to DietPi install then, or if we need to report this to Pi-hole devs.
Actually blocking page should only be shown when calling from internal network, as also the DNS server is. External access only via VPN.

anubis
Posts: 4
Joined: Tue Dec 25, 2018 11:00 pm

Re: Nextcloud, Pi-hole and the default page

Post by anubis » Thu Jul 11, 2019 9:22 am

@MichaIng
Pi-hole requires it's admin and blocking page to be related to the webroot. So if you change webroot to /nextcloud, the Pi-hole admin/blocking page sub dirs need to be at least linked from there. And in case of Nextcloud AFAIK this conflicts with their .htaccess and rewrite rules, but could be tested.
Could you please give me a hint how the link to the Pi-hole sub dirs is supposed to look like?
About the internal IP leak, that is indeed not intended! I will check if some some official Pi-hole webserver configs solve this that need to be added to DietPi install then, or if we need to report this to Pi-hole devs.
Actually blocking page should only be shown when calling from internal network, as also the DNS server is. External access only via VPN.
Did you manage to prevent the IP from leaking with additional configs?

Please let me know if there's a need for logs or configs from my setup.

User avatar
MichaIng
Legend
Posts: 1588
Joined: Sat Nov 18, 2017 5:21 pm

Re: Nextcloud, Pi-hole and the default page

Post by MichaIng » Wed Jul 24, 2019 7:36 pm

@anubis
Sorry for the late reply.

I could actually not replicate the IP leak. When installing Pi-hole with Nginx (and any other webserver), accessing either plain IP/URL or with /pihole URI, i am presented with a simple html page that allows me to head over to admin panel. Page source:

Code: Select all

    <html><head>
        <meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1"/>
        <link rel='stylesheet' href='/pihole/blockingpage.css' type='text/css'/>
    </head><body id='splashpage'><img src='/admin/img/logo.svg'/><br/>Pi-<b>hole</b>: Your black hole for Internet advertisements<br><a href='/admin'>Did you mean to go to the admin panel?</a></body></html>
So not containing any IP or other unwanted info.

The Pi-hole admin page as well does not contain any further info (when not logged in), besides version strings of Pi-hole itself, the machines hostname (not IP) and blocklist/query stats.

The plain page that you were facing above actually looks like PHP is not working properly, thus the PHP file is presented/called as plain HTML.
Check out for errors:

Code: Select all

systemctl status php7.3-fpm
journalctl -u php7.3-fpm


However when you want webroot at /nextcloud, it is anyway not available, since this requires a special index.php file in webroot, but Nextcloud has its own.
Disable the blocking page Pi-hole side:

Code: Select all

G_CONFIG_INJECT 'BLOCKINGMODE=' 'BLOCKINGMODE=NULL' /etc/pihole/pihole-FTL.conf
systemctl restart pihole-FTL
This is faster anyway, requests are immediately nulled instead of being forwarded again. I don't not much use cases where the blocking page would be helpful. Any whitelisting etc anyway requires login and I would simply do this manually from admin panel instead of via blocking page.

Okay just tried to achieve the /nextcloud webroot + Pi-hole admin panel. Was able to get it working, but the issue is that the whole dietpi-nextcloud.conf needs to be adjusted.

First the admin panel symlink:

Code: Select all

ln -s /var/www/html/admin /var/www/nextcloud/admin
To adjust dietpi-nextcloud.conf Nginx config, so it applies to webroot instead of /nextcloud subpath, do the following:

Code: Select all

mv /etc/nginx/sites-dietpi/dietpi-nextcloud.conf /etc/nginx/sites-dietpi/dietpi-nextcloud.conf.bak
sed -Ei 's|/nextcloud\\?/?|/|' /etc/nginx/sites-dietpi/dietpi-nextcloud.conf
Also CLI URL must be adjusted:

Code: Select all

sed -i 's|localhost/nextcloud|localhost|' /var/www/nextcloud/config/config.php
And finally to remove doubled location match and instead override Nextcloud location rules for the Pi-hole admin panel URIs:
In /etc/nginx/sites-available/default and the related HTTPS/SSL config (currently not sure about SSL/HTTPS config file that CertBot creates there, or you created manually)
Replace "location / {" with "location /admin {"
and "location ~ \.php(?:$|/) {" with "location ~ ^/admin/.+\.php(?:$|/) {"

With the above I got it working.

anubis
Posts: 4
Joined: Tue Dec 25, 2018 11:00 pm

Re: Nextcloud, Pi-hole and the default page

Post by anubis » Mon Jul 29, 2019 10:17 am

@MichaIng
Thanks for taking the time to investigate this weird issue I am dealing with.
I've checked for errors, but couldn't find anything useful to narrow it down.
Looks like I'll have to install my setup from scratch.
Thanks again for the webroot adjustments!

krtpowa
Posts: 7
Joined: Wed Jan 31, 2018 12:10 am
Location: Spain

Re: Nextcloud, Pi-hole and the default page

Post by krtpowa » Thu Aug 01, 2019 12:37 am

anubis wrote:
Sat Jun 29, 2019 4:37 pm
I have a pretty basic setup running on my NanoPi with DietPi 6.24.1, Nextcloud (nginx), Pi-hole, Certbot and PiVPN installed.
When using my internal IP http://192.168.x.x I get the usual Pi-hole default page opera_yvVPRBsZ1a.png
When I use my https://subdomain.domain.tld I get this page which exposes my internal IP. It also happens with URL/pihole. Is this supposed to happen or is it a misconfiguration on my side? Can someone confirm this on his setup?
Ep21m4FpEq.png


The other question is, if there is a way to set URL/nextcloud to my default page instead of Pi-hole? I've tried to change the web root to /nextcloud in the nginx config, but I couldn't get it to run without breaking Pi-hole web pages. I don't mind reverting the settings after every update as long I get my desired result ;)
Are there any news on this issue? https://github.com/MichaIng/DietPi/issues/1608
Sounds like it would be the perfect solution to my second request.
Hello, first of all, sorry for my bad English
I had the same problem, in fact I use almost the same as you.
You have to modify the configuration of lighttpd, at least I am the one I use.
Since it is your Web server, and it exposes everything you have to the internet, within lighttpd it is / admin (pi-hole) and / nextcloud
this is inside / var / www
Go to / etc / lighttpd
and modify the lighttpd.conf file (first make a copy with "cp")
server.modules = (
"mod_access",
"mod_accesslog",
"mod_auth",
"mod_expire",
"mod_compress",
"mod_redirect",
"mod_setenv",
"mod_rewrite"
)

server.document-root = "/var/www"
server.error-handler-404 = "pihole/index.php"
server.upload-dirs = ( "/var/cache/lighttpd/uploads" )
server.errorlog = "/var/log/lighttpd/error.log"
server.pid-file = "/var/run/lighttpd.pid"
server.username = "www-data"
server.groupname = "www-data"
server.port = 80
accesslog.filename = "/var/log/lighttpd/access.log"
accesslog.format = "%{%s}t|%V|%r|%s|%b"


index-file.names = ( "index.php", "index.html" )
url.access-deny = ( "~", ".inc")

# deny access to /raiz lighttpd
$HTTP["remoteip"] !~ "192.168.2.*" {
$HTTP["url"] =~ "" {
url.access-deny = ("apc.php", "opcache.php", "phpinfo.php", "index.html" )
}
}

# deny access to /admin Pihole
$HTTP["remoteip"] !~ "192.168.2.*" {
$HTTP["url"] =~ "^/admin/" {
url.access-deny = ( "" )
}
}
# deny access to /html
$HTTP["remoteip"] !~ "192.168.2.*" {
$HTTP["url"] =~ "^/html/" {
url.access-deny = ( "" )
}
}
# deny access to /Pihole
$HTTP["remoteip"] !~ "192.168.2.*" {
$HTTP["url"] =~ "^/pihole/" {
url.access-deny = ( "" )
}
}
# deny access to /cgi-bin
$HTTP["remoteip"] !~ "192.168.2.*" {
$HTTP["url"] =~ "^/cgi-bin/" {
url.access-deny = ( "" )
}
}
static-file.exclude-extensions = ( ".php", ".pl", ".fcgi" )

compress.cache-dir = "/var/cache/lighttpd/compress/"
compress.filetype = ( "application/javascript", "text/css", "text/html", "text/plain" )

# default listening port for IPv6 falls back to the IPv4 port
include_shell "/usr/share/lighttpd/use-ipv6.pl " + server.port
include_shell "/usr/share/lighttpd/create-mime.assign.pl"

# Prevent Lighttpd from enabling Let's Encrypt SSL for every blocked domain
#include_shell "/usr/share/lighttpd/include-conf-enabled.pl"
include_shell "find /etc/lighttpd/conf-enabled -name '*.conf' -a ! -name 'letsencrypt.conf' -printf 'include \"%p\"\n' 2>/dev/null"

# If the URL starts with /admin, it is the Web interface
$HTTP["url"] =~ "^/admin/" {
# Create a response header for debugging using curl -I
setenv.add-response-header = (
"X-Pi-hole" => "The Pi-hole Web interface is working!",
"X-Frame-Options" => "DENY"
)

$HTTP["url"] =~ ".ttf$" {
# Allow Block Page access to local fonts
setenv.add-response-header = ( "Access-Control-Allow-Origin" => "*" )
}
}

# Block . files from being served, such as .git, .github, .gitignore
$HTTP["url"] =~ "^/admin/\.(.*)" {
url.access-deny = ("")
}

# Add user chosen options held in external file
# This uses include_shell instead of an include wildcard for compatibility
include_shell "cat external.conf 2>/dev/null"
This is my configuration file modified by me, my internal network is 192.168.2.X modifies if yours is different
With this config, you access the Internet only to Nextcloud, the rest denies
But from local network it allows access to everything (Pi-hole etc)

User avatar
MichaIng
Legend
Posts: 1588
Joined: Sat Nov 18, 2017 5:21 pm

Re: Nextcloud, Pi-hole and the default page

Post by MichaIng » Thu Aug 01, 2019 9:06 pm

@krtpowa
Thanks for providing this. I am actually wondering if there is a "does not match" syntax to exclude every URI (block for non-local access) that does not match /nextcloud in this case.
Ah: $HTTP["url"] !~ "^/nextcloud" should do it.

Why not merging all the checks into a single remote IP block? E.g.

Code: Select all

$HTTP["remoteip"] !~ "192.168.2.*" {
  # deny access to /admin Pihole
  $HTTP["url"] =~ "^/admin/" {
    url.access-deny = ( "" )
  }
  # deny access to /html
  $HTTP["url"] =~ "^/html/" {
    url.access-deny = ( "" )
  }
  # deny access to /Pihole
  $HTTP["url"] =~ "^/pihole/" {
    url.access-deny = ( "" )
  }
# ... etc
}
Or with above:

Code: Select all

$HTTP["remoteip"] !~ "192.168.2.*" {
   # Deny access to all by Nextcloud
   $HTTP["url"] !~ "^/nextcloud" {
     url.access-deny = ( "" )
  }
}
Aside from that, generally it makes sense to grant access to Pi-hole, at least to the blocking page, to the local network only. One anyway would never want to open the DNS server to the web, so the blocking page has no use there as well, besides possible leaking information about the server.
We'll probably add this to all webserver configs by default when installing Pi-hole.

krtpowa
Posts: 7
Joined: Wed Jan 31, 2018 12:10 am
Location: Spain

Re: Nextcloud, Pi-hole and the default page

Post by krtpowa » Thu Aug 01, 2019 11:00 pm

MichaIng wrote:
Thu Aug 01, 2019 9:06 pm
@krtpowa
Thanks for providing this. I am actually wondering if there is a "does not match" syntax to exclude every URI (block for non-local access) that does not match /nextcloud in this case.
Ah: $HTTP["url"] !~ "^/nextcloud" should do it.

Why not merging all the checks into a single remote IP block? E.g.

Code: Select all

$HTTP["remoteip"] !~ "192.168.2.*" {
  # deny access to /admin Pihole
  $HTTP["url"] =~ "^/admin/" {
    url.access-deny = ( "" )
  }
  # deny access to /html
  $HTTP["url"] =~ "^/html/" {
    url.access-deny = ( "" )
  }
  # deny access to /Pihole
  $HTTP["url"] =~ "^/pihole/" {
    url.access-deny = ( "" )
  }
# ... etc
}
Or with above:

Code: Select all

$HTTP["remoteip"] !~ "192.168.2.*" {
   # Deny access to all by Nextcloud
   $HTTP["url"] !~ "^/nextcloud" {
     url.access-deny = ( "" )
  }
}
Aside from that, generally it makes sense to grant access to Pi-hole, at least to the blocking page, to the local network only. One anyway would never want to open the DNS server to the web, so the blocking page has no use there as well, besides possible leaking information about the server.
We'll probably add this to all webserver configs by default when installing Pi-hole.
That would be great, it is true that it would be much more comfortable preventing access to everything that "does not match" with / nextcloud, or whatever you want to configure.
I did it this way because I was learning to modify this file and I was testing, at the time it worked, I left it.
But if what you put there works is much better, I don't have to be blocking file by file or directories.
I will try it! cool

krtpowa
Posts: 7
Joined: Wed Jan 31, 2018 12:10 am
Location: Spain

Re: Nextcloud, Pi-hole and the default page

Post by krtpowa » Sun Aug 11, 2019 2:10 am

I just tried it, it works perfectly!!

Code: Select all

$HTTP["remoteip"] !~ "192.168.2.*" {
   # Deny access to all by Nextcloud
   $HTTP["url"] !~ "^/nextcloud" {
     url.access-deny = ( "" )
  }
}

User avatar
MichaIng
Legend
Posts: 1588
Joined: Sat Nov 18, 2017 5:21 pm

Re: Nextcloud, Pi-hole and the default page

Post by MichaIng » Tue Aug 13, 2019 1:16 pm

@krtpowa @anubis
We're about to implement a solution to block the Pi-hole blocking page by default for non-local access: https://github.com/MichaIng/DietPi/pull/3054
This makes sense since no one would ever share ones local Pi-hole DNS to the public www, although would be cool to have a public DNS with Pi-hole integrated :P. And without having something blocked by this Pi-hole instance, the blocking page has no meaning, thus denying access totally makes sense to prevent any possible information leak.

The question is now if we should do the same for the admin page:
- Block it by default for remote access? Or keep it possible to monitor/administer your Pi-hole instance from remote networks as well?
- Give a choice during install process? The Pi-hole installer anyway asks a lot of question, so one more does not hurt much?

The block is implemented a way that all client IPs have access, that match the address ranges that are reserved for local networks. This means also VPN clients and otherwise directly connected local networks have access, which is important of course.

We are thinking of allowing this for local IPv6 networks as well, but I doubt that anyone has an IPv6-only local network, meaning having only IPv6 addresses assigned and using them to connect to devices within the local network?
Otherwise it is not too hard to add those Link Local Unicast and Unique Local Unicast address ranges to the pattern, after all. There is just still to possibility to access individual local devices via external IPv6 prefix+internal address, so the device will receive the external prefix as well as remote IP, thus block access. Not sure if there is any reasonable way to check this, but there is really no point in accessing local deices by their external IPv6 address from within the local network anyway...

Post Reply