Zwei Anmeldeprüfungen sind keine zwei Faktoren: VPN und RADIUS

Ein zweites Authentifizierungs-Backend an einem VPN-Gateway hinzuzufügen fühlt sich an wie ein zweiter Faktor. Meist kommt jedoch eine zweite Prüfung hinzu, ein anderes Objekt mit anderen Fehlerarten. Ob beide erfolgreich sein müssen, was jede beweist und was passiert, wenn eine nicht erreichbar ist, sind drei getrennte Entscheidungen. Macht man sie falsch, ist das Gateway in der Vorführung strenger und im Störfall schwächer.

Was ein zweites Backend tatsächlich beweist

Eine lokale Kontosuche beweist, dass ein Name in einer Datenbank existiert und dass ein Passwort dazu passte. Ein RADIUS-Austausch beweist, dass ein RADIUS-Server Access-Accept für die empfangenen Attribute zurückgegeben hat. Keine der Aussagen nennt einen Faktortyp, denn beide prüfen Wissen. Und die NIST-Leitlinie zur digitalen Identität zählt unterschiedliche Faktortypen und ihre Authentifikatoren, nicht Server oder Aufforderungen.

Es gibt ein legitimes Design, an dem beide Systeme beteiligt sind. Ein zentraler Dienst kann die Person authentifizieren, während das Gateway unabhängig prüft, ob dieses Konto für diesen Tunnel berechtigt ist. Das ist Autorisierung neben der Authentifizierung, und es Zweifaktor zu nennen verwechselt eine Richtlinienprüfung mit einem Besitznachweis.

RADIUS kann einen echten zweiten Faktor tragen, wenn es etwas vorschaltet, das einen prüft, etwa eine Push-Genehmigung oder einen Hardware-Token. Der Umschlag sagt nicht, welche Authentifikatoren der Nutzer vorgelegt hat; lesen Sie daher die Backend-Richtlinie statt das Etikett des Gateways.

AND, OR und Fallback sind verschiedene Produkte

Bevor Sie Implementierungen vergleichen, entscheiden Sie, was beides in Ihrer Anforderung bedeutet. Eine AND-Richtlinie verlangt, dass jede genannte Prüfung besteht, eine OR-Richtlinie akzeptiert die, die gelingt, und ein Fallback versucht die zweite nur unter genannten Fehlerbedingungen. Diese drei verhalten sich im Störfall gegensätzlich, und meist ist nur eine davon gemeint.

Zwei Backend-Einträge auf einem Konfigurationsbildschirm verraten nicht, welche Richtlinie das Produkt umsetzt. Manche Gateways verketten Plugins der Reihe nach und stoppen beim ersten Ablehnen, was nur dann AND ist, wenn jedes Plugin erforderlich ist. Andere behandeln ein lokales Konto als Übersteuerung, was einen zentralen Ausfall zu einer Umgehung macht. Die verlässliche Antwort ist ein dokumentierter Negativtest für jeden Pfad, ausgeführt gegen den Build, den Sie ausrollen.

Fallback verdient das meiste Misstrauen, denn es existiert, um weiterzuarbeiten, wenn etwas kaputt ist. Ein Fallback, das ein lokales Passwort akzeptiert, sobald RADIUS nicht erreichbar ist, hat eine zentrale Richtlinie in eine zweite, schwächere Tür verwandelt.

OpenVPNs doppelte Prüfung ist ein konkreter Fall

Community-OpenVPN 2.6 verlangt sowohl ein Client-Zertifikat als auch das konfigurierte Skript auth-user-pass-verify, wenn beides aktiviert ist. Das ist ein dokumentiertes AND zwischen Zertifikatsprüfung und einem Anmeldedaten-Skript, und es sind wirklich zwei Prüfungen. Es sind trotzdem nicht automatisch zwei Faktortypen, da das Skript womöglich nur ein Passwort validiert.

