Install an ownCloud server

ownCloud is a platform that acts as a cloud storage. You can freely deploy your own because ownCloud is open source. Through this article we will see how to deploy a hardened ownCloud instance. To do this we will use full SELinux support (and not disable it as everyone else does), use sockets for Redis and MariaDB instead of TCP ports.

It is essential to have a highly secure instance because you will potentially be uploading sensitive or confidential files. I would be surprised if you don’t have a problem if these files leak.

Information and requirements

These elements are to be taken into consideration to follow this article:

The manipulations are carried out on Rocky Linux 8.
Throughout this post, we will access the ownCloud server via its domain name owncloud.local which is related to its local IP address.
In some snippets of code, the domain name owncloud.domain.fr must be replaced by the one you assigned to your public ownCloud server.

Update the system

[operator@owncloud ~]$ sudo dnf -y update

Install PHP

Install Remi’s RPM repository

[operator@owncloud ~]$ sudo dnf -y install https://rpms.remirepo.net/enterprise/remi-release-8.rpm

Enable PHP 7.4 module

[operator@owncloud ~]$ sudo dnf -y module enable php:remi-7.4

Install required packages

They are all necessary for the smooth running of the installation.

[operator@owncloud ~]$ sudo dnf -y install tar bzip2 httpd firewalld vim mod_ssl redis php php-common php-pdo unzip php-pecl-zip php-xml php-intl php-mbstring php-gd php-pgsql php-process php-pecl-redis5 php-pecl-apcu policycoreutils-python-utils setroubleshoot-server

Install PostgreSQL

Install the RPM repository

[operator@owncloud ~]$ sudo dnf -y install https://download.postgresql.org/pub/repos/yum/reporpms/EL-8-x86_64/pgdg-redhat-repo-latest.noarch.rpm

Disable the built-in PostgreSQL module

[operator@owncloud ~]$ sudo dnf -y module disable postgresql

Install PostgreSQL

[operator@owncloud ~]$ sudo dnf -y install postgresql14-server

Initialize database

[operator@owncloud ~]$ sudo /usr/pgsql-14/bin/postgresql-14-setup initdb
Initializing database ... OK

Enable and start PostgreSQL service

[operator@owncloud ~]$ sudo systemctl enable --now postgresql-14

Configure database

Create role

Choose a strong password for role owncloud. You can generate a strong password (here 40 characters but you can increase its size) with the following statement.

Note: /dev/urandom and /dev/random are using the exact same CSPRNG (Cryptographically Secure PseudoRandom Number Generator).

[operator@owncloud ~]$ tr -cd "[:alnum:]" < /dev/urandom | fold -w 39 | head -n 1

[operator@owncloud ~]$ sudo -iu postgres
[postgres@owncloud ~]$ createuser -sdRP owncloud
Enter password for new role:
Enter it again:

Create the database

[postgres@owncloud ~]$ createdb -O owncloud ownclouddb
[postgres@owncloud ~]$ exit
logout

Test the connection

[operator@owncloud ~]$ psql -h localhost -U owncloud ownclouddb
Password for user owncloud:

If you see the following text, you have succeeded!

psql (14.5)
Type "help" for help.

ownclouddb=#

HTTPD configurations

General TLS configurations

By adding ServerTokens Prod directive, you remove the Apache2 version from HTTP headers, it’s a good practice for security reasons.

[operator@owncloud ~]$ sudo sed -i "352i ServerTokens Prod" /etc/httpd/conf/httpd.conf

Any valid directive in the .htaccess context will be allowed in .htaccess files.

[operator@owncloud ~]$ sudo sed -i "128s/AllowOverride None/AllowOverride All/" /etc/httpd/conf/httpd.conf

If you want to access to ownCloud server without adding /owncloud at the end of the domain name, you should do the following thing.

[operator@owncloud ~]$ sudo sed -i "123i Alias \"/\" \"/var/www/owncloud/\"" /etc/httpd/conf/httpd.conf

Add these headers and the cache configuration for OCSP stapling just after #SSLCryptoDevice ubsec into /etc/httpd/conf.d/ssl.conf. Also, set the Diffie-Hellman parameters’ path and the temporary curve used for ephemeral ECDH modes.

