L’expéditeur utilise un nom générique. Rien de suspect à première vue. L’objet est anodin : « Disponibilité chambre du 10 au 12 novembre ». Le texte est en français assez naturel. Il a quelques petites imperfections, le genre qu’un locuteur natif remarquerait, mais rien qui déclenche une alarme immédiate. La personne qui écrit dit vouloir réserver. Elle demande une confirmation de disponibilité. Puis elle ajoute un détail qui semble anodin : elle déclare avoir joint une copie de son passeport, « pour faciliter la réservation ». Il y a aussi un petit détail temporel : elle sera en voyage à partir du 9, donc elle préférerait avoir déjà tout confirmé à l’avance.

Cette phrase, « je serai en voyage », est un levier psychologique précis. Ce n’est pas une urgence agressive. On ne demande pas d’argent tout de suite. Elle crée juste une raison plausible de se dépêcher, de répondre avant d’y réfléchir trop longtemps. J’ai vu la capture d’écran de cet e-mail, avec le lien flouté pour des raisons de sécurité. Je la trouve presque un exemple de manuel de la façon dont on construit une tentative de phishing hôtelier efficace : aimable, crédible, avec une pointe d’urgence calculée.

Comment fonctionne le phishing hôtelier en deux étapes

Le mécanisme comporte deux phases distinctes. Elles valent la peine d’être comprises toutes les deux, car de l’extérieur elles semblent banales, et pourtant elles fonctionnent. La première phase, c’est l’e-mail. Il contient un lien raccourci, du genre qui passe par un redirecteur : un service qui cache la vraie destination derrière une adresse courte. En cliquant, on ne voit pas tout de suite où l’on va atterrir. C’est déjà la première tromperie, petite mais efficace.

La seconde phase, c’est la page de destination. C’est un écran qui se fait passer pour une procédure de confirmation ou de paiement. Visuellement, il rappelle celui d’une vraie plateforme, parfois assez bien pour tromper même quelqu’un qui travaille dans le secteur depuis des années. C’est là que le vrai dommage se produit. Le gestionnaire de l’établissement, convaincu de devoir vérifier la disponibilité ou confirmer la réservation, saisit ses propres identifiants. Il peut s’agir de ceux de l’extranet de Booking ou d’Airbnb. Ou bien de ceux de sa propre boîte mail, ou du panneau de gestion du site. À partir de ce moment, les identifiants sont déjà dans les mains de celui qui a envoyé l’e-mail. Le reste, aux yeux de la victime, se passe après, quand il est trop tard pour faire machine arrière.

Pourquoi un gestionnaire d’établissement est une cible facile

Qui travaille dans un établissement touristique reçoit des dizaines de demandes similaires chaque semaine. Des e-mails de clients, des questions sur la disponibilité, des demandes de confirmation de dernière minute. C’est un flux constant, souvent géré à la hâte, entre un check-in et l’autre. Un message de plus, poli et plausible, se fond bien dans ce flux. Il ne se détache pas. Le point faible n’est pas la technologie du gestionnaire. C’est son temps limité, et l’habitude de répondre vite à quelqu’un qui ressemble à un vrai client. C’est pour ça que le phishing hôtelier fonctionne si bien : il ne vise pas un système informatique, il vise une personne occupée.

Les signaux d’alerte à reconnaître

Il y a des signaux concrets. Aucun ne suffit seul à prouver une arnaque, mais ensemble ils racontent une histoire claire. Le contact arrive par e-mail direct, pas par le canal officiel de la plateforme : Booking et Airbnb ont des systèmes de messagerie interne, et un vrai client les utilise presque toujours. Le lien est raccourci ou masqué, donc on ne comprend pas où il mène en lisant seulement l’adresse. Le message demande de « vérifier la disponibilité » en cliquant sur un lien, au lieu de laisser le gestionnaire vérifier depuis son propre panneau, en tapant l’adresse à la main comme il le ferait toujours. Le ton est aimable, presque prévenant. L’urgence est mesurée : elle n’effraie pas, mais elle pousse quand même à agir vite, avant d’y réfléchir.

Pourquoi je l’ai classé dans « Entre la chaise et le clavier »

J’ai ouvert cette catégorie sur le site exprès pour des cas comme celui-ci. « Entre la chaise et le clavier » est une blague que connaissent bien ceux qui travaillent en sécurité informatique. Elle désigne l’endroit exact où se produit presque toujours le dommage : la personne devant l’écran, pas le logiciel. La plateforme de réservation n’a aucune responsabilité dans cet épisode précis. Le problème n’est pas un bug de Booking ou d’Airbnb. C’est le moment où un humain, peut-être pressé, clique sur un lien qu’il n’aurait pas dû cliquer. Le comprendre aide à mieux se défendre. Un antivirus ne suffit pas. Il faut l’habitude de s’arrêter une seconde avant de cliquer, chaque fois.

Si les identifiants finissent malgré tout entre de mauvaises mains, il faut évaluer s’il faut les changer tout de suite, partout où ils sont utilisés. J’en ai parlé en racontant la rotation des identifiants de base de données après une faille. Le contexte technique est différent, mais le principe reste le même.

Comment protéger son établissement

La première règle est simple, mais il faut la répéter souvent : ne jamais saisir ses identifiants en cliquant sur un lien reçu par e-mail, même s’il paraît urgent. Si quelqu’un écrit en disant vouloir réserver, on vérifie depuis son propre panneau. On tape l’adresse à la main, on ne suit pas un lien envoyé par un inconnu. La deuxième règle concerne l’authentification à deux facteurs. Il faut l’activer sur chaque compte qui compte : extranet de la plateforme, boîte mail, panneau du site. Même si les identifiants sont volés, un second facteur bloque quand même l’accès, dans la plupart des cas. La troisième règle, c’est le signalement. Chaque message suspect doit être signalé à la plateforme, qui utilise ces données pour bloquer d’autres tentatives similaires. Ce n’est pas un hasard si la gestion de ces épisodes est l’une des raisons de l’enquête européenne. Le problème du phishing hôtelier concerne aussi les plateformes, pas seulement les gestionnaires individuels.

Pour suivre les développements, on peut lire le récit de l’agence italienne AGI sur l’enquête de la Commission contre Booking.com. Il résume bien ce qui se passe. Et pourquoi cela concerne aussi les petits établissements, pas seulement les grandes chaînes.

Si vous avez déjà cliqué ou saisi des données

Si c’est déjà arrivé, il vaut mieux agir vite. Changez immédiatement le mot de passe du compte concerné. Changez-le aussi partout où le même mot de passe a été réutilisé : c’est une erreur courante, et ceux qui volent des identifiants le savent bien. Activez la vérification en deux étapes, si vous ne l’aviez pas déjà fait. Vérifiez l’historique des connexions du compte. Cherchez des sessions ou des appareils que vous ne reconnaissez pas. Prévenez la plateforme, qui a des procédures dédiées aux comptes compromis. Si vous aviez joint de vrais documents dans l’e-mail, surveillez-les : une pièce d’identité volée peut être réutilisée ailleurs, pas seulement pour d’autres arnaques liées au secteur hôtelier.

