Fail2ban-Filter für den OpenVPN Access Server: real_ip und Jails

Der Access Server schreibt sein eigenes Logformat, gängige Filter treffen daher nichts. Am Feld real_ip ansetzen, Jails pro Oberfläche trennen und prüfen, dass die Adresse kein Proxy ist.

Sie haben eine OpenVPN Jail-Konfiguration aus einem Community-Beitrag kopiert, fail2ban neu gestartet, und trotzdem wird nie eine Adresse gesperrt. Der Grund ist fast immer das Logformat: Der Access Server schreibt die Authentifizierungsfehler nicht in der Form, die ein Standardfilter erwartet. Bevor Sie den Filter anfassen, prüfen Sie überhaupt, ob die Datensätze vorhanden sind, denn ein Muster kann nicht treffen, was der Dienst nie protokolliert hat.

Das ist das Runbook, das ich auf einem Access-Server-Host befolge: Form der Datensätze bestätigen, einen verankerten Ausdruck schreiben, ihn gegen das echte Log testen, dann die Jails nach der angegriffenen Oberfläche aufteilen und prüfen, dass die Sperre die Firewall erreicht.

Bestätigen, dass der Fehlerdatensatz existiert

Der Access Server schreibt seine eigenen strukturierten Zeilen nach /var/log/openvpnas.log, und die Client-Adresse steht in einem Feld real_ip in Anführungszeichen und nicht am Anfang einer Syslog-Zeile. Suchen Sie nach einem fehlgeschlagenen Login, von dem Sie wissen, dass er stattgefunden hat, bevor Sie ein Muster schreiben:

grep -i 'LOG ERR' /var/log/openvpnas.log | tail -20

Taucht nichts auf, ist die Logstufe der nächste Verdächtige. Der Access Server hat einen Debug-Schalter für die Log-Datenbank in /usr/local/openvpn_as/etc/as.conf (DEBUG_LOGDB=1), und der Dienst muss nach der Änderung neu gestartet werden. Behandeln Sie diesen Schalter als Diagnoseeinstellung, die wieder heruntergedreht wird, sobald Sie Ihr Muster haben, nicht als dauerhafte Konfiguration.

Merken Sie sich, während Sie in der Datei sind, welche Oberflächen hineinschreiben. Fehler im Client-Portal, in der Admin-Oberfläche und bei der Tunnel-Authentifizierung landen in derselben Datei, aber mit unterschiedlichen Markern, und dieses Detail entscheidet später über das Layout der Jails.

Einen Filter auf real_ip verankern

Halten Sie den Ausdruck eng. Ein Filter, der jede Zeile mit einer IP-Adresse beansprucht, sperrt Leute für gewöhnliche Verbindungsabbrüche, und auf einem ausgelasteten Server ist das einzige Symptom, dass Nutzer sich beschweren, sie seien ausgesperrt worden, weil sie ein Laptop zugeklappt haben. Beanspruchen Sie den Fehlerdatensatz und erfassen Sie die Adresse in Anführungszeichen:

# /etc/fail2ban/filter.d/openvpnaccess.local
[Definition]
failregex = ^ .*LOG ERR.*"real_ip": "<HOST>".*
ignoreregex =

Das führende Leerzeichen ist nicht kosmetisch. Der Access Server rückt seine Datensätze ein, und die Verankerung darauf verhindert, dass das Muster auch Zeilen beansprucht, die fremde Dienste in dieselbe Datei schreiben. Tragen Ihre Datensätze stattdessen einen führenden Zeitstempel, passen Sie auf dieses Präfix, aber verankern Sie auf etwas, das in jedem Datensatz, den Sie beanspruchen wollen, wirklich vorhanden ist.

Wenn Sie Genauigkeit pro Oberfläche brauchen, grenzen Sie weiter ein, indem Sie den Oberflächenmarker (WEB_CLIENT, WEB_ADMIN oder VPN) in derselben Zeile verlangen. Ein Filter mit drei Mustern ist leichter zu prüfen als drei Filter, die sich in einem Wort unterscheiden.

Den Ausdruck testen, bevor ein Jail aktiviert wird

Aktivieren Sie nie einen Filter, den Sie nicht gegen das Produktionslog laufen ließen. Der dokumentierte Test übergibt den Filter zweimal, einmal zum Laden und einmal zum Anwenden, und der Bericht über verpasste Zeilen ist der Teil, der sich zu lesen lohnt:

fail2ban-regex --print-all-missed /var/log/openvpnas.log \
  /etc/fail2ban/filter.d/openvpnaccess.local \
  /etc/fail2ban/filter.d/openvpnaccess.local > missed.txt

Vergleichen Sie die Trefferzahl mit den Fehlern, die Sie im ersten Schritt verifiziert haben. Null Treffer bedeuten, dass das Muster falsch ist; Treffer auf Zeilen, die keine Authentifizierungsfehler sind, bedeuten, dass es zu breit ist. Lesen Sie missed.txt, bis Sie jede Zeile erklären können, die Sie bewusst nicht beansprucht haben.

Machen Sie diesen Test an einer Kopie, wenn das Log groß ist, und wiederholen Sie ihn nach jedem Upgrade des Access Servers. Das Logformat ist die Schnittstelle, gegen die Sie matchen, und es ist keine stabile API.

Jails nach Oberfläche aufteilen, nicht nach Daemon

Ein Access Server bietet mehrere Authentifizierungsoberflächen: Client- und Admin-Weboberfläche auf 943/tcp und den Tunnel auf 1194/udp oder 443/tcp in den meisten Installationen. Ein einziges Jail für alle lässt Rateversuche am Tunnel eine Adresse sperren, die auch Ihr Admin-Pfad ist, und es verbirgt, welche Oberfläche tatsächlich angegriffen wird. Geben Sie jeder Oberfläche ein eigenes Jail mit eigenem Port und eigenen Schwellen:

# /etc/fail2ban/jail.d/openvpnaccess.local
[openvpnas-web-client]
enabled  = true
port     = 943
protocol = tcp
filter   = openvpnaccess
logpath  = /var/log/openvpnas.log
maxretry = 3
findtime = 10m
bantime  = 1h
[openvpnas-tunnel]
enabled  = true
port     = 443
protocol = udp
filter   = openvpnaccess
logpath  = /var/log/openvpnas.log
maxretry = 5
findtime = 10m
bantime  = 1h

Fangen Sie mit kleinen Zählern und einer kurzen Sperre an, und erhöhen Sie sie erst, wenn Sie eine Woche echten Verkehr beobachtet haben. Eine großzügige Schwelle auf einer gemeinsam genutzten Büroadresse bestraft jeden Nutzer hinter einem NAT, und eine aggressive Sperre auf der Tunneloberfläche trennt legitime Clients ab, deren gespeicherte Anmeldedaten über Nacht abgelaufen sind.

Sperre, Backend und Kollateralschäden überprüfen

Nach einem Neustart ist die Statusausgabe die schnellste Bestätigung, dass das Jail existiert und zählt:

fail2ban-client status
fail2ban-client status openvpnas-tunnel

Prüfen Sie dann, dass die Sperre die Firewall erreicht, die Sie tatsächlich betreiben, denn ein Jail, das für ein Backend konfiguriert ist, das niemand durchsetzt, schützt nichts. Bei der iptables-Action erscheinen die Adressen in einer nach dem Jail benannten Kette (f2b-openvpnas-tunnel); bei der nftables-Action landen sie in einem Set in der eigenen fail2ban-Tabelle. Prüfen Sie die Variante, die Ihr Host verwendet, statt sie anzunehmen.

Zwei Kollateralprüfungen sind wichtiger als die Sperre selbst. Erstens: Prüfen Sie, dass real_ip die Client-Adresse ist und kein Load Balancer oder Reverse Proxy; hinter einem Proxy landet jede Sperre auf dem Proxy und reißt den ganzen Dienst mit. Zweitens: Schreiben Sie das Verfahren zum Entsperren auf, denn die Adresse, die um 02:00 die Schwelle reißt, gehört meist dem Bereitschaftsingenieur: fail2ban-client set openvpnas-tunnel unbanip 203.0.113.24.

Behalten Sie die Grenze beim Tuning im Blick. Fail2ban ist ein Ratenbegrenzer auf einer Authentifizierungsoberfläche, keine Zugriffskontrollschicht. Es ersetzt weder MFA noch Kontoeinschränkungen noch das Fernhalten der Admin-Oberfläche vom öffentlichen Internet, und der Access Server hat eigene Autoban-Einstellungen, die es sich zu prüfen lohnt, bevor Sie zwei Ratenbegrenzer auf denselben Port stapeln.

Ähnliche Artikel