# Headers
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
Header always set X-Frame-Options DENY
Header always set X-Content-Type-Options nosniff
Header always set Referrer-Policy no-referrer

# OCSP stapling
SSLStaplingCache "shmcb:logs/ssl_stapling(32768)"

# Key exchange
SSLOpenSSLConfCmd DHParameters "/etc/pki/tls/private/dhparam.pem"
SSLOpenSSLConfCmd Curves secp384r1

Next, you must generate the Diffie-Hellman’s parameters. Here, the size of the generated parameters set will be 4096 bits.

[operator@owncloud ~]$ sudo openssl dhparam -check -out /etc/pki/tls/private/dhparam.pem -rand /dev/urandom 4096
DH parameters appear to be ok.

Set correct permissions.

[operator@owncloud ~]$ sudo chmod 440 /etc/pki/tls/private/dhparam.pem

Disable TLS session tickets and enable the addition of OCSP responses to TLS negociation.

[operator@owncloud ~]$ sudo sed -i "214i SSLSessionTickets Off" /etc/httpd/conf.d/ssl.conf
[operator@owncloud ~]$ sudo sed -i "215i SSLUseStapling On" /etc/httpd/conf.d/ssl.conf

Accept all protocols except those before TLSv1.2.

[operator@owncloud ~]$ sudo sed -i "s/#SSLProtocol.*/SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1/" /etc/httpd/conf.d/ssl.conf

Generate TLS certificate (local server only)

Generate the CA private key

Generate a private key for a curve. Here, I use the curve secp521r1 but you can use another one by executing openssl ecparam -list_curves.

[operator@owncloud ~]$ sudo openssl ecparam -check -name secp521r1 -genkey -noout -out /etc/pki/tls/private/CAkey.pem -rand /dev/urandom
checking elliptic curve parameters: ok

Generate the CA certificate

The CA root certificate will have 3650 days (10 years lifetime).

[operator@owncloud ~]$ sudo openssl req -utf8 -new -x509 -days 3650 -key /etc/pki/tls/private/CAkey.pem -out /etc/pki/tls/certs/CAcert.pem -rand /dev/urandom -subj "/CN=ownCloud root CA/"

Generate ownCloud private key

Generate a private key for a curve. Here, I use the curve secp384r1 but you can use another one by executing openssl ecparam -list_curves.

[operator@owncloud ~]$ sudo openssl ecparam -check -name secp384r1 -genkey -noout -out /etc/pki/tls/private/privkey.pem -rand /dev/urandom
checking elliptic curve parameters: ok

Create a dedicated OpenSSL configuration file

Copy the following content in a file called openssl.cnf. In CN = and DNS.1 =, be sure to put the Gitea domain name, heere owncloud.local.

[req]
distinguished_name = req_distinguished_name
req_extensions = req_ext
prompt = no

[req_distinguished_name]
CN = owncloud.local

[req_ext]
subjectAltName = @alt_names

[alt_names]
DNS.1 = owncloud.local

Generate CSR based on the OpenSSL configuration file

[operator@owncloud ~]$ sudo openssl req -new -key /etc/pki/tls/private/privkey.pem -out /tmp/owncloud.local.csr -rand /dev/urandom -config openssl.cnf

Generate the X.509 certificate with SAN

Certificate will have 365 days (1 year lifetime).

[operator@owncloud ~]$ sudo openssl x509 -req -days 365 -in /tmp/owncloud.local.csr -CA /etc/pki/tls/certs/CAcert.pem -CAkey /etc/pki/tls/private/CAkey.pem -CAcreateserial -out /etc/pki/tls/certs/owncloud.local.pem -rand /dev/urandom -extensions req_ext -extfile openssl.cnf
Signature ok
subject=CN = owncloud.local
Getting CA Private Key

Check the SAN extension

[operator@gitea ~]$ openssl x509 -in /etc/pki/tls/certs/owncloud.local.pem -noout -ext subjectAltName
X509v3 Subject Alternative Name:
    DNS:owncloud.local

