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:
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don’t control.
Beginning of January 1st 2024 this rule WILL be enforced. Posts that are not tagged will be warned and if not fixed within 24h then removed!
I have Nextcloud hosted internally in a podman container environment. To answer some of your more security related questions, here’s how I have my environment set up:
Cloudflare free tier with my own domain to proxy outside connections to the public domain name, and hide my external IP.
A DMZ proxy server with a local traefik container with only ports required to talk to the internal Nextcloud server allowed, and inbound 443 only allowed from the internet (cloudflare).
An Authelia container tied to the Nextcloud container using “Two-factor TOTP” app addon. Authelia is configured to point to a free DUO account for MFA. The TOTP addon also allows other methods of you want to bypass Authelia and use a simply Google auth or other app. I’ll be honest, this setup was a pain but it works beautifully when finally working.
Note: Using Authelia removes Nextcloud from the authentication process. If you login through Authelia, if set up correctly it will pass the user information to Nextcloud and present thier account. There is a way to have “quadruple” authentication of you really want it, where you log in through Authelia, Authelia MFA, then Nextcloud and Nextcloud MFA, but who would want that? Lol.
Another Note: If Authelia goes down for whatever reason, you can still log in through Nextcloud directly.
I have all of my containers set to automatically pull updates with the latest tag. This bites me sometimes of major changes happen, but it’s typically due to traefik or mariadb changes and not Nextcloud or Authelia.
I have my host operating system set to auto update and reboot once a week in the early morning.
My data is shared through an NFS connection from my NAS that only allows specific IPs to connect. I’d like to say I’m using least privileged permissions in the share, but it’s a wide open share as my NFS permissions are not my strong suite.
Hope the above helps!
Thanks for your answers!
Setting up auto update and reboot once a week seems smart. Do you set this up with cron?
Secure SSH. You should disable all password login capability and tighten the ciphers, KEX and MAC requirements. This will force modern SSH terminal use, something a lot of bots don’t do, so they won’t even get to the point of key exchange.
https://cipherlist.eu/
On your client, you can define an SSH config with a list of friendly host names that include direct IP addresses, the key to use to initiate login and whatever other properties you need. This way, you can just type in “ssh” and you don’t need to specify the key or IP address every time.
Finally, configure Fail2Ban to ban/block on first failed SSH attempt. You won’t be falling to login if you’ve configured a config definition file and are using keys.
Thanks for the tip. I will be looking into setting up SSH keys fairly soon, and look more into strengthening ciphers et al.
From a practical point of view, what is the likelihood of a brute-force login attempt to succeed? There are plenty of login attempts, but most of them are for root, and as I’ve disabled root-login that will fail no matter what. Other attempts are typically for generic other names such as ‘admin’, ‘user’ and ‘test’ that has no associated user on the server, as well as some weird choices that I can only imagine comes from some database breach.