Héberger plusieurs sites WordPress sur le même serveur permet de mutualiser les ressources et de réduire les coûts. Mais cela augmente aussi les risques : si un site est compromis, il peut devenir un point d’entrée pour attaquer les autres, consommer toutes les ressources ou faire blacklister l’IP du serveur.
Dans ce guide, nous allons voir comment sécuriser un serveur multi-sites WordPress (multi-tenant) : isolation des comptes système, pools PHP-FPM par site, bases de données séparées, gestion des permissions, durcissement WordPress et intégration d’outils comme Cloudflare, WP Cerber et CrowdSec.
Résumé rapide : Sur un serveur multi-sites WordPress, la sécurité repose sur l’isolation : un utilisateur système par site, un pool PHP-FPM par site, une base par site avec un compte SQL dédié, des droits fichiers stricts, un WAF en amont (Cloudflare) et un plugin de sécurité (WP Cerber) complété par un outil serveur comme CrowdSec ou fail2ban.
Sommaire
1. Les risques spécifiques d’un serveur multi-sites WordPress
Quand plusieurs sites partagent le même serveur, les risques s’additionnent :
- Compromission en cascade : si un site est vulnérable, l’attaquant peut tenter de pivoter vers les autres.
- Consommation abusive de ressources : un seul site peut saturer le CPU, la RAM ou la bande passante.
- Surface d’attaque élargie : plus de thèmes/plugins installés = plus de failles potentielles.
- Impact réputationnel : en cas de spam ou de malware, l’IP du serveur peut être blacklistée pour tous les sites.
L’objectif d’un modèle multi-tenant est donc d’organiser le serveur comme si chaque site était “chez lui”, même s’ils partagent les mêmes ressources physiques.
2. Isolation au niveau système : un utilisateur par site
Première brique : ne jamais exécuter tous les sites sous le même utilisateur système. Au lieu de tout mettre
sous www-data ou apache, créez :
- un utilisateur système par site (ex.
site1,site2), - un répertoire dédié (ex.
/var/www/site1), - des permissions qui empêchent un site de lire/écrire dans les dossiers des autres.
Les fichiers du site1 doivent appartenir à site1:site1, ceux du site2 à
site2:site2, etc. Le serveur web et PHP-FPM seront ensuite configurés pour exécuter le code
avec le bon utilisateur.
3. Pools PHP-FPM dédiés par site
Ensuite, configurez un pool PHP-FPM par site. Chaque pool :
- tourne sous l’utilisateur système du site,
- dispose de ses propres limites (pm, max_children, etc.),
- est relié à un VirtualHost dédié (Apache ou Nginx).
Exemple pour un pool site1 :
[site1]
user = site1
group = site1
listen = /run/php/php-fpm-site1.sock
pm = ondemand
pm.max_children = 8
pm.process_idle_timeout = 10s
pm.max_requests = 500
Avantages :
- Un site qui consomme trop de PHP ne bloque pas tous les autres.
- Les logs PHP peuvent être séparés par pool, donc par site.
- Les droits systèmes sont respectés (le code ne s’exécute pas sous un utilisateur global).
4. Bases de données : une base et un utilisateur par site
Côté MySQL/MariaDB, appliquez un principe identique : une base par site et un utilisateur SQL dédié par site.
Par exemple :
CREATE DATABASE site1_wp CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'site1_user'@'localhost' IDENTIFIED BY 'motdepassefort';
GRANT ALL PRIVILEGES ON site1_wp.* TO 'site1_user'@'localhost';
FLUSH PRIVILEGES;
Résultats :
- Un site compromis ne peut pas lire les données d’un autre via SQL.
- Les sauvegardes/restaurations peuvent être faites site par site.
- La gestion des permissions est plus fine et plus propre.
5. Droits fichiers, uploads et séparation des logs
Les droits fichiers doivent limiter au strict nécessaire :
- Fichiers PHP : lisibles par le serveur, mais pas écrits par
www-datapartout. - Dossiers d’uploads : écriture possible, mais uniquement là où c’est requis (ex.
wp-content/uploads). - Pas de dossiers de backup ou de logs dans le
DocumentRootaccessibles au public.
Idéalement, vous séparez aussi :
- les logs web par VirtualHost (un fichier access/error par site),
- les logs PHP par pool PHP-FPM,
- les logs applicatifs WordPress (WP Cerber, etc.).
Cela facilite la détection d’anomalies par site (attaque, spam, erreurs répétées).
6. Sécurité WordPress sur chaque site (WP Cerber, mises à jour)
Au-dessus de la couche serveur, chaque site WordPress doit être durci :
- Mises à jour régulières du cœur, des thèmes et des plugins.
- Plugins inutiles supprimés (et pas juste désactivés).
- WP Cerber ou équivalent pour :
- limiter les tentatives de connexion,
- bloquer certaines IP/UA,
- protéger l’interface d’admin,
- surveiller les fichiers sensibles.
- Mots de passe forts et 2FA pour les comptes administrateurs.
Sur un parc de sites, il est utile d’avoir une routine de vérification hebdomadaire (ou automatisée) pour s’assurer que tous les sites sont à jour et que les plugins critiques (sécurité, cache) sont bien actifs.
7. WAF, CrowdSec et protection au niveau serveur
Enfin, le serveur lui-même doit être protégé contre :
- les scans massifs,
- les bots agressifs,
- les attaques sur les ports exposés.
7.1. WAF en amont (Cloudflare)
Cloudflare peut filtrer une grande partie du trafic malveillant avant qu’il n’atteigne le serveur :
- WAF géré,
- règles spécifiques sur
/wp-login.php, - rate limiting,
- protection DDoS.
7.2. CrowdSec ou fail2ban côté serveur
Des outils comme CrowdSec ou fail2ban analysent vos logs (SSH, Apache, Nginx, Postfix, etc.) et peuvent :
- bannir temporairement ou durablement les IP agressives,
- construire une “réputation” partagée (dans le cas de CrowdSec),
- compléter le travail de Cloudflare en filtrant aussi le trafic qui ne passe pas par le CDN.
Avec mod_remoteip bien configuré (si vous utilisez Cloudflare), ces outils verront la
vraie IP des visiteurs.
FAQ – Sécurité serveur multi-sites WordPress
Un piratage sur un site peut-il compromettre tout le serveur ?
Oui, si l’isolation n’est pas en place (même utilisateur système, mêmes droits partout, une seule base, etc.). Avec un modèle multi-tenant bien conçu (un user, un pool PHP, une base par site), le risque est fortement réduit. Mais il reste important de corriger rapidement tout site compromis.
Est-ce plus risqué d’héberger plusieurs sites sur le même serveur ?
Oui, la surface d’attaque augmente mécaniquement. Mais si la séparation est bonne et la sécurité gérée sérieusement, un serveur multi-sites peut rester très fiable et rentable. L’alternative (un serveur par site) est souvent trop coûteuse.
WordPress Multisite est-il une meilleure solution que plusieurs WordPress séparés ?
WordPress Multisite a ses avantages, mais il complexifie la base, les plugins, les migrations. Pour un hébergement multi-clients, plusieurs WordPress séparés (avec isolation) restent souvent plus simples et plus sûrs à administrer.
Un plugin de sécurité suffit-il pour protéger un serveur multi-sites ?
Non. Un plugin de sécurité agit au niveau de WordPress. Sur un serveur multi-sites, vous devez aussi gérer la sécurité système (SSH, firewall), l’isolation des comptes, les pools PHP, les bases et un WAF en amont.
Comment surveiller la sécurité sur plusieurs sites ?
En combinant :
- un monitoring serveur (CPU, RAM, logs),
- des alertes WordPress (WP Cerber, logs de connexion, modifications de fichiers),
- un suivi régulier des mises à jour,
- et, idéalement, un reporting centralisé (tableau de bord des sites, statut des plugins, etc.).
Conclusion : un vrai modèle “multi-tenant” pour WordPress
Sécuriser un serveur multi-sites WordPress ne se résume pas à installer un plugin de sécurité et à espérer que tout ira bien. C’est une approche globale : isolation des comptes, séparation des pools PHP et des bases, droits fichiers stricts, WAF, outils serveurs comme CrowdSec, et WordPress durcis individuellement.
En appliquant ces principes, vous transformez un simple “serveur partagé maison” en une plateforme multi-tenant professionnelle, capable d’héberger plusieurs projets en limitant les impacts croisés et en offrant un bon niveau de sécurité à vos clients ou à vos propres sites.
