Quand j’ai fait du support informatique (chez Ionos – 1and1), on disait que le plus gros problème était entre la chaise et le clavier. C’est très vrai en ce qui concerne WordPress, souvent décrié comme un CMS peu sûr. En réalité, il est parfaitement possible de sécuriser son WordPress et de le rendre extrêmement difficile à hacker. Cela passe par :
- des actions à faire lors de l’installation (ou plus tard, mais c’est plus complexe),
- le paramétrage de WordPress,
- le paramétrage de l’environnement (serveur),
- la maintenance régulière de votre site.
La plupart des points que je vous recommande peuvent se faire directement et ne demandent pas de grosses connaissances techniques. Si vous ne vous sentez pas à l’aise, vous pouvez utiliser des plugins, mais cet article vous permettra de comprendre « pourquoi » et donc « comment » les paramétrer.
Travaillez sur un socle technique puissant et
fiable pour tous vos futurs projets.
Commençons par les bases
La majeure partie des hacks se font à partir de failles de sécurités issues de vos thèmes et plugins non à jour.
- Toujours mettre à jour ses plugins et thèmes (vous pouvez activer les mises à jours automatiques, en tout cas pour les mises à jour mineures).
- Limiter le nombre de plugins installés sur son site, même un plugin désactivé peut être une porte d’entrée pour un hacker, et donc
- Supprimer les plugins et thèmes inutilisés, et réservez-vous si vous le pouvez un site Wordpress dédié à vos tests.
- Ne pas installer de plugins Nulled (crackés). Si les plugins WordPress sont en licence GPL, donc légalement modifiables et redistribuables gratuitement, ces plugins contiennent des modifications dans le code qui peuvent ne pas être innocentes et surtout, ils sont mis à jour avec retard par rapport à la version officielle.
- Toujours opter pour un mot de passe fort, c’est-à-dire assez long, avec des chiffres, des lettres, des caractères spéciaux comme le # ou le !. Pour s’en souvenir, il y a des moyens mnémotechniques assez simples. Par exemple jsN!u28!mej!esf peut se mémoriser avec « Je suis né un vingt-huit mai et j‘en suis fier » (ce qui est faux, en plus d’être une phrase idiote) avec trois règles : 3° caractère en majuscule, un ! tous les trois caractères et transcrire les « nombres » en chiffres.
Vous faites ça avec votre date d’anniversaire réelle, et c’est à la fois inoubliable et très difficile à deviner.
A l’installation : modifier le préfixe par défaut de sa base de donnée
Si vous faites votre installation vous-même, WordPress vous proposera « wp_ » comme préfixe de base, c’est-à-dire les trois caractères qui apparaissent devant le nom des tables. La table « posts » sera donc « wp_posts ».
En utilisant un préfixe différent, vous limitez les possibilité de piratage pas injection sql (quelqu’un qui profite d’une faille d’un plugin pour envoyer directement une requête SQL dans votre base de données).
Mon conseil : utilisez un préfixe qui veut dire quelque chose, par exemple monblog faites le suivre de deux _ : monblog__
Pourquoi ? Parce que si vous avez plusieurs installations sur la même base de données, PhpMyAdmin regroupe les tables ayant le même préfixe. Plus facile à visualiser.
Corriger le préfixe de base de données après l’installation ?
C’est un peu compliqué, car le préfixe de base de données est utilisé dans trois endroits différents, et s’il n’est pas cohérent, le site ne va plus marcher.
- Dans le fichier wp-config.php
- Dans la base de données
- Dans les champs de la table wp_usermeta, dans champs dont les noms commencent par le préfixe de base. S’il n’est pas modifié dans cette table, l’utilisateur (donc vous) n’a plus aucun droit ! Il s’agit entre autres des champs $prefix_capabilities, $prefix_user_level, $prefix_autosave_draft_ids et $prefix_user_roles, mais certains plugins ou configurations peuvent en créer d’autres.
Modifier le fichier wp-config.php
Faites une sauvegarde du fichier. Soit vous le téléchargez et vous le modifiez avec un simple éditeur de texte (notepad++ par exemple), soit dans votre explorateur de fichiers, cpanel ou autre, vous le sélectionnez et vous cliquer sur modifier.
Vous allez trouver une ligne plutôt au début qui ressemble à ça :
$table_prefix = 'wp_';
et vous corrigez en
$table_prefix = 'afg__';
Maintenant votre site est cassé. Il va falloir immédiatement modifier les noms des tables
Changer le préfixe dans la base de données
On dispose d’une fonctionnalité bien pratique dans phpMyAdmin, qui permet de changer d’un coup le préfixe d’un ensemble de tables.
D’abord, vous faites une sauvegarde de votre base de données.
Vous sélectionnez les tables, et dans la liste des actions possibles, vous choisissez « Remplacer le préfixe de table ».
Dans la fenêtre qui apparait vous saisissez le préfixe actuel sans le _ (donc pas exactement la même syntaxe que dans le wp-config.php) et le nouveau préfixe. Comme je voulais avoir deux underscores, je n’en mets qu’un.
Reste à pouvoir utiliser le site !
Changer les clés des métadonnées dans la table usermeta
Cela se fait avec une simple requête SQL :
UPDATE afg__usermeta set meta_key = replace (meta_key, 'wp_', 'afg__') where meta_key like 'wp_%'
L’instruction « LIKE » qui n’est pas très performante, à éviter en général, permet ici de sélectionner en une seule fois toutes les métas concernées.
A l’installation : ne pas appeler le premier utilisateur « admin » et sécuriser son identifiant de connexion
Dans le temps, WordPress proposait par défaut d’appeler le premier utilisateur admin. Ce qui permettait plus facilement de craquer le site, on n’avait plus qu’à trouver le mot de passe.
Aujourd’hui, choisissez un identifiant de connexion qui n’a rien à voir avec votre nom ou le nom du site. « JoeLeLapin » par exemple… cela ralentira beaucoup plus les hackers. .
Et si vous avez un vieil utilisateur « admin », vous pouvez changer directement dans la base de données, le champ « user_login » dans la table wp_users.
L’attaque par Brute Force
Comme son nom l’indique, l’attaque « brutale » ne réfléchit pas, n’essaye pas d’exploiter des failles dans un plugin, d’injecter du SQL dans la base de données, elle se met sur une chaise, en face du formulaire de connexion, et elle va envoyer en rafale des couples « identifiant / mot de passe » pour arriver à entrer.
C’est pour cela qu’il est très important d’avoir un identifiant de connexion difficile à deviner et un mot de passe fort.
On va ensuite mettre en place des protections supplémentaires, qui vont toutes avoir le même objectif : ralentir le hacker à tel point qu’il va aller voir ailleurs. Sauf s’il vous en veut personnellement, il ne va pas passer des heures à essayer d’entrer sur votre blog, son objectif premier étant de créer en masse des liens pourris (cialis, casino, etc).
- masquer les noms d’utilisateurs : eh oui, il est possible de voir en front-end l’identifiant de connexion d’un utilisateur.
- le perdre : ne pas utiliser les urls habituelles, en particulier wp-login.php
- le bloquer, en l’empêchant d’accéder à certains fichiers
- rajouter des mots de passe supplémentaires
- lui interdire d’essayer trop souvent de se connecter
Certaines de ces méthodes sont difficiles à réaliser soi-même et nécessitent un plugin.
Masquer les noms d’utilisateurs
Tout d’abord, il faut éviter d’afficher l’utilisateur admin. J’ai toujours deux comptes sur mes sites WordPress : un utilisateur admin, qui ne publie jamais rien et un utilisateur éditeur, qui va publier, corriger, etc (mais qui a beaucoup moins de droits). Bien sûr, ils n’ont pas le même identifiant !
Mais il y a d’autres endroits dans WordPress où on peut trouver les identifiants utilisateurs : les archives d’auteur. Si pour une raison ou pour une autre, vous affichez un lien pour l’auteur d’un article (blog multi-auteurs, envoi vers une biographie pour bâtir l’autorité), ce lien affiche l’identifiant de connexion.
Là vous avez le choix entre deux solutions :
- ne pas avoir de page d’archive auteur
- changer cet identifiant, en utilisant un champ de la base de données qui n’est pas accessible dans l’admin : user_nicename.
Pour quelques utilisateurs, le plus simple est de le faire à la main, via PhpMyAdmin, sinon il existe des plugins.
Imaginons que mon identifiant de connexion soit « bandanarouge » et mon user_nicename « adrienb » quand le hackeur testera, en force brute, toutes les combinaisons possibles, il aura une 404 (donc une réponse négative) pour la page avec mon identifiant auteur/bandanarouge, et une réponse 200 (donc positive) pour la page auteur/adrienb. Il va s’épuiser à essayer toutes les combinaisons de mot de passe possibles pour « adrienb », qui n’existe pas.
Par contre, si je ne veux pas avoir de page d’archive auteur, il suffit de renvoyer mon hacker, via une fonction php :
if (!is_admin()) {
// est-ce qu'on cherche a afficher une page d'archive auteur ?
if (preg_match('/author=([0-9]*)/i', $_SERVER['QUERY_STRING'])) die();
add_filter('redirect_canonical', 'cacher_auteur', 10, 2);
}
function cacher_auteur($redirect, $request) {
if (preg_match('/\?author=([0-9]*)(\/*)/i', $request)) die(); else return $redirect;
}Changer l’URL de connexion
Changer l’url de connexion par défaut (wp-login.php) n’est vraiment utile que si vous avez un blog avec peu d’utilisateurs. Si vous êtes obligés de la laisser apparente (comme l’url de connexion du client WooCommerce), cette méthode perd de son intérêt.
Si vous ne voulez pas pas utiliser un plugin pour faire cela, vous devez :
- créer un nouveau fichier pour remplacer le wp-login.php
- ajouter du code php pour changer l’url.
Faites une sauvegarde de votre fichier wp-login.php qui se trouve à la racine du site.
Ensuite, changez le nom, par exemple en acces-secret.php.
Avec Notepad++, remplacez dans ce fichier toutes les mentions de wp-login.php par acces-secret.php. (Il y en a 14).
Ensuite, il faut éviter que les utilisateurs déconnectés soient renvoyés vers le fichier wp-login.php
Cela se fait en utilisant les filtres suivants :
//déconnexion
add_filter( 'logout_url', 'secret_logout_page', 10, 2 );
function secret_logout_page( $logout_url) {
return home_url( '/acces-secret.php');
}
// Demande de récupération de mot de passe
add_filter( 'lostpassword_url', 'secret_lost_password_page', 10, 2 );
function secret_lost_password_page( $lostpassword_url ) {
return home_url( '/acces-secret.php?action=lostpassword'); Enfin si on veut masquer complètement cette url, et par exemple, faire en sorte qu’il faille saisir « example.com/connexion » pour aller sur le fichier access-secret.php, il faut ajouter une règle de redirection dans le fichier .htaccess (toujours via Notepad++ après une sauvegarde).
RewriteRule ^connexion$ https://example.com/acces-secret.php [NC,L]
Une fois que vous avez tout testé, vous pouvez supprimer votre fichier wp-login.php. Le seul inconvénient : il sera recréé à chaque mise à jour de WordPress, il faudra donc à chaque fois penser à le supprimer.
Ou bien vous pouvez ajouter dans le .htaccess une seconde redirection :
RewriteRule ^wp-login.php https://example.com/acces-secret.php [NC,L]
Ajouter une double authentification de connexion
Quand on parle de double authentification, on pense immédiatement à la banque qui nous envoie un code de confirmation SMS quand on fait un achat en ligne.
C’est bien, mais cela peut aussi être problématique quand on n’a pas accès à son téléphone, pour une raison ou pour une autre. De plus, c’est une solution qui demande un plugin externe, et qui n’est pas obligatoirement compatible avec tous les plugins WordPress.
Ajouter un mot de passe serveur pour accéder à wp-admin
On peut protéger un répertoire ou un fichier de son site, via le fichier .htaccess et un fichier de mots de passe.
C’est très énervant pour le hacker. Il a passé 20 minutes en brute force, il a fini par trouver la combinaison utilisateur / mot de passe, il croit enfin entrer dans le site… raté, on lui demande un nouveau mot de passe (avec un identifiant différent, bien sûr, sinon ce n’est pas drôle).
Pour les générer, vous pouvez passer par la « protection de répertoire » sur votre CPanel, ou le faire à la main, dans ce cas là, au moins pour la première fois, en utilisant un générateur comme celui-ci. Vous saisissez l’identifiant et le mot de passe, et vous cliquez sur « generate ». Une ligne apparait avec la bonne syntaxe : l’utilisateur suivi de son mot de passe encrypté.
totoleheros:{SHA}eXIm+c5HG0kkq8qx4w51qE8goDY=Vous collez la ligne dans un fichier texte, vous pouvez rajoutez autant de lignes que vous voulez ! Vous enregistrez le fichier, .htpasswd exactement comme ça, ou securite.htpasswd, ce qui est important c’est l’extension et vous le téléchargez dans votre répertoire home/mdp
Reste à rajouter dans un fichier .htaccess les règles nécessaires :
AuthUserFile /home/mdp/securite.htpasswd AuthGroupFile /dev/null AuthName "Accès à l'admin" AuthType Basic require valid-user
et placer ce fichier .htaccess à la racine de wp-admin.
Ou bien vous pouvez protéger l’accès au fichier de login en rajoutant ces lignes dans le fichier .htaccess à la base de votre site :
<FilesMatch "acces-secret.php">
AuthName "Accès à l'admin"
AuthType Basic
AuthUserFile /home/mdp/securite.htpasswd
require valid-user
Dans ce cas, le hacker devra passer cette protection avant d’accéder à l’url cachée de connexion qu’il aura déjà eu du mal à trouver !
Sécuriser son site grâce au fichier .htaccess
Comme vous le voyez, le fichier .htaccess est un outil de protection très important. La syntaxe que je vous ai donnée peut aussi être utilisée pour :
Désactiver la possibilité de voir le contenu des répertoires
Dans le fichier .htaccess principal (à la racine) rajoutez la ligne suivante :
Options -Indexes
Protéger le fichier wp-config.php
Ce fichier est particulièrement sensible, puisqu’il contient, en clair, les identifiants à la base de données. Pour le protéger, là encore, quelques lignes dans le .htaccess principal (à la racine du site) :
<files wp-config.php> order allow,deny deny from all </files>
Protéger le fichier .htaccess
Eh oui, le fichier .htaccess peut s’auto-protéger !
<files> order allow,deny deny from all satisfy all </files>
Désactiver le XML-RPC
XML-RPC est une vieille technologie, détrônée par l’API Rest (en décembre 2016 donc) qui permettait à WordPress de communiquer avec des applications externes. Mais comme beaucoup de choses, le fichier existe toujours, au cas où on en aurait besoin. Comme c’est un moyen de communiquer avec l’extérieur, il présente un certain risque, et le plus simple est d’en interdire l’accès via notre fichier .htaccess
<files xmlrpc.php> order deny,allow deny from all </files>
Désactivation de l’exécution de PHP dans certains dossiers
WordPress c’est du php, mais certains répertoires n’ont aucune raison de contenir des fichiers .php et les hackers cherchent parfois à cacher leurs virus dans ces répertoires, c’est-à-dire le fichier wp-content/uploads
Pour désactiver l’exécution de php dans ce répertoire, vous allez créer un fichier wp-content/uploads/.htaccess avec les lignes suivantes :
<files> deny from all </files>
Dans ce cas, vous pouvez … changer de plugin de cache !
Masquer la version de WordPress utilisée
Cette mesure de sécurité est importante surtout si, pour de bonnes raisons, vous avez une version ancienne de WordPress. Elle est visible dans le fichier readme.html qu’on va interdire via le fichier .htaccess, vous savez déjà comment faire !
<files readme.html> order allow,deny deny from all </files>
Elle apparait aussi dans le code source de toutes les pages, dans le header.
Là, il faut rajouter une fonction dans notre plugin :
function securite_remove_version() {
return '4.5';
}
add_filter('the_generator', 'securite_remove_version');
(on peut retourner une chaine vide, mais c’est plus drôle de mettre un très vieux numéro de version !
Il reste encore un endroit où le numéro de version peut apparaître : dans la version des css et des scripts !
En effet, s’il n’y a pas de version spécifiée au moment de l’enregistrement du style ou du script, la version affichée est celle de WordPress ! Pour éviter cela, un code simple :
function securite_remove_wp_version_strings( $src ) {
global $wp_version;
parse_str(parse_url($src, PHP_URL_QUERY), $query);
if ( !empty($query['ver']) && $query['ver'] === $wp_version ) {
$src = remove_query_arg('ver', $src);
}
return $src;
}
add_filter( 'script_loader_src', 'securite_remove_wp_version_strings' );
add_filter( 'style_loader_src', 'securite_remove_wp_version_strings' );
Désactiver l’affichage des erreurs PHP
C’est normalement la configuration par défaut d’un site en production. En effet, les erreurs, en particulier les « Fatal Error », celles qui cassent le site, s’accompagnent de l’affichage détaillé des fichiers qui ont provoqué ces erreurs, donc de leur chemin complet.
Il faut enregistrer ces erreurs (pour y avoir accès et comprendre d’où elles viennent), mais empêcher qu’elles s’affichent pour les visiteurs.
La méthode qui marche à tous les coups, quel que soit le serveur, c’est le wp-config.php.
Avec cette configuration, l’affichage et l’enregistrement des erreurs est désactivé.
define( 'WP_DEBUG', false ); define( 'WP_DEBUG_DISPLAY', false ); define( 'WP_DEBUG_LOG', false ); define( 'SCRIPT_DEBUG', false );
Avec celle-ci, les erreurs sont enregistrées, dans un fichier spécifique (example.com/tmp/wp-errors.log), mais pas affichées :
define( 'WP_DEBUG', true); define( 'WP_DEBUG_DISPLAY', false ); define( 'WP_DEBUG_LOG', '/tmp/wp-errors.log' ); define( 'SCRIPT_DEBUG', false );
Désactiver l’édition de fichiers depuis le tableau de bord de WordPress
Là encore, une simple ligne à rajouter dans le wp-config.php. Vous n’avez aucune raison d’éditer vos fichiers de thème et d’extension à partir de l’admin de WordPress ! Et si vous faites une erreur, vous pouvez complètement planter votre site. Vous serez alors obligés d’aller dans le cPanel pour corriger le fichier. Autant y aller directement !
define( 'DISALLOW_FILE_EDIT', false );
Effectuer des sauvegardes régulières de son site
Ne vous reposez pas uniquement sur votre hébergeur, même s’il fait des sauvegardes. D’abord il ne les garde pas très longtemps, ensuite il peut avoir des problèmes aussi (souvenez-vous des entreprises qui ont perdu toutes leurs données dans l’incendie d’un data-center d’OVH… qui stockait les sauvegardes dans le même data-center).
Vous avez deux choses à sauvegarder très régulièrement : votre base de données et votre répertoire wp-content.
Sauvegarder ses fichiers
Pour les autres fichiers, faites une sauvegarde des wp-config.php et des .htaccess à chaque fois que vous les modifiez, et des fichiers spéciaux que vous pouvez avoir à la racine, comme les fichiers de validation pour les annonceurs, la Search Console, mais vous n’avez pas besoin de les sauvegarder aussi souvent. Enfin, pour « sauvegarder » le Core de WordPress (wp-admin et wp-include) le plus simple est d’aller télécharger la dernière version sur le site de wordpress.org si vous en avez besoin.
Des plugins vous permettent de le faire automatiquement, ou vous pouvez le faire manuellement. Pour les sites qui sont importants pour vous, répartissez vos sauvegardes sur un ou deux disques durs différents, éventuellement dans le Cloud.
Sauvegarder la base de données
C’est plus facile à faire car c’est un plus petit fichier. J’ai automatisé cette sauvegarde avec All in One Migration en ce qui me concerne (en plus d’effectuer des sauvegardes complètes de mes sites).
Fréquence des sauvegardes
Cela dépend de votre site et de votre business, mais la pratique que je vous recommande, c’est d’en faire au minimum une par semaine.
Très classique. Mais vous pouvez aller bien au delà si votre projet est vraiment très important (une fois par jours par exemple, mais attention à votre espace de stockage !).
Je vous invite à héberger vos sauvegardes dans le Cloud, avec, bien sûr, une double authentification pour s’y connecter.
Et bien sûr, une sauvegarde avant chaque modification importante (mise en place de mes recommandations, changement de thème, etc).
Tester ses sauvegardes
On l’oublie souvent.. c’est bien de sauvegarder, mais il faut absolument vérifier qu’on peut utiliser ses sauvegardes. Cela m’est déjà arrivé, à cause d’une mauvaise configuration, de me retrouver avec une sauvegarde que je n’arrivais pas à recharger.
Donc maintenant, si j’utilise un nouvel outil, un plugin ou un outil sur cPanel, je teste que je peux tout restaurer.
Conclusion
Voilà ! Bon, ça fait un peu de boulot quand même, mine de rien. Mais au moins, votre site WordPress aura très peu de chance de se faire hacker. C’est vraiment du temps bien investi.
Ce que je vous recommande de faire pour gagner du temps, c’est de vous créer un « Blueprint » ou un « Starter Site » qui contiendra tous ces points de sécurité. Vous gagnerez ainsi du temps à chaque nouveau WordPress en le dupliquant.
Et si vous souhaitez gagner encore PLUS de temps, vous pouvez utiliser le mien (qui contient énormément d’optimisations supplémentaires) :
