Votre pare-feu prend ses ordres chez des inconnus. Coupez les assistants de protocole.

Il y a sur votre pare-feu une fonction qui lit l’intérieur de vos paquets, y trouve une adresse IP et un numéro de port écrits en toutes lettres, et leur ouvre un trou entrant. Aucune règle. Aucune demande de changement. Aucune ligne de journal que vous iriez consulter un jour. Elle est active par défaut sur la plupart des équipements qui la possèdent, elle l’est depuis près de vingt-cinq ans, et le secteur qui l’a mise là a passé les vingt dernières à conclure discrètement qu’elle devrait être coupée — dans des documents de normalisation, dans les valeurs par défaut du noyau, et au fil de quatre vagues distinctes de correctifs d’urgence pour navigateurs.

Cela s’appelle un assistant de protocole, ou Application Level Gateway, ALG, session helper, fixup, moteur d’inspection, helper conntrack. La même chose. Cela existe parce que le NAT a cassé une poignée de protocoles qui écrivent des adresses dans leur propre charge utile, et parce que quelqu’un a décidé que le moins mauvais correctif était d’apprendre au traducteur à lire et réécrire cette charge utile au passage.

Voici la partie qui devrait vous arrêter.

L’assistant ne peut pas savoir qui a écrit le texte. Il lit des octets sur une connexion et agit dessus, immédiatement, sans rien demander à personne. Il n’a aucun moyen de savoir si la chaîne PORT 192,168,1,29,4,0 a été produite par un vrai client FTP effectuant un vrai transfert, ou par un formulaire caché sur une page web que votre utilisateur a ouverte par accident. Les deux sont identiques sur le fil, parce qu’elles sont identiques sur le fil. Un inconnu sur internet capable de convaincre n’importe quoi de votre réseau d’émettre les bons octets — un navigateur, un client de discussion, tout ce qui envoie ce qu’on lui dit — choisit donc quel port entrant votre pare-feu ouvre, et vers quoi.

Ce n’est pas un bogue dans l’analyseur d’un fournisseur. C’est ce que la fonction fait. Les rapports de bogues et les CVE sont le détail intéressant par-dessus ; la forme en dessous, c’est qu’un équipement de sécurité prend des instructions de configuration dans des données non fiables et les applique immédiatement.

Samy Kamkar a démontré la version navigateur en janvier 2010¹, une bien meilleure en octobre 2020², et trois mois plus tard Armis l’a étendue pour que le port ouvert n’ait même pas besoin d’être sur la machine qui a cliqué : il peut être sur votre imprimante, votre caméra, ou un automate programmable deux VLAN plus loin³. Entre-temps, l’IETF a écrit que ces choses devraient être désactivées par défaut⁴, Linux les a coupées dans le noyau⁵, et les éditeurs de navigateurs ont livré une liste de ports bloqués qui se lit presque ligne pour ligne comme un répertoire des modules conntrack de Linux⁶. Chacun de ces correctifs a été appliqué ailleurs, parce que ce qui avait réellement besoin d’être corrigé se trouve dans une boîte que personne n’ira corriger.

La conclusion à laquelle je suis arrivé, c’est que les assistants de protocole devraient être désactivés par défaut partout, et effectivement désactivés sur tout réseau dont vous êtes responsable. Pas réglés. Pas restreints à des sous-réseaux de confiance en première intention. Coupés, avec les deux ou trois exceptions réelles écrites et datées, exactement comme vous documenteriez n’importe quelle autre règle entrante — parce que c’est ce qu’elles sont.

Ce qui suit, c’est le mécanisme, puis les attaques dans l’ordre où elles ont été trouvées, puis la position de conformité, parce qu’au Royaume-Uni ce n’est pas seulement imprudent mais un échec net d’une exigence de certification que vous détenez peut-être déjà, et enfin les commandes pour y remédier.

Ce qu’un inconnu y gagne

Commençons par le résultat, car le mécanisme intéresse plus facilement quand on a vu la facture. Quelqu’un ouvre un lien. C’est là toute sa contribution. La page exécute du JavaScript qui parle au serveur de l’attaquant, et ce serveur façonne la conversation — en la rembourrant, en la mesurant, en acquittant certaines parties et pas d’autres — jusqu’à ce qu’un segment arrive sur votre pare-feu avec exactement l’allure du message d’ouverture d’un appel VoIP. Votre pare-feu y croit, parce qu’y croire est la fonction. Il crée une association entrante, et l’attaquant se reconnecte directement à travers.

Dans la version de 2020, le port s’ouvre sur la machine qui a cliqué, c’est-à-dire tout service à l’écoute sur cet hôte, joignable depuis internet tant que l’association vit². Le partage de fichiers. Le bureau à distance que personne ne voulait laisser à l’écoute. Sur le Fisher-Price OS (Windows), Armis a fait la remarque évidente : atteignez le port de partage de fichiers et vous êtes à un hôte non corrigé du chemin qu’a pris WannaCry³.

La version de 2021 est pire, et c’est la partie qui devrait trancher pour vous. Comme l’assistant H.323 gère le renvoi d’appel, un seul message peut nommer une troisième adresse plutôt qu’une des deux extrémités de la connexion ; l’attaquant n’est donc plus limité à la machine qui a cliqué et peut parcourir votre plage interne, ouvrir un port sur chaque adresse et lire ce qui répond. Armis a démontré exactement cela : le port 80 sur toute une plage, les bannières collectées, une cible choisie, puis le port d’impression brute de l’imprimante ouvert et un travail envoyé dessus. Leur seconde démonstration a atteint un automate sur son port d’administration non authentifié et a modifié son programme³.

Aucune vulnérabilité n’a été exploitée sur ces équipements. L’imprimante était une imprimante qui marchait, la caméra une caméra qui marchait, l’automate un automate qui marchait, et la seule chose qui a échoué, c’est la frontière — laquelle a échoué en faisant précisément ce pour quoi elle était configurée. Regardez aussi qui se trouve à l’intérieur de cette frontière. Pas seulement votre personnel : un visiteur sur le réseau invité, le portable d’un prestataire, n’importe qui avec un navigateur. L’attaque ne demande ni identifiants, ni point d’appui, ni logiciel malveillant, car le navigateur est le vecteur et il est déjà installé et déjà de confiance.

Mettez maintenant cela en regard de ce à quoi sert un pare-feu : garantir que rien de l’extérieur n’engage une conversation avec quoi que ce soit à l’intérieur sans que vous l’ayez dit. L’assistant est l’exception, et l’exception est accordée sur la foi d’une chaîne de caractères dans un paquet.

Ce qu’est réellement un assistant de protocole

Un NAT ordinaire est une chose bête et honnête. Un paquet arrive, il réécrit l’adresse et le port source dans l’en-tête, note une ligne pour que la réponse puisse être retournée, et transmet. Il ne regarde jamais sous l’en-tête de transport, et il ne sait ni ne se soucie de savoir si les octets à l’intérieur sont une requête web, une requête de base de données ou la photo d’un chien.

