Quand la rotation des identifiants cesse-t-elle d’être optionnelle ?

Quelques scénarios reviennent assez souvent pour que je garde un plan de rotation prêt à l’avance. Je préfère ne pas en improviser un sous pression.

Un plugin ou un CMS sur un site hébergé se fait compromettre. J’ai raconté un cas réel sur ce type de serveur dans PHP2Shell : comment j’ai protégé mes serveurs en attendant le correctif, une vulnérabilité PHP qui permettait à un attaquant de déposer un web shell avant qu’un correctif n’existe. Une fois qu’un web shell tourne sous un utilisateur d’hébergement, il peut souvent lire le config.inc.php propre à ce site. Sur un serveur ISPConfig partagé, ce fichier se trouve juste à côté des identifiants de la base de données du panneau de contrôle lui-même. Pas seulement celui que l’attaquant visait au départ.

Un fichier de configuration se retrouve là où il ne devrait pas être. Une archive de sauvegarde oubliée dans un dossier public. Un dépôt poussé avec un fichier égaré dedans. Un journal plus lisible que prévu. config.inc.php et mysql_clientdb.conf n’ont rien à faire dans aucun de ces endroits. Les erreurs arrivent malgré tout, y compris les miennes.

Un administrateur système quitte l’équipe. Quel que soit le ton du départ, les identifiants de base de données partagés qu’il détenait ne m’inspirent plus une confiance totale. La confiance ne se transmet pas automatiquement quand quelqu’un passe la porte.

Une intrusion suspectée, même non confirmée. C’est le cas le plus difficile à expliquer à qui n’a jamais géré un serveur sous suspicion d’attaque. On n’attend pas la preuve avant d’agir. On présume la compromission et on lance la rotation. Une rotation inutile coûte un après-midi. Une rotation sautée, après une faille réelle, peut coûter tous les sites hébergés par le serveur.

Pourquoi la rotation manuelle des identifiants est si sujette aux erreurs

La première fois que j’ai fait la rotation des identifiants d’ISPConfig à la main, j’ai sous-estimé le nombre de fichiers concernés. Ils doivent tous changer ensemble, sinon quelque chose casse discrètement quelques heures plus tard.

Il y a config.inc.php côté serveur, et une seconde copie côté interface. Les deux doivent recevoir les mêmes nouvelles valeurs. Il y a mysql_clientdb.conf, que ISPConfig lit pour gérer la base de données de chaque site hébergé, pas seulement son propre ménage interne. Dovecot, Pure-FTPd et Postfix conservent chacun leur propre copie de certains de ces identifiants. Le mail et le FTP peuvent cesser de s’authentifier silencieusement si vous mettez à jour l’utilisateur de la base de données et oubliez un seul de ces trois services.

Il y a ensuite la topologie Master/Slave de certaines de mes installations. Un nœud Slave s’authentifie auprès de la base de données de son Master via le réseau, avec un mot de passe distinct. Ce mot de passe doit être tourné sur le Master lui-même, pas seulement en local. Si l’ordre est mauvais, un Slave peut se retrouver verrouillé hors du Master même qu’il est censé répliquer.

Rien de tout cela n’est conceptuellement difficile. C’est juste beaucoup de fichiers. Plusieurs services à redémarrer, dans un ordre sensé. Presque aucune tolérance pour une faute de frappe, surtout sous pression, juste après avoir trouvé quelque chose que vous ne vouliez pas trouver. Cette combinaison explique pourquoi la rotation des identifiants paraissait toujours plus risquée à la main que la tâche elle-même ne devrait l’être. C’est pour cette raison que j’ai écrit reset_DB_password.sh, après avoir vécu ce problème moi-même plus d’une fois.

Ce que reset_DB_password.sh fait réellement

reset_DB_password.sh détecte si le nœud est Standalone, Master ou Slave. Il exécute ensuite uniquement les phases que ce rôle exige.

La phase A tourne le mot de passe root local de MySQL. C’est le mot de passe qu’ISPConfig utilise lui-même pour gérer la base de données de chaque site hébergé. Le script met à jour mysql_clientdb.conf avec la nouvelle valeur.

La phase B tourne le mot de passe de l’utilisateur de contrôle ispconfig. Elle met à jour config.inc.php côté serveur et côté interface. Puis elle met à jour les identifiants correspondants dans Dovecot, Pure-FTPd et Postfix, pour que le mail et le FTP continuent de s’authentifier sans passer manuellement par trois fichiers de configuration supplémentaires.

La phase C ne tourne que sur un Slave. Elle se connecte à distance à la base de données du Master. Elle tourne là le mot de passe de l’utilisateur Slave, puis met à jour dbmaster_password en local, pour que la réplication continue de s’authentifier correctement avec la nouvelle valeur.

Après la phase B, le script propose de redémarrer Dovecot, Pure-FTPd et Postfix pour vous. Je dis presque toujours oui. Une rotation d’identifiants qui laisse un service mail tourner avec l’ancien mot de passe n’est pas terminée, elle est juste silencieusement cassée. Redémarrer dans la même exécution, juste après le changement des fichiers de configuration, garde tout cela dans une seule courte fenêtre de maintenance au lieu de trois fenêtres séparées découvertes plus tard.

Des sauvegardes avant tout changement

Avant de toucher le moindre fichier, le script fait une copie rsync complète de /usr/local/ispconfig/ dans un dossier horodaté. Il tente aussi un mysqldump non bloquant des bases mysql et dbispconfig. Non bloquant volontairement : je préfère terminer une rotation d’identifiants plutôt qu’attendre un dump bloqué pour une raison qui n’a rien à voir. Chaque fichier de configuration qu’il modifie reçoit sa propre copie .bak avant qu’une seule chaîne à l’intérieur ne soit remplacée.

Rien de tout cela ne remplace une stratégie de sauvegarde indépendante. Je prends toujours un snapshot séparé, ou une sauvegarde complète, avant de lancer ceci sur un serveur qui compte vraiment. Le propre avertissement du script dit la même chose, de façon plus directe que je ne viens de le faire.

Toujours un dry run d’abord

Chaque phase demande une confirmation avant de toucher à quoi que ce soit. –dry-run simule une exécution complète sans toucher un seul fichier. J’utilise dry-run en premier sur chaque serveur, chaque fois. Même sur ceux dont j’ai déjà tourné les identifiants, et que je crois bien connaître. –skip-local-root saute la phase A, pour quand seul le mot de passe de l’utilisateur de contrôle doit changer. –role=master ou –role=slave remplace la détection automatique, pour le cas rare où elle ne lit pas correctement la topologie d’un serveur.

Les mots de passe qu’il génère comptent 32 caractères, lettres et chiffres uniquement. Assez longs pour résister à une tentative de deviner. Assez simples pour que les parseurs de MySQL et de PHP ne trébuchent jamais sur un symbole égaré dans une chaîne de connexion. J’ai testé le script sur ISPConfig 3.3.1p1. Je ne l’ai pas lancé sur des branches plus anciennes ou plus récentes. Je ne présumerais pas un comportement identique là-bas, sans vérifier moi-même d’abord.

Le rôle d’un nœud n’est pas toujours évident au premier coup d’œil, surtout sur un serveur dont vous avez hérité plutôt que celui que vous avez construit vous-même. C’est pour cela que –role existe, et pourquoi la sortie du dry-run vaut la peine d’être lue ligne par ligne la première fois, pas survolée. Je préfère passer deux minutes à confirmer qu’un Slave est vraiment un Slave plutôt que de le découvrir à la dure en plein milieu de la rotation.

Ce que je vous dirais avant de l’exécuter

Avertissement : le script est fourni tel quel, à titre informatif. Son utilisation se fait entièrement à vos risques : je n’assume aucune responsabilité pour une perte de données, une interruption de service, ou toute erreur causée par un usage incorrect ou par un contexte différent de celui dans lequel je l’utilise moi-même. Gardez toujours une sauvegarde indépendante ou un snapshot de VM avant de l’exécuter en production, quoi que la propre étape de sauvegarde du script capture déjà pour vous.

C’est un logiciel libre. Vous pouvez le redistribuer et le modifier, avec attribution à moi comme auteur original. Le code source de reset_DB_password.sh, et le reste de la collection ispconfig-fast-tools, est sur GitHub à l’adresse github.com/matteocisilino/ispconfig-fast-tools.

La rotation des identifiants de base de données est une habitude, pas une tâche de nettoyage

La rotation des identifiants de base de données après une faille confirmée, c’est simplement une réponse aux incidents compétente. La plupart des administrateurs le feraient sans qu’on ait à le leur répéter. L’habitude la plus difficile, c’est de le faire après une faille simplement suspectée, avant d’avoir la moindre preuve. C’est la seule version du plan qui limite vraiment les dégâts, tant qu’ils sont encore limitables. Un script qui exécute les bonnes phases selon le rôle d’un serveur, prend ses propres sauvegardes d’abord, et me laisse faire un dry-run complet avant de toucher à quoi que ce soit de réel. Voilà ce qui rend cette habitude praticable un mardi soir, plutôt que théorique dans un article de blog.

ISPConfig, MySQL, PHP, Dovecot, Pure-FTPd, Postfix et les autres noms mentionnés sont des marques déposées de leurs propriétaires respectifs. Ils sont utilisés uniquement pour identifier les produits.

The post Rotation des identifiants de base de données après une faille ISPConfig first appeared on Matteo Cisilino.

Qu’est-ce que MPTCP et pourquoi ça concerne aussi ceux qui ne l’utilisent pas

Multipath TCP (MPTCP) est le standard RFC 8684. Il étend le TCP classique pour faire circuler une seule connexion sur plusieurs chemins réseau à la fois. Un téléphone peut utiliser le WiFi et le réseau cellulaire au même moment, pour la même connexion. Un serveur avec plusieurs interfaces peut faire pareil, pour la redondance ou pour additionner la bande passante. Apple l’utilise en production depuis iOS 7, en 2013, pour Siri : c’est le cas d’usage réel le plus connu. Certains opérateurs mobiles, par exemple en Corée du Sud, l’exploitent pour le bonding WiFi/LTE. Plusieurs data centers l’adoptent pour le multi-homing entre différents uplinks. Dans le kernel Linux mainline, il est présent depuis la 5.6.

Le point qui m’a fait lever un sourcil est ailleurs. Depuis la version 1.24, les programmes écrits en Go exigent MPTCP par défaut pour les sockets en écoute. Le Go Security Team l’a confirmé le 29 octobre. Et il a donné un avertissement gênant : le bug dont on parle aujourd’hui n’est pas spécifique à MPTCP. Un système sans listener MPTCP actif peut rester quand même exposé à des attaques similaires. Le code vulnérable se trouve dans le chemin TCP IPv4 générique, pas dans un module optionnel. On peut désactiver MPTCP programme par programme, avec la variable GODEBUG=multipathtcp=0 à l’exécution. Mais le Go Security Team qualifie cette mitigation de « fragile » : il suffit d’un seul listener MPTCP resté exposé pour l’annuler. Personne n’a démontré que chaque exploit fonctionnel dépend vraiment de MPTCP. Voilà pourquoi le code MPTCP reste une surface d’attaque, même si vous ne l’activez jamais consciemment dans votre stack : il suffit qu’il soit compilé dans le kernel et atteignable.

