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.

Où se trouve

Dans le menu latéral de WordPress, va sur Réglages et choisis Cisilino Site Defense Network (point 1 de l’image). Ouvre l’onglet « Paranoic Hardening » (point 2). Pour enregistrer, il faut le droit manage_options ; sur multisite il faut manage_network_options.

L’onglet comporte quatre sections. Au point 3, tu trouves « Paranoic Hardening — En-têtes de sécurité HTTP ». Au point 4, il y a « HTTP Strict Transport Security (HSTS) ». Le point 5 est « Vérification des en-têtes de sécurité ». Le point 6 est « Déconnexion automatique des administrateurs pour inactivité ».

À quoi ça sert

Les en-têtes sont des instructions que le site envoie au navigateur avec chaque page. Le plugin les envoie avec le hook send_headers de WordPress, sans toucher au fichier .htaccess. Tu ne risques donc pas une erreur 500, et cela fonctionne même sans mod_headers.

Les en-têtes concernent uniquement le site public. Ils ne sont jamais envoyés dans la zone d’administration. Le plugin n’offre pas de Content-Security-Policy et n’envoie pas de X-XSS-Protection.

Comment utiliser le Paranoic Hardening

En-têtes de sécurité HTTP (point 3)

• X-Content-Type-Options envoie nosniff. Le navigateur ne « devine » plus le type des fichiers. Le risque est pratiquement nul.
• X-Frame-Options envoie SAMEORIGIN. Le site ne peut plus être intégré dans un <iframe> d’un autre domaine. Si un site partenaire affiche tes pages, il arrêtera de le faire.
• Referrer-Policy envoie strict-origin-when-cross-origin. Vers d’autres domaines, seul le domaine voyage, pas le chemin. Les statistiques de tiers qui veulent le référent complet ne le recevront pas.

Coche les cases dont tu as besoin et clique sur Enregistrer le Paranoic Hardening. Tu verras l’avertissement « Réglages Paranoic Hardening enregistrés et appliqués. » Les cases que tu ne coches pas sont enregistrées comme désactivées.

HSTS (point 4)

HSTS dit au navigateur d’utiliser toujours https avec ton domaine. Il y a trois cases : « Activer HSTS », « includeSubDomains » et « Preload ». L’en-tête envoyé a max-age=31536000, c’est-à-dire un an. La valeur est fixe et ne se change pas.

Le plugin refuse l’activation si la page n’a pas été ouverte en https. Dans ce cas, il enregistre le reste et affiche un avertissement rouge : « Réglages enregistrés, mais HSTS N’a PAS été activé : cette requête n’est pas arrivée en https. Ouvre le panneau en https et réessaie. » Si la page est en http, les trois cases sont aussi désactivées.

Si tu éteins « Activer HSTS », à l’enregistrement « includeSubDomains » et « Preload » sont aussi remises à zéro. Si tu réactives HSTS, tu dois les recocher.

Vérification des en-têtes de sécurité (point 5)

Clique sur Vérifier maintenant. Le plugin fait une requête réelle vers la page d’accueil du site et contrôle quels en-têtes arrivent vraiment. Le résultat apparaît dans l’encadré, avec la date du dernier test.

• Vert : « Tous les en-têtes attendus sont présents dans la réponse réelle du site. »
• Rouge : les en-têtes actifs qui ne sont pas arrivés. Cela peut être un proxy, un CDN ou un autre plugin qui les retire. HSTS apparaît aussi manquant si l’adresse de la page d’accueil est en http et ne mène pas à https, car le plugin l’envoie seulement sur des requêtes https.
• Bleu : « Aucun en-tête actif à vérifier : active au moins une option ci-dessus et enregistre. »
• Rouge avec « Requête de vérification échouée » : la requête n’a pas réussi.

Le test contrôle la présence de l’en-tête, pas sa valeur. Il ne démarre pas seul : tu dois le déclencher toi-même.

Déconnexion automatique des administrateurs (point 6)

Cette section du Paranoic Hardening a son propre bouton, Enregistrer l’autologout administrateurs. Coche « Activer » pour déconnecter les administrateurs inactifs. Puis règle le « Délai d’inactivité (secondes) ». Si le navigateur bloque le localStorage (par exemple en navigation privée), le contrôle ne se déclenche jamais et tu n’es pas déconnecté.