Cela marche jusqu’à ce qu’un protocole écrive une adresse dans sa propre charge utile. FTP le fait, en clair dans le flux de commandes : reconnectez-vous à moi à cette adresse, sur ce port. SIP le fait dans les champs Via, Contact et SDP, H.323 le fait, et IRC le fait pour les transferts directs. Tous ont été conçus quand l’adresse d’un hôte était l’adresse de cet hôte et que chaque machine pouvait joindre toutes les autres, et sous cette hypothèse c’est parfaitement raisonnable. Mettez un traducteur dans le chemin et l’adresse dans la charge utile devient un mensonge.

L’assistant fut donc inventé. Il lit la charge utile, trouve l’adresse, la réécrit en adresse publique, puis fait ce que tout le monde saute : il crée une règle autorisant la connexion entrante que la charge utile vient de décrire. Netfilter appelle cette règle une expectation. Cisco l’appelle pinhole, ou porte NAT⁷. Palo Alto l’appelle pinhole NAT dynamique⁸. Juniper l’appelle gate. Mot différent, objet identique : un trou percé dans la frontière, sur la foi de quelque chose lu dans un paquet.

L’IETF a nommé le motif avant que la plupart de ces produits n’existent. Un ALG, dit le RFC 2663, est un « application specific translation agent » qui « may interact with NAT to set up state, use NAT state information, modify application specific payload and perform whatever else is necessary to get the application running across disparate address realms »⁹. Relisez cela avec un adversaire en tête : whatever else is necessary, piloté par application specific payload. Et dès février 2002, la taxonomie des middleboxes de l’IETF appelait le mécanisme par son nom, notant que certains ALG créent des problèmes de fragmentation « although in this case the problem is arguably the result of a deliberate layer violation (e.g., mucking with the application data stream of an FTP control connection by twiddling TCP segments on the fly) »¹⁰.

Une violation de couche délibérée. Tripatouiller les segments TCP à la volée. C’est le mécanisme, décrit par ceux qui l’ont catalogué il y a vingt-quatre ans, et c’est le même mécanisme que traverse en droite ligne chaque attaque de ce billet.

L’expectation est tout le problème

Tout le reste de ce billet découle d’un seul objet, il vaut donc la peine de bien le comprendre.

Une expectation est une connexion pré-autorisée : un tuple adresse source, port source, adresse destination, port destination et protocole, certains champs remplis, d’autres laissés en joker, plus un minuteur. Quand un paquet correspondant arrive, le pare-feu le traite comme lié à un flux autorisé existant plutôt que comme une nouvelle connexion entrante, le laisse passer et consomme l’expectation. Sous Linux, vous les lisez directement dans /proc/net/nf_conntrack_expect, ou avec conntrack -L expect. Sur un système sain cette liste est vide, et c’est bien le but : les expectations sont censées être rares, éphémères et déclenchées par quelque chose qu’un hôte interne a réellement demandé.

Deux de ces réponses sont pires qu’on ne le croit. Les valeurs viennent de la charge utile et non du pare-feu, donc de l’extrémité de la conversation que l’assistant était en train de lire. Et sur l’assistant IRC, l’adresse source est un joker par conception, parce que le protocole ne peut pas savoir qui va se connecter : il « creates expectations whose destination address is the client address and source address is any address »¹¹.

Voici la phrase à emporter. Une expectation est une règle de pare-feu entrante, créée à la vitesse du fil, par une partie non fiable, sans aucune trace de qui l’a demandée ni pourquoi. Gardez-la jusqu’à la section Cyber Essentials, car c’est là tout l’argument.

Comme prévu : FTP dit PORT, et le pare-feu le croit

Prenez l’assistant le plus simple et regardez-le travailler correctement, car l’attaque est la même séquence avec un participant remplacé. Le FTP actif utilise deux connexions. Le client ouvre une connexion de contrôle vers le serveur sur le port 21 et lui donne des commandes en ASCII, et quand un transfert est voulu il ouvre une socket en écoute et envoie une commande PORT nommant l’adresse et le port de rappel, après quoi le serveur se connecte en entrant. C’est le protocole tel que spécifié, et il fonctionne ainsi depuis 1985. Sur le fil, ce sont six nombres, quatre pour l’adresse et deux pour le port, octet de poids fort d’abord :

PORT 192,168,1,29,4,0

C’est 192.168.1.29, port 1024, parce que 4 × 256 + 0 = 1024.

L’assistant surveille ce flux, repère PORT, réécrit l’adresse privée en adresse publique en ajustant les numéros de séquence puisque la chaîne a changé de longueur, et crée une expectation autorisant la connexion entrante du serveur sur le port nommé. Vraiment utile, tout à fait raisonnable compte tenu des contraintes de 1994, et correct à chaque étape.

Regardez bien ce qui a été vérifié avant l’ouverture du trou. Les octets étaient sur une connexion vers le port 21. Ils commençaient par PORT. C’est tout. Rien d’autre, parce qu’il n’y a rien d’autre à vérifier : FTP n’a aucune signature à offrir, aucune clé de session et aucune authentification, et l’assistant lit un flux auquel il n’est pas partie.

Une autre chose vit dans ce code, et c’est un avertissement que les auteurs se sont écrit à eux-mêmes. Si l’adresse de la commande PORT n’est pas celle du client — si le client demande au serveur de se connecter ailleurs — l’assistant Linux refuse par défaut, et le commentaire dans les sources dit pourquoi : « DMZ machines opening holes to internal networks, or the packet filter itself »¹². Mettez le paramètre de module loose et ce refus disparaît. Ceux qui ont écrit l’assistant savaient exactement à quoi on pouvait le faire servir. Ils ont livré la valeur par défaut sûre et un interrupteur, et vingt-cinq ans plus tard l’interrupteur est toujours là.

Pas comme prévu : les mêmes octets, depuis une page web

Un assistant lit un flux d’octets et compare un motif. Il ne vérifie pas, et par construction ne peut pas vérifier, que la chose à l’autre bout est le client qu’elle prétend être. Samy Kamkar a publié la conséquence en janvier 2010 et l’a appelée NAT Pinning¹. Le mécanisme est d’une petitesse gênante : posez un formulaire sur une page web, pointez-le vers le serveur de l’attaquant sur le port 6667, et arrangez le corps pour qu’il contienne une demande de discussion directe.

PRIVMSG samy :^ADCC CHAT samy 3325256705 22^A

Le navigateur l’envoie en croyant faire un POST HTTP. L’assistant IRC du routeur, qui surveille une connexion sur le port 6667, voit passer DCC CHAT avec une adresse et un port et fait ce pour quoi il est bâti. L’adresse est ici 198.51.100.1 écrite comme un seul nombre décimal, car c’est ainsi que le protocole l’encode, et le port est 22 ; rien dans cette chaîne n’a été choisi par la victime. La variante FTP est la même idée visant le port 21, avec une ligne de réponse en mode passif à la place¹.

Pas de cross-site scripting. Pas de falsification de requête au sens habituel. Aucune vulnérabilité dans le navigateur. Le navigateur a fait ce que font les navigateurs, le pare-feu a fait ce pour quoi il était configuré, et le résultat est une redirection de port vers l’attaquant.

C’était en 2010. Il y a seize ans. Les éditeurs de navigateurs ont ajouté les ports IRC à leur liste de blocage, ce qui a fermé cette porte-là et laissé la pièce qu’elle ouvrait exactement en l’état.

