En bref : vous êtes concerné ? Appelez-nous. Nous vous aidons. Dans les entreprises de taille moyenne, il manque souvent un service de sécurité interne, et c'est précisément pour cela que nous sommes là : dès le premier message, nous assurons à distance les premiers secours pour vos serveurs web, sécurisons les traces, fermons la faille, nettoyons et documentons, jusqu'à la clôture de l'incident.
Ne supprimez rien et ne réinstallez rien pour l'instant. Cela vaut aussi lorsque l'activité presse et que le site doit repartir. D'abord sécuriser, ensuite réparer. Signaler une urgence : nous vous disons ce que vous pouvez faire vous-même sans risque.
Êtes-vous concerné ? La situation typique des entreprises de taille moyenne
Qui dirige une entreprise de 20, 200 ou 800 salariés a généralement une ou deux personnes pour l'informatique, une agence pour le site web et un hébergeur pour le serveur. C'est normal, mais cela rend les lacunes visibles en cas d'urgence. Un danger aigu est probable lorsque :
- Votre site web, votre portail client ou votre boutique en ligne fonctionne sur PHP et que personne ne sait avec certitude quelle version exactement.
- Un hébergeur, un client ou un avertissement du navigateur signale des anomalies.
- Votre administrateur rapporte que des fichiers ou des comptes sur le serveur web sont inexplicables.
- Vous ne savez pas quels systèmes sont joignables publiquement.
- Le serveur web a accès à des systèmes internes, des bases de données ou des espaces de fichiers.
La presse spécialisée cite comme contexte que presque toutes les versions de PHP peuvent être concernées : selon des rapports, les versions remontent jusqu'à PHP 5.4. La page Sécurité informatique pour les PME et l'industrie décrit la situation dans les entreprises de taille moyenne.
Ce que vous faites tout de suite
- Constituer une cellule de crise. La direction, l'informatique et, le cas échéant, la protection des données : peu de personnes, un seul décideur.
- Recenser les systèmes. Quels serveurs, sites web et portails sont concernés ou pourraient l'être ? Une simple liste suffit.
- Ne rien modifier. Aucune opération de rangement, aucune réinstallation, aucune restauration de sauvegardes.
- Faire vérifier les liaisons. Le serveur web est-il relié au réseau interne ? Une attaque contre le site peut alors concerner plus que le seul site.
- Contacter l'hébergeur et l'agence. Demandez aux deux de conserver les journaux et de confirmer l'état et les responsabilités. La marche à suivre figure sous Comment interroger votre hébergeur sur l'état des correctifs.
- Sécuriser les accès. Ne changez les mots de passe et les clés qu'après concertation et depuis des appareils sains.
- Contactez-nous maintenant. Appelez-nous ou écrivez-nous sur WhatsApp.
Premiers secours pour serveurs web : comment nous procédons dans les entreprises de taille moyenne
Une entreprise de taille moyenne ne peut pas se permettre un arrêt, mais pas non plus une intervention incontrôlée. C'est pourquoi nous travaillons par étapes, qui perturbent le moins possible l'activité en cours :
- Étape 1, isoler : nous clarifions s'il faut limiter temporairement les serveurs concernés. Pour PHP2Shell, le BSI (l'office fédéral allemand de la sécurité des technologies de l'information) recommande de retirer les serveurs web du réseau lorsqu'une mise à jour n'est pas possible immédiatement.
- Étape 2, sécuriser : nous sécurisons les journaux, les fichiers et les bases de données, afin que l'incident reste démontrable.
- Étape 3, corriger : correctif ou configuration, redémarrage de tous les processus PHP, fermeture des accès inconnus.
- Étape 4, vérifier : nous recherchons sur le système et dans son environnement des traces et des dommages collatéraux, y compris sur les serveurs voisins.
Un point décisif pour les décideurs : une mise à jour du CMS, par exemple de WordPress, ne ferme pas la faille PHP, et un correctif ne supprime pas un code malveillant déjà introduit. Qui dit « terminé » après la mise à jour n'a fait que la moitié du travail.
Erreurs typiques dans les entreprises de taille moyenne durant les premières heures
La pratique révèle quelques schémas qui aggravent les dégâts. Premièrement, la responsabilité est renvoyée de l'un à l'autre : l'hébergeur renvoie au client, l'agence à l'hébergeur, l'administrateur à la direction. Fixez donc tôt qui décide. Deuxièmement, la restauration est trop rapide. Restaurer une ancienne sauvegarde sans fermer la porte d'entrée ramène aussitôt l'attaquant. Troisièmement, la communication est laissée de côté : les collaborateurs, les clients et les partenaires commerciaux apprennent l'incident de seconde main.
Dans Communication de crise après une attaque, vous trouverez des conseils pour résoudre cela calmement. Règle empirique : mieux vaut en dire peu, mais de façon étayée.
Comment PHP SOS aide-t-il concrètement ?
- Faire le point : nous clarifions avec vous les systèmes, le mode d'exécution (PHP-FPM, mod_php ou LiteSpeed), les données et les interlocuteurs. Une première vue d'ensemble se dessine vite, même sans connaissances détaillées.
- Sécuriser et fermer : nous sécurisons les traces et fermons la porte d'entrée sans perturber inutilement vos processus.
- Examiner et nettoyer : les webshells, les portes dérobées, les tâches cron et les comptes étrangers sont recherchés et supprimés. Détails dans Faire supprimer les logiciels malveillants et les webshells.
- Durcir et rendre compte : vous recevez un rapport destiné à la direction, à la protection des données et à l'assureur. Si vous le souhaitez, nous mettons en place avec vous la prévention, par exemple via un contrat de maintenance de sécurité.
Si l'incident dépasse un serveur web, nous passons à une réponse aux incidents structurée.
Ensuite : la prévention sans service de sécurité interne
Une fois l'incident clos, reste la question de savoir comment éviter le suivant ou, du moins, le détecter plus tôt. Pour les entreprises sans équipe de sécurité propre, quatre choses sont les plus importantes : un inventaire à jour de tous les sites web et serveurs, un interlocuteur clair pour les mises à jour, des sauvegardes vérifiées et un court plan d'urgence informatique.
Savoir si votre entreprise relève des obligations de NIS2 est une question juridique à laquelle nous ne répondons pas. Vous trouverez des informations générales sur notre page ; l'appréciation revient à l'avocat ou au délégué à la protection des données.
Ce que vous devriez nous envoyer
- une brève description de l'incident et du moment où il s'est produit
- une liste des sites web, boutiques et portails avec l'hébergeur et, si elle est connue, la version de PHP
- les noms de l'administrateur, de l'agence et de l'hébergeur qui connaissent le système
- des indications sur la liaison éventuelle du serveur web avec des systèmes internes
- des informations sur les sauvegardes et sur une éventuelle cyberassurance
Pourquoi PHP SOS
Nous travaillons Made in Germany et, avec notre réseau de partenaires de professionnels de la cybersécurité, nous sommes spécialisés depuis plus de 25 ans dans la sécurité informatique. Pour vous, cela signifie : un interlocuteur plutôt que beaucoup, un travail à distance sans déplacement partout en Allemagne et en Europe, et une documentation qui tient face aux clients, à l'assureur et aux autorités. Nous distinguons ouvertement ce qui est établi, probable et inconnu, et nous ne promettons rien que personne ne puisse tenir.
Vous êtes concerné ? Appelez-nous. Nous vous aidons.
Pour les premiers secours, vous n'avez pas besoin d'un service de sécurité interne, mais d'un interlocuteur qui commence. Nous prenons le relais dès le premier message et restons à vos côtés jusqu'à ce que l'incident soit clos et documenté. Signaler une urgence maintenant.
Questions fréquentes
Que faire en cas de cyberattaque sans service interne de sécurité informatique ?
Préserver les traces, ne rien supprimer, désigner un décideur et chercher une aide externe. Une entreprise de taille moyenne n'a pas à tout savoir faire elle-même. Nous prenons en charge le volet technique et travaillons avec votre administrateur, votre agence ou votre hébergeur.
Les petites et moyennes entreprises sont-elles vraiment des cibles ?
Oui. Les analyses automatisées recherchent des serveurs non corrigés sans tenir compte de la taille de l'entreprise. Pour PHP2Shell, Palo Alto Networks (Unit 42) a dénombré plus de 22,6 millions d'instances exposées et potentiellement vulnérables.
Notre activité doit-elle s'arrêter si le serveur web a été attaqué ?
Pas nécessairement. Il est souvent possible d'isoler le site et la boutique pendant que les systèmes internes continuent de fonctionner. Nous clarifions d'abord s'il existe des liaisons entre le serveur web et votre réseau interne.
NIS2 s'applique-t-elle à nous et qu'est-ce que cela signifie lors d'un incident ?
Que votre entreprise relève de NIS2 dépend du secteur et de la taille, et c'est une question juridique. Notre page sur NIS2 donne un aperçu ; l'appréciation de votre cas relève de l'avocat ou du délégué à la protection des données.
Comment nous préparer au prochain incident ?
Avec un inventaire des systèmes, un interlocuteur désigné, des sauvegardes vérifiées et un court plan d'urgence. Nous aidons à le mettre en place une fois l'incident aigu clos.