La valeur par défaut est 900, c’est-à-dire 15 minutes. Le minimum est 60 et le maximum est 86400. Si tu écris un nombre hors de ces limites, le plugin le ramène à la valeur admise la plus proche. Par exemple 30 devient 60. L’avertissement reste vert, donc relis le nombre dans le champ après l’enregistrement.

Seuls les utilisateurs avec le droit manage_options sont déconnectés. Les éditeurs et auteurs ne sont pas touchés. L’inactivité est mesurée dans le navigateur : la souris, le clavier, le défilement et le toucher comptent. La session se ferme comme avec « Se déconnecter » et les modifications non enregistrées dans un formulaire ouvert sont perdues.

Ordre d’activation recommandé

1. Ouvre le panneau en https.
2. Active X-Content-Type-Options, enregistre et clique sur « Vérifier maintenant ».
3. Active Referrer-Policy, enregistre et vérifie.
4. Vérifie qu’aucun site n’intègre le tien, puis active X-Frame-Options, enregistre et vérifie.
5. Active l’autologout avec un délai généreux, par exemple 1800. Ne le réduis qu’après quelques jours.
6. En dernier, envisage HSTS, sans includeSubDomains et sans Preload.

Active une seule option à la fois. Si quelque chose casse, tu sais immédiatement laquelle.

Le risque de HSTS, includeSubDomains et Preload

Attention : HSTS ne se défait pas depuis le site. Si tu décoches, le plugin arrête d’envoyer l’en-tête, mais les navigateurs qui l’ont déjà reçu s’en souviennent jusqu’à l’expiration. Le plugin n’envoie jamais max-age=0, il n’a donc pas d’« annuler ». La bannière de l’onglet le dit aussi : les effets peuvent rester visibles pendant des semaines ou des mois.

Avec HSTS actif, le navigateur refuse toute connexion non https vers le domaine. Si le certificat expire ou se casse, le navigateur n’affiche même plus l’écran « continuer malgré tout ». Le site reste inaccessible depuis ce navigateur.

• includeSubDomains étend la règle à tous les sous-domaines. Un seul sous-domaine sans https valide, même de test ou futur, devient inaccessible pour qui a déjà visité le site. Active-le seulement si tous les sous-domaines sont et seront en https.
• Preload ajoute seulement le drapeau preload à l’en-tête. À lui seul, cela n’inscrit pas le site : l’envoi vers la liste des navigateurs se fait à la main sur hstspreload.org. La liste est à l’intérieur des navigateurs, et en sortir demande des semaines. Considère Preload comme un choix définitif.

Enregistre toujours depuis la version https du panneau. Les cases désactivées ne sont pas envoyées par le navigateur : en enregistrant depuis une page http, HSTS et ses sous-options s’éteignent.

Ce qui se passe en coulisses

Les réglages du Paranoic Hardening sont des options de WordPress, pas des règles du serveur. L’autologout imprime un script seulement dans les pages d’administration. Le script enregistre la dernière activité dans le localStorage du navigateur et contrôle le délai toutes les 5 secondes. À l’expiration, il demande à admin-ajax.php d’exécuter la déconnexion et te ramène à la page de connexion. L’enregistrement finit dans le Registre d’activité seulement si tu as changé quelque chose.

Si quelque chose ne va pas

• L’encadré est rouge après « Vérifier maintenant » : un proxy, un CDN ou un autre plugin retire les en-têtes. Vérifie leur configuration.
• Un site partenaire n’affiche plus tes pages : décoche X-Frame-Options et enregistre.
• Tu n’arrives pas à activer HSTS : rouvre le panneau avec l’adresse https.
• Pour contrôler les en-têtes à la main, tu peux utiliser les outils de développement du navigateur ou curl -I sur l’adresse https du site.

Pour mieux comprendre comment fonctionne HSTS, lis la page Strict-Transport-Security sur MDN. Elle explique max-age, includeSubDomains et preload avec précision.

Précédent : Onglet Test : vérifier que les protections fonctionnent. Suivant : Inscription des utilisateurs : qui peut créer un compte. Pour le sommaire général, va au chapitre 1 du manuel.

