WordPress, vaccin contre le piratage

WordPress est la plate forme de blog la plus populaire au monde. C’est bien pratique puisque vous disposez ainsi d’une grosse communauté lorsqu’il vous faut un coup de main, mais revers de la médaille, WordPress est aussi une cible de choix pour les pirates de tous poils. Du coup, la sécurité est un point auquel il faut faire particulièrement attention. Je ne pense pas vous apprendre grand chose puisque le net regorge d’articles vous expliquant comment bien sécuriser votre blog. Pourquoi est-ce que j’en rédige un nième dans ce cas ? Ce n’est pas que je les trouve nuls ou incomplets, mais lorsqu’on parle sécurité, bien souvent, on vous assène de grands principes, accompagnés de faites ça, et puis ça, installez ce plugin… C’est bon vous êtes blindé. Du coup, vous n’avez pas bien compris pourquoi vous devez faire telle ou telle chose, et c’est bien dommage, car d’une part vous oublierez certainement certains points, d’autre part, vous perdez une occasion d’apprendre des trucs, et ça c’est bien dommage, n’est-ce pas ? Alors mettons nous dans la peau d’un vilain pirate et tentons d’attaquer votre blog pour mieux comprendre les parades. Are you ready ? Let’s go !

Choisir de bons mots de passe

Vous seriez surpris de voir le nombre de blogs ayant pour login et mot de passe admin/admin ou admin/1234. Si je voulais m’incruster chez vous, la première chose que je ferais est d’essayer ces simples mots de passe. Si ma tentative n’est pas immédiatement couronnée de succès, j’en rajouterais une couche en utilisant une attaque par dictionnaire pour le login admin ainsi que celui correspondant à l’auteur des articles du blog.

Trois leçons à tirer ici :

  • N’utilisez pas admin comme login, c’est la première chose à laquelle un pirate penserait
  • Faites en sorte que le pseudo qui apparaisse lorsque vous publiez des articles ne soit pas le même que votre login de wordpress. Vous pouvez pour cela attribuer un pseudonyme à votre compte : utilisateur –> votre profil –> pseudonyme
  • Trouvez vous un bon mot de passe !! On ne le répètera jamais assez, mais dans un cas un mot de passe logique (votre date de naissance etc…) sera retrouvé rapidement si l’attaquant se donne la peine d’y réfléchir, dans l’autre cas, les mots de passe simples ne résisteront pas à une attaque par dictionnaire

Il peut aussi être intéressant de limiter le nombre de tentatives de connexions provenant d’une même adresse IP – un peu à l’image du code pin sur votre téléphone. Cela permettra justement de déjouer les attaques par dictionnaire. Il existe pour cela le plugin Login LockDown. À savoir que si vous êtes un handicapé ambulant et que vous n’êtes pas foutu de vous souvenir de votre mot de passe, faudra appeler votre service client pour qu’il vous file le code PUK il faudra que vous patientiez quelques instants avant de pouvoir essayer à nouveau.

L’accès à l’interface d’administration de WordPress ne donne pas accès au serveur en lui-même, cela peut juste faciliter la chose. Une des premières choses qu’un attaquant fera s’il arrive à accéder à l’interface d’admin, c’est d’injecter du code dans votre thème pour gagner l’accès au serveur.

Cela est rendu possible par la fonctionnalité « Éditeur » qui se trouve dans le menu « Apparence ». Cette fonction bien pratique permet d’éditer les fichiers de WordPress directement depuis WordPress lui-même. C’est top pour des petites modification CSS par exemple. Mais comme chaque pièce à deux faces, cette praticité est a ses revers au niveau de la sécurité. Je vous conseille donc de désactiver cette fonctionnalité via cette petite ligne dans le wp-config.php :

define('DISALLOW_FILE_EDIT', true);

Garder WordPress à jour

Les failles des anciennes versions de WordPress sont connues, il est donc important de faire les mises à jour du CMS dès leur apparition. Et pour cause, avoir une ancienne version de WordPress avec des failles avérées, c’est un peu comme filer le mode d’emploi d’intrusion à vos ennemis, y’a plus qu’à se faufiler dans la faille de sécurité, vous admettrez que c’est un peu con…

