WordPress c’est bien. Une installation de WordPress sécurisée c’est mieux ! Nous allons voir dans cet article qu’il est nécessaire de penser à quelques points pour s’assurer que son installation de WordPress est sécurisée. Si vous souhaitez directement voir les actions à faire sans avoir besoin de plus d’explication rendez-vous à la section “Résumé”. Pour plus de détails, vous pouvez aller plus loin.

Cet article est organisé comme suit :

1. Résumé des points à voir
2. Historique de WordPress
3. Durcir WordPress
4. Quelques solutions pour vérifier sa sécurité

Résumé

Voici un tableau récapitulatif des actions qu’il est possible de faire pour renforcer la sécurité d’une instance WordPress :

Petit historique de la sécurité de WordPress

WordPress est un CMS (Content Management System) dont la première sortie a été faite en mai 2003. Il s’agit à la fois de l’un des CMS encore en développement actif les plus anciens mais également le plus répandu (ce site est “Fièrement propulsé par WordPress”).

Les fonctionnalités qui ont principalement fait son succès sont son installation facile (un peu comme le fameux “suivant”, “suivant”, “terminer”), son utilisation ne nécessitant pas de connaissance particulière en développement Web ainsi que la grande base d’extensions disponibles.

Comme dans tous les développements applicatifs, des bugs ont été introduis et certains d’entre eux impliquaient des défauts de sécurité. Si on pouvait noter durant les premières années de son développement la présence de vulnérabilités à l’impact très important, cette tendance s’est vue aller à la baisse durant les dernières années.

Néanmoins, malgré la mise en place d’une politique de sécurité et de patch réactifs, de nouvelles vulnérabilités apparaissent encore chaque année. Pourtant, ceci n’a rien de surprenant. En effet, au fil du temps le CMS a intégré tellement de fonctionnalités qu’il est impossible de s’assurer précisément lors du développement de la mise en place des bonnes pratiques de sécurité sur toutes les fonctions.

Il faut quand même reconnaître qu’aujourd’hui on peut considérer une instance de WordPress à jour comme étant sécurisée si celle-ci est bien configurée. Dans les faits, la plupart des vulnérabilités en lien avec WordPress qui sont découvertes le sont dans des extensions qui sont développées par des tiers (le simple fait de se rendre sur le site Exploit-DB permet de s’en rendre compte).

Dans la vraie vie, la plupart des attaquants ne vont pas chercher plus loin que les choses détectables automatiquement (ils cherchent la plupart du temps à se servir de votre application web comme relais de spam ou d’attaque). Avec ces bonnes pratiques de sécurité vous devriez donc vous mettre à l’abri de la plupart d’entre eux.

Attention : ne me faites pas dire, ce que je n’ai pas dit ! La sécurité ultime n’existe pas, ce guide vous propose des solutions pour vous prémunir des attaques les plus basiques. Un attaquant qui a vraiment une dent contre vous pourra toujours pousser l’attaque plus loin.

Des sites WordPress se font pirater tous les jours, c’est donc un risque auquel vous n’êtes pas à l’abri. Consultez le site suivant pour plus d’informations à propos des statistiques de compromission des sites WordPress : http://www.wpwhitesecurity.com/wordpress-security-news-updates/state-of-security-of-wordpress-blogs-and-websites/.

Durcir WordPress

Comme nous l’avons expliqué dans le paragraphe précédent, le code du cœur de WordPress peut être considéré comme raisonnablement sécurisé lorsque l’installation est à jour. Nous allons voir dans la suite quels sont les points de configuration auxquels il est nécessaire de faire attention.

Configuration du serveur et du framework

Une chose à première vue évidente mais à laquelle il est nécessaire de porter attention est la configuration des applications qui permettent de faire fonctionner l’ensemble de l’application web. On a beau avoir une application web bien codée et configurée, si ce qui la soutient est en argile tout s’effondre.

Ces configurations font l’objet de guides spécifiques et peuvent potentiellement être gérées par votre hébergeur (si vous n’êtes pas votre propre hébergeur). Veillez notamment à ce que les applications et les frameworks soient régulièrement mis à jour et informez-vous sur la politique de sécurité de votre hébergeur.

