Contrôles de sécurité du site. WP-CLI pour les administrateurs de sites

Si vous êtes propriétaire ou administrateur d’un site web, l’une de vos responsabilités principales est de le garder sécurisé et protégé. Pour cela, il est essentiel d’utiliser tous les outils à votre disposition afin de rester efficace et de vous assurer de bien faire les choses.

WP-CLI, une interface en ligne de commande pour WordPress, fait partie de ces outils.

Si vous pensez que c’est trop complexe pour vous, restez avec nous : cet article est justement fait pour vous. L’objectif est qu’à la fin, vous vous sentiez assez en confiance pour essayer quelques commandes par vous-même.

Aucune installation nécessaire (en général)

L’installation de WP-CLI se fait en ligne de commande et peut paraître intimidante, surtout qu’elle varie selon les systèmes d’exploitation et les serveurs.

Mais bonne nouvelle : beaucoup d’hébergeurs proposent WP-CLI prêt à l’emploi, et parfois avec leurs propres commandes personnalisées.

Cherchez « WP-CLI » dans leur base de connaissances, documentation, blog, ou FAQ pour savoir comment l’utiliser sur leur plateforme.

Si votre hébergeur propose WP-CLI, cela signifie généralement que vous avez un accès SSH à votre site.

Même si vous ne savez pas ce qu’est SSH, retenez simplement que c’est une connexion sécurisée.

Avec le temps, vous serez peut-être tenté d’en faire plus avec le terminal, mais ce n’est pas une obligation.

La beauté de WP-CLI, c’est que vous pouvez l’utiliser à votre niveau, en fonction de vos compétences.

Table des matières

Anatomie d’une commande

Avant de taper vos premières commandes, voici comment elles sont généralement structurées :

wp <nom> <verbe> --option-1 --option-2

Besoin d’aide ?

À n’importe quel niveau de la structure de commande (principal, nom ou verbe), vous pouvez utiliser un paramètre global nommé --help, qui révélera toutes les sous-commandes et tous les indicateurs que vous pouvez utiliser pour la commande ou la sous-commande en cours.

Par exemple, si vous voulez voir quelles sous-commandes (verbes) vous pouvez utiliser avec la commande plugin, vous pouvez taper :

wp plugin --help

Si vous voulez connaître tous les indicateurs que vous pouvez utiliser avec une sous-commande (ex: commande de mise à jour du plugin ici), vous devez taper :

wp plugin update --help

Pour sortir de l’écran d’aide, tapez simplement q et appuyez sur Entrer.

Êtes-vous à la racine de WordPress ?

Toutes les commandes présentées dans cet article doivent être exécutées dans le dossier racine de WordPress. Ce dossier est identifiable par la présence des répertoires suivants : /wp-admin, /wp-includes et /wp-content.

Lorsque vous vous connectez à votre terminal d’hébergement, il est fort probable que vous ne soyez pas à la racine de WordPress. Cela varie selon le fournisseur, mais le plus souvent, vous êtes au moins un niveau supérieur.
Pour lister les fichiers présents dans le dossier ou vous êtes, utilisez la commande ls. Pour connaître le chemin du dossier dans lequel vous êtes, tapez pwd

Sortie du terminal pour répertorier le contenu du répertoire racine du fournisseur d’hébergement.

Dans certains cas, vous verrez public_html, dans d’autres www, peut-être même le répertoire portant le même nom d’utilisateur sur le serveur. Votre racine WordPress se trouve dans l’un de ces répertoires. Pour voir le contenu de ces répertoires, sans y accéder, utilisez la même commande, suivie du nom du répertoire :

ls public_html/

Fichiers et dossiers racine WordPress – sortie du contenu de la liste dans la commande du répertoire public_html.

Maintenant que nous avons localisé la racine de WordPress, allons-y. Utilisez la commande cd pour vous rendre dans le dossier :

cd public_html/

Vous pouvez relancer la commande ls pour vous assurer que vous êtes bien à la racine de WordPress. Nous y resterons jusqu’à la fin de cet article. Faîtes donc comme chez vous.

Mises à jour sécurisées