The post Paranoic Hardening : en-têtes de sécurité et session administrateur first appeared on Matteo Cisilino.

Où se trouve le test de sécurité WordPress

Ouvre Réglages > Cisilino Site Defense Network (point 1 de l’image). Clique sur l’onglet Test (point 2). Tu trouves deux encadrés :

• point 3 : « Vérification du blocage d’exécution PHP dans uploads ».
• point 4 : « Intégrité des fichiers du plugin ».

Après chaque bouton, le site te ramène à l’onglet Général, avec un avertissement en haut. Le résultat, lui, est écrit dans l’onglet Test. Rouvre-le pour le lire.

Vérification du blocage d’exécution PHP dans uploads

Cet encadré teste la règle « Bloquer l’exécution PHP dans wp-content/uploads » de l’onglet Durcissement / IDS, décrite au chapitre Durcissement / IDS. Le texte explique que c’est le seul moyen de savoir si la règle est vraiment efficace sur ce site. Un AllowOverride désactivé ou un blocage plus spécifique dans le serveur pourraient la rendre inutile sans le signaler.

Comment procéder

1. Dans l’onglet Durcissement / IDS, active la règle et clique sur « Enregistrer les règles de durcissement ».
2. Ouvre l’onglet Test.
3. Dans l’encadré « Vérification du blocage d’exécution PHP dans uploads », clique sur « Vérifier maintenant ».
4. Retourne à l’onglet Test et lis le résultat, avec la ligne « Dernier test : » et la date.

Si la règle n’est pas active et enregistrée, le bouton est désactivé. L’encadré affiche : « Active et enregistre la règle « Bloquer l’exécution PHP dans wp-content/uploads » dans l’onglet Durcissement / IDS avant de pouvoir exécuter le test. ».

Ce que fait le test

Le plugin écrit dans uploads un petit fichier .php de test. Il le demande par HTTP, avec une limite de 10 secondes. Puis il le supprime immédiatement, dans tous les cas. Le fichier contient seulement une impression de contrôle.

Comment lire le résultat

• Vert : « Blocage efficace : la requête vers le fichier de test a reçu N. ». Le nombre est 403 ou 404.
• Rouge : « ATTENTION : le fichier PHP de test a été EXÉCUTÉ (réponse N). » La règle ne bloque rien. Le message te suggère de vérifier que AllowOverride autorise .htaccess dans ce dossier et qu’il n’existe pas de bloc <Directory> plus spécifique.
• Jaune : « Résultat peu clair (réponse N, corps non reconnu) : vérifie manuellement avec une requête directe au site. ».
• Bleu : « Règle désactivée : active-la et enregistre-la avant d’exécuter le test. ».
• Rouge, pour les erreurs : « Impossible de déterminer le dossier uploads. », « Impossible d’écrire le fichier de test dans uploads (permissions ?) : test non exécuté. » ou « Requête de vérification échouée », avec le motif.

Attention : si le site n’arrive pas à s’appeler lui-même, par exemple à cause d’un pare-feu, d’un mot de passe HTTP ou d’un DNS local, le test donne une erreur ou un résultat peu clair. Un 404 est compté comme un blocage, mais cela pourrait dépendre d’autre chose. Le test ne teste que le dossier uploads standard. Pendant quelques secondes, un fichier .php existe dans uploads : si le blocage ne fonctionne pas, il peut être exécuté, mais il contient seulement une impression de contrôle.

Intégrité des fichiers du plugin

C’est la seconde partie du test de sécurité WordPress. Le second encadré compare les empreintes MD5 des fichiers .php du plugin avec celles attendues. Il cherche des fichiers modifiés, manquants ou ajoutés. Le contrôle démarre seul une fois par jour. Le bouton « Vérifier maintenant » l’exécute immédiatement.

L’encadré rapporte une limite fixe : qui a déjà l’accès en écriture aux fichiers peut aussi réécrire les empreintes ou éteindre le contrôle. C’est un détecteur d’altérations, pas une barrière.

Comment procéder

1. Ouvre l’onglet Test.
2. Dans l’encadré « Intégrité des fichiers du plugin », clique sur « Vérifier maintenant ».
3. Lis l’avertissement : « Vérification d’intégrité exécutée : le résultat se trouve dans l’encadré « Intégrité des fichiers du plugin ». ».
4. Rouvre l’onglet Test et lis l’encadré.

