Résumé

  • RFC 862 ordonnait à Echo de renvoyer les données reçues ; RFC 864 faisait répondre Chargen par zéro à 512 caractères, sans tenir compte du contenu de la requête.
  • Une source falsifiée pouvait faire adresser la réponse de Chargen à Echo. Le retour d'Echo devenait alors la requête suivante de Chargen, sans nouvelle émission de l'initiateur.
  • BCP 38 documenta précisément cette composition et plaça les premiers contrôles dans la fermeture des services de diagnostic et la validation des préfixes source ; les pratiques ultérieures ajoutèrent validation du pair, débit maximal et disjonction.

La conversation survécut à celui qui l'avait ouverte

Le premier datagramme ne devait pas être volumineux. Il devait seulement mentir sur son origine. Envoyé à Character Generator avec l'adresse et le port d'un service Echo pour source apparente, il demandait implicitement à Chargen de répondre à Echo. Chargen fabriquait des caractères et les expédiait vers ce faux retour.

Echo accomplissait alors son travail normal : renvoyer le contenu à l'origine indiquée. Cette origine était Chargen. En recevant le texte retourné, Chargen ne savait pas qu'il s'agissait de sa propre réponse passée par un autre service. Il traitait le datagramme comme une nouvelle requête et répondait encore.

L'initiateur pouvait disparaître. La boucle n'était alimentée ni par une longue commande, ni par une diffusion vers tout un sous-réseau. Deux destinations unicast suffisaient. Le risque central n'était pas un multiplicateur universel de taille, mais la persistance d'un travail dont chaque résultat recréait la condition de départ.

Deux instruments volontairement sans jugement

RFC 862, publié en 1983, présentait Echo comme un outil de mesure et de mise au point. Sur UDP, le service du port 7 plaçait les données reçues dans un datagramme de réponse. Il ne cherchait pas à savoir ce qu'elles signifiaient.

RFC 864 attribuait une fonction comparable à Character Generator. Sa variante TCP produisait continuellement une suite de caractères, freinée par le contrôle de flux de TCP. Sa variante UDP, au port 19, ignorait l'entrée, tirait une longueur entre zéro et 512 caractères et envoyait une seule réponse. Elle ne conservait aucune histoire entre deux requêtes.

Cette absence de contexte simplifiait le banc d'essai. Nul compte, nul dialogue préparatoire : on pouvait éprouver un chemin ou un terminal avec très peu de code. Mais les services ne détenaient pas l'information causale qui aurait permis de reconnaître une réponse revenue sous le costume d'une demande.

RFC 768 donnait le cadre minimal. Le datagramme UDP indiquait notamment ports source et destination ; le premier pouvait servir de destination à la réponse. Le transport n'établissait auparavant ni session durable ni identité authentifiée du pair.

Un plafond local ne ferme pas un système

RFC 864 expliquait que Chargen ne risquait pas d'émettre plus vite que les demandes, puisqu'il ne répondait qu'une fois à chaque datagramme. Dans le périmètre d'une seule invocation, l'assertion reste exacte. Le service ne crée pas spontanément une deuxième sortie.

Elle cesse pourtant d'être une propriété de sûreté dès que la sortie entre dans une autre fonction. Si celle-ci renvoie son résultat vers la première, la réponse unique devient un segment de cercle. Le nombre de sorties par composant demeure borné ; le nombre d'activations du couple ne l'est plus.

La distinction explique pourquoi deux journaux conformes peuvent raconter un incident. Sur chaque machine, une requête précède une réponse. Il faut relier les chronologies pour constater que la réponse A cause la requête B et que la réponse B cause la prochaine requête A. L'observation du système ajoute une preuve qu'aucun composant ne possède seul.

BCP 38 désigna les deux extrémités

RFC 2827, devenu BCP 38, prit précisément le couple Chargen–Echo comme exemple de falsification de source UDP. Le texte décrivait la connexion d'un générateur de caractères sur un site à un service Echo sur un autre, puis le trafic entretenu entre eux.

Sa première réponse opérationnelle était l'exposition : ces ports de diagnostic ne devraient pas être joignables depuis l'extérieur du réseau administratif. Supprimer le chemin empêche un tiers de recruter le service, sans modifier sa grammaire.