Die Kombination lässt auch die Zuordnungsfrage offen. Ein Zertifikat identifiziert häufig ein Gerät, während die Anmeldedaten eine Person identifizieren, und nichts im Standardablauf verlangt, dass sich beides auf dasselbe Subjekt bezieht. Entscheiden Sie, welche Paare erlaubt sind, und erzwingen Sie diese Zuordnung im Prüfskript oder in einem späteren Autorisierungsschritt.

Der Nur-Zertifikat-Modus ist eine einzige Prüfung, gestützt auf einen Schlüssel, der durch eine PIN geschützt sein kann oder nicht. Eine PIN macht dieselbe Anmeldedaten zu Wissen plus Besitz nur dann, wenn der Schlüssel ohne sie nicht nutzbar ist. Bleibt der Schlüssel unverschlüsselt auf der Platte, schrumpft der zweite Teil auf eine Dateiberechtigung.

Gerätehersteller bauen ihre eigene Verrohrung, oft ein PAM-Modul oder ein RADIUS-Plugin hinter einer Weboberfläche. Das Verhalten der Community ist eine Referenz dafür, wie doppelte Prüfungen aussehen, keine Beschreibung, wie ein Gerät sie kombiniert.

Prüfen Sie die Kombination auf Ihrem Gateway

Lesen Sie die Konfiguration, bevor Sie der Konsolenzusammenfassung trauen. Die Zeilen, die die Richtlinie bestimmen, sind der Zertifikatsmodus, das Anmeldedaten-Skript und die Plugin-Reihenfolge.

grep -E 'verify-client-cert|auth-user-pass-verify|plugin' /etc/openvpn/server.conf
openssl x509 -in /etc/openvpn/pki/issued/client01.crt -noout -subject -serial
radtest alice 'wrong-password' 127.0.0.1 0 testing123

grep zeigt, ob ein Zertifikat erforderlich ist und welches Skript danach läuft, und die Reihenfolge ist wichtiger, als die Namen vermuten lassen. Der Zertifikatsdump liefert die Identität, die das Gateway sieht, einschließlich der CN und der Seriennummer, die Sie für die Zuordnung brauchen. Der RADIUS-Test ist der Negativfall: ein falsches Passwort muss Access-Reject ergeben, ein richtiges Access-Accept. Ergibt eine abgelehnte Anmeldedaten trotzdem eine Sitzung, ist das Skript gar nicht auf dem Authentifizierungspfad.

Führen Sie dann den Ausfallfall auf einer Labinstanz aus: Stoppen Sie das erforderliche Backend und verbinden Sie sich mit gültigen Anmeldedaten. Das erwartete Ergebnis ist eine Ablehnung, und alles andere ist die Fallback-Richtlinie, die niemand dokumentiert hat.

Schreiben Sie die Anforderung als Negativfälle

Eine brauchbare Anforderung benennt die Nachweise, die Konten, die sie vorlegen dürfen, und das Ergebnis, wenn ein Prüfer fehlt. Sie nennt auch die erlaubte Paarung zwischen Geräteidentität und Personenidentität. Das ist präziser als die Produktnamen auf der Bestellung und lässt sich testen.

Die Abnahme sollte vier Ablehnungen umfassen: ein ungeeignetes lokales Konto, einen fehlenden erforderlichen Nachweis, einen ungültigen zweiten Faktor und ein nicht erreichbares erforderliches Backend. Jede Ablehnung braucht eine Logzeile, die sie von den anderen unterscheidet, sonst beginnt der nächste Vorfall mit Raten. Halten Sie fest, welche Komponente welche Entscheidung getroffen hat, denn Gateway, RADIUS-Server und Verzeichnis werden jeweils die anderen beiden beschuldigen.

Wiederholen Sie die vier Ablehnungen nach jeder Plugin- oder Firmware-Änderung. Sie sind billig, und die Richtlinie, die sie schützen, ist der Teil, den ein Angreifer zuerst prüft.