En bref : les attaques automatisées sur les serveurs web se déroulent par vagues : des programmes parcourent Internet à la recherche de serveurs accessibles, les classent d'après des caractéristiques externes et essaient en masse des failles connues comme PHP2Shell. La taille de l'entreprise n'y joue aucun rôle. Une protection est offerte par un PHP corrigé, une petite surface d'attaque et une surveillance qui remarque vite les succès.
Le point de départ : « Qui s'intéresserait à notre site ? »
Nous entendons souvent cette question après PHP2Shell, surtout de la part de petites entreprises. La réponse honnête : probablement personne en particulier. Mais ce n'est pas nécessaire avec des failles de ce type. Les attaques sont exécutées par des programmes qui ne cherchent pas des noms, mais des occasions.
Pour PHP2Shell, le BSI (office fédéral allemand de la sécurité des technologies de l'information) s'attendait à une exploitation rapide et à grande échelle. Cloudflare a fait état de tentatives d'attaque et du fait que les attaquants modifiaient leurs schémas pour contourner les règles de protection. Les deux correspondent à ce qui se produit régulièrement avec des failles critiques dans des logiciels très répandus.
Comment se déroulent les attaques automatisées sur les serveurs web
Les campagnes automatisées suivent le plus souvent un schéma similaire. L'aperçu suivant décrit les phases de manière générale, sans détails d'attaque :
| Phase | Ce qui se passe | Ce qui aide contre cela |
|---|---|---|
| Recherche | des programmes examinent de larges plages d'adresses ou des répertoires publics comme les journaux de certificats à la recherche de serveurs web accessibles | peu de systèmes accessibles publiquement, inventaire de toutes les adresses |
| Classement | les réponses sont analysées : serveur web, version de PHP, CMS, chemins typiques | masquer les indications de version, supprimer les fichiers inutiles |
| Essai | des failles connues sont testées en masse, souvent sans classement préalable | PHP à jour, redémarrage, WAF comme couche supplémentaire |
| Implantation | en cas de succès, une porte dérobée est déposée, par exemple un webshell ou une tâche cron | droits d'écriture restreints, aucune exécution PHP dans les dossiers d'envoi |
| Exploitation | le serveur est utilisé, par exemple pour le spam, le minage de cryptomonnaie, des redirections ou le vol de données | surveillance des processus, des fichiers et des connexions sortantes |
La troisième ligne est importante. De nombreuses campagnes ne se donnent même pas la peine de classer précisément les serveurs au préalable. Elles essaient simplement tout ce qui est accessible. C'est pourquoi la discrétion seule ne protège pas.
Pourquoi les attaques viennent par vagues
Les campagnes automatisées se déroulent rarement une fois puis plus jamais. Un schéma en vagues est typique. La première vague suit peu après la divulgation d'une faille, souvent encore avec des outils immatures. D'autres vagues viennent quand les attaquants améliorent leurs outils ou les adaptent aux règles de protection. Cloudflare a observé exactement cela avec PHP2Shell : des schémas d'attaque modifiés pour contourner les règles.
Pour vous, cela signifie : un serveur qui a traversé la première vague sans dommage n'est pas durablement sûr tant qu'il n'est pas corrigé. Et un serveur nouvellement installé devient une cible dès qu'il est accessible. Qui fait par exemple émettre un nouveau certificat TLS rend le nom visible dans les journaux de certificats publics, que les scanners exploitent aussi. Un nouveau système ne devrait donc être connecté au réseau qu'une fois déjà mis à jour.
Pourquoi les petites entreprises sont tout autant concernées
Pour les attaques automatisées, ce n'est pas la valeur d'une cible individuelle qui compte, mais le nombre. Le serveur d'une petite entreprise offre de la puissance de calcul, un domaine avec une bonne réputation, un envoi de courriels et parfois des données clients. Pour les attaquants, c'est suffisant.
À cela s'ajoute que les petites entreprises n'ont souvent pas d'informatique propre qui installe les mises à jour immédiatement. Leurs serveurs restent vulnérables plus longtemps et se retrouvent donc plus souvent dans les listes de résultats des scanners. Qui corrige en premier sort de ces listes.
Autre point : la chaîne d'approvisionnement. De nombreux petits sites se trouvent sur des serveurs d'agences ou de petits hébergeurs, où des dizaines de projets clients tournent côte à côte. Pour les attaquants, un tel serveur est particulièrement rentable, car un seul succès touche simultanément de nombreux sites. Votre risque ne dépend alors pas seulement de votre propre soin, mais aussi de celui de votre prestataire.
Les scans dans vos journaux sont normaux et ne prouvent pas une intrusion. Une attaque réussie se voit à d'autres traces : nouveaux fichiers, processus étrangers, comptes inconnus, connexions sortantes inhabituelles.
Ce que vous pouvez vérifier vous-même
Un regard dans les journaux montre à quel point votre serveur est scanné. Les commandes suivantes ne font que lire et ne modifient rien :
# Les dix adresses ayant envoyé le plus de requêtes dans le journal d'accès actuel
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10
# Requêtes ayant reçu la réponse « introuvable », par fréquence
awk '$9 == 404 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
# Le serveur révèle-t-il sa version de PHP dans l'en-tête ?
curl -sI https://www.example.de/ | grep -i "x-powered-by"
De nombreuses requêtes sur des chemins inexistants sont du bruit de scan typique. Soyez plus attentif si ces requêtes sont soudain suivies de réponses réussies, si des fichiers que vous ne connaissez pas sont appelés dans les dossiers d'envoi, ou si l'utilisateur du serveur web lance des processus qu'il ne lance jamais autrement. Il n'existe jusqu'à présent aucun indicateur de détection confirmé spécifiquement pour PHP2Shell ; l'évaluation repose donc sur de telles anomalies de comportement. La manière d'analyser les journaux plus à fond est décrite dans le guide Analyser les journaux du serveur web. Si la troisième requête affiche une version de PHP, le paramètre expose_php = Off vaut la peine ; le contexte figure sous Masquer les indications de version.
Les couches de protection dans le bon ordre
- Mettre PHP à jour et redémarrer : sans cette étape, toutes les autres mesures restent du bricolage.
- Réduire la surface d'attaque : désactiver ou placer derrière une authentification les sites inutilisés, systèmes de test et anciens microsites.
- Règles en périphérie : un pare-feu applicatif web avec un jeu de règles entretenu, par exemple le OWASP Core Rule Set avec ModSecurity, intercepte une partie des tentatives.
- Freiner les tentatives répétées : des outils comme Fail2ban bloquent les adresses qui génèrent un nombre anormal d'erreurs. Contre les scans distribués, cela n'aide que de façon limitée.
- Surveiller : garder à l'œil les processus de l'utilisateur du serveur web, les nouveaux fichiers PHP et les connexions sortantes, afin qu'un succès ne passe pas inaperçu pendant des semaines.
Comment PHP SOS aide-t-il concrètement ?
- Recenser la surface d'attaque : nous déterminons lesquels de vos systèmes sont accessibles de l'extérieur et ce qu'ils révèlent d'eux-mêmes.
- Corriger et durcir : nous mettons PHP à jour, redémarrons et réduisons les indications de version, les droits d'écriture et les services inutiles.
- Règles et blocages : nous mettons en place des règles WAF et des mécanismes de blocage adaptés à votre application.
- Surveillance continue : nous signalons les processus, fichiers et connexions suspects avant qu'un succès ne devienne un incident.
À quoi cela ressemble en fonctionnement continu, Surveillance de sécurité pour serveurs web le décrit.
Conclusion
Les attaques automatisées ne demandent pas à qui appartient un serveur. Elles demandent seulement s'il est vulnérable. La meilleure réponse est sans éclat : corriger vite, exposer peu, regarder de près. Qui le fait continue d'être scanné, mais n'est plus trouvé.
Questions fréquentes
Les petites entreprises sont-elles la cible d'attaques automatisées ?
Oui. Les scans automatisés examinent les serveurs accessibles sans considération pour l'exploitant. Qu'il s'agisse d'un groupe ou d'un artisan n'a aucune importance pour le logiciel. Ce qui compte, c'est de savoir si le serveur paraît vulnérable.
Comment reconnaître des scans dans mes journaux ?
Typiquement, de nombreuses requêtes sur des chemins qui n'existent pas du tout sur votre site, souvent depuis des adresses changeantes et avec des identifiants suspects. De telles entrées sont normales et ne prouvent pas encore une attaque réussie, mais montrent que votre serveur est testé.
Masquer la version de PHP aide-t-il ?
Cela complique un peu la tâche des scanners pour classer précisément votre serveur et constitue un réglage de base judicieux. Mais cela ne protège pas contre des attaques qui essaient simplement tous les serveurs. La mise à jour reste obligatoire.
Puis-je empêcher complètement les scans ?
Non. Tout serveur accessible publiquement est scanné régulièrement. L'objectif n'est pas d'empêcher les scans, mais de faire en sorte qu'ils ne trouvent rien : logiciels à jour, peu de surface d'attaque et une surveillance qui signale les anomalies.