Disons la chose franchement, car elle se perd sous les noms de fournisseurs et les numéros de CVE. Les attaques n’exploitent aucun défaut des assistants. Elles utilisent les assistants correctement. Chaque paquet est bien formé et chaque vérification réussit honnêtement. La fonction fait son travail, et son travail est le problème.

Aligner les octets là où l’assistant va lire

Il y avait un vrai obstacle entre NAT Pinning et quelque chose de bien pire, et la manière de le contourner est ce qu’il y a de plus malin dans tout le sujet. La plupart des assistants ne cherchent pas un motif n’importe où dans un flux : ils vérifient que le mot-clé se trouve au début de la partie données d’un paquet, ce qui est le cas d’un vrai message de protocole et jamais celui d’un corps HTTP, puisqu’un corps arrive après une pile d’en-têtes que l’attaquant ne contrôle pas. Samy cite le comportement du noyau lui-même : le gestionnaire abandonne si la méthode n’est pas au début des données².

L’attaquant a donc besoin que le navigateur émette un segment dont le tout premier octet est le mot-clé. Il ne peut pas écrire les en-têtes, mais il peut écrire le corps et le faire aussi long qu’il veut, ce qui transforme le problème en arithmétique.

Le navigateur envoie une grande requête avec un délimiteur reconnaissable enfoui dans le corps ; le serveur de l’attaquant l’écoute, mesure combien d’octets d’en-têtes sont venus avant, et connaît dès lors le décalage. Il annonce ensuite une taille de segment qui place l’octet voulu sur une frontière, ou envoie un acquittement partiel pour que la victime retransmette exactement à partir de là — et Armis ajoute que la fenêtre TCP peut elle aussi être fabriquée dans ces acquittements, « in order to fully control how the TCP stream is to be segmented »³. C’est là toute l’astuce, et elle n’utilise rien d’autre que l’extrémité distante d’une connexion ouverte par le propre navigateur de la victime.

Une fois qu’on a cela, le navigateur est un générateur de paquets polyvalent pointé vers l’intérieur de votre pare-feu. Pas parfait, puisqu’il ne peut pas fixer d’en-têtes arbitraires ni choisir des protocoles arbitraires, mais il n’a jamais eu besoin de l’être. Il lui suffit de placer les trente bons octets au début d’un segment.

Le travail de 2021 a sauté l’essentiel de l’arithmétique. Une connexion de relais du navigateur en TCP transporte un champ nom d’utilisateur contrôlé par l’attaquant, envoyé tôt, acceptant sauts de ligne et octets nuls tant que le résultat est du texte valide — Armis a montré une capture où ce champ est la chaîne \r\nPORT 192,168,1,29,4,0\r\n, avec un acquittement partiel qui fait retransmettre la victime exactement à partir du PORT³. Pire, ce chemin ne consultait pas du tout la liste de ports bloqués du navigateur, si bien que la seule mesure que le secteur avait livrée deux fois était simplement contournée.

NAT Slipstreaming, de bout en bout

Assemblez les morceaux et voici l’attaque entière, dans l’ordre.

Temps total écoulé : quelques secondes. Interaction utilisateur totale : un clic. Vulnérabilités exploitées sur la machine de la victime : aucune.

Le calendrier de divulgation est une preuve à lui seul. Samy a publié le 31 octobre 2020, Armis l’a contacté trois jours plus tard, et la divulgation coordonnée auprès des éditeurs de navigateurs a commencé le 11 novembre. Chrome a livré une mesure le 6 janvier 2021, Edge le lendemain, Safari en bêta le 14 et en version stable le 1er février, Firefox le 26³ — suivis sous CVE-2020-16043, CVE-2021-23961 et CVE-2021-1799.

Quatre éditeurs de navigateurs ont livré des correctifs d’urgence pour une fonction de pare-feu. Armis explique pourquoi dans ses propres mots : « While the underlying issue of this attack is the way NATs are implemented (in various ways in routers and firewalls, throughout numerous vendors and applications), the easiest and fastest way to mitigate was through a patch to browsers »³.

Ce n’est pas un correctif. Ce sont quatre autres secteurs qui empilent des sacs de sable devant la porte de quelqu’un d’autre, parce que la porte elle-même n’allait jamais être remplacée.

Le renvoi d’appel H.323 vise n’importe quoi sur votre réseau

La plupart des assistants bornent les dégâts sans le vouloir. L’assistant FTP épingle la destination de l’expectation au client qui l’a créée, si bien que le pire qu’obtienne un attaquant est un port sur la machine qui a cliqué, ce qui est grave mais survivable.

H.323 est catastrophique, et la raison est une fonction de téléphonie.

Un système téléphonique doit gérer le renvoi d’appel, et un appel renvoyé est par définition un appel vers quelqu’un qui n’est pas en ligne. La signalisation doit donc nommer un troisième point d’extrémité, et l’assistant doit ouvrir un chemin vers lui, sinon le renvoi ne fonctionne pas du tout à travers un NAT. Toute implémentation sérieuse le fait, et l’assistant netfilter documente explicitement ce comportement, schéma à l’appui, sur le site netfilter¹³. Armis a lu le code et a énoncé la conséquence en une phrase : « a single H.323 packet sent over TCP port 1720 that initiates call forwarding can open a pinhole (named an expectation in the conntrack subsystem) to any TCP port of any internal IP on the network »³.

N’importe quel port TCP. N’importe quelle adresse interne. À partir d’un seul paquet, que l’attaquant a fait émettre par un navigateur.

L’attaque cesse donc de concerner la machine de la victime et devient un balayage de ports de votre réseau interne mené depuis internet, les résultats étant relus sur des connexions que votre propre pare-feu autorise. Les équipements qu’elle trouve sont l’essentiel, car ils ne sont pas corrigés, souvent pas corrigeables, et tout le modèle de sécurité de la plupart d’entre eux tient dans c’est à l’intérieur. Armis a mis un chiffre sur cette hypothèse : un an après publication, 97 % des automates industriels vulnérables à une série de failles critiques n’étaient toujours pas corrigés³. Personne ne soutient que ce chiffre soit bon. C’est la réalité que « c’est à l’intérieur » soutient.

H.323 est donc la première chose à traiter, sur toutes les plateformes, parce que c’est la seule qui porte au-delà de la victime — et c’est aussi celle que presque plus personne n’utilise, ce qui en fait l’amélioration de sécurité la moins coûteuse de ce billet. Coupez-la. Personne ne vous appellera.

L’assistant peut être déclenché par un message que vous n’avez pas envoyé

Une variante mérite sa propre section, parce qu’elle casse l’hypothèse à laquelle on se raccroche quand on cherche une raison de ne rien faire : d’accord, mais le déclencheur doit venir de l’intérieur, donc contrôlez les navigateurs et vous contrôlez le problème.

Non.

En juillet 2022, David Leadbeater a trouvé deux défauts dans l’assistant IRC de Linux¹⁴. Le module cherche la chaîne \1DCC n’importe où dans le flux au lieu de vérifier qu’elle est au bon endroit dans un message correctement encadré, et sa vérification d’adresse compare à l’adresse du serveur de discussion plutôt qu’à celle de l’hôte derrière le traducteur, si bien que l’adresse publiquement connue d’un serveur public suffit. Mettez cela ensemble et un attaquant envoie au client de la victime un ping de client à client — chose parfaitement ordinaire à recevoir de n’importe quel autre utilisateur — avec une demande de transfert direct dedans :