Pour garantir la sécurité de votre cœur WordPress , assurez-vous de le maintenir à jour avec des mises à jour sécurisées. Ces mises à jour sont également appelées « mineures ».

Il existe deux types de mises à jour du logiciel principal de WordPress qui deviennent disponibles pour votre site Web :

• Mises à jour majeures du noyau WordPress incluant de nouvelles fonctionnalités. Une mise à jour est considérée comme « majeure » car son numéro suit le modèle suivant : 4.0, 4.1, 4.2, 4.3, 4.4, etc.
• Les mises à jour mineures principales incluent souvent des versions de maintenance, des correctifs de sécurité et des mises à jour des fichiers de traduction. Une mise à jour est considérée comme « mineure » car son numéro est ajouté à celui de la version majeure actuelle. Par exemple : 4.4.1, 4.4.2, 4.4.3, etc.

 Sources : Learn.WordPress.org , Gestion des mises à jour

Pour la mise à jour vers une version majeure, consultez votre développeur. Il est nécessaire de tester cette mise à jour en local afin de garantir le bon fonctionnement des nouvelles fonctionnalités. 

Vous pouvez toutefois effectuer vous-même des mises à jour mineures. Vérifiez d’abord la version dont vous disposez :

wp core version

Cela vous donnera le numéro de version majeure et mineure actuellement installée pour votre site Web, par exemple 6.5.4.

Ensuite, nous voulons vérifier si une mise à jour est disponible :

wp core check-update --minor

Tableau des mises à jour disponibles – sortie de la commande WP-CLI pour vérifier si des mises à jour de version mineures sont disponibles.

L’omission de cette option –minor indiquera à WP-CLI de rechercher les versions majeures. Si votre site WordPress est à jour avec les versions mineures, le message suivant s’affichera :

Success: WordPress is at the latest minor release.

Si, toutefois, vous voyez un tableau avec version, update_type, et package_url, alors une mise à jour est disponible et vous devriez mettre à jour votre site Web le plus tôt possible :

Sortie du terminal pour la commande WP-CLI pour la mise à jour de WordPress vers la dernière version mineure.

Les mises à jour mineures ne devraient jamais endommager votre site web ; il s’agit simplement de corrections de bugs. Quoi qu’il en soit, vérifiez votre site web pour vous assurer que tout fonctionne correctement. Si quelque chose ne fonctionne pas correctement, voici deux choses à faire :

Et voilà ! Vous avez exécuté vos premières commandes WP-CLI et réalisé quelque chose d’utile. Plus important encore, votre site web est toujours actif. Félicitations !

Des principes similaires s’appliquent à la mise à jour des thèmes et des extensions . Tous deux disposent d’un indicateur --dry-run permettant de vérifier les extensions et les thèmes dont les mises à jour sont disponibles, sans les mettre à jour :

wp plugin update --all --dry-run

Tableau des plugins avec mises à jour disponibles – sortie de la commande WP-CLI pour vérifier les mises à jour disponibles pour les plugins.

Pour vérifier la version mineure, le flag (indicateur) --minor est également disponible :

wp theme update --all --minor --dry-run

Si aucune mise à jour n’est disponible, un message s’affichera No theme/plugin updates available. Dans le cas contraire, un tableau s’affichera avec tous les plugins ou thèmes dont les mises à jour sont disponibles, leurs versions actuelles et disponibles, ainsi que leur statut (actif ou inactif).

Tableau des thèmes avec mises à jour mineures disponibles – sortie de la commande WP-CLI pour vérifier les mises à jour mineures disponibles pour les thèmes.

Pour mettre à jour uniquement certains plugins ou thèmes, vous pouvez les spécifier en utilisant le nom du tableau ci-dessus :

wp plugin update akismet --minor

Sortie de la commande WP-CLI pour la mise à jour du plugin Akismet vers la dernière version mineure.

Si, pour une raison ou une autre, vous ne souhaitez pas exécuter ces mises à jour en production, vous pouvez toujours les tester d’abord sur un site web de test. Tous les hébergeurs sérieux vous fourniront une version de test de votre site web pour ce type de tests.

Surveillance des modifications de fichiers

