Kill-Switch pro App gegen Gerätesperre: Was sich ändert

Ein Kill-Switch pro App klingt nach der vorsichtigen Wahl: Nur der Arbeits-Client verliert sein Netzwerk, wenn der Tunnel ausfällt, und alles andere läuft weiter. Dann bemerkt jemand, dass der private Browser trotzdem eine Seite geladen hat, dass der mitgelieferte Synchronisationshelfer weiter versuchte und dass ein zwischengespeicherter Name weiterhin zu einer Adresse aufgelöst wurde, die den Tunnel nie berührt hat. Das Etikett der Funktion und die Menge der Verbindungen, die sie tatsächlich schützt, sind zwei verschiedene Dinge. Bestimmen Sie zuerst die geschützte Menge, denn sie entscheidet, ob Durchsetzung pro App oder eine geräteweite Sperre die ehrliche Beschreibung ist.

Beginnen Sie mit der Menge, nicht mit dem Etikett

Eine Richtlinie pro App schützt ausgewählte Anwendungen. Eine Gerätesperre zielt auf eine breitere Netzgrenze, meist mit dokumentierten Ausnahmen für lokales Drucken, Verwaltungsverkehr oder Captive Portals. Keines der beiden Etiketten ist vollständig, bis Sie drei Fragen beantworten können: was mit ausgeschlossenen Apps passiert, was mit Helfern passiert, die diese Apps starten, und was mit Verbindungen passiert, die geöffnet werden, während der Schutz nicht verfügbar ist.

Schreiben Sie diese Antworten auf, bevor Sie eine Client-Einstellung anfassen. Wenn die Anforderung lautet "dieser Lohn-Client darf nie außerhalb des Tunnels mit dem Internet sprechen, mein Browser darf es", ist die Menge klein und die Durchsetzung pro App passt. Wenn die Anforderung lautet "nichts auf diesem Gerät erreicht das Internet ungeschützt, außer dem Update-Dienst", erzeugt keine Richtlinie pro App das, weil die Apps, die Sie nicht genannt haben, das Problem sind.

Durchsetzung pro App gleicht Kennungen ab, nicht Programmnamen

Android stellt VPN pro App über Pakete bereit, und seine VpnService-Dokumentation beschreibt, wie das mit dem Dauerbetrieb und der Blockierung zusammenspielt. iOS konfiguriert VPN pro App über ein Verwaltungsprofil und gleicht nach App oder nach Domain ab. Windows und Linux haben überhaupt keine Route pro Prozess, deshalb wird dieselbe Idee mit einer auf ein Programm beschränkten Firewall-Regel oder mit einer Regel angenähert, die auf den besitzenden Benutzer passt.

Die Grenze ist die Kennung, und Kennungen lassen sich leicht umgehen. Eine Anwendung, die eine URL an den Systembrowser übergibt oder ein Dokument in einem Betrachter öffnet, wechselt in einen Prozess, den Ihre Richtlinie nie genannt hat. Eine Option zum Beenden beim Abbruch ist auch kein Paketfilter: Sie beendet die konfigurierte App, während ein Kindprozess, ein Warteschlangen-Arbeiter oder ein Browser-Tab einen bestehenden Socket am Leben halten kann.

Die Sperre deckt ab, was eine Richtlinie pro App nicht sehen kann

Eine geräteweite Sperre nimmt die Wahl weg. Jedes ausgehende Paket, das nicht zum Tunnel gehört, wird verworfen, auch Verkehr von Prozessen, von denen Ihre App-Richtlinie nie wusste. Auf Android ist das Dauerbetrieb-VPN in Kombination mit der Einstellung zum Blockieren von Verbindungen, und die Durchsetzung erfolgt im System, nicht im Clientfenster. Auf dem Desktop ist es eine dauerhafte Firewall-Regel oder eine Standardroute zu einem nicht erreichbaren Gateway.

Der Preis ist, dass alles andere stoppt, sodass die Ausnahmen Teil des Entwurfs werden statt eines nachträglichen Einfalls. Lokale Drucker, Dienstfindung, Anmeldungen an Captive Portals, Verwaltungsagenten und Betriebssystem-Updates brauchen jeweils ein dokumentiertes Loch, weil jedes ein Weg ist, der offen bleibt, wenn der Tunnel ausgefallen ist. Die Sperre ist nur so stark wie der kürzeste Eintrag auf dieser Liste.

DNS, IPv6 und Hintergrundhelfer verbergen die Lecks

Dass eine geschützte App einen Namen nicht auflösen kann, belegt nicht, dass zwischengespeicherte Antworten oder direkter IP-Verkehr blockiert sind. Ist der Resolver außerhalb des Tunnels noch erreichbar, wird der Name aufgelöst und die Verbindung scheitert, was wie ein funktionierender Kill-Switch aussieht und keiner ist. Schlimmer noch: Ein zwischengespeicherter Eintrag kann auf eine Adresse zeigen, die der Tunnel nicht trägt, sodass die Verbindung direkt hinausgeht, während die App einen VPN-Fehler meldet.

IPv6 braucht auf jeder Plattform, die es betreibt, eine eigene Regel, weil eine Drop-Regel für v4 keine v6-Route abdeckt. Auf Mobilgeräten kann eine Einstellung für privates DNS die Auflösung in einen verschlüsselten Kanal verschieben, den die Geräterichtlinie nicht prüft. Und Hintergrundhelfer sind auf dem Desktop der übliche Übeltäter: Ein Updater- oder Sync-Tray-Prozess startet vor dem VPN-Client und hält seine eigene Verbindung, sodass er die geänderte Route nie sieht.

Testen Sie drei Apps und zwei Übergänge

Führen Sie jede Zeile zweimal aus, einmal mit einem Hostnamen und einmal mit einer literalen Adresse, und noch einmal über IPv6, wenn das Netzwerk es anbietet. Ein Bestehen bedeutet, dass die eingeschlossene App stoppte, die ausgeschlossene sich wie notiert verhielt und der Helfer nicht entwischte. Halten Sie das direkte Verhalten fest, das Sie als akzeptabel eingestuft haben, damit der nächste Administrator eine bewusste Ausnahme von einem Fehler unterscheiden kann.

Beschreiben Sie das Ergebnis dann in einem Satz, der die Apps und die Bedingungen nennt, zum Beispiel: Der Lohn-Client hat keine Route außerhalb des Tunnels, der Browser ist absichtlich direkt, und alles andere stoppt, wenn der Tunnel ausgefallen ist. Wenn dieser Satz schwer zu schreiben ist, sind die Richtlinien noch zwei Richtlinien, die gegeneinander kämpfen.