Nextcloud 23 Installation mit Nginx, MariaDB, PHP7.4, LetsEncrypt, Redis und Fail2Ban
In diesem Beitrag wird der komplette Installationsablauf für die Inbetriebnahme von Nextcloud v23 auf einem Ubuntu Server 20.04 LTS behandelt.

Inhalt:
- Vorwort
- Vorbereitungen
- Konfiguration der einzelnen Programme
- Installation
- Warnungen im Admin Bereich / Nacharbeit
Vorwort
Als Basis für den gesamten Artikel dient mir eine Virtuelle Maschine mit folgenden Eigenschaften:
- OS: Ubuntu 20.04 LTS
- 4 CPU Kerne
- 8 GB Ram
- 200 GB SSD Speicherplatz
Desweiteren wird der LEMP Stack zum Einsatz kommen, das heißt ich werde auf:
- Ubuntu als Betriebssystem,
- Nginx als Webserver / Reverse Proxy,
- MariaDB als Datenbankserver
- und PHP7.4 setzen.
Die Installation von Nginx, MariaDB und PHP 7.4 wird in folgenden Abschnitten noch ausführlich beschrieben. Der Zeitaufwand für die Installation sollte hierbei 3 Stunden nicht überschreiten, wenn wenig Kenntnisse vorhanden sind.
Vorbereitungen
Bevor wir starten, sollte das System und alle Programme noch auf den aktuellen Stand gebracht werden, dies geschieht mit folgendem Befehl:
apt update && apt upgrade -y && apt autoremove
Nginx
Anschließend füge ich noch die Paketquellen des Mainline Repository von Nginx ein, um aktuellere Versionen des Webservers zu erhalten, als in den Standard Ubuntu Paketquellen freigegeben sind.Zuerst wird der Key hinzugefügt:
wget -O - http://nginx.org/keys/nginx_signing.key | apt-key add -
Anschließend können die Paketquellen hinzugefügt werden:
nano /etc/apt/sources.list.d/nginx.list
# Nginx (Mainline)
deb [arch=amd64] http://nginx.org/packages/mainline/ubuntu/ focal nginx
deb-src [arch=amd64] http://nginx.org/packages/mainline/ubuntu/ focal nginx
Danach kann Nginx wie gewohnt installiert werden:
apt update && apt install nginx
MariaDB
Das gleiche Vorgehen erledigen wir noch für MariaDB um auch hier eine neuere Version - aktuell 10.6 - zu erhalten: Key:
sudo apt-key adv --fetch-keys 'https://mariadb.org/mariadb_release_signing_key.asc'
Und wie bei Nginx, auch hier die neuen Paketquellen hinzufügen:
nano /etc/apt/sources.list.d/MariaDB.list
# MariaDB 10.6 repository list
# https://mariadb.org/download/
deb [arch=amd64,arm64,ppc64el,s390x] https://ftp.agdsn.de/pub/mirrors/mariadb/repo/10.6/ubuntu focal main
deb-src https://ftp.agdsn.de/pub/mirrors/mariadb/repo/10.6/ubuntu focal main
Und die gewohnte Installation über den APT Paketmanager:
apt update && apt install mariadb-server
PHP
Bei PHP werde ich die letzte Stable Version in den Ubuntu Paketquellen verwenden. Aktuell ist dies PHP 7.4. Die benötigten Pakete beziehen wir über folgenden Befehl:
apt install php7.4 php-fpm php-gd php-mysql php-curl php-xml php-zip php-intl php-mbstring php-bz2 php-json php-apcu php-imagick php-gmp php-bcmath
Zusätzliche Pakete:
Ab Nextcloud Version 21 wird zusätzlich noch ImageMagick benötigt, dies ist recht simpel zu erledigen, ebenso die Erweiterung um den Support für SVG Dateien:
apt install imagemagick libmagickcore-6.q16-6-extra
Konfiguration der einzelnen Programme
Einrichtung von Nginx
Die Nginx Konfiguration ist recht schnell über die folgenden Konfigurationsdateien abgebildet. Die Basis dazu war nginxconfig.io und ich habe die Dateien auf meine Bedürfnisse zugeschnitten: Zuerst widmen wir uns der »nginx.conf« Datei, der "Steuereinheit" für den Webserver, diese Datei erhält folgenden Inhalt:
nano /etc/nginx/nginx.conf
user www-data;
pid /run/nginx.pid;
worker_processes auto;
worker_rlimit_nofile 65535;
events {
multi_accept on;
worker_connections 65535;
}
http {
charset utf-8;
sendfile on;
tcp_nopush on;
tcp_nodelay on;
server_tokens off;
log_not_found off;
types_hash_max_size 2048;
client_max_body_size 16M;
# MIME
include mime.types;
default_type application/octet-stream;
# Logging
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log warn;
# SSL
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;
# Mozilla Modern configuration
ssl_protocols TLSv1.3;
# OCSP Stapling
ssl_stapling on;
ssl_stapling_verify on;
resolver 1.1.1.1 1.0.0.1 [2606:4700:4700::1111] [2606:4700:4700::1001] valid=60s;
resolver_timeout 2s;
# Load configs
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
}
Anschließend erstellen wir ein Unterverzeichnis, welches unsere zusätzlichen Konfigurationsdateien beinhalten wird:
mkdir -p /etc/nginx/configs
Anschließend erstellen wir die »general.conf« Datei und betanken diese mit unten stehendem Inhalt:
nano /etc/nginx/configs/general.conf
# favicon.ico
location = /favicon.ico {
log_not_found off;
access_log off;
}
# robots.txt
location = /robots.txt {
log_not_found off;
access_log off;
}
# assets, media
location ~* \.(?:css(\.map)?|js(\.map)?|jpe?g|png|gif|ico|cur|heic|webp|tiff?|mp3|m4a|aac|ogg|midi?|wav|mp4|mov|webm|mpe?g|avi|ogv|flv|wmv)$ {
expires 7d;
access_log off;
}
# svg, fonts
location ~* \.(?:svgz?|ttf|ttc|otf|eot|woff2?)$ {
add_header Access-Control-Allow-Origin "*";
expires 7d;
access_log off;
}
# gzip
gzip on;
gzip_vary on;
gzip_proxied any;
gzip_comp_level 6;
gzip_types text/plain text/css text/xml application/json application/javascript application/rss+xml application/atom+xml image/svg+xml;
Und gleich darauf wird noch die »security.conf« Datei erstellt, welche Zusatzinformationen wie Header beinhalten wird:
nano /etc/nginx/configs/security.conf
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-XSS-Protection "1; mode=block" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "no-referrer" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
# . files
location ~ /\.(?!well-known|file).* {
deny all;
}
Anschließend kann Nginx noch gestartet werden, sowie der Befehl abgesetzt werden, dass der Webserver nach einem Neustart automatisch startet:
systemctl start nginx
systemctl enable nginx
systemctl status nginx
Ist nach Absetzen des letzten Befehles abzusehen, dass der Webserver läuft, können wir uns der Einrichtung von MariaDB widmen.