Comment lire le résultat

Vert : « Tous les N fichiers vérifiés correspondent. Dernier contrôle : date. ». Si la référence est une photographie, l’encadré ajoute qu’elle détecte les modifications postérieures, pas un plugin déjà compromis à l’installation. Rouge : « ATTENTION : les fichiers du plugin ne correspondent pas à ceux attendus. », avec les listes « Modifiés », « Manquants » et « Imprévus ». Jaune : « Aucune référence disponible ». Dans ce cas, réactive le plugin.

Le bouton manuel n’écrit pas dans le registre d’activité. Seul le contrôle planifié le fait, et seulement s’il trouve un problème ou si les fichiers redeviennent réguliers après une alerte. Pour les détails, lis le chapitre Surveillance des téléversements et contrôle d’intégrité.

Attention : si tu as modifié à la main un fichier du plugin, l’alerte rouge est normale. Si tu ne l’as pas fait, traite le site comme potentiellement compromis : réinstalle le plugin depuis une copie fiable et vérifie le reste de l’installation.

Si quelque chose ne va pas

Répète le test de sécurité WordPress après chaque correction. Si le test sur le PHP donne rouge, la règle ne protège pas. Demande à ton hébergeur si .htaccess est activé. Si le serveur ne lit pas .htaccess, par exemple avec nginx, la règle n’a aucun effet. Répète le test après chaque correction. Un 403 est la réponse que tu veux voir : la page sur le code de statut 403 de MDN explique ce qu’il signifie.

Chapitre précédent : Surveillance des téléversements et contrôle d’intégrité. Chapitre suivant : Paranoic Hardening : en-têtes de sécurité et session administrateur. Pour le sommaire des chapitres, retourne à l’introduction du manuel.

The post Onglet Test : vérifier que les protections fonctionnent first appeared on Matteo Cisilino.

Où se trouve

Attention à l’emplacement : le formulaire ne se trouve pas dans l’onglet « Durcissement / IDS ». Ouvre Réglages > Cisilino Site Defense Network (point 1), reste sur l’onglet Général (point 2) et fais défiler jusqu’en bas. Après la liste blanche, tu trouves la section « Surveillance des téléversements de fichiers » (point 3). Le contrôle d’intégrité, lui, se lit dans l’onglet Test, expliqué au chapitre Onglet Test.

À quoi sert la surveillance des téléversements

La section dit : « Enregistre les fichiers téléversés sur le site, y compris ceux qui ne passent pas par la bibliothèque de médias : formulaires de plugins, point d’accès admin-ajax, téléversements arbitraires d’un thème. » C’est par là qu’entrent la plupart des webshells. Un journal qui ne surveille que la bibliothèque de médias ne les voit pas.

Comment procéder

1. Ouvre l’onglet Général et fais défiler jusqu’à « Surveillance des téléversements de fichiers ».
2. Vérifie la ligne « Surveillance » : « Enregistre les téléversements de fichiers ».
3. Vérifie la ligne « Blocage des fichiers exécutables » : « Refuse les téléversements avec une extension exécutable (.php, .phtml, .phar, .sh, .htaccess…) ».
4. Clique sur « Enregistrer la surveillance des téléversements ».
5. Lis l’avertissement : « Réglages de la surveillance des téléversements enregistrés. ».

Enregistre les téléversements de fichiers

Cette option est active par défaut. Les événements finissent dans le groupe « Téléversements de fichiers » du registre d’activité. Sur une requête sans fichier, le coût est nul. Le plugin note chaque requête qui contient un fichier, avec le champ et l’adresse qui l’a reçu. Les actions que tu verras dans le registre sont :

• « Fichier reçu dans une requête POST ».
• « Fichier téléversé ».
• « ATTENTION : fichier potentiellement exécutable téléversé ».
• « Téléversement BLOQUÉ ».

Le registre local garde au maximum 500 lignes, si tu ne changes pas le plafond dans les réglages du registre d’activité. Comment le lire est expliqué au chapitre Registre d’activité.

Blocage des fichiers exécutables