Le projet MPTCP lui-même déclare, sur sa propre page, que les principales distributions Linux actuelles livrent le kernel avec le support MPTCP compilé par défaut (CONFIG_MPTCP=y). Il cite explicitement Debian, Ubuntu, RHEL et Fedora. C’est une déclaration du projet lui-même, pas une vérification indépendante distribution par distribution, mais le concept reste valable : le support est activé au niveau du kernel, pas « opt-in » au niveau du système d’exploitation. Seule la négociation par connexion individuelle reste à la charge de l’application.

La vulnérabilité kernel Linux CVE-2026-98432 en bref

Le CVE team du kernel Linux a publié la CVE-2026-98432 le 15 octobre 2026. Le correctif upstream avait déjà été appliqué dix jours plus tôt, le 5 octobre. Il arrive souvent que la publication suive le commit avec un certain retard. Le score CVSS de 9,8 (critique) n’est arrivé que le 24 octobre, neuf jours après la publication de la CVE.

Le problème se situe dans la gestion du handshake TCP pour IPv4, en particulier dans la fonction tcp_v4_syn_recv_sock(). Quand une connexion est créée, les options IP du paquet SYN sont transmises du request socket en attente vers le nouveau socket. Par exemple Record Route ou Timestamp, si le client les inclut dans un SYN forgé. Le problème est qu’elles sont transmises par référence, pas par copie, et sans le lock du listener. Selon l’analyse technique du patch, les structures concernées s’appellent inet_opt et ireq_opt. Un deuxième CPU peut libérer ce buffer avec kfree(), appelé depuis inet_sock_destruct() ou depuis tcp_v4_reqsk_destructor(). Pendant ce temps, un premier CPU est encore en train de le lire dans ip_options_build(), pour construire le SYNACK. C’est un classique use-after-free causé par une race condition. Le chemin IPv6 équivalent, tcp_v6_syn_recv_sock(), copie les options au lieu de les transmettre par référence : il n’est pas vulnérable à la race principale. Il existe aussi une seconde voie d’attaque, via la migration des request-sockets : net.ipv4.tcp_migrate_req=1 ou bien un programme eBPF BPF_SK_REUSEPORT_SELECT_OR_MIGRATE. Les deux sont désactivées par défaut.

Le bug est distant et ne nécessite ni authentification ni interaction de l’utilisateur, selon l’évaluation du kernel team. Il est présent depuis la version 4.4 du kernel. Le correctif est signé par Eric Dumazet, signalé par Xinyang Ge d’Anthropic. Il déplace la libération de la mémoire après une grace period RCU, avec kfree_rcu() : ainsi aucun CPU ne peut plus lire un buffer déjà libéré. Les versions stables corrigées sont 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 et la mainline depuis la 7.3-rc7.

Scores CVSS discordants : les fournisseurs ne sont pas tous d’accord

C’est ici que l’histoire se complique. Le kernel CVE team et Ubuntu évaluent la complexité d’attaque comme basse, et donnent 9,8 (critique). Oracle et SUSE donnent au contraire 8,1 (important) : même vecteur CVSS, mais complexité d’attaque haute. Red Hat, curieusement, a deux évaluations qui ne coïncident pas entre elles. La page CVE publique affiche « Moderate, 5.9 ». Le fichier d’advisory lisible par machine, mis à jour le 29 octobre, affiche au contraire « Important, 8.1 », avec un impact élevé sur la confidentialité et l’intégrité. Le même jour, le bug tracker interne de Red Hat a relevé la sévérité de medium à high. Amazon, de son côté, attribue 7,0. Au moment où j’écris, le NVD n’a pas encore publié son propre score.

Il faut le dire honnêtement. Cette incohérence interne à Red Hat n’est pas un détail que j’ai déduit moi-même : c’est ainsi que la rapporte l’article original de The Hacker News, ma source principale pour ces données. Ce n’est pas la première fois qu’un fournisseur publie deux chiffres différents pour le même bug, sur des canaux différents. Mais ici, le saut de « modéré » à « important » le même jour en dit long. Même pour ceux qui écrivent le code, estimer avec certitude l’exploitabilité réelle d’une race condition dans le kernel est difficile.

État des correctifs : Debian déjà corrigé, d’autres pas encore

C’est le point qui me concerne le plus directement : les hébergements que je gère tournent sur Debian stable. Et ici les faits parlent clairement, sans besoin d’ajouter d’emphase : Debian a déjà corrigé cette vulnérabilité kernel Linux, aussi bien sur trixie que sur bookworm. Debian trixie (stable) a été corrigée le 16 octobre 2026, avec le paquet linux 6.12.113-1, avis DSA-6568-1. Debian 12 (bookworm) a été corrigée en deux étapes : le 17 et le 22 octobre 2026, avec linux 6.1.190-1 (avis DLA-4841-1) et linux-6.12 6.12.113-1~deb12u1 (avis DLA-4850-1). Dans son propre tableau de suivi, Debian ne liste pas de score CVSS séparé pour cette CVE. Elle se limite à indiquer l’état du correctif pour chaque release : c’est l’information qui compte vraiment, pour qui doit décider de redémarrer un serveur.

Comparer cela à l’état d’autres distributions très utilisées aide à donner du poids à la chose. Au 30 octobre, Red Hat a mis à jour l’état de RHEL 8, 9, 10 et OpenShift 4. Avant, c’était « fix deferred » (noté le 29 octobre), maintenant c’est « affected ». Aucune date de sortie n’a été communiquée. Ubuntu, sur toutes les versions supportées (22.04, 24.04, 26.04, 26.10), reste « en cours de traitement », sans date. Ubuntu 16.04, 18.04 et 20.04 sont vulnérables, sans même un correctif listé. SUSE Linux Enterprise Server, de la SP4 à la SP7 plus la 16.0, est dans la même situation. Oracle Linux (UEK), openSUSE Leap 16.0, SUSE Linux Micro 6.2 et Amazon Linux 2023 sont au contraire déjà corrigés. RHEL 7 n’est pas affecté : le chemin de code vulnérable n’a jamais été distribué sur cette release.

Je ne dis pas cela pour faire concurrence à Ubuntu ou RHEL. Ce sont des distributions sérieuses, avec des processus de sécurité robustes. Je le dis parce que sur ce bug précis, dans cette fenêtre temporelle, les faits sont les suivants : ceux qui s’appuient sur des hébergements basés sur Debian stable ont déjà le correctif installé. Sur d’autres distributions très utilisées, en revanche, le serveur reste exposé pendant une durée indéterminée. C’est un avantage concret, vérifiable en regardant les dates. Ce n’est pas une opinion sur le projet Debian en général.

L’exploit (rapporté, non vérifié de façon indépendante) d’Anthropic

La partie la plus inhabituelle de cette histoire concerne Anthropic, l’entreprise qui a signalé le bug en premier via Xinyang Ge. Selon les rapports du secteur, un de ses modèles d’IA internes, non publié publiquement, a construit seul un exploit root fonctionnel. En partant uniquement du patch et du rapport comme prompt. L’attaque en deux phases fonctionnerait ainsi. Dans la première phase, la race fait envoyer à l’attaquant des octets supplémentaires de la réponse du kernel. De là, il récupère une adresse kernel, pour désamorcer KASLR. Dans la seconde phase, le même bug provoquerait un dépassement de buffer. Il écrase un pointeur de callback avec l’adresse d’une charge utile déjà placée en mémoire kernel par l’attaquant. Quand le kernel appelle ce pointeur, la charge utile exécute une commande shell au choix en tant que root. Une race perdue ferait échouer uniquement cette tentative de connexion, sans faire planter le système : des tentatives répétées seraient donc possibles. Dans le test décrit par Anthropic : 48 minutes pour voler l’adresse kernel, 5 minutes supplémentaires pour arriver à l’exécution de commandes.

Red Hat affirme qu’un attaquant distant qui atteint un service TCP exposé peut en général déclencher la race. L’exploit root décrit par Anthropic, cependant, aurait visé spécifiquement des serveurs avec un listener multipath TCP actif. Le billet d’Anthropic ne précise pas si un serveur sans MPTCP est exploitable de la même manière. Ni le record CVE ni le correctif upstream ne mentionnent MPTCP à aucun moment. C’est la presse spécialisée, et non une source primaire, qui rapporte ce lien : je l’écris donc avec le scepticisme qu’il mérite, pas comme un fait établi à cent pour cent. Anthropic n’a publié ni le code de l’exploit, ni la version exacte du kernel utilisée, ni la configuration du serveur cible. Une autre société, Innora, a publié une analyse de la cause racine, avec un environnement de reproduction QEMU. Elle a déclaré qu’elle ne publierait pas d’exploit armé à court terme. Pour l’instant, il n’y a aucune preuve d’exploitation réelle par des fournisseurs ou des CERT. Le bug ne figure pas dans le catalogue CISA KEV, selon la copie mise à jour par le CIRCL du Luxembourg au 28 octobre.

Que faire maintenant sur vos serveurs

Aucun fournisseur n’a publié de contournement officiellement sanctionné pour cette vulnérabilité kernel Linux. Red Hat dit explicitement qu’aucune des mesures qui circulent jusqu’à présent n’atteint son standard de facilité de déploiement et de stabilité. La mitigation principale reste d’appliquer le kernel corrigé et de redémarrer, quand le correctif est disponible pour votre distribution. Sur Debian, c’est déjà le cas. Sur RHEL et Ubuntu, pas encore, au moment où j’écris.

Comme défense en profondeur, pas comme solution définitive, certaines choses ont du sens. Vérifier que net.ipv4.tcp_migrate_req est bien à 0. Contrôler qu’aucun programme eBPF BPF_SK_REUSEPORT_SELECT_OR_MIGRATE n’est chargé. Évaluer un filtrage des paquets IPv4 entrants avec des options Record Route ou Timestamp. Surveiller les éventuels crashs qui citent ip_options_build, ip_build_and_send_pkt ou skb_under_panic. Faire l’inventaire des éventuels listeners MPTCP exposés, en évitant de les laisser atteignables sans raison. Si vous gérez aussi des services contre les attaques applicatives plus courantes, j’ai décrit la même approche dans comment j’ai protégé mes serveurs en attendant le correctif pour PHP2Shell. Atténuer ce qui peut l’être, en attendant le correctif définitif, sans promettre des protections qui n’existent pas.

Pour ceux qui me demandent s’il faut mettre à jour tout de suite : si vous utilisez Debian stable, le kernel corrigé est déjà dans les dépôts de sécurité. La mise à jour est simple, et la fenêtre d’exposition est déjà fermée. Si vous utilisez d’autres distributions, il n’y a pas encore de correctif à installer aujourd’hui. Cela vaut la peine de suivre de près les avis de votre fournisseur dans les prochains jours : la situation évolue rapidement.

Sources : The Hacker News, Debian Security Tracker et le commit du correctif. Debian, Red Hat, Ubuntu et les autres noms cités sont des marques de leurs propriétaires respectifs.

The post Vulnérabilité kernel Linux : un use-after-free dans le TCP IPv4 first appeared on Matteo Cisilino.

