Incident de sécurité : que faire les 4 premières heures

Un client qui appelle parce que Google affiche « site trompeur » sur son e-commerce, une redirection qui envoie les visiteurs vers une pharmacie russe, un pic CPU inexplicable à 3 h du matin, un formulaire qui envoie désormais les paniers ailleurs. Quand un incident de sécurité frappe, les quatre premières heures conditionnent à la fois la qualité du nettoyage et vos obligations légales. Ce runbook donne le déroulé minute par minute, avec les bons réflexes et ceux qu'il faut absolument éviter.

Signaux d'incident à reconnaître

• Google Search Console ou le navigateur affiche « Site trompeur », « Contenu trompeur », « Logiciel malveillant ».
• Redirections vers des domaines inconnus, souvent visibles uniquement depuis mobile ou depuis un referrer Google.
• Contenus injectés : pages ou articles en pharma, casino, contrefaçon, liens sortants vers des domaines douteux.
• Charge CPU anormale, pics PHP-FPM, load qui grimpe sans trafic légitime en face.
• Alerte Matomo ou outil d'analytics : pic de visites sur une URL inconnue, taux de rebond à 100 %.
• Nouveaux comptes admin, horaires de connexion inhabituels, fichiers modifiés en masse dans wp-content/, plugins/, uploads/.
• Le client qui vous appelle parce qu'un de ses visiteurs lui a signalé l'anomalie.

T+0 : ne touchez à rien avant d'avoir une copie

Le premier réflexe naturel est le pire : vouloir « vite nettoyer ». Résistez. Un site compromis est une scène. Les preuves (timestamps, fichiers modifiés, lignes de logs, contenus injectés) sont indispensables pour comprendre comment ça s'est passé et d'où ça vient. Sans ça, vous restaurez un backup et vous vous faites re-compromettre dans les 48 h par la même porte dérobée.

Dans l'ordre :

1. Snapshot de la VM si vous gérez l'hyperviseur, ou ticket Datacampus pour demander un snapshot immédiat.
2. Backup Plesk complet de l'abonnement (inclut fichiers, DB, config mail). Menu Sauvegarde et restauration > Sauvegarder, cocher tout.
3. Copie des logs pendant qu'ils contiennent encore la fenêtre d'intrusion :

   mkdir -p ~/incident-$(date +%Y%m%d)/logs
   cp /var/www/vhosts/exemple.fr/logs/access_ssl_log* ~/incident-$(date +%Y%m%d)/logs/
   cp /var/www/vhosts/exemple.fr/logs/error_log* ~/incident-$(date +%Y%m%d)/logs/
   cp /var/log/apache2/access.log* ~/incident-$(date +%Y%m%d)/logs/ 2>/dev/null
   cp /var/log/auth.log* ~/incident-$(date +%Y%m%d)/logs/ 2>/dev/null

4. Notez l'heure de détection et ce qui vous a alerté. Ce sera la ligne 1 de votre ticket et de votre notification CNIL si besoin.

T+15 min : isoler le site

L'objectif est de bloquer les visiteurs pour stopper le préjudice, sans détruire le contenu compromis. On veut pouvoir l'examiner ensuite.

Option A — Mode maintenance Plesk

Dans l'abonnement > Sites Web & Domaines > Hébergement & DNS > activer Maintenance. Plesk renvoie une page statique neutre.

Option B — .htaccess deny all sauf votre IP

# À la racine du vhost (httpdocs/.htaccess)
<RequireAll>
    Require ip 203.0.113.42
</RequireAll>
ErrorDocument 403 "Site en maintenance"

Remplacez 203.0.113.42 par votre IP publique (curl ifconfig.me). Avec Apache event + PHP-FPM, la directive est lue immédiatement, pas besoin de reload.

T+30 min : périmétrer

Un site compromis est rarement isolé. La question n'est pas « qu'est-ce qui est touché ? » mais « qu'est-ce qui n'est pas touché ? ».