Le cas que j’ai vu n’a pas fait de dégâts. La personne qui l’a reçu s’est arrêtée un instant avant de cliquer, et me l’a signalé. Ça a suffi. La technologie aide, les filtres anti-spam aident, mais au final, c’est toujours la personne qui décide de cliquer ou non qui fait la différence. Le problème du phishing hôtelier, presque toujours, reste entre la chaise et le clavier.

The post Phishing hôtelier : l’e-mail piège que j’ai vue arriver chez un gestionnaire d’établissement first appeared on Matteo Cisilino.

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.

Où se trouve

Ouvre l’entrée Extensions > Extensions installées (point 1 de l’image). Sur la ligne de Cisilino Site Defense Network (point 3), tu trouves le lien Désactiver. Après la désactivation (point 4), la même ligne montre Activer et Supprimer.

Ce qui se passe à la désactivation

Désactiver le plugin l’arrête sans toucher aux données. À la désactivation, le plugin fait quatre choses.

1. il enregistre l’événement « Plugin désactivé sur ce site » et essaie de le livrer au panneau, s’il est configuré.
2. il annule les trois tâches planifiées.
3. il vide les deux blocs de .htaccess, celui des IP bloquées et celui du durcissement.
4. il met à jour les règles de réécriture de WordPress.

Attention : une fois désactivé, aucune règle ne reste en vigueur. Les IP bloquées retrouvent l’accès et le durcissement n’est plus appliqué. Le plugin n’est même plus chargé, donc les autres protections n’agissent plus non plus. Les en-têtes de sécurité s’arrêtent aussi, mais un navigateur qui a déjà reçu HSTS s’en souvient pendant le temps réglé.

La base de données reste intacte. Si tu réactives le plugin, les blocs de .htaccess sont reconstruits et tu retrouves les réglages comme tu les avais laissés.

Comment désinstaller le plugin

Pour désinstaller le plugin, tu dois cliquer sur Supprimer dans Extensions installées, après l’avoir désactivé. Avant de le faire, suis ces étapes.

1. Dans l’onglet Journal d’activité, vérifie que la ligne « en attente d’envoi au panneau » est à zéro, si tu utilises le panneau.
2. Dans l’onglet Journal de débogage, télécharge les fichiers dont tu as besoin. Puis, si tu veux, clique sur Supprimer tous les fichiers.
3. Fais une sauvegarde, si tu ne l’as pas déjà faite.
4. Désactive le plugin et clique sur Supprimer.

Ce qui est retiré et ce qui reste

Quand tu choisis de désinstaller le plugin, il enregistre d’abord « Plugin désinstallé de ce site : données locales retirées » et essaie de le livrer au panneau. Puis il supprime, quel que soit le résultat de la livraison.

Est retiré ce qui suit.

• les quatre tables csdn_events, csdn_overrides, csdn_rate_hits et csdn_activity.
• presque toutes les options dont le nom commence par csdn_, y compris les identifiants du panneau, la liste blanche et les réglages des onglets. Il en reste trois, listées plus bas.
• la donnée de suspension de la limitation de débit sur tous les utilisateurs.
• les données temporaires du plugin.
• les règles des deux blocs du plugin dans .htaccess et les règles de réécriture. Les marqueurs # BEGIN et # END restent dans le fichier, vides.

Reste en revanche ce qui suit.

• les fichiers du journal de débogage dans le dossier csdn-debug-* à l’intérieur de uploads, car ce sont tes propres données : supprime-les à la main ou avec le bouton Supprimer tous les fichiers avant de désinstaller.
• l’historique déjà livré au panneau, qui se trouve sur le panneau et non sur ton site.
• les lignes de .htaccess qui se trouvent hors des marqueurs du plugin.
• trois options mineures : csdn_registration_lock (la politique d’Inscription des utilisateurs), csdn_remote_ban_reasons (motifs des blocages reçus) et csdn_trigger_token (jeton reçu du panneau). Restent aussi la donnée utilisateur csdn_registration_blocked_at, si présente, et les données temporaires csdn_rl_block_*, qui expirent seules. On peut les retirer à la main de la base de données.

Attention : désinstaller le plugin supprime aussi le journal d’activité local. Les lignes pas encore livrées au panneau, si le panneau ne répond pas, sont perdues.

Données personnelles traitées par le plugin

Le plugin garde les données sur ton site, dans la base de données. Jamais le mot de passe. Voici ce qu’il traite.

• Échecs de connexion : adresse IP, nom d’utilisateur essayé, nombre de tentatives, première et dernière occurrence, état de blocage. Il n’y a pas de suppression automatique : ils restent dans la base de données jusqu’à ce que tu désinstalles le plugin.
• Journal d’activité : date et heure, utilisateur WordPress (id, identifiant, rôle), IP, type d’action, objet concerné (pour les contenus, le titre) et une brève description. Dans certains cas, il ajoute des détails : pour un nouvel utilisateur l’email et les rôles, pour une modification de profil la valeur précédente et la nouvelle de l’email, de l’identifiant, du nom affiché et du site web. Il n’enregistre pas le contenu des articles, des commentaires ou des fichiers. Pour les options avec un nom suspect, comme des clés ou des jetons, il enregistre seulement qu’elles ont changé.
• Limitation de débit : IP et type d’envoi des invités, conservés un jour. Les suspensions des auteurs se trouvent dans les données de l’utilisateur.
• Dérogations IP, liste blanche et liste noire reçue.
• Journal de débogage, si tu l’actives : des fichiers qui peuvent contenir des chemins et des fragments de données.

Le journal local garde par défaut 30 jours et au maximum 500 lignes. Tu peux changer les deux valeurs dans l’onglet Journal d’activité.

Ce qui sort du site

Seulement si tu connectes le panneau. Toutes les 15 minutes, le plugin envoie les échecs de connexion : IP, nom d’utilisateur, résultat « failed » et date. Il en envoie jusqu’à 200 par fois. Il ajoute le customer code et l’URL du site. Il reçoit les IP bloquées. Le journal d’activité, avec les détails ci-dessus, est envoyé en général immédiatement, en fin de requête, et ce qui reste en file d’attente part avec le tour des 15 minutes. Il part seulement si le journal et l’option « Envoyer les activités au panneau » sont actifs tous les deux. Les dérogations manuelles ne sont jamais envoyées.

Que mettre dans la politique de confidentialité

Tant que tu ne décides pas de désinstaller le plugin, indique dans la politique du site au moins ces points.

• que le site enregistre l’IP et le nom d’utilisateur des tentatives de connexion échouées, pour des raisons de sécurité.
• qu’il tient un journal des actions des utilisateurs, avec l’IP, et pendant combien de jours il le conserve.
• que, si tu as connecté le panneau, certaines de ces données sont envoyées au service externe.
• qui est le responsable du traitement et comment les utilisateurs peuvent exercer leurs droits.

Adapte le texte à ta situation, avec ton conseiller si tu en as un : le manuel ne remplace pas un avis juridique. Pour les bases sur les plugins, le guide officiel de WordPress explique aussi la différence entre désactiver et supprimer.

Si quelque chose ne va pas

Si après la désactivation le site donne une erreur, vérifie .htaccess par FTP et regarde le chapitre Résolution des problèmes et questions fréquentes. Si tu as décidé de désinstaller le plugin par erreur, les données locales ne reviennent pas : il faut une sauvegarde du site.

Chapitre précédent : Résolution des problèmes et questions fréquentes. Retourne au sommaire avec l’introduction au manuel CSDN.