Certains préconisent de cacher la version de WordPress, je ne trouve pas vraiment cela utile si vous respectez le conseil ci-dessus et que vous êtes toujours à jour. Ça peut même avoir un effet dissuasif de proclamer que vous êtes à jour, c’est un peu comme l’écriteau /!\ chien méchant, accroché au portail de vos voisins ! Et comme le diraient si bien nos politiciens, lorsqu’on à rien à cacher…

Les mises à jour régulières valent aussi pour les thèmes que les plugins, car ils sont aussi potentiellement porteurs de failles.

WordPress dans ses versions récentes permet d’automatiser les mises à jour. Pour cela, tout se passe dans wp-config.php

// autoriser toutes les maj auto (majeures et mineures)
define('WP_AUTO_UPDATE_CORE', true);

// automatiser seulement les maj mineures
define('WP_AUTO_UPDATE_CORE', 'minor');

// et pour tout interdire
define('WP_AUTO_UPDATE_CORE', false);

Et pour activer les mises à jour automatique pour les thèmes et plugins, il faut placer un filtre dans le function.php de votre thème :

// active les maj des plugins
add_filter('auto_update_plugin', '__return_true');

// active les maj des thèmes
add_filter('auto_update_theme', '__return_true');

Attention toutefois, s’il reste globalement sûr d’automatiser les mise à jours du cœur de WordPress, c’est un peu plus risqué d’automatiser celle des plugins, surtout si vous en avez de nombreux et/ou des exotiques…

L’idéal étant bien entendu de faire les mises à jour manuellement et de vérifier que tout fonctionne pour résoudre le plus rapidement possible un bug éventuel. Cependant, si vous êtes du genre oisif avec les maj, il vaut peut-être mieux prendre le risque d’avoir un bug à cause de celle-ci que celui d’avoir une faille béante publiquement connue.

Chouchouter les fichiers sensibles

Certains fichiers renferment des informations particulièrement sensibles. En l’occurrence, wp-config.php, il contient l’admin et le mot de passe de votre base de données, les préfixes de vos tables etc… Autant vous dire que c’est à ne pas mettre à la disposition de tout le monde. Sinon, autant afficher les infos directement dans votre header. Empêchez donc quiconque d’accéder à ces fichiers en faisant un bon paramètrage de votre .htaccess :

MAJ : suite à quelques remarques dans les commentaires, merci à JM et à Scout123, normalement, le wp-config.php, même s’il est accessible, n’affichera rien dans le navigateur puisque le php est interprété et que le code n’est pas sensé afficher quoi que ce soit. En revanche, comme le note Scout123, si le module php plante tandis qu’apache reste en fonction (ce pourrait être le résultat d’une attaque…) alors la page php serait affichée telle quelle par apache. Donc même si tout cela est peu probable, un peu de sécurité supplémentaire ne coûte rien !

<Files wp-config.php>  
order allow,deny  
deny from all  
</Files>

Normallement, si votre serveur est bien configuré, il n’est pas possible s’avoir accès au .htaccess. Si ce n’est pas le cas, procédez comme ci-dessus, en remplaçant wp-config.php par .htaccess.

En outre, pensez bien à empêcher le listage de vos dossiers si ce n’est pas déjà fait. Sans cela, on pourrait se promener dans votre arborescence à la recherche d’indices susceptibles de nous donner un coup de pouce pour venir vous faire un coucou, allez directement voir les plugins qui sont installés chez vous serait un bon début. Pour empêcher cela, retour au .htaccess :

Options All -Indexes

Restreindre l’accès à l’interface d’administration

Là ça n’est pas un impératif, mais c’est un plus pour la sécurité. Vous pouvez mettre un .htaccess qui restreint l’accès à tout votre dossier admin. De cette manière, si quelqu’un veut tenter de deviner votre mot de passe, ou veut tenter une attaque par dictionnaire, il devra d’abord franchir ce premier sas de sécurité. Si vous voulez mettre cela en place, c’est très simple, nous allons encore faire appel au .htaccess, mais cette fois-ci, nous allons en créer un nouveau, que nous allons placer dans le dossier admin :

AuthUserFile chemin-absolu/.htpasswd
AuthName "Guess what !"
AuthType Basic
Require Valid-User

