Comment vérifier ce que couvre un coupe-circuit sur un hôte compromis

Activez le coupe-circuit, mettez le serveur du tunnel hors ligne et observez ce que la machine fait encore. Le test vaut la peine, car il sépare ce que le pare-feu applique de ce que vous supposiez, et les résultats sont plus étroits que ne le suggèrent la plupart des pages produit. Un coupe-circuit gouverne des chemins réseau ; il ne gouverne pas le logiciel déjà en cours d'exécution sur l'appareil. J'exécute cette séquence sur toute machine dont le client prétend être fail-closed, et elle prend une dizaine de minutes.

Partez du client, pas du serveur

Le point d'application est l'hôte sur lequel vous êtes assis : le pare-feu du système d'exploitation, un service auxiliaire ou le pilote du client VPN lui-même. Cela compte parce que tout ce que le commutateur peut faire est borné par ce que cette couche voit. Si le client implémente le blocage avec une règle de routage et une marque, tout ce qui dispose de privilèges suffisants peut ajouter sa propre règle ; s'il utilise une table de pare-feu du noyau, les mêmes privilèges peuvent modifier la table. La force du chiffrement n'entre jamais dans cette question.

La première chose à établir est donc qui possède la politique sur cet appareil et ce qu'elle est autorisée à contourner. Sur une machine de travail gérée, la réponse est généralement l'agent de point de terminaison de l'organisation, et un VPN personnel ne supprime pas ces capacités, quelle que soit la configuration du tunnel.

Première étape : confirmez le blocage sur les chemins que vous croyez couverts

Coupez le tunnel à l'extrémité distante plutôt que sur le client, afin que le client croie encore devoir être connecté. Essayez ensuite ce qu'une personne essaierait réellement :

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

Vous voulez un client qui échoue vite et proprement, pas un client qui reste suspendu jusqu'au délai du navigateur. Une suspension signifie généralement que des paquets sont abandonnés silencieusement par une règle sans rejet, ce qui est acceptable, mais elle peut aussi signifier que le client a laissé une route par défaut obsolète pointant vers une interface morte. Lisez la table de routage tunnel coupé : une route par défaut qui pointe encore vers l'interface du tunnel et une règle de pare-feu qui ne bloque que les nouvelles connexions sortantes sont deux états différents, et un seul des deux est fail-closed.

Répétez les mêmes commandes avec l'option autoriser le LAN du client activée puis désactivée. Ce commutateur est là où vivent la plupart des surprises, car il rouvre un chemin que le reste de la politique était censé fermer.

Deuxième étape : vérifiez DNS et IPv6 comme des chemins distincts

La résolution de noms est la faille qui survit à la plupart des implémentations, car la requête peut sortir par autre chose que le résolveur du système. Interrogez avec un outil qui ignore votre configuration de résolveur, et vérifiez le côté v6 au passage :

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

Des réponses vides aux deux requêtes de nom, tunnel coupé, sont le résultat souhaité. Si la seconde requête répond, une adresse de résolveur codée en dur est joignable et le tunnel n'est pas la seule sortie de la machine. Si seule la requête v6 réussit, la politique couvre IPv4 et ignore IPv6, ce qui est la même fuite dans une autre famille d'adresses.

Les navigateurs rendent cela plus difficile à lire de l'extérieur, car un navigateur configuré pour DNS over HTTPS résout la requête par une requête HTTPS : la requête n'est bloquée que dans la mesure où le port 443 vers ce point de terminaison l'est. Sur un hôte dont la politique autorise le sous-réseau local, cette requête peut encore atteindre un résolveur du LAN.

Troisième étape : séparez l'exposition réseau de l'exposition du point de terminaison

Voici maintenant la partie qu'aucune règle de pare-feu n'atteint. Un coupe-circuit bloque des chemins hors de la machine ; il n'empêche pas le logiciel de la machine de lire des données avant leur chiffrement, et il n'empêche pas ce logiciel d'utiliser légitimement le tunnel. Un enregistreur de frappe, une extension malveillante, un écran laissé déverrouillé, un client de synchronisation aux permissions larges : tout cela déplace des informations sur une connexion que le commutateur autorise volontiers.

Il en va de même pour un logiciel de surveillance installé exprès par un employeur. Bloquer des routes ne le supprime pas, et acheter un nouveau serveur VPN n'est pas la réparation, car l'exposition se situe en amont du tunnel.

Un gestionnaire de presse-papiers qui téléverse vers un compte cloud le montre nettement. Le trafic est chiffré, la destination est autorisée, et le coupe-circuit signale un état sain tout du long.

Quatrième étape : écrivez l'affirmation que votre test soutient

Après le test de coupure, vous pouvez énoncer des faits précis : quelles applications ont échoué, quels chemins se sont arrêtés, comment DNS et IPv6 se sont comportés et si le blocage a tenu quand le tunnel est tombé. Vous ne pouvez pas affirmer que le système d'exploitation est propre, ni qu'un service à l'extrémité distante gardera votre identifiant privé.

Gardez les deux problèmes séparés et donnez à chacun son propre contrôle :

• Coupe-circuit : l'exigence de défaillance définie, vérifiée par un test de coupure que vous répétez après chaque mise à jour du client.
• Confiance de l'appareil : mises à jour prises en charge, protection des points de terminaison issue d'une source fiable, examen des autorisations et des demandes d'authentification inexpliquées.
• Incident : suivez le processus de la plateforme ou de l'organisation en cas de compromission suspectée ; un serveur neuf n'est pas une étape de nettoyage.
• Divulgation : quand vous demandez de l'aide, ne collez pas de clés privées ni d'archives de diagnostic complètes, car les journaux et les captures portent les mêmes secrets que la connexion.

Relancez la séquence après la prochaine mise à jour, car un coupe-circuit est une configuration qui évolue avec les versions. Le test est la seule preuve que le comportement sur lequel vous comptez est encore celui que vous obtenez.