Protection de l’administration de son WordPress

Hello les amis !

L’interface d’administration d’un site ( appelé aussi back office ou BO ) est très importante puisque c’est d’ici que tout s’effectue sur votre site/blog.
Imaginez-vous qu’un pirate arrive à avoir un accès, vous aurez plus qu’à faire une restauration des fichiers et de votre base de données ( c’est logique après tout ).

Nous allons donc voir dans cet article comment protéger son interface d’administration pour un blog sous WordPress.
Réparer ce genre d’attaque c’est bien, pouvoir la contrer d’avance, c’est encore mieux 🙂

Comment je sais si je suis attaqué ?

C’est assez simple. L’accès à cette interface nécessaire une authentification, authentification que vous devez faire sur la page « wp-login.php ».
Et cette page est aussi valable pour le dossier « wp-admin » si vous n’êtes pas authentifié.

Ensuite pour savoir si vous êtes en train de vous faire attaqué, c’est simple, il vous suffit de regarder vos fichiers de logs.
Il vous suffira de vous penchez sur des requêtes de type « POST » ( envoi des données comme login/password ) sur la page « wp-login.php ».

Nous prennons l’exemple ici avec notre fichier d’accès « access.log ». Et exécuter cette commande sous Linux :

echo -ne "Nombre d'accès : $(cat access.log | egrep "POST" | egrep "wp-login.php" | wc -l)\n"

Suite à cela, vous verrez les nombres d’accès, tous ne sont pas forcement faux mais en avoir plus de 30, cela reste bizarre quand même.

Pourquoi je ne bloque pas l’adresse IP ?

C’est une excellente question ! Regardez bien votre fichier et particulièrement sur les adresses IP.
Il sera possible de voir que tous les accès change d’adresse IP et un blocage sera pas efficace ( même pas du tout ).

Cette commande vous fournis les adresses IP :

cat access.log | egrep "POST" | egrep "wp-login.php" | awk '{ print $1 }' | sort | uniq -c | sort -n

Vous vous imaginez déjà en train de bloquer toutes ces adresses IP à la main ? Vous n’avez pas terminé :p

Comment je fais ? Je panique !

Le hacker ( nous allons le nommer de cette manière ), effectue ce que l’on appelle une attaque de type brute force.
Il ne connais pas réellement le login et mot de passe que vous utilisez, il utilise donc un dictionnaire afin de les tester un par un ( et cela prend beaucoup de temps ).

La panique arrive lorsque nous voyons le serveur chargé comme un vieux bourin. Apache fournis tellement de requêtes qu’il n’arrive plus à suivre.
Et cela ce termine en crash ( surtout si vous avez un petit serveur ), vous rebooter et 10 minutes plus tard, il crash de nouveau ( cela peut aussi durer des jours ).

Comme nous ne pouvons pas bloquer l’adresse IP, nous allons bloquer le User-Agent. Dans le cas de cet article, ce sera « Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0 » que nous allons prendre. Après plusieurs cas, il s’avère qu’il ne change pas beaucoup. Nous allons le bloquer uniquement sur la page « wp-login.php », comme cela vous ne bloquez pas l’accès au site en lui même.

Blocage du User-Agent

Je vous recommande de faire cela directement dans la configuration vhost d’Apache ( oui nous verrons seulement Apache ).
Dans le cas contraire, il reste possible de le mettre en place dans votre fichier « .htaccess », cela fonctionne aussi mais consommera plus de ressources sur le serveur.

Cette ligne est à mettre juste en dessous de votre directory « <Directory /PATH> »

SetEnvIfNoCase User-Agent "Mozilla\/5.0 \(Windows NT 6.1\; rv:19.0\) Gecko\/20100101 Firefox\/19.0" bad_user
 Deny from env=bad_user

Un « configtest » et un « graceful » suffirons à recharger cette nouvelle configuration.

Je le valide comment ?

Vous l’avez mis en place, maintenant validons le bon fonctionnement.
Le mieux est de faire un « tail -f » sur votre fichier de log afin de tout voir en direct. Utilisez « egrep » afin de les filtrer, je suis sympa je vous donne la commande :

tail -f access.log | egrep "POST" | egrep "wp-login.php"

Voici un morceau de log dans mon cas :

........ "POST /wp-login.php HTTP/1.0" 200 11798 "www.djerfy.com/wp-login.php" "Mozilla/5.0 ..........

Le nombre en gras qui ce trouve au dessus correspond à la taille de la page renvoyer, enfin c’était valable avant notre configuration.
Depuis la mise en place, vous devriez avoir cette taille à « 0 », si ce n’est pas le cas, vous avez du faire une erreur.

Sécurisez aussi le dossier « wp-admin »

Nous allons aussi sécuriser le dossier « wp-admin » par une simple authentification « .htaccess ». Vous devez donc vous mettre dans ce dossier afin de faire la suite.
Mettons en place notre fichier « .htaccess » :

# Protection sur l'accès à l'interface ADMIN de WordPress
 AuthName "Private authentification"
 AuthType Basic
 AuthUserFile ".htpasswd
 Require valid-user

Nous faisons ensuite la création de notre couple de login/passwd de cette manière ( l’option « -c », c’est uniquement pour le « create » ) :

htpasswd -c .htpasswd ADMIN

Conclusion

Avec ces astuces, je pense que vous serez déjà protégé un minimum. Tout cela avec Apache et non pas avec des modules WordPress à la con 🙂
Vous pouvez toujours ensuite mettre en place des nouvelles règles de redirection suivant le REFERER …