Gérer de nombreux sites WordPress : mises à jour, sauvegardes, sécurité

Gérer trois sites WordPress, c'est facile : vous vous connectez à chaque tableau de bord, cliquez sur « Tout mettre à jour » et passez à autre chose. Quelque part entre dix et cinquante sites, cette routine s'effondre. Les mises à jour s'accumulent, le site d'un client casse après la sortie d'une extension et vous l'apprenez par ses propres clients, et une installation oubliée avec une extension de slider vieille de deux ans devient discrètement un relais de spam. La solution n'est pas de travailler plus ; c'est une routine reproductible qui traite vos sites comme un parc plutôt que comme cinquante corvées séparées. Voici la routine qui tient la route en pratique.

Pourquoi un parc WordPress devient ingérable

• Les mises à jour sont fréquentes et inégales. Le cœur publie des versions mineures de sécurité plusieurs fois par an, et un site moyen embarque 15 à 30 extensions, chacune avec son propre calendrier. Multipliez par votre nombre de sites et il y a quelque chose à mettre à jour presque tous les jours.
• La plupart des compromissions viennent des extensions, pas du cœur. Année après année, l'écrasante majorité des vulnérabilités WordPress publiées concernent des extensions et des thèmes. Le site piraté est généralement celui que personne n'a regardé depuis des mois.
• Les tableaux de bord ne passent pas à l'échelle. Se connecter à cinquante interfaces d'administration est lent, il est facile d'en oublier une, et vous n'avez aucune vue d'ensemble de ce qui est obsolète et où.

Utilisez wp-cli, pas le tableau de bord

wp-cli est l'outil officiel en ligne de commande de WordPress, et c'est le plus gros gain de temps pour quiconque gère plus d'une poignée de sites. Chaque tâche courante devient une commande que vous pouvez scripter :

# Quelle version du cœur, et y a-t-il une mise à jour ?
wp core version
wp core check-update

# Quelles extensions et quels thèmes sont obsolètes ?
wp plugin list --update=available --fields=name,version,update_version
wp theme list --update=available

# Mettre à jour une extension, ou tout
wp plugin update woocommerce
wp plugin update --all
wp theme update --all
wp core update
wp core update-db

Deux règles rendent wp-cli sûr sur un serveur multi-sites :

• Lancez-le sous l'utilisateur du site, jamais en root. Si chaque site a son propre utilisateur Linux (ce qui devrait être le cas), lancez sudo -u siteuser wp --path=/var/www/siteuser/public_html .... En root, les fichiers écrits par une mise à jour appartiennent à root, ce qui casse la mise à jour suivante et les envois de fichiers du site. wp-cli refuse d'ailleurs de tourner en root sans --allow-root, et cet avertissement a une bonne raison d'être.
• Passez toujours --path. Dans une boucle sur de nombreux sites, un chemin explicite garantit que chaque commande touche le site voulu.

Avec cela en place, l'inventaire de tout votre parc tient en une courte boucle :