Einrichtung von MariaDB
Da der Datenbankserver erst neu installiert wird, wird die Einrichtung über das Absetzen des Befehls
mysql_secure_installation
gestartet. Hierbei wird das Kennwort für den root User vergeben, alle anderen Fragen der Installationsroutine können mit "Ja" bzw. Y/J beantwortet werden.
Einrichtung von PHP
PHP benötigt einige tiefergehende Änderungen, zuerst widmen wir uns der »www.conf« Datei:
nano /etc/php/7.4/fpm/pool.d/www.conf
Hier sollten folgende Änderungen bzw. Checks durchgeführt werden, die Datei habe ich zur besseren Lesbarkeit entsprechend eingekürzt:
user = www-data
group = www-data
[...]
listen = /run/php/php7.4-fpm.sock
[...]
# Durch entfernen der Semikolons am Zeilenbeginn werden die Umgebungsvariablen aktiviert
env[HOSTNAME] = $HOSTNAME
env[PATH] = /usr/local/bin:/usr/bin:/bin
env[TMP] = /tmp
env[TMPDIR] = /tmp
env[TEMP] = /tmp
Jetzt folgen noch zwei weitere Dateien zur Bearbeitung:
nano /etc/php/7.4/fpm/php.ini
cgi.fix_pathinfo = 0
memory_limit = 512M
opcache.enable = 1
opcache.enable_cli = 1
opcache.memory_consumption = 128
opcache.interned_strings_buffer = 8
opcache.max_accelerated_files = 10000
opcache.revalidate_freq = 1
opcache.save_comments = 1
Erklärung:
- »cgi.fix_pathinfo«: Sorgt für eine sichere Interpretation von Pfadangaben
- »memory_limit«: Dieser Wert gibt an, wie viel Speicher ein PHP-Skript nutzen darf. Nextcloud benötigt mindestens 512 MB als Memory Limit
- »OPcache«: PHP OPcache ermöglicht bessere Performance durch das Ablegen vorkompilierten Bytecodes in den Arbeitsspeicher.
Die Einträge liegen auskommentiert vor und müssen durch Entfernen des »;« noch scharf geschalten werden.
Tipp: Unter nano lässt sich durch die Tastenkombination »Strg + W« nach beliebigen Einträgen suchen! Die letzte benötigte Datei beinhaltet die Informationen für die CLI Version von PHP und wird wie folgt abgeändert:
nano /etc/php/7.4/cli/php.ini
cgi.fix_pathinfo = 0
apc.enable_cli = 1
»apc.enable« muss ab Version 21 aktiv gesetzt werden, andernfalls kommt es zu Fehlermeldungen oder der Arbeitsspeicher läuft euch wieder und wieder voll.
service php7.4-fpm restart
Mit obigem Restart lassen wir getätigte Änderungen wirksam werden.
Beantragen der SSL Zertifikate
Dieser Teil wurde in einen eigenen Artikel ausgegliedert: Link.
Installation
vHost für Nextcloud anlegen
Die Vorarbeit ist getan, jetzt fehlt noch der vHost für Nginx, der später unsere Nextcloud ausliefern wird. Meine Konfiguration basiert auf der ausgeschriebenen Config aus dem Admin Manual und wurde nach meinen Wünschen abgeändert:
upstream php-handler {
#server 127.0.0.1:9000;
server unix:/var/run/php/php7.4-fpm.sock;
}
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name nextcloud.domain.tld;
# SSL configuration
# SSL ECC
ssl_certificate /etc/letsencrypt/nextcloud.domain.tld/ecc/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/nextcloud.domain.tld/ecc/key.pem;
# SSL RSA
ssl_certificate /etc/letsencrypt/nextcloud.domain.tld/rsa/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/nextcloud.domain.tld/rsa/key.pem;
ssl_trusted_certificate /etc/letsencrypt/nextcloud.domain.tld/ecc/ca.pem;
# Include headers
include /etc/nginx/configs/security.conf;
#specific Nextcloud Headers until Version 21.0.2
add_header X-Permitted-Cross-Domain-Policies none;
add_header X-Robots-Tag none;
add_header X-Download-Options noopen;
#
# Nextcloud configuration
#
# Path to the root of your installation
root /var/www/nextcloud/;
# set max upload size
client_max_body_size 10G;
fastcgi_buffers 64 4K;
# Enable gzip but do not remove ETag headers
gzip on;
gzip_vary on;
gzip_comp_level 4;
gzip_min_length 256;
gzip_proxied expired no-cache no-store private no_last_modified no_etag auth;
gzip_types application/atom+xml application/javascript application/json application/ld+json application/manifest+json application/rss+xml application/vnd.geo+json application/vnd.ms-fontobject application/x-font-ttf application/x-web-app-manifest+json application/xhtml+xml application/xml font/opentype image/bmp image/svg+xml image/x-icon text/cache-manifest text/css text/plain text/vcard text/vnd.rim.location.xloc text/vtt text/x-component text/x-cross-domain-policy;
# Pagespeed is not supported by Nextcloud, so if your server is built
# with the 'ngx_pagespeed' module, uncomment this line to disable it.
#pagespeed off;
# Specify how to handle directories -- specifying '/index.php$request_uri'
# here as the fallback means that Nginx always exhibits the desired behaviour
# when a client requests a path that corresponds to a directory that exists
# on the server. In particular, if that directory contains an index.php file,
# that file is correctly served; if it doesn't, then the request is passed to
# the front-end controller. This consistent behaviour means that we don't need
# to specify custom rules for certain paths (e.g. images and other assets,
# '/updater', '/ocm-provider', '/ocs-provider'), and thus
# 'try_files $uri $uri/ /index.php$request_uri'
# always provides the desired behaviour.
index index.php index.html /index.php$request_uri;
# Rule borrowed from '.htaccess' to handle Microsoft DAV clients
location = / {
if ( $http_user_agent ~ ^DavClnt ) {
return 302 /remote.php/webdav/$is_args$args;
}
}
location = /robots.txt {
allow all;
log_not_found off;
access_log off;
}
proxy_cookie_path / "/; HTTPOnly; Secure";
# logging
access_log /var/log/nginx/cloud.access.log;
error_log /var/log/nginx/cloud.error.log warn;
# Make a regex exception for '/.well-known' so that clients can still
# access it despite the existence of the regex rule
# 'location ~ /(\.|autotest|...)' which would otherwise handle requests
# for '/.well-known'.
location ^~ /.well-known {
# The following 6 rules are borrowed from '.htaccess'
location = /.well-known/carddav { return 301 /remote.php/dav/; }
location = /.well-known/caldav { return 301 /remote.php/dav/; }
# Anything else is dynamically handled by Nextcloud
location ^~ /.well-known { return 301 /index.php$uri; }
try_files $uri $uri/ =404;
}
# Rules borrowed from '.htaccess' to hide certain paths from clients
location ~ ^/(?:build|tests|config|lib|3rdparty|templates|data)(?:$|/) { return 404; }
location ~ ^/(?:\.|autotest|occ|issue|indie|db_|console) { return 404; }
# Ensure this block, which passes PHP files to the PHP process, is above the blocks
# which handle static assets (as seen below). If this block is not declared first,
# then Nginx will encounter an infinite rewriting loop when it prepends '/index.php'
# to the URI, resulting in a HTTP 500 error response.
location ~ \.php(?:$|/) {
fastcgi_split_path_info ^(.+?\.php)(/.*)$;
set $path_info $fastcgi_path_info;
try_files $fastcgi_script_name =404;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param PATH_INFO $path_info;
fastcgi_param HTTPS on;
fastcgi_param modHeadersAvailable true; # Avoid sending the security headers twice
fastcgi_param front_controller_active true; # Enable pretty urls
fastcgi_pass php-handler;
fastcgi_intercept_errors on;
fastcgi_request_buffering off;
fastcgi_read_timeout 600;
fastcgi_send_timeout 600;
fastcgi_connect_timeout 600;
fastcgi_param PHP_VALUE "upload_max_filesize = 10G
post_max_size = 10G
max_execution_time = 3600
output_buffering = off";
}
location ~ \.(?:css|js|svg|gif)$ {
try_files $uri /index.php$request_uri;
expires 6M; # Cache-Control policy borrowed from '.htaccess'
access_log off; # Optional: Don't log access to assets
}
location ~ \.woff2?$ {
try_files $uri /index.php$request_uri;
expires 7d; # Cache-Control policy borrowed from '.htaccess'
access_log off; # Optional: Don't log access to assets
}
location / {
try_files $uri $uri/ /index.php$request_uri;
}
}
server {
listen 80;
listen [::]:80;
server_name nextcloud.domain.tld;
# enforce https
return 301 https://nextcloud.domain.tld$request_uri;
}
Ob bis zu diesem Punkt alles geklappt hat erfahrt ihr via »nginx -t«, mit »systemctl restart nginx« wird der Webserver im Anschluss noch neu gestartet.
Download der Serverfiles
Die letzte Stable Version von Nextcloud laden wir uns zunächst auf unser System, entpacken es anschließend und verschieben es an den künftigen Speicherort im Webroot:
wget https://download.nextcloud.com/server/releases/latest.tar.bz2
tar -xjf latest.tar.bz2 -C /var/www
rm latest.tar.bz2
Anschließend werden die Berechtigungen für den Nextcloud Ordner angepasst:
chown -R www-data:www-data /var/www/nextcloud
Datenverzeichnis anlegen
Im Admin Manual wird explizit geraten, die Daten die in der Nextcloud gespeichert werden, nicht im Webroot abgelegt werden. Hierfür erstelle ich einen Ordner außerhalb und gebe anschließend die Berechtigungen an den www-data User ab.
mkdir -p /var/nextcloud_data
chown -R www-data:www-data /var/nextcloud_data
Datenbank und Datenbankverbindung anlegen
CREATE USER [email protected] IDENTIFIED BY 'PasSw0rT';
CREATE DATABASE nextcloud_db CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
GRANT ALL PRIVILEGES on nextcloud_db.* to [email protected];
FLUSH privileges;
exit;
Nextcloud Setup
Die Vorarbeit ist geschafft. Navigiert jetzt zu eurer Domain https://nextcloud.domain.tld
und gebt alle benötigten Daten an.

