Pourquoi bloquer les ports VPN n’arrête pas les tunnels non autorisés

Une règle de pare-feu refuse le trafic qu’elle cible. Elle ne refuse pas tous les usages d’une connexion qu’elle autorise, et c’est dans cet écart que la plupart des politiques contre les tunnels non autorisés échouent. Bloquer les ports du client qui était populaire il y a cinq ans laisse intact tout ce qui passe par le 443, et ne dit rien d’un appareil capable de réécrire ses propres routes. Construisez le contrôle autour de l’autorité et des destinations, puis lisez les flux que vous autorisez réellement.

Pourquoi une liste de ports n’est pas une politique

Les ports sont un concept de la couche transport, et plusieurs technologies de tunnel n’en utilisent aucun. D’autres partagent délibérément un port avec le trafic web ordinaire, parce que ce port est celui dont le passage est garanti. Une règle fondée sur un port historique énumère donc une poignée d’implémentations plutôt que la classe de comportement. Elle vieillit mal aussi: dès qu’un fournisseur change ses valeurs par défaut, la liste décrit le passé.

Pire encore, un blocage réussi sur un port peut être lu comme la preuve que tout le problème est résolu, ce qui retarde ensuite les contrôles qui auraient compté.

Les numéros de protocole et les ports sont des espaces de noms différents

GRE se voit attribuer le numéro de protocole IP 47. Ce n’est pas le port TCP 47 ni le port UDP 47, et un filtre écrit pour un port ne le touche pas. ESP et AH occupent les numéros de protocole 50 et 51 avec la même propriété. Le trafic encapsulé peut aussi se cacher dans une connexion autorisée, c’est pourquoi une catégorie ou une signature peut aider, mais ne certifie jamais l’objectif à elle seule. La confiance et la couverture appartiennent à un produit et à une version précis, pas au concept.

nft list ruleset | grep -nE 'gre|esp|ah|47|50|51'
cat /proc/net/protocols | head -20
ss -tn state established '( dport = :443 )'

La première commande montre ce que vous avez réellement écrit; la deuxième montre la table de protocoles que connaît la pile; la troisième montre combien de sessions utilisent le port web en ce moment. Aucune d’elles ne dit à quoi servent ces sessions. L’interception TLS est une décision distincte, avec ses propres coûts de confiance, de vie privée et de compatibilité client. Elle n’est pas un prérequis pour refuser une destination nommée, et elle n’est pas non plus une garantie de reconnaissance des tunnels.

Contrôlez l’autorité dont dispose l’appareil

Un appareil qui peut modifier sa propre table de routage et son filtrage possède des capacités qu’une application ordinaire n’a pas. La gestion des admissions et de la configuration est ce qui retire cette capacité, et elle agit quel que soit le port que le tunnel utiliserait.

Cela signifie que les rattachements approuvés reçoivent leur rôle déclaré plutôt qu’une autorisation illimitée de transmettre pour d’autres appareils, et que les droits d’installation et d’administration réseau font partie de la politique au lieu d’être une réflexion après coup.

Observez les flux qui restent. Corrélez l’identité de l’appareil, le rôle attribué et les métadonnées du flux, et traitez la classification comme une preuve avec des limites plutôt que comme un verdict.

conntrack -L | awk '{print $1, $4, $5}' | sort | uniq -c | sort -rn | head
ip -br addr show
ip route show default

Une session chiffrée de longue durée ou un volume d’octets important ne prouve pas un usage abusif: les sauvegardes, les outils de support et les liaisons de site se ressemblent. Gardez la collecte limitée à l’enquête et conservez ce que vous trouvez sous le processus qui en est propriétaire.

Rendez les exceptions explicites

Chaque environnement a des destinations qui doivent rester joignables pour les mises à jour, l’authentification et la récupération. Notez-les avec un objectif et un responsable, et révisez-les au lieu de les découvrir une panne à la fois.

Lorsque l’entreprise autorise réellement un large service externe, évaluez l’autorité que ce service fournit plutôt que de supposer que l’étiquette de destination rend tout usage acceptable.

Une exception non révisée est un trou avec un numéro de ticket. Une exception avec un nom, une raison et une date de révision est une décision.

Acceptez avec un plan écrit, pas avec un slogan

L’acceptation a deux moitiés: le travail approuvé réussit toujours, et les cas interdits précis échouent lors d’un test autorisé. Les deux doivent être écrits avant le changement et répétés après.

Incluez les changements de point de terminaison et de politique dans cette révision, car une route ajoutée sur un ordinateur portable peut annuler un filtre qui fonctionnait parfaitement en périphérie.

Le livrable est une frontière de sortie maîtrisée avec une liste connue de risques restants. Affirmer que quelques ports fermés ont mis fin à un usage VPN non autorisé n’est pas cela.