Fail2Ban auf einem Linux-VPS installieren und konfigurieren

Fail2Ban überwacht Ihre Logdateien auf wiederholte Authentifizierungsfehler und sperrt die angreifenden IP-Adressen über Ihre Firewall. Es stoppt Brute-Force-Angriffe, bevor sie Erfolg haben. Ein frisch aufgesetzter VPS erhält in der Regel innerhalb von Minuten SSH-Loginversuche. Fail2Ban ist die Standardverteidigung.

Diese Anleitung behandelt die Installation auf Ubuntu 24.04 und Debian 12, die Konfiguration von SSH- und Nginx-Jails, beide Bannaktion-Backends (UFW und nftables), die Recidive-Jail für Wiederholungstäter und das Testen von Filtern mit fail2ban-regex. Jede Konfigurationsänderung enthält einen Verifizierungsschritt.

Voraussetzungen: Ein VPS mit Ubuntu 24.04 oder Debian 12 und Root- oder Sudo-Zugang. Ihre Firewall sollte bereits aktiv sein und SSH sollte abgesichert sein. Diese Anleitung ist Teil der Serie Linux-VPS-Sicherheit.

Wie installiere ich Fail2Ban auf Ubuntu 24.04 und Debian 12?

Installieren Sie Fail2Ban mit apt. Das Paket befindet sich in den Standard-Repositories beider Distributionen. Ubuntu 24.04 liefert Version 1.0.2, Debian 12 ebenfalls. Unter Debian 12 benötigen Sie zusätzlich python3-systemd, damit Fail2Ban das systemd-Journal lesen kann.

sudo apt update && sudo apt install -y fail2ban

Unter Debian 12 installieren Sie die systemd-Python-Bindings:

sudo apt install -y python3-systemd

Aktivieren und starten Sie den Dienst:

sudo systemctl enable --now fail2ban

Das Flag enable sorgt dafür, dass Fail2Ban beim Booten startet. Das Flag --now startet es sofort. Prüfen Sie, ob es läuft:

sudo systemctl status fail2ban

Die Ausgabe zeigt Active: active (running) in der Ausgabe sehen. Falls der Status failed zeigt, prüfen Sie das Journal:

journalctl -u fail2ban -n 20 --no-pager

Was ist der Unterschied zwischen jail.conf, jail.local und jail.d/?

jail.conf ist die Standard-Konfigurationsdatei, die mit dem Paket geliefert wird. Paketupdates überschreiben sie. Bearbeiten Sie jail.conf niemals direkt. Ihre Änderungen verschwinden beim nächsten apt upgrade.

jail.local ist die traditionelle Override-Datei. Fail2Ban liest zuerst jail.conf und wendet dann die Einstellungen aus jail.local darüber an. Das funktioniert, aber die Datei wächst zu einem Monolithen, der schwer zu pflegen ist.

Das Verzeichnis jail.d/ ist der bessere Ansatz. Legen Sie eine .conf-Datei pro Jail ab. Fail2Ban lädt sie alphabetisch nach jail.conf und jail.local. So bleibt jeder Dienst isoliert und Sie können Jails hinzufügen oder entfernen, ohne andere Konfigurationen zu berühren.

Diese Anleitung verwendet Drop-in-Dateien in jail.d/. Prüfen Sie, ob das Verzeichnis existiert:

ls /etc/fail2ban/jail.d/

Es sollte bereits vorhanden sein. Wenn Sie Dateien wie defaults-debian.conf sehen, ist das normal. Unter Ubuntu 24.04 aktiviert diese Datei die sshd-Jail und setzt banaction = nftables als Standard-Bannaktion. Unter Debian 12 aktiviert sie die sshd-Jail. Da Fail2Ban die Dateien in jail.d/ alphabetisch lädt, muss jede benutzerdefinierte Standarddatei alphabetisch nach defaults-debian.conf sortiert werden, um deren Einstellungen zu überschreiben. Diese Anleitung verwendet deshalb zz-defaults.conf.

Wie konfiguriere ich die SSH-Jail in Fail2Ban?

Die SSH-Jail überwacht Authentifizierungslogs und sperrt IPs, die zu oft beim Login scheitern. Unter Ubuntu 24.04 und Debian 12 ist die sshd-Jail standardmäßig über /etc/fail2ban/jail.d/defaults-debian.conf aktiviert. Die Standardwerte sind jedoch zu locker (5 Versuche, 10 Minuten Sperre). Verschärfen Sie sie.

