Les signes qui doivent alerter

Une intrusion n'est pas toujours spectaculaire. Les attaquants cherchent souvent à rester discrets pour exploiter le site le plus longtemps possible. Plusieurs signes doivent vous alerter :

  • des pages modifiées, ou des contenus que personne n'a publiés ;
  • des redirections vers des sites inconnus, parfois uniquement pour les visiteurs issus des moteurs de recherche ou sur mobile ;
  • un avertissement de Google dans les résultats de recherche ou dans la Search Console ;
  • une alerte de votre hébergeur signalant un envoi massif d'emails ou une consommation anormale de ressources ;
  • des comptes administrateur que vous ne connaissez pas ;
  • des fichiers PHP inconnus dans les répertoires du site, notamment dans le dossier des fichiers déposés.

Les premières mesures, dans l'ordre

1. Ne rien effacer

Le premier réflexe, supprimer les contenus suspects, est une erreur. Les fichiers, la base de données et les journaux du serveur sont des éléments indispensables pour comprendre comment l'attaquant est entré. Commencez par réaliser une copie complète du site dans son état actuel, et conservez-la à l'écart.

2. Limiter l'impact

Selon la gravité de l'attaque, placez le site en maintenance ou mettez-le temporairement hors ligne. Un site qui diffuse des contenus malveillants porte atteinte à vos visiteurs et à votre réputation, et risque d'être bloqué par les moteurs de recherche.

3. Changer tous les accès

Mots de passe des comptes administrateur, de l'hébergement, de la base de données, des accès SFTP et SSH, ainsi que les clés d'API des services connectés. Partez du principe que tous les identifiants présents sur le serveur ont pu être lus.

4. Prévenir les personnes concernées

Informez votre hébergeur et, le cas échéant, votre responsable de la sécurité des systèmes d'information. Si des données personnelles ont pu être consultées ou dérobées, le RGPD impose de notifier la violation à la CNIL dans un délai de 72 heures après en avoir pris connaissance, et dans certains cas d'informer les personnes concernées.

Comprendre l'origine de l'intrusion

Restaurer une sauvegarde sans comprendre ce qui s'est passé revient à laisser la porte ouverte : l'attaque se reproduira. L'analyse porte sur plusieurs pistes :

  • Une version vulnérable du cœur de Drupal ou d'un module, pour laquelle un correctif était disponible mais n'avait pas été appliqué. C'est de loin la cause la plus fréquente.
  • Un mot de passe compromis, trop simple ou réutilisé sur un autre service.
  • Une faille dans le code spécifique du site.
  • Un autre site hébergé sur le même serveur, par lequel l'attaquant a pu rebondir.

Les journaux du serveur web, la date de modification des fichiers et la comparaison du code avec les versions officielles de Drupal permettent généralement d'identifier la faille exploitée.

Nettoyer et restaurer

Un nettoyage fiable ne consiste pas à supprimer les fichiers suspects un par un. La méthode sûre est de reconstruire le site à partir de sources saines :

  1. réinstaller le cœur de Drupal et les modules contribués depuis leurs sources officielles, dans leurs versions à jour ;
  2. reprendre le code spécifique depuis le dépôt de versions, après vérification ;
  3. analyser la base de données pour supprimer les comptes, contenus et scripts injectés, ou restaurer une sauvegarde antérieure à l'intrusion si elle existe et si la perte de contenus récents est acceptable ;
  4. contrôler le dossier des fichiers déposés et y interdire l'exécution de scripts PHP ;
  5. vérifier l'ensemble du site avant de le remettre en ligne.

Si le site a été signalé par Google, une demande de réexamen peut ensuite être effectuée depuis la Search Console.

Éviter que cela se reproduise

La très grande majorité des intrusions sur des sites Drupal exploitent des failles connues, pour lesquelles un correctif était disponible. La prévention repose donc avant tout sur la régularité :

  • une veille quotidienne des avis de sécurité Drupal et application rapide des correctifs ;
  • une version de Drupal encore supportée : un site sous Drupal 7 ne reçoit plus de correctifs officiels ;
  • des sauvegardes automatiques, conservées hors du serveur et régulièrement testées ;
  • des comptes administrateur limités au strict nécessaire, avec des mots de passe robustes ;
  • un hébergement à jour et correctement configuré.

Un cas client

Le site du Lycée Léonard de Vinci, à Antibes, réalisé sous Drupal 7 par un autre prestataire, avait été piraté à cause d'une version de Drupal obsolète. Nous l'avons restauré, puis avons assuré le suivi régulier de ses mises à jour de sécurité. Ce type d'incident est presque toujours évitable : c'est la raison d'être de notre veille de sécurité.

Votre site présente des signes d'intrusion ? Contactez-nous sans attendre : chaque heure compte.