En bref : les traces montrent s'il s'agit d'un DDoS ou d'un piratage. Un DDoS génère de très nombreuses requêtes et rend le site lent ou inaccessible, mais ne modifie rien. Un exploit n'a souvent besoin que de quelques requêtes et laisse de nouveaux fichiers, comptes, processus ou connexions. La bonne qualification détermine si vous devez repousser une charge ou contenir un incident.
La différence en termes simples
Une attaque DDoS (Distributed Denial of Service) est comme une foule qui bloque l'entrée d'un magasin. Personne ne peut entrer, mais rien n'est volé dans la boutique. Le but est de surcharger votre site ou votre serveur afin que les vrais clients n'arrivent plus à passer.
Un exploit, en revanche, est une intrusion par une porte ouverte. L'attaquant exploite une vulnérabilité, par exemple dans PHP, dans le CMS ou dans une extension, pour exécuter du code sur votre serveur. Cela peut se faire discrètement, sans que le site ne ralentisse. Les conséquences vont des pages de spam au vol de données, jusqu'à la prise de contrôle du serveur.
Pour la direction, la différence est décisive : un DDoS est un problème de disponibilité qui prend fin avec l'attaque. Un exploit réussi est un incident de sécurité qui persiste jusqu'à ce qu'il soit trouvé, nettoyé et documenté.
DDoS ou piratage : les signes comparés
Le tableau suivant aide pour la première qualification. Il ne remplace pas une analyse, mais montre où regarder en premier.
| Caractéristique | Plutôt DDoS | Plutôt exploit ou intrusion |
|---|---|---|
| Accessibilité | lent ou en panne | souvent normale |
| Requêtes dans le journal | très nombreuses, souvent uniformes | peu de requêtes ciblées |
| Fichiers | inchangés | fichiers PHP nouveaux ou modifiés |
| Comptes | inchangés | nouveaux admins, mots de passe modifiés |
| Processus | serveur web et PHP à pleine charge | processus inconnus, minage, envoi de spam |
| Réseau | beaucoup de trafic entrant | connexions sortantes inhabituelles |
| Après la fin | tout comme avant | les traces subsistent |
Attention aux recoupements : un balayage massif à la recherche d'une faille peut ressembler à un petit DDoS. C'est précisément ce à quoi il fallait s'attendre autour de PHP2Shell, lorsque des attaquants recherchaient des serveurs vulnérables. Une charge élevée peut donc aussi signifier que quelqu'un tente en ce moment de s'introduire.
Premiers contrôles sur le serveur
Les commandes suivantes ne modifient rien dans le système et donnent un aperçu rapide. En cas de soupçon d'intrusion, sauvegardez les journaux avant d'entreprendre des interventions plus importantes.
# Charge et durée de fonctionnement
uptime
# Connexions résumées et interlocuteurs les plus fréquents
ss -s
ss -tn state established | awk 'NR>1 {print $4}' | cut -d: -f1 | sort | uniq -c | sort -rn | head
# Adresses clientes les plus fréquentes dans le journal d'accès (adapter le chemin)
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
# Fichiers PHP modifiés au cours des 7 derniers jours
find /var/www -type f -name '*.php' -mtime -7 -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort
# Processus avec la charge CPU la plus élevée
ps aux --sort=-%cpu | head -15
Dans l'aperçu des connexions, la quatrième colonne indique l'interlocuteur. De nombreuses connexions provenant de peu d'adresses ou une hausse à un multiple de la valeur normale indiquent une surcharge. De nouveaux fichiers PHP dans les répertoires d'upload ou de cache, des processus sous l'utilisateur du serveur web avec des noms inconnus ou des connexions sortantes vers des destinations inconnues indiquent plutôt une intrusion. Vous trouverez une liste détaillée sous Signes de compromission après PHP2Shell.
Pourquoi une charge élevée peut aussi être une diversion
Il arrive que des attaquants provoquent une surcharge tout en s'introduisant en même temps de façon ciblée. L'équipe est alors occupée par la disponibilité, et les véritables traces se noient dans le bruit des journaux. C'est pourquoi, même si un DDoS est manifeste, vérifiez après sa fin les fichiers, les comptes et les connexions sortantes.
Dans le cas de PHP2Shell s'ajoute le fait que, selon php.net et les sociétés de sécurité, il n'existe aucun indicateur de compromission confirmé publié. La détection repose sur l'analyse du comportement. Un serveur qui n'était pas corrigé pendant la période de balayage à partir de la mi-octobre devrait donc être contrôlé indépendamment de la charge observée.
Une autre variante consiste en des e-mails d'extorsion menaçant d'une attaque DDoS si l'on ne paie pas. Conservez de tels messages, ne payez pas sans concertation avec des spécialistes et envisagez un signalement auprès de la Zentrale Ansprechstelle Cybercrime, le point de contact central allemand pour la cybercriminalité. Informez en parallèle votre hébergeur afin que des mesures de protection puissent être préparées. La façon d'analyser les journaux à cette fin est décrite dans le guide Analyser les journaux du serveur web après une attaque.
Que faire dans les premières heures
En cas de soupçon de DDoS :
- Informer l'hébergeur ou le centre de données ; il existe souvent des filtres en amont du serveur.
- Activer ou renforcer un service de protection en amont ou un WAF avec correctif virtuel.
- Définir des limites de débit dans le serveur web et protéger tout particulièrement les pages coûteuses comme la recherche ou le panier.
- Conserver les journaux afin que l'attaque puisse être retracée plus tard.
En cas de soupçon d'intrusion :
- Ne rien supprimer et ne pas réinstaller le serveur avant que les journaux et les fichiers concernés aient été sauvegardés.
- Mettre PHP à jour vers une version corrigée et redémarrer tous les workers, si ce n'est pas encore fait.
- Si la mise à jour n'est pas possible immédiatement, mettre le site temporairement hors ligne, comme le BSI (office fédéral allemand de la sécurité des technologies de l'information) le recommande.
- Renouveler les identifiants depuis un appareil sain, pas depuis le serveur éventuellement touché.
- Faire vérifier si des données personnelles pourraient être concernées ; des délais de notification peuvent alors courir.
Dans les deux cas, une note brève et factuelle pour l'hébergeur et les prestataires est utile : depuis quand le problème existe, quels sites sont concernés, ce que vous avez observé et ce qui a déjà été modifié. Consignez en outre qui a pris quelle décision. Cette chronologie fait gagner du temps lors de l'analyse et est précieuse plus tard pour l'assurance, la protection des données et le bilan interne. S'il n'est pas clair qu'il y ait seulement une attaque, traitez la situation par précaution comme un incident, jusqu'à preuve du contraire.
Comment PHP SOS aide-t-il concrètement ?
- Nous qualifions la situation à distance à partir de la charge, des journaux, des fichiers et des connexions et vous disons à quoi vous avez probablement affaire.
- En cas de surcharge, nous mettons en place des filtres, des limites de débit et des règles de protection en amont jusqu'à ce que l'attaque s'estompe.
- En cas de soupçon d'intrusion, nous prenons en charge la réponse à incident structurée : sauvegarder, contenir, trouver la cause, nettoyer.
- À la fin, nous documentons ce qui s'est passé et quelles mesures ont été mises en œuvre, jusqu'à la clôture de l'incident.
Questions fréquentes
Une attaque DDoS peut-elle voler des données ?
Une attaque DDoS pure vise la disponibilité, pas les données. Elle ne modifie aucun fichier et ne lit aucune base de données. Elle peut toutefois survenir en même temps qu'une tentative d'intrusion ; un coup d'œil aux fichiers et aux comptes vaut donc quand même la peine.
À quoi reconnaître que mon site a été piraté ?
Sont typiques de nouveaux fichiers PHP ou des fichiers PHP modifiés, des comptes administrateur inconnus, des redirections vers des sites étrangers, des connexions sortantes inattendues et des processus qui ne correspondent pas à votre application. Un seul signe n'est pas une preuve, plusieurs ensemble sont un signal sérieux.
Un CDN ou un WAF aide-t-il contre les deux types d'attaque ?
Contre les attaques volumétriques, un service placé en amont aide généralement bien. Contre les exploits, les règles ne fonctionnent que si elles reconnaissent le motif. Pour PHP2Shell, Cloudflare souligne lui-même que des règles fondées sur les seules données de la requête ne suffisent pas.
Dois-je signaler une attaque DDoS ?
Cela dépend du cas particulier et de votre secteur. Sans accès à des données personnelles, l'obligation de notification du RGPD ne s'applique en général pas, mais des obligations sectorielles peuvent exister. Clarifiez ce point avec votre délégué à la protection des données ou un avocat.