Vous devez ensuite créer un fichier .htpasswd (vous pouvez le nommer comme bon vous semble, le tout est que ce soit cohérent avec AuthUserFile), dans lequel vous placerez votre login et votre mot de passe comme ceci :

pseudo:mot_de_passe

Note : il est possible d’encoder le mot de passe en MD5 (sauf si vous êtes hébergé chez Free), il vous suffit pour cela d’utiliser un encodeur MD5 et de coller le hash MD5 à la place du mot de passe.

Enfin, vous pouvez placer ce fichier où bon vous semble. N’oubliez pas de renseigner le chemin absolu d’accès au fichier. Attention, ceci est un chemin serveur et non un chemin internet. Pour le trouver, vous pouvez créer un fichier php qui vous indiquera le chemin. Nommez votre fichier chemin.php, placez le à l’endroit où vous souhaiter mettre votre .htpasswd et accédez-y via votre navigateur. Vous n’avez plus qu’à copier/coller ce chemin dans votre .htaccess en remplaçant chemin.php par .htpasswd !

<?php
realpath("chemin.php")
?>

Blindé n’existe pas

On peut faire tout ce que l’on veut, le 100% sécurisé n’existe pas en informatique, il faut le savoir et vivre avec, c’est tout. Quoi ? ça ne met pas un peu de piment dans votre vie tout d’un coup ?! Quoi qu’il en soit, ce qui est certain, c’est qu’il est très sage (je me l’impose, mais c’est vrai que si vous aimez le danger… libre à vous) de faire des sauvegardes régulière de sa base de donnée afin de pouvoir la restaurer en cas de piratage. De même, pensez à sauvegarder votre dossier uploads, qui contient tous les fichiers multimédias de vos articles !

Je crois qu’on a à peu près fait le tour. Si j’ai oublié quelque chose, dites-le moi. Et bon blogging !

Déjà 10 réponses, rejoignez la discussion !

    • Buzut

      dit :

      Je ne connaissais pas le site , pratique, il permet aussi de générer des mots de passe, pour ceux qui n’ont pas d’inspiration…
      Merci du conseil

  • JM

    dit :

    Hello.

    Très bon article sur le sujet.

    J’ai juste une petite remarque sur le fait de bloquer l’accès au wp-config.php … ça ne sert pas vraiment à grand chose dans la mesure où même si quelqu’un demande ce fichier, il n’en obtiendra qu’une page vide puisque rappelons le, le code PHP est géré côté serveur.

    • Buzut

      dit :

      Tu as tout à fait raison, on n’obtiendrait qu’une page blanche. J’ai donc enlevé le paragraphe en question : pas pertinent !
      Merci de la correction ;)

      • scout123

        dit :

        @JM : Objection. Si le module PHP plante, mais que Apache survive au bug, le contenu serait alors affiché accidentellement. C’est rare, mais un peu de sécurité supplémentaire ne fait pas de mal ;).

        • Buzut

          dit :

          C’est sur que pour qu’un tel cas ne doit pas arriver tous les deux matins, certaines attaques doivent permettre de faire planter le module PHP…
          Loi de Murphy oblige, je vais mettre à jour l’article !

          • tpouzet

            dit :

            A noter que quand tu édites wp-config.php, avec vim, emacs, nano, tu as un fichier temporaire non couvert par le htaccess qui est créé, avec une extension non ‘php’ donc lisible par tous : wp-config~ .wp-config.php.swp etc. etc.

            Il faut interdire de servir à apache tout sauf un subset d’extensions : css, js, html, php, png, jpeg, jpg, …

          • Buzut

            dit :

            Merci tpouzet de cette intéressante remarque ! Il faut donc créer une whitelist et interdire à apache de servir tout autre chose que ce qui y figure.

            On retient aussi qu’il est sage de ne pas éditer ces fichiers avec nano/vim et consorts…

  • Buzut

    dit :

    Hello !
    Ouais c’est sur que sans base de donnée et sans php, c’est forcément plus sur ! Mais tu perds quand même un certain nombre d’avantages, dont les commentaires sans faire appel à un service extérieur.
    Et puis si je dis au gens, comment sécuriser wordpress ? Installez octopress les gars ! Je vais me faire frapper moi :mrgreen:

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *