Site suspendu par l'hébergeur : obtenir la remise en ligne

Ce que dit vraiment la page de suspension

Un compte hébergeur suspendu affiche souvent une page générique. L’information utile est dans l’email d’abus ou dans le ticket : malware, phishing, spam, resource abuse, parfois un chemin de fichier. Ce motif décide de l’ordre. Un compte coupé pour une page d’hameçonnage ne se traite pas comme un compte coupé pour CPU à 100 %.

Si vous n’avez plus l’email, le premier message au support demande la référence et le motif, pas la réouverture. « Merci de nous communiquer l’ID d’abus et le fichier ou l’URL signalés. Adresse hors domaine : … ». Sans ça, vous nettoyez au hasard et le scan interne retrouve le même chemin.

La page « Account Suspended » n’est pas une fatalité ni une punition morale. C’est un interrupteur automatique. L’humain de l’autre côté lève l’interrupteur quand il a de quoi montrer à son outil que la cause a disparu. Votre job est ce dossier, pas de négocier le chiffre d’affaires dans le chat.

• Malware : fichier à identifier et retirer, entrée à fermer.
• Phishing : URL encore en 200 = refus quasi certain.
• Spam mail : journal d’envoi, mot de passe boîte, relais ouvert.
• CPU / minage : cron et process, pas seulement « on a mis Wordfence ».

Chronologie type d’une remise en ligne

Jour 0 : suspension, lecture du motif, demande d’archive + logs, mot de passe panel dès qu’il est encore actionnable (parfois trop tard). Jour 0–1 : copie hors serveur, identification du chemin, retrait, fermeture de l’entrée (extension, compte, voisin). Jour 1 : constat écrit dans le ticket. Jour 1–3 ouvrés : scan côté hébergeur, réouverture, parfois un aller-retour « on voit encore X ».

Ce calendrier glisse si vous restaurez une sauvegarde sale, si vous ouvrez cinq tickets, si la messagerie de contact est morte, si le phishing a plusieurs URL. Il glisse aussi le vendredi 17 h : abuse ne travaille pas comme le commercial.

La remise en ligne n’est pas la fin. Safe Browsing, l’index spam, les clients qui ont vu l’alerte : d’autres horloges. Ne les mélangez pas. Voir délai réel de remise en ligne.

Obtenir l’archive quand le FTP est mort

Même sans FTP, la plupart des hébergeurs peuvent générer un tar du home et un dump SQL, ou un accès temporaire lecture. C’est la pièce sans laquelle on devine. Demandez-la dans le même fil que le motif. Téléchargez le jour du lien.

Traitez cette archive comme un constat, pas comme un bouton « restore et on rouvre ». Remettre le compte à l’heure T replace le malware. Travaillez hors ligne : extraire, trouver, préparer un tree propre, puis soit ils vous rendent le FTP pour pousser, soit ils restaurent votre archive nettoyée — selon leurs process. Faites préciser.

Si on vous dit « on ne fournit pas de backup », insistez une fois sur une copie du seul vhost. En parallèle, cherchez vos propres Updraft / Jetpack / disques. Documentez le refus : utile pour l’assurance, utile pour décider d’une reconstruction depuis les zips officiels.

Traiter le motif, pas le badge rouge

Le fichier cité doit disparaître du web (plus en 200). Les copies sous un autre nom aussi (`wp-core.php`, `wp-core2.php`). L’entrée (plugin vulnérable, admin fantôme, voisin) doit être fermée, sinon le scan de l’hébergeur est vert deux heures et rouge le lendemain — deuxième suspension, file plus lente.

Un plugin cleaner lancé dans le vide, ou un chmod 000 sur tout `wp-content`, produit un site cassé et un ticket « on a nettoyé » que le tech ne peut pas vérifier. Comparez au cœur, retirez les ajouts, gardez la liste des chemins. C’est exactement ce qu’ils veulent lire.

Phishing : toutes les URL du kit, pas seulement la home. Testez avec un user-agent mobile. Resource abuse : tuez le cron, pas seulement le process du moment. Spam : mot de passe boîte + relais + `.php` mailer à la racine. Chaque motif a son objet. Le guide hébergeur suspend le site reprend les pièces.

Le constat : trouvé, retiré, corrigé

Trois phrases minimum, chemins et dates. « Trouvé : `public_html/wp-core.php` (modifié le 25/08 03:12) et utilisateur WP `shop_mgr`. Retiré : fichier + utilisateur. Corrigé : extension X mise à jour / retirée, mots de passe panel et FTP changés le 27/08 09:00, 2FA activée. Plus de 200 sur les URL listées. Merci de rescanner la référence #12345. »

Joignez une liste, pas un roman, pas « c’est nettoyé vous pouvez rouvrir ». Si un prestataire a fait le travail, son compte-rendu est le document. Un ticket d’une ligne est refusé presque toujours.

Ne mentez pas sur une entrée que vous n’avez pas trouvée. « Entrée non identifiée avec certitude, surveillance 30 jours, secrets tournés » est acceptable. « On a tout sécurisé à 100 % » alors que le voisin de compte est encore sale se voit au scan suivant.

Délais constatés (et ce qui les double)

Une fois le constat recevable : souvent 4 à 48 heures ouvrées, parfois plus en pointe ou le week-end. Relancer toutes les heures n’enlève pas un cran. Fournir référence + constat dès le premier message utile, si.

Ce qui double : restore sale, nouveau fichier détecté, ticket sans adresse de secours, débat sur la facture, migration commencée en parallèle, quatre interlocuteurs différents. Un seul fil, une seule personne titulaire.

La réouverture du vhost ≠ levée Chrome. Prévenez les clients qui voient encore « site dangereux » que c’est une autre liste. Blacklist Google se demande après un site réellement propre, pas à la minute où le FTP revient.

Messagerie du domaine coupée avec le site

Indiquez Gmail / Outlook perso dans le ticket et dans le profil client. Rappelez le numéro de ticket par un canal qui marche (formulaire logué du manager). Sinon vous et l’abuse vous attendez mutuellement.

Les mots de passe « oubliés » du panel partent souvent vers l’email du domaine. Si cet email est mort, passez par le support identité, pas par une boucle de reset. Anticipez : dès le premier soupçon, ajoutez un email de secours, avant la suspension.

Les mails clients (commandes) en attente : ce n’est pas le sujet d’abuse. Traitez-le après réouverture, ou via un SMTP externe si vous en aviez un indépendant du vhost.

Ce qu’il ne faut pas faire pour « contourner »

Changer les DNS vers un VPS « le temps que ça se calme » : l’infection voyage, le nouvel hébergeur suspend plus vite (IP neuve + malware connu), les logs de l’ancien compte restent bloqués. Recréer le site à la main ailleurs sans archive : vous perdez contenus et preuves, l’attaquant recommence.

Ouvrir le site sur un sous-domaine « clean » du même compte : le scan voit le même home. Changer uniquement le dossier public vers une page « coming soon » sans retirer le kit : le fichier est encore là, le ticket reste rouge.

Payer une offre « unsuspend now » d’un tiers qui demande les accès panel : vous ajoutez un prestataire opaque sur un compte déjà compromis. Restez sur le titulaire, le constat, le fil officiel. Vous pouvez déclarer chez nous sans contourner l’hébergeur : on travaille avec leur process, pas contre.

• Pas de migration sale.
• Pas de second ticket « c’est urgent » sans pièce.
• Pas de restore de la dernière sauvegarde sans l’ouvrir.
• Pas de sous-domaine magique sur le même tree infecté.