To login-tjek er ikke to faktorer: VPN og RADIUS

At tilføje en anden godkendelsesbackend til en VPN-gateway føles som at tilføje en anden faktor. Det tilføjer normalt et andet tjek, som er et andet objekt med andre fejltilstande. Om begge skal lykkes, hvad hver især beviser, og hvad der sker, når den ene er utilgængelig, er tre separate beslutninger. Tager du fejl, ender gatewayen strammere i demonstrationen og svagere under et udfald.

Hvad en anden backend faktisk beviser

Et lokalt kontoopslag beviser, at et navn findes i en database, og at en adgangskode passede til det. En RADIUS-udveksling beviser, at en RADIUS-server returnerede Access-Accept for de attributter, den modtog. Ingen af udsagnene nævner en faktortype, fordi begge verificerer viden. Og NIST-vejledningen om digital identitet tæller forskellige faktortyper og deres autentifikatorer, ikke servere eller prompter.

Der findes et legitimt design, hvor begge systemer deltager. En central tjeneste kan godkende personen, mens gatewayen uafhængigt kontrollerer, om den konto har ret til denne tunnel. Det er autorisation ved siden af godkendelse, og at kalde det tofaktor forveksler et politiktjek med bevis for besiddelse.

RADIUS kan bære en ægte anden faktor, når det står foran noget, der verificerer en, såsom en push-godkendelse eller et hardwaretoken. Konvolutten fortæller ikke, hvilke autentifikatorer brugeren har fremvist, så læs backendpolitikken i stedet for gatewayens etiket.

AND, OR og fallback er forskellige produkter

Før du sammenligner implementeringer, skal du beslutte, hvad begge betyder i dit krav. En AND-politik kræver, at hvert navngivet tjek består, en OR-politik accepterer det, der lykkes, og en fallback prøver kun det andet under angivne fejlforhold. De tre opfører sig modsat under et udfald, og normalt er kun én af dem det, anmeldelsen havde tænkt på.

At tilføje to backend-poster til en konfigurationsskærm afslører ikke, hvilken politik produktet implementerer. Nogle gateways kæder plugins i rækkefølge og stopper ved den første afvisning, hvilket kun er AND, når hvert plugin er påkrævet. Andre behandler en lokal konto som en tilsidesættelse, hvilket gør et centralt udfald til en omgåelse. Det pålidelige svar er en dokumenteret negativ test for hver vej, kørt mod det build, du udruller.

Fallback fortjener mest mistanke, fordi den findes for at fortsætte med at virke, når noget er i stykker. En fallback, der accepterer en lokal adgangskode, når RADIUS er utilgængelig, har gjort en central politik til en anden, svagere dør.

OpenVPNs dobbelte tjek er et konkret tilfælde

Fællesskabs-OpenVPN 2.6 kræver både et klientcertifikat og det konfigurerede auth-user-pass-verify-script, når begge er aktiveret. Det er en dokumenteret AND mellem certifikatverifikation og et legitimationsscript, og det er virkelig to tjek. Det er stadig ikke automatisk to faktortyper, da scriptet måske kun validerer en adgangskode.

Kombinationen efterlader også associationsspørgsmålet åbent. Et certifikat identificerer ofte en enhed, mens legitimationsoplysningerne identificerer en person, og intet i standardflowet kræver, at begge henviser til samme principal. Beslut, hvilke par der er tilladte, og gennemtving derefter det kort i verifikationsscriptet eller i et senere autorisationstrin.

Tilstanden kun-certifikat er et enkelt tjek, understøttet af en nøgle, der måske eller måske ikke er beskyttet af en PIN-kode. En PIN-kode gør den samme legitimationsoplysning til viden plus besiddelse kun, hvis nøglen ikke kan bruges uden den. At lade nøglen være ukrypteret på disken reducerer den anden del til en filrettighed.

Apparatleverandører bygger deres eget VVS, ofte et PAM-modul eller et RADIUS-plugin bag en webkonsol. Fællesskabsadfærd er en reference for, hvordan dobbelte tjek ser ud, ikke en beskrivelse af, hvordan et apparat kombinerer dem.

Kontroller kombinationen på din gateway

Læs konfigurationen, før du stoler på konsoloversigten. De linjer, der bestemmer politikken, er certifikattilstanden, legitimationsscriptet og plugin-rækkefø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 certifikat er påkrævet, og hvilket script der kører efter det, og rækkefølgen betyder mere, end navnene antyder. Certifikatdumpet giver den identitet, gatewayen vil se, inklusive det CN og serienummer, du har brug for til associationskortet. RADIUS-testen er det negative tilfælde: en forkert adgangskode skal give Access-Reject, og en korrekt Access-Accept. Hvis en afvist legitimationsoplysning stadig giver en session, er scriptet slet ikke på godkendelsesvejen.

Kør derefter udfaldstilfældet på en laboratorieinstans: stop den påkrævede backend, og opret forbindelse med gyldige legitimationsoplysninger. Det forventede resultat er en afvisning, og alt andet er den fallback-politik, som ingen dokumenterede.

Skriv kravet som negative tilfælde

Et brugbart krav navngiver beviserne, de konti, der må fremvise dem, og resultatet, når en verifikator mangler. Det angiver også den tilladte parring mellem enhedsidentitet og personidentitet. Det er mere præcist end produktnavnene på indkøbsordren, og det kan testes.

Accept bør omfatte fire afvisninger: en uegnet lokal konto, et manglende påkrævet bevis, en ugyldig anden faktor og en utilgængelig påkrævet backend. Hver afvisning kræver en loglinje, der adskiller den fra de andre, ellers begynder den næste hændelse med gætværk. Registrer, hvilken komponent der traf hver beslutning, da gatewayen, RADIUS-serveren og biblioteket hver vil bebrejde de to andre.

Kør de fire afvisninger igen efter enhver plugin- eller firmwareændring. De er billige, og den politik, de beskytter, er den del, en angriber først undersøger.