Résumé

  • Le programme d’APNIC 62 annonce « 1.27M Attacks in 204 Days », son résumé parle d’« attack events » et les diapositives comptent exactement 1 272 286 « Total Events ».
  • La mesure vient d’un seul capteur, sur une seule adresse IP publique, avec SSH et Telnet volontairement ouverts. Elle ne constitue pas un recensement régional des attaques.
  • Le tableau des signatures affiche 198 973 réussites de connexion SSH, tandis que l’entonnoir dénombre 4 530 adresses IP sources à cette étape.
  • Pour rendre le résultat reproductible, chaque chiffre devrait porter son périmètre, sa fenêtre, son unité, sa règle de sévérité et sa clé de déduplication.

Un chiffre, trois substantifs

La fiche de la session dit que le déploiement de l’Université de Dhaka a vu 1,27 million d’attaques en 204 jours. Le résumé fourni au programme parle, plus précisément, de 1,27 million d’événements d’attaque. La première diapositive retire encore un cran d’interprétation et indique seulement « 1.27M Events ». Le tableau de bord donne le total exact : 1 272 286.

La différence n’est pas stylistique. Un événement est une ligne produite par un capteur ou une règle de détection. Un événement d’attaque est déjà une qualification. Une attaque évoque généralement une action ou un incident délimité. Ces notions peuvent décrire la même chaîne technique, mais elles ne comptent pas la même chose.

Le dispositif, lui, est bien borné : une machine virtuelle Ubuntu, un cœur de processeur, 2 Go de mémoire, 20 Go de conservation des journaux et une adresse IP publique dédiée. Seuls les ports 22 et 23, respectivement SSH et Telnet, sont mentionnés comme ouverts. Le trafic entrant a été laissé accessible à dessein.

Cette étroitesse ne diminue pas l’intérêt du honeynet. Elle en précise la valeur : observer ce que font les automates et les sessions interactives lorsqu’un leurre propose deux services connus. Elle interdit simplement d’extrapoler ce point d’observation à l’ensemble du Bangladesh ou de la région APNIC.

La double mesure des connexions réussies

Une diapositive offre l’audit le plus parlant. À droite, la ventilation des signatures compte 198 973 événements « SSH login successful ». À gauche, l’entonnoir intitulé « Unique IPs » ne conserve que 4 530 connexions réussies. On comprend qu’un côté additionne des événements répétés et que l’autre déduplique des adresses sources. Mais le schéma public ne permet pas de refaire exactement le calcul.

L’écart représente environ 44 événements de connexion réussie par adresse source arrivée à ce stade. Le premier nombre décrit la pression et la répétition sur le capteur. Le second décrit la cardinalité d’identifiants réseau selon une fenêtre et une règle de déduplication. Aucun des deux ne compte directement des personnes, des organisations ou des campagnes.

Une adresse IP peut correspondre à une machine compromise, un relais, une plateforme partagée, un accès derrière NAT ou une infrastructure automatisée. Elle peut changer d’utilisateur. Un opérateur peut mobiliser de nombreuses adresses ; plusieurs opérateurs peuvent apparaître derrière la même. Transformer 36 598 adresses sources en 36 598 « attaquants uniques » ajoute une identité que les données ne prouvent pas.

Les autres tuiles exigent la même sobriété. Les 78 411 mots de passe uniques sont des chaînes essayées contre un leurre, pas autant de comptes. Les 7 107 noms d’utilisateur ne sont pas des identités vérifiées. Téléchargements de logiciels malveillants, commandes, URL de commande et contrôle et systèmes autonomes sont chacun un objet de mesure distinct.

Une réussite prévue par le leurre

Le mot « réussi » a lui aussi besoin d’un complément. Un honeypot est configuré pour attirer, accepter et contenir des comportements qu’un service de production cherche à refuser. Une connexion acceptée par le leurre prouve que la session a franchi les règles du capteur. Elle ne prouve pas qu’un serveur de production de l’université a été compromis.

Les actions qui suivent restent sérieuses. Le document rapporte des commandes exécutées, des fichiers téléchargés et des comportements de persistance. Pour la défense, leur valeur vient de la séquence conservée — connexion, tentative d’authentification, session acceptée, commande, charge utile — et non de leur conversion en nombre d’intrusions réelles.

La répartition par protocole se réconcilie nettement : 1 016 974 événements SSH plus 255 312 événements Telnet donnent bien 1 272 286. Les huit lignes du tableau des signatures totalisent en revanche 1 272 287, soit une unité de plus. Les diapositives n’indiquent pas si des classes se chevauchent, si une cellule comporte une erreur de copie ou si un filtre diffère. Il faut s’arrêter à ce constat, sans inventer la cause.

Joindre un reçu de mesure au résultat

Le correctif éditorial tient dans une petite fiche. Pour chaque nombre : capteurs et services concernés, dates exactes, type d’événement, règle de sévérité, clé de déduplication, unité et limites d’identification. Un entonnoir doit aussi définir le passage d’une étape à l’autre. Une ventilation doit dire si ses catégories sont exclusives et montrer son rapprochement avec le total.

Ce reçu de mesure est une proposition de Theo March, pas une règle annoncée par APNIC ou l’Université de Dhaka. Il ne demande pas de publier les charges utiles sensibles. Il permettrait de distinguer volume et portée, adresse et acteur, connexion au leurre et compromission réelle.

Ce que les sources établissent — et ce qu’elles ne permettent pas de conclure

Le programme et la présentation d’APNIC établissent l’intitulé, l’architecture du capteur et les chiffres affichés. Les pages du projet expliquent que des honeypots recueillent du trafic suspect, des logiciels malveillants et des motifs d’attaque. Elles n’établissent ni nombre de personnes, ni nombre d’incidents, ni attribution nationale, ni prévalence régionale, ni compromission d’un système de production. Elles ne résolvent pas non plus l’écart d’une unité dans le tableau des signatures.

Sources