Twee inlogcontroles zijn geen twee factoren: VPN en RADIUS

Een tweede authenticatiebackend aan een VPN-gateway toevoegen voelt als een tweede factor toevoegen. Meestal voegt het een tweede controle toe, een ander object met andere faalmodi. Of beide moeten slagen, wat elk bewijst en wat er gebeurt als één niet beschikbaar is, zijn drie afzonderlijke beslissingen. Doe je het verkeerd, dan is de gateway strenger in de demonstratie en zwakker tijdens een storing.

Wat een tweede backend werkelijk bewijst

Een lokale accountopzoeking bewijst dat een naam in een database bestaat en dat een wachtwoord erbij paste. Een RADIUS-uitwisseling bewijst dat een RADIUS-server Access-Accept teruggaf voor de ontvangen attributen. Geen van beide uitspraken noemt een factortype, omdat beide kennis verifiëren. En de NIST-richtlijn voor digitale identiteit telt verschillende factortypen en hun authenticatoren, niet servers of prompts.

Er bestaat een legitiem ontwerp waarin beide systemen deelnemen. Een centrale dienst kan de persoon authenticeren terwijl de gateway onafhankelijk controleert of dat account recht heeft op deze tunnel. Dat is autorisatie naast authenticatie, en het tweefactor noemen verwart een beleidscontrole met een bewijs van bezit.

RADIUS kan een echte tweede factor dragen wanneer het voor iets staat dat er één verifieert, zoals een push-goedkeuring of een hardwaretoken. De envelop vertelt niet welke authenticatoren de gebruiker heeft getoond, dus lees het backendbeleid in plaats van het label van de gateway.

AND, OR en fallback zijn verschillende producten

Bepaal voordat u implementaties vergelijkt wat beide in uw eis betekent. Een AND-beleid vereist dat elke genoemde controle slaagt, een OR-beleid accepteert degene die slaagt, en een fallback probeert de tweede alleen onder vermelde faalcondities. Die drie gedragen zich tegengesteld tijdens een storing, en meestal is slechts één ervan wat de review bedoelde.

Twee backend-vermeldingen op een configuratiescherm onthullen niet welk beleid het product implementeert. Sommige gateways koppelen plugins in volgorde en stoppen bij de eerste weigering, wat alleen AND is als elke plugin verplicht is. Andere behandelen een lokaal account als een override, wat een centrale storing in een omzeiling verandert. Het betrouwbare antwoord is een gedocumenteerde negatieve test voor elk pad, uitgevoerd tegen de build die u uitrolt.

Fallback verdient het meeste wantrouwen, omdat het bestaat om te blijven werken als er iets kapot is. Een fallback die een lokaal wachtwoord accepteert zodra RADIUS onbereikbaar is, heeft een centraal beleid in een tweede, zwakkere deur veranderd.

De dubbele controle van OpenVPN is een concreet geval

Community-OpenVPN 2.6 vereist zowel een clientcertificaat als het geconfigureerde auth-user-pass-verify-script wanneer beide zijn ingeschakeld. Dat is een gedocumenteerde AND tussen certificaatverificatie en een inloggegevensscript, en het zijn echt twee controles. Het zijn nog steeds niet automatisch twee factortypen, omdat het script misschien alleen een wachtwoord valideert.

De combinatie laat ook de associatievraag open. Een certificaat identificeert vaak een apparaat terwijl de inloggegevens een persoon identificeren, en niets in de standaardstroom vereist dat beide naar dezelfde principal verwijzen. Bepaal welke paren zijn toegestaan en dwing die mapping vervolgens af in het verificatiescript of in een latere autorisatiestap.

De modus alleen certificaat is één controle, ondersteund door een sleutel die al dan niet door een PIN wordt beschermd. Een PIN maakt dezelfde inloggegevens tot kennis plus bezit, alleen als de sleutel er niet zonder kan worden gebruikt. De sleutel onversleuteld op schijf laten staan, reduceert het tweede deel tot een bestandsrechten.

Apparaatleveranciers bouwen hun eigen loodgieterswerk, vaak een PAM-module of een RADIUS-plugin achter een webconsole. Het gedrag van de community is een referentie voor hoe dubbele controles eruitzien, geen beschrijving van hoe een apparaat ze combineert.

Controleer de combinatie op uw gateway

Lees de configuratie voordat u het consolesamenvatting vertrouwt. De regels die het beleid bepalen, zijn de certificaatmodus, het inloggegevensscript en de pluginvolgorde.

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 toont of een certificaat vereist is en welk script daarna draait, en de volgorde is belangrijker dan de namen suggereren. De certificaatdump geeft de identiteit die de gateway ziet, inclusief de CN en het serienummer dat u voor de associatiemap nodig hebt. De RADIUS-test is het negatieve geval: een verkeerd wachtwoord moet Access-Reject opleveren, en een juist Access-Accept. Als geweigerde inloggegevens toch een sessie opleveren, staat het script helemaal niet op het authenticatiepad.

Voer daarna het storingsgeval uit op een labinstantie: stop de vereiste backend en verbind met geldige inloggegevens. Het verwachte resultaat is een weigering, en al het andere is het fallbackbeleid dat niemand documenteerde.

Schrijf de eis als negatieve gevallen

Een bruikbare eis noemt de bewijzen, de accounts die ze mogen presenteren en het resultaat wanneer een verifieerder ontbreekt. Ze vermeldt ook de toegestane koppeling tussen apparaatidentiteit en persoonsidentiteit. Dat is preciezer dan de productnamen op de inkooporder, en het is testbaar.

De acceptatie moet vier weigeringen bevatten: een ongeschikt lokaal account, een ontbrekend vereist bewijs, een ongeldige tweede factor en een onbereikbare vereiste backend. Elke weigering heeft een logregel nodig die haar van de andere onderscheidt, anders begint het volgende incident met giswerk. Noteer welke component elke beslissing nam, want de gateway, de RADIUS-server en de directory zullen elkaar de schuld geven.

Voer de vier weigeringen opnieuw uit na elke plugin- of firmwarewijziging. Ze zijn goedkoop, en het beleid dat ze beschermen is het deel dat een aanvaller als eerste onderzoekt.