PRIVMSG ExampleUser :^APING ^ADCC CHAT x 3325256705 22^A

Selon les règles du protocole, le client répond à un ping en renvoyant la charge utile en écho, si bien que le client de la victime envoie consciencieusement cette chaîne vers l’extérieur, et l’assistant, qui surveille le flux sortant, y trouve DCC et ouvre le port.

Personne à l’intérieur n’a rien fait de mal et personne n’a cliqué. Le client a suivi la spécification, et la spécification et l’assistant ont produit ensemble un trou entrant vers le port 22 d’une machine du réseau. C’est devenu la CVE-2022-2663, et la description de la base nationale des vulnérabilités est admirablement claire : « A firewall may be able to be bypassed when users are using unencrypted IRC with nf_conntrack_irc configured »¹⁵.

Notez le mot unencrypted. Retenez-le aussi.

La recommandation de l’auteur est exactement là où le reste de ce billet arrive par un autre chemin : « Potentially entirely deprecate and remove nf_conntrack_irc, it’s unclear it has much use anymore »¹⁴.

Les analyseurs sont l’autre moitié

Jusqu’ici il s’agissait d’assistants fonctionnant correctement. Il y a un second problème, distinct : ce sont des analyseurs de protocole écrits en C, tournant dans le chemin rapide d’un équipement de sécurité, sur des données fournies par des inconnus, et ils ont le taux de bogues qu’on attend de cette description. Et ce n’est ni un problème Linux ni un problème de routeur bon marché : cela apparaît chez tous les fournisseurs, dans le code qu’ils facturent le plus cher.

Chacune est atteignable depuis le réseau sans aucune authentification, par quiconque peut faire parvenir un paquet à l’interface externe, c’est-à-dire tout le monde. Et lisez les formulations : specific SIP messages, specific H.323 packets, a specific SIP packet. Ce n’est pas un protocole qui cède sous la charge. C’est quelqu’un qui fabrique un paquet exprès.

Arrêtez-vous un instant sur le cas Cisco. La CVE-2018-15454 a été publiée le 31 octobre 2018 avec une gravité de 8,6, elle était exploitée dans la nature, et l’avis disait que la mise à jour logicielle n’était pas encore disponible¹⁶. La mesure de Cisco, dans son propre avis, est no inspect sip. La réponse du fournisseur à une faille activement exploitée dans la fonction a donc été de couper la fonction — ce qui pose la question sur laquelle repose le reste de ce billet. Si la couper est une réponse acceptable pendant un incident, sur quelle base est-elle active le reste du temps ?

Un assistant ne fonctionne que si vous ne chiffrez pas

C’est la partie qui devrait clore le débat à elle seule, et c’est celle qui retient le moins l’attention. Un assistant de protocole lit votre charge utile et ne peut pas en lire une chiffrée. Un assistant ne fait donc absolument rien sinon sur du trafic que vous avez choisi de laisser en clair, et garder l’assistant opérationnel signifie garder ce trafic en clair.

Tous les protocoles de la liste disposent d’un mode chiffré depuis bien plus de dix ans. FTP a TLS depuis 2005¹⁷ ; activez-le et les échanges PORT et PASV sont invisibles, l’assistant ne fait rien. SIP a TLS depuis la spécification de base, avec les médias chiffrés à côté. H.323 a sa propre annexe de sécurité. La discussion a TLS depuis très longtemps, et le conseil officiel pour la CVE-2022-2663 était, mot pour mot, de l’utiliser afin que l’assistant ne voie pas vos demandes de transfert¹⁵.

La formulation honnête de « il nous faut le SIP ALG » est donc : il nous faut que notre signalisation d’appel traverse des réseaux non fiables en clair, afin qu’une middlebox que nous ne contrôlons pas puisse la réécrire. Dites-le ainsi en revue de conception et regardez jusqu’où cela va.

Il y a une version plus tranchante, et c’est pourquoi l’affaire n’est pas serrée. Laisser un assistant actif est une incitation permanente contre le chiffrement : le jour où quelqu’un active SIP sur TLS, les appels cassent et l’assistant en est la cause, donc le changement est annulé et le clair reste une année de plus. Demandez à quiconque a essayé derrière un pare-feu grand public comment cela s’est passé.

Tous les autres protocoles d’internet sont allés dans l’autre sens : trafic web chiffré par défaut, DNS chiffré, transport de courrier chiffré, QUIC chiffrant jusqu’à l’en-tête de transport précisément pour que les middleboxes ne puissent ni le lire ni le modifier. L’ère de la middlebox s’est terminée sur l’internet ouvert il y a des années, et les derniers endroits qui comptent encore sur un équipement du chemin lisant la charge utile sont ceux où quelqu’un a laissé un assistant actif.

IPsec, le cas où l’assistant ne peut rien lire du tout

Ce qui pose la question évidente du protocole qui n’est que chiffrement. La réponse est pire que vous ne l’imagineriez.

ESP n’a pas de numéros de port, étant un protocole IP à part entière et non quelque chose transporté sur UDP, et un traducteur démultiplexe le trafic de retour par port. Avec deux clients derrière une même adresse publique visant la même passerelle, rien ne permet donc de distinguer leurs paquets entrants. RFC 3715 l’a consigné en mars 2004 : un NAT ne peut pas apprendre la correspondance par inspection, et « it is possible that the NAT will deliver the incoming IPsec packets to the wrong destination »¹⁸.

Les constructeurs ont donc bâti un assistant. Il observe l’échange IKE sur UDP 500, dont les premiers paquets sont en clair, récolte les cookies et l’index des paramètres de sécurité, et ouvre une porte pour que l’ESP entrant portant cette valeur atteigne le bon hôte à l’intérieur. Juniper le décrit le plus simplement : « When ESP traffic hits the IKE ALG gates, sessions are created to capture subsequent ESP traffic »¹⁹. L’inspect ipsec-pass-thru de Cisco fait de même pour ESP et AH « associated with an IKE UDP port 500 connection », avec une table par défaut qui ne fixe aucune limite au nombre de connexions ESP par client²⁰.

Même objet, même autorité, sauf qu’ici l’assistant ne fait même pas correspondre un mot-clé. Il ne peut pas analyser ESP, puisque ESP est justement la partie chiffrée ; il aiguille des paquets d’après un nombre de 32 bits qu’il a vu passer en clair. La section de RFC 3715 qui traite de cela s’intitule, sans ironie, « Helper Incompatibilities », et consigne que le démultiplexage par cookie « results in problems with re-keying » et que les équipements analysant les charges utiles ISAKMP « may not handle all payload ordering combinations »¹⁸. Une supposition tenant lieu de règle, et un analyseur fait maison dans le chemin des paquets, écrit noir sur blanc il y a vingt-deux ans.

Le correctif est arrivé dix mois plus tard, dans le protocole, là où il doit être : RFC 3947 fait détecter un traducteur aux deux extrémités pendant l’échange de clés, et RFC 3948 encapsule ESP dans de l’UDP sur le port 4500 pour qu’il y ait de nouveau des ports²¹. Juniper dit alors tout haut ce qu’il faut : « IKE NAT-T traffic on floating port 4500 is not processed in an IKE ALG »¹⁹. Faites-le correctement et l’assistant est entièrement contourné — la même phrase que pour le FTP passif et pour ICE.

