Ce validatori afectează un certificat rădăcină suplimentar?

Găsiți un certificat rădăcină care nu ar trebui să fie acolo, iar prima întrebare este a cui identitate poate fi imitată. Răspunsul onest depinde de ce software consultă acel depozit și de modul în care VPN-ul dumneavoastră își verifică gateway-ul. Un browser, un manager de pachete și un client VPN cu o amprentă fixată nu împart neapărat aceeași decizie de încredere. Cartografiați validatorii înainte de a decide amploarea.

O rădăcină din depozitul de sistem nu este o cheie universală

Instalarea unei rădăcini face certificatele semnate cu acea cheie acceptabile pentru programele care folosesc depozitul afectat. Nu le face automat acceptabile peste tot, deoarece unele aplicații își aduc propriul pachet sau verifică o valoare fixată. De asemenea, nu dovedește că cineva a rulat cod pe mașină; o schimbare de încredere este una dintre mai multe capacități. Tratați certificatul ca o constatare de delimitat, nu ca întregul incident.

Depozitul contează la fel de mult ca certificatul: un pachet la nivel de utilizator și o ancoră la nivel de sistem ajung la consumatori diferiți.

Cartografiați fiecare validator și sursa sa de încredere

Notați fiecare componentă care validează certificate pentru fluxurile de lucru afectate: browser, manager de pachete, client de e-mail, VPN. Apoi găsiți sursa de încredere pe care o citește fiecare.

ls /usr/local/share/ca-certificates
trust list | grep -i -E "vpn|corp"

Listarea directorului arată ancore adăugate local pe sisteme de tip Debian, iar lista de încredere arată ce expune în prezent depozitul de sistem. Un browser cu depozit propriu nu va apărea acolo, iar o aplicație Java sau Python poate folosi încă un alt pachet. Înregistrați care intrări sunt așteptate și care nu, folosind amprenta și nu doar numele afișat. Acea listă este ceea ce are nevoie un responsabil de incident înainte de a șterge ceva.

Verificați validarea de partener a VPN-ului însuși

Un VPN cu o CA privată sau o amprentă explicită evaluează gateway-ul conform propriei configurații. Comparați ce așteaptă clientul cu ce prezintă gateway-ul.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts </dev/null 2>/dev/null | openssl x509 -noout -fingerprint -sha256 -subject

Rezultatul oferă amprenta SHA-256 și subiectul certificatului prezentat de punctul final, pe care le puteți compara cu valoarea configurată. OpenVPN are o opțiune de amprentă de partener care face acea comparație pentru tunel fără a cere depozitului de sistem să accepte semnatarul. Această independență este utilă pentru tunel și nu spune nimic despre browser. Nu ajută nici dacă amprenta așteptată a fost copiată de la început din conexiunea suspectă.

Delimitați incidentul dincolo de certificat

Folosiți procedura proprietarului dispozitivului pentru a elimina ancorele neautorizate și a căuta modificările care le însoțesc de obicei: servicii noi, clienți modificați, setări de proxy modificate. Pe o mașină gestionată, confirmați configurația legitimă înainte de a șterge material de care depinde alt software. Pentru fiecare validator, notați de unde vine încrederea sa, ce identitate așteaptă și cum ați confirmat că configurația actuală este corectă. Un tunel funcțional după curățare este o observație, nu o dovadă că punctul final este curat.

Apoi retestați fluxurile de lucru care foloseau depozitul, deoarece eliminarea unei ancore poate rupe un serviciu intern care se baza legitim pe ea. Recuperarea este completă când relațiile de încredere așteptate funcționează, iar cele neașteptate nu.