Bytt VPN-passord uten å låse ute alle enheter
Passordendring oppdaterer ikke lagrede kopier. Inventer hver klient, erstatt den lagrede verdien hos eieren og stopp gjentakelsesløkken.
Tre telefoner, en ruter og en overvåkingssjekk holder fortsatt på det gamle passordet, og én av dem kobler til på nytt hvert nittiende sekund. Kontopassordet ble endret for ti minutter siden, så hver av disse klientene sender nå en verdi serveren avviser. Det er øyeblikket myten brister: en passordendring berører kontoen, ikke kopiene av den gamle verdien på hver enhet. Det som følger, er arbeidet endringen ikke gjorde.
Myten: én endring, overalt samtidig
Troen er at en passordendring logger ut alt og tvinger en ren ny innlogging. Det gjør den ikke, fordi serveren bare sporer hvilken legitimasjon den sist godtok, mens klientene beholder det de lagret. En enhet med lagret passord prøver det på nytt etter sin egen plan og feiler stille til noen oppdager at kontoen er låst. Når man godtar at kopiene lever utenfor kontoen, slutter rotasjonen å se ut som én handling.
Ingenting av dette taler mot rotasjon. Det taler for å behandle de lagrede kopiene som en del av endringen i stedet for en ettertanke. En utlåsing kommer vanligvis fra parallelle gjentakelser: hver enhet fortsetter å sende den gamle verdien etter sin egen plan til telleren slår ut. Kontoen ser da angrepet ut, mens den bare tilbys legitimasjon ingen har erstattet. Den forskjellen betyr noe, fordi løsningen er en enhetsliste og ikke en strengere utlåsingspolicy.
Inventer kopiene før du roterer
Skriv oversikten før du åpner passordskjemaet. List opp hver klient, skript, automatisering og administrert profil som autentiserer som denne kontoen: telefonen som kobler til av seg selv, ruteren som ble konfigurert for to år siden, laptopen som bare våkner på mandager, og overvåkingssjekken som prøver hvert minutt. For hver av dem, noter hvor legitimasjonen er lagret, om enheten kan nås under endringen, og hvilken gjenopprettingsvei som finnes hvis den ikke kan koble til på nytt. Den listen er det som gjør en risikabel endring om til en planlagt endring, og den må finnes før det gamle passordet slutter å virke.
Frakoblede enheter er den klassiske glippen. En laptop i en skuff kommer tilbake tre uker senere og presenterer den utdaterte verdien på det verste tidspunktet. Noter også plasseringen og planen dens, fordi du må jage den i stedet for å vente på den.
På en Linux-flåte er søket mekanisk og ikke smart. Se etter profiler som refererer til en legitimasjonsfil, deretter selve legitimasjonsfilene, fordi den andre listen er den som må skrives om. Gjenta øvelsen for skrivebordsklienter og telefoner, der lageret er en profil eller en nøkkelringoppføring og ikke en sti. Målet er en liste du kan arbeide deg gjennom, ikke en skanning som hevder å finne hver kopi.
grep -rl auth-user-pass /etc/openvpn /etc/NetworkManager
grep -rl auth-user-pass ~/.config 2>/dev/null
Mål kopiene mot menneskene som eier dem. En enhet ingen gjør krav på, er en enhet ingen kommer til å oppdatere, og det er også den som mest sannsynlig fortsetter å prøve på nytt.
Hvilken hemmelighet du faktisk roterer
Et kontopassord er bare én legitimasjon i en VPN-utrulling. En nøkkelpassfrase, en sertifikatidentitet og en valgfri peer-hemmelighet har hver sin erstatningsvei og sin egen eier. Å endre kontopassordet gjør ingenting for en enhet som autentiserer med sertifikat, og å utstede et sertifikat på nytt gjør ingenting for en klient med lagret passord. Navngi hemmeligheten før du navngir løsningen.
Hvis rotasjonen drives av mistanke og ikke av policy, har hendelsesprosessen forrang for bekvemmelighetsplanen. Tilbakekall det bevisene krever, og godta ekstraarbeidet på enhetslisten. Den beslutningen tilhører hendelseseieren, ikke hvem som tilfeldigvis holder skjemaet for tilbakestilling av passord.
Erstatt den lagrede verdien der den bor
Endre legitimasjonen gjennom mekanismen tjenesten dokumenterer, og oppdater deretter den lagrede kopien eller kjør innloggingsflyten på hver enhet du vil beholde. Ikke rediger en generert konfigurasjon bak en behandler som skriver den på nytt, fordi behandleren gjenoppretter den eldre verdien ved neste kjøring, og redigeringen blir en forsinket feil. Oppdater kilden behandleren leser, eller bruk klientens eget legitimasjonslager. Uansett må enheten ende opp med den nye verdien på stedet klienten faktisk leser.
En klient som lagrer en passordfil, trenger at filen skrives på nytt, mens en klient som spør, trenger en fullført innlogging. NetworkManager holder hemmeligheten inne i tilkoblingsprofilen, så endringen går gjennom nmcli i stedet for en teksteditor:
nmcli connection modify work vpn.secrets "password=NEW"
nmcli connection up work
En profil som leser en legitimasjonsfil, er et tredje tilfelle. Erstatt innholdet i den filen, hold tillatelsene lukket, og last klienten på nytt i stedet for å redigere profilen som peker på den. Profilen ble ikke endret; bare hemmeligheten den leser, ble endret.
Koble hver tiltenkt enhet til på nytt én gang, med vilje, og se hvilke som feiler. Hvis en enhet fortsetter å feile, se på kontoen den peker på og lageret den leser før du endrer passordet igjen, fordi en andre endring mangedobler kopiene som må oppdateres. En enhet som feiler to ganger peker vanligvis på feil konto eller leser et lager du ennå ikke har funnet. Rett det, og koble deretter til på nytt.
Økter og tokens overlever passordet
Å endre passordet beviser ikke at eksisterende økter eller separate sertifikater ble tilbakekalt. Noen tjenester holder en økt i live til den utløper eller avsluttes eksplisitt, og utstedte tokens har sin egen levetid. Sjekk hva tjenesten faktisk gjør i stedet for å anta at endringen var global. Hvis endringen var drevet av mistanke, avslutt øktene eksplisitt og bekreft resultatet.
Veiledningen om legitimasjonens livssyklus i NIST SP 800-63B holder autentikatorer og økter i separate kategorier, og derfor er en passordendring og en global utlogging forskjellige operasjoner. Behandle dem som to oppgaver med to fullføringskriterier. Den første er ferdig når den nye verdien virker, og den andre når de gamle øktene er borte.
Registrer fullføringen uten å skrive det nye passordet inn i posten. En rotasjonslogg som inneholder legitimasjonen, er en ny hendelse som venter på en delt disk. Noter datoen, enhetene som ble oppdatert, og enhetene som fortsatt står igjen.