• VM dédiée compromise = toute la VM est suspecte. Tous les services qui y tournent (autres sites, scripts, cron) sont à considérer comme potentiellement compromis tant que vous n'avez pas prouvé le contraire.
• WordPress compromis dans un hosting Plesk mutualisé = les autres domaines du même user Plesk sont potentiellement touchés aussi (permissions Unix partagées, PHP-FPM pool commun selon la config).
• Compte FTP ou SSH compromis = tous les sites accessibles depuis ce compte sont à auditer.

Listez explicitement le périmètre affecté. Ça servira pour le ticket, la notification CNIL, et surtout pour la remediation.

# Lister les vhosts du même user Plesk
ls -la /var/www/vhosts/
# Fichiers modifiés dans les 7 derniers jours sur tout le vhost
find /var/www/vhosts/exemple.fr/ -type f -mtime -7 -ls 2>/dev/null | head -100

T+1h : couper les accès

Partez du principe que tous les credentials exposés au site sont compromis. On rote tout, sans exception.

Checklist de rotation

• Plesk : mot de passe du compte client et de l'abonnement.
• WordPress / PrestaShop / Drupal : tous les comptes admin, puis forcer la déconnexion de toutes les sessions (wp user session destroy --all).
• Base de données : utilisateur MySQL du site, mettre à jour wp-config.php / parameters.php avec le nouveau mot de passe.
• FTP / SFTP : tous les utilisateurs Plesk qui ont un accès.
• SSH : supprimer les clés inconnues dans ~/.ssh/authorized_keys, changer le mot de passe du compte système.
• API keys : Stripe, PayPal, Mailchimp, reCAPTCHA, toutes les clés visibles dans wp-config.php, .env, plugins de paiement.
• SMTP : credentials utilisés par le site pour envoyer des mails (formulaires de contact, commandes). Si la boîte a été utilisée pour du spam, vous risquez un blacklistage IP.
• Salts WordPress : régénérer les 8 clés dans wp-config.php via l'API officielle. Ça invalide tous les cookies de session existants.

Salts WordPress, exemple

cd /var/www/vhosts/exemple.fr/httpdocs
# Sauvegarder avant de modifier
cp wp-config.php wp-config.php.before-incident
# Récupérer de nouveaux salts
curl -s https://api.wordpress.org/secret-key/1.1/salt/
# Les copier-coller dans wp-config.php à la place des anciens

T+2h : diagnostic et ticket Datacampus

Ouvrez un ticket sur le ServiceDesk Datacampus avec la mention « Incident de sécurité » en objet. Ça déclenche un traitement prioritaire.

Contenu du ticket

• Timestamp de détection et ce qui vous a alerté.
• Périmètre identifié à T+30 : quel domaine, quel vhost, quel user, quelle VM.
• Symptômes précis : URLs suspectes, redirections observées, capture d'écran de l'alerte Google si applicable.
• Logs pertinents déjà identifiés : extraits d'access_ssl_log et error_log avec la fenêtre temporelle suspecte.
• Actions déjà réalisées : snapshot fait, site isolé, credentials rotés.
• Plan d'action envisagé et points sur lesquels vous avez besoin d'aide.

Ce que l'équipe Datacampus peut apporter côté infra :

• Logs réseau edge : connexions entrantes, patterns d'attaque, scan de ports.
• WAF Cloudflare (si l'option est activée sur l'offre) : règles de blocage, signatures déclenchées, géolocalisation des IP sources.
• Analyse des IP sources : corrélation avec d'autres incidents connus, blacklistage IP côté edge.
• Restauration d'un snapshot antérieur si vous avez identifié une date avant compromission.

Quelques grep utiles pendant que le ticket avance

# Requêtes POST suspectes vers wp-login ou xmlrpc
grep -E "POST /(wp-login|xmlrpc)" /var/www/vhosts/exemple.fr/logs/access_ssl_log | \
  awk '{print $1}' | sort | uniq -c | sort -rn | head -20

# Fichiers PHP modifiés dans uploads (interdit en temps normal)
find /var/www/vhosts/exemple.fr/httpdocs/wp-content/uploads/ -name "*.php" -ls

