I am curious whether it is possible to setup 2 federated instances where the traffic is explicitly only from instance A to instance B.
I am investigating whether it is possible to use a nextcloud instance on my intranet to push data to a nextcloud instance on my DMZ. The reason is that I don’t want to allow any traffic from the DMZ to the intranet.
I am in the process of testing this but I am not very hopeful after reading the logs where I get errors such as
[federation] Error: remote server not trusted (https://nextcloud.example.com) while requesting shared secret
POST /ocs/v2.php/cloud/shared-secret
from 192.168.1.25 by -- at Sep 9, 2024, 1:25:06 AM
I can have the intranet server trust the DMZ one (since it is in the public facing area) but to do the opposite I would have to break the contract of no traffic from DMZ to intranet if I am not mistaken.
Can someone please tell me that this is not possible so that I can go on about my life?
Thank you very much for your help.
That is not the purpose of a DMZ. The purpose of a DMZ is to only allow very specific traffic to very specific things, and ideally also to monitor this traffic.
In the case of Nextcloud, ideally only a web server/reverse proxy would run in the DMZ, while the backend and application services, such as database and storage servers, which hold the actual user data, and Nextcloud itself, would be behind another router/firewall in one or more separate network segments. (This can also be managed by a single router/firewall if it can manage multiple physical networks and/or VLANs)
So, assuming you are running Nextcloud as an appliance, i.e. web server, database, storage, etc. are all running on a single server, you could simply place a reverse proxy in one network segment, let’s call it the DMZ, and then expose that reverse proxy to the Internet, while placing the Nextcloud appliance in another network segment, let’s call that one the SERVER network, and then configure the firewall to only allow web traffic from the reverse proxy to the Nextcloud server.
Thanks @ernolf.
The intranet server can trust the one in the DMZ but it is not possible the other way around.
Do both servers need to trust each other for federation to work? Or can it happen if only one trusts the other if I am only interested in pushing data from the intranet to the DMZ?
Why not just make three network segements, and limit and monitor traffic between them?
CLIENT Network (Client devices like PCs, laptops…): Only allow web traffic to the Nextcloud server
SERVER Network (Nextcloud server): Only allow traffic to the internet, for updates etc.
DMZ (Reverse Proxy): expose the proxy to the internet and only allow web traffic from the reverse proxy to the Nextcloud server.
This would prevent lateral movement from the DMZ to the SERVER network, as well as lateral movement from the SERVER network to the CLIENT network.
Of course, Nextcloud itself would still be exposed to the Internet that way, but that’s what Nextcloud is designed to be, and as long as you don’t expose any other things like management interfaces or database connections etc to the DMZ or to the CLIENT network, this should be a pretty secure setup, network-wise.
I am not claiming to be an expert but having read a lot of articles on DMZ I have decided that the best use case for me is that any device on the DMZ shall not have access to any device on the intranet. There are more than ways to skin a cat and some are more secure than others.
and more complicated But that’s of course you decission to be made, and depends on your specific threat model.
A third option would be to not expose it at all, and use a VPN to access it from outside the intranet, but then you would need anorther separte solution for public shares.
Hey @devnull, appreciate the input that is the backup option. Just want to make sure that the first option is not feasible first. Was thinking more scp but yours is a good idea also.
That would be an even more complicated solution and would lead to things being out of sync and all sorts of problems. It’s also IMHO overkill just to share a few things here and there with third parties.
The main threat in an average organisation is not someone getting root access to your Nextcloud server and then moving laterally through the intranet, but the client devices and their users…
A user catches malware on their client device, which encrypts the data and then synchronises it to the Nextcloud server when the desktop client is used (can be prevented if you only use the webUI or maybe partially with virtual files)
A user exposes their credentials and the threat actor can use them to log into the Nextcloud server. In such a case, a second Nextcloud server exposed to the Internet would prevent the threat actor from accessing the first server and from there maybe other parts of the intranet, but it wouldn’t protect against data leakage if the second server also held all the data.
Also in order to move from your Nextcloud server to somewhere else on the network, they would first have to exploit one or more vulnerabilities on the Nextcloud server, and then they would have to exploit more vulnerabilities on the services they wanted to access from there on your local network. Just because they get access to one thing, they don’t have automatically acces to everything.
So while things like network segmentation, restrictive firewall rules, traffic monitoring, etc. are important, it’s also important to secure all your services on your local network in a way that you could (not should ) expose them to the Internet, because then the hackers won’t get far, even if they somehow find a way into the local network.
But again, this is not the most inherent threat of all, and if it happens, it’s much more likely to happen from one of your client devices than from your Nextcloud server.
Thanks for the discussion.
I already have a VPN from my devices to the nextcloud instance in the LAN side of my internal firewall and now I want to explore how to leverage nextcloud to be able to share files with friends and family.
I don’t care if the nextcloud server is public, that is kind of a given since I want to be able to share files with people.
What I am focusing on though is no connections possible from outside the internal firewall to inside.
As @devnull pointed out as a backup option I can use scp or rsync to copy the files from the intranet to the public nextcloud instance and then scan them into nextcloud. Before I do that though I would like to rule out the possibility of federation acting in a one-way fashion.
Initial attempts suggest that the federated instances must be able to trust each other and then nextcloud controls the information flow with the options in Federated Cloud Sharing. This is not possible in my setup without breaking my requirement of no connection initiated from DMZ to intranet.
I rewrote my previous post, to make it more clear how it is meant.
In short, I don’t think hackers using your Nextcloud server to attack other services on the intranet is the main threat you need to focus on, but your client devices, although I’d still put it in a separate network and maybe put a reverse proxy in front of it, also in its own separate network (DMZ).
The prerequisiste for a green status is that the trusted servers were maintained in both interacting Nextcloud servers. Additionally occ federation:sync-addressbooks must have been executed (part of cron job list).
So, yes, both servers need to trust each other. However, I must admit that I haven’t tried a scenario exactly like yours.
Regarding the DMZ, I’m quite familiar with the concept, and I don’t fully understand your point. A DMZ is designed—specifically for this purpose—to be accessible from both the INTRAnet and the INTERnet, while the servers located within it are isolated from accessing the INTRAnet but can reach the INTERnet. In other words, TCP connections to a server in the DMZ can be initiated from the Intranet or the Internet, but the server in the DMZ can only establish connections to the Internet and not the Intranet, because it’s typically NATed.
If you could clarify the exact purpose of your network topology—specifically, which components or subnets can or cannot be accessed from which network—I might be able to better understand and provide more specific guidance.
To stick to your rule, you shouldn’t rely on SCP. Instead, set up an NFS host in your DMZ (that can even be on the same host as your Nextcloud server). This way, you can share the same NFS data set between both your public and private Nextcloud servers. Ideally, you would configure this as “external storage” in Nextcloud. Since your Intranet server can initiate connections to the DMZ, you can control from your internal Nextcloud what data is accessible in the DMZ-based Nextcloud, without exposing your Intranet Nextcloud to the DMZ.
The DMZ should be configured so that the NFS server and its services remain invisible to the Internet.
Allowed:
Internet → Reverse Proxy in DMZ
Reverse Proxy in DMZ → Services in DMZ
Reverse Proxy in DMZ → Internet
Services in DMZ → Internet
Hosts/Services in Intranet → Reverse Proxy in DMZ
Hosts/Services in Intranet → Internet
VPN → Intranet
Blocked:
DMZ → Hosts/Services in Intranet
I have configured VPN from my phone to be able to backup data and access services inside intranet including nextcloud.
Data consists of sensitive information that I want to keep private and other data that I want to share with friends and family.
The whole point is how do I push the data from intranet to Nextcloud service in DMZ.
I have considered NFS and ruled it out mainly because I was not sure if I can configure it to be solely 1-way. scp for this matter will only push the data there is no way that a compromised nextcloud host would be able to write to a host in intranet.
Here’s another idea. You can also use the External Storage Local in your Nextcloud DMZ instance, which is an folder outside Nextcloud but on your Nextcloud DMZ instance. You could also copy the content there via SCP. However, I am afraid that you will also have to perform an occ files:scan here. But you can probably limit it to the folder maybe with --path="/path/to/local/external/storage". Not tested.
Your concept would never be used like that in the real world. My scenario here, while probably not good enough on its own in an enterprise environment where VXLANs and Software Defined Networking are taking over, is something you could implement 1:1 in an SMB.
Also if you absolutely need to run two separate Nextcloud instances, use the natively supported proticoll (WebDAV), to move the data to the external one, instead of NFS or SCP with having to run occ files:scan. That has also the advantage, that you don’t have to open any additional ports in either direction, because WebDAV runs over HTTPS.
But that’s of course you decission to be made, and depends on your specific threat model.