Isoler les sites d'un même compte d'hébergement

Ce que « même compte » veut dire concrètement

Chez un mutualisé, un « compte » cPanel, Plesk, LWS, o2switch ou World PlanetHoster porte souvent plusieurs domaines : le site vitrine, l'ancien blog, le préprod oublié, le domaine de l'asso du cousin. Ils partagent l'utilisateur système, parfois la même version de PHP, souvent la possibilité pour un script d'un dossier d'ouvrir un fichier dans l'autre.

Les plugins de sécurité ne voient que « leur » site. Ils ne listent pas `../ancien-wordpress/wp-config.php`. C'est pour cela qu'un WordPress « propre » se réinfecte en une nuit : le voisin n'a pas été traité. Plusieurs sites infectés sur le même compte décrit le symptôme ; ici on parle du levier.

Un addon domain, un parked, un sous-domaine `dev.` encore en ligne : même logique. Sous-domaine oublié et parked / addon infecté sont des variantes du même trou.

• Tous les domaines du panel, pas seulement celui de l'e-mail d'abus.
• Les dossiers à la racine qui ne sont plus des sites « officiels ».
• Les copies « backup-2019 » laissées en HTTP.

Le site abandonné, porte de tous les autres

Un WordPress 4.7 que plus personne n'ouvre, un Joomla 3, un dossier `old` avec un admin `admin/admin`. Personne ne le met à jour. Les bots, si. Une fois à l'intérieur, ils cherchent les configs des voisins : `wp-config.php`, `.env`, `configuration.php`, `settings.php`. C'est plus simple qu'une faille neuve.

La décision utile n'est pas de « sécuriser » ce site. C'est de le retirer du web (vhost coupé, dossier hors racine web, ou compte séparé) après en avoir copié ce qui a encore une valeur. Un musée en ligne n'a pas besoin d'un PHP 5.6 joignable.

Si l'hébergeur a suspendu « un » site, lisez le motif et demandez si d'autres vhosts du compte ont été cités. Le support ne le dit pas toujours. La page compte suspendu et le guide associé rappellent de demander l'archive du compte, pas seulement du domaine visible.

Ce qu'un PHP peut lire chez le voisin

Sans isolation, `file_get_contents` ou un simple `include` vers un chemin relatif suffit à lire une config. On ne détaille pas ici comment le faire : le constat suffit. Si deux sites partagent l'utilisateur Unix, partez du principe que l'un peut lire l'autre, jusqu'à preuve contraire (open_basedir, comptes séparés, permissions 750 bien posées).

Les configs sont le jackpot : mot de passe de base, clés, parfois SMTP. Un incident « petit site oublié » devient un incident « boutique + messagerie ». Changez les secrets de tous les sites du compte, pas seulement ceux du vhost signalé. Mots de passe à changer.

Les sauvegardes dans le même arbre (`backup.zip`, Updraft dans uploads) sont lisibles pareil. Stockez les copies hors du compte. Une archive dans le voisin se corrompt avec le reste.

Permissions, configs, open_basedir

`open_basedir` borne les chemins que PHP a le droit d'ouvrir. Beaucoup de mutualisés français le posent par domaine ; d'autres non, ou mal (borne trop large, `:/tmp` trop permissif, ou exception pour « que le cron marche »). Demandez à l'hébergeur si chaque vhost est borné à son dossier. Ce n'est pas une question honteuse.

Permissions : configs en 644 lisibles par tous les utilisateurs du serveur partagé, c'est trop. 640 ou 600, propriétaire = utilisateur du site, groupe selon le modèle de l'hébergeur. Un `wp-config.php` à 777 « pour que ça marche » est une invitation. On corrige après nettoyage, pas à l'aveugle pendant l'attaque (vous casserez l'affichage).

Les droits d'écriture du dossier web pour l'utilisateur Apache/nginx commun à tout le serveur sont le cauchemar du mutualisé bas de gamme. Si l'isolation est structurellement impossible, le levier devient : changer d'offre, ou de compte. Quand changer d'hébergement.

• Une config par site, pas un mot de passe MySQL unique pour tout le compte.
• Pas de `old.zip` à la racine web.
• PHP des dossiers médias : exécution interdite.

Ce que l'hébergeur isole — et ce qu'il n'isole pas

o2switch, Infomaniak, alwaysdata, les offres « un compte = un site » : souvent mieux bornés. Un World PlanetHoster, un cPanel avec quinze addons, un VPS où vous avez tout mis dans `/var/www` sans utilisateurs séparés : à vous de poser l'isolation. L'article PlanetHoster World insiste sur le nettoyage du compte, pas d'un seul vhost.

Cloudflare devant un seul domaine ne protège pas le voisin qui n'est pas proxifié. Le WAF du site vitrine ne voit pas le PHP de `old.exemple.fr`. WAF après piratage.

La réputation IP est l'autre face : un voisin (même d'un autre client) qui spam peut noircir l'IP. Ce n'est pas la même chose que la lecture de fichiers, mais ça se cumule. Réputation IP du serveur et le guide associé.

Nettoyer le compte, pas seulement le vhost signalé

Le mail d'abus cite souvent un chemin. Partez de ce chemin, puis listez tous les document roots du panel. Dates de fichiers, PHP isolés, cron de chaque site, utilisateurs FTP. Un seul site « propre » dans un compte sale se refait.

Mots de passe : panel d'abord, puis chaque FTP, puis chaque admin CMS, puis chaque base. Si le panel a fuité, l'isolation des PHP ne suffit plus : l'attaquant réécrit ce qu'il veut. cPanel ou Plesk forcé.

Joignez au ticket d'abus la liste des vhosts traités, pas seulement « le site est clean ». Les supports OVH, LWS, IONOS comprennent une phrase factuelle. Relancer toutes les heures n'accélère pas. Une adresse e-mail hors domaine si la messagerie est coupée. E-mail coupé avec le site.

Quand l'isolation est impossible

Hébergeur qui refuse open_basedir, offre où tous les clients partagent un utilisateur trop large, VPS mal tenu dont vous n'avez plus la main : on migre après nettoyage, pas avant. Migrer un compte sale brûle parfois le nouveau contrat en 24 heures. Changer d'hébergement après un hack et migration de nuit.

Un VPS à vous, mal isolé (un seul user, Docker root oublié), se traite comme un serveur, pas comme un WordPress. VPS OVH, Scaleway, AWS.

Si vous ne savez pas distinguer « PHP borné » et « impression que c'est bon », déléguez la cartographie. Créer un compte : prix avant accès.

Moins de sites, moins de dettes

Chaque site sur le compte est une surface à mettre à jour, à inventorer, à surveiller trente jours. Vingt vitrines oubliées, c'est vingt portes. Archivez hors ligne, coupez le DNS, retirez le vhost. Le nom de domaine peut attendre chez le registrar sans PHP derrière.

Un site « qui tournait encore » (SPIP, TYPO3, PHP 5) n'est pas gratuit parce que personne ne le touche. CMS oublié. Le coût de reconstruction du métier non documenté se paie le jour où on ose enfin l'éteindre : copiez avant toute bravoure.

L'habitude : un compte = un projet vivant, ou une isolation démontrée. Le reste est de l'archéologie en ligne, et l'archéologie se pille.

• Inventaire panel à jour.
• Sites morts hors web.
• Secrets distincts par site.