Votre site est piraté : la marche à suivre, dans l'ordre

Les signes, dont trois sont invisibles depuis votre navigateur

Le piratage visible, avec une page de revendication à la place de l'accueil, est devenu rare. Il ne rapporte rien. Ce qui rapporte, c'est d'utiliser discrètement votre nom de domaine, et la discrétion fait partie du plan.

• Des pages qui ne sont pas de vous dans Google. Cherchez site:votredomaine.fr dans Google et faites défiler. Des pages en langue étrangère, ou sur des sujets sans rapport, signent une injection de contenu.
• Un avertissement de la Search Console. Google prévient le propriétaire vérifié. Encore faut-il que quelqu'un lise cette boîte mail.
• Des redirections qui ne se déclenchent que pour certains visiteurs. Depuis un téléphone, ou depuis un lien Google, mais jamais quand vous tapez l'adresse directement. C'est fait exprès : le propriétaire ne voit rien.
• Des envois d'e-mails que vous n'avez pas faits. Un pic de messages rejetés, ou des clients qui reçoivent des messages en votre nom.
• Des fichiers récents que personne n'a déposés. Visible dans le gestionnaire de fichiers de votre hébergeur, colonne date de modification.

Les six étapes, dans cet ordre

1. Prévenir votre hébergeur. Avant tout le reste. Il a des sauvegardes, des journaux d'accès, et parfois déjà repéré l'incident sur d'autres sites du même serveur. C'est aussi lui qui peut suspendre proprement le site le temps de l'intervention.

2. Changer tous les mots de passe, depuis un autre appareil. Panneau d'hébergement, base de données, comptes d'administration du site, FTP, et la boîte mail associée. Depuis un autre appareil, parce que si le poste habituel est compromis, vous changez les mots de passe sous les yeux de l'attaquant.

3. Comprendre par où c'est entré, avant de restaurer. C'est l'étape qu'on saute et qu'on paie. Les portes d'entrée classiques : une extension ou un thème non mis à jour, un mot de passe d'administration faible, un fichier de sauvegarde ou de configuration laissé accessible publiquement.

4. Restaurer une sauvegarde antérieure à l'intrusion. Antérieure, pas la plus récente. Si l'intrusion date de trois semaines et que vous restaurez celle d'hier, vous restaurez aussi la porte dérobée.

5. Mettre à jour tout ce qui peut l'être, puis retirer ce qui ne sert pas. Une extension désactivée reste installée, donc reste attaquable.

6. Demander un réexamen à Google si le site a été signalé, depuis la Search Console. Sans cette demande, l'avertissement rouge peut rester affiché longtemps après la réparation.

L'erreur qui fait tout recommencer

Elle tient en une phrase : restaurer avant d'avoir identifié l'entrée. La restauration remet le site dans son état d'avant, y compris la faille qui a servi. L'attaque se rejoue, souvent dans les jours qui suivent, parfois automatiquement puisque beaucoup de compromissions sont le fait de robots qui repassent.

Deuxième erreur, plus insidieuse : croire qu'un site vitrine sans données clients n'intéresse personne. Ce qui intéresse, ce n'est pas votre contenu, c'est votre nom de domaine. Un domaine légitime, avec un peu d'ancienneté, sert à envoyer des e-mails qui passent les filtres et à héberger des pages qui se positionnent. Vous n'êtes pas la cible, vous êtes l'outil.

Ce qui réduit vraiment le risque, avant

Trois habitudes, dans l'ordre de leur rapport efficacité sur effort :

• Les mises à jour, appliquées. La très grande majorité des compromissions de sites de TPE exploite une faille connue et corrigée depuis des mois. Le correctif existait, il n'a pas été posé.
• Ne rien laisser traîner à la racine. Sauvegardes, exports de base, fichiers de configuration renommés en .old : c'est le sujet de notre article sur les fichiers qu'il ne faut jamais laisser accessibles.
• Une authentification à deux facteurs sur l'administration et sur la boîte mail associée. C'est ce qui neutralise un mot de passe volé.

Le reste, en-têtes de sécurité et durcissement du serveur, est traité dans le guide de la sécurité d'un site.

Ce qu'il faut conserver, et pourquoi

Le réflexe naturel après une intrusion est de tout nettoyer au plus vite. C'est compréhensible, et c'est la meilleure façon de perdre ce qui permettrait de comprendre.

Avant de restaurer, demandez à votre hébergeur une copie des journaux d'accès de la période concernée, et faites une sauvegarde du site compromis tel quel. Elle ne servira pas à être remise en ligne : elle sert à identifier le fichier modifié en premier, donc la porte d'entrée. Sans elle, vous restaurez à l'aveugle et vous ne saurez jamais si la faille est fermée.

Deux cas imposent des démarches supplémentaires. Si des données personnelles ont pu être consultées, le règlement européen impose de notifier l'autorité de contrôle dans les 72 heures, et d'informer les personnes concernées quand le risque est élevé pour elles. Un site vitrine avec un simple formulaire de contact est concerné si le carnet de messages était accessible.

Second cas : le dépôt de plainte. Il ne fera probablement pas retrouver l'auteur, et ce n'est pas son but. Il date officiellement l'incident, ce qui compte si un client conteste une facture, si votre assurance couvre le risque cyber, ou si votre domaine se retrouve sur une liste noire et qu'il faut prouver votre bonne foi pour en sortir.

Ce que notre audit mesure

La catégorie exposition et fichiers sensibles compte 8 vérifications : fichiers sensibles servis publiquement, listing de répertoire actif, version du logiciel annoncée par la balise generator, chemins d'administration et de déploiement accessibles, bibliothèques JavaScript abandonnées, chemins sensibles révélés par le robots.txt, messages d'erreur techniques visibles, et technologies détectées. Une catégorie voisine, exposition de la couche d'automatisation, en ajoute 4, dont les secrets et clés laissés en clair dans le code de la page.

Ce que l'audit ne fait pas, et c'est important : il regarde votre site de l'extérieur, comme un visiteur. Il ne détecte pas une porte dérobée déjà installée dans vos fichiers, ni un contenu injecté qui ne s'affiche que pour Google. Il mesure les portes ouvertes, pas les intrus déjà entrés. Après une compromission, un examen des fichiers côté serveur reste indispensable.