Cette option est désactivée par défaut. Elle ne fonctionne que si « Enregistre les téléversements de fichiers » est aussi active : avec la surveillance éteinte, le blocage ne fait rien, même si la case est cochée. Si tu l’actives, WordPress refuse le fichier avec le message : « Type de fichier non autorisé sur ce site (Cisilino Site Defense Network : téléversement de fichiers exécutables bloqué). » Le contrôle reconnaît aussi les doubles extensions, comme image.php.jpg.

Les extensions considérées dangereuses sont : php, php3, php4, php5, php7, php8, phtml, phps, phar, pht, shtml, cgi, pl, py, rb, sh, bash, htaccess, htpasswd, jsp, asp, aspx, exe, so, dll, ini, svg et svgz.

Attention : la liste bloque aussi .svg, donc les logos en SVG ne se chargent plus. Elle bloque aussi .ini, .py, .exe et .dll, qui apparaissent dans des pièces jointes et des paquets. Le plugin regarde toutes les parties après le premier point. Un nom comme archive.pl.zip est donc rejeté. Le blocage ne vaut que pour les téléversements gérés par WordPress (filtre wp_handle_upload_prefilter). Un plugin qui enregistre le fichier pour son propre compte est noté (« Fichier reçu dans une requête POST ») mais pas arrêté. Qui écrit directement sur le disque, sans requête avec fichier, ne laisse aucune trace dans ce registre.

Le contrôle d’intégrité

À la différence de la surveillance des téléversements, ici tu ne regardes pas les nouveaux uploads mais les fichiers déjà présents. Le plugin compare les empreintes MD5 de ses fichiers .php avec celles attendues. Il cherche des fichiers modifiés, manquants ou ajoutés. Il exclut les dossiers tests et dist. Les fichiers qui ne sont pas PHP ne sont pas contrôlés.

Le contrôle tourne une fois par jour, via le système de planification de WordPress. Si le site a peu de visites, il peut glisser. La référence est le fichier checksums.json dans le dossier du plugin, s’il est présent. Sinon le plugin utilise une photographie des fichiers prise à l’activation et à chaque changement de version.

Comment lire le résultat

Tu le trouves dans l’onglet Test, dans l’encadré « Intégrité des fichiers du plugin », où il y a aussi le bouton « Vérifier maintenant » pour lancer le contrôle immédiatement. Il y a quatre cas :

• « Aucune vérification exécutée pour le moment. », si cela n’a jamais démarré.
• Encadré vert : « Tous les N fichiers vérifiés correspondent. Dernier contrôle : date. ».
• Encadré jaune : « Aucune référence disponible : impossible de vérifier. Réactive le plugin pour capturer une nouvelle photographie des fichiers. ».
• Encadré rouge : « ATTENTION : les fichiers du plugin ne correspondent pas à ceux attendus. », avec trois listes : « Modifiés », « Manquants », « Imprévus ».

Dans la liste apparaissent au maximum 15 noms. Si tu vois le rouge et que tu n’as pas touché les fichiers à la main, le plugin te dit de traiter le site comme potentiellement compromis. Réinstalle le plugin depuis une copie fiable et vérifie le reste de l’installation.

Si la référence est la photographie, l’encadré vert l’indique. Cette comparaison trouve les modifications postérieures, pas un plugin déjà compromis au moment de l’installation.

Attention : l’intégrité est un détecteur, pas une barrière. Qui a déjà écrit sur les fichiers peut aussi réécrire les empreintes ou éteindre le contrôle. Des modifications faites à la main ou un téléversement à moitié terminé produisent une alerte rouge.

Ce qui se passe en coulisses

La surveillance des téléversements et l’intégrité utilisent le même registre. Le contrôle quotidien écrit dans le registre d’activité seulement dans deux cas : quand il trouve un problème et quand, après un problème, tout redevient normal. Quand tout va bien, il n’écrit rien. Le registre est ensuite envoyé au panneau, afin qu’une copie de l’alerte se trouve hors de ton serveur.

Si quelque chose ne va pas

La surveillance des téléversements reste utile même avec le blocage éteint. Si un plugin légitime arrête de charger des fichiers, éteins « Blocage des fichiers exécutables » et réessaie. Pour comprendre quels téléversements arrivent sur le site, laisse la surveillance active et consulte le registre. Pour les règles sur les fichiers dans uploads, voir aussi le chapitre Durcissement / IDS.