Pourquoi je consulte le journal email WordPress avant les logs du serveur

Le cas typique est toujours le même. Un formulaire de contact qui « n’arrive pas ». Un client qui ne reçoit pas l’email de réinitialisation de mot de passe. Une commande qui reste sans confirmation. Sans un journal à portée de main, la première hypothèse est le dossier spam. Puis les logs du serveur SMTP. Puis peut-être le pare-feu. Avec FluentSMTP, je saute ces étapes. Je vois tout de suite si WordPress a vraiment tenté d’envoyer cet email. À qui, quand, avec quelle réponse du serveur d’envoi.

FluentSMTP enregistre chaque appel à wp_mail(). Pas seulement les emails des plugins tiers, aussi ceux générés par le cœur de WordPress : notifications de nouvel utilisateur, rappels de mise à jour, alertes d’erreur. Pour chaque envoi, le journal affiche l’expéditeur, le destinataire, l’objet, les en-têtes complets, le corps du message. Et la réponse du fournisseur SMTP ou de l’API utilisée. Si un email a échoué, cette réponse du serveur est là. Je n’ai pas à la deviner.

Ce que je trouve vraiment dans le registre des envois

Le plugin prend en charge des dizaines de connecteurs : Amazon SES, SendGrid, Mailgun, Brevo, Postmark, SparkPost. Aussi Google Workspace et Microsoft 365 via OAuth, en plus du SMTP générique classique. Sur les sites que je gère, j’utilise presque toujours du SMTP authentifié avec le domaine du client. Parfois une API dédiée, quand le volume d’emails augmente. Dans les deux cas, le journal email WordPress ne change pas. Chaque ligne a un statut, envoyé ou échoué. Il y a un bouton pour revoir le contenu ou renvoyer le message, sans que l’utilisateur doive refaire l’action qui l’a généré.

Le renvoi manuel est la fonction que j’utilise le plus souvent. Un formulaire rempli deux fois parce qu’il « n’arrivait pas » devient un clic sur le journal. Pas un nouveau signalement au client. Pour les échecs répétés, j’ai activé les notifications sur Telegram. Dès qu’une connexion arrête de fonctionner, je le sais avant qu’on me le signale. Plutôt que de le découvrir par un ticket de support.

Le journal ne concerne pas seulement les notifications adressées à moi ou au client qui administre le site. Y finit aussi chaque email sortant généré par le site vers des tiers : la confirmation de commande qu’une boutique en ligne envoie au client final, le reçu d’un paiement, la notification d’expédition. Si cette confirmation n’arrive pas, je la vois dans le journal email WordPress exactement comme une notification interne, avec le même bouton pour la renvoyer au bon destinataire sans lui faire répéter l’achat.

Comment je configure FluentSMTP sur les sites que je gère

Après avoir connecté le bon connecteur, je change la conservation du journal. Par défaut elle reste active longtemps. Moi, je la porte à 30-60 jours, selon le trafic du site. Ça sert à retrouver un problème signalé en retard. Sans remplir la base de données de lignes que je ne consulterai jamais. J’active ensuite au moins un canal de notification pour les échecs, Telegram ou Slack selon le client. Le journal seul n’avertit personne : il faut l’ouvrir pour être lu.

Sur les sites avec formulaire de contact, j’utilise aussi Cisilino Site Defense Network pour bloquer les bots. Moins de spam entrant signifie moins d’emails générés par les formulaires. Le journal reste plus lisible, avec moins de bruit à filtrer quand je cherche le bon message.

Les identifiants SMTP ne restent pas en clair dans la base de données

Un détail que je vérifie toujours avant d’enregistrer une connexion : où finissent les identifiants. FluentSMTP les chiffre par défaut avec les clés SALT de WordPress, celles déjà présentes dans wp-config.php pour la sécurité des sessions. On peut désactiver le chiffrement, mais le plugin lui-même signale que c’est déconseillé. Sur les sites que je gère, je préfère une autre option : enregistrer le mot de passe API ou SMTP directement dans wp-config.php, hors de la base de données. Je définis les constantes avant que le plugin ne les lise. Ainsi, même un dump de la base de données ou un accès non autorisé au tableau de bord n’expose pas la clé du fournisseur d’envoi. C’est le même principe que j’applique ailleurs : moins de secrets dans la base de données, mieux c’est.

Plusieurs connexions en même temps, pas une seule à la fois

FluentSMTP permet de configurer plusieurs connexions en même temps, pas une seule à la fois. Sur un site, je règle celle par défaut et j’en ajoute une seconde comme réserve : si le premier fournisseur ne répond pas, l’envoi passe automatiquement à la connexion de réserve, sans que j’aie besoin d’intervenir. Le choix de la connexion dépend de l’adresse de l’expéditeur : chaque connexion a son « From », le reste passe par celle par défaut. La réserve n’est prête que si la connexion par défaut échoue vraiment (une erreur du fournisseur, pas un email tombé en spam). C’est une des raisons pour lesquelles je le préfère à un simple SMTP sans alternative. Si SendGrid ou Amazon SES ont un problème pendant quelques heures, le site continue quand même à envoyer, et je le vois tout de suite dans le journal email WordPress. Tout est inclus dans la version gratuite, sans version pro payante : on paie seulement le fournisseur d’envoi choisi, pas le plugin.

Un contrôle de santé chaque jour, pas seulement quand quelque chose casse

Au-delà du journal ligne par ligne, FluentSMTP fait un contrôle de santé de la connexion chaque jour, automatiquement. Si le fournisseur arrête de répondre, l’alerte arrive avant qu’un client ne m’écrive « le site n’envoie plus d’emails ». Le même tableau de bord affiche un graphique avec les totaux journaliers d’envois réussis et échoués. Utile pour comprendre en un coup d’œil si une baisse est normale ou le symptôme de quelque chose qui se détériore, sans avoir à ouvrir le journal email WordPress ligne par ligne chaque fois. Il y a aussi un résumé périodique par email, avec les totaux de la semaine : ce n’est pas une alerte d’erreur, c’est un bulletin que je lis en passant pour savoir si le volume d’envois est dans la norme.

Pour qui, comme moi, gère plusieurs sites en ligne de commande, FluentSMTP expose aussi des commandes WP-CLI : un test d’envoi, un contrôle de santé de la connexion, les statistiques et le nettoyage des anciens journaux. Je les utilise dans les mêmes scripts qui tournent déjà sur les serveurs pour d’autres tâches de maintenance, sans avoir à ouvrir le tableau de bord de chaque site un par un.

Les limites honnêtes du journal email WordPress

Ce n’est pas une solution magique. La conservation est basée sur les jours, pas sur un nombre maximal de lignes. Sur un site avec beaucoup de trafic transactionnel, la table du journal peut grossir vite. Il vaut mieux la surveiller, ou fixer une conservation plus courte. Les notifications d’échec n’arrivent que sur les canaux de chat configurés, pas par email. C’est logique : un email qui avertit d’un email en échec risque lui aussi d’échouer. Mais il faut le savoir avant d’y compter.

Enfin, le journal enregistre ce qui s’est passé côté WordPress et côté fournisseur. Il ne garantit pas la livraison dans la boîte du destinataire. Si un email est marqué comme envoyé mais finit en spam, c’est un problème de réputation du domaine ou de configuration SPF/DKIM. Pas quelque chose qu’un journal peut résoudre seul. Il reste malgré tout le premier endroit où je regarde, avant toute autre vérification.

Le plugin est gratuit et open source. Page officielle sur wordpress.org, sans fonctions bloquées derrière une version pro. Pour qui gère même un seul site avec un formulaire de contact, ça vaut le coup de l’installer juste pour le journal email WordPress. La première fois qu’il résout un « je n’ai pas reçu l’email » en une minute plutôt qu’en une demi-heure, il est rentabilisé.

The post Journal email WordPress : pourquoi je le contrôle first appeared on Matteo Cisilino.

Dans cet article, j’explique ce que c’est et quelles versions de PHP sont concernées. Je raconte comment j’ai sécurisé les serveurs que je gère pendant que le correctif n’existait pas, et comment je suis arrivé à la mise à jour définitive. Tu trouveras aussi le script que j’ai utilisé et les commandes pour le lancer.

Qu’est-ce que PHP2Shell

Le problème vient de la façon dont PHP lit les requêtes de type multipart/form-data. C’est le format que le navigateur utilise pour envoyer des fichiers. PHP l’interprète avant le démarrage de n’importe quel script.

Il n’y a donc pas besoin d’un module d’upload. Une seule requête vers un fichier PHP quelconque du site peut suffire.

Les deux failles, en bref :

• CVE-2026-109618. Si la mémoire s’épuise pendant que PHP lit la requête, certaines données se corrompent. La corruption apparaît lors du nettoyage final de la requête et peut mener à l’exécution de code.
• CVE-2026-109619. Une partie de l’état d’une requête reste en mémoire. Une requête suivante, sur le même processus, la réutilise.

Ces détails techniques viennent de l’analyse du NCSC néerlandais et d’autres sources publiques. Je n’ai pas essayé d’exploiter les failles sur mes serveurs.

Quelles versions de PHP sont concernées

Les versions corrigées sont sorties le 21 octobre 2026 : PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Toute version antérieure est touchée.

Les branches 8.1 et plus anciennes n’ont pas de version corrigée officielle, parce qu’elles ne sont plus supportées. PHP a publié seulement des backports minimaux du code source pour 7.4, 8.0 et 8.1. Pour les branches encore plus anciennes, rien n’est indiqué.

Le risque concerne toutes les façons d’exécuter PHP. La plus exposée est mod_php. PHP-FPM, php-cgi, FrankenPHP et LiteSpeed comptent aussi. Cela touche ensuite chaque application qui tourne dessus : WordPress, Joomla, Drupal, Nextcloud, phpMyAdmin, Roundcube et le panneau ISPConfig.

Sur Debian, il y a un détail à connaître. Debian applique les corrections sous forme de backports et ne change pas le numéro de version de PHP. Un serveur peut afficher un numéro bas et être déjà corrigé. C’est pourquoi le script ne compare pas les versions. Il vérifie si le changelog du paquet installé cite les deux CVE.

L’atténuation, en attendant le patch

Quand les failles sont devenues publiques, les correctifs n’étaient pas encore disponibles pour les distributions. Je ne voulais pas laisser les serveurs à découvert, alors j’ai réduit le risque avec un script.

L’atténuation n’est pas un patch. Désactiver session.upload_progress ne ferme qu’un des chemins connus de la CVE-2026-109619 et ne fait rien contre la CVE-2026-109618. Elle servait à réduire la marge d’attaque jusqu’à la mise à jour, pas à la remplacer.

Ce que fait le script

Le script est prévu pour Debian 12 et 13. Il fonctionne avec Apache (mod_php, FastCGI, suPHP, PHP-FPM) et avec Nginx (PHP-FPM). Il reconnaît les serveurs gérés avec ISPConfig, aussi bien Apache que Nginx.

Les options :