The post Désactivation, désinstallation et données personnelles first appeared on Matteo Cisilino.

Résolution des problèmes : par où commencer

Avant de chercher la réponse exacte, parcours cette liste de contrôle.

1. Arrives-tu encore à ouvrir wp-admin ? Si oui, presque tout se résout depuis la page Réglages du plugin.
2. Lis les avertissements en haut. Le plugin explique le résultat des actions avec des messages dans des encadrés colorés.
3. Rappelle-toi la dernière chose que tu as changée : une règle de durcissement, une politique, une limite.
4. S’il existe un bouton Vérifier maintenant, utilise-le avant de deviner au hasard.
5. Si tu n’entres plus sur le site, prépare l’accès FTP ou le gestionnaire de fichiers de l’hébergeur.

Connexions et blocages

Je me suis bloqué moi-même : que faire ?

Si tu as encore accès à WordPress, par exemple depuis ton téléphone avec le réseau mobile, ouvre l’onglet IP bloquées. Cherche ton IP et clique sur Débloquer. Si ton IP n’est pas dans la liste mais que tu es bloqué, le blocage peut venir de la liste de sécurité facultative. Va alors dans l’onglet Général, section « Dérogations locales IP ». Saisis l’IP, choisis « Débloquer toujours (unban) » et clique sur Enregistrer la dérogation. Puis, dans l’onglet Général, clique sur Ajouter à la liste blanche.

Si tu es aussi bloqué depuis le site et que tu vois une erreur 403, entre par FTP. Ouvre ensuite .htaccess. Retire la ligne avec ton IP. Ou retire tout le bloc entre # BEGIN Cisilino Site Defense Network et # END Cisilino Site Defense Network.

Attention : la modification à la main est temporaire. Le blocage sera réécrit par la même source au prochain événement. Cela peut être un échec de connexion, une synchronisation ou le tour des 15 minutes. Dès que tu es à l’intérieur, utilise Débloquer et la liste blanche.

Pourquoi la liste blanche ne m’a pas débloqué ?

La liste blanche évite seulement que les échecs de connexion soient comptés. Elle ne retire pas les blocages déjà présents. Pour retirer un blocage, il faut Débloquer, qui crée une dérogation permanente de déblocage sur ce site.

Un utilisateur légitime a été bloqué

Le compteur des tentatives est cumulatif par IP et ne se remet pas à zéro seul. Même des erreurs dispersées sur des semaines peuvent atteindre le seuil, qui est par défaut de 10. Débloque l’IP et mets-la en liste blanche. Ou augmente le seuil dans Réglages distants, où le champ est « Seuil de blocage local (tentatives échouées) ».

Le blocage d’une IP ne finit jamais

Un blocage local n’expire pas. Un blocage manuel expire selon la durée choisie, de 1 heure à 7 jours. Si tu as choisi « Permanente (jusqu’à suppression) », il n’expire pas. Un blocage reçu du panneau disparaît quand le panneau le retire de la liste. Un déblocage à durée limitée, à son expiration, remet le blocage si la source d’origine est encore là. Pour un déblocage définitif, utilise Débloquer, qui est permanent.

Derrière un proxy ou un CDN, les blocages sont étranges

Le plugin lit l’IP seulement depuis REMOTE_ADDR. Il ignore l’en-tête X-Forwarded-For, parce qu’il peut être falsifié. Regarde la phrase « Ton IP actuelle est … » sous le champ Adresse IP de l’onglet Général. Si ce n’est pas ton IP publique, le plugin voit l’adresse du proxy. Dans ce cas, évite de bloquer ou de mettre en liste blanche cette adresse. Attends d’avoir clarifié la situation avec qui gère le proxy.

Erreurs après les règles dans .htaccess

Cette partie de la résolution des problèmes concerne les règles écrites dans le fichier du serveur.

Le site donne une erreur 500 après avoir enregistré le durcissement

Le plugin ne crée pas de copie de .htaccess. Il ne contrôle pas non plus la syntaxe après l’écriture. Une erreur, ou une règle que le serveur n’accepte pas, se voit immédiatement comme une erreur 500.

1. Entre par FTP ou depuis le gestionnaire de fichiers.
2. Fais une copie de .htaccess.
3. Supprime le bloc entier. Il se trouve entre # BEGIN Cisilino Site Defense Network - Hardening et # END Cisilino Site Defense Network - Hardening.
4. Recharge le site, puis corrige les réglages dans l’onglet Durcissement / IDS.

Le bloc du durcissement n’est réécrit que dans deux cas. C’est quand tu enregistres l’onglet ou quand tu réactives le plugin, jamais par le tour des 15 minutes. Ta modification à la main reste donc en place.

J’ai écrit un chemin personnalisé et tout le site donne 403

Dans la case des chemins personnalisés, chaque ligne est un texte littéral. Il n’y a pas de jokers. La règle bloque toute adresse qui contient cette chaîne. Écrire / ou wp bloque tout, y compris wp-admin. Retire par FTP le bloc du durcissement, comme ci-dessus. Puis, dans l’onglet Durcissement / IDS, corrige ou vide la case « Chemins personnalisés à bloquer » et enregistre. Si tu ne la corriges pas, un nouvel enregistrement ou une réactivation du plugin réécrit la règle. Le site redonne alors 403.

Le message « Réglages enregistrés, mais l’écriture dans .htaccess a échoué » apparaît

Le fichier .htaccess n’est pas accessible en écriture. Vérifie les permissions. Les règles de ce bloc ne sont pas actives. Restent en revanche actifs les deux interrupteurs qui agissent en PHP, c’est-à-dire XML-RPC et ?author=N.

Le test dit que le blocage PHP dans uploads ne fonctionne pas

Dans l’onglet Test, il y a l’encadré « Vérification du blocage d’exécution PHP dans uploads ». Il signale si le fichier de test a été exécuté. Vérifie que l’hébergeur autorise .htaccess dans ce dossier et qu’il n’existe pas de bloc <Directory> plus spécifique. Sur nginx, les règles n’ont aucun effet. La règle couvre seulement le dossier uploads standard.

Un plugin ou le thème a arrêté de fonctionner

Éteins la dernière règle que tu as activée et enregistre. Les cas les plus courants sont trois. Le blocage du PHP dans uploads casse les plugins qui y écrivent des fichiers PHP. La désactivation de XML-RPC arrête des applications et des fonctions distantes. Le blocage des téléversements exécutables rejette aussi des fichiers comme .svg.

Utilisateurs, auteurs et visiteurs

Un auteur ne peut plus publier : « ton compte est suspendu »

La limitation de débit s’est déclenchée. Elle a vu trop de contenus créés en peu de temps. Par défaut la limite est de 150 contenus en 300 secondes, avec une suspension de 3600 secondes. Depuis l’onglet Limitation de débit, dans le tableau des utilisateurs suspendus, clique sur Révoquer la suspension. Sinon, attends l’expiration.

Éteindre « Limitation de débit active » ne retire pas une suspension déjà en cours. Avant une grande importation, augmente la limite N ou désactive le garde-fou.

Un visiteur voit « Trop d’envois »

Un invité a envoyé trop de commentaires ou de formulaires en peu de temps. Par défaut, le seuil est de plus de 2 en 60 secondes, et le blocage dure 3600 secondes. Le blocage est par IP, donc il peut toucher plusieurs personnes dans le même bureau. Augmente la valeur N de la section visiteurs. Il n’existe pas de liste d’exceptions.

