Två inloggningskontroller är inte två faktorer: VPN och RADIUS

Att lägga till en andra autentiseringsbackend på en VPN-gateway känns som att lägga till en andra faktor. Oftast lägger det till en andra kontroll, ett annat objekt med andra felmoder. Om båda måste lyckas, vad var och en bevisar och vad som händer när en inte är tillgänglig är tre separata beslut. Gör fel och gatewayen blir strängare i demonstrationen och svagare vid ett avbrott.

Vad en andra backend verkligen bevisar

En lokal konto uppslagning bevisar att ett namn finns i en databas och att ett lösenord passade till det. Ett RADIUS-utbyte bevisar att en RADIUS-server returnerade Access-Accept för de attribut den tog emot. Inget av påståendena nämner en faktortyp, eftersom båda verifierar kunskap. Och NIST:s vägledning om digital identitet räknar olika faktortyper och deras autentiserare, inte servrar eller uppmaningar.

Det finns en legitim design där båda systemen deltar. En central tjänst kan autentisera personen medan gatewayen oberoende kontrollerar om kontot har rätt till denna tunnel. Det är auktorisering vid sidan av autentisering, och att kalla det tvåfaktor blandar ihop en policykontroll med ett bevis på innehav.

RADIUS kan bära en riktig andra faktor när det står framför något som verifierar en, till exempel ett pushgodkännande eller en hårdvarutoken. Kuvertet säger inte vilka autentiserare användaren visade, så läs backendpolicyn i stället för gatewayens etikett.

AND, OR och reserv är olika produkter

Innan du jämför implementationer, bestäm vad båda betyder i ditt krav. En AND-policy kräver att varje namngiven kontroll går igenom, en OR-policy accepterar den som lyckas, och en reserv provar den andra endast under angivna felvillkor. Dessa tre beter sig motsatt vid ett avbrott, och vanligtvis är bara en av dem vad granskningen avsåg.

Att lägga till två backend-poster på en konfigurationsskärm avslöjar inte vilken policy produkten implementerar. Vissa gateways kedjar plugins i ordning och stoppar vid första avvisning, vilket bara är AND när varje plugin krävs. Andra behandlar ett lokalt konto som en åsidosättning, vilket gör ett centralt avbrott till en kringgående. Det tillförlitliga svaret är ett dokumenterat negativt test för varje väg, kört mot den build du rullar ut.

Reserv förtjänar mest misstanke, eftersom den finns för att fortsätta fungera när något är trasigt. En reserv som accepterar ett lokalt lösenord närhelst RADIUS inte nås har gjort en central policy till en andra, svagare dörr.

OpenVPN:s dubbla kontroll är ett konkret fall

Community-OpenVPN 2.6 kräver både ett klientcertifikat och det konfigurerade auth-user-pass-verify-skriptet när båda är aktiverade. Det är en dokumenterad AND mellan certifikatverifiering och ett inloggningsuppgiftsskript, och det är verkligen två kontroller. Det är fortfarande inte automatiskt två faktortyper, eftersom skriptet kanske bara validerar ett lösenord.

Kombinationen lämnar också associationsfrågan öppen. Ett certifikat identifierar ofta en enhet medan uppgifterna identifierar en person, och inget i standardflödet kräver att båda avser samma principal. Bestäm vilka par som är tillåtna och genomdriv sedan den kartan i verifieringsskriptet eller i ett senare auktoriseringssteg.

Läget endast certifikat är en enda kontroll, stödd av en nyckel som kanske eller kanske inte skyddas av en PIN. En PIN gör samma uppgift till kunskap plus innehav endast om nyckeln inte kan användas utan den. Att lämna nyckeln okrypterad på disken minskar den andra delen till en filbehörighet.

Apparattillverkare bygger sitt eget rörarbete, ofta en PAM-modul eller en RADIUS-plugin bakom en webbkonsol. Communitybeteendet är en referens för hur dubbla kontroller ser ut, inte en beskrivning av hur en apparat kombinerar dem.

Kontrollera kombinationen på din gateway

Läs konfigurationen innan du litar på konsolsammanfattningen. Raderna som avgör policyn är certifikatläget, inloggningsuppgiftsskriptet och pluginordningen.

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 visar om ett certifikat krävs och vilket skript som körs efter det, och ordningen spelar större roll än namnen antyder. Certifikatdumpen ger identiteten som gatewayen ser, inklusive CN och serienumret du behöver för associationskartan. RADIUS-testet är det negativa fallet: ett fel lösenord måste ge Access-Reject, och ett rätt Access-Accept. Om en avvisad uppgift ändå ger en session är skriptet inte alls på autentiseringsvägen.

Kör sedan avbrottsfallet på en laboratorieinstans: stoppa den nödvändiga backend och anslut med giltiga uppgifter. Det förväntade resultatet är en vägran, och allt annat är reservpolicyn som ingen dokumenterade.

Skriv kravet som negativa fall

Ett användbart krav namnger bevisen, kontona som får presentera dem och resultatet när en verifierare saknas. Det anger också den tillåtna sammankopplingen mellan enhetsidentitet och personidentitet. Det är mer exakt än produktnamnen på inköpsordern, och det går att testa.

Acceptansen bör omfatta fyra vägran: ett olämpligt lokalt konto, ett saknat obligatoriskt bevis, en ogiltig andra faktor och en onåbar obligatorisk backend. Varje vägran behöver en logglinje som skiljer den från de andra, annars börjar nästa incident med gissningar. Registrera vilken komponent som tog varje beslut, eftersom gatewayen, RADIUS-servern och katalogen kommer att skylla på varandra.

Kör de fyra vägran igen efter varje plugin- eller firmwareändring. De är billiga, och policyn de skyddar är den del en angripare undersöker först.