ownCloud mit Fail2ban absichern

7. Juni 2016 23. Dezember 2021 / Home-Server / 26 Kommentare

Im letzten Artikel ging es um die Einrichtung von ownCloud 9 auf Ubuntu Server mit nginx, MariaDB, PHP 7 und Let’s Encrypt. Da in der persönlichen Cloud zumeist sensible Daten gespeichert werden, sollte das Thema Sicherheit hier nicht zu kurz kommen. Daher zeigt der folgende Artikel eine einfache, aber dennoch effektive Möglichkeit, ownCloud mittels Fail2ban abzusichern.

Update 14.08.2016: ownCloud-Filter wird nun in der (globalen) defaults-debian.conf angegeben. bantime ist eine Angabe in Sekunden (nicht Minuten wie hier vorher fälschlicherweise angegeben war).

Anfälliger ownCloud Login

Da die eigene Cloud praktischerweise von überall aus erreichbar sein soll, muss diese direkt über das Internet erreichbar sein. Meistens wird man hier einen DynDNS-Dienst verwenden und ein entsprechendes Port-Forwarding (Ports 80 und 443) im Router einrichten. Mit der Eingabe der richtigen URL im Browser bekommt man dann die Login-Maske zu sehen, die einen Benutzernamen nebst dazugehörigem Passwort erwartet. Gibt man nun einen nicht vorhandenen Benutzer und/oder ein falsches Passwort ein, schlägt der Login logischerweise fehl. Nun gibt es bei ownCloud allerdings keine Möglichkeit, die Anzahl der Login-Versuche zu beschränken. Dies macht ownCloud prinzipiell anfällig für Brute-Force-Angriffe, besonders, wenn nur ein schwaches Kennwort zum Login benötigt wird.

Funktionsweise Fail2ban

Eine mögliche Lösung dieses Problems bietet Fail2ban: Das Programm analysiert Log-Dateien (beliebiger) Programme. Werden hier verdächtige Aktivitäten erkannt (zu viele Login-Versuche, Ausnutzen von Exploits, etc.), die einer IP zugeordnet werden können, kann eine bestimmte Aktion ausgeführt werden. In den meisten Fällen möchte man dann die IP-Adresse für einen bestimmten Zeitraum sperren. Dies wird von Fail2ban mit der Anpassung der Firewall-Regeln ermöglicht. Die einzige Voraussetzung dabei ist, dass das zu überwachende Programm die IP-Adressen bei verdächtigen Aktivitäten mit loggt.

Fail2ban kommt dabei bereits schon mit vorkonfigurierten Filtern (z.B. für Apache oder auch nginx). Leider fehlt hier ein Filter speziell für ownCloud – dieser muss manuell angelegt werden.

Vorbereitung ownCloud

Damit ownCloud mit Fail2ban abgesichert werden kann, sollte zunächst einmal sichergestellt sein, dass die ownCloud-Log-Einträge mit dem richtigen Zeitstempel versehen werden. Dies kann man z.B. in der Administrator-Oberfläche von ownCloud kontrollieren: Die hier aufgelisteten Einträge sind die Inhalte der Log-Datei von ownCloud (diese liegt im Datenverzeichnis, z.B. /var/owncloud_data/owncloud.log) und müssen mit der Systemzeit übereinstimmen.

Falls dies nicht der Fall ist und die Log-Einträge beispielsweise um eine Stunde abweichen, dann kann man in der ownCloud-Konfiguration explizit die Zeitzone der Log-Einträge angeben:

nano /var/www/owncloud/config/config.php

Hier ist folgende Zeile am Ende zu ergänzen:

'logtimezone' => 'Europe/Berlin',

Nun sollten die Logeinträge mit der lokalen Zeit übereinstimmen. Testen kann man dies, indem man sich absichtlich mit einem falschen Passwort einzuloggen versucht. In der Admin-Oberfläche (und damit dem ownCloud-Log) sollte daraufhin dieser fehlgeschlagene Login-Versuch dokumentiert worden sein.