Je n’arrive pas à créer un utilisateur éditeur ou administrateur

C’est voulu. La politique par défaut d’Inscription des utilisateurs est « Rôles à faible privilège uniquement ». Elle ne fait aucune exception, même pour toi. Passe temporairement à « Aucune restriction », crée l’utilisateur, puis reviens en arrière. Avec « Aucune inscription (exclusive) », personne ne peut créer d’utilisateurs. Vérifie aussi le rôle par défaut dans Réglages > Général de WordPress. S’il s’agit d’un rôle interdit, les inscriptions sont rejetées.

Connexion au panneau

La connexion au panneau n’apparaît pas

L’état se trouve dans un encadré précis. C’est « État de la connexion au panneau : », en haut de l’onglet Réglages distants. Si l’encadré manque, les champs étaient incomplets : il faut Customer code, Clé API et URL du panneau. Après « Enregistrer et vérifier la connexion », aucune bannière séparée n’apparaît.

• « URL du panneau non sécurisée : https requis … » : l’adresse doit commencer par https. Le plugin refuse même d’enregistrer une URL http.
• « Authentification refusée par le panneau : customer_code ou clé API incorrects. » : revérifie les deux valeurs.
• « Impossible d’atteindre le panneau : … » : problème de réseau, de DNS ou de certificat.
• « Réponse du panneau invalide (ce n’est pas du JSON). » : l’adresse ne pointe pas vers le bon endroit.

Si le panneau ne répond pas, la protection locale continue. Les données en file d’attente sont envoyées au tour suivant. Le plugin fonctionne aussi sans panneau.

Les activités n’arrivent pas au panneau

Dans l’onglet Journal d’activité, regarde le tableau de diagnostic. Regarde aussi la ligne « en attente d’envoi au panneau ». Clique sur Essayer d’envoyer maintenant : le résultat apparaît dans le diagnostic. Le plafond de lignes, par défaut 500, supprime les plus anciennes même si elles n’ont pas été livrées.

Journal de débogage, intégrité et en-têtes

Le journal de débogage ne s’active pas

Tu as deux messages possibles. « le dossier des téléversements n’est pas accessible en écriture » : corrige les permissions de uploads. « les fichiers de son dossier semblent accessibles depuis internet » : serveur probablement sans .htaccess, comme nginx. Bloque l’accès au dossier csdn-debug-* dans la configuration du serveur et réessaie. Si le journal s’est arrêté pour le plafond de 200 Mo, télécharge ou supprime les fichiers et réactive-le.

L’intégrité signale « les fichiers du plugin ne correspondent pas »

Cela peut venir de deux cas. Si tu as modifié à la main un fichier du plugin, c’est normal. Sinon, traite le site comme potentiellement compromis : réinstalle le plugin depuis une copie fiable et vérifie le reste. Si le message dit qu’il n’y a aucune référence, réactive le plugin pour prendre une nouvelle photographie.

HSTS ne s’active pas, ou ne s’éteint pas

Pour l’activer, tu dois ouvrir les réglages du plugin en https. Sinon apparaît « HSTS N’a PAS été activé ». Enregistre toujours depuis une page https. Décocher la case arrête l’envoi de l’en-tête, mais les navigateurs qui l’ont déjà reçu s’en souviennent longtemps.

Si tu ne trouves pas la réponse

Si la résolution des problèmes ne suffit pas, active le journal de débogage. Reproduis ensuite le problème et lis l’entrée. Puis ouvre une discussion sur le forum de support du plugin. C’est l’endroit où recevoir de l’aide et voir les problèmes déjà signalés. Ne colle pas de chemins du serveur ni de données sensibles.

Chapitre précédent : Journal de débogage : les erreurs PHP dans un fichier dédié. Chapitre suivant : Désactivation, désinstallation et données personnelles. Pour le sommaire : manuel CSDN.

The post Résolution des problèmes et questions fréquentes first appeared on Matteo Cisilino.

Où se trouve

Va sur Réglages > Cisilino Site Defense Network (point 1 de l’image) et ouvre l’onglet Journal de débogage (point 2). Les sections sont trois :

• point 3 : « Journal de débogage du site », avec état et activation.
• point 4 : « Fichiers collectés ».
• point 5 : « Dernières entrées ».

À quoi sert le journal de débogage WordPress

Il te sera utile quand le site affiche une page blanche ou une erreur critique, quand quelque chose casse après une mise à jour, ou quand ton hébergeur ne te permet pas de modifier wp-config.php ni de lire les journaux. Les constantes WP_DEBUG et WP_DEBUG_LOG se définissent avant le chargement des plugins, donc un plugin ne peut pas les activer. Ce journal utilise un gestionnaire d’erreurs PHP rattaché au chargement du plugin.

Ce journal s’ajoute, il ne remplace rien. Les erreurs continuent d’arriver là où elles arrivaient avant, c’est-à-dire dans debug.log et dans le journal du serveur. Il n’envoie rien au panneau.

Comment procéder

1. Ouvre l’onglet Journal de débogage.
2. Choisis Reste activé pendant : 1 heure, 24 heures (par défaut) ou 7 jours.
3. Choisis Taille maximale par fichier.
4. Clique sur Activer le journal de débogage. Lis « Journal de débogage activé. Il s’éteint seul à l’expiration du délai choisi ; les fichiers restent. ».
5. Reproduis le problème sur le site.
6. Retourne à l’onglet. Lis « Dernières entrées » ou télécharge le fichier depuis la section « Fichiers collectés ».
7. Quand tu as terminé, clique sur Éteindre le journal de débogage, ou attends l’expiration. Tu verras « Journal de débogage éteint. Les fichiers collectés sont encore ici dessous. ».

Le « État : » te dit si le journal est « activé, s’éteint le jj/mm/aaaa hh:mm », « éteint (expiré le …) » ou « éteint ». Avec le journal activé, tu peux changer la taille avec Enregistrer la taille.

Fichiers collectés

Le tableau liste le nom, la taille et les boutons Télécharger et Supprimer. En dessous se trouve Supprimer tous les fichiers. Avant de supprimer, le plugin demande une confirmation : « Supprimer ce fichier ? L’opération ne peut pas être annulée. ». Pour Supprimer tous les fichiers, le texte est « Supprimer tous les fichiers du journal de débogage ? L’opération ne peut pas être annulée. ». S’il n’y a rien, tu lis « Aucun fichier : le journal n’a jamais été activé ou n’a encore rien enregistré. ».

Dernières entrées

L’encadré montre les 200 entrées les plus récentes, de la plus nouvelle à la plus ancienne. Le menu Tous les niveaux te permet de filtrer par Fatal error, Parse error, Recoverable error, Warning, Notice ou Deprecated. Puis clique sur Filtrer. Pour tout le reste, télécharge les fichiers. Si le filtre ne trouve rien, tu lis « Aucune entrée avec ce filtre. ».

Une entrée a cette forme :

[2026-10-29 10:15:03 UTC] Warning: message dans /chemin/fichier.php:12 | GET /page