• Sans option, il contrôle, c’est tout. Pour chaque paquet PHP, il vérifie que le changelog cite les deux CVE. Il signale les processus qui utilisent encore un ancien binaire, lit les réglages actifs et les ports web en écoute.
• --update met d’abord à jour l’index des paquets.
• --logs cherche des indices suspects : fichiers PHP récents dans les dossiers d’upload ou de cache, motifs typiques des webshells, références à php2shell dans les logs. C’est une heuristique, elle ne prouve pas une compromission.
• --harden applique la sécurisation décrite plus bas.
• --dry-run, avec --harden, montre ce qu’il ferait sans rien modifier.
• --skip-disable-functions, avec --harden, ne touche pas à disable_functions.
• --rollback retire ce qu’a appliqué --harden.

Ce que change –harden

Pour chaque version de PHP présente dans /etc/php, le script crée le fichier mods-available/cve-hardening.ini. Il l’active avec phpenmod pour les SAPI fpm, apache2 et cgi. La protection vaut ainsi pour tous les sites d’un coup.

Les php.ini d’origine restent intacts. La CLI n’est pas touchée, donc composer, artisan et wp-cli continuent de fonctionner.

Le fichier règle trois choses :

• session.upload_progress.enabled = Off
• expose_php = Off
• disable_functions avec exec, passthru, shell_exec, system, proc_open, popen et pcntl_exec, ajoutées à celles déjà présentes.

Ensuite le script teste la configuration et recharge PHP-FPM et Apache seulement si le test passe. Avant d’écrire, il fait une sauvegarde dans /var/backups/php-cve-hardening/.

Les limites à connaître

• disable_functions peut casser certaines applications, par exemple WordPress avec certains plugins ou Magento. Si ça arrive, utilise --rollback ou relance avec --skip-disable-functions.
• Les directives php_admin_value dans les pools PHP-FPM ont la priorité sur le fichier global. Le script les signale mais ne les modifie pas.
• Avec ISPConfig, les fichiers de pool.d sont régénérés par le panneau. Les surcharges se corrigent depuis le panneau, dans Sites, Website, Options, Custom php.ini settings, pas à la main.
• Les php.ini propres à chaque site (mode FastCGI ou suPHP d’ISPConfig) et les versions de PHP dans /opt ne sont pas gérés. Il faut les contrôler à part.

Comment lancer le script

Le script est ici : https://cisilino.com/mscripts/php20261.sh

Avant d’exécuter quoi que ce soit venu d’internet, lis-le. Tu peux le télécharger et l’ouvrir :

wget -qO php20261.sh https://cisilino.com/mscripts/php20261.sh
less php20261.sh

Si tu veux le lancer directement à distance, il faut les droits root. Voici les commandes, dans l’ordre que je conseille.

1. Contrôle seul, avec mise à jour de l’index des paquets :

wget -qO- https://cisilino.com/mscripts/php20261.sh | sudo bash -s -- --update

2. Simulation de la sécurisation, sans modification :

wget -qO- https://cisilino.com/mscripts/php20261.sh | sudo bash -s -- --harden --dry-run

3. Application :

wget -qO- https://cisilino.com/mscripts/php20261.sh | sudo bash -s -- --harden

4. Retrait, si quelque chose casse :

wget -qO- https://cisilino.com/mscripts/php20261.sh | sudo bash -s -- --rollback

Après --harden et après --rollback, pas besoin de redémarrer quoi que ce soit à la main : le script recharge lui-même PHP-FPM et Apache, après avoir testé la configuration. Le redémarrage est en revanche nécessaire après la mise à jour du paquet PHP, car les processus en cours gardent l’ancien binaire en mémoire :

sudo systemctl restart 'php*-fpm' apache2

Les apostrophes autour de php*-fpm sont nécessaires. Sans elles, c’est le shell qui développe l’astérisque, pas systemctl. Si le serveur utilise seulement Nginx, retire apache2.

Le résultat du script est aussi un code de sortie : 0 si tout va bien, 1 s’il y a des avertissements, 2 si le système est vulnérable ou si une action est nécessaire.

Sur les serveurs avec ISPConfig : ispconfig-multipart-guard

Qui utilise ISPConfig a une arme de plus. Le projet a publié le script ispconfig-multipart-guard, décrit dans l’avis officiel d’ISPConfig.

Le principe est simple. Si le problème est dans les requêtes multipart, le serveur web les arrête avant qu’elles n’arrivent à PHP :

• il bloque les requêtes Content-Type: multipart/... pour tous les sites, pour certains sites choisis ou pour le panneau de contrôle ;
• avec Nginx, il répond 415 aux requêtes PHP des sites bloqués et les fichiers statiques ne changent pas. Avec Apache, il répond 403, même pour les fichiers statiques ;
• par défaut, il bloque seulement le panneau ISPConfig. Les sites se bloquent avec des commandes comme block all ou block esempio.it ;
• il crée un cron qui, toutes les 5 minutes, rétablit ses hooks si ISPConfig réécrit la configuration ;
• il a une liste d’IP autorisées qui peuvent encore envoyer des fichiers.

Il fonctionne avec Debian et Ubuntu, avec ISPConfig 3.2 ou 3.3 (et même sans ISPConfig), avec Nginx ou avec Apache 2.4 et suivants.

Le prix à payer : sur les sites bloqués, les uploads ne fonctionnent pas. Cela vaut aussi pour les médias des CMS, les pièces jointes des formulaires et celles du webmail, et les imports de phpMyAdmin. Les pages normales et les formulaires urlencoded continuent de fonctionner. Là aussi, c’est une mesure provisoire et non une correction.

Ce script et le mien ne sont pas des alternatives. Le mien agit sur la configuration de PHP, celui d’ISPConfig sur le serveur web. Je ne les ai pas comparés sur le terrain et je ne peux pas te dire comment ils se comportent ensemble sur chaque configuration.

La mise à jour définitive, en deux étapes

Les atténuations devaient durer peu. J’ai mis à jour les serveurs dès que les mises à jour ont été disponibles, en deux étapes :

1. Compilation directe. En attendant que la distribution utilisée sur chaque serveur publie son paquet, j’ai compilé PHP depuis les sources dans les versions corrigées.
2. Paquet officiel. Quand le paquet officiel de la distribution est sorti pour ce serveur, j’ai remplacé la compilation par le paquet.

La deuxième étape compte. Un PHP compilé à la main ne se met pas à jour tout seul avec le reste du système. Le paquet de la distribution, si, et le script peut le vérifier en lisant le changelog.

Que faire maintenant

1. Mets PHP à jour vers la 8.5.12, 8.4.27, 8.3.36 ou 8.2.35. Sur Debian, tu peux aussi utiliser le paquet de la distribution quand le changelog cite les deux CVE.
2. Redémarre PHP-FPM et Apache, puis relance le script sans option. Il ne doit plus signaler de problème.
3. Si tu utilises PHP 8.1 ou antérieur, prévois le passage à une branche supportée. Pour ces branches, il n’y a pas de version officielle corrigée.
4. Garde session.upload_progress désactivé jusqu’à la prochaine publication de correctifs, si ton application ne l’utilise pas.
5. Contrôle les logs et les fichiers récents, avec --logs ou à la main, en cherchant des fichiers PHP apparus dans les dossiers d’upload.
6. N’oublie pas PHP dans les conteneurs, les images et les appliances de tiers. Ils se mettent à jour à part.
7. Si ton site utilise WordPress, le plugin Cisilino Site Defense Network ne résout pas PHP2Shell. Il protège toutefois la connexion et tient un journal des activités, utile pour comprendre ce qui se passe sur le site.

Sources

• ISPConfig : PHP2Shell, vulnérabilités critiques de PHP (CVE-2026-109618, CVE-2026-109619)
• NCSC-NL : wiki sur PHP2Shell

ISPConfig, PHP, Debian et les autres noms cités sont des marques de leurs propriétaires respectifs. Ils sont indiqués uniquement pour identifier les produits.

The post PHP2Shell : comment j’ai protégé mes serveurs en attendant le correctif first appeared on Matteo Cisilino.

Je m’y suis retrouvé confronté après une optimisation. J’avais lancé OPTIMIZE TABLE en espérant récupérer de l’espace, mais le système de fichiers ne baissait pas comme prévu. Sans un « avant » à comparer à l’« après », impossible de savoir si l’optimisation avait fonctionné. Impossible aussi de savoir quelle base était responsable, et si l’espace disque manquant n’était pas carrément ailleurs.

Les outils dont je disposais ne répondaient qu’à la moitié du problème :

• du montre les fichiers sur le disque, mais ne dit pas à quelle table ils appartiennent ;
• information_schema (ou pg_class sur PostgreSQL) donne les tailles logiques, mais ne voit ni les binlogs, ni ibdata1, ni les undo logs, ni les WAL ;
• tous deux photographient un seul instant : la comparaison dans le temps reste un travail manuel, fait de copier-coller et d’un tableur.

Il me fallait quelque chose de simple : photographier l’état de toutes les bases à un moment donné, refaire la photo plus tard et me dire ce qui a changé, en classant les différences de la plus grande à la plus petite. Le coupable saute ainsi aux yeux.

Il en est sorti un unique script Bash, sans dépendances au-delà du client de base de données et des outils standard de Linux (awk, du, df). Il fonctionne avec MySQL/MariaDB et avec PostgreSQL. Je le partage ici dans l’espoir d’épargner à quelqu’un le même après-midi de frustration.

Ce qu’il fait

Le script a quatre commandes :

• snapshot enregistre l’état actuel (bases, tables, fichiers du répertoire de données, espace du système de fichiers) ;
• compare compare deux instantanés et montre les différences, les plus grandes en tête ;
• report montre les bases et tables les plus grosses d’un seul instantané ;
• list liste les instantanés enregistrés.

La comparaison est divisée en quatre sections, pour ne laisser aucun angle mort :

• taille de chaque base (données + index) ;
• espace libre ou récupérable (data_free sur MySQL, estimation des tuples morts sur PostgreSQL) ;
• taille de chaque table ;
• fichiers réels du répertoire de données : dossiers des bases, ibdata1, binlogs, undo, pg_wal.

La dernière section est souvent celle qui résout le mystère. Bien des fois, l’espace « anormal » n’appartient à aucune base, mais aux journaux binaires ou aux fichiers partagés d’InnoDB.

Prérequis

• Linux avec Bash 4 ou supérieur, awk, du, df (le tout en standard) ;
• le client mysql ou psql, avec un utilisateur capable de lire les métadonnées de toutes les bases ;
• les droits root (ou ceux de l’utilisateur mysql/postgres) si vous voulez aussi mesurer les fichiers sur disque ; sans eux, cette section est ignorée avec un avertissement.

Installation

Enregistrez le script (vous le trouverez à la fin de l’article) dans un fichier et rendez-le exécutable :

nano db_space_compare.sh
chmod +x db_space_compare.sh

Identifiants

Pour MySQL/MariaDB, le plus propre est un fichier ~/.my.cnf contenant les identifiants, afin qu’ils n’apparaissent pas dans l’historique des commandes :

[client]
user=root
password=LA_TUA_PASSWORD

Vous pouvez aussi passer les options via une variable d’environnement :

export MYSQL_OPTS="-u root -pPASSWORD -h 127.0.0.1"

Pour PostgreSQL, ~/.pgpass, les variables PG* ou PG_OPTS fonctionnent :

export PG_OPTS="-U postgres -h localhost"