Le noyau Linux amont n’a jamais pris celui-là. Il n’y a pas de module ESP parmi les protocoles de conntrack, et un correctif de 2021 ajoutant un suivi fondé sur le SPI est passé en revue sur la liste netfilter sans jamais être intégré²². Les constructeurs qui l’embarquent l’embarquent hors arbre, sur les équipements les moins susceptibles d’être mis à jour un jour.

Cela fait échouer Cyber Essentials, ligne par ligne

Jusqu’ici c’était un argument de sécurité. Pour quiconque se certifie au Royaume-Uni, c’est aussi un argument de conformité, et aucune interprétation habile n’est en jeu : ce sont trois puces contre trois puces. Cyber Essentials est le dispositif soutenu par le gouvernement britannique et délivré via IASME, sa première exigence technique porte sur les pare-feux, et le document d’exigences en vigueur est la version 3.3, avril 2026. Voici ce qu’il vous impose, mot pour mot²³ :

• block unauthenticated inbound connections by default
• ensure inbound firewall rules are approved and documented by an authorised person, and include the business need in the documentation
• remove or disable unnecessary firewall rules, when they are no longer needed

Placez maintenant un assistant de protocole en face de chacune.

Une expectation existe précisément pour autoriser une connexion entrante qui serait autrement bloquée, et la partie dont les données l’ont provoquée ne s’est authentifiée auprès de rien : la première puce échoue donc d’emblée. La règle a été écrite à la vitesse du fil par un module noyau, il n’y a donc aucun document, aucun besoin métier consigné et aucune personne autorisée nulle part dans la chaîne — demandez à un auditeur la trace d’approbation de la règle qui a laissé une connexion atteindre le port 9100 de votre imprimante et vous n’en avez pas et ne pouvez pas en produire, parce qu’elle a existé quatre-vingt-dix secondes il y a dix-huit mois. Et les règles d’un assistant sont retirées par un minuteur, qui n’est pas une revue.

Trois exigences, trois échecs, sur le premier contrôle des cinq, qui s’applique selon les mots du dispositif aux « boundary firewalls, desktop computers, laptops, routers, servers »²³, c’est-à-dire à tout ce que vous possédez.

Soyez juste sur ce que cela signifie, car je ne suis pas l’organisme de certification. Un évaluateur travaille à partir du questionnaire et des preuves que vous lui donnez, et ce questionnaire demande si vous bloquez par défaut les connexions entrantes non authentifiées et si vos règles entrantes sont documentées et approuvées. Répondez oui avec un assistant actif sur votre frontière et la réponse est fausse. Vous passerez sans doute quand même. Passer et se conformer ne sont pas la même chose, et l’écart se voit après un incident plutôt qu’avant.

Cyber Essentials n’est pas non plus inhabituel dans ce qu’il demande, seulement inhabituellement clair. Une norme du secteur des cartes, un dispositif d’assurance gouvernemental, le questionnaire d’un client et le formulaire de votre assureur posent tous la même chose dans une autre langue : savez-vous ce que votre pare-feu autorise en entrée, et quelqu’un l’a-t-il décidé ? C’est donc la section à porter à qui signe le certificat. Pas les attaques ni les CVE. Trois puces, et la réponse honnête à chacune.

Le secteur a tranché cela il y a vingt ans

Rien de tout cela n’est nouveau et rien n’est contesté. Ce qui est remarquable, c’est depuis combien de temps la décision est prise pendant que les valeurs par défaut continuaient imperturbablement.

Le RFC 3027 a catalogué en janvier 2001 tous les protocoles que le NAT casse²⁴. Le RFC 3234 a rangé les ALG dans la taxonomie des middleboxes un an plus tard, a qualifié le mécanisme de « a deliberate layer violation » et a été direct sur le coût d’ajouter des boîtes dans un chemin : cela « creates extra points of attack, reduces or eliminates the ability to perform end to end encryption, and complicates trust models »¹⁰. Puis, en janvier 2007, le RFC 4787 — une Best Current Practice et non une suggestion — a fixé comment un NAT doit se comporter, et l’exigence dix disait ceci :

REQ-10: To eliminate interference with UNSAF NAT traversal mechanisms and allow integrity protection of UDP communications, NAT ALGs for UDP-based protocols SHOULD be turned off.⁴

Coupés. Il y a dix-neuf ans, avec la raison donnée : les assistants gênent les mécanismes qui fonctionnent vraiment, et ils vous empêchent de protéger l’intégrité de votre propre trafic. La même section note, avec lassitude, que certains produits ont des ALG « turned on permanently »⁴.

Trois ans plus tard, NAT Pinning montrait une page web ouvrant un port¹. Netfilter a répondu en 2012 par un mécanisme pour le faire délibérément plutôt qu’automatiquement — la cible CT, qui rattache un assistant à un flux nommé par une règle explicite, et un interrupteur pour stopper complètement l’attribution automatique¹¹. Puis, le 25 avril 2016, le noyau a changé sa valeur par défaut, dans un message de commit qu’il vaut la peine de lire en entier tant il sonne las :

Four years ago we introduced a new sysctl knob to disable automatic helper assignment […] This knob kept this behaviour enabled by default to remain conservative. This measure was introduced to provide a secure way to configure iptables and connection tracking helpers through explicit rules. Give the time we have waited for this, let’s turn off this by default now, worse case users still have a chance to recover the former behaviour by explicitly enabling this back through sysctl.⁵

C’est arrivé avec Linux 4.7, et depuis, une machine dont ces modules sont chargés n’en fait rien tant que vous n’écrivez pas une règle en rattachant un à un flux, avec une ligne de journal qui vous le dit. Tout ce qui suit est dans le diagramme ci-dessus : Slipstreaming et sa variante visant tous les équipements, quatre éditeurs de navigateurs livrant des mesures pendant que la norme de la plateforme web elle-même gagnait la liste de ports²⁵, l’assistant IRC se déclenchant sur un message que personne n’a composé, et quatre autres failles d’ALG dans la gamme phare de pare-feux d’un fournisseur.

Regardez maintenant ce qui manque à la liste. En vingt-cinq ans, pas une seule ligne n’est un fabricant de pare-feu poussant une mise à jour de micrologiciel qui coupe ces fonctions sur du matériel déjà déployé. L’organisme de normalisation l’a demandé. Le noyau l’a fait en amont. Les chercheurs l’ont prouvé quatre fois séparément. Les navigateurs ont payé. Les boîtes ont continué.

Et la liste de ports bloqués est l’indice. Les ports 69, 137, 161, 554, 1719, 1720, 1723, 5060, 5061, 6566 et 10080 y figurent tous⁶ — TFTP, NetBIOS, SNMP, RTSP, H.323 deux fois, PPTP, SIP deux fois, le protocole de scanner et le protocole de sauvegarde Amanda. Listez les modules d’assistance dans un arbre de noyau Linux et vous constaterez que vous avez lu deux fois la même liste. Pas une coïncidence, et pas une mesure de sécurité. C’est un secteur qui entretient en permanence une liste de blocage de ports qui s’allonge, parce qu’un autre secteur refuse de changer une valeur par défaut.