Vous pouvez néanmoins agir à votre niveau pour régler de petits détails très précis (mais qui peuvent avoir un gros impact) de la configuration du serveur afin de renforcer la sécurité de l’application.

Interdiction d’accès à certains fichiers et répertoires

Dans la mesure du possible, mettre en place une liste blanche des adresses IP autorisées à accéder à l’interface d’administration wp-admin. Sous Apache cela se traduirait par l’ajout d’un fichier .htaccess dans le dossier /wp-admin :

Order deny,allow
Deny from all
Allow from 192.168.0.1 #Remplacer par l'IP de votre admin
Allow from 2a01:e34:edb1::1234 #Remplacer par l'IPv6 de votre admin s'il se connecte en IPv6

Il est aussi possible d’interdire l’accès au fichier wp-config.php en éditant le fichier .htaccess à la racine:

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

Attention : à la modification du fichier /.htaccess pensez à bien éditer le fichier en-dehors des balises #BEGIN WordPress.

Voici d’autres choses possibles dans le fichier /.htaccess pour améliorer la sécurité de WordPress :

• Interdire l’accès à wp-includes :

<IfModule mod\_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^wp-admin/includes/ - \[F,L\]
RewriteRule !^wp-includes/ - \[S=3\]
RewriteRule ^wp-includes/\[^/\]+\\.php$ - \[F,L\]
RewriteRule ^wp-includes/js/tinymce/langs/.+\\.php - \[F,L\]
RewriteRule ^wp-includes/theme-compat/ - \[F,L\]
</IfModule>

• Désactiver le listing de répertoires :

Options All -Indexes

Mise en place d'un chiffrement des flux

Si vous avez l’argent pour ou la nécessité de garder des informations personnelles, vous devriez déjà avoir une couche de protection des flux par chiffrement TLS. Dans tous les cas veillez à ne pas vous connecter à vos comptes d’administration de n’importe où pour éviter le vol de vos identifiants par le réseau.

Dans le cas où le chiffrement des flux est mis en place, il est possible de forcer la connexion et l’accès à l’interface d’administration en HTTPS en ajoutant les lignes dans le fichier wp-config.php :

<?php
define('FORCE_SSL_LOGIN', true);
define('FORCE_SSL_ADMIN', true);

Ajout de fichiers index.php vides

L’intérêt de l’ajout de tels fichiers est d’interdire le listing de répertoires et donc l’énumération de fichier dans le cas où il est impossible de modifier la configuration du serveur ou d’ajouter des fichiers .htaccess (ou équivalents, je ne suis pas forcément raciste avec les autres serveurs web 😉 ). Combiné avec ces configurations, cela prémunit d’une éventuelle régression dans la configuration.

Mettre les bons droits d’accès sur les dossiers et fichiers

Comme pour les autres droits, les droits concernant les fichiers doivent correspondre au nécessaire mais surtout au suffisant. C’est-à-dire qu’il faut appliquer les droits minimums nécessaires au fonctionnement de l’application.

Voici une description des droits à appliquer :

• Tous les dossiers doivent être au moins à 755 (drwxr-xr-x)
• Tous les fichiers doivent être au moins à 644 (rw-r–r–)
• wp-config.php doit être à 600 (rw——-)

Sécurisation de la base de données

Il est, indépendamment de l’application, recommandé d’utiliser un utilisateur de base de données dédié à chaque application et ne disposant que des droits nécessaires et suffisants au fonctionnement. Dans le cas de WordPress, il est possible de lui attribuer le privilège GRANT ALL sur sa propre base de données mais en pratique les droits suivants suffisent :

• SELECT
• INSERT
• UPDATE
• DELETE
• ALTER
• DROP TABLE (pour la désinstallation de plugins)
• CREATE TABLE (pour l’installation de plugins)

Par ailleurs mettre en place des préfixes de table non communs rend la tâche d’un attaquant plus difficile car la détermination des noms des tables devient un peu plus complexe en cas d’exploitation réussie d’une injection SQL.

Remarque : je ne dis pas que la sécurité par l’obfuscation est une bonne pratique, mais mettre en place cette mesure permet de retarder un peu un attaquant qui aurait pris le contrôle de la base. Dans l’idéal, conformez-vous aux bonnes pratiques en matière de base de données et veillez à installer des plugins sécurisés.