Comment l’utiliser

Le déroulement type est avant, optimisation, après, comparaison :

# 1. fotografia prima dell'ottimizzazione
sudo ./db_space_compare.sh snapshot prima

# 2. esegui l'ottimizzazione (OPTIMIZE TABLE, VACUUM FULL, ...)

# 3. fotografia dopo
sudo ./db_space_compare.sh snapshot dopo

# 4. confronto
sudo ./db_space_compare.sh compare prima dopo

Pour PostgreSQL, il suffit d’ajouter l’option -e postgres :

sudo ./db_space_compare.sh -e postgres snapshot prima
sudo ./db_space_compare.sh -e postgres snapshot dopo
sudo ./db_space_compare.sh -e postgres compare prima dopo

Les options disponibles sont :

• -e mysql|postgres choisit le moteur (par défaut : mysql) ;
• -d DIR change le dossier où sont enregistrés les instantanés (par défaut : ./db_snapshots) ;
• -n N fixe le nombre de lignes affichées par section (par défaut : 20).

Si vous n’indiquez pas d’étiquette, l’instantané prend pour nom la date et l’heure. C’est pratique pour surveiller la croissance dans le temps.

Exemple de sortie

Voici une comparaison sur des données de test, construites exprès pour montrer un cas typique. La base shop diminue après l’optimisation, mais la base log grossit et les binlogs doublent.

Confronto 'prima' (2026-10-11 20:00:00)  ->  'dopo' (2026-10-11 22:00:00)
Filesystem /var: usato 46.6 GiB -> 48.4 GiB (+1.9 GiB)

=== Database - dimensione totale ===
  NOME                                                      PRIMA         DOPO    DIFFERENZA  NOTE
  log                                                    21.4 GiB     27.5 GiB      +6.1 GiB  +28.3%
  shop                                                    5.6 GiB      3.6 GiB      -2.0 GiB  -35.0%

=== Tabelle - dimensione (dati + indici) ===
  NOME                                                      PRIMA         DOPO    DIFFERENZA  NOTE
  log.eventi                                             21.4 GiB     27.5 GiB      +6.1 GiB  +28.3%
  shop.ordini                                             5.6 GiB      3.6 GiB      -2.0 GiB  -35.0%
  log.nuova                                                   0 B      1.0 KiB      +1.0 KiB  NUOVO

=== File nella data directory (cartelle DB, ibdata1, binlog, undo, WAL) ===
  NOME                                                      PRIMA         DOPO    DIFFERENZA  NOTE
  log                                                    21.4 GiB     27.5 GiB      +6.1 GiB  +28.3%
  mysql-bin.*                                             3.7 GiB      8.4 GiB      +4.7 GiB  +125.0%
  shop                                                    5.7 GiB      3.6 GiB      -2.0 GiB  -36.1%
  ibdata1                                                11.2 GiB     11.2 GiB           0 B

Ici le coupable est évident. La table log.eventi a grossi de plus de 6 GiB. Les fichiers mysql-bin.* sont passés de 3,7 à 8,4 GiB. L’optimisation sur shop a fonctionné, mais le gain d’espace disque a été englouti par le reste.

Comment lire les résultats

• En haut de chaque section se trouvent les éléments qui ont le plus changé. Une base ou une table qui ne diminue pas (voire grossit) après l’optimisation est le premier suspect.
• Si les tables diminuent mais pas le système de fichiers, l’espace disque est ailleurs. Regardez la section sur les fichiers du répertoire de données (binlogs, ibdata1, undo, pg_wal).
• MySQL/MariaDB : ibdata1 ne rétrécit jamais, pas même avec OPTIMIZE TABLE. Avec innodb_file_per_table=OFF, la valeur de data_free est partagée et peu indicative.
• PostgreSQL : un simple VACUUM ne rend pas d’espace au système d’exploitation, il faut VACUUM FULL (ou pg_repack). L’espace « récupérable » affiché est une estimation fondée sur les tuples morts.

Pour PostgreSQL, la documentation officielle sur l’utilisation du disque explique comment mesurer l’espace occupé.

Surveiller l’espace disque dans le temps

Si le problème n’est pas lié à une seule optimisation mais à une croissance progressive, mieux vaut automatiser les instantanés avec cron, un par heure, puis comparer deux moments quelconques :

# crontab -e (come root)
0 * * * * /usr/local/bin/db_space_compare.sh -d /var/lib/db_snapshots snapshot >/dev/null 2>&1

Sans étiquette, chaque instantané prend pour nom la date et l’heure (par exemple 20261011-140000). Avec list vous voyez ceux qui existent et avec compare vous en comparez deux. En quelques jours, on voit quelle base grossit de façon anormale.

./db_space_compare.sh -d /var/lib/db_snapshots list
./db_space_compare.sh -d /var/lib/db_snapshots compare 20261011-140000 20261012-140000

Le script complet

Voici le code. Copiez-le dans un fichier nommé db_space_compare.sh, rendez-le exécutable et vous êtes prêt.

#!/usr/bin/env bash
#
# db_space_compare.sh
# Fotografa l'occupazione di spazio di tutti i database (MySQL/MariaDB o
# PostgreSQL) e confronta due fotografie (es. prima/dopo l'ottimizzazione)
# per capire quale database, tabella o file occupa spazio in modo anomalo.
#
# Uso:
#   db_space_compare.sh [opzioni] snapshot [etichetta]   (default: data-ora)
#   db_space_compare.sh [opzioni] compare  <prima> <dopo>
#   db_space_compare.sh [opzioni] report   <etichetta>
#   db_space_compare.sh [opzioni] list
#
# Opzioni:
#   -e mysql|postgres   motore del database (default: mysql)
#   -d DIR              cartella delle fotografie (default: ./db_snapshots)
#   -n N                righe mostrate per sezione (default: 20)
#
# Credenziali:
#   MySQL/MariaDB: ~/.my.cnf oppure MYSQL_OPTS="-u root -pPASSWORD -h 127.0.0.1"
#   PostgreSQL:    ~/.pgpass, variabili PG* oppure PG_OPTS="-U postgres -h localhost"
#                  (non mettere -d in PG_OPTS: lo script si collega a ogni database)
#
# Per misurare anche i file su disco (cartelle dei DB, ibdata1, binlog, undo,
# pg_wal) va eseguito come root o come utente mysql/postgres; altrimenti
# quella parte viene saltata con un avviso.
#
# Esempio:
#   sudo ./db_space_compare.sh snapshot prima
#   ... ottimizzazione (OPTIMIZE TABLE / VACUUM FULL / ...) ...
#   sudo ./db_space_compare.sh snapshot dopo
#   sudo ./db_space_compare.sh compare prima dopo

set -euo pipefail
export LC_ALL=C

ENGINE=mysql
OUTDIR=./db_snapshots
TOPN=20
SNAP_IN_PROGRESS=""

die()  { echo "ERRORE: $*" >&2; exit 1; }
warn() { echo "ATTENZIONE: $*" >&2; }
usage() { sed -n '2,/^$/{s/^# \{0,1\}//;p}' "$0"; exit "${1:-0}"; }

cleanup() {
  if [[ -n $SNAP_IN_PROGRESS ]]; then
    rm -rf -- "$SNAP_IN_PROGRESS"
    echo "Fotografia incompleta rimossa: $SNAP_IN_PROGRESS" >&2
  fi
}
trap cleanup EXIT

while getopts ":e:d:n:h" opt; do
  case $opt in
    e) ENGINE=$OPTARG ;;
    d) OUTDIR=$OPTARG ;;
    n) TOPN=$OPTARG ;;
    h) usage 0 ;;
    *) usage 1 ;;
  esac
done
shift $((OPTIND - 1))

[[ $ENGINE == mysql || $ENGINE == postgres ]] || die "motore non valido: '$ENGINE' (usa mysql o postgres)"
[[ $TOPN =~ ^[0-9]+$ ]] || die "-n deve essere un numero"

read -r -a MYSQL_ARGS <<< "${MYSQL_OPTS:-}"
read -r -a PG_ARGS    <<< "${PG_OPTS:-}"

my() { mysql "${MYSQL_ARGS[@]+"${MYSQL_ARGS[@]}"}" --batch --skip-column-names "$@"; }
pg() { psql  "${PG_ARGS[@]+"${PG_ARGS[@]}"}" -X -q -A -t -F $'\t' -v ON_ERROR_STOP=1 "$@"; }

# Funzioni awk comuni: formattazione in KiB/MiB/GiB, chiave e valore di riga.
#   nk = numero di colonne che formano il nome (1 = database, 2 = db.tabella)
#   vc = colonne da sommare per il valore (es. "4,5" = dati + indici)
AWK_LIB='
function h(b,   a, i, u) {
  split("B KiB MiB GiB TiB PiB", u, " ")
  a = (b < 0) ? -b : b; i = 1
  while (a >= 1024 && i < 6) { a /= 1024; i++ }
  if (i == 1) return sprintf("%s%d B", (b < 0 ? "-" : ""), a)
  return sprintf("%s%.1f %s", (b < 0 ? "-" : ""), a, u[i])
}
function hs(b) { return (b > 0 ? "+" : "") h(b) }
function key(   k, i) { k = $1; for (i = 2; i <= nk; i++) k = k "." $i; return k }
function val(   n, c, i, s) { n = split(vc, c, ","); s = 0; for (i = 1; i <= n; i++) s += $(c[i]); return s }
'

meta_get() { awk -F= -v k="$2" '$1 == k { sub(/^[^=]*=/, ""); print; exit }' "$1/meta.txt"; }

# ---------------------------------------------------------------- raccolta dati