Sous la plupart des badges, c’est du Linux

Le détail netfilter est la partie importante et non une digression en forme de Linux, et il vaut la peine de dire pourquoi avant la liste des fournisseurs. Une très grande part des boîtes qui font du NAT sur cette planète, c’est du Linux avec netfilter sous une interface de fournisseur : toute dérivée d’OpenWrt, c’est-à-dire l’essentiel du marché des routeurs grand public et petites entreprises, la plupart des box fournies par les opérateurs, une bonne partie des équipements de NAT d’opérateur, et quantité d’appliances commerciales dont l’interface web ne laisse rien deviner de ce qu’il y a dessous. L’assistant qui analyse votre SIP est, dans bien des cas, ce même nf_conntrack_sip.c livré dans le noyau principal, compilé par quelqu’un d’autre et piloté par un menu.

La preuve est dans la recherche elle-même. Quand Samy a cherché le SIP ALG dans un routeur Netgear, il a extrait le micrologiciel et trouvé un module noyau contenant ftp_decode et sip_decode². La liste testée par Armis comprenait OpenWrt et VyOS plus une catégorie qu’ils ont simplement appelée « various consumer grade Linux routers, with likely older kernel versions », et l’analyse H.323 qui a produit le résultat « n’importe quel hôte interne » a été faite en lisant les sources de netfilter, puis confirmée sur des pare-feux commerciaux de trois fournisseurs³.

Deux conséquences pratiques en découlent.

La valeur par défaut du noyau ne vous atteint pas. Linux 4.7 a coupé l’attribution automatique en 2016, mais seulement si le noyau est assez récent et que personne ne l’a rallumée. Armis a trouvé VyOS remettant explicitement nf_conntrack_helper à 1, et a noté que quantité de produits fondés sur Linux la réactivent « as it is still useful for many users »³. Un noyau de 2014 dans un produit de 2026 hérite du comportement de 2014, et un noyau récent avec l’interrupteur basculé donne la même chose. Ni l’un ni l’autre n’apparaît sur une fiche technique.

Connaître le modèle netfilter vous dit quoi demander à toutes les autres boîtes. Les trois questions de la section sur les expectations ne sont pas des questions Linux. Ce sont les questions. Chaque fournisseur a le même objet sous un autre nom, la documentation ne donne presque jamais les réponses, et savoir ce que fait l’implémentation de référence est la façon de déterminer quoi tester.

Faites le travail Linux correctement, puis lisez tous les autres fournisseurs à cette aune.

Les assistants Linux, correctement

Commencez par ce qui est réellement chargé :

lsmod | grep -E 'nf_conntrack|nf_nat'

Les modules d’assistance sont ceux nommés d’après des protocoles — nf_conntrack_ftp, _sip, _h323, _irc, _tftp, _pptp, _snmp, _amanda, _sane, _netbios_ns et _talk — chacun avec un nf_nat_* correspondant là où des adresses sont réécrites. Vérifiez ensuite si l’attribution automatique est active, car c’est l’interrupteur qui décide si un module chargé fait quelque chose de lui-même :

sysctl net.netfilter.nf_conntrack_helper

Zéro est ce que vous voulez, et zéro est la valeur par défaut depuis Linux 4.7⁵. Un signifie que chaque assistant chargé est actif sur tout flux correspondant à son port, depuis n’importe quelle adresse, c’est-à-dire le comportement de 2015 et celui que supposent les attaques de ce billet.

Surveillez ensuite conntrack -L expect sur un pare-feu en service. Assistants désactivés, cela reste vide ; activés, mettez une capture à côté et regardez les lignes apparaître à mesure que les gens utilisent le réseau. Cet exercice vaut d’être fait une fois dans sa vie, car rien ne fait passer le message plus vite que de voir une autorisation entrante que vous n’avez pas écrite apparaître et disparaître sous vos yeux.

Si l’attribution automatique est coupée et que vous voulez malgré tout un assistant précis sur un flux précis, la voie sanctionnée est une règle explicite, qui le borne au moins à une destination et un port :

iptables -t raw -A PREROUTING -p tcp --dport 21 -d 192.0.2.10 -j CT --helper ftp

L’équivalent nftables déclare un objet ct helper et le rattache avec ct helper set dans la chaîne prerouting, la même discipline avec une meilleure syntaxe.

Regardez ce qu’est cette règle : une exception entrante documentée, approuvée, justifiée par un besoin métier, écrite par une personne, dans le jeu de règles, là où un auditeur peut la lire. C’est-à-dire la chose que la version automatique n’a jamais pu être.

Si vous les voulez parties plutôt que simplement endormies, et sur un pare-feu c’est ce qu’il faut, empêchez carrément le chargement des modules :

for m in ftp sip h323 irc tftp pptp snmp amanda sane netbios_ns talk; do
  echo "install nf_conntrack_$m /bin/false"
done > /etc/modprobe.d/no-conntrack-helpers.conf

install ... /bin/false plutôt que blacklist est délibéré : blacklist n’empêche que le chargement automatique par alias, et qui demande le module par son nom l’obtient quand même. Et si la couche pare-feu de votre distribution les charge pour vous — firewalld le fait quand une zone active le service FTP ou TFTP — c’est cette couche qu’il faut corriger, car elle les remettra obligeamment.

Tous les autres badges, et comment les couper

Vérifiez votre propre version plutôt que de croire quoi que ce soit écrit sur internet, le mien compris, car ces valeurs par défaut bougent entre les versions et entre les modèles d’une même gamme.

pfSense et OPNsense sont la preuve que le débat est clos. Il n’y a pas de SIP ALG à désactiver, parce qu’il n’y en a jamais eu à activer. Ce sont parmi les distributions de pare-feu les plus déployées qui soient, elles font tourner la téléphonie de très nombreuses organisations, et si un assistant était réellement nécessaire pour que la VoIP moderne fonctionne, ce ne serait pas possible. Cela l’est manifestement. Le proxy FTP a suivi le même chemin : Netgate l’a sorti du système de base en janvier 2015 et rétrogradé en paquet additionnel que la plupart des gens n’ont jamais installé.

La conception d’OpenBSD est celle que tous les autres auraient dû copier. pf ne réécrit aucune charge utile dans le chemin de transmission. Si vous voulez que FTP soit aidé, vous lancez ftp-proxy, un démon distinct en espace utilisateur, et vous écrivez une règle divert-to explicite qui y envoie la connexion de contrôle ; le proxy se connecte alors au serveur pour le compte du client²⁶. Trois propriétés en découlent aussitôt : il est coupé tant que vous ne l’activez pas délibérément, il ne voit que le trafic que vous avez nommé dans une règle, et un bogue dedans fait planter un processus utilisateur plutôt que le chemin des paquets. Voilà à quoi ressemble l’opt-in quand quelqu’un le conçoit au lieu de le rajouter après coup.

OpenWrt ne livre pas les modules ALG, et l’attribution automatique reste coupée même si vous les installez.

Cisco ASA et FTD portent des moteurs d’inspection dans la politique globale par défaut, et no inspect sip est le conseil de Cisco lui-même en cas d’incident :

policy-map global_policy
 class inspection_default
  no inspect sip
  no inspect h323 h225
  no inspect h323 ras
  no inspect skinny