Sonderfall: ownCloud hinter Proxy

Im Artikel ownCloud 9 auf Ubuntu Server 16.04 LTS mit nginx, MariaDB, PHP 7 und Let’s Encrypt wird nginx als Reverse-Proxy verwendet. Hier empfängt ein virtueller Host (Gateway-Host) alle Anfragen an den Webserver und leitet diese dann an spezialisierte virtuelle Hosts (z.B. für ownCloud) weiter (proxy_pass).

In diesem Szenario ist es in Verbindung mit Fail2ban wichtig, dass das Backend (virtueller Host für ownCloud, bzw. der entsprechende PHP-Handler) die echte IP-Adresse des Remote-Hosts erhält.
Folgende Anweisungen sind nur dann wichtig, wenn der Webserver als Reverse-Proxy fungiert. Wenn ein virtueller Host „direkt“ für ownCloud zuständig ist, müssen diese Schritte nicht ausgeführt werden.

Zunächst muss die echte IP des Remote-Hosts durch den Proxy weitergeleitet werden. Dazu muss im location-Block, der für den proxy_pass verantwortlich ist, folgende Zeile enthalten sein:

proxy_set_header X-Real-IP $remote_addr;

Im virtuellen Host für ownCloud muss dann im PHP-Handler folgende Zeile hinzugefügt werden, damit die echte IP des Remote-Hosts auch an PHP weitergereicht wird:

fastcgi_param REMOTE_ADDR $http_x_real_ip;

Für andere Webserver (z.B. Apache) sind analoge Schritte durchzuführen.

Wenn die echte Remote-IP in einem Proxy-Szenario nicht an ownCloud/PHP weitergeleitet wird, kann Fail2ban später nicht richtig funktionieren, da die falsche IP-Adresse gebannt wird.

Installation und Einrichtung Fail2ban

Nach dem obligatorischen

apt-get update && apt-get upgrade

kann Fail2ban installiert werden:

apt-get install fail2ban

Anschließend wird ein spezielle ownCloud-Filter für Fail2ban angelegt:

nano /etc/fail2ban/filter.d/owncloud.conf

In dieser Datei wird über einen regulären Ausdruck (Regex) der Log-Eintrag von ownCloud für einen fehlgeschlagenen Login-Versuch beschrieben:

[Definition]
failregex={"reqId":".*","remoteAddr":".*","app":"core","message":"Login failed: '.*' \(Remote IP: '<HOST>'\)","level":2,"time":".*"}

ignoreregex =

Nun muss der soeben angelegte Filter noch von fail2ban beim Start geladen werden. Dazu öffnet man folgende Datei:

nano etc/fail2ban/jail.d/defaults-debian.conf

Und fügt folgenden Inhalt am Ende ein:

[owncloud]
enabled = true
port = 80,443
protocol = tcp
filter = owncloud
maxretry = 3
bantime = 5400
logpath = /var/owncloud_data/owncloud.log

Wichtig ist hier die Angabe der ownCloud-Log-Datei unter logpath (/var/owncloud_data/owncloud.log). Wenn man einen anderen Datenpfad für ownCloud definiert hat, muss dieses Verzeichnis hier angepasst werden.

Die Einträge für maxretry und bantime sagen aus, dass maximal 3 Login-Versuche möglich sind, bevor ein temporärer Ban für 5400 Sekunden (1,5 Stunden) aktiviert wird. Wird bei bantime eine negative Zahl angegeben, wirkt jeder Ban dauerhaft.

Mit dem Befehl

service fail2ban restart

wird Fail2ban anschließend neu gestartet, damit die neue Konfiguration geladen wird.

Nun sollte noch kontrolliert werden, ob der Filter für ownCloud korrekt geladen wurde:

fail2ban-client status