Don’t forget to add the CA root certificate to your certificate store so that the certificate linked to the owncloud.local domain name is validateur without error. You can retrieve it via this command.

[operator@owncloud ~]$ cat /etc/pki/tls/certs/CAcert.pem

This command should return something like this.

Copy this text and paste it in a file named CAcert.pem, this is the file you have to import in your trust store.

Set correct permissions

[operator@owncloud ~]$ sudo chmod 440 /etc/pki/tls/private/CAkey.pem
[operator@owncloud ~]$ sudo chmod 644 /etc/pki/tls/certs/CAcert.pem
[operator@owncloud ~]$ sudo chmod 440 /etc/pki/tls/private/privkey.pem
[operator@owncloud ~]$ sudo chmod 644 /etc/pki/tls/certs/owncloud.local.pem

Virtual host configuration

Create the reverse proxy configuration into /etc/httpd/conf.d/vhost.conf.

<VirtualHost *:80>
    ServerName 192.168.2.75
    Redirect permanent / https://owncloud.local
</VirtualHost>

<VirtualHost *:443>
    ServerName 192.168.2.75
    Redirect permanent / https://owncloud.local
</VirtualHost>

<VirtualHost *:443>
    ServerName owncloud.local:443
    ServerAlias owncloud.local
    ServerAdmin contact@owncloud.local

    SSLCertificateFile /etc/pki/tls/certs/owncloud.local.pem
    SSLCertificateKeyFile /etc/pki/tls/private/privkey.pem
    SSLCACertificateFile /etc/pki/tls/certs/CAcert.pem

    Protocols h2 http/1.1

    ErrorLog /var/log/owncloud/error_log
    CustomLog /var/log/owncloud/access_log combined
</VirtualHost>

Request a Let’s Encrypt certificate (public server only)

In case you wish to obtain free certificates (via Let’s Encrypt), two methods are available to you. Luck is on your side, you will find here the method to obtain a certificate from Let’s Encrypt, and here a slightly more advanced method that allows you to obtain a certificate based on elliptic curve cryptography (still via Let’s Encrypt).

The reverse proxy configuration is the exact same. Things you have to modify are the location of the certificate, private key and the chain of trust, but it is documented in the article previously mentionned.

Create the logs directory

[operator@owncloud ~]$ sudo mkdir -p /var/log/owncloud

Edit the PHP configuration

By modifying this line, you remove the PHP version from HTTP headers, it’s a good practice for security reasons.

[operator@owncloud ~]$ sudo sed -i "s/expose_php = On/expose_php = Off/" /etc/php.ini

Download ownCloud

You can check the latest version here.

[operator@owncloud ~]$ curl -LOsSf https://download.owncloud.org/community/owncloud-complete-20220112.tar.bz2

Extract ownCloud’s files

[operator@owncloud ~]$ sudo tar -jxf owncloud-complete-20220112.tar.bz2 -C /var/www/
[operator@owncloud ~]$ rm -f owncloud-complete-20220112.tar.bz2

Set rights

[operator@owncloud ~]$ sudo chown -R apache: /var/www/owncloud

Edit the Redis configuration

Configure a Redis password enables one of its two built-in security features, the AUTH command, which requires clients to authenticate to access the database. With this command, you generate a random password with a size of 150 characters and insert it in the Redis’ configuration file.

[operator@owncloud ~]$ sudo sed -i "s/# requirepass foobared/requirepass $(tr -cd "[:alnum:]" < /dev/urandom | fold -w 149 | head -n1 | sed "s/ .*$//")/" /etc/redis.conf

Unix sockets operate at a lower level OSI model layer than TCP sockets so they should be faster. Moreover, it adds an extra level of security.

[operator@owncloud ~]$ sudo sed -i "s/# unixsocket \/tmp\/redis.sock/unixsocket \/run\/redis\/redis.sock/" /etc/redis.conf

Set the correction permission for the socket file.

[operator@owncloud ~]$ sudo sed -i "s/# unixsocketperm 700/unixsocketperm 770/" /etc/redis.conf

If port 0 is specified Redis will not listen on a TCP socket, so it will not be possible to exchange with it via its port. This is not a problem because we have just seen that we will communicate with it via a socket.