Sur FTD, c’est configure inspection sip disable depuis la CLI de l’équipement¹⁶. Le passage IPsec est la chose que Cisco a bien faite : inspect ipsec-pass-thru ne figure pas du tout dans la politique par défaut, donc à moins que quelqu’un ne l’ait ajouté délibérément, il n’y a rien à retirer²⁰.

Cisco IOS et IOS XE l’ont aussi actif par défaut — « NAT support for SIP is enabled by default on port 5060 », dans les mots de Cisco⁷, et de même pour H.323 :

no ip nat service sip tcp port 5060
no ip nat service sip udp port 5060
no ip nat service h225

Juniper SRX active SIP et H.323 sur les modèles Branch et pas sur le haut de gamme, ce qui à soi seul vous dit ce qu’en pensent les ingénieurs de Juniper. Voyez où vous en êtes avec show security alg status, puis :

set security alg h323 disable
set security alg sip disable
set security alg ftp disable
set security alg ike-esp-nat disable

FortiGate inspecte la VoIP par défaut via le profil VoIP, avec un session helper noyau en dessous. La séquence documentée par Fortinet retire d’abord l’assistant²⁷ :

config system session-helper
 show
 delete <l'entrée SIP>
end
config system settings
 set default-voip-alg-mode kernel-helper-based
end

Lisez le numéro d’entrée dans votre propre sortie show plutôt que d’en recopier un, car il change selon les modèles et les versions. Fortinet prévient qu’un redémarrage est souvent nécessaire.

Check Point est le cas gênant à auditer, parce qu’il n’y a pas d’interrupteur unique. L’assistant est une propriété de l’objet service utilisé dans la règle, donc le service SIP prédéfini vous apporte le gestionnaire de protocole et tout ce qu’il fait. L’éviter suppose de définir votre propre service UDP ou TCP simple sur le port 5060 avec le type de protocole à « none », d’activer la correspondance, et de placer cette règle avant tout ce qui utilise encore les services intégrés. « L’ALG est-il actif ? » n’est donc pas une question à laquelle une page de réglages peut répondre. À ce titre, méfiez-vous avant d’accepter la parole de quelqu’un affirmant qu’il est désactivé.

Palo Alto vous donne un interrupteur par application, et sa propre documentation dit que le SIP ALG « creates dynamic NAT pinholes »⁸. Objects, Applications, cherchez sip, personnalisez l’option ALG, cochez Disable ALG, validez.

MikroTik livre dix assistants sous /ip firewall service-port — SIP, H.323, FTP, IRC, TFTP, PPTP, RTSP et d’autres — documentés en une ligne chacun, sans le moindre avertissement de sécurité sur la page. Listez d’abord, puis coupez ce que vous trouvez :

/ip firewall service-port print
/ip firewall service-port set [find name=sip] disabled=yes
/ip firewall service-port set [find name=h323] disabled=yes
/ip firewall service-port set [find name=ftp] disabled=yes

Box grand public et box opérateur. Cherchez « SIP ALG », « SIP helper », « VoIP passthrough » ou « application layer gateway », en général sous une page de NAT avancé. Sur beaucoup, surtout celles des opérateurs, il n’y a aucun réglage — ce qui vous dit si cette boîte a sa place sur un réseau dont vous êtes responsable.

Quelle que soit la plateforme, terminez de la même façon : prouvez-le. Mettez une capture sur l’interface externe, envoyez depuis l’extérieur une ligne PORT ou REGISTER fabriquée sur le port concerné, et vérifiez que rien ne s’ouvre. Un réglage que vous n’avez pas testé est une croyance.

L’essentiel de ce qui casse est déjà mort

Être honnête sur le coût est toute la base pour demander cela à quelqu’un, alors le voici. Couper l’assistant SIP sur un réseau aux téléphones mal configurés peut casser des appels, en général de l’audio unidirectionnel ou des enregistrements qui tombent. Couper l’assistant FTP casse le FTP actif sortant. Couper l’assistant H.323 casse H.323, s’il vous en reste. C’est réel, et vous devez vous attendre à au moins un de ces effets si vous faites cela en un seul changement sur un réseau que personne n’a regardé depuis des années.

Relisez maintenant la liste et remarquez que presque chaque protocole servi par un assistant est un protocole que le reste du secteur a déjà enterré. H.323 a perdu contre SIP il y a vingt ans. PPTP est indéfendable depuis 1998, et j’ai développé ce point dans IPsec était une bonne idée. Les transferts directs IRC appartiennent à une décennie que personne ne regrette. Le service de noms NetBIOS, les versions à community string de SNMP, le protocole de découverte de scanners et l’ancien protocole de sauvegarde sont des reliques de réseau local qui n’ont jamais eu à franchir une frontière. Le FTP simple a totalement disparu des navigateurs — Firefox l’a désactivé en version 88 et retiré en 90 en juillet 2021, et Chrome en a supprimé le code en version 95 en octobre, tous deux au motif que l’usage était négligeable et la sécurité ne valait pas l’entretien²⁸.

Donc « on ne peut pas couper l’assistant, quelque chose va casser » est le plus souvent un argument pour maintenir un protocole mort sous assistance afin de justifier une fonction qui ouvre des ports à des inconnus. Le couper ne casse pas votre réseau. Cela met au jour la seule chose dessus qui aurait dû être retirée il y a des années, information que vous vouliez de toute façon.

SIP est la vraie exception et c’est la seule. Tout le reste de cette liste est un argument que vous devriez être content de perdre — et rien n’y est insoluble, car chaque protocole concerné a résolu lui-même son problème de traduction il y a des années, dans le protocole, là où c’est sa place.

Quoi faire à la place

FTP. Le mode passif, dans la spécification depuis 1985 et le comportement par défaut de tous les clients depuis vingt ans : les deux connexions partent vers l’extérieur et il ne reste rien à faire pour un assistant. Et si vous déplacez des fichiers entre organisations en 2026, FTP n’est pas le protocole pour cela — SFTP et FTPS sont chiffrés, et un assistant n’atteint ni l’un ni l’autre.

SIP et tout le temps réel. Le point d’extrémité demande à un serveur sur internet à quoi ressemblent son adresse et son port publics vus de l’extérieur, propose tous les chemins dont il dispose, et les deux extrémités testent les chemins l’un contre l’autre et gardent celui qui marche, avec un relais là où aucun chemin direct n’existe. C’est STUN, TURN et ICE, et c’est ce que fait chaque navigateur du monde à chaque appel vidéo, à travers tous les types de traducteurs, sans un seul ALG dans le chemin. Si votre téléphonie ne sait pas le faire en 2026, le problème est votre téléphonie.

IPsec. La traversée de NAT, c’est-à-dire RFC 3947 et RFC 3948 : les deux extrémités repèrent le traducteur pendant l’échange de clés et encapsulent ESP dans UDP 4500 pour le reste de la session²¹, sans porte sur aucun boîtier intermédiaire.

H.323. Retirez-le. SIP a gagné ce débat vers 2005, il n’y a donc pas de migration à planifier, seulement une suppression. Les transferts directs, TFTP, SNMP, NetBIOS, la découverte de scanners et le protocole de sauvegarde suivent le même chemin : aucun n’a à traverser une frontière.