Le risque que l’on cherche ici à réduire est décrit par OWASP : lis la page sur le téléversement de fichiers sans restriction, utile pour comprendre pourquoi les uploads sont un point faible.

Chapitre précédent : Durcissement / IDS : les règles pour .htaccess. Chapitre suivant : Onglet Test : vérifier que les protections fonctionnent. Sommaire : introduction du manuel.

The post Surveillance des téléversements et contrôle d’intégrité first appeared on Matteo Cisilino.

Où trouver le durcissement WordPress

Ouvre Réglages > Cisilino Site Defense Network (point 1 de l’image). Puis clique sur l’onglet Durcissement / IDS (point 2). Dans l’onglet tu trouves trois sections, dans cet ordre :

• point 3 : sous le titre « Durcissement / contrôle d’accès (IDS) », la ligne « Règles .htaccess ».
• point 4 : « WordPress ».
• point 5 : « Chemins personnalisés à bloquer ».

En haut, l’onglet dit : « Règles facultatives appliquées au niveau du serveur (.htaccess) ou de WordPress. Toutes désactivées par défaut : active-les seulement si tu sais qu’elles n’entrent pas en conflit avec les thèmes/plugins du site. » En bas, il y a un seul bouton : « Enregistrer les règles de durcissement ».

À quoi ça sert

Les règles réduisent la surface d’attaque. Trois interrupteurs écrivent dans le fichier .htaccess, comme le champ des chemins personnalisés. Deux interrupteurs sont des filtres de WordPress. Ce n’est pas un pare-feu et cela n’analyse pas les requêtes : ici « IDS » veut dire des règles d’accès aux fichiers et aux dossiers.

Les règles .htaccess (point 3)

Bloquer l’exécution PHP dans wp-content/uploads

Le libellé complet est « Bloquer l’exécution PHP dans wp-content/uploads (protection contre les shells téléversés comme « image ») ». Le plugin répond 403 à toute requête d’un fichier avec extension php, php3, php4, php5, php7, php8, php9, phtml, phps, phar ou pht dont l’adresse contient /wp-content/uploads/. Les majuscules n’ont pas d’importance.

Cela fonctionne seulement avec Apache 2.4 (il faut le module mod_authz_core : sans lui, la règle ne fait rien et ne le signale pas). Sur nginx, le fichier .htaccess est ignoré et aucune règle de cet onglet n’a d’effet, filtres de WordPress mis à part. Cela couvre le dossier uploads standard, pas un dossier personnalisé. Cela peut casser des plugins qui servent vraiment des fichiers PHP depuis ce dossier. Pour savoir si ça marche sur ton site, utilise le test du chapitre Onglet Test.

Désactiver la liste des fichiers dans les dossiers sans index

Cela écrit une seule ligne : Options -Indexes. En ouvrant un dossier sans page index, tu verras une erreur 403 au lieu de la liste des fichiers. Si tu utilises un dossier comme liste publique de téléchargements, cette liste disparaît.

Bloquer l’accès direct à wp-config.php, .htaccess, readme.html, debug.log

Le plugin écrit une règle pour chaque nom et répond 403. Le contrôle porte sur le nom du fichier, pas sur le chemin. Cela vaut donc pour chaque fichier portant ce nom, dans n’importe quel dossier du site, même à l’intérieur d’autres plugins. Un plugin qui publie son propre readme.html ou debug.log sera bloqué.

Les règles de WordPress (point 4)

Ces deux règles du durcissement WordPress sont des filtres PHP. Elles ne touchent pas à .htaccess.

Désactiver XML-RPC

Le libellé est « Désactiver XML-RPC (bruteforce/pingback, presque jamais nécessaire sur les sites modernes) ». Le fichier xmlrpc.php reste à sa place, mais WordPress refuse les méthodes XML-RPC qui nécessitent une connexion. Attention : cela arrête l’application mobile de WordPress, une partie des fonctions de Jetpack et la publication depuis des clients externes. La méthode pingback.ping ne nécessite pas de connexion et le filtre ne l’arrête pas : ne compte pas sur cette règle pour fermer les pingbacks. Les trackbacks n’utilisent pas XML-RPC et ne sont pas concernés. La connexion du plugin au panneau n’utilise pas XML-RPC, elle n’est donc pas touchée.