Erstellen Sie eine Drop-in-Konfiguration:

sudo tee /etc/fail2ban/jail.d/sshd.conf > /dev/null << 'EOF'
[sshd]
enabled = true
mode = aggressive
port = ssh
backend = systemd
maxretry = 3
findtime = 600
bantime = 3600
EOF

Bedeutung der einzelnen Einstellungen:

Parameter	Wert	Bedeutung
enabled	true	Aktiviert diese Jail
mode	aggressive	Erkennt mehr SSH-Fehlermuster, einschließlich Key-Authentifizierungsfehler
port	ssh	Überwacht den SSH-Port (wird zu 22 aufgelöst oder Ihr benutzerdefinierter Port)
backend	systemd	Liest aus dem systemd-Journal statt aus Logdateien
maxretry	3	Sperrt nach 3 fehlgeschlagenen Versuchen
findtime	600	Zählt Fehler innerhalb eines 10-Minuten-Fensters
bantime	3600	Sperrt für 1 Stunde (3600 Sekunden)

Falls Sie Ihren SSH-Port geändert haben (das sollten Sie), ersetzen Sie ssh durch Ihre Portnummer:

port = 2222

Starten Sie Fail2Ban neu, um die Änderungen anzuwenden:

sudo systemctl restart fail2ban

Überprüfen Sie, ob die Jail aktiv ist:

sudo fail2ban-client status sshd

Erwartete Ausgabe:

Status for the jail: sshd
|- Filter
|  |- Currently failed:	0
|  |- Total failed:	0
|  `- Journal matches:	_SYSTEMD_UNIT=sshd.service + _COMM=sshd
`- Actions
   |- Currently banned:	0
   |- Total banned:	0
   `- Banned IP list:

Achten Sie auf die Zeile Journal matches: Sie bestätigt, dass Fail2Ban aus dem systemd-Journal liest und nicht aus einer Logdatei. Das ist korrekt für Ubuntu 24.04 und Debian 12.

Wie richte ich Fail2Ban mit UFW als Bannaktion ein?

Wenn Sie UFW als Firewall verwenden, konfigurieren Sie Fail2Ban so, dass Bannregeln über UFW eingefügt werden. Das ist der einfachere Weg und für die meisten Setups geeignet.

Erstellen Sie eine Standarddatei, die UFW als Bannaktion festlegt. Der Dateiname zz-defaults.conf ist beabsichtigt: Unter Ubuntu 24.04 liefert das Paket defaults-debian.conf, das banaction = nftables setzt. Ihre Datei muss alphabetisch dahinter sortiert werden, um diesen Standard zu überschreiben.

sudo tee /etc/fail2ban/jail.d/zz-defaults.conf > /dev/null << 'EOF'
[DEFAULT]
banaction = ufw
banaction_allports = ufw
backend = systemd
EOF

Neustarten und überprüfen:

sudo systemctl restart fail2ban
sudo fail2ban-client status sshd

Wenn Fail2Ban eine IP sperrt, führt es ufw insert 1 deny from <IP> to any aus. Prüfen Sie die UFW-Regeln nach einer Sperre:

sudo ufw status numbered

Sie sehen die Deny-Regeln von Fail2Ban oben in der Liste.

Wie konfiguriere ich Fail2Ban für nftables statt iptables?

Für Produktionsserver, die nftables direkt verwenden (ohne UFW), nutzen Sie die Bannaktion nftables-multiport. Fail2Ban erstellt eine eigene nftables-Tabelle und verwaltet die Bannregeln dort, ohne Ihr bestehendes Regelwerk zu beeinflussen.

Erstellen Sie die Standarddatei. Unter Ubuntu 24.04 setzt defaults-debian.conf bereits banaction = nftables, dieser Schritt ist also technisch optional. Es ist dennoch gute Praxis, explizit zu sein. Unter Debian 12 ist diese Datei erforderlich.

sudo tee /etc/fail2ban/jail.d/zz-defaults.conf > /dev/null << 'EOF'
[DEFAULT]
banaction = nftables-multiport
banaction_allports = nftables[type=allports]
chain = input
backend = systemd
EOF

Neustarten und überprüfen:

sudo systemctl restart fail2ban
sudo fail2ban-client status sshd

Um die nftables-Integration zu bestätigen, listen Sie die Fail2Ban-Tabelle auf:

sudo nft list tables

Die Ausgabe zeigt eine Tabelle namens inet f2b-table sehen. Nach einer Sperre können Sie deren Inhalt inspizieren:

sudo nft list table inet f2b-table

Vergleich der Bannaktionen UFW und nftables

Aspekt	UFW (banaction = ufw)	nftables (banaction = nftables-multiport)
Bannbefehl	ufw insert 1 deny from <IP>	Fügt IP zu einem nftables-Set hinzu
Wo Regeln erscheinen	ufw status numbered	nft list table inet f2b-table
IPv6-Unterstützung	Ja (UFW verwaltet es)	Ja (inet-Familie)
Persistenz	UFW-Regeln überdauern Neustarts	Fail2Ban wendet sie beim Start erneut an
Performance	Lineare Regelauswertung	Set-basierter Lookup (schneller bei vielen Einträgen)
Geeignet für	Einfache Setups, einzelne Dienste	Produktion, viele Jails, hohe Bannzahlen

Wählen Sie einen Ansatz. Mischen Sie nicht UFW- und nftables-Bannaktionen auf demselben Server.

Wie setze ich meine IP-Adresse in Fail2Ban auf die Whitelist?

Fügen Sie Ihre IP zu ignoreip hinzu, um sich nicht selbst auszusperren. Das ist wichtig. Wenn Sie Ihr Passwort dreimal falsch eingeben, sperrt Fail2Ban Ihre eigene IP. Sie verlieren den SSH-Zugang.

Fügen Sie Ihre IP zu den Standardeinstellungen hinzu:

sudo tee /etc/fail2ban/jail.d/01-whitelist.conf > /dev/null << 'EOF'
[DEFAULT]
ignoreip = 127.0.0.1/8 ::1 YOUR_IP_HERE
EOF

Ersetzen Sie YOUR_IP_HERE durch Ihre tatsächliche öffentliche IP. Sie können sie ermitteln, indem Sie curl -4 ifconfig.me auf Ihrem lokalen Rechner ausführen. Fügen Sie mehrere IPs durch Leerzeichen getrennt hinzu.

Neustarten und überprüfen, ob die Whitelist geladen ist:

sudo systemctl restart fail2ban
sudo fail2ban-client get sshd ignoreip

Die Ausgabe listet alle freigegebenen IPs und Bereiche auf. Bestätigen Sie, dass Ihre IP in der Liste erscheint.

Warnung: Wenn Sie sich von einer dynamischen IP verbinden, bietet das Whitelisting nur begrenzten Schutz. Halten Sie einen alternativen Zugangsweg bereit (Konsolenzugang über das Panel Ihres Hosting-Anbieters) als Backup für den Fall einer Sperrung.

Wie schütze ich Nginx mit benutzerdefinierten Fail2Ban-Jails?

Fail2Ban wird mit mehreren Nginx-Filtern geliefert. Die nützlichsten sind nginx-http-auth für Brute-Force auf HTTP-Basic-Authentifizierung und nginx-botsearch für Scanner, die nicht existierende Pfade abfragen. Sie können auch benutzerdefinierte Filter für anwendungsspezifische Muster schreiben.

nginx-http-auth-Jail

Diese Jail sperrt IPs, die wiederholt bei der HTTP-Basic-Authentifizierung scheitern. Sie liest das Nginx-Fehlerlog.

sudo tee /etc/fail2ban/jail.d/nginx-http-auth.conf > /dev/null << 'EOF'
[nginx-http-auth]
enabled = true
port = http,https
logpath = /var/log/nginx/error.log
maxretry = 3
findtime = 600
bantime = 3600
EOF

nginx-botsearch-Jail

Diese Jail fängt Bots ab, die nach verwundbaren Pfaden scannen (/wp-admin, /phpmyadmin, /.env). Sie liest das Nginx-Zugriffslog auf 404-Antworten.

sudo tee /etc/fail2ban/jail.d/nginx-botsearch.conf > /dev/null << 'EOF'
[nginx-botsearch]
enabled = true
port = http,https
logpath = /var/log/nginx/access.log
maxretry = 5
findtime = 600
bantime = 7200
EOF

Benutzerdefinierter Filter: übermäßige 4xx-Fehler sperren

Für Anwendungen hinter Nginx möchten Sie möglicherweise IPs sperren, die zu viele 4xx-Fehler erzeugen. Das fängt Credential Stuffing, API-Missbrauch und Pfadaufzählung ab. Die integrierten Filter decken dies nicht ab, erstellen Sie daher einen benutzerdefinierten Filter.

Erstellen Sie die Filterdatei:

sudo tee /etc/fail2ban/filter.d/nginx-4xx.conf > /dev/null << 'EOF'
[Definition]
failregex = ^<HOST> - \S+ \[.*\] "[A-Z]+ .+" (400|401|403|404|405) \d+
ignoreregex = ^<HOST> - \S+ \[.*\] "[A-Z]+ /favicon\.ico
              ^<HOST> - \S+ \[.*\] "[A-Z]+ /robots\.txt
EOF

Die failregex trifft auf Zeilen im Nginx-Zugriffslog zu, bei denen die Antwort ein 4xx-Statuscode ist. Die ignoreregex schließt häufige False Positives wie favicon.ico- und robots.txt-Anfragen aus.

Erstellen Sie die Jail:

sudo tee /etc/fail2ban/jail.d/nginx-4xx.conf > /dev/null << 'EOF'
[nginx-4xx]
enabled = true
port = http,https
filter = nginx-4xx
logpath = /var/log/nginx/access.log
maxretry = 20
findtime = 600
bantime = 3600
EOF

Der höhere maxretry-Wert von 20 vermeidet das Sperren legitimer Nutzer, die beim normalen Surfen auf ein paar 404er stoßen.

Starten Sie Fail2Ban neu und prüfen Sie, ob alle Jails geladen sind:

sudo systemctl restart fail2ban
sudo fail2ban-client status

Erwartete Ausgabe mit allen aktiven Jails:

Status
|- Number of jail:      4
`- Jail list:   nginx-4xx, nginx-botsearch, nginx-http-auth, sshd