• L’heure est en UTC, différente de l’heure du site que tu vois dans le Journal d’activité.
• Après la barre verticale, tu trouves la méthode et le chemin de la requête, sans la chaîne de requête. Depuis la ligne de commande ou un cron, tu vois « cli/cron ».
• Un message sur plusieurs lignes, comme une pile d’appels, reste une seule entrée avec les lignes suivantes indentées.
• Les lignes « Info : journal de débogage activé (utilisateur N) » et « Info : journal de débogage désactivé (utilisateur N) » n’ont pas de niveau : avec un filtre, elles n’apparaissent pas.

Valeurs par défaut et limites

• Durée du journal de débogage WordPress : 1 heure, 24 heures ou 7 jours. Une autre valeur devient 24 heures.
• Taille par fichier : 1, 5, 10, 25 ou 50 Mo. Le défaut est 5 Mo. La taille choisie s’enregistre quand tu cliques sur Activer le journal de débogage ou Enregistrer la taille. Attention : Éteindre le journal de débogage remet la taille à 5 Mo, parce que ce module ne contient pas le menu de taille.
• Plafond global : 200 Mo, en additionnant les fichiers .log et .zip.
• Chaque message est tronqué à 4000 caractères.
• Il n’enregistre que les erreurs PHP : pas les requêtes lentes, les erreurs JavaScript ni les requêtes HTTP.

Exemples

• Erreur critique après la mise à jour d’un plugin : active pour 1 heure, recharge la page, filtre « Fatal error ». L’entrée indique le fichier et la ligne, par exemple /…/plugins/xyz/fichier.php:210 | GET /boutique/.
• Avertissements sporadiques : 24 heures, filtre Warning ou Deprecated. Si le fichier a été tourné, télécharge le zip.
• Site lent sans cause claire : 7 jours avec des fichiers de 25 Mo, puis cherche les Notice et Warning qui se répètent.

Garde-le activé le minimum nécessaire : souvent 1 heure suffit.

Attention : les fichiers du journal de débogage contiennent des chemins du serveur et des fragments de données. Ne les partage pas en public. Ils restent sur le disque même après l’extinction et après la désinstallation du plugin, qui supprime les options mais pas les fichiers. Supprime-les toi-même quand tu as fini. Le plafond global est de 200 Mo.

Attention : sur un serveur nginx, l’activation peut être refusée jusqu’à ce que le serveur bloque le dossier csdn-debug-*. Le message est « Journal de débogage non activé : les fichiers de son dossier semblent accessibles depuis internet (serveur probablement sans support de .htaccess, comme nginx). Les journaux peuvent contenir des chemins et des données : bloque l’accès au dossier csdn-debug-* dans la configuration du serveur et réessaie. ». Si tu ne gères pas le serveur, demande à qui le gère.

Attention : le journal ne voit pas les erreurs supprimées avec @ ni celles générées avant le chargement du plugin. Par exemple, il ne voit pas les erreurs de wp-config.php. Le journal de débogage WordPress du plugin ne remplace pas les journaux du serveur.

Ce qui se passe en coulisses

Le journal de débogage WordPress enregistre les fichiers dans un dossier wp-content/uploads/csdn-debug- suivi de 16 caractères aléatoires. Dedans se trouvent un index.php, un .htaccess qui refuse l’accès et le fichier en cours d’utilisation csdn-debug.log. À l’activation, le plugin écrit un fichier de test et essaie de le lire par HTTP. S’il répond, il refuse d’activer le journal.

Quand le fichier en cours d’utilisation dépasse la taille choisie, il est fermé, compressé en .zip et un nouveau démarre. Aucune entrée n’est perdue. Le .log original n’est supprimé qu’après vérification du zip. Si la compression échoue, le .log reste. Les entrées de « Dernières entrées » sont lues seulement depuis le fichier en cours d’utilisation, donc après une rotation les anciennes se trouvent dans les zip.

Avant de faire tourner les fichiers, le plugin contrôle le plafond de 200 Mo. S’il est atteint, le journal s’arrête pour ne rien écraser. L’avertissement jaune apparaît : « Le journal s’est arrêté car les fichiers ont atteint le plafond d’espace (200 Mo) : pour ne pas écraser les données, il n’écrit plus. Télécharge ou supprime les fichiers, puis réactive-le. ». Pour repartir, supprime les fichiers et réactive.

À l’expiration, le journal s’éteint seul, mais les fichiers restent. Le plugin ne les tronque ni ne les supprime jamais : seul toi le fais, avec Supprimer ou Supprimer tous les fichiers. Pour les erreurs fatales, l’entrée est écrite en fin de requête.

Si le journal de débogage WordPress ne fonctionne pas

• « Journal de débogage non activé : le dossier des téléversements n’est pas accessible en écriture. » : vérifie les permissions du dossier wp-content/uploads.
• Le journal n’écrit pas : si l’écriture échoue, le plugin le signale avec une entrée « Journal de débogage du site : … » dans les « Dernières tentatives » de l’onglet Journal d’activité.
• Le journal est arrêté pour le plafond : télécharge ce qui te sert, supprime les fichiers et réactive.

Le guide général du manuel explique où se situe cet onglet. Pour mieux comprendre les constantes de WordPress, regarde le guide officiel de débogage de WordPress : il explique WP_DEBUG et WP_DEBUG_LOG, que ce plugin ne peut pas remplacer.

Chapitre précédent : Journal d’activité. Chapitre suivant : Résolution des problèmes et questions fréquentes.

The post Journal de débogage : les erreurs PHP dans un fichier dédié first appeared on Matteo Cisilino.

Où se trouve

Dans le back-office, va sur Réglages > Cisilino Site Defense Network (point 1 de l’image). Ouvre l’onglet Journal d’activité (point 2). De haut en bas, tu trouves ces sections :

• point 3 : « Réglages du journal d’activité ».
• point 4 : la ligne d’état au-dessus du formulaire, avec les compteurs de lignes.
• point 5 : « Diagnostic d’envoi au panneau ».
• point 6 : « Activités enregistrées », le tableau avec les filtres.
• point 7 : « Vider le journal local ».

À quoi sert le journal d’activité WordPress

Il t’aide à répondre à des questions comme « qui a désactivé ce plugin ? » ou « depuis quelle IP cet utilisateur s’est-il connecté ? ». Chaque événement est une ligne dans le tableau de la base de données du site.

Ne le confonds pas avec le compteur des échecs de connexion par IP, qui sert à décider les blocages. Ce sont deux données séparées, avec des règles de conservation différentes. La tentative de connexion échouée, elle, apparaît aussi ici, une ligne par tentative.

Pour l’historique long et pour les recherches sérieuses, le panneau est préférable. Le journal local fonctionne aussi sans panneau. La connexion se configure dans Réglages distants.

Comment procéder

1. Ouvre l’onglet et regarde la ligne « Lignes dans le journal local : N — en attente d’envoi au panneau : M ».
2. Dans le formulaire, choisis les réglages décrits ci-dessous.
3. Clique sur Enregistrer les réglages du journal. Tu lis « Réglages du journal d’activité enregistrés. ».
4. Pour lire les événements, va sur « Activités enregistrées ». Choisis un groupe dans le menu Tous les groupes, ou écris dans le champ Utilisateur, objet ou IP, puis clique sur Filtrer.

Les réglages du formulaire