[operator@owncloud ~]$ sudo sed -i "s/port 6379/port 0/" /etc/redis.conf

Group modification

Add the user apache to the group redis to avoid permission issue regarding the socket I/O. In order to apply group modification, you have to log out (and login again) to reload rights.

[operator@owncloud ~]$ sudo gpasswd -a apache redis
[operator@owncloud ~]$ exit

Enable and start Redis service

[operator@owncloud ~]$ sudo systemctl enable --now redis

Check if Redis is listening

As you can see, port 6379 is no longer in listening mode.

[operator@owncloud ~]$ ss -ltup | grep redis

Flush Redis database

Make sure to put the generated Redis password after the AUTH keyword. You can retrieve it with this command: sudo grep ^requirepass /etc/redis.conf.

[operator@owncloud ~]$ sudo redis-cli -s /run/redis/redis.sock
AUTH cEoQNyT5R...
SELECT 0
FLUSHDB
QUIT

Set the SELinux context

[operator@owncloud ~]$ sudo semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/owncloud/config(/.*)?"
[operator@owncloud ~]$ sudo semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/owncloud/apps(/.*)?"
[operator@owncloud ~]$ sudo semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/owncloud/apps-external(/.*)?"
[operator@owncloud ~]$ sudo semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/owncloud/data(/.*)?"
[operator@owncloud ~]$ sudo semanage fcontext -a -t httpd_sys_rw_content_t /var/www/owncloud/.htaccess
[operator@owncloud ~]$ sudo semanage fcontext -a -t httpd_sys_rw_content_t /var/www/owncloud/.user.ini
[operator@owncloud ~]$ sudo restorecon -Rv /var/www/owncloud/

Install ownCloud

You can simply install your ownCloud instance by running the following command. Note that the administrator user will be named by the value of the --admin-user flag. Change the values of the different flags to fit you your needed.

You will be asked for the owncloud user and administrator passwords.

[operator@owncloud ~]$ sudo -u apache php /var/www/owncloud/occ maintenance:install --database pgsql --database-name "ownclouddb" --database-user "owncloud" --admin-user "root"
What is the password to access the database with user <owncloud>?
What is the password you like to use for the admin account <root>?
ownCloud was successfully installed

Add the ownCloud URL inside the trusted domains

Add the ownCloud instance URL inside the trusted_domains array to be able to access it, otherwise you will get an error.

[operator@owncloud ~]$ sudo -u apache php /var/www/owncloud/occ config:system:set trusted_domains 0 --value owncloud.local
System config value trusted_domains => 0 set to string owncloud.local

Configure Redis

Add the following content at the end of /var/www/owncloud/config/config.php and make sure to put the generated Redis password. You can retrieve it with this command: sudo grep ^requirepass /etc/redis.conf.

'memcache.local' => '\OC\Memcache\Redis',
'memcache.locking' => '\OC\Memcache\Redis',
'redis' =>
array(
        'host' => '/run/redis/redis.sock',
	'port' => 0,
	'timeout' => 0,
	'password' => 'cEoQNyT5R...',
	'dbindex' => 0
)

SELinux configurations

Because Redis is configured to listen on a Unix socket instead of a TCP/IP port (which is recommended if Redis is running on the same system as ownCloud) we must instruct SELinux to allow daemons to enable cluster mode.

[operator@owncloud ~]$ sudo setsebool -P daemons_enable_cluster_mode on

This boolean allows httpd_t complete access to all of the httpd types (that is to execute, read, or write sys_content_t). Enable this boolean to allow this access.

[operator@owncloud ~]$ sudo setsebool -P httpd_unified on

When disabled, this boolean prevents HTTP scripts and modules from initiating a connection to a network or remote port. Enable this boolean to allow this access.

[operator@owncloud ~]$ sudo setsebool -P httpd_can_network_connect on

Modify authorized ports

[operator@owncloud ~]$ sudo firewall-cmd --add-port={80/tcp,443/tcp} --permanent
[operator@owncloud ~]$ sudo firewall-cmd --reload

Enable and start HTTPD service