Souvent, lorsque votre site web est piraté, des modifications sont apportées à ses fichiers. Il peut s’agir d’un nouveau fichier n’importe où dans votre système de fichiers, ou d’une modification de fichiers existants. Vous pouvez utiliser WP-CLI pour surveiller ces modifications.

La vérification des modifications apportées à vos fichiers s’effectue avec la sous-commande verify-checksums :

wp core verify-checksums

Cela comparera vos fichiers principaux WordPress aux versions connues. Si vous souhaitez vérifier une version spécifique, vous pouvez la spécifier :

wp core verify-checksums --version=6.5.2

Commandes WP-CLI pour vérifier les fichiers principaux et leurs sorties.

Si la vérification échoue, vous verrez ce message :

Error: WordPress installation doesn’t verify against checksums.

Avant ce message, vous verrez également la liste des fichiers qui n’ont pas été vérifiés par rapport à la somme de contrôle.

Cela peut signifier que votre installation WordPress est corrompue, mais il est également possible que vous ayez mal saisi la version. Pour être sûr d’avoir saisi la bonne version, vous pouvez utiliser :

wp core verify-checksums --version=$(wp core version)

Comme vous pouvez le constater, dans la substitution de commande , $() nous exécutons la commande pour obtenir le numéro de version. Vous n’avez donc même pas besoin de connaître votre version, car différents outils CLI fonctionnent parfaitement ensemble et vous pouvez fournir des valeurs en imbriquant des commandes. Il suffit de les encapsuler dans $().

Si tout va bien, vous verrez le message suivant :

Success: WordPress installation verifies against checksums.

Ce message de réussite peut s’afficher alors que des modifications malveillantes sont en cours. Par exemple, un nouveau fichier peut être présent dans votre installation même si aucun fichier principal n’est modifié. Si ce nouveau fichier est ajouté dans un dossier /wp-includes ou, /wp-admin un avertissement s’affichera concernant ce fichier qui ne devrait pas y figurer :

Warning: File should not exist: wp-includes/install-wp.php

Sortie incluant un message d’avertissement sur l’existence d’un fichier inconnu, tandis que les fichiers principaux passent la vérification.

Pour inclure le dossier racine de votre WordPress dans cette vérification, ajoutez le drapeau (indicateur) --include-root.

wp core verify-checksums --include-root --version=$(wp core version)

Il ne vous reste plus qu’un seul répertoire non vérifié : wp-content. Ce répertoire ne devrait contenir qu’un index.php fichier et des dossiers (ou des fichiers PHP) nommés comme extensions visibles dans votre tableau de bord WordPress. Pour les vérifier tous, vous pouvez exécuter la même sous-commande verify-checksums . Si vous souhaitez également vérifier les petites modifications (comme dans le fichier readme.txt), ajoutez l’option --strict .

wp plugin verify-checksums --all --strict

Pour tout plugin qui n’est pas hébergé sur WordPress.org, vous recevrez l’avertissement suivant :

Warning: Couldn’t fetch response from https://downloads.wordpress.org/plugin-checksums//.json (HTTP code 404).
Warning: Could not retrieve the checksums for version of plugin , skipping.

Sortie incluant un message d’avertissement indiquant que WP-CLI n’a pas pu effectuer la vérification pour un plugin, alors que deux plugins ont été vérifiés avec succès.

Encore une fois, cela ne signifie pas nécessairement que votre installation WordPress contient du code malveillant. Cela signifie simplement que cette extension n’est pas hébergée sur WordPress.org. Il peut s’agir d’une extension personnalisée créée par votre développeur spécifiquement pour votre site web, ou d’une version premium d’une extension achetée sur une plateforme. 

Si vous ne savez pas comment gérer tous ces avertissements, copiez-collez la sortie du terminal dans un autre document et envoyez-la à votre développeur pour analyse. Cela réduira considérablement le temps de débogage ou évitera de fausses alertes. Ces deux solutions sont plus avantageuses que leurs alternatives.

Gestion des utilisateurs

