Durcissement / IDS : les règles pour .htaccess

Le durcissement WordPress du plugin CSDN tient tout entier dans un onglet : « Durcissement / IDS ». Ce sont cinq interrupteurs et un champ de texte. Ils servent à fermer des portes que presque aucun site n’utilise vraiment. Ils sont tous désactivés, et tu les actives un à la fois.

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.