# Occupazione reale su disco delle voci di primo livello della data directory:
# cartelle dei database, ibdata1, binlog, undo, redo log, pg_wal, base, ...
# I file numerati (mysql-bin.000123, relay-log.000045, ...) sono sommati in una voce.
collect_disk() {
  local d=$1 out=$2
  : > "$out"
  if [[ -z $d || ! -r $d || ! -x $d ]]; then
    warn "data directory '${d:-?}' non leggibile: salto i file su disco (esegui come root per includerli)"
    return 0
  fi
  { du -sb -- "$d"/* 2>/dev/null || true; } |
    awk -F'\t' -v p="$d/" '
      { n = $2
        if (index(n, p) == 1) n = substr(n, length(p) + 1)
        if (n ~ /\.[0-9][0-9][0-9][0-9][0-9][0-9]$/) sub(/[0-9]+$/, "*", n)
        s[n] += $1 }
      END { for (n in s) printf "%s\t%.0f\n", n, s[n] }' > "$out"
}

write_meta() {
  local dir=$1 datadir=$2 version=$3
  {
    echo "timestamp=$(date '+%Y-%m-%d %H:%M:%S')"
    echo "engine=$ENGINE"
    echo "host=$(hostname)"
    echo "version=$version"
    echo "datadir=$datadir"
    if [[ -n $datadir && -e $datadir ]]; then
      { df -P -B1 -- "$datadir" 2>/dev/null || true; } |
        awk 'NR == 2 { print "fs_mount=" $6; print "fs_used=" $3; print "fs_avail=" $4 }'
    fi
  } > "$dir/meta.txt"
}

# File prodotti da ogni fotografia (separati da TAB):
#   tables.tsv     db, tabella, engine, dati, indici, libero/recuperabile, righe
#   databases.tsv  db, dati, indici, libero/recuperabile, totale
#   disk.tsv       voce della data directory, byte su disco
#   meta.txt       data, host, versione, filesystem

snapshot_mysql() {
  local dir=$1 pre="" datadir version
  command -v mysql >/dev/null 2>&1 || die "client 'mysql' non trovato"
  my -e "SELECT 1" >/dev/null || die "connessione a MySQL/MariaDB fallita (controlla ~/.my.cnf o MYSQL_OPTS)"

  # MySQL 8 tiene in cache le statistiche di information_schema fino a 24 ore:
  # senza questo, i valori "dopo" l'ottimizzazione potrebbero essere quelli vecchi.
  if [[ -n $(my -e "SHOW VARIABLES LIKE 'information_schema_stats_expiry'") ]]; then
    pre="SET SESSION information_schema_stats_expiry = 0;"
  fi

  my -e "$pre
    SELECT table_schema, table_name, IFNULL(engine, '-'),
           IFNULL(data_length, 0), IFNULL(index_length, 0), IFNULL(data_free, 0), IFNULL(table_rows, 0)
      FROM information_schema.TABLES
     WHERE table_type IN ('BASE TABLE', 'SYSTEM VERSIONED')
       AND table_schema NOT IN ('information_schema', 'performance_schema', 'sys')" > "$dir/tables.tsv"

  my -e "$pre
    SELECT s.schema_name,
           IFNULL(SUM(t.data_length), 0), IFNULL(SUM(t.index_length), 0), IFNULL(SUM(t.data_free), 0),
           IFNULL(SUM(t.data_length), 0) + IFNULL(SUM(t.index_length), 0)
      FROM information_schema.SCHEMATA s
      LEFT JOIN information_schema.TABLES t
             ON t.table_schema = s.schema_name
            AND t.table_type IN ('BASE TABLE', 'SYSTEM VERSIONED')
     WHERE s.schema_name NOT IN ('information_schema', 'performance_schema', 'sys')
     GROUP BY s.schema_name" > "$dir/databases.tsv"

  datadir=$(my -e "SELECT @@datadir"); datadir=${datadir%/}
  version=$(my -e "SELECT VERSION()")
  collect_disk "$datadir" "$dir/disk.tsv"
  write_meta "$dir" "$datadir" "$version"
}

snapshot_postgres() {
  local dir=$1 maindb=${PGDATABASE:-postgres} datadir version db
  command -v psql >/dev/null 2>&1 || die "client 'psql' non trovato"
  pg -d "$maindb" -c "SELECT 1" >/dev/null || die "connessione a PostgreSQL fallita (controlla PG_OPTS, PGUSER, ~/.pgpass)"

  pg -d "$maindb" -c "SELECT datname FROM pg_database WHERE datallowconn AND NOT datistemplate ORDER BY 1" > "$dir/.dblist"

  # Per ogni database: dimensione di ogni tabella (catalogo incluso, es. pg_largeobject)
  # e stima dello spazio occupato da tuple morte (bloat recuperabile con VACUUM FULL).
  : > "$dir/tables.tsv"
  while IFS= read -r db; do
    [[ -n $db ]] || continue
    pg -d "$db" -c "
      SELECT current_database(), s.schemaname || '.' || s.relname, 'table',
             pg_table_size(s.relid), pg_indexes_size(s.relid),
             CASE WHEN s.n_live_tup + s.n_dead_tup > 0
                  THEN (pg_table_size(s.relid)::numeric * s.n_dead_tup / (s.n_live_tup + s.n_dead_tup))::bigint
                  ELSE 0 END,
             s.n_live_tup
        FROM pg_stat_all_tables s
       WHERE s.schemaname <> 'information_schema'
         AND s.schemaname NOT LIKE 'pg_toast%'" < /dev/null >> "$dir/tables.tsv" \
      || warn "impossibile leggere le tabelle del database '$db'"
  done < "$dir/.dblist"

  pg -d "$maindb" -c "SELECT datname, pg_database_size(oid) FROM pg_database WHERE datallowconn AND NOT datistemplate" > "$dir/.dbsize"
  awk -F'\t' '
    FILENAME == ARGV[1] { d[$1] += $4; i[$1] += $5; f[$1] += $6; next }
    { printf "%s\t%.0f\t%.0f\t%.0f\t%s\n", $1, d[$1], i[$1], f[$1], $2 }' \
    "$dir/tables.tsv" "$dir/.dbsize" > "$dir/databases.tsv"

  datadir=$(pg -d "$maindb" -c "SHOW data_directory" 2>/dev/null || true)
  version=$(pg -d "$maindb" -c "SHOW server_version")
  collect_disk "$datadir" "$dir/disk.tsv"

  # Dettaglio di base/<oid> con il nome del database al posto dell'oid
  if [[ -n $datadir && -r $datadir/base && -x $datadir/base ]]; then
    pg -d "$maindb" -c "SELECT oid, datname FROM pg_database" > "$dir/.oidmap"
    { du -sb -- "$datadir"/base/* 2>/dev/null || true; } |
      awk -F'\t' '
        FILENAME == ARGV[1] { name[$1] = $2; next }
        { o = $2; sub(/.*\//, "", o); printf "base/%s\t%s\n", ((o in name) ? name[o] : o), $1 }' \
        "$dir/.oidmap" - >> "$dir/disk.tsv"
  fi
  write_meta "$dir" "$datadir" "$version"
}

# --------------------------------------------------------------- presentazione

print_fs() {
  local d=$1 used avail mount
  used=$(meta_get "$d" fs_used); avail=$(meta_get "$d" fs_avail); mount=$(meta_get "$d" fs_mount)
  [[ -n $used ]] || return 0
  awk -v u="$used" -v a="$avail" -v m="$mount" "$AWK_LIB"'
    BEGIN { printf "Filesystem %s: usato %s, libero %s\n", m, h(u), h(a) }'
}

top_section() {
  local f=$1 nk=$2 vc=$3 title=$4
  echo
  echo "=== $title ==="
  if [[ ! -s $f ]]; then echo "  (nessun dato)"; return 0; fi
  awk -F'\t' -v nk="$nk" -v vc="$vc" "$AWK_LIB"'
    { v = val(); printf "%.0f\t%s\t%s\n", v, key(), h(v) }' "$f" |
    sort -t $'\t' -k1,1nr -k2,2 |
    awk -F'\t' -v top="$TOPN" 'NR <= top && $1 > 0 { printf "  %-60s %12s\n", $2, $3 }'
}

compare_section() {
  local fa=$1 fb=$2 nk=$3 vc=$4 title=$5
  [[ -f $fa ]] || fa=/dev/null
  [[ -f $fb ]] || fb=/dev/null
  echo
  echo "=== $title ==="
  if [[ ! -s $fa && ! -s $fb ]]; then echo "  (nessun dato)"; return 0; fi
  printf '  %-50s %12s %12s %13s  %s\n' "NOME" "PRIMA" "DOPO" "DIFFERENZA" "NOTE"
  awk -F'\t' -v nk="$nk" -v vc="$vc" "$AWK_LIB"'
    FILENAME == ARGV[1] { k = key(); A[k] = val(); S[k] = 1; next }
                        { k = key(); B[k] = val(); S[k] = 1 }
    END {
      for (k in S) {
        inA = (k in A); inB = (k in B)
        a = inA ? A[k] : 0; b = inB ? B[k] : 0; d = b - a
        if (!inA)                 note = "NUOVO"
        else if (!inB)            note = "RIMOSSO"
        else if (a > 0 && d != 0) note = sprintf("%+.1f%%", 100 * d / a)
        else                      note = ""
        printf "%.0f\t%s\t%s\t%s\t%s\t%s\n", (d < 0 ? -d : d), k, h(a), h(b), hs(d), note
      }
    }' "$fa" "$fb" |
    sort -t $'\t' -k1,1nr -k2,2 |
    awk -F'\t' -v top="$TOPN" 'NR <= top { printf "  %-50s %12s %12s %13s  %s\n", $2, $3, $4, $5, $6 }'
}

# -------------------------------------------------------------------- comandi

cmd_snapshot() {
  local label=${1:-$(date '+%Y%m%d-%H%M%S')}
  [[ $label =~ ^[A-Za-z0-9][A-Za-z0-9._-]*$ ]] || die "etichetta non valida: usa solo lettere, numeri, . _ -"
  local dir=$OUTDIR/$label
  [[ ! -e $dir ]] || die "la fotografia '$label' esiste già ($dir)"
  mkdir -p -- "$dir"
  SNAP_IN_PROGRESS=$dir
  echo "Fotografia '$label' ($ENGINE) in corso..."
  "snapshot_$ENGINE" "$dir"
  rm -f -- "$dir/.dblist" "$dir/.dbsize" "$dir/.oidmap"
  SNAP_IN_PROGRESS=""
  echo "Salvata in $dir ($(wc -l < "$dir/tables.tsv") tabelle)"
  print_fs "$dir"
  top_section "$dir/databases.tsv" 1 5 "Database più grandi"
}

cmd_report() {
  local label=${1:-}
  [[ -n $label ]] || die "uso: report <etichetta>"
  local d=$OUTDIR/$label
  [[ -f $d/meta.txt ]] || die "fotografia '$label' non trovata in $OUTDIR"
  echo "Fotografia '$label' del $(meta_get "$d" timestamp) - $(meta_get "$d" engine) $(meta_get "$d" version) su $(meta_get "$d" host)"
  print_fs "$d"
  top_section "$d/databases.tsv" 1 5   "Database più grandi (dati + indici)"
  top_section "$d/tables.tsv"    2 4,5 "Tabelle più grandi (dati + indici)"
  top_section "$d/tables.tsv"    2 6   "Tabelle con più spazio recuperabile (data_free / tuple morte stimate)"
  top_section "$d/disk.tsv"      1 2   "Voci più grandi nella data directory"
}

cmd_compare() {
  local a=${1:-} b=${2:-}
  [[ -n $a && -n $b ]] || die "uso: compare <etichetta_prima> <etichetta_dopo>"
  [[ $a != "$b" ]] || die "le due etichette sono uguali"
  local da=$OUTDIR/$a db=$OUTDIR/$b
  [[ -f $da/meta.txt ]] || die "fotografia '$a' non trovata in $OUTDIR"
  [[ -f $db/meta.txt ]] || die "fotografia '$b' non trovata in $OUTDIR"
  [[ $(meta_get "$da" engine) == "$(meta_get "$db" engine)" ]] || warn "le due fotografie sono di motori diversi"

  echo "Confronto '$a' ($(meta_get "$da" timestamp))  ->  '$b' ($(meta_get "$db" timestamp))"
  local ua ub m
  ua=$(meta_get "$da" fs_used); ub=$(meta_get "$db" fs_used); m=$(meta_get "$db" fs_mount)
  if [[ -n $ua && -n $ub ]]; then
    awk -v a="$ua" -v b="$ub" -v m="$m" "$AWK_LIB"'
      BEGIN { printf "Filesystem %s: usato %s -> %s (%s)\n", m, h(a), h(b), hs(b - a) }'
  fi

  compare_section "$da/databases.tsv" "$db/databases.tsv" 1 5   "Database - dimensione totale"
  compare_section "$da/databases.tsv" "$db/databases.tsv" 1 4   "Database - spazio libero/recuperabile"
  compare_section "$da/tables.tsv"    "$db/tables.tsv"    2 4,5 "Tabelle - dimensione (dati + indici)"
  compare_section "$da/disk.tsv"      "$db/disk.tsv"      1 2   "File nella data directory (cartelle DB, ibdata1, binlog, undo, WAL)"

  cat <<'EOF'

Come leggere il risultato:
  - In cima a ogni sezione ci sono le voci cambiate di più: un database o una
    tabella che dopo l'ottimizzazione non cala, o addirittura cresce, è il
    primo sospetto.
  - Se le tabelle calano ma il filesystem no, lo spazio sta altrove: guarda la
    sezione "File nella data directory" (binlog, ibdata1, undo, pg_wal).
  - MySQL/MariaDB: ibdata1 non si restringe mai, nemmeno con OPTIMIZE; con
    innodb_file_per_table=OFF il data_free è condiviso e poco indicativo.
  - PostgreSQL: VACUUM semplice non restituisce spazio al disco, serve
    VACUUM FULL (o pg_repack); lo spazio "recuperabile" è una stima.
EOF
}

cmd_list() {
  if [[ ! -d $OUTDIR ]]; then echo "Nessuna fotografia in $OUTDIR"; return 0; fi
  local d found=0
  for d in "$OUTDIR"/*/; do
    [[ -f $d/meta.txt ]] || continue
    found=1
    printf '%-24s %s  %-8s  %s\n' "$(basename "$d")" "$(meta_get "$d" timestamp)" \
      "$(meta_get "$d" engine)" "$(meta_get "$d" host)"
  done
  [[ $found -eq 1 ]] || echo "Nessuna fotografia in $OUTDIR"
}

cmd=${1:-}
shift || true
case $cmd in
  snapshot) cmd_snapshot "$@" ;;
  compare)  cmd_compare "$@" ;;
  report)   cmd_report "$@" ;;
  list)     cmd_list ;;
  ""|help)  usage 0 ;;
  *)        die "comando sconosciuto: '$cmd' (usa snapshot, compare, report, list)" ;;