[operator@owncloud ~]$ sudo systemctl enable --now httpd

Check if it works

If you navigate to the URL of your ownCloud instance, you will face an Internal Server Error. This error comes from SELinux. By default, SELinux is preventing /usr/sbin/php-fpm from write access on the socket file redis.sock. Generate a local policy module to allow this access.

[operator@owncloud ~]$ sudo ausearch -c 'php-fpm' --raw | audit2allow -M phpfpm-redis
[operator@owncloud ~]$ sudo semodule -i phpfpm-redis.pp
[operator@owncloud ~]$ sudo rm -f phpfpm-redis.*

Note that the creation of the local policy module will only be possible if you have already navigated to the URL: you need a SELinux error to generate it.

Configure ownCloud cron job

[operator@owncloud ~]$ sudo -u apache php /var/www/owncloud/occ background:cron
Set mode for background jobs to 'cron'

Add the cron job for apache user by executing this command: sudo -u apache crontab -e, then add this cron job.

*/15 * * * * /usr/bin/php /var/www/owncloud/occ system:cron

Add user

You can manage many things with the occ command, please visit the documentation to learn more.

[operator@owncloud ~]$ sudo -u apache php /var/www/owncloud/occ user:add --display-name="John Doe" jdoe
Enter password: <John's password>
Confirm password: <John's password again>
The user "jdoe" was created successfully
Display name set to "John Doe"

Enable server-side encryption

ownCloud includes an encryption application. When enabled, all of your ownCloud data files are automatically encrypted. Encryption is server-wide, so when it is enabled you cannot choose to keep your files unencrypted. You don’t have to do anything special, as it uses your ownCloud login as the password for your unique private encryption key. Just log in and out and manage and share your files as you normally do, and you can still change your password whenever you want. Learn more here.

Enable the encryption application

[operator@owncloud ~]$ sudo -u apache php /var/www/owncloud/occ app:enable encryption
encryption enabled

Enable the the encryption

Once enabled this module will encrypt all your files transparently. The encryption is based on AES 256 keys.

[operator@owncloud ~]$ sudo -u apache php /var/www/owncloud/occ encryption:enable
Encryption enabled

Default module: OC_DEFAULT_MODULE

Set encryption type to user-keys. This means that each user will have his own key to cipher and decipher his data, which is more secure.

[operator@owncloud ~]$ sudo -u apache php /var/www/owncloud/occ encryption:select-encryption-type user-keys
Warning: Only available for fresh installations with no existing encrypted data! There is also no way to disable it again. Do you want to continue? (y/n) y
User key successfully enabled.

