Un VPN non fiable, ce sont trois frontières distinctes, pas une

« Je ne fais pas confiance à ce VPN » est généralement trois affirmations habillées en une seule phrase. Les pairs distants de ce réseau pourraient atteindre des services sur votre hôte, l’opérateur qui exploite le tunnel pourrait observer le trafic qui le traverse, et le logiciel client que vous avez installé pourrait modifier la politique réseau de votre machine. La croyance à corriger est qu’une règle de pare-feu, une machine virtuelle ou un choix soigné de système d’exploitation répond aux trois. Chaque mesure répond exactement à l’une d’elles.

Le mythe : un seul contrôle couvre tout le risque

L’hypothèse courante est que rejoindre un réseau non fiable est une décision unique assortie d’une seule atténuation. Les gens choisissent le contrôle auquel ils font déjà confiance, l’appliquent et considèrent le risque réglé : le pare-feu est actif, l’espace de travail est jetable, le client vient d’un fournisseur réputé.

Ces contrôles ne se recouvrent pas comme l’hypothèse le suggère. Un pare-feu d’hôte limite ce qu’un pair distant peut atteindre, et il ne fait rien contre un opérateur qui termine votre TLS. Une machine virtuelle sépare un espace de travail des fichiers de votre hôte, et elle ne fait rien contre un composant client autorisé à reconfigurer la pile réseau sous les deux. Nommer la frontière que chaque contrôle crée réellement, c’est tout l’exercice.

Les séparer vous dit aussi quel risque vous avez choisi d’accepter. La plupart des décisions réelles atténuent une frontière et en tolèrent une autre, ce qui est acceptable tant que le registre des changements précise laquelle est laquelle.

Ce que le pair distant peut réellement atteindre

Commencez par les services en écoute. L’interface de tunnel traitée comme largement fiable parce que ses paquets sont arrivés chiffrés est l’erreur habituelle, et elle transforme chaque écoute locale en cible potentielle pour quiconque se trouve sur ce réseau. Le chiffrement protège le fil entre deux extrémités ; il ne dit rien de l’intention du pair à l’autre bout.

ss -tulpn
sudo nft list ruleset
ip -br addr

Liez les services à l’adresse dont ils ont besoin plutôt qu’à chaque interface, et n’autorisez que les opérations que la tâche approuvée exige. Gardez le transfert, le pontage et le proxy d’applications explicites, car deux connexions réseau ne créent pas un chemin de transit à elles seules, mais une règle de proxy le peut certainement.

Un espace de travail jetable approuvé réduit ce que le réseau distant peut atteindre, mais seulement lorsque sa configuration de partage correspond à l’affirmation. Les dossiers partagés, l’intégration du presse-papiers, les agents d’identifiants et les canaux de gestion traversent tous la frontière que l’espace de travail était censé créer. L’étiquette d’un espace de travail ne prouve rien sur ceux qui sont ouverts.

L’architecture de confiance zéro du NIST énonce le principe derrière tout cela : la localisation réseau seule n’accorde pas de confiance implicite. L’authentification des ressources a encore du travail après l’admission du tunnel, tout comme la question de savoir qui d’autre partage ce réseau.

Ce que l’opérateur sur le chemin peut voir

Un VPN déplace votre trafic vers un autre endroit du chemin ; il n’ajoute pas de chiffrement applicatif. Si le fournisseur termine votre TLS, il peut lire ce que votre navigateur aurait protégé autrement, et aucune règle de pare-feu locale n’y change rien.

Conservez la validation normale des certificats pour la destination réelle et comprenez le chemin du résolveur et des métadonnées, car une requête DNS peut révéler plus que la charge utile qui la précède. Les métadonnées seules, c’est-à-dire quelles adresses vous avez contactées et quand, répondent souvent à la question de l’opérateur sans aucun besoin de lire le contenu. C’est pourquoi « le trafic est chiffré » et « le trafic est privé » sont des affirmations différentes.

Si cette visibilité est inacceptable pour la tâche, la réponse est une autre architecture approuvée plutôt que davantage de filtrage local. Le filtrage local ne peut pas retirer un observateur d’un chemin sur lequel il se trouve encore.

Ce que le client local a le droit de changer

C’est la frontière que les gens manquent, et c’est celle qui rend les deux autres sans objet. Sous Linux, CAP_NET_ADMIN couvre la configuration des interfaces, l’administration du pare-feu et les changements de routes dans son contexte réseau. Un logiciel détenant cette capacité peut réécrire la politique que vous venez d’écrire.

getcap /usr/sbin/openvpn
systemd-analyze security vpn-client.service
ip netns list

Un espace de noms réseau est une frontière réelle pour l’état du réseau et une mauvaise pour tout le reste : il n’isole ni le système de fichiers ni le magasin d’identifiants. Traitez-le comme une couche et non comme un conteneur pour tout le problème.

Obtenez le client et sa configuration auprès d’une source maintenue, examinez l’autorité qu’il demande et gardez les composants privilégiés sous contrôle d’administrateur. Une machine virtuelle peut faire partie d’une frontière d’évaluation qualifiée sans devenir une permission d’exécuter un installateur inexpliqué à côté d’identifiants précieux. L’installateur s’exécute avec l’autorité que vous lui donnez, et cette autorité est la frontière.

Écrivez quelle frontière vous avez acceptée

Terminez par une phrase qui nomme quatre choses : le code local de confiance, l’accès distant autorisé, les données applicatives protégées et la relation avec l’opérateur qui demeure. Cette phrase vaut plus qu’une affirmation générale selon laquelle une VM, un système d’exploitation ou un antivirus ont rendu un réseau hostile sûr.

Confirmez ensuite que l’opération étroite fonctionne et que le refus requis tient toujours, y compris après la chute du tunnel. Une frontière qui n’existe que tant que le tunnel est monté n’est pas la frontière que vous avez documentée.

Aucun test ne prouve que toute vulnérabilité est absente, et une revue qui prétend le contraire exagère. Le résultat honnête nomme le risque résiduel et la personne qui l’a accepté.