Parfois, lorsque des pirates pénètrent dans le site web, ils modifient l’accès des utilisateurs. Ils peuvent supprimer complètement un ou plusieurs utilisateurs (principalement les administrateurs) ou simplement limiter l’accès. Dans ce cas, il est fort probable qu’ils aient pénétré dans le tableau de bord WordPress en piratant le mot de passe ou en créant un nouvel utilisateur en exécutant des fichiers dans votre installation WordPress.

Mais vous disposez d’un accès SSH. Cela fait de vous l’utilisateur le plus puissant de votre serveur. Commencez donc par vérifier tous les utilisateurs disposant d’un accès administrateur :

wp user list --role=administrator

Tableau avec tous les utilisateurs administrateurs comme sortie pour la commande WP-CLI pour répertorier tous les utilisateurs avec un rôle d’administrateur.

Vous obtiendrez un tableau contenant les identifiants, les noms d’utilisateur, les noms d’affichage, les adresses e-mail, les rôles et les dates d’inscription. Les utilisateurs les plus récemment inscrits devraient se méfier si les noms d’utilisateur et les adresses e-mail ne leur disent rien.

À partir de ce point, vous pouvez révoquer silencieusement l’accès à un utilisateur suspect avec la commande suivante (vous avez besoin de son nom d’utilisateur, de son adresse e-mail ou de son identifiant utilisateur) :

wp user remove-role <user_name|user_email|ID>

Sortie pour la commande WP-CLI pour supprimer le rôle d’un utilisateur.

Lorsqu’un utilisateur n’a aucun rôle, WordPress ne sait pas quoi en faire ; il n’a donc aucun accès. Même les abonnés ont accès à leur profil dans le tableau de bord, contrairement aux utilisateurs sans rôle.

Si vous n’êtes pas sûr de l’utilisateur malveillant, vous pouvez supprimer les rôles de tous les administrateurs en combinant d’autres outils CLI :

for i in $(wp user list --role=administrator --field=ID); do wp user remove-role $i; done

Vous reconnaîtrez peut-être la substitution de commande ici : $(). Nous l’utilisons pour obtenir les identifiants de chaque administrateur. Au lieu de ID, vous pouvez utiliser user_name ou user_email. Comme il peut y en avoir plusieurs, nous devons exécuter la commande ci-dessus pour supprimer le rôle de chaque utilisateur. C’est pourquoi nous exécutons nos identifiants dans une boucle for où i représente la valeur de l’utilisateur. Nous souhaitons maintenant exécuter la commande wp user remove-role pour chaque utilisateur, où la valeur individuelle est représentée par $i. En parcourant tous les utilisateurs, nous obtenons done.

Après l’avoir exécuté, vous verrez un message qui vous informe du succès ou de l’échec éventuel :

Success: Removed <user_login> (<ID>) from <URL>

Sortie pour supprimer les rôles pour tous les utilisateurs administrateurs.

Vous pouvez désormais créer votre propre nouvel utilisateur si nécessaire, mais comme nous ne savons pas comment les utilisateurs suspects ont été créés, vous souhaitez exécuter des vérifications pour les modifications de fichiers .

Si vous ne savez pas quels indicateurs sont obligatoires pour la sous-commande, et que vous ne souhaitez pas consulter l’aide ou la documentation, le paramètre --prompt global est une aide précieuse. Il vous proposera tous les indicateurs disponibles (les indicateurs obligatoires sont inclus dans <>les balises), vous n’aurez donc qu’à saisir ceux qui sont spécifiques à votre cas d’utilisation. Cela rendra votre commande beaucoup plus simple et intuitive :

wp user create --prompt

Sortie pour la commande WP-CLI pour créer un nouvel utilisateur.

Ensuite, vous souhaiterez supprimer l’historique de vos commandes, car vous ne souhaitez pas que ce mot de passe y soit enregistré. Pour cela, exécutez :

history -c && history -w

Ou vous pouvez omettre le mot de passe ici et utiliser la fonction « Mot de passe oublié » sur un écran de connexion WordPress pour en définir un.

Sauvegardes

Comme pour les sites web de test, tout hébergeur sérieux propose un service de sauvegarde. Cependant, certains hébergeurs ne proposent pas d’option de téléchargement, mais uniquement la restauration.

Les seules choses pour lesquelles vous souhaitez vraiment avoir une sauvegarde sont le wp-content dossier et la base de données .

