Surveillance continue après un incident : fichiers, URL, admins

Pourquoi le premier mois n'est pas « après »

La porte oubliée se manifeste souvent entre J+2 et J+20 : un cron qui n'a pas encore tourné, un cache objet qui n'a pas encore resservi le JS, un attaquant qui attend que vous baissiez la garde. Crier victoire le soir du nettoyage est le scénario de la majorité des seconds appels.

Notre garantie, quand elle s'applique, couvre précisément cette fenêtre pour la même faille. Elle ne remplace pas vos yeux — ou un filet qui vous écrit quand un `radio.php` apparaît. Les deux se complètent.

Le guide des premiers gestes clôt l'urgence. Cet article ouvre le quotidien. Sans ce quotidien, le bel ordre du jour J se défait tout seul.

Trois signaux, pas trente tableaux

On se noie dans les suites « sécurité » qui envoient 400 mails. Trois familles suffisent. Un fichier (ou une date de modification) qui n'aurait pas dû bouger. Un utilisateur à privilège créé ou réélevé. Un volume d'URL nouvelles hors sitemap, vu par Search Console ou par un crawl interne.

Tout le reste (CVE du jour, scan de ports, note A+ d'un tester en ligne) peut attendre le mercredi calme. Pendant trente jours, ces trois-là ont priorité. S'ils restent verts, vous avez le droit de relâcher un cran.

Choisissez des seuils bêtes : tout PHP créé à la racine ; tout rôle administrateur ; plus de N URL indexées en 24 h hors plan de site. Les seuils intelligents arrivent plus tard, quand vous n'êtes plus en sevrage d'incident.

• Fichier : nouveau PHP, `.htaccess`, mu-plugin, cron.
• Identité : admin CMS, utilisateur FTP, invitation GSC/GTM.
• Index : pic d'URL, titres étrangers, sitemap inconnu.

Fichiers : ce qui mérite une alerte

Un inventaire des hashes juste après nettoyage vaut mieux qu'un antivirus en temps réel mal réglé. WordPress : cœur et extensions comparés aux zips, alerte sur `wp-content/mu-plugins`, `uploads` qui deviennent exécutables, racine. PrestaShop : `/modules` et override. PHP métier : les dossiers que vous avez cartographiés, pas « tout le disque ».

L'hébergeur a parfois une notification « fichier modifié ». Activez-la si elle n'aboie pas à chaque cache. Sinon un cron quotidien qui liste les PHP plus récents que la date de clôture. Simple. Relisible. Suffisant pour attraper le retour du même payload.

N'alertez pas sur chaque image. Alertez sur les extensions dangereuses et les doubles extensions. Le bruit tue la surveillance plus sûrement qu'un attaquant discret.

Admins, FTP, invitations

Un compte `agence2023` qui se réélève tout seul n'est pas un CVE. C'est quelqu'un qui a encore une session ou un mot de passe. Listez les admins le jour de la clôture, photographiez l'écran, comparez chaque semaine le premier mois. Panel : utilisateurs FTP. Search Console et GTM : invitations. Business Manager : partenaires.

Les mots de passe d'application WordPress survivent au mot de passe principal. Relisez-les. Application passwords oubliés.

Si vous travaillez avec des stagiaires et des freelances, la revue après chaque mission est de la surveillance préventive. Compte encore ouvert. Moins spectaculaire qu'un webshell, plus fréquent.

URL inconnues et `site:`

Un `site:votre-domaine.fr` le lundi matin, comparé au sitemap, attrape le générateur plus tôt que le client qui tombe sur une pharmacie. Search Console : pages indexées, sitemaps, éventuellement alerte par email sur les problèmes de sécurité — celle-là, vous la gardez.

Un pic d'impressions sur des requêtes hors métier (casino, médicament, prêt) arrive parfois avant que vous voyiez les URL. Ce n'est pas « le SEO qui revient ». C'est un signal.

Pour le multilingue, surveillez les locales qui n'existent pas. Hreflang et sitemaps détournés.

Ce qu'un plugin de scan ne voit pas

Le voisin de compte. Le cron système. Le container GTM. Le pixel ajouté dans le thème enfant. Adminer oublié. Le `.git`. Un webhook boutique. Le plugin regarde « son » WordPress. L'attaquant, lui, n'a pas cette politesse.

Gardez le scan comme filet de signatures, une fois le site propre. N'en faites pas la seule sentinelle. Pendants l'attaque, il ajoute du bruit ; après, il rassure à tort si vous n'avez que lui.

Un WAF cloud voit d'autres choses (pics d'admin-ajax, user-agents). Utile en complément, pas en substitut des trois signaux. Et il ne dit rien d'un utilisateur FTP créé dans o2switch.

Qui reçoit l'alerte, qui révoque

Une alerte qui tombe dans la boîte de l'ancien webmaster ne sert à rien. Deux destinataires vivants, dont un qui a le droit de révoquer (panel, CMS). Documentez-le comme vous documentez les accès prestataire : nominatif, révocable.

Le week-end compte. Les générateurs n'attendent pas le mardi. Un SMS ou un canal court pour « PHP à la racine » / « nouvel admin », le reste en mail quotidien.

Si vous nous confiez un suivi, le périmètre est écrit : mêmes trois signaux, fenêtre, hors nouvelle extension que vous posez sans nous le dire. Pas un SOC théâtre.

Arrêter, alléger, ou garder un an

Après trente jours calmes, vous pouvez passer à un rythme hebdomadaire sur les fichiers et mensuel sur `site:`. Gardez l'alerte sécurité Search Console. Gardez la revue des admins à chaque fin de mission prestataire.

Garder le mode « J+3 » pendant deux ans épuise tout le monde : on ignore les mails, puis on rate le vrai. La surveillance qui dure est celle qu'on lit encore.

Si un deuxième incident arrive, on remonte le régime. Et on se demande quelle porte le premier filet n'avait pas dans sa liste — souvent le cron système, le GTM, ou le blog vitrine à côté de la boutique.