En bref : lorsqu'une attaque touche plus qu'un seul site web, vous avez besoin d'un prestataire de réponse aux incidents qui traite l'incident de façon structurée. Nous assurons la vue d'ensemble de la situation, le confinement, le nettoyage et le rétablissement sûr, avec des rôles clairs et une documentation sans faille. Vous gardez les décisions, nous assurons la base technique.
Ce que signifie la réponse aux incidents lors d'attaques de serveurs
La réponse aux incidents est le traitement ordonné d'un incident de sécurité. Au lieu d'actions isolées et précipitées, le travail suit des phases fixes : détecter et situer, contenir, éliminer, rétablir, faire le bilan. Chaque mesure est consignée avec l'heure et sa justification.
C'est particulièrement important pour les serveurs web. Un serveur avec des applications PHP contient souvent des identifiants pour des bases de données, des prestataires de paiement, des serveurs de messagerie et des interfaces. Quiconque y est entré peut se déplacer latéralement. La situation après PHP2Shell montre avec quelle rapidité une telle situation peut surgir : exécution de code sans authentification, plus de 22,6 millions d'instances exposées selon Unit 42 et aucun indicateur de compromission (IOC) publié et confirmé.
Quand vous avez besoin d'un prestataire de réponse aux incidents
- plusieurs serveurs ou applications sont concernés ou pourraient l'être
- on soupçonne que des données personnelles ou des données de paiement ont fuité
- un attaquant est peut-être encore actif, par exemple par des connexions en cours ou de nouveaux comptes
- il y a une extorsion ou une annonce publique de l'attaque
- l'assurance, les autorités ou des partenaires commerciaux attendent un déroulement documenté
Pour un seul site web infecté, l'aide d'urgence en cas de site web piraté suffit souvent. Nous discutons avec vous de la transition vers un traitement complet de l'incident dès qu'une ampleur plus grande se dessine.
Comment PHP SOS aide-t-il concrètement ?
- Triage et vue d'ensemble : nous clarifions ce qui a été observé, quels systèmes et quelles données peuvent être concernés et qui doit être impliqué en interne. Le résultat est une première vue d'ensemble écrite de la situation, avec les questions ouvertes.
- Sauvegarder les traces et contenir : les journaux, systèmes de fichiers et bases de données sont sauvegardés avant que nous n'intervenions. Nous isolons ensuite les systèmes concernés, bloquons les accès compromis et interrompons les connexions identifiables de l'attaquant.
- Éliminer : nous refermons la porte d'entrée, par exemple en appliquant les correctifs vers les versions corrigées de PHP et en redémarrant tous les workers, supprimons les portes dérobées et remplaçons les secrets. Pour l'analyse détaillée, nous faisons appel si nécessaire à des partenaires spécialisés en forensique informatique.
- Rétablir : les systèmes sont remis en service de façon contrôlée, si possible à partir de sources saines ou sur des serveurs réinstallés. Nous les surveillons ensuite plus étroitement pour détecter de nouvelles anomalies.
- Faire le bilan : vous recevez un rapport final avec chronologie, causes, mesures et recommandations. Ensemble, nous consignons ce qui doit aller plus vite la prochaine fois.
Conservez les journaux du serveur et ne modifiez aucun système avant que tout soit sauvegardé. Pour PHP2Shell, le BSI (l'office fédéral allemand de la sécurité des technologies de l'information) recommande de déconnecter temporairement du réseau les serveurs web qui ne peuvent pas être corrigés immédiatement.
Rôles et communication pendant l'incident
Un incident exige des responsabilités claires. Un petit cercle a fait ses preuves : une personne habilitée à décider, un interlocuteur technique de votre côté et nous-mêmes comme direction technique. Les points de situation ont lieu à intervalles fixes, les résultats sont consignés par écrit.
En parallèle se déroulent des tâches que nous ne prenons pas en charge, mais pour lesquelles nous fournissons des faits : l'examen d'une obligation de notification RGPD dans les 72 heures, l'information de l'assureur, une éventuelle plainte et la communication de crise envers les clients et les partenaires.
Ce dont nous avons besoin de votre part et ce que vous recevez
Nous avons besoin d'accès administratifs aux systèmes concernés, d'un aperçu de l'infrastructure et des prestataires, d'une personne habilitée à décider et de la disposition à mettre temporairement hors service des systèmes si nécessaire. Des plans d'urgence existants, des schémas de réseau et des sauvegardes datées sont utiles.
Vous recevez un journal d'incident continu, des points de situation réguliers dans un langage compréhensible, un rapport final pour la direction, les délégués à la protection des données et les assureurs, ainsi qu'une liste priorisée d'améliorations. Comment mieux vous préparer au prochain incident, Établir un plan d'urgence informatique pour serveurs web le décrit.
Erreurs typiques dans les premières heures
De nombreux incidents s'aggravent parce que, dans l'agitation, des mesures bien intentionnées sont prises dans le mauvais ordre. Nous voyons souvent ces schémas :
- Réinstaller aussitôt : le serveur est effacé et réinstallé avant d'avoir été sauvegardé. Ensuite, on ne peut plus établir si des données ont fuité.
- Changer les mots de passe depuis le système infecté : si l'attaquant a encore accès, il voit aussi les nouveaux mots de passe.
- Supprimer seulement le fichier visible : la webshell a disparu, la seconde porte dérobée dans la tâche cron reste.
- Corriger sans redémarrer : de nouveaux fichiers PHP sont sur le disque, les anciens workers continuent de tourner en mémoire.
- Personne ne tient de journal : plus tard, personne ne sait qui a modifié quoi et quand. Cela complique les échanges avec l'assureur et les autorités.
Un déroulement coordonné évite ces erreurs, sans retarder le confinement.
Ce que nous ne promettons pas
Nous ne promettons pas que chaque incident soit entièrement élucidé ; sans traces, des questions restent ouvertes, et nous l'écrivons ainsi dans le rapport. Nous ne donnons ni conseil juridique ni indication sur la responsabilité ou la couverture d'assurance. Notre objectif est une fin claire : nous travaillons sur l'incident jusqu'à ce qu'il soit clos et documenté.
Questions fréquentes
Quelle est la différence entre réponse aux incidents et forensique informatique ?
La réponse aux incidents a pour but de contenir l'incident et de rétablir l'exploitation en toute sécurité. La forensique informatique établit en détail et avec valeur probante ce qui s'est passé. En pratique, les deux s'imbriquent, la forensique sécurisant souvent des traces en parallèle.
Quand dois-je faire appel à un prestataire de réponse aux incidents ?
Dès qu'il y a lieu de soupçonner qu'un attaquant a eu accès à des systèmes et que vous ne pouvez pas estimer l'ampleur avec certitude. Plus la préservation des traces commence tôt, plus on pourra établir de choses par la suite.
Qui décide pendant l'incident ?
Les décisions sont les vôtres, par exemple sur les mises hors service, la communication ou les notifications. Nous préparons les bases techniques, montrons les options avec leurs conséquences et mettons en œuvre les décisions.
Dois-je faire appel à la police ?
Dans de nombreux cas, une plainte est judicieuse et importante pour certaines assurances. Les points de contact centraux pour la cybercriminalité (ZAC) de la police allemande en sont responsables. Vous décidez avec votre avocat si et quand déposer plainte.