IPv6. Rien de tout cela n’y existe, car il n’y a pas de traduction et donc rien qu’un assistant puisse réécrire. Un hôte a sa propre adresse, l’adresse dans la charge utile est vraie, et un pare-feu à états autorise ce que vous lui avez dit et rien d’autre. Tous les problèmes de ce billet descendent de la traduction d’adresses, et la traduction d’adresses descend du non-déploiement d’IPv6 — argument que j’ai développé ailleurs et que je ne répéterai pas.

Maintenant la partie où je ne serai pas diplomate.

Si quelqu’un vous dit d’activer ces choses — un fournisseur, un installateur de téléphonie, un service managé, un intégrateur sous accord-cadre — ce n’est ni un ingénieur réseau ni un spécialiste de la sécurité. Il est peut-être très bon dans ce qu’il fait réellement, et ce ne sera pas cela. La bonne réponse à une téléphonie qui a besoin qu’un pare-feu réécrive sa signalisation est de réparer la téléphonie, et celui qui vous dit plutôt d’ouvrir votre frontière à un analyseur de chaînes vous dit qu’il ignore ce qu’est une expectation ou qu’il s’en moque. Ici, on n’est pas chez les amateurs. La bonne manière de faire est écrite dans des documents standards track depuis 2007, et « activez donc l’assistant SIP » est le bruit de quelqu’un qui attrape ce qui ferme le ticket aujourd’hui.

Demandez-lui, dans la pièce, à quoi est réglé le joker d’adresse source de l’expectation. Si la question le surprend, vous avez votre réponse, et il n’a jamais été question du protocole.

Si vous les faites encore tourner, pouvez-vous vous dire professionnel ?

C’est une vraie question et elle mérite une vraie réponse, alors en voici trois, car il y a trois cas. Tout tient à savoir ou non — et le savoir n’est pas quelque chose qui vous arrive. Faire en sorte de savoir, c’est le travail.

S’il y a un assistant SIP, H.323 ou FTP actif sur une frontière dont vous êtes responsable, et que vous ne pouvez pas dire sans chercher ce qu’est une expectation, lesquels de ses champs sont des jokers, qui fournit les valeurs, et ce que votre dossier de certification affirme sur les règles entrantes — alors non. Pas là-dessus. Vous n’avez pas choisi une configuration, vous avez hérité d’une valeur par défaut sans jamais aller la lire. Le manquement n’est pas la lacune ; tout le monde en a, et j’ai eu celle-ci. C’est de bâtir une frontière par-dessus une lacune que vous n’êtes jamais allé combler, puis de signer un papier disant que la frontière tient.

Si vous savez exactement ce que cela fait, et que c’est actif parce qu’un régulateur nomme le protocole, parce que l’équipement d’un partenaire ne termine rien d’autre, ou parce que la téléphonie est remplacée en mars et que cela doit tenir jusque-là — alors oui, évidemment, et vous faites le travail correctement. Ce sont de vraies contraintes et j’ai contourné pire. Ce qui rend la chose professionnelle plutôt que négligente, c’est que vous avez écrit quel assistant, sur quelle interface, pour quel flux, pourquoi, et à quelle date il saute. C’est-à-dire exactement la paperasse que demandait déjà l’exigence pare-feu.

Le cas indéfendable est celui du milieu. En savoir assez pour être mal à l’aise, et le laisser tourner parce que personne ne vous a jamais obligé à le justifier. Ce n’est pas de l’ingénierie. C’est de l’habitude avec un numéro de changement accroché, et c’est ainsi qu’une fonction qu’une Best Current Practice vous a dit de couper en janvier 2007 est encore active en 2026.

Cela compte surtout quand vous payez quelqu’un pour son jugement, car le jugement ne s’inspecte pas à la livraison. Inspectez-le donc avant de signer. Demandez ce que fait leur configuration standard des assistants de protocole et pourquoi, demandez ce qui se passe si quelqu’un sur le réseau invité ouvre un lien, et demandez quels équipements internes seraient joignables avec l’assistant H.323 actif — puis regardez s’ils répondent « seulement la machine qui a cliqué », car c’est faux, et c’est la mauvaise réponse que donne quelqu’un qui a l’air compétent. Vous saurez en deux minutes si on vous dit quelque chose ou si on vous fait la lecture, et deux minutes sont un test bien moins cher qu’un incident.

Si la réponse est un haussement d’épaules et que vous signez quand même, c’est aussi une décision. Elle a simplement cessé d’être la leur pour devenir la vôtre.

Personne n’a jamais eu à le justifier

Je veux être juste envers ceux qui ont construit ces choses, car ils le méritent.

En 1994, l’assistant était une réponse raisonnable à un vrai problème. Les adresses se raréfiaient, le NAT était le correctif pragmatique, une poignée de protocoles importants n’y survivaient pas, et le choix était de modifier tous les clients FTP de la terre ou d’apprendre à lire à la boîte. Ils ont appris à lire à la boîte, ont livré les valeurs par défaut les plus sûres qu’ils imaginaient, et ont écrit dans les sources des avertissements sur ce à quoi on pouvait la faire servir. Ces avertissements sont toujours là. J’en ai cité un.

Ce qui a mal tourné ensuite n’est pas un échec technique. C’est que rien dans ce secteur n’a jamais obligé qui que ce soit à y revenir. L’IETF a dit de les couper et n’avait aucun pouvoir d’y contraindre. Le noyau a changé sa valeur par défaut et ne pouvait pas atteindre les équipements déjà livrés. Les chercheurs l’ont prouvé quatre fois en seize ans, et à chaque fois le correctif a atterri ailleurs que dans le pare-feu.

Pendant ce temps, la valeur par défaut est restée active. Non parce que quelqu’un la défendait. Parce qu’une valeur par défaut dont personne ne discute survit indéfiniment, et qu’il n’existe nulle part un service dont le métier serait de mettre fin aux choses.

C’est le motif, et il dépasse une fonction de pare-feu. Ce métier est excellent pour entretenir et désespérant pour arrêter. La maintenance est budgétée, dotée, facturable et sûre, tandis que le retrait demande à une personne de mettre son nom sur un changement sans bénéfice s’il se passe bien et couvert de son nom s’il se passe mal. Alors la chose reste, et reste, et un jour quelqu’un découvre qu’elle ouvre des ports vers votre imprimante.

L’indice, pour moi, c’est cette formule dans la documentation de Cisco : l’ALG crée une porte NAT. Pas un filtre. Pas un contrôle. Une porte, dans le mur que vous avez payé, ouverte par quiconque y fait parvenir un paquet avec les bons mots en tête — et la réponse installée du secteur a été de prier les passants de bien vouloir ne pas essayer la poignée.

Vous pouvez fermer la vôtre cet après-midi, et c’est là-dessus qu’il vaut la peine de finir. Pas sur les attaques ; les attaques ne sont que ce qui arrive quand personne ne le fait. Allez voir ce que votre frontière autorise en entrée sans que vous l’ayez jamais écrit, décidez si vous le vouliez, et retirez ce que vous ne vouliez pas — en mettant une date à côté de ce que vous gardez.

Une frontière n’a jamais été autre chose : une liste de choses que quelqu’un a choisi d’autoriser et savait justifier. Ce qui y figure sans que personne l’ait choisi n’est pas de la sécurité. C’est du mobilier.