Enfin, faites régulièrement des sauvegardes de votre bases de données (idéalement périodiquement, du type quotidien ou hebdomadaire en fonction de la vitesse de modification de votre site). Ça n’est jamais agréable de perdre ses données.

Mises à jour

Veillez à toujours bien appliquer les mises à jour. Sur les versions mineures, appliquez-les tout particulièrement si l’éditeur indique qu’il s’agit d’une mise à jour de sécurité. En plus avec WordPress c’est facile ! Gardez tout de même à l’esprit, si vous avez des plugins, de vérifier leur compatibilité avec la nouvelle version.

Si vous en avez la motivation, abonnez-vous aux services de notification de sécurité WordPress. Vous pouvez par exemple régulièrement vérifier les dernières vulnérabilités découvertes dans WordPress et ses plugins à l’aide de WPVulnDB : https://wpvulndb.com/.

Supprimer les plugins non utilisés

Si vous n’utilisez pas une extension pendant une longue durée, supprimez-la ! En effet, une extension désactivée a ses fichiers toujours présents sur votre serveur et peut représenter une vulnérabilité ! Rendez-vous dans le menu des extensions dans votre panneau d’administration.

Contrôler les commentaires

Par défaut, WordPress accepte les commentaires d’utilisateurs. Si vous n’en avez pas besoin, désactivez-les dans les réglages généraux et l’onglet discussion.

Configurer les clés secrètes de WordPress

WordPress, à partir des versions 2.6 et 2.7, utilise une série de systèmes cryptographiques pour garantir la sécurité entre utilisateurs et du CMS lui-même.

Il est possible de “tuner” ces outils cryptographiques en ajoutant un peu d’aléa dans la génération des différents hashs (nonce ou sel pour les connaisseurs). L’intérêt est principalement d’empêcher un attaquant qui a la main sur la seule base de données de ne pas pouvoir “casser” les hashs (les empreintes des mots de passe) sans obtenir le contenu du fichier wp-config.php.

Pour ajouter ce tuning, modifiez le fichier wp-config.php pour y ajouter les lignes suivantes à la fin des autres lignes define :

<?php
define( 'AUTH_KEY',         'mettez ici un truc très long' );
define( 'SECURE_AUTH_KEY',  'mettez ici un truc très long' );
define( 'LOGGED_IN_KEY',    'mettez ici un truc très long' );
define( 'NONCE_KEY',        'mettez ici un truc très long' );
define( 'AUTH_SALT',        'mettez ici un truc très long' );
define( 'SECURE_AUTH_SALT', 'mettez ici un truc très long' );
define( 'LOGGED_IN_SALT',   'mettez ici un truc très long' );
define( 'NONCE_SALT',       'mettez ici un truc très long' );

Ces chaînes doivent rester secrètes ! Gardez-les bien dans un endroit protégé !

Attention : la modification de ces primitives va déconnecter tous vos utilisateurs et les forcer à changer leur mot de passe ! Ne faites cette opération que si vous savez ce que vous faites.

Notez que ces valeurs sont en général générées automatiquement par WordPress si elles ne sont pas spécifiées. En cas de compromission (un attaquant a réussi à s’introduire sur votre application), il est recommandé de les changer.

Si vous n’êtes pas inspirés (vous n’avez pas besoin de retenir ces valeurs), vous pouvez générer ces lignes automatiquement ici : https://api.wordpress.org/secret-key/1.1/salt/

Désactiver l’éditeur de fichier de WordPress

L’éditeur de fichiers WordPress permet la modification directement depuis l’interface d’administration de WordPress de fichiers présents sur le serveur.

Désactiver celui-ci permet d’éviter la modification non désirée de fichiers nécessaires au bon fonctionnement de WordPress. Pour ce faire ajouter la ligne suivante au fichier wp-config.php :

<?php
define( 'DISALLOW_FILE_EDIT', true );

Supprimer le numéro de version de WordPress de la balise meta Generator

La balise meta Generator a pour but de décrire l’application web au navigateur dans le code HTML. Or le numéro de version d’une application est une aide pour un attaquant afin de connaître les vulnérabilités l’affectant.

Si la disparition du numéro de version de cette balise n’est pas la panacée (on peut par exemple déterminer le numéro de version à partir des signatures des différents fichiers statiques tels que les feuilles de style), cela rend la tâche de la prise d’empreintes un peu plus difficile pour un attaquant.