esac

Notes finales

• Le script est en lecture seule sur les bases : il n’exécute que SELECT sur les métadonnées. Il n’écrit que dans le dossier des instantanés.
• Sur MySQL 8, il définit information_schema_stats_expiry = 0 dans la session. Sinon, les statistiques en cache (jusqu’à 24 heures) pourraient afficher d’« anciennes » valeurs même après l’optimisation.
• Si un instantané échoue à mi-parcours, il est supprimé automatiquement pour ne pas laisser de données incomplètes.
• Avant de l’utiliser en production, essayez-le dans un environnement de test et vérifiez les droits de l’utilisateur de la base.

Si MySQL ne démarre plus après une mise à jour, voyez l’article sur Debian 12.

Si vous l’utilisez pour surveiller l’espace disque et trouvez un cas qu’il ne couvre pas, écrivez-moi dans les commentaires. Vos idées pour l’étendre sont aussi bienvenues (autres moteurs, export CSV, alertes par e-mail).

The post Quelle base de données occupe l’espace disque ? Un script pour MySQL et PostgreSQL first appeared on Matteo Cisilino.

Nous avions besoin d’une base MySQL 5.7 dans Docker. Le serveur, lui, tourne pour le reste avec une distribution récente. Certaines applications héritées ne sont pas compatibles avec MySQL 8. Les raisons : changement du plugin d’authentification par défaut, modes SQL plus stricts, nouveaux mots réservés. Les migrer rapidement n’était pas envisageable.

Installer une version aussi ancienne directement sur l’hôte pose plusieurs problèmes. Les dépôts officiels des distributions actuelles ne la proposent plus. Les paquets tiers risquent d’entrer en conflit avec le reste du système. Une mise à jour de l’OS pourrait la casser.

Nous avons donc décidé de l’isoler dans un conteneur Docker. L’hôte reste propre et à jour. La version de la base est figée et reproductible. Données et configuration se trouvent dans un dossier facile à sauvegarder et à déplacer.

Cet article raconte comment nous l’avons configurée et, surtout, les obstacles rencontrés en chemin. Il y a l’exposition involontaire du port 3306 et une erreur iptables au redémarrage. Il y a aussi l’écriture d’un pare-feu avec nftables qui ne laisse passer que les IP autorisées.

Note : MySQL 5.7 a atteint sa fin de vie (EOL) en octobre 2023. Il ne reçoit plus de correctifs de sécurité. C’est une solution de transition : l’objectif reste de migrer vers MySQL 8.x ou MariaDB. C’est précisément pour cela qu’il est encore plus important de ne pas la laisser exposée.

1. Structure du dossier

/opt/mysql57/
├── docker-compose.yml
├── .env
├── conf.d/        # configurazioni personalizzate (my.cnf aggiuntivi)
├── data/          # dati del database (volume persistente)
└── logs/

Le fichier .env contient les identifiants, afin qu’ils ne se retrouvent pas dans le compose. Voici son contenu :

TZ=Europe/Rome
MYSQL_ROOT_PASSWORD=una_password_molto_lunga_e_casuale
MYSQL_DATABASE=nome_db
MYSQL_USER=nome_utente
MYSQL_PASSWORD=altra_password_robusta

Protégez-le avec chmod 600 .env.

2. Le docker-compose.yml

services:
  mysql57:
    image: mysql:5.7
    container_name: mysql57
    restart: unless-stopped
    env_file:
      - .env
    ports:
      - "3306:3306"
    environment:
      TZ: "${TZ:-Europe/Rome}"
      MYSQL_ROOT_PASSWORD: "${MYSQL_ROOT_PASSWORD}"
      MYSQL_DATABASE: "${MYSQL_DATABASE}"
      MYSQL_USER: "${MYSQL_USER}"
      MYSQL_PASSWORD: "${MYSQL_PASSWORD}"
    command:
      - --default-authentication-plugin=mysql_native_password
    volumes:
      - ./data:/var/lib/mysql
      - ./conf.d:/etc/mysql/conf.d:ro
      - ./logs:/var/log/mysql
    healthcheck:
      test: ["CMD-SHELL", "mysqladmin ping -h 127.0.0.1 -uroot -p$$MYSQL_ROOT_PASSWORD --silent"]
      interval: 20s
      timeout: 5s
      retries: 10
      start_period: 45s
    ulimits:
      nofile:
        soft: 65535
        hard: 65535

Quelques choix à noter :

• restart: unless-stopped : la base redémarre toute seule après un redémarrage du serveur.
• Volumes en bind mount : données, configuration et logs sont sur l’hôte. Sauvegardes et migrations se résument donc à des copies de dossiers.
• Healthcheck : permet aux autres services d’attendre que MySQL soit vraiment prêt. Le $$ sert à faire développer la variable dans le conteneur et non par Compose.
• ulimits nofile : évite l’erreur « too many open files » sous charge.

3. Premier problème : MySQL 5.7 dans Docker exposé

La ligne - "3306:3306" équivaut à 0.0.0.0:3306:3306. Docker publie le port sur toutes les interfaces de l’hôte, y compris la publique.

Le plus insidieux : Docker écrit ses propres règles directement dans le pare-feu du noyau. Elles sont évaluées avant celles d’UFW ou de firewalld. Avoir un pare-feu actif ne suffit pas : le port reste joignable.

Voici les solutions possibles.

1. Localhost uniquement : "127.0.0.1:3306:3306", si la base ne sert qu’à l’hôte ou via un tunnel SSH.
2. Aucun port publié : si les clients sont d’autres conteneurs, un réseau Docker partagé suffit.
3. IP précise : publier uniquement sur une adresse d’un réseau privé/VPN.
4. Port public avec filtrage par IP : notre cas. Un client externe (une instance phpMyAdmin sur un autre serveur) doit pouvoir se connecter.

Pour le cas 4, il faut un pare-feu qui filtre correctement le trafic des ports publiés par Docker. La documentation de Docker sur le filtrage des paquets explique comment Docker interagit avec les règles de l’hôte.

4. Deuxième problème : erreur iptables au démarrage

Après avoir touché au pare-feu, docker compose up a renvoyé cette erreur.