Hier muss in der Jail list nun auch owncloud aufgeführt werden.

Test mit Fail2ban

Nun sollte man in jedem Fall kurz testen, ob die Konfiguration von Fail2ban korrekt greift.

Wenn vorher schon ein Login-Versuch mit (absichtlich) falschen Daten erfolgt ist, kann man den regulären Ausdruck der Fail2ban-ownCloud-Konfiguration mit folgendem Befehl testen:

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

Hier werden alle Log-Einträge angezeigt, die vom angegebenen Regex-Ausdruck erfasst wurden:

Test des Fail2ban-Regex gegen die ownCloud-Log-Datei

Nun kann man nochmals versuchen, sich mit falschen Login-Daten an die ownCloud anzumelden. Nach dem dritten Versuch sollte die ownCloud nicht mehr erreichbar sein und ein Fehler im Browser angezeigt werden:

Nach dem dritten Login-Versuch ist Schluss... — Nach dem dritten Login-Versuch ist Schluss…

Um sich nun die gebannte IP anzeigen zu lassen, kann man folgenden Befehl verwenden:

fail2ban-client status owncloud

Hier sollte nun die eigene IP gelistet werden.

Entsperren kann man diese IP mit dem Befehl:

fail2ban-client set owncloud unbanip <IP>

Im Fail2ban-Wiki gibt es eine Liste mit allen verfügbaren Befehlen.

Vertrauen ist gut, Kontrolle ist besser

Auch wenn man ownCloud mit Fail2ban gegen zu viele fehgeschlagene Login-Versuche abgesichert hat, sollte man sich hin und wieder die Zeit nehmen, um in den Log-Dateien nach verdächtigen Aktivitäten Ausschau zu halten:

/var/log/nginx/access.log: nginx-Log, in dem sämtliche Zugriffe geloggt werden
/var/owncloud_data/owncloud.log: Log-Datei von ownCloud (auch über die Admin-Oberfläche zugänglich)
/var/log/fail2ban.log: Fail2ban-Log; hier werden alle Ban-Vorgänge dokumentiert

Fazit

Mit Fail2ban kann man in wenigen Schritten einen wirkungsvollen Schutz gegen Brute-Force-Angriffe konfigurieren. Weil das Verfahren darüber hinaus nur mit wenig Aufwand verbunden ist, empfiehlt es sich in jedem Fall, seine eigene Cloud auf diese Weise abzusichern.

Weiterführende Artikel

Links

26 Kommentare zu „ownCloud mit Fail2ban absichern“

Hans
23. Juni 2016 um 20:48 Uhr

Hallo Jan,

vielen Dank für das Tutorial. Es funktioniert wunderbar.

Grüße
Hans

Antworten
Major
13. August 2016 um 19:43 Uhr

Inzwischen wurde für fail2ban ja auch ein modulares Konfigurationsmanagment eingeführt.

Das beschriebene „jail“ legt man daher am besten unter /etc/fail2ban/jail.d/ in der vorhandenen defaults-debian.conf oder besser als neue Datei owncloud.conf ab. Das obige Vorgehen führte bei mir immer dazu, daß fail2ban nicht gestartet werden konnte, als eigenes Jail in jail.d lief es problemlos.

Noch eine Anmerkung: Auch unter Nextcloud 9.0.50 scheint das Log immer noch owncloud.log zu heißen…

Desweiteren ist da oben ein ganz erheblicher Fehler gemacht worden: die bantime ist ist in Sekunden, am obigen Beispiel sind es also 180 SEKUNDEN, nicht Minuten. Das reicht zwar, um die meisten Brute-Force-Bots nach 3-4 Versuchen (Fail2ban ‚feuert‘ manchmal erst nach 4-5 Fehlern, auch wenn 3 retries eingestellt sind) abzubrechen, aber sollte man wissen, daß der Ban nach 3 Minuten schon wieder weg ist, bei „Bantime=180“