La seconde réponse se trouvait près de la source. Lorsqu'un fournisseur reçoit du trafic d'un client, il peut refuser les adresses source étrangères aux préfixes que ce client annonce légitimement. Le réseau cesse ainsi d'exporter une revendication d'identité manifestement incompatible avec son point d'entrée.

Le mot « ingress » se lit donc du point de vue du fournisseur : le paquet entre depuis le client avant de partir vers l'Internet. La frontière responsable est celle qui dispose de l'information locale permettant de comparer origine déclarée et préfixes autorisés.

Un préfixe plausible n'est pas une personne reconnue

RFC 2827 en expose aussi la limite. Une machine compromise peut prendre l'adresse d'une autre machine du même préfixe autorisé et franchir le filtre. Un émetteur utilisant sa véritable adresse peut toujours inonder une destination. Le contrôle réduit l'espace du mensonge ; il n'authentifie pas l'hôte.

Le routage multihomé empêche en outre de réduire la politique à une commande unique. RFC 3704 présente vérification stricte, chemin faisable, vérification lâche et listes d'accès. La méthode stricte exige que la meilleure route de retour corresponde à l'interface d'arrivée, condition qu'un trajet asymétrique légitime peut violer.

La méthode lâche protège surtout contre les sources absentes de la table. Le chemin faisable admet davantage de routes légitimes mais réclame l'information correspondante. Les listes explicites demandent une maintenance fidèle aux changements de préfixe. Le choix doit être éprouvé sur la topologie réelle et son niveau de preuve ne doit pas être surinterprété.

L'application UDP doit savoir retirer son autorisation

RFC 8085 formule les devoirs des applications plus récentes. Connecter localement une socket UDP peut filtrer les datagrammes livrés, mais ne prévient pas le pair et ne crée aucune association authentifiée. Si une origine déterminée est exigée, l'application ou le système doit la vérifier explicitement.

UDP n'apporte pas de contrôle de flux. Le texte recommande de ne pas transformer une courte requête en réponse disproportionnée, de ne pas prendre l'adresse IP pour une preuve d'identité et de restreindre ou authentifier les opérations coûteuses. Une limite de débit ou un disjoncteur introduit la mémoire minimale qui manque à la boucle : même si ce paquet est valide, existe-t-il encore une raison de continuer ?

Les contrôles ne sont pas interchangeables. Fermer l'accès public ne garantit pas les machines internes. Valider le préfixe ne distingue pas deux hôtes autorisés. Limiter le débit réduit les dommages sans corriger le mensonge. Pour un diagnostic qui n'a pas de public légitime, la décision la plus nette reste souvent de ne pas l'exposer.

Deux numéros stables, aucune permission implicite

Le registre IANA des noms de service et ports de transport conserve echo sur le port 7 et chargen sur le port 19, en TCP comme en UDP. Il explique comment des programmes indépendants partageaient un rendez-vous.

Il n'atteste ni présence actuelle, ni accessibilité, ni conformité, ni autorisation. Un port dans une capture est un indice. Pour établir une boucle, il faut aussi la direction, le contenu, les écarts de temps, la propriété des extrémités et l'enchaînement entre réponse et demande suivante.

La sûreté réside dans les raccordements

Echo et Chargen proposaient des actions lisibles, non des commandes secrètes. Le danger naquit lorsque l'identité source falsifiée relia leurs autorités de réponse. Chaque service connaissait sa règle, aucun ne voyait le circuit entier et aucun ne détenait seul le fait qui justifiait l'arrêt.

Une limite locale ne devient donc une limite de système qu'après examen de la composition. Où la sortie peut-elle revenir comme entrée ? Quelle preuve décide de la destination de réponse ? Quelle frontière peut retirer le droit de répondre ? Quel observateur reconstitue la causalité dispersée ?

La réponse historique resta distribuée : l'opérateur maîtrise la portée, le réseau d'accès contrôle les revendications source, l'application gouverne le pair et le coût, l'observabilité relie les événements. La sécurité n'apparaît que lorsque chacun refuse de transformer une information locale en preuve universelle.

Sources et limites de preuve

Ces sources établissent les mécanismes, l'exemple historique et les familles de contrôle. Elles ne mesurent ni le nombre actuel de services exposés, ni la fréquence des attaques, ni une amplification moyenne, ni le déploiement mondial de BCP 38. L'article ne leur attribue aucune de ces mesures.