for dir in /var/www/*/public_html; do
  user=$(stat -c %U "$dir")
  [ -f "$dir/wp-config.php" ] || continue
  echo "== $dir"
  sudo -u "$user" wp --path="$dir" plugin list --update=available --format=csv
done

Lancez-la chaque semaine et vous savez exactement où se trouve le risque avant de toucher à quoi que ce soit.

Le bon ordre de mise à jour

Tout mettre à jour d'un coup sur tous les sites en même temps, c'est ainsi qu'une mauvaise version met vingt clients hors ligne en un après-midi. Un ordre plus serein :

1. Sauvegardez d'abord. Fichiers et base de données, à chaque fois (plus de détails ci-dessous).
2. Mettez à jour les extensions avant le cœur lors d'une version majeure, pour que les extensions qui ajoutent la compatibilité avec le nouveau cœur soient déjà en place. Pour les versions mineures courantes, l'ordre compte moins, mais restez cohérent.
3. Mettez à jour les thèmes en dernier, et ne modifiez jamais un thème que vous mettez aussi à jour ; placez vos personnalisations dans un thème enfant.
4. Lancez wp core update-db après une mise à jour du cœur pour que les migrations de base n'attendent pas la prochaine connexion d'un administrateur.
5. Vérifiez le site. Au minimum, récupérez la page d'accueil et une page intérieure et regardez le code HTTP et le journal d'erreurs PHP. Une page blanche que personne ne remarque pendant une journée est pire qu'une page blanche repérée en trente secondes.

Échelonnez selon le risque. Mettez d'abord à jour vos propres sites à faible trafic, attendez un jour, puis déployez sur les sites clients. Pour les boutiques à fort trafic, testez sur une copie avant la production.

Sauvegardez avant chaque mise à jour, et stockez ailleurs

Une mise à jour sans sauvegarde est un pari. Faites de la sauvegarde une partie de la commande de mise à jour, pas une habitude à part :

wp db export /var/backups/siteuser/before-update-$(date +%F).sql
tar -czf /var/backups/siteuser/files-$(date +%F).tar.gz -C /var/www/siteuser public_html

Puis appliquez les règles de base des sauvegardes qui vous sauvent vraiment :

• Hors du serveur. Une sauvegarde sur le même disque meurt avec le disque ou avec l'attaquant. Envoyez une copie vers un stockage compatible S3 ou une autre machine. (Nous l'avons détaillé dans sauvegardes de sites chiffrées vers S3.)
• Une rétention, pas une seule copie. Conservez plusieurs générations. Un malware passé inaperçu pendant une semaine se trouve aussi dans la sauvegarde d'hier soir.
• Testez une restauration de temps en temps. Une sauvegarde jamais restaurée est un espoir, pas une sauvegarde.

L'hygiène des extensions : la sécurité la moins chère qui soit

• Supprimez ce que vous n'utilisez pas. Les extensions désactivées restent sur le disque et peuvent toujours être exploitées si leurs fichiers sont accessibles directement. wp plugin list --status=inactive, puis wp plugin delete.
• Préférez des extensions moins nombreuses et maintenues. Une extension sans mise à jour depuis deux ans, ou retirée du répertoire wordpress.org, est un passif. Remplacez-la.
• N'installez jamais d'extensions ou de thèmes « nulled ». Les copies « gratuites » d'extensions premium sont l'un des moyens les plus courants d'introduire des portes dérobées sur des sites WordPress.
• Verrouillez l'édition de fichiers. Ajoutez define('DISALLOW_FILE_EDIT', true); à wp-config.php pour qu'un identifiant administrateur volé ne puisse pas être transformé en exécution de code PHP via l'éditeur de thème.
• Isolez les sites les uns des autres. Un utilisateur Linux et un pool PHP-FPM par site, pour qu'une compromission sur un site ne puisse pas lire les fichiers ni les identifiants de base du suivant. (Voir héberger plusieurs sites clients sur un seul VPS.)
• Analysez régulièrement. Passez un scanner de malware comme ClamAV sur les fichiers de chaque site selon un calendrier, pas seulement quand quelque chose semble anormal.

Les pièges courants

• Tout mettre à jour automatiquement, à l'aveugle. Les mises à jour automatiques de WordPress pour les versions mineures du cœur sont raisonnables. Mettre à jour automatiquement chaque extension de chaque boutique client sans sauvegarde ni vérification ne l'est pas.
• Oublier update-db. Après certaines mises à jour du cœur et de WooCommerce, le site fonctionne mais la mise à niveau de la base est en attente, et le prochain administrateur qui se connecte la déclenche à un moment aléatoire.
• Des utilisateurs partagés entre sites. Si tous les sites tournent sous www-data, une seule extension vulnérable expose tous les sites du serveur.
• Des sauvegardes sur le même serveur. Les rançongiciels et les pannes de disque se moquent bien de votre dossier de sauvegardes.
• Pas d'inventaire. Vous ne pouvez pas corriger ce dont vous ignorez l'existence. Tenez une liste de chaque installation, de son propriétaire et de ses extensions.

Comment ShadowPanel supprime les tâches répétitives

ShadowPanel est un panel d'hébergement auto-hébergé, et sur les offres Pro et Agency il couvre la routine ci-dessus sans renoncer aux règles d'isolation :

• WordPress Toolkit. Chaque site WordPress dispose d'une vue qui détecte l'installation et liste la version du cœur, la mise à jour disponible, ainsi que chaque extension et chaque thème avec sa version installée et disponible. Vous pouvez mettre à jour le cœur, une extension ou un thème précis, ou toutes les extensions ou tous les thèmes d'un coup, et le panel vous affiche la sortie de wp-cli.
• Exécuté sous l'utilisateur du site. En coulisses, il utilise wp-cli sous l'utilisateur Linux propre au site, jamais en root, avec un chemin cible vérifié par rapport au répertoire personnel de cet utilisateur. Les fichiers mis à jour gardent le bon propriétaire.
• Des sauvegardes avant les changements. Les sauvegardes à la demande des fichiers et des bases sont disponibles sur toutes les offres ; Pro et Agency ajoutent des sauvegardes automatiques planifiées (quotidiennes, hebdomadaires ou mensuelles) envoyées vers un stockage compatible S3 ou un serveur SFTP, avec le nombre de copies à conserver de votre choix et un e-mail en cas d'échec. Les archives peuvent être chiffrées par GPG en AES-256.
• Analyses antimalware. Pro et Agency peuvent lancer une analyse ClamAV complète du site depuis le panel, en plaçant éventuellement les fichiers infectés en quarantaine, avec l'historique des analyses conservé par site et une notification à la fin.
• Isolation par défaut. Chaque site a son propre utilisateur Linux et son propre pool PHP-FPM avec open_basedir, pour qu'une extension obsolète reste le problème d'un seul site.

En résumé

Cinquante sites WordPress restent en bonne santé quand le travail devient une routine : inventaire avec wp-cli, sauvegarde hors serveur avant chaque changement, mises à jour dans un ordre constant, vérification du résultat et suppression des extensions inutiles. Rien de tout cela n'est difficile ; il faut simplement le faire chaque semaine, pour chaque site. ShadowPanel réunit l'inventaire, les mises à jour, les sauvegardes planifiées et les analyses antimalware en un seul endroit, tout en gardant chaque site isolé des autres.

curl -fsSL https://shadowpanel.de/install.sh | bash

Voir les tarifs et télécharger →