Înlocuirea unei chei VPN compromise: ce trebuie să facă serverul

Un laptop care purta o cheie de client s-a pierdut, iar primul pas este de obicei ștergerea copiei locale. Asta nu schimbă nimic pe server, care are încă o autorizare ce va accepta cheia până când cineva o elimină. Înlocuirea înseamnă două operațiuni, iar doar a doua privește acreditarea veche.

Copia locală nu este autoritatea

O acreditare VPN este acceptată pentru că așa spune configurația din partea serverului. Pentru certificate, asta înseamnă că certificatul se înlănțuie la un emitent de încredere și nu apare într-o listă de revocare consultată de gateway. Pentru WireGuard, înseamnă că cheia publică a partenerului apare în configurația interfeței. Ștergerea unui fișier pe un client elimină o copie a unui secret și lasă regula de acceptare neatinsă.

De aceea o cheie furată continuă să funcționeze după curățarea evidentă, și de aceea incidentul pare nerezolvat chiar și când noua configurație este instalată.

Porniți de la regula serverului, apoi lucrați spre exterior, până la client.

Certificate: serverul deține decizia

Emiteți înlocuirea prin procesul emitentului însuși, astfel încât noua identitate să fie înregistrată, apoi retrageți-o pe cea veche cu o revocare semnată. Gateway-ul trebuie configurat să consulte acea sursă de revocare și trebuie să o reîncarce, altfel fișierul rămâne pe disc în timp ce tunelul continuă să accepte vechiul număr de serie. Sesiunile active pot supraviețui până la renegociere, așa că planificați o reconectare.

Confirmați că înlocuirea funcționează pentru aplicația vizată, apoi confirmați printr-un proces aprobat că certificatul retras nu mai stabilește acces.

Sunt două teste diferite și ambele sunt necesare. RFC 5280 definește semantica certificatelor și a revocării pe care se bazează gateway-ul.

WireGuard: cheia partenerului este identitatea

WireGuard nu are strat de certificate: cheia publică a partenerului este identitatea, iar intrarea allowed-ips a serverului este autorizarea. Eliminarea partenerului vechi din configurația interfeței este revocarea, și se aplică imediat noilor handshake-uri.

Sesiunile existente se termină când următorul handshake eșuează, ceea ce se întâmplă de obicei în câteva minute, nu instantaneu.

Distribuiți noua configurație printr-un canal căruia i-ați încredința o parolă, pentru că cheia privată este acreditarea. Păstrați o cheie pe dispozitiv, astfel încât un singur dispozitiv pierdut să nu oblige toate dispozitivele să se schimbe.

Ce altceva mai era în acel pachet

Un pachet de client transportă adesea mai mult decât cheia privată: o cheie TLS statică, un nume de utilizator și o parolă, un secret prepartajat sau un token de provizionare. Limitați incidentul la ce a fost expus efectiv și rotiți și acele elemente. Rotirea certificatului în timp ce o cheie statică partajată rămâne pe loc închide o ușă și lasă alta deschisă.

Dacă pachetul a fost partajat între dispozitive, fiecare dispozitiv care îl poartă moștenește expunerea.

Notați ce a fost rotit, pentru că următorul audit va întreba.

Dovediți refuzul, apoi înregistrați înlocuirea

Înlocuirea este completă când sunt valabile două fapte: noua identitate funcționează pentru serviciul vizat, iar cea veche este refuzată. Verificați al doilea cu acreditarea retrasă dintr-un mediu de test, sau cu o încercare controlată pe care organizația o aprobă, și citiți jurnalele gateway-ului pentru a confirma că refuzul a venit din politică, nu dintr-o greșeală de tastare. Apoi înregistrați identificatorul vechi, pe cel nou și momentul schimbării, pentru că aceste trei valori sunt ce are nevoie un auditor pentru a o reconstrui. Nimic altceva din tichet nu va explica golul.

Țineți cheile private în afara tichetelor și a conversațiilor, și eliminați exporturile învechite din stocare și din copiile de siguranță conform politicii.

O înlocuire fără test de refuz este o presupunere, nu o reparație.