failed to create network mysql57_default: Error response from daemon:
Failed to Setup IP tables: Unable to enable ACCEPT OUTGOING rule:
(iptables failed: iptables --wait -t filter -A DOCKER-FORWARD -i br-... -j ACCEPT:
iptables: No chain/target/match by that name.

L’erreur ne dépend pas du compose. La chaîne DOCKER-FORWARD (introduite dans les versions récentes de Docker) n’existait plus. Elle avait été supprimée par quelque chose qui avait nettoyé les règles après le démarrage du démon. Un redémarrage de Docker (systemctl restart docker) la recrée. Mais le problème revient tant que le vrai coupable n’est pas éliminé.

Le coupable : flush ruleset

Notre /etc/nftables.conf commençait par cette ligne.

flush ruleset

Cette commande supprime toutes les tables nftables, y compris celles créées par Docker. De plus, le fichier contenait une copie statique des règles de Docker. Le nom du bridge (br-278550235c3f) et l’IP du conteneur (172.18.0.2) y étaient écrits à la main. Or le nom du bridge change chaque fois que le réseau Compose est recréé. La copie devenait aussitôt obsolète. La table ip nat entrait en conflit avec celle gérée par Docker.

Règle d’or : avec Docker, dans le fichier nftables on n’utilise pas flush ruleset. On ne copie pas ses règles. On ne gère que son propre pare-feu, dans des tables dédiées.

5. Le pare-feu avec nftables

Le principe est le suivant pour MySQL 5.7 dans Docker. Les ports publiés par Docker sont réécrits par DNAT, puis transférés par l’hôte vers le conteneur. Ils traversent donc la chaîne forward, pas input. Une règle drop dans une chaîne à nous, forward, rejette le paquet. Sa priorité est légèrement plus basse, donc elle est évaluée avant. Les règles accept de Docker n’y changent rien.

Pour ne pas toucher aux tables des autres, nous utilisons le motif table ... + delete table ... : il rend le fichier ré-exécutable sans erreur et sans flush.

/etc/nftables.conf:

#!/usr/sbin/nft -f

# NIENTE "flush ruleset": cancellerebbe anche le tabelle di Docker

# ---------------- firewall host ----------------
table inet filter
delete table inet filter

table inet filter {

    chain input {
        type filter hook input priority filter; policy drop;
        ct state established,related accept
        iifname "lo" accept
        ip6 nexthdr icmpv6 accept
        iifname "enp7s0" accept                       # rete privata
        ip saddr 203.0.113.20 tcp dport 22 accept     # SSH da host fidato
        ip saddr 203.0.113.30 tcp dport 22 accept     # SSH da VPN
        ip saddr 203.0.113.20 icmp type echo-request accept
        tcp dport { 80, 443 } accept
    }

    chain output {
        type filter hook output priority filter; policy accept;
    }
}

# ---------------- guardia MySQL (porta pubblicata da Docker) ----------------
table ip mysql_guard
delete table ip mysql_guard

table ip mysql_guard {
    set allowed {
        type ipv4_addr
        flags interval
        elements = {
            203.0.113.10        # phpMyAdmin
        }
    }

    chain forward {
        type filter hook forward priority filter - 5; policy accept;
        iifname "enp7s0" accept
        ct status dnat tcp dport 3306 ip saddr @allowed accept
        ct status dnat tcp dport 3306 counter drop
    }
}

Voici comment fonctionne la garde.

• ct status dnat ne sélectionne que les paquets passés par le DNAT, c’est-à-dire ceux destinés aux ports publiés par Docker.
• La première règle accepte ceux qui sont dans l’ensemble allowed. La seconde rejette tous les autres et les compte (counter).
• Le trafic local (127.0.0.1) et celui entre conteneurs du même réseau ne passent pas par le forward. Ils ne sont donc pas touchés.

Compatibilité : dans une première version, nous utilisions ct original proto-dst 3306. Mais certaines versions de nft répondent par « Can’t parse symbolic invalid expressions ». Dans le hook forward, le DNAT a déjà eu lieu. Le port du conteneur coïncide avec le port publié (3306:3306). L’expression tcp dport 3306 combinée à ct status dnat est donc équivalente et fonctionne partout. Si vous changez le mapping (par exemple 3307:3306), la règle doit être adaptée au port interne.

Appliquer les modifications sans se verrouiller dehors

Gardez une session SSH de secours ouverte. Puis lancez les commandes suivantes.

nft -c -f /etc/nftables.conf     # solo verifica della sintassi
nft delete table ip nat          # una tantum: elimina la vecchia copia statica
nft -f /etc/nftables.conf
systemctl restart docker         # Docker ricrea le sue tabelle pulite
cd /opt/mysql57 && docker compose up -d

Pour le chargement au démarrage, assurez-vous que le service est activé (systemctl enable --now nftables). Vérifiez aussi que /etc/nftables.conf ne contient pas flush ruleset.

Gérer les IP à l’exécution

nft add element ip mysql_guard allowed { 203.0.113.50 }
nft delete element ip mysql_guard allowed { 203.0.113.50 }

Pour le rendre permanent, mettez aussi à jour l’ensemble dans le fichier.

6. Vérification

Depuis le serveur autorisé, testez.

nc -zv IP_PUBBLICO_DB 3306        # deve rispondere "succeeded"

Depuis une autre IP, testez à nouveau.

nmap -Pn -p 3306 IP_PUBBLICO_DB   # deve risultare "filtered" / timeout

Sur le serveur, le compteur de la règle de rejet doit augmenter à chaque tentative non autorisée.

nft list chain ip mysql_guard forward
ss -tlnp | grep 3306

7. Seconde barrière : les utilisateurs MySQL

Le pare-feu ne remplace pas les droits de la base de données. Créez l’utilisateur avec un hôte limité à l’IP du client.

CREATE USER 'pma_user'@'203.0.113.10' IDENTIFIED BY 'password_robusta';
GRANT ALL ON nome_db.* TO 'pma_user'@'203.0.113.10';
FLUSH PRIVILEGES;

Si la connexion TCP aboutit mais que MySQL répond Access denied, le problème est ici. Il n’est pas dans le pare-feu.

8. À retenir

• Docker et le pare-feu de l’hôte ne s’ignorent pas. Comprendre quelle chaîne le trafic traverse (input ou forward) est la clé de tout.
• Jamais flush ruleset sur un hôte avec Docker ; utilisez des tables dédiées.
• Ne copiez pas les règles générées par Docker dans vos fichiers : noms de bridge et IP changent.
• Si vous avez déjà exposé le port, vérifiez les logs dans ./logs. Envisagez aussi de changer les mots de passe, surtout celui de root.
• Quand c’est possible, préférez un VPN (WireGuard) ou un tunnel SSH à l’exposition publique d’une base de données.
• Planifiez la migration de MySQL 5.7 vers une version prise en charge.

Si MySQL refuse de redémarrer après une mise à jour, voyez aussi MySQL qui ne démarre plus sous Debian 12.

Vous avez des questions ou une solution différente pour MySQL 5.7 dans Docker ? Écrivez-le dans les commentaires.

The post MySQL 5.7 dans Docker protégé par nftables first appeared on Matteo Cisilino.

Sous Debian 12, MySQL ne démarre plus. Le service apparaît en échec et le log signale l’erreur Can't read dir of '/etc/mysql/mariadb.conf.d/'.

Voici la sortie complète :

# service mysql status
× mysql.service - MySQL Community Server
     Loaded: loaded (/lib/systemd/system/mysql.service; enabled; preset: enabled)
     Active: failed (Result: exit-code)
     Status: "Server startup in progress"

mysqld: Can't read dir of '/etc/mysql/mariadb.conf.d/' (OS errno 2 - No such file or directory)
mysqld: [ERROR] Stopped processing the 'includedir' directive in file /etc/mysql/my.cnf at line 29.
mysqld: [ERROR] Fatal error in defaults handling. Program aborted!
systemd[1]: Failed to start mysql.service - MySQL Community Server.

En vérifiant les paquets installés, MySQL est bien présent (paquets mysql-community-server 8.0 du dépôt officiel Oracle) :

dpkg -l | grep mysql

La cause : l’alternative my.cnf pointe vers mariadb.cnf

Sous Debian, le fichier /etc/mysql/my.cnf n’est pas un vrai fichier. C’est un lien géré par update-alternatives. Plusieurs paquets peuvent enregistrer leur propre version. En mode automatique, celle qui a la priorité la plus haute l’emporte.

Pendant la mise à jour, le paquet mariadb-common a été installé (puis retiré). Il enregistre /etc/mysql/mariadb.cnf avec une priorité de 500, supérieure à celle de /etc/mysql/mysql.cnf (priorité 300). Le paquet a été retiré mais pas entièrement purgé (état rc). Sa configuration est donc restée active. À la ligne 29 de ce fichier se trouve l’inclusion de /etc/mysql/mariadb.conf.d/, un répertoire qui n’existe pas. MySQL lit la configuration, ne trouve pas le répertoire et s’arrête.

Bonne nouvelle : les données dans /var/lib/mysql n’ont pas été touchées. Ce n’est qu’un problème de configuration.

Diagnostic : vérifier vers où pointe my.cnf

ls -l /etc/mysql/my.cnf /etc/alternatives/my.cnf
update-alternatives --display my.cnf
sed -n '25,32p' /etc/mysql/my.cnf
dpkg -l | grep -i mariadb

Si le problème est bien celui-ci, la sortie ressemblera à ceci :

/etc/alternatives/my.cnf -> /etc/mysql/mariadb.cnf
/etc/mysql/my.cnf -> /etc/alternatives/my.cnf

my.cnf - modalità automatica
  la versione migliore del collegamento è /etc/mysql/mariadb.cnf
  il collegamento attualmente punta a /etc/mysql/mariadb.cnf
/etc/mysql/mariadb.cnf - priorità 500
/etc/mysql/my.cnf.fallback - priorità 100
/etc/mysql/mysql.cnf - priorità 300

!includedir /etc/mysql/conf.d/
!includedir /etc/mysql/mariadb.conf.d/

rc  mariadb-common   1:10.11.18-0+deb12u1   all   MariaDB common configuration files

Solution pas à pas

1. Sauvegarder la configuration

cp -a /etc/mysql /root/etc-mysql-backup-$(date +%F)

2. Supprimer les résidus de mariadb-common

La purge supprime mariadb.cnf et son entrée dans update-alternatives :

apt purge mariadb-common

3. Repointer my.cnf vers mysql.cnf

update-alternatives --remove my.cnf /etc/mysql/mariadb.cnf 2>/dev/null
update-alternatives --set my.cnf /etc/mysql/mysql.cnf

4. Vérifier la configuration

update-alternatives --display my.cnf
cat /etc/mysql/my.cnf
my_print_defaults mysqld

Désormais my.cnf doit pointer vers /etc/mysql/mysql.cnf et inclure /etc/mysql/conf.d/ et /etc/mysql/mysql.conf.d/. Si my_print_defaults mysqld affiche les paramètres sans erreur, la configuration est correcte.

5. Démarrer MySQL

systemctl start mysql
systemctl status mysql
journalctl -u mysql -n 50 --no-pager

Si my.cnf n’est pas un lien symbolique

Si /etc/mysql/my.cnf est un fichier normal ou si /etc/mysql/mysql.cnf n’existe pas, on peut recréer la configuration à la main :

mv /etc/mysql/my.cnf /etc/mysql/my.cnf.mariadb.bak
cat > /etc/mysql/my.cnf <<'EOF'
!includedir /etc/mysql/conf.d/
!includedir /etc/mysql/mysql.conf.d/
EOF
mkdir -p /etc/mysql/conf.d
systemctl start mysql

Solution rapide quand MySQL ne démarre plus

S’il faut remettre la base en ligne tout de suite, créez le dossier manquant. Ce n’est toutefois qu’un pis-aller. MySQL continuerait à lire la configuration prévue pour MariaDB. Il vaut donc mieux appliquer la solution complète dès que possible.

mkdir /etc/mysql/mariadb.conf.d && systemctl start mysql

Comment éviter que cela se reproduise

Il est utile de comprendre quelle mise à jour a installé MariaDB, en consultant l’historique d’apt :

grep -i -B3 -A3 mariadb /var/log/apt/history.log*

Pour empêcher mariadb-common d’être réinstallé à l’avenir, on peut le bloquer avec un pin APT à priorité négative :

cat > /etc/apt/preferences.d/no-mariadb <<'EOF'
Package: mariadb-*
Pin: release *
Pin-Priority: -1
EOF

Après chaque mise à jour importante, c’est aussi une bonne habitude de vérifier l’état de l’alternative avec update-alternatives --display my.cnf.

Les notes de version de Debian 12 décrivent les changements de cette version.

Un autre piège de configuration à connaître : MySQL 5.7 dans Docker et le port 3306 exposé.

Questions fréquentes

Vais-je perdre les données de mes bases ?

Non. Le problème ne concerne que les fichiers de configuration dans /etc/mysql ; les données dans /var/lib/mysql restent intactes.

Pourquoi Debian a-t-il choisi mariadb.cnf ?

Parce que l’alternative my.cnf était en mode automatique et que mariadb.cnf a une priorité de 500, supérieure aux 300 de mysql.cnf. Avec update-alternatives --set, le choix devient manuel et ne change plus tout seul.

Cela vaut-il aussi pour Ubuntu ?

Oui, le mécanisme de update-alternatives pour my.cnf est le même sur Ubuntu et sur les autres distributions dérivées de Debian.

Conclusion

L’erreur « Can’t read dir of /etc/mysql/mariadb.conf.d/ » n’indique pas que MySQL est endommagé. Quand MySQL ne démarre plus, le coupable est une configuration résiduelle de MariaDB. Elle est restée active via update-alternatives. En supprimant mariadb-common avec apt purge et en remettant my.cnf sur mysql.cnf, MySQL refonctionne normalement.

The post MySQL ne démarre plus après la mise à jour vers Debian 12 : cause et solution first appeared on Matteo Cisilino.