Byt VPN-lösenord utan att låsa ute alla enheter

Tre telefoner, en router och en övervakningskontroll håller fortfarande det gamla lösenordet, och en av dem återansluter var nittionde sekund. Kontolösenordet ändrades för tio minuter sedan, så var och en av dessa klienter skickar nu ett värde som servern avvisar. Det är ögonblicket då myten brister: en lösenordsändring rör kontot, inte kopiorna av det gamla värdet på varje enhet. Det som följer är arbetet som ändringen inte gjorde.

Myten: en ändring, överallt samtidigt

Tron är att ett lösenordsbyte loggar ut allt och tvingar fram en ren ny inloggning. Det gör det inte, eftersom servern bara spårar vilken autentiseringsuppgift den senast accepterade, medan klienterna behåller det de sparade. En enhet med sparat lösenord försöker igen enligt sitt eget schema och misslyckas tyst tills någon märker att kontot är låst. När man accepterar att kopiorna lever utanför kontot slutar rotationen att se ut som en enda åtgärd.

Inget av detta talar emot rotation. Det talar för att behandla de sparade kopiorna som en del av ändringen i stället för en eftertanke. En utelåsning kommer vanligtvis från parallella upprepningar: varje enhet fortsätter att skicka det gamla värdet enligt sitt eget schema tills räknaren slår till. Kontot ser då attackerat ut medan det bara erbjuds autentiseringsuppgifter som ingen har ersatt. Den skillnaden spelar roll, eftersom lösningen är en enhetslista och inte en strängare utelåsningspolicy.

Inventera kopiorna innan du roterar

Skriv inventariet innan du öppnar lösenordsformuläret. Lista varje klient, skript, automatisering och hanterad profil som autentiserar som detta konto: telefonen som ansluter av sig själv, routern som konfigurerades för två år sedan, laptopen som bara vaknar på måndagar, och övervakningskontrollen som försöker varje minut. För var och en, notera var autentiseringsuppgiften lagras, om enheten kan nås under ändringen och vilken återställningsväg som finns om den inte kan återansluta. Den listan är det som gör en riskabel ändring till en planerad, och den måste finnas innan det gamla lösenordet slutar fungera.

Offline-enheter är den klassiska missen. En laptop i en låda kommer tillbaka tre veckor senare och presenterar det inaktuella värdet i värsta möjliga ögonblick. Notera också dess plats och schema, eftersom du måste jaga den i stället för att vänta på den.

På en Linux-flotta är sökningen mekanisk och inte smart. Leta efter profiler som refererar till en autentiseringsfil, sedan själva autentiseringsfilerna, eftersom den andra listan är den som måste skrivas om. Upprepa övningen för skrivbordsklienter och telefoner, där lagringen är en profil eller en nyckelringspost och inte en sökväg. Målet är en lista du kan arbeta dig igenom, inte en skanning som påstår sig hitta varje kopia.

grep -rl auth-user-pass /etc/openvpn /etc/NetworkManager
grep -rl auth-user-pass ~/.config 2>/dev/null

Mät kopiorna mot människorna som äger dem. En enhet som ingen gör anspråk på är en enhet som ingen kommer att uppdatera, och det är också den som mest sannolikt fortsätter att försöka igen.

Vilken hemlighet du faktiskt roterar

Ett kontolösenord är bara en autentiseringsuppgift i en VPN-driftsättning. En nyckelfras, en certifikatidentitet och en valfri peer-hemlighet har var sin ersättningsväg och var sin ägare. Att ändra kontolösenordet gör ingenting för en enhet som autentiserar med certifikat, och att utfärda ett certifikat på nytt gör ingenting för en klient med sparat lösenord. Namnge hemligheten innan du namnger lösningen.

Om rotationen drivs av misstanke och inte av policy har incidentprocessen företräde framför bekvämlighetsplanen. Återkalla det bevisen kräver och acceptera extraarbetet på enhetslistan. Det beslutet tillhör incidentägaren, inte den som råkar hålla i formuläret för återställning av lösenordet.

Ersätt det sparade värdet där det bor

Ändra autentiseringsuppgiften genom mekanismen som tjänsten dokumenterar, uppdatera sedan den sparade kopian eller kör inloggningsflödet på varje enhet du vill behålla. Redigera inte en genererad konfiguration bakom en hanterare som skriver om den, eftersom hanteraren återställer det äldre värdet vid nästa körning och redigeringen blir ett fördröjt fel. Uppdatera källan som hanteraren läser, eller använd klientens eget autentiseringslager. Hur som helst måste enheten sluta med det nya värdet på den plats där klienten faktiskt läser.

En klient som lagrar en lösenordsfil behöver filen omskriven, medan en klient som frågar behöver en slutförd inloggning. NetworkManager håller hemligheten i anslutningsprofilen, så ändringen går genom nmcli i stället för en textredigerare:

nmcli connection modify work vpn.secrets "password=NEW"
nmcli connection up work

En profil som läser en autentiseringsfil är ett tredje fall. Ersätt innehållet i den filen, håll dess behörigheter stängda och ladda om klienten i stället för att redigera profilen som pekar på den. Profilen ändrades inte; bara hemligheten den läser ändrades.

Återanslut varje avsedd enhet en gång, medvetet, och se vilka som misslyckas. Om en enhet fortsätter att misslyckas, titta på kontot den pekar på och lagret den läser innan du byter lösenordet igen, eftersom en andra ändring mångdubblar kopiorna som måste uppdateras. En enhet som misslyckas två gånger pekar vanligtvis på fel konto eller läser ett lager du ännu inte hittat. Åtgärda det och återanslut sedan.

Sessioner och tokens överlever lösenordet

Att byta lösenordet bevisar inte att befintliga sessioner eller separata certifikat har återkallats. Vissa tjänster håller en session vid liv tills den löper ut eller avslutas uttryckligen, och utfärdade tokens bär sin egen livstid. Kontrollera vad tjänsten faktiskt gör i stället för att anta att ändringen var global. Om ändringen drevs av misstanke, avsluta sessionerna uttryckligen och bekräfta resultatet.

Vägledningen om autentiseringsuppgifternas livscykel i NIST SP 800-63B håller autentiserare och sessioner i separata kategorier, och därför är ett lösenordsbyte och en global utloggning olika operationer. Behandla dem som två uppgifter med två slutförandekriterier. Den första är klar när det nya värdet fungerar, och den andra när de gamla sessionerna är borta.

Registrera slutförandet utan att skriva det nya lösenordet i posten. En rotationslogg som innehåller autentiseringsuppgiften är en ny incident som väntar på en delad disk. Notera datumet, enheterna som uppdaterades och enheterna som fortfarande återstår.