Le plus simple pour retirer cette information est d’éditer le fichier functions.php pour y ajouter la ligne suivante :

<?php
remove_action('wp_head', 'wp_generator');

Sécurisation des utilisateurs

Ne soyez pas stupide : utilisez un mot de passe fort pour votre/vos comptes ayant des droits de modification. Un mot de passe fort c’est :

• 12 caractères minimum,
• Majuscules/minuscules,
• Chiffres,
• Caractères spéciaux,
• Pas de mot du dictionnaire (même en 1337 5|°34|<).

Dans l’idéal utilisez un gestionnaire de mots de passe (comme Keepass : http://keepass.info/).

Pour vous prémunir des attaques par force brute, vous pouvez mettre en place un système de captcha sur l’écran d’authentification (des plugins le font) ou encore mettre en place une liste blanche des accès à wp-login.php si vous en avez la possibilité.

Si vous avez plusieurs utilisateurs, renseignez-vous sur les différents droits proposés par le CMS :

• Super Administrateur : accès à tout, c’est l’administrateur du serveur Web,
• Administrateur : l’administrateur qui est défini à l’installation de WordPress (et les autres définis par la suite). Il a tous les droits sur l’application,
• Editeur : il peut publier mais aussi éditer ou supprimer les posts des autres,
• Auteur : il peut publier et modifier ses propres articles,
• Contributeur : il peut éditer et créer ses propres articles mais ne peut pas les publier,
• Abonné: il ne peut pas faire de modification ou de publication d’article et ne peut que gérer son profil et ses commentaires.

Vérifier la bonne application des solutions de sécurité

Comment faire pour vérifier que tout ce que vous avez mis en place fonctionne correctement ?

Vous avez plusieurs solutions qui vont de tester à la main, scanner automatiquement ou encore faire appel à des entreprises d’audit spécialisées.

Évidemment, la dernière solution coûte cher mais est la manière la plus efficace de s’assurer qu’on est bon lorsqu’on n’est pas spécialiste.

Cependant, vous avez la possibilité de tester vous-même avec quelques outils automatiques non-intrusifs.

Certaines extensions WordPress font des contrôles réguliers de l’intégrité de vos composants WordPress et vous permettent de vérifier qu’aucun code malveillant n’a été intégrée dans le code de votre application WordPress.

Quelques exemples :

• WP Security Audit Log : https://wordpress.org/plugins/wp-security-audit-log/
• Sucuri Scanner : https://wordpress.org/plugins/sucuri-scanner/

Une autre approche est de tester votre application depuis l’extérieur. J’utilise par exemple pour tester mon blog WPScan (http://wpscan.org/) qui est basé sur l’excellente base de données WPVulnsDB (https://wpvulndb.com) et fait une revue de la plupart des points de configuration de WordPress qui sont visibles de l’extérieur.

Et voilà ! Tout ça fait beaucoup de choses à prendre en compte (et on peut encore en trouver d’autres en suivant les liens ci-dessous) mais ceci contribuera à grandement améliorer le niveau de sécurité de votre application WordPress. Je vous invite tout de même à réfléchir lorsque vous mettez en œuvre l’une des actions décrites dans ce guide. Elles ne sont malheureusement pas toutes sans incident et demandent parfois certaines conditions. N’appliquez donc pas aveuglément chacune des actions décrites ici, j’ai fait de mon mieux pour expliquer les raisons sous-jacentes mais si vous ne comprenez pas les raisons d’un de ces points, n’hésitez pas à me contacter ou laisser un commentaire.

Sources

1. Sortie de WordPress : https://wordpress.org/news/2003/05/wordpress-now-available/
2. Statistiques CVE à propos de WordPress : http://www.cvedetails.com/product/4096/Wordpress-Wordpress.html?vendor_id=2337
3. Guide de durcissement de WordPress de l’OWASP : https://www.owasp.org/index.php/OWASP_Wordpress_Security_Implementation_Guideline
4. Guide de durcissement de WordPress de wpmudev : https://premium.wpmudev.org/blog/keeping-wordpress-secure-the-ultimate-guide/
5. The WordPress Codex : http://codex.wordpress.org/Hardening_WordPress