• « Enregistrer les activités sur ce site » : si tu l’éteins, aucune nouvelle ligne n’est écrite. Les anciennes restent.
• « Rétention locale (jours) » : de 0 à 3650. Avec 0, rien n’est supprimé pour ancienneté.
• « Plafond de lignes conservées » : de 0 à 1 000 000. Avec 0, il n’y a pas de plafond.
• « Envoyer les activités au panneau » : nécessite la connexion dans Réglages distants.
• « Livraison immédiate » : l’envoi part en fin de requête, sans faire attendre le visiteur. Si tu l’éteins, l’envoi n’a lieu qu’avec la synchronisation toutes les 15 minutes.
• « Que faut-il enregistrer » : une case pour chacun des 18 groupes d’événements.

Les groupes d’événements

Les groupes ont ces libellés, identiques dans les cases de « Que faut-il enregistrer » et dans le menu Tous les groupes : Connexions (connexion, déconnexion, tentatives échouées) ; Utilisateurs (création, modification de profil, rôles, suppression) ; Contenus (articles, pages, types de contenu personnalisés) ; Catégories et étiquettes ; Commentaires ; Médias (pièces jointes) ; Plugins (activation, désactivation, installation, mise à jour) ; Thèmes (changement de thème, mise à jour, personnalisation) ; Mises à jour de WordPress ; Réglages de WordPress ; Menus de navigation ; Widgets ; Éditeur de fichiers de thèmes/plugins depuis wp-admin ; Export de contenus ; Téléversements de fichiers (y compris ceux hors de la bibliothèque de médias) ; Intégrité des fichiers du plugin ; Réglages des plugins (y compris ceux de ce plugin) ; Cycle de vie du plugin (désactivation, désinstallation, vidage du journal).

Pour les réglages de WordPress, seule une sélection d’options principales est enregistrée, par exemple blogname, siteurl, admin_email, default_role et active_plugins. Pour les autres plugins, seuls les réglages déclarés avec register_setting() ou enregistrés depuis options.php sont visibles. L’éditeur de fichiers enregistre la tentative, pas le résultat.

Comment lire le tableau

Les colonnes sont Quand, Utilisateur, IP, Groupe, Action, Détail et Envoyé. Les lignes sont au nombre de 50 par page, les plus récentes d’abord. Utilise Précédentes et Suivantes pour te déplacer. S’il n’y a rien, tu lis « Aucune activité enregistrée (avec ces filtres). ».

Groupe et Action apparaissent avec le nom brut, par exemple plugins et deactivated. Qui n’est pas authentifié apparaît comme « (non authentifié) ». Dans la colonne Envoyé, tu trouves la date de confirmation du panneau, ou « — » si la ligne est encore en file d’attente. Le champ des détails techniques n’est pas visible ici : il se lit sur le panneau.

Un exemple de ligne : 12/10/2026 09:14:02, utilisateur mario (administrator), IP 203.0.113.5, groupe plugins, action deactivated.

Exemples de lecture

• Groupe « Connexions (connexion, déconnexion, tentatives échouées) » et une IP suspecte : une série de failed suivie d’un success peut signifier que quelqu’un a deviné le mot de passe.
• Une ligne users avec l’action role_changed et un utilisateur inattendu : vérifie s’il s’agit d’une escalade de privilèges.
• Une ligne du groupe Téléversements avec un avertissement de blocage : quelqu’un a essayé de charger un fichier dangereux.

Valeurs par défaut du journal d’activité WordPress

• Journal activé, envoi au panneau activé, livraison immédiate activée, tous les groupes actifs.
• Rétention : 30 jours. La suppression par ancienneté a lieu une fois par jour.
• Plafond de lignes : 500. Le contrôle se déclenche tous les 100 ajouts, donc le tableau peut le dépasser d’environ 100 lignes.
• Si tu enregistres sans cocher aucun groupe, le journal reste actif mais n’écrit rien.
• Il n’enregistre pas les visites normales et n’exporte pas les données.

Attention : un échec de connexion enregistre le nom d’utilisateur saisi. Si quelqu’un écrit le mot de passe dans le champ nom d’utilisateur, ce texte reste dans le journal, qui peut partir vers le panneau. Le plugin ne le filtre pas. Garde cela en tête quand tu partages ou consultes le journal.

Attention : le plafond de lignes (500 par défaut) supprime les lignes les plus anciennes même si elles n’ont pas encore été envoyées au panneau. Le plafond a priorité sur la garantie de livraison. Sur les sites avec beaucoup de trafic non authentifié (échecs de connexion, commentaires, envois de fichiers), 500 lignes peuvent s’épuiser rapidement. Si tu as besoin de l’historique complet, augmente le plafond, mais sache qu’avec 0 tu retires la limite d’espace disque.

Attention : « Vider le journal d’activité » est irréversible en local. Une confirmation est demandée au préalable : « Vider tout le journal d’activité local ? L’opération n’est pas réversible. ».

Ce qui n’est pas enregistré

Les mots de passe en clair ne sont jamais enregistrés. À la modification d’un profil, seule l’indication que le mot de passe a changé est enregistrée. Le champ « Clé API » du plugin est affiché comme ***. Les options d’autres plugins dont le nom contient des mots comme key, secret, token, password, auth, salt, nonce, license ou credential ont leur valeur remplacée par « *** (valeur non enregistrée) ». Les valeurs des options sont tronquées à 200 caractères.

Diagnostic de l’envoi au panneau

La section au point 5 sert quand les activités n’arrivent pas au panneau. Un envoi qui échoue ne donne aucune erreur visible : les lignes restent en file d’attente et réessaient. Le seul symptôme est le compteur « en attente » qui ne descend pas.

Le tableau montre, parmi d’autres informations, « Connexion au panneau », « Journal d’activité », « Envoi au panneau », « Livraison immédiate », « Lignes en file d’attente », « Destination de error_log() » et « Dernière tentative d’envoi ». Les valeurs problématiques sont en rouge. Si la dernière tentative montre moins de lignes acceptées qu’envoyées, « Lignes rejetées par le panneau » apparaît : ces lignes ne seront pas réessayées.

Il y a trois boutons :

• Essayer d’envoyer maintenant : fait un envoi de test immédiatement. Le résultat se trouve dans le tableau.
• Activer le journal détaillé (puis Désactiver le journal détaillé) : enregistre aussi les envois réussis.
• Vider le journal de diagnostic : efface seulement la liste « Dernières tentatives », qui garde au maximum 25 entrées. Elle apparaît seulement s’il y a des entrées.

Ce qui se passe en coulisses

En fin de requête, le plugin ferme la réponse au visiteur, quand le serveur le permet, et envoie les lignes au panneau en lots de 200 maximum, des plus anciennes aux plus récentes. Une ligne compte comme livrée seulement quand le panneau confirme sa réception. Une synchronisation toutes les 15 minutes fait office de filet de sécurité.

La rétention par ancienneté supprime les lignes anciennes une fois par jour. Si l’envoi est actif et le panneau configuré, elle ne supprime que celles déjà confirmées. Sinon, elle supprime seulement par ancienneté.

Le vidage essaie d’abord d’envoyer l’arriéré, puis supprime tout. Il enregistre l’événement de vidage, qui devient la première ligne du nouveau journal. Il n’envoie aucune commande de suppression au panneau : l’historique déjà envoyé y reste. Après le vidage, tu lis « Journal d’activité local vidé. L’historique déjà envoyé au panneau n’a pas été touché. ». S’il y avait des lignes jamais livrées, un avertissement en gras t’indique combien ont été perdues.