Mehr zum Schutz von Nginx auf Anwendungsebene finden Sie in der Anleitung zum Nginx Rate Limiting.

Wie teste ich Fail2Ban-Filter mit fail2ban-regex?

Testen Sie den Filter gegen echte Logs, bevor Sie eine Jail aktivieren. Das Tool fail2ban-regex führt einen Filter gegen eine Logdatei aus und meldet Treffer. So vermeiden Sie Filter, die entweder nichts treffen (nutzlos) oder alles treffen (sperren legitime Nutzer).

Testen Sie den benutzerdefinierten nginx-4xx-Filter:

sudo fail2ban-regex /var/log/nginx/access.log /etc/fail2ban/filter.d/nginx-4xx.conf

Beispielausgabe:

Running tests
=============

Use   failregex filter file : nginx-4xx, basedir: /etc/fail2ban
Use         log file : /var/log/nginx/access.log
Use         encoding : utf-8

Results
=======

Failregex: 42 total
|-  #) [# of hits] regular expression
|   1) [42] ^<HOST> - \S+ \[.*\] "[A-Z]+ .+" (400|401|403|404|405) \d+
`-

Ignoreregex: 3 total

Date template hits:
...

Lines: 1842 lines, 0 ignored, 42 matched, 1800 missed

Achten Sie auf die Ausgabe: 42 Treffer von 1842 Zeilen. Das ist ein vernünftiges Verhältnis. Wenn der Filter 90 % der Zeilen trifft, ist die Regex zu breit. Wenn er 0 Zeilen trifft, ist entweder die Regex falsch oder das Log enthält noch keine 4xx-Fehler.

Um die getroffenen Zeilen anzuzeigen:

sudo fail2ban-regex --print-all-matched /var/log/nginx/access.log /etc/fail2ban/filter.d/nginx-4xx.conf

Um die nicht getroffenen Zeilen anzuzeigen (nützlich zum Feintuning):

sudo fail2ban-regex --print-all-missed /var/log/nginx/access.log /etc/fail2ban/filter.d/nginx-4xx.conf

Testen Sie den integrierten sshd-Filter gegen das systemd-Journal:

sudo fail2ban-regex systemd-journal /etc/fail2ban/filter.d/sshd.conf

Wie richte ich die Recidive-Jail für Wiederholungstäter ein?

Die Recidive-Jail überwacht das eigene Log von Fail2Ban. Wenn eine IP mehrfach in beliebigen Jails gesperrt wird, verhängt die Recidive-Jail eine längere Sperre. Das ist eine Eskalation: erstes Vergehen = 1 Stunde, Wiederholungstäter = 1 Woche.

Auf einem ausgelasteten Produktionsserver ist die Recidive-Jail das, was hartnäckige Angreifer tatsächlich fernhält.

sudo tee /etc/fail2ban/jail.d/recidive.conf > /dev/null << 'EOF'
[recidive]
enabled = true
logpath = /var/log/fail2ban.log
banaction = %(banaction_allports)s
maxretry = 3
findtime = 86400
bantime = 604800
EOF

Parameter	Wert	Bedeutung
logpath	/var/log/fail2ban.log	Fallback-Logpfad. Mit backend = systemd liest Fail2Ban stattdessen seine eigenen Journal-Einträge (der Recidive-Filter hat eine eingebaute journalmatch-Direktive)
maxretry	3	Löst nach 3 Sperren durch andere Jails aus
findtime	86400	Schaut 24 Stunden zurück (86400 Sekunden)
bantime	604800	Sperrt für 1 Woche (604800 Sekunden)
banaction	%(banaction_allports)s	Blockiert alle Ports, nicht nur den, der die Sperre ausgelöst hat

Der Recidive-Filter wird mit Fail2Ban unter /etc/fail2ban/filter.d/recidive.conf geliefert. Sie müssen ihn nicht erstellen.

Neustarten und überprüfen:

sudo systemctl restart fail2ban
sudo fail2ban-client status recidive

Wie überwache ich Sperren und entsperre eine IP-Adresse?

Fail2Ban stellt fail2ban-client für alle Überwachungs- und Verwaltungsaufgaben bereit. Diese Befehle funktionieren unabhängig von Ihrem Bannaktion-Backend.

Gesamtstatus prüfen

sudo fail2ban-client status

Listet alle aktiven Jails und ihre Sperrenzähler auf.

Eine bestimmte Jail prüfen

sudo fail2ban-client status sshd

Zeigt aktuell gesperrte IPs, Gesamtsperren und aktuelle Fehler an.

Eine IP manuell sperren

sudo fail2ban-client set sshd banip 203.0.113.50

Eine IP entsperren

sudo fail2ban-client set sshd unbanip 203.0.113.50

Wenn die IP durch die Recidive-Jail gesperrt wurde, entsperren Sie sie dort ebenfalls:

sudo fail2ban-client set recidive unbanip 203.0.113.50

Prüfen, welche Bannaktion eine Jail verwendet

sudo fail2ban-client get sshd actions

Konfiguration ohne Neustart neu laden

sudo fail2ban-client reload

Fail2Ban-Log lesen

journalctl -u fail2ban -f

Dies verfolgt das Fail2Ban-Dienstlog in Echtzeit. Sie sehen Sperr- und Entsperr-Ereignisse, sobald sie eintreten.

Das Fail2Ban-Anwendungslog mit Sperrdetails:

sudo tail -f /var/log/fail2ban.log

Befehlsreferenz für fail2ban-client

Befehl	Zweck
fail2ban-client status	Alle Jails auflisten
fail2ban-client status <jail>	Jail-Details und gesperrte IPs anzeigen
fail2ban-client set <jail> banip <IP>	Eine IP manuell sperren
fail2ban-client set <jail> unbanip <IP>	Eine IP entsperren
fail2ban-client reload	Gesamte Konfiguration neu laden
fail2ban-client reload <jail>	Eine einzelne Jail neu laden
fail2ban-client get <jail> bantime	Sperrdauer anzeigen
fail2ban-client get <jail> findtime	Fehlerfenster anzeigen
fail2ban-client get <jail> maxretry	Versuchsschwelle anzeigen
fail2ban-client get <jail> ignoreip	Freigegebene IPs anzeigen
fail2ban-client get <jail> actions	Verwendete Bannaktion anzeigen

End-to-End-Verifizierung: eine Sperre auslösen und bestätigen

Gehen Sie nicht davon aus, dass Ihre Konfiguration funktioniert. Testen Sie sie. Lösen Sie eine echte Sperre aus und überprüfen Sie die gesamte Kette: Logerkennung, Bannaktion, Firewallregel und Entsperrung.

Schritt 1: Versuchen Sie von einem anderen Rechner (nicht Ihrer freigegebenen IP) SSH-Logins mit falschem Passwort. Nach 3 Fehlern (entsprechend maxretry) sollte die Verbindung abgelehnt werden.

Wenn Sie keinen zweiten Rechner haben, simulieren Sie eine Sperre mit fail2ban-client:

sudo fail2ban-client set sshd banip 198.51.100.25

Schritt 2: Überprüfen Sie, ob die Sperre erfasst wurde:

sudo fail2ban-client status sshd

Die gesperrte IP sollte in Banned IP list erscheinen.

Schritt 3: Überprüfen Sie, ob die Firewallregel existiert.

Für UFW:

sudo ufw status numbered | grep 198.51.100.25

Für nftables:

sudo nft list table inet f2b-table

Die IP sollte in einem Set innerhalb der Tabelle erscheinen.

Schritt 4: Entsperren und Entfernung überprüfen:

sudo fail2ban-client set sshd unbanip 198.51.100.25
sudo fail2ban-client status sshd

Die IP sollte nicht mehr in der Sperrliste erscheinen. Prüfen Sie die Firewall erneut, um zu bestätigen, dass die Regel entfernt wurde.

Referenz der Fail2Ban-Konfigurationsparameter

Parameter	Standard	Empfohlen	Beschreibung
bantime	10m	1h oder 3600	Dauer der Sperre
findtime	10m	10m oder 600	Fenster für die Fehlerzählung
maxretry	5	3 für SSH, 5-20 für Web	Fehler vor der Sperrung
ignoreip	127.0.0.1/8 ::1	Eigene IP hinzufügen	IPs, die nie gesperrt werden
banaction	nftables (Ubuntu 24.04), iptables-multiport (Upstream)	ufw oder nftables-multiport	Auszuführender Firewall-Befehl
backend	auto	systemd	Log-Quelle (systemd-Journal auf modernen Distributionen)
destemail	root@localhost	Ihre E-Mail	Empfänger der Warnmeldungen
action	%(action_)s	%(action_mwl)s für E-Mail-Benachrichtigungen	Aktion bei Sperrung

Etwas funktioniert nicht?

Fail2Ban startet nicht: Prüfen Sie die Syntaxfehler in Ihren Jail-Dateien. Eine fehlende Klammer oder ein ungültiger Wert verhindert den Start.

sudo fail2ban-client -t

Dieser Befehl testet die Konfiguration, ohne den Dienst zu starten. Beheben Sie alle gemeldeten Fehler.

Jail zeigt 0 Treffer, obwohl Angriffe stattfinden: Der backend ist wahrscheinlich falsch. Unter Ubuntu 24.04 und Debian 12 verwenden Sie backend = systemd. Wenn Sie backend = auto verwenden und das System kein /var/log/auth.log hat, liest Fail2Ban nichts.

Gesperrte IP kann sich weiterhin verbinden: Die Bannaktion stimmt nicht mit Ihrer Firewall überein. Wenn Sie UFW verwenden, setzen Sie banaction = ufw. Wenn Sie nftables direkt verwenden, setzen Sie banaction = nftables-multiport. Prüfen Sie, ob die Firewallregel nach einer Sperre tatsächlich existiert.

Sie haben sich selbst gesperrt: Greifen Sie über die Webkonsole Ihres Hosting-Anbieters (VNC/KVM) auf Ihren Server zu. Von dort aus:

sudo fail2ban-client set sshd unbanip YOUR_IP

Oder stoppen Sie Fail2Ban vollständig:

sudo systemctl stop fail2ban

Korrigieren Sie dann Ihre ignoreip-Konfiguration und starten Sie neu.

Fail2Ban verbraucht zu viel Speicher: Auf Servern mit großen Logdateien kann Fail2Ban viel Speicher verbrauchen. Setzen Sie dbpurgeage, um die Datenbankgröße zu begrenzen:

sudo tee /etc/fail2ban/jail.d/99-performance.conf > /dev/null << 'EOF'
[DEFAULT]
dbpurgeage = 7d
EOF

---

Copyright 2026 Virtua.Cloud. Alle Rechte vorbehalten. Dieser Inhalt ist ein Originalwerk des Virtua.Cloud-Teams. Vervielfältigung, Wiederveröffentlichung oder Weiterverbreitung ohne schriftliche Genehmigung ist untersagt.