The problem with a VPN is that it makes it much harder to get friends and family to use it. Not to mention if you use the link sharing feature of NextCloud, you can't just give strangers VPN access. I do use WireGuard for accessing services like SSH or NFS from the public internet, but the usability hit is a deal-breaker for my family. Client-side certificates would help solve this problem somewhat (you could whitelist only sharing-links for instance), but now you've hit usability problems again.
I mitigate code execution worries by running all of my services in individual LXD containers. They're all using isolated user namespaces (unique mappings), and are firewalled away from being able to access my internal network. The data is bind-mounted from a ZFS filesystem which is backed up by the host and uploaded to BackBlaze. The containers themselves are also snapshotted by ZFS. Thus, I think the risks of exploits being able to do much damage are greatly reduced.
However, there is still a worry about information disclosure. Yeah, NextCloud can only access the documents it manages -- but some of those documents are somewhat sensitive. I don't know what the ideal solution for this would be (a wholly separate NextCloud instance just for accessing the private stuff? But what if your family needs to access them?). My main worry when hosting NextCloud was that I am entirely trusting the safety of my NextCloud-stored data to an authentication flow that they wrote themselves in PHP (and has had pretty ugly flaws such as silently disabling 2FA or letting you bypass it by clicking "cancel".)
> The problem with a VPN is that it makes it much harder to get friends and family to use it. Not to mention if you use the link sharing feature of NextCloud, you can't just give strangers VPN access.
This is a feature. Besides, you can send friends and family a QR code to connect to your WireGuard VPN. It isn't perfect, but it beats having your personal data stolen.
I don't see how "you cannot use the link sharing feature of NextCloud" is a feature? Seems to be the precise opposite. As for setting everyone else up on the VPN, you could probably get that to work (you'd need to mess with DNS, AllowedIPs, and iptables rules to only allow port 443 access for your family's clients). I might look into that.
Sure (and I agree), but that means it's not a feature. But after reading your earlier comment, I have set nginx to only permit NextCloud traffic if I'm on the local network (I can't block everything because my personal website and Matrix homeserver need to be publicly accessible in order to function, and there's no way in hell I'm hosting my homeserver anywhere other than at home).
I'm currently serving some of my "internal" services (a wiki, a coffee tracker; things like that - nothing fancy) only from a zerotier network my devices can connect to.
Thanks to letsencrypt "now" (for some time, I know.. but I wanted to do this way before they allowed one to) allowing wildcard TLS certs, I host the above on a domain which doesn't have a single public IP DNS entry, yet has full proper "validated, browser approved" TLS cert.
IOW, I fire up my zerotier client on my phone, open brave, put the URL in, and off I go. https, and for my eyes only.
Note that in any configuration where you end up asking remote DNS servers about some particular name the operator might well be selling the list of names queried and their answers, this is called "passive DNS" and is aggregated then sold on so it isn't PII by the time it's sold (purchasers can't tell who asked, only what was asked and what the answer was)
Where people set wildcard DNS this means passive DNS reveals typos, as well as such "hidden" services. wwww.example.com and ddd.example.com are common typos for www for example whereas int-test.example.com is maybe interesting to black hats.
I've transitioned all my self-hosted services to behind a Wireguard VPN. This even includes SSH, so there are no ports exposed except the UDP port for Wireguard.
I hide mine behind letsencrypt, just dont put nextcloud.yourdomain.com but put it under a path like yourdomain.com/shortPhrase/nextcloud where shortPhrase is something like noway pizde and so on.
Lets Encrypt does not per se, but TLS does is what I mean with letsencrypt, thats why I said dont put a domain name for your nextcloud instance - because even if you get a wildcard cert, the domain names are public, and every lookup you do of your subdomain is visible to all ISPs, so even if you call it zyrkon.yourdomain.com someone can still attempt to make requests to it like /index.php?a
Put your services, on a shared domain name, only yourdomain.com and under a sub-path, like yourdomain.com/thisISAlmostLikeaPassword/nextcloud the subpath is hidden by TLS, unless you make it public by posting it on the internet. And also if you arent careful, like using google "auto-suggest" or just using any Google products, then they will at least know about your path.
Why not just add real HTTP authentication to the site instead?
One should always be wary of password-like mechanisms like secret paths, secret ports, etc. since none of these things are made to be secret, and could be disclosed by something unforeseen. (Paths, for instance, are saved in your browser history/cache, your HTTP caching proxy, if any, and also in the server’s access logs.)
Of course the site has its normal login/password, for example nextcloud has authentication.
But you see, for what we are discussing here, you could have exploited it even without authenticating, and especially it would have been easier for scanners to find it and exploit, if it was on its own domain.
Defense in depth.
For some services, yes I do basic http auth, besides their own shitty auth.
If you're worried about your ISP or people snooping on your traffic, then this scheme can be trivially defeated with a downgrade attack or looking at your address bar.
TLS hides the path from a potential attacker that could observe traffic. Putting your nextcloud instance on a nonstandard path might help in this case, but - if I read the issue correctly - not in this cases
I haven't studied the issue, but it requires to access/execute php, no?
If configuration requires a path to get further than a canned reply from nginx (403, 404, static page..), then it should reduce attack surface a lot. You should not be able to get anywhere near php without the path.
I mitigate code execution worries by running all of my services in individual LXD containers. They're all using isolated user namespaces (unique mappings), and are firewalled away from being able to access my internal network. The data is bind-mounted from a ZFS filesystem which is backed up by the host and uploaded to BackBlaze. The containers themselves are also snapshotted by ZFS. Thus, I think the risks of exploits being able to do much damage are greatly reduced.
However, there is still a worry about information disclosure. Yeah, NextCloud can only access the documents it manages -- but some of those documents are somewhat sensitive. I don't know what the ideal solution for this would be (a wholly separate NextCloud instance just for accessing the private stuff? But what if your family needs to access them?). My main worry when hosting NextCloud was that I am entirely trusting the safety of my NextCloud-stored data to an authentication flow that they wrote themselves in PHP (and has had pretty ugly flaws such as silently disabling 2FA or letting you bypass it by clicking "cancel".)