# Fichiers qui contiennent du base64 ou eval suspect
grep -rlE "eval\s*\(\s*base64_decode|gzinflate\s*\(\s*base64" \
  /var/www/vhosts/exemple.fr/httpdocs/ 2>/dev/null

T+3h : notifier

Si des données personnelles sont compromises

Obligation RGPD, article 33 : notification à la CNIL dans les 72 heures après la prise de connaissance de la violation. Le délai court depuis T+0 détection, pas depuis la fin du nettoyage.

• Violation avérée ou suspicion forte : déclaration via le téléservice CNIL.
• Si la violation est susceptible d'engendrer un risque élevé pour les droits et libertés des personnes (mots de passe en clair, données bancaires, données de santé), information directe des personnes concernées.
• Documenter la violation dans votre registre interne, même si vous jugez que la notification n'est pas nécessaire.

Communication clients et utilisateurs

La règle est la transparence factuelle. Un communiqué court qui dit :

• ce qui s'est passé (sans minimiser, sans dramatiser),
• ce qui est concerné et ce qui ne l'est pas,
• ce que vous faites,
• ce que la personne doit faire de son côté (changer son mot de passe typiquement),
• un point de contact.

Éviter les formulations vagues type « un incident technique » quand il s'agit d'une compromission avec fuite. Ça se retourne toujours contre l'émetteur quelques jours plus tard.

T+4h : nettoyage

Maintenant seulement, et après avoir vérifié que le snapshot de T+0 est bien disponible, on peut nettoyer.

Procédure de restauration

1. Identifier la date de compromission la plus ancienne possible (via les logs, les timestamps des fichiers suspects).
2. Choisir un backup Plesk antérieur à cette date. Si le plus ancien backup disponible est lui-même postérieur, ticket Datacampus pour voir ce qui est récupérable côté Ceph.
3. Restaurer dans un abonnement de staging d'abord, pas directement sur la prod. Vérifier que le contenu restauré est sain (pas de fichier PHP bizarre dans uploads/, pas d'utilisateur admin inconnu, pas de redirection).
4. Mettre à jour core + plugins + thèmes à la dernière version stable avant la remise en ligne.
5. Réappliquer les salts, credentials, clés API fraîchement générés à T+1.
6. Retirer le mode maintenance et monitorer la charge et les logs pendant 24 h.

Le détail du nettoyage (cas où vous n'avez pas de backup sain) est couvert dans la doc Mon site a été piraté : que faire.

Post-incident

Les 48 h qui suivent sont aussi importantes que les 4 premières heures. Sans post-mortem, l'incident se reproduit.

• Post-mortem écrit : chronologie, vecteur d'entrée identifié (ou hypothèse la plus probable), périmètre final, durée d'exposition, données concernées, actions correctives.
• Mise à jour du hardening : voir Hardening général d'un site WordPress. Désactivation XML-RPC, limitation des tentatives de login, restriction des extensions exécutables dans uploads/.
• Audit de sécurité plus large : Audit de sécurité rapide pour checker les autres sites du même périmètre.
• 2FA partout : Plesk, WordPress admins, comptes Datacampus, comptes email. Si ce n'était pas en place avant l'incident, c'est le moment.
• Monitoring renforcé : surveillance des fichiers modifiés (Wazuh, Tripwire léger), alerte sur création de compte admin WP.
• Demande de revue Google : dans Search Console > Problèmes de sécurité, demander une nouvelle analyse une fois le site propre. Délai typique 24 à 72 h pour la levée du warning navigateur.

Récapitulatif

1. T+0 : snapshot, backup, copie des logs. Rien supprimer.
2. T+15 : isoler (mode maintenance ou .htaccess deny all sauf votre IP).
3. T+30 : périmétrer (VM, user Plesk, sites voisins).
4. T+1h : couper les accès, rotate tous les credentials, régénérer les salts.
5. T+2h : ticket Datacampus avec timestamp, périmètre, logs, plan d'action.
6. T+3h : notification CNIL si données personnelles compromises, communication clients.
7. T+4h : restauration depuis backup sain antérieur, maj, réapplication des nouveaux secrets.
8. J+1 à J+7 : post-mortem, hardening, 2FA partout, demande de revue Google.