So testen Sie, was ein Notausschalter auf einem kompromittierten Host abdeckt

Führen Sie den Ausfalltest aus, lesen Sie das Ergebnis jeder Schicht und sehen Sie, wo ein Kill-Switch endet: Er blockiert Pfade, nicht Software, die Daten vor der Verschlüsselung liest.

Schalten Sie den Kill-Switch ein, nehmen Sie den Tunnelserver offline und beobachten Sie, was die Maschine noch tut. Der Test lohnt sich, weil er trennt, was die Firewall durchsetzt, von dem, was Sie angenommen haben, und die Ergebnisse sind enger, als die meisten Produktseiten nahelegen. Ein Kill-Switch regelt Netzwerkpfade; er regelt keine Software, die bereits auf dem Gerät läuft. Ich führe diese Sequenz auf jeder Maschine aus, deren Client angibt, fail-closed zu sein, und sie dauert etwa zehn Minuten.

Beim Client anfangen, nicht beim Server

Der Durchsetzungspunkt ist der Host, an dem Sie sitzen: die Firewall des Betriebssystems, ein Hilfsdienst oder der Treiber des VPN-Clients selbst. Das zählt, weil alles, was der Schalter tun kann, dadurch begrenzt ist, was diese Schicht sieht. Setzt der Client die Sperre mit einer Routingregel plus Markierung um, kann alles mit genügend Rechten eine eigene Regel hinzufügen; nutzt er eine Kernel-Firewalltabelle, kann dasselbe Recht die Tabelle bearbeiten. Die Stärke der Verschlüsselung spielt hier nie eine Rolle.

Zuerst ist also zu klären, wer die Richtlinie auf diesem Gerät besitzt und was sie überschreiben darf. Auf einem verwalteten Arbeitsrechner ist die Antwort meist der Endpoint-Agent der Organisation, und ein privates VPN entfernt diese Möglichkeiten nicht, wie der Tunnel auch konfiguriert ist.

Schritt eins: Bestätigen Sie die Sperre auf den Pfaden, die sie Ihrer Meinung nach abdeckt

Nehmen Sie den Tunnel am fernen Ende herunter, nicht beim Client, damit der Client weiterhin glaubt, verbunden sein zu sollen. Probieren Sie dann, was ein Mensch tatsächlich probieren würde:

curl -m 5 -sS -o /dev/null -w '%{http_code}
' https://example.com
ping -c 2 1.1.1.1
ip route
nft list ruleset   # or: iptables -S

Sie wollen einen Client, der schnell und sauber scheitert, nicht einen, der bis zum Browser-Timeout hängt. Hängen bedeutet meist, dass Pakete still von einer Regel ohne Zurückweisung verworfen werden, was akzeptabel ist, aber auch bedeuten kann, dass der Client eine veraltete Standardroute auf eine tote Schnittstelle hinterlassen hat. Lesen Sie die Routentabelle, während der Tunnel unten ist: eine Standardroute, die noch auf das Tunnelgerät zeigt, und eine Firewallregel, die nur neue ausgehende Verbindungen blockiert, sind zwei verschiedene Zustände, und nur einer davon ist fail-closed.

Wiederholen Sie dieselben Befehle mit ein- und ausgeschalteter Allow-LAN-Option des Clients. Dieser Schalter ist der Ort der meisten Überraschungen, weil er einen Pfad wieder öffnet, den der Rest der Richtlinie schließen sollte.

Schritt zwei: DNS und IPv6 als getrennte Pfade prüfen

Namensauflösung ist die Lücke, die die meisten Implementierungen überlebt, weil die Abfrage über etwas anderes als den Systemresolver hinausgehen kann. Fragen Sie mit einem Werkzeug, das Ihre Resolver-Konfiguration ignoriert, und prüfen Sie dabei die v6-Seite:

dig +short example.com
dig +short @1.1.1.1 example.com
curl -6 -m 5 -sS https://example.com -o /dev/null -w '%{http_code}
'
ip -6 route

Leere Antworten auf beide Namensabfragen bei abgeschaltetem Tunnel sind das gewünschte Ergebnis. Antwortet die zweite Abfrage, ist eine fest codierte Resolver-Adresse erreichbar und der Tunnel nicht der einzige Weg von der Maschine. Gelingt nur die v6-Anfrage, deckt die Richtlinie IPv4 ab und ignoriert IPv6, was dasselbe Leck in einer anderen Adressfamilie ist.

Browser machen das von außen schwerer lesbar, weil ein für DNS über HTTPS konfigurierter Browser die Abfrage über eine HTTPS-Anfrage auflöst: Die Abfrage ist nur so blockiert, wie Port 443 zu diesem Endpunkt es ist. Auf einem Host, dessen Richtlinie das lokale Subnetz erlaubt, kann diese Anfrage noch einen Resolver im LAN erreichen.

Schritt drei: Netzwerkexposition von Endpoint-Exposition trennen

Nun der Teil, den keine Firewallregel erreicht. Ein Kill-Switch blockiert Pfade von der Maschine; er hindert Software auf der Maschine nicht daran, Daten vor der Verschlüsselung zu lesen, und er hindert diese Software nicht daran, den Tunnel legitim zu nutzen. Ein Keylogger, eine bösartige Erweiterung, ein offen gelassener Bildschirm, ein Synchronisierungsclient mit breiten Rechten: All das bewegt Informationen über eine Verbindung, die der Schalter gern erlaubt.

Dasselbe gilt für Überwachungssoftware, die ein Arbeitgeber absichtlich installiert hat. Routen zu blockieren entfernt sie nicht, und ein neuer VPN-Server ist nicht die Reparatur, weil die Exposition oberhalb des Tunnels liegt.

Ein Zwischenablage-Manager, der in ein Cloud-Konto hochlädt, macht das deutlich. Der Verkehr ist verschlüsselt, das Ziel ist erlaubt, und der Kill-Switch meldet die ganze Zeit einen gesunden Zustand.

Schritt vier: Formulieren Sie die Aussage, die Ihr Test stützt

Nach dem Ausfalltest können Sie konkrete Fakten nennen: welche Anwendungen ausgefallen sind, welche Pfade gestoppt haben, ob DNS und IPv6 sich richtig verhalten haben und ob die Sperre hielt, als der Tunnel ausfiel. Sie können nicht sagen, dass das Betriebssystem sauber ist, und nicht, dass ein Dienst am fernen Ende Ihr Login privat hält.

Halten Sie die beiden Probleme getrennt und geben Sie jedem seine eigene Kontrolle:

  • Kill-Switch: die definierte Ausfallanforderung, verifiziert durch einen Ausfalltest, den Sie nach jedem Client-Upgrade wiederholen.
  • Gerätevertrauen: unterstützte Updates, Endpoint-Schutz aus vertrauenswürdiger Quelle, Prüfung unerklärter Berechtigungen und Authentifizierungsaufforderungen.
  • Vorfall: Folgen Sie dem Prozess der Plattform oder Organisation, wenn ein Kompromiss vermutet wird; ein frischer Server ist kein Aufräumschritt.
  • Offenlegung: Wenn Sie um Hilfe bitten, fügen Sie keine privaten Schlüssel oder ganze Diagnosearchive ein, weil Protokolle und Screenshots dieselben Geheimnisse tragen wie die Verbindung.

Führen Sie die Sequenz nach dem nächsten Update erneut aus, weil ein Kill-Switch Konfiguration ist, die sich mit Versionen bewegt. Der Test ist der einzige Beweis, dass das Verhalten, auf das Sie sich verlassen, noch das Verhalten ist, das Sie bekommen.

Ähnliche Artikel