Een gelekt VPN-sleutel vervangen: wat de server moet doen

Een laptop met een clientsleutel is kwijtgeraakt, en de eerste actie is meestal de lokale kopie verwijderen. Dat verandert niets op de server, die nog steeds een autorisatie heeft die de sleutel accepteert tot iemand hem verwijdert. Vervangen zijn twee handelingen, en alleen de tweede gaat over de oude referentie.

De lokale kopie is niet de autoriteit

Een VPN-referentie wordt geaccepteerd omdat de configuratie aan de serverkant dat zegt. Voor certificaten betekent dat het certificaat aan een vertrouwde uitgever ketent en niet op een intrekkingslijst staat die de gateway raadpleegt. Voor WireGuard betekent het dat de publieke sleutel van de peer in de interfaceconfiguratie staat. Een bestand op een client verwijderen haalt één kopie van een geheim weg en laat de acceptatieregel onaangeroerd.

Daarom blijft een gestolen sleutel werken na de voor de hand liggende opruiming, en daarom voelt het incident onopgelost ook als de nieuwe configuratie is geïnstalleerd.

Begin bij de regel van de server en werk dan naar buiten toe naar de client.

Certificaten: de server heeft de beslissing

Geef de vervanging uit via het eigen proces van de uitgever zodat de nieuwe identiteit wordt vastgelegd, en trek de oude daarna in met een ondertekende intrekking. De gateway moet zijn geconfigureerd om die intrekkingsbron te raadplegen, en hij moet die opnieuw laden, anders blijft het bestand op schijf staan terwijl de tunnel het oude serienummer blijft accepteren. Actieve sessies kunnen ook overleven tot de heronderhandeling, dus plan een herverbinding.

Bevestig dat de vervanging werkt voor de bedoelde toepassing, en bevestig daarna via een goedgekeurd proces dat het buiten gebruik gestelde certificaat geen toegang meer verschaft.

Dat zijn twee verschillende tests en beide zijn nodig. RFC 5280 definieert de certificaat- en intrekkingssemantiek waarop de gateway vertrouwt.

WireGuard: de peersleutel is de identiteit

WireGuard heeft geen certificaatlaag: de publieke sleutel van de peer is de identiteit, en de allowed-ips-regel van de server is de autorisatie. De oude peer uit de interfaceconfiguratie verwijderen is de intrekking, en die geldt onmiddellijk voor nieuwe handshakes.

Bestaande sessies eindigen wanneer de volgende handshake mislukt, wat meestal binnen een paar minuten gebeurt in plaats van onmiddellijk.

Verspreid de nieuwe configuratie via een kanaal waaraan je een wachtwoord zou toevertrouwen, want de privésleutel is de referentie. Houd één sleutel per apparaat, zodat één verloren apparaat niet elk apparaat dwingt te wisselen.

Wat er nog meer in dat pakket zat

Een clientpakket bevat vaak meer dan de privésleutel: een statische TLS-sleutel, een gebruikersnaam en wachtwoord, een vooraf gedeeld geheim of een provisioning-token. Beperk het incident tot wat daadwerkelijk is blootgesteld en roteer die items ook. Het certificaat roteren terwijl een gedeelde statische sleutel blijft staan, sluit één deur en laat een andere open.

Als het pakket tussen apparaten is gedeeld, erft elk apparaat dat het draagt de blootstelling.

Schrijf op wat er is geroteerd, want de volgende audit zal het vragen.

Bewijs de weigering en leg de vervanging vast

De vervanging is compleet wanneer twee feiten gelden: de nieuwe identiteit werkt voor de bedoelde dienst, en de oude wordt geweigerd. Verifieer het tweede met de buiten gebruik gestelde referentie vanuit een testomgeving, of met een gecontroleerde poging die de organisatie goedkeurt, en lees de gateway-logs om te bevestigen dat de weigering uit beleid kwam en niet uit een typefout. Leg daarna de oude identificatie, de nieuwe en het tijdstip van de wijziging vast, want die drie waarden heeft een auditor nodig om het te reconstrueren. Niets anders in het ticket zal de leemte verklaren.

Houd privésleutels buiten tickets en chat, en verwijder verouderde exports uit opslag en back-ups volgens beleid.

Een vervanging zonder weigeringstest is een aanname, geen oplossing.