Si le journal d’activité WordPress n’envoie pas

• Le compteur « en attente » ne descend pas : ouvre le diagnostic, regarde la dernière tentative et le code HTTP, puis clique sur « Essayer d’envoyer maintenant ».
• Encadré jaune sur le panneau qui ne confirme pas : le panneau n’est peut-être pas à jour. Les lignes restent en file d’attente et rien n’est perdu.
• Connexion « NON configurée » : sans customer code, clé API et URL, rien n’est envoyé. Retourne à Réglages distants.

Pour un guide plus large sur les bonnes pratiques de journalisation, lis le guide OWASP sur la journalisation : il explique ce qu’il vaut mieux enregistrer et ce qu’il faut éviter.

Retourne au chapitre 1, le sommaire du manuel. Chapitre précédent : Limitation de débit. Chapitre suivant : Journal de débogage.

The post Journal d’activité : ce qui s’est passé sur le site first appeared on Matteo Cisilino.

Où se trouve

Va sur Réglages et choisis Cisilino Site Defense Network (point 1 de l’image). Ouvre l’onglet « Limitation de débit » (point 2). Pour enregistrer, il faut le droit manage_options ; sur multisite il faut manage_network_options.

Les sections sont quatre. Le point 3 est « Comment ça marche, concrètement : ce qui est compté ». Le point 4 est « 1. Auteurs : publications trop fréquentes ». Le point 5 est « 2. Visiteurs : commentaires et formulaires de contact ». Le point 6 est « Utilisateurs actuellement suspendus ». Les valeurs de temps sont toutes en secondes.

À quoi ça sert

Le garde-fou sur les auteurs arrête un compte qui publie en rafale, avant qu’il ne remplisse le site de contenus. Le garde-fou sur les visiteurs freine qui inonde les commentaires et les formulaires. Le code connaît aussi un troisième garde-fou, l’email obligatoire. Tu le trouves dans l’onglet « Inscription des utilisateurs », décrit au chapitre précédent.

Comment procéder

Ce qui est compté (point 3)

L’encadré informatif explique les règles. Pour les auteurs, le contrôle se déclenche quand WordPress enregistre un article ou une page. Le plugin compte combien d’articles et de pages de cet auteur ont une date de création ou de publication dans les T dernières secondes. S’il y en a plus de N, l’auteur est suspendu. L’enregistrement qui dépasse le seuil réussit : la suspension bloque les suivants.

Ne comptent pas les plugins et les thèmes, les connexions, les modifications de contenus plus anciens que la fenêtre, les brouillons automatiques, les révisions, la corbeille, les médias, les commentaires et les autres types de contenu. Les environnements temporaires, comme celui de test du Plugin Check, sont ignorés.

Attention : l’exemple écrit dans cet encadré cite encore N=3. C’est un texte ancien. La valeur par défaut réelle est 150 contenus en 5 minutes, depuis la version 1.0.13.

Auteurs (point 4)

1. Coche « Limitation de débit active » pour limiter les publications des auteurs.
2. Décide si tu gardes « Alerte par email » : tu reçois un mail à la suspension d’un auteur.
3. Règle « N : contenus autorisés », de 1 à 1000. Par défaut 150.
4. Règle « T : fenêtre (secondes) », de 10 à 86400. Par défaut 300, c’est-à-dire 5 minutes.
5. Règle « S : suspension (secondes) », de 60 à 2592000. Par défaut 3600, c’est-à-dire 1 heure.
6. Clique sur Enregistrer les réglages de limitation de débit.

Le mail part vers l’adresse administrateur de Réglages > Général. Il contient l’utilisateur, les contenus dans la fenêtre, l’expiration et la liste jusqu’à 20 contenus récents à contrôler. La suspension ne modifie pas ces contenus.

Visiteurs (point 5)

1. Coche « Limitation de débit active » pour limiter les envois des invités.
2. L’« Alerte par email » est désactivée par défaut. Sur un site exposé, cela peut générer beaucoup de mails. Elle arrive à la même adresse administrateur de Réglages > Général, une fois pour chaque blocage.
3. « N : envois autorisés », de 1 à 100. Par défaut 2.
4. « T : fenêtre (secondes) », de 5 à 3600. Par défaut 60.
5. « S : blocage IP (secondes) », de 60 à 2592000. Par défaut 3600.

Le garde-fou concerne seulement qui n’est pas connecté. Il compte les envois par IP et par type, commentaires ou formulaires. Un blocage sur les commentaires ne bloque pas les formulaires. Les formulaires de contact couverts sont ceux de Contact Form 7. Le commentaire rejeté affiche « Trop d’envois » avec une erreur 429.

Si une valeur est hors des limites, le plugin la ramène à la plus proche autorisée. L’enregistrement affiche « Réglages de limitation de débit enregistrés. Les valeurs hors des limites autorisées ont été ramenées à la plus proche permise. »

Limitation de débit WordPress : suspensions et blocages

Un auteur suspendu conserve son rôle et peut utiliser le reste du panneau. Il perd cependant les droits de créer et de publier des articles et des pages. « Ajouter un article » et les entrées des pages disparaissent, et s’il ouvre ces écrans il reçoit « permission refusée ». Dans le tableau de bord apparaît un avertissement qui ne peut pas être fermé.

Attention : la suspension des auteurs touche aussi les administrateurs. Un administrateur suspendu perd la création et la publication, mais peut encore ouvrir les Réglages et révoquer lui-même sa suspension. Il n’existe pas de liste d’exceptions pour utilisateurs, rôles ou IP : la liste blanche d’IP de l’onglet Général n’exempte pas de la limitation de débit.

Attention : le blocage des visiteurs est par IP. Plusieurs personnes derrière la même IP, comme un bureau, peuvent être bloquées ensemble. Dans ce cas, augmente N. Le plugin lit seulement l’adresse de connexion (REMOTE_ADDR) et non les en-têtes de proxy ou de CDN : derrière un proxy inverse ou un CDN, tous les visiteurs peuvent apparaître avec la même IP et se bloquer mutuellement.

Comment révoquer une suspension

Tu as deux options.

1. Attends. La suspension se termine seule après S secondes.
2. Dans la section au point 6, « Utilisateurs actuellement suspendus », clique sur Révoquer la suspension sur la ligne de l’utilisateur. Tu verras « Suspension révoquée : l’utilisateur peut de nouveau créer et publier des contenus. » Si le tableau est vide, tu lis « Aucun utilisateur suspendu. »

Le tableau montre au maximum 100 utilisateurs. Les avertissements du tableau de bord ont les liens « Révoque la suspension » et « Contrôle et révoque », qui mènent au même onglet.

Éteindre « Limitation de débit active » ne retire pas une suspension déjà en cours. Pour la retirer, il faut la révoquer ou attendre l’expiration.

Ce qui se passe en coulisses

La suspension est une information enregistrée sur l’utilisateur, avec la date d’expiration. Pour les invités, chaque envoi est enregistré pendant 24 heures dans une table du plugin, puis compté dans la fenêtre. Si deux requêtes arrivent ensemble, une de plus peut passer. Suspensions et blocages finissent dans le Registre d’activité, s’il est actif et si les groupes Utilisateurs et Commentaires sont activés.

