VPS OVH, Scaleway ou AWS : le site et le serveur
Sur un VPS OVH, Scaleway, AWS ou autre, l'incident peut être le système, pas seulement le vhost WordPress. Mots de passe SSH, clés, utilisateurs, Docker oubliés. Un « nettoyage WordPress » ne suffit pas si root a été pris. Distinguez tôt site et serveur. En cas de doute, snapshot hors ligne puis rebuild : moins cher qu'un troisième incident sur les mêmes clés.
Sur un VPS, l'incident peut être le système, pas seulement le vhost. Mots de passe SSH, clés, utilisateurs, docker oubliés. Un « nettoyage WordPress » ne suffit pas si root a été pris.
Site compromis ou serveur compromis
Signaux serveur : process inconnus, nouveaux users Unix, clés SSH, cron root, Docker qui mine, ports d'admin ouverts, charge 100 % hors trafic. Signaux site : PHP à la racine, admin CMS fantôme, JS pied de page — le système peut être encore sain. Les deux se cumulent.
Si root a été pris, traiter uniquement `/var/www` est un théâtre. L'attaquant reviendra. Cette page est pour ce doute. Un mutualisé n'a pas ce dilemme : OVH mutualisé.
On ne donne pas de recette pour « prendre root ». On dit comment constater et choisir rebuild vs nettoyage. Un plugin WordPress ne tranche pas un sudoers modifié.
Ce qu'on fige sur un VPS (sans tout formater)
Snapshot / image hors ligne si l'hébergeur le permet (OVH, Scaleway, AWS AMI). Copie des sites et bases vers un stockage que le VPS ne monte pas en écriture. Logs `/var/log`. Liste des users et des clés.
Formater tout de suite détruit la chronologie (assurance, CNIL, compréhension). Preuves. Fuite.
Coupez SSH mot de passe, restreignez l'accès admin (console hébergeur) le temps de voir. Console KVM/IPMI : parfois le seul chemin si SSH est mort ou hostile.
SSH, clés, utilisateurs, sudo
`authorized_keys` pour chaque user, sudoers, users UID 0, mots de passe. Révoquez, nominatif ensuite. Fail2ban n'efface pas une clé déjà déposée.
Clés dans CI/CD, laptop du prestataire, agent ssh-forward : la porte peut être hors du VPS. Tournez aussi là. Ancien développeur.
alwaysdata / Simple Hosting : périmètre plus petit, même idée clés. alwaysdata.
Docker, panels, vieux stacks
Containers oubliés, socket Docker exposé, images qui minent. Docker WordPress. Lister `docker ps -a` (ou équivalent) fait partie du constat, pas d'un tutoriel d'attaque.
cPanel/Plesk/Webmin/Cockpit sur le VPS : si le panel est forcé, tous les vhosts suivent. cPanel/Plesk.
PHP 5, CMS oubliés dans un vhost. CMS oublié.
WordPress n'est qu'un vhost
Nettoyer WP (zip, admins, mu-plugins) reste nécessaire SI le système est sain. Si root est pris, le WP propre est re-salí. Ordre : hypothèse serveur d'abord quand les signaux système sont là.
Plusieurs vhosts : isolation — sur un VPS c'est VOUS l'hébergeur (users Unix, open_basedir, pools PHP).
Snapshots, restore, et le rançongiciel
Rançon disque : snapshot antérieur hors ligne, ne pas payer. Rançongiciel. Vérifiez que le snapshot n'est pas déjà chiffré.
Restore d'un snapshot sale + mêmes clés SSH = second passage. Secrets neufs sur un serveur neuf de préférence si root était pris.
Sauvegardes Borg/Restic montées en écriture depuis le VPS : parfois emportées. Hors ligne = immutable / autre compte cloud.
Hébergeur VPS : tickets, abuse, IP
Abuse OVH/Scaleway/AWS : motif, IP, parfois port. Ils peuvent null-router. Demandez snapshot, pas seulement « débloquez ». Adresse perso. Mail coupé si le mail était sur le VPS.
Réputation IP du VPS : réputation IP. Une IP VPS brûlée se change plus facilement qu'un mutualisé — après propreté.
AWS : clés IAM, security groups, instances oubliées dans une autre région. Le « site » n'est pas toute la facture.
Rebuild ou chirurgical : décider
Rebuild (OS neuf, clés neuves, sites recopiés propres) si root douteux, rançon, mineur système, panel forcé. Chirurgical si signaux uniquement dans un vhost et SSH resté sain (hypothèse à documenter). En cas de doute, rebuild : moins cher qu'un troisième incident.
Migrer vers un mutualisé borné est parfois plus sûr qu'un VPS mal tenu. Changer d'hébergement.
Créer un compte : on ne « s'occupe pas de votre AWS Organizations » à l'aveugle ; on constate le web et on dit si le serveur dépasse le forfait site. C'est déjà un service que beaucoup de « clean WordPress » ne rendent pas.
En cas de doute root, rebuild. Un chirurgical « parce que c'est plus rapide » sur un sudoers modifié est le troisième incident, pas le premier économisé.
Infogérance, mutualisé, ou rester root
Après un VPS pris, trois issues honnêtes : quelqu'un patche le système (vous, infogéreur), vous redescendez sur un mutualisé borné, ou vous acceptez le prochain incident. Un VPS « pour être plus sûr » sans mises à jour kernel n'est pas plus sûr qu'o2switch. Changer d'hébergement.
OVH rescue / snapshot : copiez avant de « réparer ». AWS : autres régions, IAM, security groups. Scaleway : mêmes réflexes snapshot. L'abuse IP se change après propreté, plus facilement qu'en mutualisé. Réputation IP.
Mail sur le VPS : adresse perso dès le ticket, parfois le seul tuyau si Postfix est null-routé. Mail coupé. Docker : listez, ne supposez pas l'isolation. Docker WordPress.