10 tips d’expert pour sécuriser votre WordPress
Aujourd’hui, 2 sites sur 3 dans le monde utilisent WordPress pour des sites e-commerces, vitrines ou blogs. Cela attise malheureusement la convoitise d’organisations malveillantes afin de prendre possession du vôtre, mais pourquoi, comment les en dissuader, comment sécuriser votre WordPress ?
Le Spam SEO consiste à implémenter à votre insu des redirections vers les sites des hackers lorsque l’internaute clic sur un lien de votre site. Vous pouvez mettre un certain temps à vous en rendre compte. La demande de rançon concerne moins de 1% des sites hackés.
Quelles que soient les motivations des hackers, se faire pirater représente un préjudice pour votre organisation. Que ce soit en termes de notoriété, de confiance, ou même financier.
Sans compter le temps perdu à résoudre ce problème et remettre votre site en ordre de marche (si vous avez respecté le point N° 7 ci-dessous)
En moins d’1h, vous pouvez facilement mettre en place ces recommandations techniques afin de sécuriser votre WordPress et décourager une bonne partie des hackers. Chez Ginette, nous appliquons toutes ces bonnes pratiques par défaut lors de nos développements.
1- Supprimer certains fichiers de vos serveurs
4 fichiers sont à supprimer. Non seulement ils ne servent à rien, mais ils permettent de divulguer des infos précieuses aux potentiels hackers.
- monsite.com/readme.html (vérifier si ce fichier est accessible sur votre WordPress).
On peut y lire entre autres en clair les urls d’accès à votre administration même si vous avez pris soin de modifier l’url par défaut (voir point N° 5). - le fichier licence.txt > contient des infos de versions de votre WordPress > le hacker sait donc facilement quelles failles de sécurités exploiter selon vôtre versions.
- wp-admin/install.php (accessible depuis le fichier readme.html) – en cas de problème sur votre base de données, par exemple du fait d’un plug-in défaillant, cette URL proposera de réinstaller votre WordPress !
- wp-config-sample.php > ce fichier sert à générer le fichier sensible wp-config qui contient vos identifiants de connexion à votre base de données. Inutile dans un environnement de production, même si le risque d’accès direct à ce fichier est minime, autant le supprimer. Ne sous estimer pas les capacités techniques des hackers qui tenteront d’accéder à vos données par tous les moyens.
2 – interdire le listing des dossiers
Si certains de vos dossiers ne contiennent pas de fichier index, on peut en lister le contenu et récupérer ce que l’on veut dans ces dossiers. Certains hébergeurs protègent automatiquement cet accès, mais pas tous.
Pour s’assurer que tous les dossiers de votre arborescence ne soient pas éditables s’il manque un index.php ou index.html, il suffit d’ajouter cette ligne dans le fichier .htaccess de votre site :
Options All -Indexes
3 – sécuriser l’accès au fichier wp-config.php
Le fichier wp-config.php contient la configuration de votre WordPress, et notamment les accès à votre base de données. Normalement, on accède pas à un fichier php depuis un navigateur puisque ce type de fichier s’exécute uniquement côté serveur, mais il est plus prudent de sécuriser votre WordPress en interdisant totalement l’accès à ce fichier dans le .htaccess comme cela :
<Files wp-config.php> order allow,deny deny from all </Files>
4 – Empêcher l’injection SQL
Cette méthode consiste à passer par des formulaires pour tenter de faire interpréter des requêtes SQL lors du traitement du formulaire. Normalement, un développement dans les règles de l’art prévoit cela et s’en prémunit. Le développeur a normalement utilisé le principe d’échappement des données utilisateurs et les déclarations préparées Mais, si ce n’est pas le cas, alors, il est facile d’injecter / d’extraire des données à votre insu dans la base de données.
L’injection SQL est LA cause principale de violation de données. Cette technique est complexe et l’objet de cet article n’est pas de vous noyer dans tous les types d’injections différentes qui existent. Passons directement au remède.
Pour qu’une injection SQL fonctionne, il faut indiquer dans la requête le nom de la table de la base de données sur laquelle va s’exécuter la requête SQL. Le nom des tables WordPress est composé d’un préfixe par défaut ‘wp_’ + le nom de la table. Par exemple, la table des utilisateurs est par défaut wp_users. Le plus souvent l’installation est faite par défaut avec ce préfixe. Le Hacker va donc tenter d’injecter sa requête SQL dans la table wp_users par exemple.
Afin de sécuriser votre WordPress, vous devez modifier le préfixe utilisé par défaut. Le hacker ne peut pas le connaître. Modifiez donc le préfixe des tables ‘wp_’ en ce que vous voulez et la majorité des injections seront impossibles.
Le plus simple est de le faire lors de l’installation de WordPress, car il faut juste préciser le nouveau préfixe.
Si vous devez le faire à postériori, il y a plusieurs étapes à réaliser.
- Réalisez une sauvegarde de votre BDD avant de réaliser la suite
- Modifier le fichier wp-config.php > recherchez la variable $table_prefix = ‘wp_’; et modifiez avec votre choix, admettons ici $table_prefix = ‘xx1234_’;
- Renommer les 12 tables WordPress dans phpMyAdmin (sélectionnez la table, puis “opérations” et “renommer la table en” :
‘wp_commentmeta’ renommer en ‘xx1234_commentmeta’
‘wp_comments’ renommer en ‘xx1234_comments’
…idem pour les 12 tables
- Dans la table ‘xx1234_options’ recherchez ‘%wp_%’ dans le champ ‘options_name” et modifiez les quelques valeurs ‘wp_’ par ‘xx1234_’
- Dans la table ‘xx1234_usermeta’ recherchez ‘%wp_%’ dans le champ ‘meta_key” et modifiez les quelques valeurs ‘wp_’ par ‘xx1234_’
5 – Empêcher l’attaque par brute force
L’attaque par brute force consiste à tenter un maximum de combinaisons utilisateurs / mots de passe sur la page de connexion à votre administration par des robots jusqu’à trouver la bonne combinaison.
Le robot du hacker va rechercher la page de connexion à votre back office puis tenter sans cesse des combinaisons. La page de login par défaut sur un site WordPress est monsite.com/wp-login.php (testez sur votre site).
Il y a deux actions à mettre en place pour sécuriser votre WordPress en empêchant l’attaque par brute force :
- renommer l’url de connections monsite.com/wp-login.php
Installer pour cela un plug-in qui se charge de cette opération et vous permettra de choisir une url personnalisée (attention à bien la mémoriser pour y accéder…). ‘wps hide login‘ par exemple fait cela très bien. Vérifier si d’autres extensions seraient plus pertinentes au moment où vous lisez cet article. - Limiter le nombre de tentative de connexion :
Là aussi, vous pouvez installer un plug-in comme “login lock down” qui permettra de paramétrer le nombre de tentatives autorisées, sur telle période, le temps de bannissement, etc. Le plug-in permet également de voir l’historique des attaques subies.
Pour aller encore plus loin, vous pouvez également mettre en place une authentification à 2 facteurs (via SMS) – c’est une excellente sécurité. Il faut pour cela installer un plug-in comme ‘Two Factor Authentication’.
6 – Empêcher la visualisation des N° de versions de vos différents logiciels / plug-in.
Par défaut, le code source de vos pages indique en clair le N° de versions de WordPress. Il est donc très facile pour un hacker de savoir quelle faille de sécurité exploiter, car évidemment il connaît lui aussi l’historique des correctifs apportés. Cette information n’a pas à être divulguée publiquement.
Voici la solution pour crypter le N° de versions.
Dans votre thème, modifiez le fichier ‘fonctions.php’. Voici le code à ajouter dans projet/wp_content/themes/NomDeMonTheme/ ‘fonctions.php’ :
remove_action("wp_head", "wp_generator");
function supprimer_versions( $src ){
$parts = explode( '?', $src );
$ver = '?ver=' . md5( wp_salt( 'nonce' ) . $parts[1] );
return $parts[0] . $ver;
}
add_filter( 'script_loader_src', 'supprimer_versions', 15, 1 );
add_filter( 'style_loader_src', 'supprimer_versions', 15, 1 );
7 – Faire des back-up réguliers
Malgré l’application de toutes ces bonnes règles de sécurité, il n’y a jamais de sécurité garantie à 100%. En mars 2021, un incendie a détruit un data center d’OVH à Strasbourg, et de nombreux sites ont été perdus. Il est donc primordial d’avoir un back-up de ses fichiers et de sa base de données.
Les fichiers sont normalement sauvegardés par votre équipe de développement sur des solutions de versioning telle que Github, GitLab, Bitbucket, Source Forge. La structure de votre base de données est parfois sauvegardée, mais jamais les données.
Certains hébergeurs proposent des options de back-up (gratuite ou payante). Dans ce cas Il faut s’assurer que les données soient bien sauvegardées sur un autre lieu physique pour éviter les déconvenues OVH.
Si vous préférez le faire vous même, il existe des plug-ins adaptés. L’un des plus connus est ‘updraft plus’. Vérifiez au moment de votre lecture s’il en existe de plus pertinents.
Avec ce type de plug-ins, vous pouvez paramétrer la fréquence des sauvegardes si elles sont réalisées automatiquement ou choisir une sauvegarde ponctuelle manuellement. Vous pouvez ensuite récupérer le contenu séparément(BDD,fichiers WordPress, plug-in) en local.
Vous pouvez également paramétrer une sauvegarde automatique sur un service cloud de votre choix (la liste proposée est importante).
Quelle que soit la méthode de sauvegarde, c’est la seule sécurité absolue qui permettra de remettre votre site en route avec les dernières données à la date de votre dernière sauvegarde.
Il faut également s’assurer avant de devoir s’en servir, que votre sauvegarde est utilisable. Tentez donc au moins une fois de réinstaller votre sauvegarde en local avec la solution de sauvegarde mise en place.
8 – protection du .htaccess
Ce fichier n’est pas éditable par défaut…normalement. Par sécurité, il convient de protéger le fichier .htacess dans le .htaccess lui-même.
Comme au point N° 3, ajouter ceci dans votre fichier .htaccess :
<Files .htacess> order allow,deny deny from all </Files>
9 – Supprimer les thèmes et plug-ins non utilisés
Même si ces fichiers ne sont pas chargés par WordPress, il est inutile de laisser des fichiers sur votre serveur qui ne servent à rien. D’autant plus qu’ils ne sont vraisemblablement pas mis à jour, puisqu’ils ne sont pas utilisés. Des éventuelles failles de sécurité sont donc potentiellement présentes. Là encore, pour sécuriser votre WordPress, même si ce risque est moindre, il est inutile de le prendre.
10 – Bonnes pratiques
Enfin, en sécurité il n’est jamais inutile de rappeler les bonnes pratiques, même si elles peuvent sembler élémentaires :
- Modifiez régulièrement vos mots de passe d’administration et utilisez des mots de passe complexes (longueur, caractères spéciaux). Vous pouvez par exemple utiliser des passphrases et remplacer un caractère par un autre (les ‘e’ par des 3, les espaces par une *…)
Personnellement j’ai totalement abandonné les mots de passe facile à retenir. J’utilise un gestionnaire de mots de passe (Laspass) et j’utilise des pwd longs et complexes pour tous mes accès. Je n’ai plus qu’une seule passphrase à retenir, celle de mon gestionnaire de mot de passe. - Vérifier les mises à jours disponibles pour votre thème et vos plug-ins. S’il s’agit de correctifs de sécurité il est important de mettre à jour.
- Ne pas utiliser de thèmes / plug-ins issus de sources non fiables – Ils peuvent contenir du code malveillant. WordPress.org reste sans doute la source la plus sûr.
Conclusion
L’application de toutes ces règles pour sécuriser votre WordPress est simple à mettre en place et efficace. En effet, la très grande majorité des sites WordPress en service n’appliquent pas ces règles. Les robots des hackers vont les trouver et s’en prendre en priorité à ces sites faciles à infiltrer.
Il ne faut cependant jamais sous estimer la capacité de nuisance des hackers. La mise en place de ces sécurités diminue considérablement les risques d’attaque sur votre site, mais le risque zéro n’existe pas.