Attention : une importation légitime de nombreux contenus peut déclencher le garde-fou sur les auteurs. Avant une migration, désactive le garde-fou ou augmente N.

Exemples de limitation de débit WordPress

• Blog avec un seul auteur : tu peux abaisser N à 10 ou 20 avec T=300. Tu intercepteras plus vite un compte compromis. Ce sont des valeurs d’essai, pas une règle du plugin.
• Rédaction qui duplique ou importe des pages : garde 150/300 ou plus.
• Bureaux avec IP partagée : augmente les envois autorisés des visiteurs à 3 ou 5.

Conversions utiles : 300 secondes font 5 minutes, 3600 font 1 heure, 86400 font 1 jour. Pour approfondir le sujet général, lis le guide OWASP Blocking Brute Force Attacks, qui explique pourquoi limiter les tentatives répétées.

Précédent : Inscription des utilisateurs : qui peut créer un compte. Suivant : Registre d’activité : ce qui s’est passé sur le site. Pour le sommaire général, va au chapitre 1 du manuel.

The post Limitation de débit : limites pour auteurs et visiteurs first appeared on Matteo Cisilino.

Où se trouve

Dans le menu de WordPress, ouvre Réglages puis Cisilino Site Defense Network (point 1 de l’image). Choisis l’onglet « Inscription des utilisateurs » (point 2). Pour enregistrer, il faut le droit manage_options ; sur multisite il faut manage_network_options.

Les sections sont trois. Le point 3 est « Politique d’inscription ». Le point 4 est « Rôles autorisés (seulement niveau « rôles à faible privilège ») ». Le point 5 est « Email obligatoire ».

À quoi ça sert

La politique s’applique à toutes les voies de création : le panneau wp-admin, l’API REST, XML-RPC, WP-CLI et n’importe quel plugin ou thème qui utilise les fonctions de WordPress pour créer des utilisateurs. Le contrôle se fait en PHP, sans toucher au fichier .htaccess.

Comment procéder

Politique d’inscription (point 3)

Choisis un seul niveau parmi trois. Ils ne s’additionnent pas.

• « Aucune restriction (désactivé) » : le module est éteint et WordPress se comporte comme d’habitude.
• « Rôles à faible privilège uniquement (jamais administrateur/éditeur/auteur) » : c’est le niveau par défaut. Les rôles autorisés du point 4 s’appliquent.
• « Aucune inscription (exclusive) » : aucun nouvel utilisateur ne peut être créé.

Rôles autorisés (point 4)

Cela vaut seulement pour le niveau des rôles à faible privilège. Tu peux cocher subscriber (coché par défaut), contributor et customer (utile avec WooCommerce). Les cases administrator, editor, author et shop_manager sont toujours désactivées, avec la mention « jamais autorisé ».

Email obligatoire (point 5)

La case « Ne pas créer d’utilisateurs sans une adresse email valide » est active par défaut. Elle empêche la création d’utilisateurs sans email valide, quelle que soit la voie. Elle ne touche pas les utilisateurs déjà existants. Ce réglage est enregistré avec ceux de la limitation de débit, mais se gère ici.

À la fin, clique sur Enregistrer la politique d’inscription. Tu verras « Politique d’inscription des utilisateurs enregistrée. » L’enregistrement finit dans le Registre d’activité, avec le libellé « Inscription des utilisateurs ».

Inscription des utilisateurs WordPress : valeurs par défaut et limites

• La politique par défaut est « Rôles à faible privilège uniquement », active même si tu n’as jamais rien enregistré.
• Le rôle autorisé de départ est seulement subscriber.
• Les rôles interdits sont toujours rejetés, même si quelqu’un essaie de les envoyer à la main.
• La liste des rôles est fixe : elle ne montre pas les rôles personnalisés de ton site.
• Il n’existe pas de listes de domaines email, de captcha ni de contrôles anti-spam sur les inscriptions.

Attention : avec « Aucune inscription (exclusive) », personne ne peut créer d’utilisateurs, pas même l’administrateur. L’entrée « Ajouter un nouvel utilisateur » disparaît du menu et ouvrir user-new.php à la main donne une erreur 403. Si, au niveau des rôles à faible privilège, tu décoches tous les rôles, la liste reste vide et aucun utilisateur n’est autorisé. Ici cependant l’entrée de menu et la page restent visibles : l’erreur 403 n’arrive qu’au moment où tu essaies de créer l’utilisateur.

Avec le niveau par défaut, tu ne peux pas créer un éditeur ou un auteur, même en étant administrateur. Le plugin ne prévoit pas d’exceptions pour qui est déjà connecté. Pour créer un utilisateur avec un rôle élevé, passe temporairement à « Aucune restriction », crée l’utilisateur, puis reviens en arrière.

Vérifie aussi le « Rôle par défaut des nouveaux utilisateurs » dans Réglages > Général de WordPress. S’il s’agit d’un rôle interdit, comme Éditeur, chaque inscription sans rôle explicite est rejetée.

Ce qui se passe en coulisses

Le contrôle principal agit sur le filtre pre_insert_user_data, seulement à la création d’un utilisateur. Les modifications des utilisateurs existants passent toujours. Une tentative rejetée affiche le titre « Inscription non autorisée » avec une erreur 403. Sur l’API REST, tu reçois une erreur JSON 403 au lieu de la page.

Avec n’importe quelle politique active, le plugin retire la méthode XML-RPC wp.newUser. Avec la politique exclusive, il force aussi à faux l’option « N’importe qui peut s’inscrire » de WordPress. Avec le niveau des rôles bas, cette option reste celle que tu as choisie.

Il existe aussi un filet de sécurité après la création. Si un compte naît malgré tout en violant la politique, le plugin lui retire immédiatement le rôle et écrit un événement dans le Registre d’activité. Le compte n’est pas supprimé, pour que tu puisses l’examiner.

Attention : un plugin ou un thème compromis qui écrit directement dans la table des utilisateurs avec un INSERT dans la base de données ne passe par aucun filtre. Aucun plugin PHP ne peut l’arrêter. L’inscription des utilisateurs WordPress protégée par cet onglet est une barrière solide, mais elle n’est pas absolue.

Exemples

• Site vitrine sans utilisateurs publics : choisis « Aucune inscription (exclusive) ».
• Site avec abonnés ou commentaires : laisse le niveau par défaut avec subscriber.
• Boutique avec WooCommerce : ajoute customer.
• Tu dois ajouter un collaborateur avec un rôle élevé : utilise « Aucune restriction » seulement le temps nécessaire.

Si quelque chose ne va pas

Si une inscription est rejetée avec le message sur le rôle non autorisé, vérifie le rôle par défaut de WordPress et les rôles cochés au point 4. Le Registre d’activité te dit si un compte a été privé de son rôle par le filet de sécurité. Pour mieux comprendre les rôles, lis la page rôles et permissions dans la documentation de WordPress. Elle liste ce que peut faire chaque rôle.

Précédent : Paranoic Hardening : en-têtes de sécurité et session administrateur. Suivant : Limitation de débit : limites pour auteurs et visiteurs. Pour le sommaire général, va au chapitre 1 du manuel.

The post Inscription des utilisateurs : qui peut créer un compte first appeared on Matteo Cisilino.