Fail2ban auf einem VPN-Gateway: Was es behebt und was nicht

Jeder exponierte Dienst bekommt denselben Rat: fail2ban daraufsetzen. Für ein VPN-Gateway ist dieser Rat weder falsch noch ausreichend, und ihn als Häkchen bei der Härtung zu behandeln, führt genau dazu, dass man mit einer Jail endet, die nichts Nützliches blockiert. Fail2ban liest die Fehlerdatensätze, auf die man es zeigt, und bittet ein Durchsetzungs-Backend, passende Quellen zu sperren. Sein gesamter Wert hängt davon ab, welche Authentifizierungsoberfläche den Datensatz erzeugt hat, ob die darin enthaltene Adresse der echte Client ist und was mit allen anderen hinter dieser Adresse geschieht.

Was fail2ban mechanisch ist

Ein Filter gleicht Zeilen in einem Log ab, eine Jail zählt Treffer pro Quelle, und eine Action setzt eine Sperre über ein Firewall-Backend durch. Drei bewegliche Teile, und jedes kann unabhängig falsch sein.

Keines der drei berührt den Authentifizierungspfad: fail2ban reagiert im Nachhinein auf Beweise und validiert nie selbst ein Credential. Eine Jail kann also sauber laufen, während die Oberfläche, die sie benennt, genau so exponiert bleibt wie zuvor.

Der Tunnel-Listener ist kein Login-Formular

Ein OpenVPN-Listener, der mit tls-auth oder tls-crypt geschützt ist, verwirft Pakete ohne Kontrollkanal-Schutz, bevor die normale TLS-Verarbeitung beginnt. Ein Scanner, der den Schlüssel nie hat, erzeugt nichts, was Ihr Filter zählen könnte. Zertifikatsauthentifizierung fügt ein weiteres Tor hinzu, denn es gibt kein Passwort zu raten. Das Fail2ban-Projekt dokumentiert ein allgemeines loggetriebenes Modell, und ein generischer VPN-Filter macht aus einem nicht authentifizierten Paket kein aussagekräftiges Fehlerereignis.

Akzeptiert das Gateway nur Zertifikate, existiert die Brute-Force-Geschichte, gegen die Sie sich verteidigen, auf diesem Port womöglich gar nicht.

Welche Oberfläche schützen Sie also?

Derselbe Host exponiert oft drei verschiedene Dinge: den Tunnel-Listener, ein Client-Profil- oder Self-Service-Portal und eine Administrationsseite. Portal und Admin-Seite haben Passwortformulare und erzeugen Logzeilen, die ein Filter zählen kann. Der Tunnel erzeugt womöglich nur Handshake-Fehler, die etwas völlig anderes bedeuten. Ordnen Sie die Jail der Oberfläche zu, nicht dem Produktnamen.

Eine Jail, die das falsche Log beobachtet, ist schlimmer als keine, denn sie schafft Vertrauen ohne Abdeckung. Richten Sie einen Login-Filter auf Tunnel-Handshake-Fehler, feuert der Zähler bei Scannern, die nie einen Schlüssel hatten, während ein Passwortangriff auf das Portal ungezählt bleibt. Lesen Sie die Logzeile, die der Filter abgleicht, bevor Sie der Zahl der Jail trauen.

Die Quellzuordnung ist das schwache Glied

Eine Sperre ist nur so gut wie die Adresse, auf die sie zielt. Steht der Dienst hinter einem lokalen Reverse-Proxy, kann die Clientadresse im Log der Proxy sein, und ihn zu sperren entfernt alle. Einem weitergeleiteten Header aus einer nicht vertrauenswürdigen Quelle zu vertrauen, gibt einem Angreifer die Möglichkeit, beliebige Adressen zu sperren. Bei UDP lassen sich Quelladressen fälschen, daher verdient ihr Zählen mehr Sorgfalt als das Zählen eines abgeschlossenen TCP-Logins.

Halten Sie die Methode der Quellzuordnung im README der Jail fest, denn ein weitergeleiteter Header von einem nicht vertrauenswürdigen Hop macht aus einer Sperre eine Waffe.

Der Kollateralschaden sind andere Menschen

Mehrere Mitarbeiter hinter einem Büro-NAT teilen sich eine Adresse, sodass ein einziges veraltetes gespeichertes Passwort den ganzen Standort aussperren kann, sobald die Schwelle überschritten wird. Das Log zeigt eine Quelle und ein Konto, die gescheitert sind, keinen standortweiten Ausfall.

Kurze Sperren und maßvolle Schwellen reduzieren das, und ein dokumentierter Weg zum Entsperren senkt die Supportlast, wenn es trotzdem passiert. Die Adresse ist ein grobes Signal und keine Identität, und wer das Ticket eröffnet, wird den Ausfall beschreiben, nicht die Schwelle.

Wann man es einführt und wann man etwas anderes repariert

Führen Sie es ein, wenn es auf einer Oberfläche, die Sie kontrollieren, ein echtes, zuordenbares, wiederholtes Online-Login-Scheitern gibt und wenn das Durchsetzungs-Backend diese Oberfläche tatsächlich abdeckt. Reparieren Sie etwas anderes, wenn das Problem eine schwache Credential-Politik ist, eine ins Internet exponierte Verwaltungsseite oder ein Konto, das sich erfolgreich anmeldet, weil es kompromittiert wurde. Eine Sperre kann nichts davon reparieren, und sie kann keinen Verkehr aufnehmen, der Ihren Uplink bereits gesättigt hat. Das letzte Problem gehört stromaufwärts, zu jemandem, der filtern kann, bevor die Pakete Sie erreichen.

Halten Sie jede Jail an eine Oberfläche gebunden, prüfen Sie Fehlalarme und messen Sie die vermiedene Authentifizierungsarbeit statt der Zahl gesperrter Adressen.