Welche Validatoren betrifft ein zusätzliches Root-Zertifikat?

Sie finden ein Root-Zertifikat, das dort nicht hingehört, und die erste Frage ist, wessen Identität es vortäuschen kann. Die ehrliche Antwort hängt davon ab, welche Software diesen Speicher konsultiert und wie Ihre VPN ihr Gateway prüft. Ein Browser, ein Paketmanager und ein VPN-Client mit gepinntem Fingerabdruck teilen nicht zwangsläufig dieselbe Vertrauensentscheidung. Ordnen Sie die Validatoren zu, bevor Sie den Umfang festlegen.

Ein Root im Systemspeicher ist kein universeller Schlüssel

Die Installation eines Roots macht Zertifikate, die mit diesem Schlüssel signiert sind, für Programme akzeptabel, die den betroffenen Speicher nutzen. Sie werden dadurch nicht automatisch überall akzeptabel, denn manche Anwendungen bringen ihr eigenes Bundle mit oder prüfen einen gepinnten Wert. Es beweist auch nicht, dass jemand Code auf dem Rechner ausgeführt hat; eine Vertrauensänderung ist eine von mehreren Möglichkeiten. Behandeln Sie das Zertifikat als Befund, dessen Umfang zu bestimmen ist, nicht als den gesamten Vorfall.

Der Speicher ist ebenso wichtig wie das Zertifikat: ein Bundle auf Benutzerebene und ein systemweiter Anker erreichen unterschiedliche Verbraucher.

Ordnen Sie jeden Validator und seine Vertrauensquelle zu

Notieren Sie jede Komponente, die Zertifikate für die betroffenen Abläufe validiert: Browser, Paketmanager, Mailclient, VPN. Suchen Sie dann die Vertrauensquelle, die jede von ihnen liest.

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

Die Verzeichnisauflistung zeigt lokal hinzugefügte Anker auf Systemen im Debian-Stil, und die Vertrauensliste zeigt, was der Systemspeicher derzeit bereitstellt. Ein Browser mit eigenem Speicher erscheint dort nicht, und eine Java- oder Python-Anwendung kann noch ein anderes Bundle nutzen. Halten Sie fest, welche Einträge erwartet werden und welche nicht, und nutzen Sie dabei den Fingerabdruck statt nur den Anzeigenamen. Diese Liste braucht ein Incident-Responder, bevor er irgendetwas löscht.

Prüfen Sie die eigene Peer-Validierung der VPN

Eine VPN mit einer privaten CA oder einem expliziten Fingerabdruck bewertet das Gateway anhand ihrer eigenen Konfiguration. Vergleichen Sie, was der Client erwartet, mit dem, was das Gateway präsentiert.

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

Die Ausgabe liefert den SHA-256-Fingerabdruck und den Subject des Zertifikats, das der Endpunkt präsentiert; beides können Sie mit dem konfigurierten Wert vergleichen. OpenVPN's Peer-Fingerprint-Option führt diesen Vergleich für den Tunnel durch, ohne dass der Systemspeicher den Signierer akzeptieren muss. Diese Unabhängigkeit ist für den Tunnel nützlich und sagt nichts über den Browser. Sie hilft auch nicht, wenn der erwartete Fingerabdruck von Anfang an aus der verdächtigen Verbindung kopiert wurde.

Bestimmen Sie den Umfang des Vorfalls über das Zertifikat hinaus

Entfernen Sie mit dem Verfahren des Geräteeigentümers unbefugte Anker und suchen Sie nach den Änderungen, die sie üblicherweise begleiten: neue Dienste, veränderte Clients, geänderte Proxy-Einstellungen. Bestätigen Sie auf einem verwalteten Rechner die legitime Konfiguration, bevor Sie Material löschen, auf das andere Software angewiesen ist. Halten Sie für jeden Validator fest, woher sein Vertrauen stammt, welche Identität er erwartet und wie Sie bestätigt haben, dass die aktuelle Konfiguration korrekt ist. Ein funktionierender Tunnel nach der Bereinigung ist eine Beobachtung, kein Beweis, dass der Endpunkt sauber ist.

Testen Sie anschließend die Abläufe erneut, die den Speicher genutzt haben, denn das Entfernen eines Ankers kann einen internen Dienst brechen, der sich zu Recht darauf verlassen hat. Die Wiederherstellung ist abgeschlossen, wenn die erwarteten Vertrauensbeziehungen funktionieren und die unerwarteten nicht.