Bytte ut en lekket VPN-nøkkel: hva serveren må gjøre

En bærbar PC med en klientnøkkel ble borte, og det første tiltaket er vanligvis å slette den lokale kopien. Det endrer ingenting på serveren, som fortsatt har en autorisasjon som vil godta nøkkelen til noen fjerner den. Utskifting er to operasjoner, og bare den andre gjelder den gamle legitimasjonen.

Den lokale kopien er ikke autoriteten

En VPN-legitimasjon godtas fordi konfigurasjonen på serversiden sier det. For sertifikater betyr det at sertifikatet knyttes til en klarert utsteder og ikke står på en tilbakekallingsliste som gatewayen sjekker. For WireGuard betyr det at peerens offentlige nøkkel står i grensesnittkonfigurasjonen. Å slette en fil på en klient fjerner én kopi av en hemmelighet og lar godtakelsesregelen være urørt.

Derfor virker en stjålet nøkkel fortsatt etter den åpenbare opprydningen, og derfor føles hendelsen uavklart selv når den nye konfigurasjonen er installert.

Start med serverens regel, og arbeid deg deretter utover til klienten.

Sertifikater: serveren har avgjørelsen

Utsted erstatningen gjennom utstederens egen prosess slik at den nye identiteten blir registrert, og trekk deretter tilbake den gamle med en signert tilbakekalling. Gatewayen må være konfigurert til å slå opp den tilbakekallingskilden, og den må laste den på nytt, ellers blir filen liggende på disken mens tunnelen fortsetter å godta det gamle serienummeret. Aktive økter kan også overleve til re-forhandling, så planlegg en gjentilkobling.

Bekreft at erstatningen virker for den tiltenkte applikasjonen, og bekreft deretter gjennom en godkjent prosess at det avviklede sertifikatet ikke lenger etablerer tilgang.

Det er to forskjellige tester, og begge kreves. RFC 5280 definerer sertifikat- og tilbakekallingssemantikken gatewayen bygger på.

WireGuard: peernøkkelen er identiteten

WireGuard har ikke noe sertifikatlag: peerens offentlige nøkkel er identiteten, og serverens allowed-ips-oppføring er autorisasjonen. Å fjerne den gamle peeren fra grensesnittkonfigurasjonen er tilbakekallingen, og den gjelder umiddelbart for nye håndtrykk.

Eksisterende økter avsluttes når neste håndtrykk mislykkes, noe som vanligvis skjer innen et par minutter og ikke umiddelbart.

Distribuer den nye konfigurasjonen over en kanal du ville betrodd et passord, fordi den private nøkkelen er legitimasjonen. Hold én nøkkel per enhet, slik at én tapt enhet ikke tvinger hver enhet til å bytte.

Hva annet var i den pakken

En klientpakke bærer ofte mer enn den private nøkkelen: en statisk TLS-nøkkel, et brukernavn og passord, en forhåndsdelt hemmelighet eller et provisjoneringstoken. Begrens hendelsen til det som faktisk ble eksponert, og roter også disse elementene. Å rotere sertifikatet mens en delt statisk nøkkel blir stående lukker én dør og lar en annen stå åpen.

Hvis pakken ble delt mellom enheter, arver hver enhet som bærer den eksponeringen.

Skriv ned hva som ble rotert, fordi neste revisjon vil spørre.

Bevis avvisningen, og registrer deretter erstatningen

Erstatningen er fullført når to fakta holder: den nye identiteten virker for den tiltenkte tjenesten, og den gamle blir avvist. Verifiser det andre med den avviklede legitimasjonen fra et testmiljø, eller med et kontrollert forsøk organisasjonen godkjenner, og les gateway-loggene for å bekrefte at avvisningen kom fra policy og ikke fra en skrivefeil. Registrer deretter den gamle identifikatoren, den nye og tidspunktet for endringen, fordi det er disse tre verdiene en revisor trenger for å rekonstruere den. Ingenting annet i saken vil forklare gapet.

Hold private nøkler unna saker og chat, og fjern utdaterte eksporter fra lagring og sikkerhetskopier i tråd med policy.

En erstatning uten avvisningstest er en antakelse, ikke en retting.