I've been self-hosting Nextcloud for sometime on Linode. At some point in the not too distant future, I plan on hosting it locally on a server in my home as I would like to save on the money I spend on hosting. I find the use of Nextcloud to suit my needs perfectly, and would like to continue using the service.
However, I am not so knowledgeable when it comes to security, and I'm not too sure whether I have done sufficient to secure my instance against potential attacks, and what additional things I should consider when moving the hosting from a VPS to my own server. So that's where I am hoping from some input from this community. Wherever it shines through that I have no idea what I'm talking about, please let me know. I have no reason to believe that I am being specifically targeted, but I do store sensitive things there that could potentially compromise my security elsewhere.
Here is the basic gist of my setup:
- My Linode account has a strong password (>20 characters, randomly generated) and I have 2FA enabled. It required security questions to set up 2FA, but the answers are all random answers that has no relation to the question themselves.
- I've disabled ssh login for root. I have instead a new user that is in the sudo usergroup with a custom name. This is also protected by a different, strong password. I imagine this makes automated brute-force attacks a lot more difficult.
- I have set up fail2ban for sshd. Default settings.
- I update the system at the latest bi-weekly.
- Nextcloud is installed with the AIO Docker container. It gets a security rating A from the Nextcloud scan, and fails on not being on the latest patch level as these are released slower for the AIO container. However, updates for the container is applied automatically, and maintaining the container is a breeze (except for a couple of problems I had early on).
- I have server-side encryption enabled. Not client-side as my impression is that the module is not working properly.
- I have daily backups with borg. These are encrypted.
- Images of the server are also daily backed up on Linode.
- It is served by an Apache web server that is exposed to outside traffic with HTTPS with DNS records handled by Cloudflare.
- I would've wanted to use a reverse proxy, but I did not figure out how to use it together with the Apache server. I have previously set up Nginx Reverse Proxy on a test server, but then I used a regular Docker image for Nextcloud, and not the AIO.
- I don't use the server to host anything else.
I may not be able to answer some of the more security-oriented questions, but one of the things I recommend is using a proxy to "hide" your home IP address. IP addresses can contain a lot of information including location data, so it's a good idea to make things harder for attackers to figure out where you live. I'm pretty sure you can do this with a basic VPS setup, but I know for sure you can do this with Cloudflare (as I have it enabled on my server).
As for getting reverse proxies set up from your Docker containers to the outside world using Apache, I can help. I use (rootless) Podman on my Raspberry Pi, meaning when I expose ports from my containers I have to choose port numbers greater than 8000. Once I have a port (let's say 8080), and a subdomain (I'll use subdomain.example.com), I just need to create a file in
/etc/apache2/sites-available/which I'll callsite.example.com.conf. The content usually looks something like this:Then you just need to enter the commands
sudo a2ensite subdomain.example.comandsudo systemctl reload apache2and you should be able to access your container as a subdomain. You should just need to forward port 80 (and 443 if you want to set up Let's Encrypt and HTTPS) on your router.Hope this helps!
Thanks for the description, I'll look closer into this and see if I can get this to work (on a test server at home first... :)).
This thread is the first I've heard of Podman - is this something I should look into in favor of Docker, or would you say it is more a case of "pick one and stick to it"?
Yeah, Podman is definitely one of those things I would say to do the latter with. It's functionality is the same as Docker though (commands work almost 1:1, and even docker-compose works with Podman), it has better integration with other system components (like automatically creating systemd services to start containers when a computer is restarted), and it gets you away from Docker as a company while still being able to access their containers on Docker Hub.
In the end though, I'd recommend sticking to what you're familiar with. It's always better to administer commands to your server that you know will work rather than learning as you go and hoping something doesn't break.