Deux vagues de déni de service sur la France maritime en 2026
Depuis le début de l’année, plus d’une trentaine de cibles françaises du secteur maritime ont été revendiquées par NoName057(16), un groupe hacktiviste prorusse (j’avais décrit son action contre un port roumain) qui mène des attaques par déni de service distribué (DDoS, Distributed Denial of Service) avec l’outil DDoSia. Quatre datent de mai et de juin, une quinzaine en juillet et autant en octobre.
Je ne nomme pas les organisations pour une raison simple : une revendication est une intention d’attaque, pas un constat de panne… et citer, à part faire du name and shame systématique, c’est une manière de faire de certains, assez rarement la mienne.
La vague de juillet
Du 21 au 25 juillet, les cibles concernées étaient des armateurs et des opérateurs de transport, des logisticiens, des ports. Les cibles se concentraient sur l’arc méditerranéen, avec un point en Corse et deux autres dans la vallée du Rhône.
La vague d’octobre
Elle est plus large. Près de vingt cibles en dix jours, essentiellement sur les journées des 13 et 14 octobre. Ports et autorités portuaires, un chantier naval, un prestataire de services offshore, un armateur et un organisme de recherche océanographique, un industriel de défense, notamment. Le 5 octobre, c’est une administration qui figurait sur la liste, et le 9 trois entreprises de la défense et du secteur aérospatial. Les cibles d’octobre débordent sur la Bretagne, la façade atlantique, le Nord et la région parisienne.
Mais pour quels impacts réels ?
Les impacts pour les sites visés dépend vraiment, sans suprise, de la préparation (ou non) de leur hébergeur,, des moyens de protection anti-DDoS et autres en amont, et de la technologie de site/Content Management System/appli web utilisée.
On trouve donc, logiquement, des impacts très variés : le site Internet d’un port injoignable pendant plus de 17 heures, un autre port qui répond presque tout le temps, avec quelques perturbations (réponses lentes, erreur serveur, délai dépassé) et, enfin, le site d’un port de la façade atlantique qui a toujours répondu, avec des pointes de lenteur comparables. Faute de mesure d’avant la vague, ces pointes peuvent faire partie du fonctionnement habituel de ces sites.
Cette distinction entre cibles désignées et interruptions de service, je l’ai déjà posée dans un article sur le FUD maritime.
Les requêtes envoyées par DDoSia
Pour chaque cible, la liste distribuée aux participants décrit la requête à répéter : méthode, protocole, chemin. On y voit requêtes HTTP/2, deux du HTTP/3, des tentatives de SYN flood pour épuiser la table de connexions du serveur ou du pare-feu avant toute requête web.
Vingt cibles reçoivent des requêtes de recherche, avec une valeur aléatoire à la place du terme (/search?q=$_1, où $_1 change à chaque envoi). Une valeur nouvelle à chaque requête contourne le cache du site ou du réseau de diffusion de contenu (Content Delivery Network, CDN) : chaque appel atteint le serveur d’origine, qui interroge sa base ou son moteur d’indexation. La recherche interne est une des pages les plus coûteuses d’un site, et elle est souvent ouverte à tous sans limitation de débit.
Douze cibles reçoivent des requêtes POST. Sept visent une page de connexion ou de réinitialisation de mot de passe, cinq un formulaire de contact. Une requête POST n’est jamais mise en cache, et un formulaire déclenche du travail côté serveur : vérification d’identifiants, envoi de courriel, écriture en base. Trois cibles reçoivent des pages de pagination (/page/$_1/), qui produisent le même effet qu’une recherche, et une autre un fichier du répertoire des médias, qui consomme de la bande passante plutôt que du calcul.
Bref, des moyens connus, pas trop surprenants, contre lesquels il est parfois possible de se prémunir.
En parallèle de la hausse globale
Le déni de service est en recul dans mon jeu de données en 2026 (742 incidents contre 851 pour l’ensemble de 2025), tandis que le reste progresse. La France fait exception : ses cibles maritimes revendiquées passent de 4 au premier semestre à 31 depuis juillet.
Anticiper et mutualiser
La prévention est possible : limitation de débit sur la recherche et les formulaires, services de filtrage en amont pour le reste, hébergeurs dimensionnés, centralisés et sécurisés pour absorbe ce genre de charge (certains pays européens le font pour leurs infrastructures vitales).
Les entités essentielles et importantes au sens de NIS 2 n’ont pas toutes les moyens d’un tel dispositif en propre. Un hébergement centralisé, mutualisé et protégé contre le déni de service, par exemple à l’échelle d’une communauté portuaire ou d’une région, serait une piste à étudier pour leurs sites vitrines.
