Sécuriser son WordPress

Je ne suis pas une grande fana des plugins “de sécurisation”, et tout particulièrement de ceux qui auditent un code. Sur le forum de support wordpress-fr, on a longtemps vu des gens qui ne comprenaient pas réellement le résultat des audits, qui faisaient des erreurs, qui bloquaient leurs installations.

De plus, WordPress a intégré quelques mécanismes qui avant n’étaient possibles que par plugin, ce qui fait que, régulièrement mis à jour, en n’utilisant que des plugins distribués par WordPress.org, on est raisonnablement tranquille.

Néanmoins, il reste la possibilité du petit malin qui s’échine, automatiquement, à essayer de trouver votre mot de passe (ce qui m’arrive en ce moment… d’où ce post). En trois étapes, comment lui faire perdre beaucoup, beaucoup de temps.

Cacher l’accès au profil Admin

Etape 1 : à la création, ne pas appeler le profil “admin”. C’est maintenant possible en standard sous WordPress, si vous avez une vieille installation, faites le changement. Le plus simple est de créer un nouvel admin, de vous connecter à partir de ce nouveau profil, de supprimer l’ancien en basculant tous les posts sur le nouveau. Et bien sûr de remettre l’ancien mail sur le nouveau profil.

Etape 2 : modifier le slug / nicename de son auteur. En effet, si vous affichez l’auteur (ce que je ne fais pas ici, mais que vous êtes obligés de faire sur les blogs multi auteurs), le lien donnera l’identiant. Par défaut, WordPress utilise l’identifiant comme nicename, alors que les champs sont différenciés dans la base de données. Pour accéder au nicename, j’utilise Author Slug Field. (Pas mis à jour, mais étant donné ce qu’il fait, ce n’est pas un problème : un bon exemple des “risques” des analyses de sécurité automatisées qui génèrent des avertissements pas toujours pertinents).

Etape 3 : avoir deux utilisateurs, un admin et un éditeur, que vous utiliserez au quotidien. L’avantage est que même si on repère votre mot de passe, via un keylogger, ou un virus, l’accès admin n’est toujours pas donné.

Limit Login Attempts

Un autre très bon plugin, dont je recommande l’utilisation systématique. Il bloque les IP pour une durée paramétrable, au bout d’un nombre paramétrable de tentatives de connexion, et il vous informe par mail. C’est en trouvant ce matin plus de 150 mails (donc 150 * 3 tentatives de connexion, toutes sur l’utilisateur admin, avec 150 IP différentes) que je me suis aperçue que “quelqu’un” s’excitait un peu.

Le seul défaut : quand vous travaillez à plusieurs avec un IP fixe, vous pouvez bloquer tout le monde :) c’est arrivé chez un client. Dans ce cas, si vous êtes admin, il suffit de supprimer le plugin, le temps de rétablir les accès. Si l’admin a accès via une autre IP, le plugin permet de réinitialiser les blocages.

Limit Login Attempts est un excellent ralentisseur.

Mais en théorie, avec du temps et de l’obstination, on peut craquer tous les mots de passe.

Le bunker : protéger les fichiers sensibles par .htpasswd

On va donc rajouter une couche supplémentaire (en tout cas c’est ce que j’ai fait ce matin, parce que j’en avais un peu assez de voir tous ces mails dans ma boite de réception) : la protection au niveau Apache, via .htaccess et .htpasswd

Le principe : pour chaque fichier à protéger, on va mettre dans le fichier .htaccess du répertoire où il se trouve une consigne, et un appel à un autre fichier, de type .htpasswd, qui contiendra les couples user / mot de passe.

Je protège généralement mes fichiers wp-config.php comme cela, ici j’ai rajouté le fichier wp-login.php

Les deux fichiers se trouvant à la racine de WordPress, les instructions sont à rajouter en haut du fichier .htaccess, avec les règles de réécriture de WordPress.

Vous avez sur htaccesstools un générateur de fichier qui encode les mots de passe.

Voici ce que vous allez rajouter pour protéger votre fichier wp-login.php

<Files wp-login.php>
 AuthUserFile [chemin à partir de la racine du serveur/monfichier].htpasswd
 AuthGroupFile /dev/null
 AuthName " Gee a second password to guess ! Happy you !"
 AuthType Basic
 <Limit GET POST>
   require valid-user
 </Limit>
</Files>

Le chemin à partir de la racine du serveur ne comprend pas votre nom de domaine. HTaccessTools vous indique comment trouver ce chemin. (Non je n’ai pas la flemme de réécrire ce que les autres ont fait)

“AuthName” est le message qui s’affiche pour demander le mot de passe. Ici, un peu d’ironie…

Enfin la consigne require valid-user demande qu’on utilise un user listé dans le fichier monfichier.htpasswd (que vous aurez eu soin de stocker dans un répertoire extérieur à votre “www”).

Bien évidemment, comme tous les mots de passe, celui ci peut être craqué. Néanmoins, vous verrez alors à nouveau dans votre boite mail les avertissements de Limit Login Attempts… et il vous suffira de changer votre mot de passe dans le .htpasswd pour que votre petit curieux soit obligé de recommencer…

(NB : on peut, si le fichier .htpasswd contient plusieurs utilisateurs, par exemple toto et titi, remplacer require valid-user par require toto)

L’inconvénient de cette méthode : elle est très lourde pour les utilisateurs, elle est donc réservée aux blogs “de vrais geeks” ou mono auteurs.

Message à l’intention du hacker :  étant donné les IP utilisées, je sais qui vous êtes. Dans la situation actuelle, il y a plus intelligent à faire !

Edit : sur la proposition de Frédéric, je rajoute le plugin Theme Authenticity Checker (TAC) cité par Laurent en commentaire, pour valider les thèmes. Je ne l’ai pas dit ici, mais, de la même façon qu’on n’utilise pas n’importe quoi comme plugin, il faut être très vigilant sur les thèmes qu’on utilise. Je me fournis aussi en thèmes payants chez Elegant Themes et Themes Forest, mais je fais très attention en règle général aux thèmes “non WordPress”.