Secure Nextcloud Server

This article is about how to securely configure the machine where your Nextcloud/ Owncloud instance will be running.
Even if you set-up your connection with Owncloud in a secure way,  your data still can be compromised by exploiting security flaws in the underlying architecture.

In the following we specifically will cover the underlying software stack and brute-force password hacking attempts.

Automatically install security updates

No software package is perfect – there might be security holes in the the whole stack – starting with the linux kernel up to the used SSL library.
However most security holes that are being exploited are publicly known and security updates have been provided for them.
The only reason why they still can be exploited is that people do not install the security updates in time. Especially if there is no server-admin dedicated to maintaining the Owncloud machine one might easily miss on such updates.

Fortunately it is very easy to enable automatic security updates on debian based distributions with

sudo dpkg-reconfigure -plow unattended-upgrades

Starting with owncloud 8.2, there are per release package sources, so it is safe to also include owncloud itself in the unattended-upgrades. To do so add the following line to



This line follows the format "<origin>:<suite>" and is matched against the contents of /var/lib/apt/lists/.

To verify whether the origin is included as desired run:

 sudo unattended-upgrades --dry-run --debug

Prevent brute-force password hacks

Unfortunately Owncloud 9.1 is still vulnerable to brute-force password attacks in its default configuration as it does not enforce timeouts after failed login-attempts.

Therefore one might just try all possible passwords gain access to your machine in about 3 days for a typical password length:

To prevent this we can use fail2ban to enforce a timeout after a certain number of failed login attempts.

First install fail2ban

sudo apt-get install fail2ban

Fail2ban works by parsing the log files of a service and then reconfiguring the firewall in order to ban the offending ip-address.

So we need to tell owncloud to log the failed login attempts. To do so edit


  'logtimezone' => '<TIMEZONE>', // e.g. 'Europe/Berlin'
  'logfile' => '/var/log/owncloud.log',
  'loglevel' => '2'

Note that logtimezone must match the clock of your server. Furthermore the webserver user (e.g. www-data) must have write access to the logfile. To verify that logging works, do some failed logins and check /var/log/owncloud.log.

Next create the following filter definition for fail2ban


failregex={"reqId":".*","remoteAddr":"<HOST>","app":"core","message":"Login failed: .*","level":2,"time":".*"}

Together with the following service definition


enabled = true
filter  = owncloud
port    = https
logpath = /var/log/owncloud.log

Now restart fail2ban and try to log in 4 times with a wrong password. The 4th attempt should give you a timeout. (for 15min)

If you do not get the timeout you should verify that fail2ban correctly reads the log by

fail2ban-regex /var/log/owncloud.log /etc/fail2ban/filter.d/owncloud.conf