Wenn ihr soweit seid, schließt das Setup mit "Installation abschließen" ab. Nach einem kurzen Moment solltet ihr eingeloggt in der Cloud ankommen.
Warnungen im Admin Bereich / Nacharbeit
Cronjob anlegen
Nextcloud setzt nach Standard Installation AJAX zur Bewältigung von Hintergrundaufgaben ein, das heißt aber auch, dass Datenbankbereinigungen etc. nur dann ausgeführt werden, wenn jemand aktiv in der Cloud ist. Das möchte ich dringend ändern und werde es in einen Cronjob auslagern, der diese Hintergrundaufgaben alle 5min anstößt - auch wenn niemand angemeldet ist. Zuerst öffnet man crontab als »www-data« User, anschließend kommt folgender Cronjob neu hinzu:
sudo -u www-data crontab -e
*/5 * * * * php -f /var/www/nextcloud/cron.php > /dev/null 2>&1
Fehlende Datenbank Indizes
Nach Upgrades oder Neuinstallationen können neue Indizes für die Datenbank benötigt werden. Hinweise dazu liefert Nextcloud selbst im Dashboard:

Um diese Meldung zu beheben navigieren wir zuerst ins Installationsverzeichnis der Nextcloud Instanz und setzen anschließend das folgende Command ab:
cd /var/www/nextcloud
sudo -u www-data php occ db:add-missing-indices
Nach kurzer Wartezeit sollten dann ähnliche Meldungen im Terminal erscheinen:
Check indices of the share table.
Check indices of the filecache table.
Check indices of the twofactor_providers table.
Check indices of the login_flow_v2 table.
Check indices of the whats_new table.
Check indices of the cards table.
Check indices of the cards_properties table.
Check indices of the calendarobjects_props table.
Check indices of the schedulingobjects table.
Check indices of the oc_properties table.
Adding properties_pathonly_index index to the oc_properties table, this can take some time...
oc_properties table updated successfully.
Check indices of the oc_jobs table.
Adding job_lastcheck_reserved index to the oc_jobs table, this can take some time...
Damit sollte die Meldung im Admin Dashboard verschwunden sein.
config.php - Nacharbeiten
Die config.php beinhaltet Instruktionen für die Nextcloud Instanz, es fehlen jedoch noch ein paar Nacharbeiten um zum Einen Fehlermeldungen zu verhindern und zum anderen den Betrieb zusätzlich noch etwas abzusichern, diese Änderungen habe ich an meinen Instanzen vorgenommen:
# Standard Telefonregion
'default_phone_region' => 'DE',
# Memory-Caches für PHP
'memcache.local' => '\OC\Memcache\APCu',
'overwriteprotocol' => 'https',
# Anpassen der Sprache und Zeitzone
'logtimezone' => 'Europe/Berlin',
'force_language' => 'de',
'force_locale' => 'de_DE',
Redis Setup
Zwei weitere Vorteile bietet der Redis Server für die neu erstellte Nextcloud Instanz: Zum einen wird Last vom Datenbankserver genommen, zum anderen kann die Cloud »Transactional File Locking« verwenden. Hierbei werden Sperren auf aktuell zu bearbeitende Dateien gesetzt, sodass bei parallelem Arbeiten keine Fortschritte überschrieben werden können. Ohne diese Sperren würde immer der zuletzt übermittelte Stand durchgesetzt werden.
Installation und Konfiguration des Redis-Server
Zunächst wird Redis und das dazugehörige PHP-Modul installiert:
apt update && apt install redis-server php-redis
nano /etc/redis/redis.conf
Anstatt die Anfragen auf Ports lauschen zu lassen, empfiehlt es sich, Redis so zu konfigurieren, dass Sockets verwendet werden. Hierzu muss die Konfigurationsdatei wie folgt abgeändert werden:
unixsocket /var/run/redis/redis-server.sock
unixsocketperm 770
port 0
Die Konfiguration hat folgende Auswirkungen:
- port: Standardmäßig nutzt Redis den Port 6379, mit der Änderung auf 0 wird stattdessen ein Socket genutzt
- unixsocket: Der ab jetzt zu verwendende Socket
- unixsocketperm: Berechtigungen für den Socket, diese müssen angepasst werden, ansonsten wirft Nextcloud im Anschluss Berechtigungsfehler
Im Anschluss muss der Redis-User noch der Webserver Gruppe »www-data« hinzugefügt werden:
usermod -a -G redis www-data
Um die Änderungen zu übernehmen, wird der Redis-Server noch neu gestartet:
systemctl restart redis-server
Einbinden in die Nextcloud
Damit die eigene Cloud nun auch Redis nutzt, muss dieses noch in der Nextcloud-Konfiguration angepasst werden:
Bisher läuft Redis zwar, ist aber momentan noch nicht in die Nextcloud integriert. Hierzu müssen noch Änderungen in der Konfigurationsdatei vorgenommen werden.
nano /var/www/nextcloud/config/config.php
Am Ende der Datei wird folgende Konfiguration hinzugefügt:
<?php
$CONFIG = array (
[...]
'filelocking.enabled' => 'true',
'memcache.locking' => '\OC\Memcache\Redis',
'redis' => array (
'host' => '/var/run/redis/redis-server.sock',
'port' => 0,
'timeout' => 0.0,
),
[...]
); // Ende der Config
Hinweis: Bei mir führte die Änderung zu Fehlermeldungen bis zur Nichterreichbarkeit der Cloud. Ursache scheint hierbei folgende Zeile zu sein:
'memcache.local' => '\\OC\\Memcache\\APCu',
Füge ich den Code Block für die Redis Konfiguration über dieser Zeile ein, funktioniert alles problemlos.
EMPFEHLUNG: Bei etlichen Neuinstallationen kam es anschließend zu Problemen, die erst ein Neustart des Systems lösen konnte, daher führe ich an dieser Stelle meist einen Neustart des Systems aus mit:
reboot now
Fail2Ban Setup
Da die eingebaute Bruteforce Protection für mich bis zum aktuellen Zeitpunkt nicht optimal aufgebaut ist, wird auf Fail2Ban zurückgegriffen, dieses Tool kann normal über die Paketquellen nachinstalliert werden und wird im Anschluss mit einem eigenen Jail (Gefängnis, in Fail2Ban eine Art Konfigurationsdatei pro überwachtem Dienst) angesprochen.
apt update && apt install fail2ban
Jetzt wird wie oben beschrieben, ein eigenes Jail erstellt:
nano /etc/fail2ban/filter.d/nextcloud.local
[Definition]
_groupsre = (?:(?:,?\s*"\w+":(?:"[^"]+"|\w+))*)
failregex = ^\{%(_groupsre)s,?\s*"remoteAddr":"<HOST>"%(_groupsre)s,?\s*"message":"Login failed:
^\{%(_groupsre)s,?\s*"remoteAddr":"<HOST>"%(_groupsre)s,?\s*"message":"Trusted domain error.
datepattern = ,?\s*"time"\s*:\s*"%%Y-%%m-%%d[T ]%%H:%%M:%%S(%%z)?"
Das Nextcloud Jail wird nun noch in der Konfigurationseinheit scharf geschalten:
nano /etc/fail2ban/jail.local
[DEFAULT]
maxretry=3
bantime=86400
[nextcloud]
enabled=true
port=80,443
protocol=tcp
filter=nextcloud
logpath=/var/nextcloud_data/nextcloud.log
[nginx-http-auth]
enabled = true
Im [DEFAULT] Tab werden die allgemeinen Regeln festgelegt, hier also die maximalen Versuche (maxretry) bis Fail2Ban einschreitet und die Bandauer (bantime) ausformuliert in Sekunden. Unter [nextcloud] wird das eigentliche Jail definiert und angesprochen:
- enabled => Aktivierung der Regel
- port => Zu überwachende Ports, hier HTTP(S) Ports
- protocol => zu verwendendes Protokoll, hier TCP
- logpath => Pfad zur Logdatei eurer Instanz, solltet ihr die Logging Einstellungen abgeändert haben, passt diesen Pfad an eure Gegebenheiten an
Im Anschluss wird fail2ban neu gestartet:
service fail2ban restart
Bei Bedarf kann nachgeschaut werden, welche IP Adressen aktuell gesperrt sind, dies geschieht mit folgendem Befehl:
fail2ban-client status nextcloud