Ihr VPN-Gateway ist kompromittiert: was tatsächlich offengelegt ist
Ein gehacktes VPN-Gateway sieht in seinen eigenen Tunnel hinein, aber das bedeutet nicht Kontrolle über jede Sitzung. Trennen Sie Verkehr, Reichweite und gespeicherte Geheimnisse vor der Wiederherstellung.
Ein VPN-Gateway steht am Ende des Tunnels, den es schützt, was bedeutet, dass es diese Verschlüsselung beendet, statt sie durchzuleiten. Wenn ein Angreifer den Host kontrolliert, wirkt der Tunnel von außen weiterhin gesund, während die Maschine in der Mitte nicht mehr vertrauenswürdig ist. Die nützliche Frage ist nicht, ob alles entschlüsselt wird. Sie lautet, was dieser Host sehen konnte, was er erreichen konnte und welche Geheimnisse tatsächlich auf ihm gespeichert waren. Diese drei Antworten unterscheiden sich stark, und die Reaktion unterscheidet sich mit ihnen.
Das Gateway beendet den Tunnel, also sieht es hinein
Verschlüsselung in einem VPN erfolgt Sprung für Sprung, und das Gateway ist der Sprung. Es entfernt die äußere Schicht, wendet Richtlinien an und leitet das innere Paket weiter, sodass jedes transportierte Paket irgendwann in lesbarer Form im Speicher dieses Hosts existiert. Das ist das Design und kein Mangel. Deshalb ist die Kompromittierung des Gateways ein anderes Ereignis als die Kompromittierung der Kryptografie des Tunnels.
Was der Angreifer zuerst gewinnt, ist Position: die Fähigkeit, transportierten Verkehr zu beobachten, die Weiterleitung zu ändern oder anstelle eines Backends zu antworten. Was er als Nächstes gewinnt, hängt vom Host ab, und hier überschätzen Menschen. Der Zugang zum Gateway allein übergibt keine TLS-Sitzungsschlüssel eines Browsers, denn die waren nie auf dem Gateway.
Drei Offenlegungen, die nicht gleich groß sind
Teilen Sie die Frage in transportierten Verkehr, erreichbare Systeme und gespeicherte Geheimnisse und beantworten Sie jede für sich.
| Exposure | What the attacker gains | What does not follow |
|---|---|---|
| Carried traffic | Plaintext of whatever the tunnel forwards without its own encryption | Keys for TLS sessions that terminate at the application |
| Reachable systems | Whatever the backends accept from the gateway's address | Control of every connected client endpoint |
| Stored secrets | The specific keys, tokens and accounts present on that host | Possession of every client certificate or of a CA key |
Die mittlere Zeile wird übersprungen. Ein Gateway hat normalerweise eine Route in private Netze und eine Quelladresse, der die Backends bereits vertrauen, sodass die interessante Frage ist, was diese Backends von dieser Adresse aus erlauben. Eine enge Client-Zugriffsrichtlinie ist eine gute Kontrolle, aber ein Angreifer auf dem Host ist nicht auf die Schnittstelle beschränkt, die ein normaler Client nutzen würde.
Die untere Zeile entscheidet, wie lange der Vorfall dauert. Ein Serverschlüssel und ein CA-Schlüssel haben völlig unterschiedliche Wirkungsradien, ebenso ein lokales Administratorkonto und ein schreibgeschütztes Überwachungstoken.
HTTPS im Tunnel bleibt HTTPS
Anwendungs-TLS endet in der Anwendung, nicht am VPN-Gateway, sodass ein kompromittiertes Gateway für diese Flüsse Chiffrat beobachtet. Das ist eine echte Grenze dessen, was der Angreifer erhält, und es lohnt sich, das klar zu sagen, weil die gegenteilige Behauptung Panik und schlechte Entscheidungen verbreitet. Zwei Bedingungen brechen das. Sitzt eine Inspektionskomponente mit vertrauenswürdigem Zertifikat im Pfad, kann das Gateway designbedingt Klartext sehen. Ist der Anwendungsendpunkt selbst kompromittiert, ist der Tunnel irrelevant.
Die Antwort darauf, was sie gesehen haben, ist also bedingt, und sie sollte als Bedingungen festgehalten und nicht als Urteil verkündet werden.
Was sich ändern muss, bevor Sie ihm wieder vertrauen
Den Host neu aufzubauen ist notwendig und selten ausreichend. Ein Angreifer, der noch ein Verwaltungskonto, eine Bereitstellungsanmeldeinformation oder einen Signaturschlüssel hält, kann den Host nach seinem Belieben zurücksetzen. Die Wiederherstellung muss von einem Administrationspfad ausgehen, der nicht von der kompromittierten Maschine abhängt.
Bestandsaufnahme, was darauf war, bevor Sie entscheiden, was rotiert wird. Schlüssel, Dienstkonten, API-Token, lokale Benutzer, geplante Aufträge, Vertrauensbeziehungen und die Bereitstellungspipeline sind alles Kandidaten, und jeder hat einen Eigentümer, der das bestätigen sollte.
ss -lntup
getent passwd
crontab -l
ip route show table allDiese Auflistung ist der schnellste Weg zu sehen, was der Host anbot und wohin er reichen konnte. Sichern Sie zuerst die Beweise, nach dem Verfahren des Verantwortlichen für die Reaktion, denn ein Neuaufbau zerstört genau das, was eine Untersuchung braucht. NIST SP 800-61 Revision 3 behandelt Vorbereitung, Erkennung, Reaktion und Wiederherstellung als Teile eines Risikoprozesses und nicht als Neustartanweisung.
Grenzen, die den nächsten Fall billiger machen
Vier Grenzen lohnt es sich zu bauen, bevor Sie sie brauchen. Halten Sie einen unabhängigen Wiederherstellungspfad, der sich nicht über das Gateway authentifiziert. Halten Sie die Signaturbefugnis getrennt vom Host, der Verkehr bedient. Begrenzen Sie, was das Gateway erreichen kann, damit ein kompromittiertes Gateway nicht automatisch ein kompromittiertes Verwaltungsnetz ist. Und halten Sie fest, wem welche Anmeldeinformation gehört, damit Rotation ein Anruf ist statt eines archäologischen Projekts.
Nichts davon verhindert eine Kompromittierung. Es begrenzt sie und macht den Unterschied zwischen einer schlechten Woche und einem schlechten Quartal.