Gruß,

Major

Antworten
1. Jan
  14. August 2016 um 12:57 Uhr
  
  Hallo Major,
  
  danke für deine Hinweise, habe den Artikel angepasst. Besonders das mit der bantime ist mir bei meinen Tests nicht weiter aufgefallen. Aber diese Angabe stellt wirklich Sekunden und nicht Minuten dar.
  
  Bei Nextcloud heißt das Log immer noch ownCloud.log, ja. Habe mich da auch schon gewundert, aber man findet echt noch viele Hinweise, dass Nextcloud 9.0.50 recht schnell zusammengeschustert wurde. Ich hoffe mal, dass sich das zu Version 10 ändern wird. Übrigens wird man für Nextcloud 10 keinen jail2ban-Filter mehr benötigen, da hier ein Brute-Force-Schutz mit eingebaut sein soll.
  
  Gruß,
  Jan
  
  Antworten
Ingo
13. September 2016 um 11:25 Uhr

Hallo Jan,

in der owncloud.log Wirt ja nur die Öffentliche IP eingetragen.
Man kann ja in der jail.local bei ignoreip IP-Adressen die nicht gesperrt werden sollen eintragen, da habe ich meine Heim Netzwerk Adresse vom Computer eingetragen.
Wenn ich mich jetzt x mal verkehrt anmelde werde ich ja trotzdem gesperrt.
Gibt es da eine Möglichkeit das zu ändern?

Und kann man auch die owncloud.log von /var/www/owncloud/data/ nach /var/log/ verlgen?

Bis dann
Ingo

