Kontosperre gegen Adresssperre: wo OpenVPN tatsächlich zählt

Eine Adresse zu blockieren und ein Konto zu sperren sind zwei verschiedene Mechanismen, und sie scheitern in entgegengesetzte Richtungen. Eine Adresssperre stoppt eine Quelle und lässt das Zielkonto von anderswo erreichbar; eine Kontosperre stoppt diese Identität überall, auch auf dem eigenen Laptop des Nutzers.

Bei einem VPN, das die Authentifizierung an PAM delegiert, ist der Zähler das, was der PAM-Stack erreicht, nicht das, was der Listener protokolliert hat.

Zwei Zähler, zwei verschiedene Opfer

Ein Ratenbegrenzer betrachtet eine Quelle und fragt, wie viele Versuche kürzlich von ihr kamen. Eine Sperre betrachtet eine Identität und fragt, wie viele Fehlschläge das Konto angesammelt hat. Das erste schützt die Verfügbarkeit, das zweite die Anmeldedaten; keines ersetzt das andere.

Deshalb ist der Satz wir blockieren die IP nach fünf Fehlschlägen keine Antwort auf einen Bericht über Credential Stuffing. Der Angreifer wechselt Quellen, jede bekommt wenige Versuche, und das Konto wird nie gezählt. Umgekehrt erlaubt eine Sperre ohne Quellenkontrolle dem Angreifer, das Konto durch absichtliches Scheitern unbegrenzt gesperrt zu halten.

Die beiden Kontrollen haben auch unterschiedliche Erholungsgeschichten. Eine Adresssperre läuft über einen Timer ab, über den niemand nachdenken muss; eine Kontosperre kann einen Administrator, eine dokumentierte Wartezeit oder ein Self-Service-Reset erfordern.

Finden Sie den Speicher, der die Zählung bereits besitzt

Bevor Sie etwas hinzufügen, stellen Sie fest, ob bereits ein Fehlerspeicher existiert. Ein lokales Linux-Konto, ein Verzeichnisdienst und ein externer Identitätsanbieter führen jeweils ihre eigene Zählung, und ein davor gesetztes PAM-Modul schafft eine zweite, statt die erste zu erweitern.

grep -rnE 'faillock|pam_tally|pam_unix' /etc/pam.d/
ls -l /etc/pam.d/ | head -20

Lesen Sie die Dienstdatei, die das VPN tatsächlich nennt, und folgen Sie ihren Include-Zeilen. Bei vielen Distributionen bindet der VPN-Dienst eine gemeinsame Datei ein, was bedeutet, dass die Zählung, die Sie anpassen, auch für SSH und lokale Anmeldungen gilt.

Wenn das Verzeichnis bereits eine Sperre erzwingt, lautet die nützliche Frage, wie die PAM-Konversation zu dieser Entscheidung kommt und wie das VPN sie meldet. Eine lokale Zählung obendrauf wird nicht der Zähler des Verzeichnisses, und die beiden Richtlinien können uneinig sein, wann das Konto entsperrt wird.

pam_faillock hat drei Aufrufpositionen, nicht eine

Das Modul trennt drei Vorgänge, die eine kopierte Zeile meist verwischt: prüfen, ob das Konto bereits gesperrt ist, einen Fehlschlag erfassen und den Verlauf nach einem Erfolg löschen.

Hier geht eine Migration von einem älteren Zählmodul meist schief. Eine Zeile aus einem funktionierenden pam_tally2-Beispiel in einen pam_faillock-Stack zu kopieren ist keine Umbenennung; die dokumentierte Einrichtung ist anders, und ein falsch platzierter Aufruf kann Fehlschläge erfassen, ohne sie je zu prüfen.

faillock --user alice
faillock --user alice --reset

Das Prüfwerkzeug ist der schnellste Weg zu sehen, ob der Zähler echt ist: es zeigt die erfassten Fehlschläge eines Kontos und kann sie löschen. Ändert ein kontrollierter Fehlschlag diese Ausgabe nicht, ist die Aufrufposition falsch.

Ein eigener Dienstname ist keine Isolation

Dem VPN eine eigene PAM-Dienstdatei zu geben macht die beabsichtigte Richtlinie sichtbar, begrenzt aber nicht die Wirkung. Jedes Einbinden einer gemeinsamen Datei zieht mit, was diese Datei tut, einschließlich systemweiter Zählungen.

Entscheiden Sie ausdrücklich, ob die Sperre nur den VPN-Zugang oder jeden Dienst abdeckt, der dasselbe Konto authentifiziert. Beide Antworten sind vertretbar; der Fehler ist zu glauben, man habe eine gewählt, während der Stack die andere umsetzt.

Rechnen Sie dann die Kosten ein. Eine Sperre kann ein Angreifer auslösen, und der leidende Nutzer ist der Kontoinhaber. Schwelle, Wartezeit und der administrative Wiederherstellungsweg sind Teil der Richtlinie, und die Wiederherstellung darf nicht davon abhängen, das VPN während eines Vorfalls umzukonfigurieren.

Akzeptieren Sie die Abfolge, nicht eine einzelne Ablehnung

Testen Sie mit festgelegten Identitäten nach einem genehmigten Plan, und testen Sie eine Kette statt eines einzelnen Ereignisses: ein gültiges Konto authentifiziert sich, ein absichtlich falsches Passwort bewegt den Zähler, die konfigurierte Sperre greift, und die dokumentierte Wiederherstellung gibt den Zugang zurück.

faillock --user test-vpn-01
journalctl -u openvpn-server@lab -n 30 --no-pager | grep -i 'auth\|pam'

Prüfen Sie das Erfolgsverhalten ebenso sorgfältig wie das Fehlerverhalten. Löscht eine erfolgreiche Anmeldung den Verlauf nicht, sperrt sich ein Konto nach langsamer Anhäufung gewöhnlicher Fehler. Löscht sie alles aus jedem Dienst, ist der Zähler schwächer, als die Richtlinie behauptet.

Stoppen Sie schließlich unbeaufsichtigte Clients, bevor Sie den Sieg erklären. Gespeicherte Anmeldedaten, die im Hintergrund erneut versuchen, erzeugen Minuten nach einer Wiederherstellung erneut Fehlschläge und sperren das Konto wieder. Quellenbasierte Ratenbegrenzung kann als zusätzliche Kontrolle bleiben, ist aber keine Kontorichtlinie.