Note: In the encryption page (https://owncloud.local/index.php/settings/admin?sectionid=encryption), you can set a recovery key password. The recovery key is an extra encryption key that is used to encrypt files. It allows recovery of a user’s files if the user forgets his or her password. Again, read the documentation here.

Recommendations

Protection against brute-force with Fail2ban

[operator@owncloud ~]$ sudo dnf -y install fail2ban-server fail2ban-firewalld

First, we want to ban brute-force user login attempts. Copy the following snippet into /etc/fail2ban/filter.d/owncloud.conf.

[INCLUDES]
before = common.conf

[Definition]
failregex = {.*Login failed: \'.*\' \(Remote IP: \'<ADDR>\'\)"}
ignoreregex =

Create the jail by copying the following snippet into /etc/fail2ban/jail.d/owncloud.local.

[owncloud]
enabled = true
port = 80,443
filter = owncloud
action = iptables-allports[name=owncloud]
logpath = /var/www/owncloud/data/owncloud.log
maxretry = 3
bantime = 86400
findtime = 3600

Start the Fail2ban server and enable it at boot.

[operator@owncloud ~]$ sudo systemctl enable --now fail2ban

At this moment, SELinux is preventing /usr/libexec/platform-python3.6 from getattr access on the file /var/www/owncloud/data/owncloud.log. To overcome this error, you have to generate a local policy module to allow this access.

[operator@owncloud ~]$ sudo ausearch -c 'fail2ban-server' --raw | audit2allow -M fail2ban-getattr-owncloud-log
[operator@owncloud ~]$ sudo semodule -i fail2ban-getattr-owncloud-log.pp
[operator@owncloud ~]$ sudo rm -f fail2ban-getattr-owncloud-log.*

Restart the Fail2ban server.

[operator@owncloud ~]$ sudo systemctl restart fail2ban

Now, SELinux is preventing /usr/libexec/platform-python3.6 from read access on the file owncloud.log. You have to generate a local policy module to allow this access.

[operator@owncloud ~]$ sudo ausearch -c 'fail2ban-server' --raw | audit2allow -M fail2ban-read-owncloud-log
[operator@owncloud ~]$ sudo semodule -i fail2ban-read-owncloud-log.pp
[operator@owncloud ~]$ sudo rm -f fail2ban-read-owncloud-log.*

Restart the Fail2ban server.

[operator@owncloud ~]$ sudo systemctl restart fail2ban

Lastly, SELinux is preventing /usr/libexec/platform-python3.6 from open access on the file /var/www/owncloud/data/owncloud.log. Without much surprise, you have to generate a local policy module to allow this access.

[operator@owncloud ~]$ sudo ausearch -c 'fail2ban-server' --raw | audit2allow -M fail2ban-open-owncloud-log
[operator@owncloud ~]$ sudo semodule -i fail2ban-open-owncloud-log.pp
[operator@owncloud ~]$ sudo rm -f fail2ban-open-owncloud-log.*

Restart the Fail2ban server.

[operator@owncloud ~]$ sudo systemctl restart fail2ban

Check the login attempts jail.

[operator@owncloud ~]$ sudo fail2ban-client status owncloud
Status for the jail: owncloud
|- Filter
|  |- Currently failed:	0
|  |- Total failed:	0
|  `- File list:	/var/www/owncloud/data/owncloud.log
`- Actions
   |- Currently banned:	0
   |- Total banned:	0
   `- Banned IP list:

You can try to log in with bad credentials and executed a new time the previous command, the Currently failed and Total failed values will increment. Don’t abuse, you’ll be block otherwise!

Finally, you can unban an IP with the following command.

[operator@owncloud ~]$ sudo fail2ban-client set owncloud unbanip <IP>

Delete skeleton directories and files

For each added user, two directories and a file will be created, you can delete the following directory to avoid this behavior.

[operator@owncloud ~]$ sudo rm -rf /var/www/owncloud/core/skeleton/

Backing up data

Create the folder that will receive the backups.

[operator@owncloud ~]$ sudo mkdir -p /var/local/owncloud/backups

Copy the following snippet into /usr/local/sbin/ocbackup. Change <owncloud user's password> by the password you have defined to the owncloud user. Because we use the short password flag -p, you cannot have a space between the flag and the password.

#!/usr/bin/env bash

backuptime=$(date +%Y-%m-%d)
dir=/var/local/owncloud/backups/$backuptime
mkdir $dir
rsync -Aax /var/www/owncloud/data/ $dir/data
rsync -Aax /var/www/owncloud/config/ $dir/config
mariadb-dump --single-transaction -S /var/lib/mysql/mysql.sock -u owncloud -p<owncloud user's password> owncloud > $dir/database.sql
tar -cf $dir.tar.gz --absolute-names $dir
rm -rf $dir

Make it executable.

[operator@owncloud ~]$ sudo chmod +x /usr/local/sbin/ocbackup

Then, add these entries into the root user’s crontab via sudo crontab -e.

0 4 * * * /usr/local/sbin/ocbackup
0 6 * * * /usr/bin/find /var/local/owncloud/backups/ -type f -name '*.tar.gz' -mtime +1 -delete

Each day, at 4 a.m., the script will save data in a directory (format: Y-m-D) into /var/local/owncloud/backups. Then, each day at 6 a.m. all backup older than 4 days will be deleted. With this configuration, data can be retrieved in n-4 days. Increase this number to have more days of retention.

Configure e-mail server

The section named General in the Admin panel allows you to define the mail server settings you want to use.

Your ownCloud server installation is now finished! You can see that all security and setup configuration checks are successfully passed in the section named General in the Admin panel.