Antworten
1. Jan
  14. September 2016 um 7:09 Uhr
  
  Hi Ingo,
  
  du wirst vermutlich auch über die (öffentliche) DynDNS-Adresse auf die Cloud zugreifen. Dann ist die Client-IP auch immer deine öffentliche IP im Internet und nicht deine lokale (LAN)-)IP. Also verhält sich das zunächst einmal wie erwartet.
  Du könntest nun natürlich über die lokale IP auf die Cloud zugreifen (z.B. http://192.168.178.20/owncloud). Dann wird auch die lokale IP des Clients verwendet. Hier sollte dann die jail2ban Whitelist greifen. Das Ganze geht natürlich nur, wenn der ownCloud-Server und der Client sich im gleichen Netzwerk befinden.
  
  Die Log-Datei kannst du auf verschiedene Arten konfigurieren (siehe ownCloud Admin Manual). In deinem Fall sollte ein 'logfile' => '/var/log/owncloud.log', in der config.php ausreichen.
  
  Gruß,
  Jan
  
  Antworten
  1. Ingo
    14. September 2016 um 15:39 Uhr
    
    Hallo
    
    Dass mit der IP-Adresse ist richtig habe immer mit der DynDNS-Adresse auf owncloud zugegriffen mache ich das mit der lokale IP ist auch die in der Liste.
    
    Das mit der Verlegung von owncloud.log funktioniert nicht ganz so. Habe die config.php angepast sowie die /etc/php/7.0/fpm/php.ini und /etc/php/7.0/cli/php.ini da habe ich bei open_basedir noch /var/log hin zu gefügt.
    
    Dan ist folgender Fehler:
    
    is_writable(): open_basedir restriction in effect. File(/var/log) is not within the allowed path(s): (/var/www:/tmp/:/var/owncloud_data:/dev/urandom) at /var/www/owncloud/lib/private/Log/Owncloud.php#55
    
    Bis dann
    Ingo
    
    Antworten
    1. Jan
      15. September 2016 um 6:35 Uhr
      
      Hi Ingo,
      
      versuch es mal mit /var/log/
      
      Gruß,
      Jan
      
      Antworten
      1. Ingo
        18. September 2016 um 17:28 Uhr
        
        Hallo Jan,
        habe den Fehler gefunden habe im Virtuellen Host von ownCloud bei „fastcgi_param PHP_VALUE „open_basedir=/var/www:/tmp/:/var/owncloud_data:“ vergessen das Verzeichnis mit anzugeben. Und man muss auch die Log Datei erstellen und die Zugriffsrechte www-data geben.
        
        Bis dann
        Ingo
G. Krause
1. Januar 2017 um 13:27 Uhr

Ich kann machen, was ich will. Ich bekomme leider immer die Fehlermeldung, dass ich nicht auf debian-default.conf zugreifen kann, weil jail.d nicht existiert (beim Öffnen der der Debian-Default.conf via nano). Die Existenz der Datei bzw. des Ordners ist geprüft, scheint ein Rechteproblem zu sein.

Antworten
1. Jan
  1. Januar 2017 um 13:39 Uhr
  
  Hi,
  
  hast du vor dem Bearbeiten der Dateien mit nano ein sudo -s abgesetzt?
  Damit sollte es eigentlich klappen.
  
  Gruß,
  Jan
  
  Antworten
  1. G. Krause
    1. Januar 2017 um 14:02 Uhr
    
    ja. Wenn ich mich via cd durch den Verzeichnisbaum hangele, schimpft er mich schon an, dass /etc/fail2ban nicht existiert. habe fail2ban schon 2x neu installiert, jedoch keine Besserung beim Patienten bemerkt. Sonst funktioniert alles super.
    
    Antworten
  2. G. Krause
    1. Januar 2017 um 14:04 Uhr
    
    drwxr-xr-x 2 root root 4096 Jan 1 13:57 action.d
    -rw-r–r– 1 root root 2328 Aug 1 2015 fail2ban.conf
    drwxr-xr-x 2 root root 4096 Aug 2 2015 fail2ban.d
    drwxr-xr-x 3 root root 12288 Jan 1 13:58 filter.d
    -rw-r–r– 1 root root 18562 Aug 1 2015 jail.conf
    drwxr-xr-x 2 root root 4096 Jan 1 13:57 jail.d
    -rw-r–r– 1 root root 1939 Aug 1 2015 paths-common.conf
    -rw-r–r– 1 root root 642 Aug 1 2015 paths-debian.conf
    
    Antworten
    1. Jan
      1. Januar 2017 um 14:06 Uhr
      
      Welche Dateien befinden sich in filter.d (nach einer sauberen Installation)? Wie sehen hier die Rechte aus?
      
      Gruß,
      Jan
      
      Antworten
      1. G. Krause
        1. Januar 2017 um 14:19 Uhr
        
        -rw-r–r– 1 root root 442 Aug 1 2015 3proxy.conf
        -rw-r–r– 1 root root 3241 Aug 1 2015 apache-auth.conf
        -rw-r–r– 1 root root 2741 Aug 1 2015 apache-badbots.conf
        -rw-r–r– 1 root root 1273 Aug 1 2015 apache-botsearch.conf
        -rw-r–r– 1 root root 813 Aug 1 2015 apache-common.conf
        -rw-r–r– 1 root root 268 Aug 1 2015 apache-fakegooglebot.conf
        -rw-r–r– 1 root root 402 Aug 1 2015 apache-modsecurity.conf
        -rw-r–r– 1 root root 596 Aug 1 2015 apache-nohome.conf
        -rw-r–r– 1 root root 1187 Aug 1 2015 apache-noscript.conf
        -rw-r–r– 1 root root 2000 Aug 1 2015 apache-overflows.conf
        -rw-r–r– 1 root root 346 Aug 1 2015 apache-pass.conf
        -rw-r–r– 1 root root 1014 Aug 1 2015 apache-shellshock.conf
        -rw-r–r– 1 root root 1156 Aug 1 2015 assp.conf
        -rw-r–r– 1 root root 2328 Aug 1 2015 asterisk.conf
        -rw-r–r– 1 root root 513 Aug 1 2015 botsearch-common.conf
        -rw-r–r– 1 root root 1781 Aug 1 2015 common.conf
        -rw-r–r– 1 root root 252 Aug 1 2015 counter-strike.conf
        -rw-r–r– 1 root root 393 Aug 1 2015 courier-auth.conf
        -rw-r–r– 1 root root 482 Aug 1 2015 courier-smtp.conf
        -rw-r–r– 1 root root 443 Aug 1 2015 cyrus-imap.conf
        -rw-r–r– 1 root root 345 Aug 1 2015 directadmin.conf
        -rw-r–r– 1 root root 1571 Aug 1 2015 dovecot.conf
        -rw-r–r– 1 root root 1696 Aug 1 2015 dropbear.conf
        -rw-r–r– 1 root root 557 Aug 1 2015 drupal-auth.conf
        -rw-r–r– 1 root root 1282 Aug 1 2015 ejabberd-auth.conf
        -rw-r–r– 1 root root 403 Aug 1 2015 exim-common.conf
        -rw-r–r– 1 root root 1379 Aug 1 2015 exim.conf
        -rw-r–r– 1 root root 2158 Aug 1 2015 exim-spam.conf
        -rw-r–r– 1 root root 942 Aug 1 2015 freeswitch.conf
        -rw-r–r– 1 root root 1209 Aug 1 2015 froxlor-auth.conf
        -rw-r–r– 1 root root 236 Aug 1 2015 groupoffice.conf
        -rw-r–r– 1 root root 322 Aug 1 2015 gssftpd.conf
        -rw-r–r– 1 root root 512 Aug 1 2015 guacamole.conf
        -rw-r–r– 1 root root 404 Aug 1 2015 horde.conf
        drwxr-xr-x 2 root root 4096 Jan 1 13:57 ignorecommands
        -rw-r–r– 1 root root 482 Aug 1 2015 kerio.conf
        -rw-r–r– 1 root root 323 Aug 1 2015 lighttpd-auth.conf
        -rw-r–r– 1 root root 350 Aug 1 2015 monit.conf
        -rw-r–r– 1 root root 886 Aug 1 2015 mysqld-auth.conf
        -rw-r–r– 1 root root 400 Aug 1 2015 nagios.conf
        -rw-r–r– 1 root root 1594 Aug 1 2015 named-refused.conf
        -rw-r–r– 1 root root 161 Dez 31 14:56 nextcloud.conf
        -rw-r–r– 1 root root 528 Aug 1 2015 nginx-botsearch.conf
        -rw-r–r– 1 root root 442 Aug 1 2015 nginx-http-auth.conf
        -rw-r–r– 1 root root 716 Aug 1 2015 nsd.conf
        -rw-r–r– 1 root root 495 Aug 1 2015 openwebmail.conf
        -rw-r–r– 1 root root 1905 Aug 1 2015 oracleims.conf
        -rw-r–r– 1 root root 161 Jan 1 13:58 owncloud.conf
        -rw-r–r– 1 root root 814 Aug 1 2015 pam-generic.conf
        -rw-r–r– 1 root root 568 Aug 1 2015 perdition.conf
        -rw-r–r– 1 root root 834 Aug 1 2015 php-url-fopen.conf
        -rw-r–r– 1 root root 188 Aug 1 2015 portsentry.conf
        -rw-r–r– 1 root root 951 Aug 1 2015 postfix.conf
        -rw-r–r– 1 root root 447 Aug 1 2015 postfix-rbl.conf
        -rw-r–r– 1 root root 468 Aug 1 2015 postfix-sasl.conf
        -rw-r–r– 1 root root 1216 Aug 1 2015 proftpd.conf
        -rw-r–r– 1 root root 2335 Aug 1 2015 pure-ftpd.conf
        -rw-r–r– 1 root root 795 Aug 1 2015 qmail.conf
        -rw-r–r– 1 root root 1286 Aug 1 2015 recidive.conf
        -rw-r–r– 1 root root 1367 Aug 1 2015 roundcube-auth.conf
        -rw-r–r– 1 root root 517 Aug 1 2015 selinux-common.conf
        -rw-r–r– 1 root root 570 Aug 1 2015 selinux-ssh.conf
        -rw-r–r– 1 root root 330 Aug 1 2015 sendmail-auth.conf
        -rw-r–r– 1 root root 2424 Aug 1 2015 sendmail-reject.conf
        -rw-r–r– 1 root root 371 Aug 1 2015 sieve.conf
        -rw-r–r– 1 root root 472 Aug 1 2015 sogo-auth.conf
        -rw-r–r– 1 root root 1094 Aug 1 2015 solid-pop3d.conf
        -rw-r–r– 1 root root 206 Aug 1 2015 squid.conf
        -rw-r–r– 1 root root 199 Aug 1 2015 squirrelmail.conf
        -rw-r–r– 1 root root 2951 Aug 1 2015 sshd.conf
        -rw-r–r– 1 root root 761 Aug 1 2015 sshd-ddos.conf
        -rw-r–r– 1 root root 363 Aug 1 2015 stunnel.conf
        -rw-r–r– 1 root root 645 Aug 1 2015 suhosin.conf
        -rw-r–r– 1 root root 821 Aug 1 2015 tine20.conf
        -rw-r–r– 1 root root 374 Aug 1 2015 uwimap-auth.conf
        -rw-r–r– 1 root root 627 Aug 1 2015 vsftpd.conf
        -rw-r–r– 1 root root 444 Aug 1 2015 webmin-auth.conf
        -rw-r–r– 1 root root 520 Aug 1 2015 wuftpd.conf
        -rw-r–r– 1 root root 503 Aug 1 2015 xinetd-fail.conf
G. Krause
1. Januar 2017 um 14:20 Uhr

Ich kann es mir nicht erklären, hatte die gleiche Installation schon mal vor 14 Tagen erfolgreich abgeschlossen.

Antworten
G. Krause
1. Januar 2017 um 15:09 Uhr

alles gut, hab den Eigentümer kurz auf meinen usernamen in der Gruppe root rekursiv gesetzt und dann die Defaults-Debian.cof ergänzt. Danach den Eigentümer wieder auf root:root geändert und jetzt geht es…

Antworten
1. Jan
  1. Januar 2017 um 15:38 Uhr
  
  Hi,
  
  ok, dann klappt es nun bei dir. Danke für die Rückmeldung.
  
  Gruß,
  Jan
  
  Antworten
Hans
28. März 2017 um 18:21 Uhr

Hallo Jan,
kann fail2ban auch für WordPress konfiguriert werden?

Danke Gruß Hans

Antworten
1. Jan
  28. März 2017 um 20:43 Uhr
  
  Hi Hans,
  
  fail2ban kann für alles konfiguriert werden, was fehlgeschlagene Login-Versuche loggt, damit auch WordPress (siehe hier).
  Allerdings geht ähnliches auch mit einem WP-Plugin. Im den meisten Fällen düfte das wohl die einfachste und schnellste Lösung sein.
  
  Gruß,
  Jan
  
  Antworten
  1. Hans
    30. März 2017 um 16:08 Uhr
    
    Hallo Jan,
    
    danke für die Info, ich mach mich mal auf die Suche.
    
    Gruß Hans
    
    Antworten
    1. Jan
      31. März 2017 um 13:55 Uhr
      
      Hi Hans,
      
      das ist vielleicht auch ein guter allgemeiner Tipp:
      Es gibt für so gut wie alle Anforderungen WP-Plugins. Diese kann man auch verwenden, auch wenn es eher Anforderungen an die Webserver-Konfiguration wären. Beispielsweise kann man einen Redirect über nginx/Apache anlegen (low level). Wenn man sich im Umfeld von WP bewegt, ist es in vielen Fällen einfacher, dafür ein WP-Plugin zu verwenden.
      
      Gruß,
      Jan
      
      Antworten
Ben
24. September 2017 um 14:00 Uhr

Hallo Jan,

bei mir kommt nach dem restart von Fail2Ban folgende Fehlermeldung:

Job for fail2ban.service failed because the control process exited with error code. See „systemctl status fail2ban.service“ and „journalctl -xe“ for details.

Systemctl status fail2ban.service gibt dann aus:

fail2ban.service – Fail2Ban Service
Loaded: loaded (/lib/systemd/system/fail2ban.service; enabled; vendor preset: enabled)
Active: inactive (dead) (Result: exit-code) since So 2017-09-24 13:57:27 CEST; 1min 42s ago
Docs: man:fail2ban(1)
Process: 1932 ExecStop=/usr/bin/fail2ban-client stop (code=exited, status=0/SUCCESS)
Process: 1973 ExecStart=/usr/bin/fail2ban-client -x start (code=exited, status=255)
Main PID: 1872 (code=killed, signal=TERM)

Sep 24 13:57:27 SRV systemd[1]: fail2ban.service: Unit entered failed state.
Sep 24 13:57:27 SRV systemd[1]: fail2ban.service: Failed with result ‚exit-code‘.
Sep 24 13:57:27 SRV systemd[1]: fail2ban.service: Service hold-off time over, scheduling restart.
Sep 24 13:57:27 SRV systemd[1]: Stopped Fail2Ban Service.
Sep 24 13:57:27 SRV systemd[1]: fail2ban.service: Start request repeated too quickly.
Sep 24 13:57:27 SRV systemd[1]: Failed to start Fail2Ban Service.

Was kann das sein, bzw. was kann ich tun?

Danke!

Gruß
Ben

Antworten
1. Ben
  24. September 2017 um 14:14 Uhr
  
  Hallo zusammen,
  
  inzwischen konnte ich den Fehler lösen.
  Wenn der Log Pfad in der defaults-debian.conf nicht passt, startet der Service nicht korrekt.
  
  Gruß
  Ben
  
  Antworten
2. Ben
  24. September 2017 um 14:23 Uhr
  
  Allerdings greift die owncloud.conf nicht…
  Über fail2ban-regex /var/owncloud_data/owncloud.log /etc/fail2ban/filter.d/owncloud.conf bekomme ich leider 0 results bzw. 0 matched, allerdings 87 missed?
  
  Antworten
  1. Ben
    24. September 2017 um 14:37 Uhr
    
    Auch dieses Problem konnte ich inzwischen lösen.
    Bei Owncloud 10 hat sich der Aufbau der Log-Dateien geändert sodass die regex angepasst werden müssen.
    
    Die Owncloud.conf muss folgendermaßen angepasst werden:
    
    [INCLUDES]
    before = common.conf
    
    [Definition]
    _daemon = owncloud
    failregex = {„reqId“:“.*“,“level“:2,“time“:“.*“,“remoteAddr“:“.*“,“user“:“–„,“app“:“core“,“method“:“.*“,“message“:“Login failed: ‚.*‘ \(Remote IP: “\)“}
    ignoreregex =
    
    Gruß
    Ben
    
    Antworten
    1. Jan
      24. September 2017 um 14:57 Uhr
      
      Hi Ben,
      
      da haben sich ja alle Probleme von selbst gelöst. ;)
      Danke für den passenden Regex-Ausdruck für ownCloud 10. Ich bin mittlerweile auf Nextcloud umgestiegen und die ownCloud-Serie in meinem Blog wird wohl nicht weiter geführt werden. Dennoch wird deine Ergänzung hier bestimmt anderen Leuten eine Hilfe sein.
      
      Gruß,
      Jan
      
      Antworten