Bloquer l’énumération des utilisateurs via ?author=N

Si la requête contient le paramètre author avec une valeur (différente de vide et de 0), le site public affiche « Introuvable. » avec une réponse 404. Attention : cette règle ne protège pas l’API REST. La liste des utilisateurs dans /wp-json/wp/v2/users reste accessible. Certains thèmes et plugins utilisent ?author= pour filtrer les archives, et seront bloqués.

Chemins personnalisés à bloquer (point 5)

Le champ de texte est pour qui veut fermer un dossier précis, par exemple /wp-content/uploads/ancienne-sauvegarde/. Écris un chemin par ligne. Les lignes vides sont ignorées.

Chaque ligne est un texte littéral. Les majuscules comptent et la partie après le ? de l’adresse n’est pas comparée. L’aide sous le champ parle de « motifs », mais ici il n’en existe pas. Il n’existe pas de jokers : *, ^ et $ valent comme de simples caractères. Le plugin bloque avec 403 chaque adresse qui contient cette chaîne, à n’importe quel endroit. C’est pourquoi le chemin /wp-content/uploads/ancienne-sauvegarde/ bloque aussi /blog/wp-content/uploads/ancienne-sauvegarde/x.

Ce champ n’a pas d’interrupteur. La règle est active dès que le champ n’est pas vide et que tu enregistres.

Attention : si tu écris / ou wp, tu bloques tout le site, y compris la zone d’administration. Pour revenir en arrière, tu devrais corriger .htaccess par FTP. Même une chaîne comme /uploads/ bloque toutes les images. Évite le caractère % dans les chemins.

Valeurs par défaut

Cinq interrupteurs désactivés et un champ vide. Les réglages sont dans l’option csdn_hardening.

Comment procéder

Vas-y calmement : le durcissement WordPress se fait une règle à la fois.

1. Fais une copie de .htaccess avant de commencer.
2. Coche une seule règle.
3. Clique sur « Enregistrer les règles de durcissement ».
4. Vérifie que le site s’ouvre et que l’administration fonctionne.
5. Passe à la règle suivante.

Après l’enregistrement, tu es ramené à l’onglet Général, pas à celui où tu as enregistré. En haut, tu trouves l’avertissement. En cas de succès, il dit « Règles de durcissement enregistrées et appliquées. ». En cas d’erreur, il dit « Réglages enregistrés, mais l’écriture dans .htaccess a échoué (permissions ?). Les règles ne sont pas actives. ». Avec l’erreur, les deux filtres de WordPress restent quand même actifs.

Attention : le plugin ne crée aucune sauvegarde de .htaccess. Il ne contrôle même pas la syntaxe avant d’écrire. Une règle incompatible avec ton serveur peut provoquer une erreur 500 sur tout le site. Sur un réseau multisite, le fichier est celui du réseau : l’erreur touche tous les sites.

Ce qui se passe en coulisses

Le plugin écrit entre deux marqueurs : # BEGIN Cisilino Site Defense Network - Hardening et le # END correspondant. Le reste du fichier n’est pas touché. Un second bloc, séparé, contient les IP bloquées. Si tu désactives le plugin, les deux blocs sont vidés. Si tu éteins tout et enregistres, le bloc de durcissement reste vide.

Si quelque chose ne va pas

Si après le durcissement WordPress le site affiche une erreur 500, ouvre .htaccess par FTP. Supprime les lignes entre les deux marqueurs de durcissement. Puis réessaie avec moins de règles. Si l’écriture dans le fichier échoue, vérifie les permissions de .htaccess.

Pour une vue plus large sur les bonnes pratiques, lis le guide officiel sur le durcissement de WordPress : il explique d’autres mesures qui se situent hors du plugin.

Chapitre précédent : Onglet IP bloquées : lire la liste noire. Chapitre suivant : Surveillance des téléversements et contrôle d’intégrité. Pour le sommaire complet, retourne à l’introduction du manuel.

The post Durcissement / IDS : les règles pour .htaccess first appeared on Matteo Cisilino.