To innloggingskontroller er ikke to faktorer: VPN og RADIUS

Å legge til en ekstra autentiseringsbackend på en VPN-gateway føles som å legge til en ekstra faktor. Vanligvis legger det til en ekstra kontroll, som er et annet objekt med andre feilmoduser. Om begge må lykkes, hva hver av dem beviser, og hva som skjer når én ikke er tilgjengelig, er tre separate beslutninger. Tar du feil, ender gatewayen strengere i demonstrasjonen og svakere under et avbrudd.

Hva en ekstra backend faktisk beviser

Et lokalt kontoopslag beviser at et navn finnes i en database og at et passord passet til det. En RADIUS-utveksling beviser at en RADIUS-server returnerte Access-Accept for attributtene den mottok. Ingen av påstandene nevner en faktortype, fordi begge verifiserer kunnskap. Og NIST-veiledningen om digital identitet teller ulike faktortyper og deres autentisatorer, ikke servere eller oppfordringer.

Det finnes et legitimt design der begge systemene deltar. En sentral tjeneste kan autentisere personen mens gatewayen uavhengig kontrollerer om kontoen har rett til denne tunnelen. Det er autorisasjon ved siden av autentisering, og å kalle det tofaktor forveksler en policykontroll med bevis på besittelse.

RADIUS kan bære en ekte ekstra faktor når den står foran noe som verifiserer én, som en push-godkjenning eller et maskinvaretoken. Konvolutten forteller ikke hvilke autentisatorer brukeren viste, så les backendpolicyen i stedet for gatewayens etikett.

AND, OR og reserve er forskjellige produkter

Før du sammenligner implementasjoner, avgjør hva begge betyr i kravet ditt. En AND-policy krever at hver navngitte kontroll består, en OR-policy godtar den som lykkes, og en reserve prøver den andre bare under angitte feilforhold. Disse tre oppfører seg motsatt under et avbrudd, og vanligvis er bare én av dem det anmeldelsen mente.

Å legge to backend-oppføringer til en konfigurasjonsskjerm avslører ikke hvilken policy produktet implementerer. Noen gateways kjeder plugins i rekkefølge og stopper ved første avvisning, noe som bare er AND når hver plugin er påkrevd. Andre behandler en lokal konto som en overstyring, noe som gjør et sentralt avbrudd til en omgåelse. Det pålitelige svaret er en dokumentert negativ test for hver vei, kjørt mot bygget du ruller ut.

Reserve fortjener mest mistanke, fordi den finnes for å fortsette å virke når noe er ødelagt. En reserve som godtar et lokalt passord når RADIUS er utilgjengelig, har gjort en sentral policy om til en andre, svakere dør.

OpenVPNs doble kontroll er et konkret tilfelle

Fellesskaps-OpenVPN 2.6 krever både et klientsertifikat og det konfigurerte auth-user-pass-verify-skriptet når begge er aktivert. Det er en dokumentert AND mellom sertifikatverifisering og et legitimasjonsskript, og det er virkelig to kontroller. Det er fortsatt ikke automatisk to faktortyper, siden skriptet kanskje bare validerer et passord.

Kombinasjonen lar også assosiasjonsspørsmålet stå åpent. Et sertifikat identifiserer ofte en enhet mens legitimasjonen identifiserer en person, og ingenting i standardflyten krever at begge refererer til samme principal. Bestem hvilke par som er tillatt, og håndhev deretter det kartet i verifiseringsskriptet eller i et senere autorisasjonstrinn.

Modusen kun sertifikat er én kontroll, støttet av en nøkkel som kanskje eller kanskje ikke er beskyttet av en PIN. En PIN gjør samme legitimasjon til kunnskap pluss besittelse bare hvis nøkkelen ikke kan brukes uten den. Å la nøkkelen ligge ukryptert på disken reduserer den andre delen til en filrettighet.

Apparatleverandører bygger sitt eget rørleggerarbeid, ofte en PAM-modul eller en RADIUS-plugin bak en nettkonsoll. Fellesskapets oppførsel er en referanse for hvordan doble kontroller ser ut, ikke en beskrivelse av hvordan et apparat kombinerer dem.

Kontroller kombinasjonen på gatewayen din

Les konfigurasjonen før du stoler på konsollsammendraget. Linjene som bestemmer policyen, er sertifikatmodusen, legitimasjonsskriptet og plugin-rekkefølgen.

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 viser om et sertifikat er påkrevd og hvilket skript som kjører etter det, og rekkefølgen betyr mer enn navnene antyder. Sertifikatdumpen gir identiteten gatewayen vil se, inkludert CN og serienummeret du trenger for assosiasjonskartet. RADIUS-testen er det negative tilfellet: et feil passord må gi Access-Reject, og et riktig Access-Accept. Hvis en avvist legitimasjon likevel gir en sesjon, er skriptet ikke på autentiseringsveien i det hele tatt.

Kjør deretter avbruddstilfellet på en laboratorieinstans: stopp den påkrevde backenden og koble til med gyldig legitimasjon. Det forventede resultatet er en avvisning, og alt annet er reservepolicyen som ingen dokumenterte.

Skriv kravet som negative tilfeller

Et brukbart krav navngir bevisene, kontoene som har lov til å presentere dem, og resultatet når en verifiserer mangler. Det angir også den tillatte sammenkoblingen mellom enhetsidentitet og personidentitet. Det er mer presist enn produktnavnene på innkjøpsordren, og det kan testes.

Aksept bør omfatte fire avvisninger: en uegnet lokal konto, et manglende påkrevd bevis, en ugyldig andre faktor og en utilgjengelig påkrevd backend. Hver avvisning trenger en logglinje som skiller den fra de andre, ellers begynner neste hendelse med gjetting. Registrer hvilken komponent som tok hver beslutning, siden gatewayen, RADIUS-serveren og katalogen hver vil klandre de to andre.

Kjør de fire avvisningene på nytt etter enhver plugin- eller fastvareendring. De er billige, og policyen de beskytter, er den delen en angriper undersøker først.