VPN-øktstimaren og autentiseringstokenet går ut kvar for seg

Eit VPN-brot kan skje av grunnar som ser identiske ut frå klienten og ikkje har noko felles under overflata: økta i tunnelen vart avslutta, ein inaktivitets-timer slo til, eller eit bevis klienten brukte på nytt vart utdatert. Kvar har ein annan eigar og ei anna retting. Nettopp feilsekvensen i augneblinken brotet skjer, er det som skil dei, og han er som regel éi line.

Tre klokker går mot ein tunnel, og berre éi av dei er tunnelen.

Tre ulike klokker på ein tunnel

Øktsklokka høyrer til gatewayen: ei maksimal tilkoplingstid, ein inaktivitets-timeout eller begge, og ho avsluttar tunnelen når ein av dei er nådd. Tokenklokka høyrer til autentiseringssystemet, og ho avgjer kor lenge eit bevis kan leggjast fram igjen utan eit menneske. Baneklokka høyrer til kvar NAT eller brannmur mellom klient og gateway, og ho lèt mappingane gå ut for straumar ho reknar som avslutta. Alle tre gir ein fråkopling, og ingen av dei gir same loggline.

Berre den første er eit VPN-omgrep. Dei to andre er lånte frå identitet og nettverk, og dei vert rutinemessig forveksla med det.

Korleis tokenet faktisk vert gjenbrukt

OpenVPN-tenarar kan gje ut eit autentiseringstoken etter den første innlogginga, slik at ein ny forhandling av kontrollkanalen ikkje ber brukaren om bevis igjen. Klienten held fram med å leggje fram tokenet, og tenaren avgjer kor lenge det held seg akseptabelt. Når levetida til tokenet er kortare enn nyforhandlingsintervallet, mislukkast den neste nyforhandlinga, og klienten rapporterer ein autentiseringsfeil i staden for ein timeout. Difor verkar same profil i ein time og sviktar deretter på eit fast punkt.

Nyforhandlingsintervallet er ei eiga innstilling. Å endre det flyttar når tokenet vert lagt fram, ikkje kor lenge det lever.

Korleis kvar utløp ser ut frå klienten

Ein øktstimeout kjem vanlegvis som ein rein fråkopling med ein grunn frå tenarsida, ofte etter ei føreseieleg tid og utan nokon autentiseringsfeil. Ein inaktivitets-timeout ser ut som stille: tunnelen sluttar å bera trafikk, og så gir keepalive opp. Eit tokenutløp kjem som AUTH_FAILED midt i ei økt som verka eit sekund tidlegare.

Les lina, og sjå så på klokka. Ei tid som passar med ein konfigurert verdi er ikkje tilfeldig.

Kvifor eit lagra passord ikkje hjelper

Eit bufra passord svarar på ei utfordring for eit passord. Det forlengar ikkje levetida til eit token, og det oppfyller ikkje ei utfordring for ein annan faktor eller ein kontroll av tilstanden til eininga. Hyppigare nye forsøk, kortare tilkoplingstimeoutar eller ny import av profilen endrar ingenting på kor lenge identitetssystemet godtek beviset.

Dei varige rettingane er rett levetid på rett objekt, eller ein klientflyt som kan fullføre den påkravde utfordringa utan eit menneske.

Kva som skal dokumenterast og testast

Skriv ned alle tre verdiane: økts- og inaktivitetsgrensene til gatewayen, levetida til tokenet og den kortaste relevante mappingstimeouten på banen. Test deretter kvart utløp med vilje ved å forkorte éin verdi, sjå kva klienten rapporterer, og setje han attende. Stadfest kva brukaren må gjere ved kvar grense, fordi å krevje full innlogging kvar time er ei policyavgjerd nokon burde ha teke med vilje.

Eit brot som kjem heilt utan noka autentiseringshending, høyrer til banen eller inaktivitets-timaren, og det er ei anna undersøking med andre bevis.