Fail2ban überwacht Logfiles nicht

Mit fail2ban kann man unter Linux Logfiles überwachen und den Server gegen massive Einbruchsversuche über das Netzwerk schützen. Mit fail2ban kann man zum Beispiel den ssh-Daemon absichern oder die access-Logs einer Website kontrollieren und Angreifer vom weiteren Zugriff aussperren.

Ein merkwürdiges Phänomen von fail2ban

Wir setzen als Linux Distribution hauptsächlich Centos ein. Unter Centos 6 funktioniert das Überwachen von apache Logfiles mit fail2ban prima. Sowohl Jails als auch Actions sind ok. Unter Centos7 werden aber bei näherem Hinsehen die Logfiles der nginx/apache Websites nicht wirklich überwacht. In der Konsequenz kann sich der Webserver nicht effektiv gegen verteilte DDOS Angriffe wehren.

Wie bemerkt man dass fail2ban nicht funktioniert?

Im ersten Schritt steigt in der Regel die Last auf dem Centos 7 Server erheblich an. Bei einer Analyse fällt dann auf, daß sehr viele php-fpm Prozesse für eine Website immer aktiv sind. Im konkreten Beispiel war nginx mit php-fpm installiert. Das Vorgehen wäre aber auch bei einem Apache2 im Wesentlichen identisch.

Sofern man sich das Logfile der Web-Domain näher anschaut, stößt man auf folgenden Einträge.

66.33.212.11 - - [18/Jul/2019:15:42:53 +0000] "GET /wp-login.php HTTP/1.1" 499 0 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0"

132.148.130.138 - - [18/Jul/2019:15:42:54 +0000] "POST /wp-login.php HTTP/1.1" 499 0 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0"

Wir haben bereits einen Filter für genau diesen Fall:

[Definition]

failregex = ^<HOST> .* "GET /wp-login.php"

            ^<HOST> .* "POST /wp-login.php"

Ebenfalls ist unter /etc/fail2ban/jail.conf ein Eintrag dafür vorhanden:

[apache-wplogin]

enabled  = true

action   = iptables-multiport[name=apache-wplogin, port="80,443", protocol=tcp]

filter   = apache-wplogin

logpath  = /var/log/ispconfig/httpd/*/access.log

#          /var/log/ispconfig/httpd/*/access.log

maxretry = 5

findtime = 600

Trotzdem finden sich keine Einträge von IP-adressen in den iptables oder bei der Auflistung des fail2ban-jails:

iptables -L -n

Chain f2b-apache-wplogin (1 references)

target     prot opt source               destination

RETURN     all  --  0.0.0.0/0            0.0.0.0/0

 

Fehlersuche mit fail2ban

Die Ausgabe von “fail2ban-client status” bringt folgendes:

[root@server01 fail2ban]# fail2ban-client status

WARNING 'pidfile' not defined in 'Definition'. Using default one: '/var/run/fail2ban/fail2ban.pid'

Status

|- Number of jail:      10

`- Jail list:   apache-wplogin, apache-xmlrpc, dovecot, nginx-wplogin, postfix-sasl, pure-ftpd, recidive, ssh-blocklist, ssh-iptables, sshd

[root@server01 fail2ban]#

Sofern man sich dann ein Jail genauer anschaut:

[root@server01 fail2ban]# fail2ban-client status apache-wplogin

WARNING 'pidfile' not defined in 'Definition'. Using default one: '/var/run/fail2ban/fail2ban.pid'

Status for the jail: apache-wplogin

|- Filter

|  |- Currently failed: 0

|  |- Total failed:     0

|  `- Journal matches:

`- Actions

   |- Currently banned: 0

   |- Total banned:     0

   `- Banned IP list:

[root@server01 fail2ban]#

Bei genauerem Hinsehen fällt also auf, dass für das Jail „apache-wplogin” gar kein Logfile überwacht wird. Die Zeile „Journal matches” benennt jeweils für jedes Jail die überwachten Logfiles. Zum Vergleich schauen wir uns den ssh-jail an, der die erfolglosen Einbruchsversuche über ssh protololliert:

[root@server01 fail2ban]# fail2ban-client status ssh-iptables

WARNING 'pidfile' not defined in 'Definition'. Using default one: '/var/run/fail2ban/fail2ban.pid'

Status for the jail: ssh-iptables

|- Filter

|  |- Currently failed: 13

