Hi, finally setting up Nextcloud in an effort to de-Google myself and replace GDrive for good.
I am currently running Nextcloud via Tailscale and that works fine except for when i want to share a file to someone outside of my Tailnet. I have heard of federated Nextcloud but i am not sure that i quite understood the purpose of this or maybe there is a better solution? If i run two instances like that, will i simply be able to share certain files over to that instance for sharing?
Here is my security point of view. Second instance would be too much overhead for just one use case of sharing file. You have to decide how comfortable you are with exposing anything in your private network. I would personally not expose Nextcloud instance because it’s complex application with many modules each possibly having 0day exploits. If your goal is to share a file and selfhost I would look into dedicated apps for that purpose. You can setup simple microbin/privatebin on dedicated hardware in DMZ network behind firewall. You should run IDS/IPS on your open ports (pfsense/opnsense have that nicely pairs with crowdsec). You could also look into cloud fare tunnels to expose your dedicated file sharing app but I would still use as much isolation as possibilities (ideally phisical hardware) so that it would be not easy to compromise your local network in event of breach. Regardless selfhosted solution will always pose risks and management overhead if you want to run a tight setup. It’s much easier to use public cloud solution. For example proton drive is encrypted and you can share files via links with people.
Thanks, did not occur to me to use a dedicated app for that purpose! Will check that out.
Thread parent’s approach is what I would use as well. It makes lot of sense to isolate something as sprawling and with as large an attack surface as nextcloud… but that implies you can’t use it for public sharing. Any use that that DOES involve public sharing creates an incentive to choose a smaller and more auditable codebase (not that you’ll necessarily audit it yourself, but simplicity does have benefits here).
Another approach I’ve used with semi-public services is to stick them behind a proxy I trust like Caddy or nginx and gate access to them with https basic auth. Basic auth rightfully gets dismissed in many security contexts, but in the case of personal self-hosting it can serve a useful purpose. The proxy handles the basic auth, and no network packets can reach the protected application until basic auth is complete, which completely protects against unathenticated exploits in the protected application (though obviously exploits against the proxy would still work, but major proxies are pretty well hardened). The major downside here is that you can’t really use mobile apps, as none of them support this niche and frankly dubious approach to network access control. But for public sharing, you’re almost certainly having folks use a browser as their client rather than an app, and for the small convenience overhead of the basicauth login you get a pretty significant reduction in unauthenticated attack surface. The app limitation again makes this a poor match for Nextcloud, but a good match for a standalone public filesharing system that you don’t quite trust as much as your proxy.
Edit: If you want to get fancy you could even expose the same Nextcloud instance BOTH via tailscale for your own app use behind a basicauth proxy for semi-public sharing. It gets network protection in both cases, but basicauth is sort of kind of easy enough to grant semi-public access to.