Commençons par créer un dossier de sauvegarde :

mkdir backup

Pour les bases de données, vous pouvez spécifier le nom du fichier ou utiliser la structure par défaut de WP-CLI : . Le hachage aléatoire permet de s’assurer que personne ne puisse deviner le nom d’un fichier de base de données sur votre serveur. Cependant, en toute honnêteté, il est déconseillé de conserver des sauvegardes de base de données sur votre serveur. Vous pouvez donc lui donner le nom que vous souhaitez. Nous allons de toute façon le supprimer prochainement. <database_name>-<date>-<random_hash>.sql

wp db export backup/database.sql

Nous voulons maintenant préparer le wp-content dossier en le compressant au format zip et en le déplaçant vers un nouveau répertoire de sauvegarde :

zip -rv backup/wp-content.zip ./wp-content -i "wp-content/themes/*" "wp-content/plugins/*" "wp-content/uploads/*"

Ici, j’ajoute uniquement les dossiers /themes, /plugins, et /uploadsau fichier zip car je veux éviter les dossiers inutiles, tels que /upgrades et tous les dossiers que divers plugins créent pour leurs besoins.

Décomposition de la commande de zipping :

1. zip – évidemment, utilisez la commande zip
2. -rv – va dans chaque dossier ( recurse-paths ) et dis-moi ce que tu fais (messages verbose)
3. backup/wp-content.zip – enregistrez l’archive dans ce chemin (et nommez-la wp-content.zip)
4. ./wp-content – utiliser /wp-contentcomme source pour l’archive
5. -i – inclure uniquement les fichiers suivants
6. "wp-content/themes/*" – tout ce que vous trouvez dans le répertoire /wp-content/themes/ (et répétez cela pour /wp-content/plugins et /wp-content/uploads) 

Maintenant, je peux compresser l’intégralité du dossier de sauvegarde pour pouvoir le télécharger facilement :

zip -rv backup.zip ./backup/

Vidéo montrant toute la procédure de création de sauvegardes.

Voici à quoi ressemble votre dossier racine maintenant :

.
├── backup
├── wp-admin
├── wp-content
├── wp-includes
├── backup.zip
├── index.php
├── license.txt
├── readme.html
├── wp-activate.php
├── wp-blog-header.php
├── wp-comments-post.php
├── wp-config.php
├── wp-config-sample.php
├── wp-cron.php
├── wp-links-opml.php
├── wp-load.php
├── wp-login.php
├── wp-mail.php
├── wp-settings.php
├── wp-signup.php
├── wp-trackback.php
└── xmlrpc.php

Il existe deux manières de télécharger le fichier backup.zip : 

Je vais garder cela simple et supposer que vous n’avez jamais ouvert le terminal sur votre machine locale (mais vous en avez un), nous allons donc opter pour la deuxième option. 

Si vous exécutez ces commandes à la racine de votre WordPress, vous pourrez facilement télécharger le fichier zip en accédant à . Le téléchargement démarrera automatiquement et, une fois terminé, vous devrez supprimer les deux sauvegardes de votre serveur, du fichier zip et du répertoire : https://<your-website.com>/backup.zip

rm -rf backup*

Vous disposez désormais de toutes les sauvegardes nécessaires sur votre machine, et vous l’avez fait en moins de 5 minutes, sans aucune trace sur votre site Web. 🤫

Mode de maintenance

La documentation officielle explique très bien comment utiliser WP-CLI pour le mode maintenance. Je vous suggère de la consulter pour obtenir des informations complémentaires.

Vous souhaitez en savoir plus ?

Si vous vous sentez suffisamment en confiance pour effectuer des vérifications et des actions plus avancées, je vous recommande de vous renseigner sur :

Aucune de ces commandes n’est fournie avec WP-CLI ; vous devez donc les installer séparément.
En bonus, vous trouverez une liste de plugins disposant de leurs propres commandes personnalisées, ainsi que des conseils utiles pour combiner WP-CLI avec d’autres outils CLI afin d’optimiser les performances.

Conclusion

Si vous avez lu jusqu’ici, j’espère que vous êtes arrivé aux conclusions suivantes :