|  |- Total failed:     79

|  `- Journal matches:  _SYSTEMD_UNIT=sshd.service + _COMM=sshd

`- Actions

   |- Currently banned: 7

   |- Total banned:     7

   `- Banned IP list:   104.211.4.217 177.139.28.241 182.93.48.21 37.187.6.235 177.71.74.230 188.165.211.201 81.149.211.134

Wenn man tiefer bohrt und die Logfiles pro Jail von fail2ban explizit abfragt  mit “fail2ban-client get <jail> logpath”

[root@server01 fail2ban]# fail2ban-client get apache-wplogin logpath

WARNING 'pidfile' not defined in 'Definition'. Using default one: '/var/run/fail2ban/fail2ban.pid'

No file is currently monitored

[root@server01 fail2ban]#

Hinweis: Mit “fail2ban-client -d” bekommt man für fail2ban die gesamte effektive Konfiguration als Dump angezeigt. Ausschnitt:

['add', 'apache-wplogin', 'systemd']

['set', 'apache-wplogin', 'usedns', 'warn']

['set', 'apache-wplogin', 'maxretry', 5]

['set', 'apache-wplogin', 'addignoreip', '127.0.0.1/8']

Zum Vergleich: So sollte das eigentlich aussehen:

['add', 'apache-wplogin', 'auto']

['set', 'apache-wplogin', 'usedns', 'warn']

['set', 'apache-wplogin', 'addlogpath', '/var/www/domain.com/log/access.log', 'head']

...

['set', 'apache-wplogin', 'addlogpath', '/var/log/httpd/access_log', 'head']

['set', 'apache-wplogin', 'maxretry', 10]

['set', 'apache-wplogin', 'addignoreip', '127.0.0.1/8']

Die erste Zeile gibt einen Hinweis darauf, wo es klemmt: Die Standard-Vorgabe für fail2ban bei Centos 7 scheint “systemd” zu sein. Das passt für ssh-Einbruchsversuche oder andere Hacks die auf generische Dienste abzielen, deren System-Logfiles via systemd überwacht werden können. Im Fall unserer Websites müssen aber normale Logfile überwacht werden.

Auch lesenswert:
Nextcloud vs Seafile: Ein Persönlicher Vergleich

Während bei Centos 6 hier pro Jail automatisch die richtige Art der Überwachung von fail2ban gewählt wurde, muss man bei Centos 7 pro Jail zusätzlich das Backend des Logfiles angeben.

In unserem Fall war die richtige Einstellung

backend = pyinotify

Der gesamte Eintrag für ein Jail sieht dann so aus:

[apache-wplogin]

enabled  = true

action   = iptables-multiport[name=apache-wplogin, port="80,443", protocol=tcp]

filter   = apache-wplogin

logpath  = /var/log/ispconfig/httpd/*/access.log

maxretry = 5

findtime = 600

backend  = pyinotify

Sobald man die eine Zeile „backend = pyinotify“ einfügt, dann sieht die Abfrage „fail2ban-client get apache-wplogin logpath“ wie folgt aus:

 

[root@server01 ~]# fail2ban-client  status apache-wplogin

WARNING 'pidfile' not defined in 'Definition'. Using default one: '/var/run/fail2ban/fail2ban.pid'

Status for the jail: apache-wplogin

|- Filter

|  |- Currently failed: 0

|  |- Total failed:     1202

|  `- File list:        /var/www/domain01.net/log/access.log /var/www/domain02.com/log/access.log

`- Actions

   |- Currently banned: 1

   |- Total banned:     30

   `- Banned IP list:   122.134.143.253

Gut zu erkennen ist, daß nun zwei konkrete Log-Files in der „File List“ auftauchen.

Dazu passt dann auch die Ausgabe von „iptables –L –n“

Chain f2b-apache-wplogin (1 references)

target     prot opt source               destination

REJECT     all  --  122.134.143.253      0.0.0.0/0           reject-with icmp-port-unreachable

RETURN     all  --  0.0.0.0/0            0.0.0.0/0

 

Fazit zum fail2ban „Fehler“

Das Auffinden des Fehlers von fail2ban war hier tatsächlich kniffelig und zeitaufwändig. Den entscheidenden und anschließenden Hinweis gab übrigens eine japanische Website, auf der wir dann mit Google Translate den passenden Eintrag für „backend=“ gefunden haben. Vielen Dank dafür.