Comment gérer un serveur compromis?
Ceci est une Question canonique sur la sécurité du serveur - Répondre aux événements de violation (piratage)
Voir également:
Version canonique
Je soupçonne qu'un ou plusieurs de mes serveurs sont compromis par un pirate, un virus ou un autre mécanisme:
- Quelles sont mes premières étapes? Lorsque j'arrive sur le site, dois-je déconnecter le serveur, conserver les "preuves", y a-t-il d'autres considérations initiales?
- Comment dois-je procéder pour remettre les services en ligne?
- Comment puis-je empêcher la même chose de se reproduire immédiatement?
- Existe-t-il des meilleures pratiques ou méthodologies pour tirer des enseignements de cet incident?
- Si je voulais élaborer un plan de réponse aux incidents, par où commencer? Cela devrait-il faire partie de ma planification de reprise après sinistre ou de continuité des activités?
Version originale
2011.01.02 - Je suis en route pour le travail à 21h30. un dimanche parce que notre serveur a été compromis d'une manière ou d'une autre et a entraîné une attaque DOS contre notre fournisseur. L'accès des serveurs à Internet a été fermé, ce qui signifie que plus de 5 à 600 de nos sites clients sont désormais fermés. Maintenant, cela pourrait être un piratage FTP ou une faiblesse du code quelque part. Je ne suis pas sûr jusqu'à ce que j'arrive.
Comment puis-je retrouver cela rapidement? Nous sommes confrontés à de nombreux litiges si je ne récupère pas le serveur dès que possible. Toute aide est appréciée. Nous exécutons Open SUSE 11.0.
2011.01.03 - Merci à tous pour votre aide. Heureusement, je n'étais pas la seule personne responsable de ce serveur, juste la plus proche. Nous avons réussi à résoudre ce problème, bien qu'il puisse ne pas s'appliquer à de nombreux autres dans une situation différente. Je vais détailler ce que nous avons fait.
Nous avons débranché le serveur du net. Il effectuait (tentait de réaliser) une attaque par déni de service sur un autre serveur en Indonésie, et le coupable y était également basé.
Nous avons d'abord essayé d'identifier d'où provenait le serveur, étant donné que nous avons plus de 500 sites sur le serveur, nous nous attendions à faire du clair de lune pendant un certain temps. Cependant, avec l'accès SSH toujours, nous avons exécuté une commande pour trouver tous les fichiers modifiés ou créés au moment où les attaques ont commencé. Heureusement, le fichier incriminé a été créé pendant les vacances d'hiver, ce qui signifie que peu d'autres fichiers ont été créés sur le serveur à l'époque.
Nous avons ensuite pu identifier le fichier incriminé qui se trouvait dans le dossier d'images téléchargées dans un site Web ZenCart .
Après une courte pause cigarette, nous avons conclu qu'en raison de l'emplacement des fichiers, ils devaient avoir été téléchargés via une installation de téléchargement de fichiers qui était mal sécurisée. Après quelques recherches sur Google, nous avons constaté qu'il y avait une vulnérabilité de sécurité qui permettait de télécharger des fichiers, dans le panneau d'administration ZenCart, pour une photo pour une maison de disques. (La section qu'il n'a jamais vraiment utilisée), publier ce formulaire vient de télécharger n'importe quel fichier, il n'a pas vérifié l'extension du fichier et n'a même pas vérifié si l'utilisateur était connecté.
Cela signifiait que tous les fichiers pouvaient être téléchargés, y compris un fichier PHP pour l'attaque. Nous avons sécurisé la vulnérabilité avec ZenCart sur le site infecté et supprimé les fichiers incriminés.
Le travail était fait et j'étais à la maison pendant 2 heures du matin.
The Moral - Toujours appliquer des correctifs de sécurité pour ZenCart, ou tout autre système CMS d'ailleurs. Comme lorsque les mises à jour de sécurité sont publiées, le monde entier est informé de la vulnérabilité. - Faites toujours des sauvegardes et sauvegardez vos sauvegardes. - Employer ou organiser quelqu'un qui sera là dans des moments comme ceux-ci. Pour empêcher quiconque de s'appuyer sur une publication paniquée sur Server Fault.
Il est difficile de donner des conseils spécifiques à partir de ce que vous avez publié ici, mais j'ai quelques conseils génériques basés sur un post que j'ai écrit il y a longtemps, alors que je pouvais encore être dérangé pour bloguer.
Ne paniquez pas
Tout d'abord, il n'y a pas de "solution rapide" autre que la restauration de votre système à partir d'une sauvegarde effectuée avant l'intrusion, et cela pose au moins deux problèmes.
- Il est difficile de déterminer quand l'intrusion s'est produite.
- Cela ne vous aide pas à fermer le "trou" qui leur a permis de s'introduire la dernière fois, ni à faire face aux conséquences de tout "vol de données" qui pourrait également avoir eu lieu.
Cette question continue d'être posée à plusieurs reprises par les victimes de pirates informatiques s'introduisant dans leur serveur Web. Les réponses changent très rarement, mais les gens continuent de poser la question. Je ne sais pas pourquoi. Peut-être que les gens n'aiment tout simplement pas les réponses qu'ils ont vues en cherchant de l'aide, ou ils ne peuvent pas trouver quelqu'un en qui ils ont confiance pour leur donner des conseils. Ou peut-être que les gens lisent une réponse à cette question et se concentrent trop sur les 5% des raisons pour lesquelles leur cas est spécial et différent des réponses qu'ils peuvent trouver en ligne et manquent les 95% de la question et de la réponse lorsque leur cas est assez proche de la même manière comme celui qu'ils lisent en ligne.
Cela m'amène à la première pépite d'informations importante. J'apprécie vraiment que vous soyez un flocon de neige unique et spécial. J'apprécie que votre site Web soit également un reflet de vous et de votre entreprise ou, à tout le moins, de votre travail acharné pour le compte d'un employeur. Mais pour quelqu'un à l'extérieur qui regarde, que ce soit un responsable de la sécurité informatique qui regarde le problème pour essayer de vous aider ou même l'attaquant lui-même, il est très probable que votre problème sera au moins à 95% identique à tous les autres cas qu'ils ont jamais regardé.
Ne prenez pas l'attaque personnellement, et ne prenez pas les recommandations qui suivent ici ou que vous obtenez personnellement d'autres personnes. Si vous lisez ceci après avoir été victime d'un piratage de site Web, je suis vraiment désolé et j'espère vraiment que vous pourrez trouver quelque chose d'utile ici, mais ce n'est pas le moment de laisser votre ego vous empêcher de faire ce dont vous avez besoin. faire.
Vous venez de découvrir que vos serveurs ont été piratés. Et maintenant?
Ne paniquez pas. N'agissez absolument pas à la hâte et n'essayez absolument pas de prétendre que les choses ne se sont jamais produites et de ne pas agir du tout.
Premièrement: comprenez que la catastrophe s'est déjà produite. Ce n'est pas le moment du déni; c'est le moment d'accepter ce qui s'est passé, d'être réaliste à ce sujet et de prendre des mesures pour gérer les conséquences de l'impact.
Certaines de ces étapes vont faire mal, et (à moins que votre site Web ne contienne une copie de mes coordonnées), je m'en fiche vraiment si vous ignorez tout ou partie de ces étapes, c'est à vous de décider. Mais les suivre correctement améliorera les choses à la fin. Le médicament peut avoir un goût horrible, mais vous devez parfois l'oublier si vous voulez vraiment que le remède fonctionne.
Empêchez le problème de devenir pire qu'il ne l'est déjà:
- La première chose à faire est de déconnecter les systèmes concernés d'Internet. Quels que soient les autres problèmes que vous rencontrez, laisser le système connecté au Web ne fera que poursuivre l'attaque. Je veux dire cela littéralement; demandez à quelqu'un de visiter physiquement le serveur et de débrancher les câbles réseau si c'est ce qu'il faut, mais déconnectez la victime de ses agresseurs avant d'essayer de faire autre chose.
- Modifiez tous vos mots de passe pour tous les comptes sur tous les ordinateurs qui sont sur le même réseau que les systèmes compromis. Pas vraiment. Tous les comptes. Tous les ordinateurs. Oui, vous avez raison, cela pourrait être exagéré; d'un autre côté, ce n'est peut-être pas le cas. Vous ne savez pas de toute façon, n'est-ce pas?
- Vérifiez vos autres systèmes. Portez une attention particulière aux autres services accessibles sur Internet et à ceux qui contiennent des données financières ou commerciales sensibles.
- Si le système contient les données personnelles de quiconque, informez immédiatement la personne responsable de la protection des données (si ce n'est pas vous) et demandez instamment une divulgation complète. Je sais que celui-ci est difficile. Je sais que celui-ci va faire mal. Je sais que de nombreuses entreprises veulent balayer ce genre de problème sous le tapis, mais l'entreprise va devoir y faire face - et doit le faire en tenant compte de toutes les lois pertinentes sur la vie privée.
Quelle que soit la gêne de vos clients de vous faire parler d'un problème, ils seront bien plus agacés si vous ne le leur dites pas, et ils ne le découvriront qu'après que quelqu'un aura facturé 8 000 $ de marchandises en utilisant les détails de leur carte de crédit volé sur votre site.
Rappelez-vous ce que j'ai dit précédemment? La mauvaise chose est déjà arrivée. La seule question qui se pose maintenant est de savoir comment vous y parvenez.
Comprendre parfaitement le problème:
- Ne remettez PAS les systèmes concernés en ligne avant que cette étape ne soit complètement terminée, à moins que vous ne vouliez être la personne dont le message a été le point de basculement pour moi décidant d'écrire cet article. Je ne vais pas créer de lien vers cet article pour que les gens puissent rire à bon marché, mais la vraie tragédie, c'est quand les gens n'apprennent pas de leurs erreurs.
- Examinez les systèmes "attaqués" pour comprendre comment les attaques ont réussi à compromettre votre sécurité. Faites tout votre possible pour savoir d'où viennent les attaques, afin de comprendre les problèmes que vous avez et que vous devez résoudre pour assurer la sécurité de votre système à l'avenir.
- Examinez à nouveau les systèmes "attaqués", cette fois pour comprendre où les attaques se sont déroulées, afin de comprendre quels systèmes ont été compromis lors de l'attaque. Assurez-vous de suivre tout pointeur suggérant que des systèmes compromis pourraient devenir un tremplin pour attaquer davantage vos systèmes.
- Assurez-vous que les "passerelles" utilisées dans toutes les attaques sont bien comprises, afin que vous puissiez commencer à les fermer correctement. (par exemple, si vos systèmes ont été compromis par une attaque par injection SQL, alors non seulement vous devez fermer la ligne de code défectueuse particulière par laquelle ils se sont cassés, mais vous devriez auditer tout votre code pour voir si le même type d'erreur a été faite ailleurs).
- Comprenez que les attaques peuvent réussir en raison de plusieurs failles. Souvent, les attaques réussissent non pas en trouvant un bogue majeur dans un système mais en enchaînant plusieurs problèmes (parfois mineurs et triviaux par eux-mêmes) pour compromettre un système. Par exemple, utiliser des attaques par injection SQL pour envoyer des commandes à un serveur de base de données, découvrir le site Web/l'application que vous attaquez s'exécute dans le contexte d'un utilisateur administratif et utiliser les droits de ce compte comme tremplin pour compromettre d'autres parties de un système. Ou comme les pirates aiment l'appeler: "un autre jour au bureau en profitant des erreurs courantes que les gens font".
Pourquoi ne pas simplement "réparer" l'exploit ou le rootkit que vous avez détecté et remettre le système en ligne?
Dans de telles situations, le problème est que vous n'avez plus le contrôle de ce système. Ce n'est plus votre ordinateur.
La seule façon d'être certain que vous avez le contrôle du système est de reconstruire le système. Bien qu'il soit très utile de trouver et de réparer l'exploit utilisé pour pénétrer dans le système, vous ne pouvez pas être sûr de ce qui a été fait d'autre dans le système une fois que les intrus ont pris le contrôle (en effet, ce n'est pas inconnu pour les pirates qui recrutent systèmes dans un botnet pour patcher les exploits qu'ils ont eux-mêmes utilisés, pour protéger "leur" nouvel ordinateur des autres pirates, ainsi que pour installer leur rootkit).
Faites un plan de récupération et remettez votre site Web en ligne et respectez-le:
Personne ne veut être déconnecté plus longtemps que nécessaire. C'est une évidence. Si ce site Web est un mécanisme générateur de revenus, la pression pour le réactiver rapidement sera intense. Même si la seule chose en jeu est la réputation de votre/votre entreprise, cela va encore générer beaucoup de pression pour remettre les choses en place rapidement.
Cependant, ne cédez pas à la tentation de revenir en ligne trop rapidement. Au lieu de cela, avancez le plus rapidement possible pour comprendre ce qui a causé le problème et le résoudre avant de vous reconnecter, sinon vous serez certainement à nouveau victime d'une intrusion, et rappelez-vous, "se faire pirater une fois peut être considéré comme un malheur; se faire pirater à nouveau tout de suite après ressemble à de la négligence "(avec des excuses à Oscar Wilde).
- Je suppose que vous avez compris tous les problèmes qui ont conduit à l'intrusion réussie en premier lieu avant même de commencer cette section. Je ne veux pas exagérer l'affaire, mais si vous ne l'avez pas fait en premier, vous en avez vraiment besoin. Désolé.
- Ne payez jamais d'argent de chantage/protection. C'est le signe d'une marque facile et vous ne voulez pas que cette expression soit utilisée pour vous décrire.
- Ne soyez pas tenté de remettre les mêmes serveurs en ligne sans une reconstruction complète. Il devrait être beaucoup plus rapide de construire une nouvelle boîte ou de "neutraliser le serveur depuis l'orbite et de faire une installation propre" sur l'ancien matériel qu'il ne le serait de vérifier chaque coin de l'ancien système pour s'assurer qu'il est propre avant de le remettre en place. en ligne à nouveau. Si vous n'êtes pas d'accord avec cela, vous ne savez probablement pas ce que cela signifie vraiment de garantir un nettoyage complet du système, ou les procédures de déploiement de votre site Web sont un gâchis impie. Vous disposez probablement de sauvegardes et de tests de déploiement de votre site que vous pouvez simplement utiliser pour créer le site en direct, et si vous ne le faites pas, le piratage n'est pas votre plus gros problème.
- Soyez très prudent lorsque vous réutilisez des données qui étaient "en direct" sur le système au moment du piratage. Je ne dirai pas "ne jamais le faire" parce que vous m'ignorerez, mais franchement, je pense que vous devez considérer les conséquences de la conservation des données lorsque vous savez que vous ne pouvez pas garantir leur intégrité. Idéalement, vous devez restaurer cela à partir d'une sauvegarde effectuée avant l'intrusion. Si vous ne pouvez pas ou ne voulez pas le faire, vous devez être très prudent avec ces données car elles sont entachées. Vous devez surtout être conscient des conséquences pour autrui si ces données appartiennent aux clients ou aux visiteurs du site plutôt qu'à vous directement.
- Surveillez attentivement le ou les systèmes. Vous devez vous résoudre à le faire en tant que processus continu à l'avenir (plus ci-dessous), mais vous vous efforcez d'être vigilant pendant la période suivant immédiatement la remise en ligne de votre site. Les intrus seront certainement de retour, et si vous pouvez les repérer en train de s'introduire de nouveau, vous pourrez certainement voir rapidement si vous avez vraiment fermé tous les trous qu'ils ont utilisés auparavant et tous ceux qu'ils ont faits pour eux-mêmes, et vous pourriez rassembler des informations utiles informations que vous pouvez transmettre à votre application de la loi locale.
Réduire le risque à l'avenir.
La première chose que vous devez comprendre est que la sécurité est un processus que vous devez appliquer tout au long du cycle de vie de la conception, du déploiement et de la maintenance d'un système accessible sur Internet, pas quelque chose que vous pouvez ensuite gifler quelques couches sur votre code comme bon marché Peindre. Pour être correctement sécurisé, un service et une application doivent être conçus dès le départ en gardant cela à l'esprit comme l'un des principaux objectifs du projet. Je me rends compte que c'est ennuyeux et que vous avez déjà entendu tout cela auparavant et que "je ne me rends pas compte de la pression exercée par l'homme" pour que votre service beta web2.0 (beta) devienne bêta sur le web, mais le fait est que cela continue se répéter parce que c'était vrai la première fois qu'on l'a dit et que ce n'est pas encore devenu un mensonge.
Vous ne pouvez pas éliminer le risque. Vous ne devriez même pas essayer de faire ça. Ce que vous devez cependant faire est de comprendre quels risques de sécurité sont importants pour vous, et de comprendre comment gérer et réduire à la fois l'impact du risque et la probabilité que le risque se produise.
Quelles mesures pouvez-vous prendre pour réduire la probabilité de réussite d'une attaque?
Par exemple:
- La faille qui permettait aux utilisateurs de pénétrer dans votre site était-elle un bogue connu dans le code du fournisseur, pour lequel un correctif était disponible? Dans l'affirmative, devez-vous repenser votre approche de la façon dont vous corrigez les applications sur vos serveurs Internet?
- La faille qui permettait aux utilisateurs de pénétrer dans votre site était-elle un bogue inconnu dans le code du fournisseur, pour lequel un correctif n'était pas disponible? Je ne préconise certainement pas de changer de fournisseur chaque fois que quelque chose comme ça vous mord parce qu'ils ont tous leurs problèmes et que vous manquerez de plateformes dans un an au maximum si vous adoptez cette approche. Cependant, si un système vous laisse constamment tomber, vous devez soit migrer vers quelque chose de plus robuste ou, à tout le moins, réorganiser votre système afin que les composants vulnérables restent enveloppés dans du coton et aussi loin que possible des yeux hostiles.
- La faille était-elle un bug dans le code développé par vous (ou un entrepreneur travaillant pour vous)? Dans l'affirmative, devez-vous repenser votre approche de la façon dont vous approuvez le code pour le déploiement sur votre site en ligne? Le bogue aurait-il pu être détecté avec un système de test amélioré ou avec des modifications de votre "standard" de codage (par exemple, bien que la technologie ne soit pas une panacée, vous pouvez réduire la probabilité d'une attaque par injection SQL réussie en utilisant des techniques de codage bien documentées ).
- La faille était-elle due à un problème de déploiement du serveur ou du logiciel d'application? Si oui, utilisez-vous des procédures automatisées pour créer et déployer des serveurs dans la mesure du possible? Ceux-ci sont d'une grande aide pour maintenir un état "de base" cohérent sur tous vos serveurs, minimisant la quantité de travail personnalisé qui doit être effectué sur chacun et donc, espérons-le, minimisant la possibilité d'une erreur. Il en va de même pour le déploiement de code - si vous avez besoin de quelque chose de "spécial" pour déployer la dernière version de votre application Web, essayez de l'automatiser et assurez-vous qu'elle est toujours effectuée de manière cohérente.
- L'intrusion aurait-elle pu être détectée plus tôt grâce à une meilleure surveillance de vos systèmes? Bien sûr, une surveillance 24h/24 ou un système "sur appel" pour votre personnel peut ne pas être rentable, mais il existe des entreprises qui peuvent surveiller vos services Web pour vous et vous alerter en cas de problème. Vous pourriez décider que vous ne pouvez pas vous le permettre ou que vous n'en avez pas besoin et c'est très bien ... il suffit de le prendre en considération.
- Utilisez des outils tels que tripwire et nessus lorsque cela est approprié - mais ne les utilisez pas simplement à l'aveugle parce que je l'ai dit. Prenez le temps d'apprendre à utiliser quelques bons outils de sécurité adaptés à votre environnement, gardez ces outils à jour et utilisez-les régulièrement.
- Envisagez d'embaucher des experts en sécurité pour "auditer" régulièrement la sécurité de votre site Web. Encore une fois, vous pourriez décider que vous ne pouvez pas vous le permettre ou que vous n'en avez pas besoin et c'est très bien ... il suffit de le prendre en considération.
Quelles mesures pouvez-vous prendre pour réduire les conséquences d'une attaque réussie?
Si vous décidez que le "risque" d'inondation de l'étage inférieur de votre maison est élevé, mais pas suffisamment élevé pour justifier un déménagement, vous devez au moins déplacer les héritages irremplaçables de la famille à l'étage. Droite?
- Pouvez-vous réduire la quantité de services directement exposés à Internet? Pouvez-vous maintenir une sorte d'écart entre vos services internes et vos services accessibles sur Internet? Cela garantit que même si vos systèmes externes sont compromis, les chances de l'utiliser comme tremplin pour attaquer vos systèmes internes sont limitées.
- Stockez-vous des informations que vous n'avez pas besoin de stocker? Stockez-vous ces informations "en ligne" alors qu'elles pourraient être archivées ailleurs. Il y a deux points à cette partie; la plus évidente est que les gens ne peuvent pas vous voler des informations que vous ne possédez pas, et le deuxième point est que moins vous stockez, moins vous avez besoin de maintenir et de coder, et donc il y a moins de chances pour que les bogues se glissent dans la conception de votre code ou de vos systèmes.
- Utilisez-vous les principes du "moindre accès" pour votre application Web? Si les utilisateurs ont uniquement besoin de lire à partir d'une base de données, assurez-vous que le compte que l'application Web utilise pour le service n'a qu'un accès en lecture, ne lui permettez pas un accès en écriture et certainement pas un accès au niveau du système.
- Si vous n'êtes pas très expérimenté dans quelque chose et qu'il n'est pas au cœur de votre entreprise, envisagez de l'externaliser. En d'autres termes, si vous exécutez un petit site Web qui parle d'écrire du code d'application de bureau et décidez de commencer à vendre de petites applications de bureau à partir du site, envisagez d'externaliser votre système de commande de cartes de crédit à quelqu'un comme Paypal.
- Dans la mesure du possible, intégrez la pratique de la récupération à partir de systèmes compromis à votre plan de reprise après sinistre. C'est sans doute juste un autre "scénario de catastrophe" que vous pourriez rencontrer, simplement un avec son propre ensemble de problèmes et de problèmes qui sont distincts de l'habituel "la salle des serveurs a pris feu"/"a été envahie par le genre de chose du serveur géant qui mange des furbies".
... Et enfin
Je n'ai probablement laissé aucune fin à des choses que d'autres considèrent importantes, mais les étapes ci-dessus devraient au moins vous aider à trier les choses si vous n'avez pas la chance de devenir victime de pirates informatiques.
Surtout: ne paniquez pas. Pense avant d'agir. Agissez fermement une fois que vous avez pris une décision et laissez un commentaire ci-dessous si vous avez quelque chose à ajouter à ma liste d'étapes.
On dirait que vous êtes légèrement au-dessus de votre tête; c'est bon. Appelez votre patron et commencez à négocier un budget d'intervention d'urgence. 10 000 $ pourraient être un bon point de départ. Ensuite, vous devez demander à quelqu'un (un PFY, un collègue, un gestionnaire) de commencer à appeler des entreprises spécialisées dans la réponse aux incidents de sécurité. Beaucoup peuvent répondre dans les 24 heures, et parfois même plus rapidement s'ils ont un bureau dans votre ville.
Vous avez également besoin de quelqu'un pour trier les clients; Sans doute, quelqu'un l'est déjà. Quelqu'un doit être au téléphone avec eux pour expliquer ce qui se passe, ce qui est fait pour gérer la situation et répondre à leurs questions.
Ensuite, vous devez ...
Reste calme. Si vous êtes en charge de la réponse aux incidents, ce que vous faites maintenant doit faire preuve du plus grand professionnalisme et leadership. Documentez tout ce que vous faites et tenez votre gestionnaire et votre équipe de direction informés des principales mesures que vous prenez; cela comprend le travail avec une équipe d'intervention, la désactivation des serveurs, la sauvegarde des données et la remise en ligne des éléments. Ils n'ont pas besoin de détails sanglants, mais ils devraient vous entendre toutes les 30 minutes environ.
Être réaliste. Vous n'êtes pas un professionnel de la sécurité et il y a des choses que vous ne savez pas. C'est bon. Lors de la connexion aux serveurs et de la consultation des données, vous devez comprendre vos limites. Marchez doucement. Au cours de votre enquête, assurez-vous de ne pas piétiner des informations vitales ou de modifier quelque chose qui pourrait être nécessaire plus tard. Si vous vous sentez mal à l'aise ou que vous devinez, c'est un bon endroit pour s'arrêter et demander à un professionnel expérimenté de prendre le relais.
Obtenez une clé USB propre et des disques durs de rechange. Vous collecterez des preuves ici. Faites des sauvegardes de tout ce qui vous semble pertinent; communication avec votre FAI, décharges réseau, etc. Même si les forces de l'ordre ne s'impliquent pas, en cas de poursuite, vous voudrez que ces preuves prouvent que votre entreprise a géré l'incident de sécurité de manière professionnelle et appropriée.
Le plus important est d'arrêter la perte. Identifiez et coupez l'accès aux services, données et machines compromis. De préférence, vous devez tirer leur câble réseau; si vous ne le pouvez pas, coupez le courant.
Ensuite, vous devez retirer l'attaquant et fermer le (s) trou (s). Vraisemblablement, l'attaquant n'a plus d'accès interactif car vous avez tiré le réseau. Vous devez maintenant identifier, documenter (avec des sauvegardes, des captures d'écran et vos propres notes d'observation personnelles; ou de préférence même en supprimant les lecteurs des serveurs affectés et en faisant une copie complète de l'image disque), puis supprimez tout code et processus qu'il a laissé derrière . Cette prochaine partie sera nulle si vous n'avez pas de sauvegardes; Vous pouvez essayer de démêler l'attaquant du système à la main, mais vous ne serez jamais sûr d'avoir tout ce qu'il a laissé. Les rootkits sont vicieux et tous ne sont pas détectables. La meilleure réponse sera d'identifier la vulnérabilité qu'il a utilisée pour entrer, de faire des copies d'images des disques affectés, puis d'effacer les systèmes affectés et de recharger à partir d'une bonne sauvegarde connue. Ne faites pas aveuglément confiance à votre sauvegarde; vérifie ça! Réparez ou fermez la vulnérabilité avant que le nouvel hôte ne se connecte à nouveau au réseau, puis mettez-le en ligne.
Organisez toutes vos données dans un rapport. À ce stade, la vulnérabilité est fermée et vous avez le temps de respirer. Ne soyez pas tenté de sauter cette étape; c'est encore plus important que le reste du processus. Dans le rapport, vous devez identifier ce qui n'a pas fonctionné, comment votre équipe a réagi et les mesures que vous prenez pour éviter que cet incident ne se reproduise. Soyez aussi détaillé que possible; ce n'est pas seulement pour vous, mais pour votre gestion et comme défense dans un éventuel procès.
C'est un examen exorbitant de ce qu'il faut faire; la plupart du travail consiste simplement en la documentation et la gestion des sauvegardes. Ne paniquez pas, vous pouvez faire ce genre de choses. Je fortement vous recommande d'obtenir une aide professionnelle en matière de sécurité. Même si vous pouvez gérer ce qui se passe, leur aide sera inestimable et ils viennent généralement avec du matériel pour rendre le processus plus facile et plus rapide. Si votre patron rechigne au prix, rappelez-lui que c'est très petit par rapport à la gestion d'un procès.
Vous avez mes consolations pour votre situation. Bonne chance.
Le CERT a un document Étapes de récupération à partir d'un compromis système UNIX ou NT qui est bon. Les détails techniques spécifiques de ce document sont quelque peu dépassés, mais une grande partie des conseils généraux s'appliquent toujours directement.
Voici un bref résumé des étapes de base.
- Consultez votre politique ou gestion de sécurité.
- Prenez le contrôle (mettez l'ordinateur hors ligne)
- Analyser l'intrusion, obtenir des journaux, comprendre ce qui n'a pas fonctionné
- Réparer des trucs
- Installez une version propre de votre système d'exploitation !!! Si le système a été compromis, vous ne pouvez pas lui faire confiance, point final.
- Mettre à jour les systèmes pour que cela ne se reproduise plus
- Reprendre les opérations
- Mettez à jour votre politique pour l'avenir et documentez
Je voudrais vous signaler spécifiquement la section E.1.
E.1. N'oubliez pas que si une machine est compromise, tout élément de ce système aurait pu être modifié, y compris le noyau, les fichiers binaires, les fichiers de données, les processus en cours d'exécution et la mémoire. En général, la seule façon de garantir qu'une machine est exempte de portes dérobées et de modifications d'intrus est de réinstaller le
Si vous n'avez pas de système déjà en place comme tripwire, il n'y a aucun moyen pour vous d'être sûr à 100% que vous avez nettoyé le système.
- Identifiez le problème. Lisez les journaux.
- Contient . Vous avez déconnecté le serveur, c'est fait.
- Éradiquer . Réinstallez le système affecté, très probablement. N'effacez pas le disque dur du piraté, utilisez-en un nouveau. C'est plus sûr, et vous pourriez avoir besoin de l'ancien pour récupérer de vilains hacks qui n'ont pas été sauvegardés, et pour faire de la médecine légale pour découvrir ce qui s'est passé.
- Récupérez . Installez tout ce dont vous avez besoin et récupérez les sauvegardes pour mettre vos clients en ligne.
- Suivi . Déterminez quel était le problème et évitez qu'il ne se reproduise.
La réponse de "pilule amère" de Robert est précise mais complètement générique (enfin, comme ce fut votre question). Il semble que vous ayez un problème de gestion et que vous ayez un besoin urgent d'un administrateur système à temps plein si vous avez un serveur et 600 clients, mais cela ne vous aide pas maintenant.
Je dirige une société d'hébergement qui offre un peu de prise en main dans cette situation, je traite donc beaucoup de machines compromises, mais aussi les meilleures pratiques pour la nôtre. Nous demandons toujours à nos clients compromis de reconstruire à moins qu'ils ne soient pas absolument sûrs de la nature d'un compromis. Il n'y a pas d'autre voie responsable à long terme.
Cependant, vous êtes presque certainement la victime d'un script kiddy qui voulait une rampe de lancement pour les attaques DoS, ou IRC bouncers, ou quelque chose de complètement indépendant des sites et des données de vos clients. Par conséquent, en tant que mesure temporaire pendant la reconstruction, vous pourriez envisager de mettre en place un pare-feu sortant lourd sur votre boîte. Si vous pouvez bloquer toutes les connexions UDP sortantes et TCP qui ne sont pas absolument nécessaires au fonctionnement de vos sites) , vous pouvez facilement rendre votre boîtier compromis inutile à quiconque vous l'emprunte et atténuer l'effet sur le réseau de votre fournisseur à zéro.
Ce processus peut prendre quelques heures si vous ne l'avez pas encore fait et n'a jamais envisagé de pare-feu, mais peut vous aider à restaurer le service de vos clients au risque de continuer à donner à l'attaquant un accès aux données de vos clients . Puisque vous dites que vous avez des centaines de clients sur une seule machine, je suppose que vous hébergez de petits sites Web de brochures pour les petites entreprises, et non 600 systèmes de commerce électronique remplis de numéros de cartes de crédit. Si tel est le cas, cela peut être un risque acceptable pour vous et remettre votre système en ligne plus rapidement que l'audit de 600 sites pour les bogues de sécurité avant de rapporter quoi que ce soit . Mais vous saurez quelles données sont disponibles et à quel point vous seriez à l'aise de prendre cette décision.
Ce n'est absolument pas la meilleure pratique, mais si ce n'est pas ce qui s'est passé chez votre employeur jusqu'à présent, agitez le doigt vers lui et demandez des dizaines de milliers de livres pour une équipe SWAT pour quelque chose qu'il pourrait estimer être de votre faute (même si cela n'est pas justifié! ) ne ressemble pas à l'option pratique.
L'aide de votre FAI ici sera assez cruciale - certains FAI fournissent un serveur de console et un environnement d'initialisation résea (branchez, mais au moins vous savez quel type d'installation rechercher) qui vous permettra d'administrer le serveur lorsqu'il est déconnecté du réseau. Si c'est une option, demandez-la et utilisez-la.
Mais à long terme, vous devez planifier une reconstruction du système sur la base du message de Robert et un audit de chaque site et de sa configuration. Si vous ne pouvez pas ajouter un administrateur système à votre équipe, recherchez un accord hébergement géré où vous payez votre FAI pour l'aide à l'administration système et une réponse dans les 24 heures pour ce genre de chose. Bonne chance :)
Vous devez réinstaller. Enregistrez ce dont vous avez vraiment besoin. Mais gardez à l'esprit que tous vos fichiers exécutables peuvent être infectés et falsifiés. J'ai écrit ce qui suit en python: http://frw.se/monty.py qui crée MD5-sumbs de tous vos fichiers dans un répertoire donné et la prochaine fois que vous l'exécutez, il vérifie si quelque chose a été modifié, puis affichez quels fichiers ont changé et ce qui a changé dans les fichiers.
Cela pourrait être pratique pour vous, pour voir si des fichiers étranges sont modifiés régulièrement.
Mais la seule chose que vous devriez faire maintenant, c'est de supprimer votre ordinateur d'Internet.
REMARQUE: Ce n'est pas une recommandation. Mon protocole spécifique de réponse aux incidents ne serait probablement pas ne s'applique pas sans modification au cas de Grant unwin.
Dans nos installations universitaires, nous avons environ 300 chercheurs qui ne font que du calcul. Vous avez 600 clients avec des sites Web, donc votre protocole sera probablement différent.
Les premières étapes de notre Lorsqu'un serveur obtient un protocole compromis est:
- Identifier que l'attaquant a réussi à obtenir un root (privilèges élevés)
- Débranchez les serveurs concernés. Réseau ou alimentation? Veuillez voir ne discussion séparée .
- Vérifiez tous les autres systèmes
- Démarrez le ou les serveurs concernés à partir d'un CD live
- (facultatif) Prenez les images de tous les lecteurs système avec
dd Commencez à faire de la criminalistique post mortem. Regardez les journaux, déterminez l'heure de l'attaque, trouvez les fichiers qui ont été modifiés à cette heure. Essayez de répondre à la question Comment? .
- En parallèle, planifiez et exécutez votre récupération.
- Réinitialisez tous les mots de passe root et utilisateur avant de reprendre le service
Même si "tous les backdoors et rootkits sont nettoyés", ne faites pas confiance à ce système - réinstallez-le à partir de zéro.
Je dirais que @Robert Moir, @Aleksandr Levchuk, @blueben et @Matthew Bloch sont tous assez précis dans leurs réponses.
Cependant, les réponses des différentes affiches diffèrent - certaines sont plutôt de haut niveau et parlent des procédures à mettre en place (en général).
Je préfère séparer cela en plusieurs parties distinctes 1) Triage, AKA Comment traiter avec les clients et les implications juridiques, et identifier où aller à partir de là (très bien répertorié par Robert et @blueben 2) Atténuation de l'impact 3 ) Réponse aux incidents 4) Médecine légale post-mortem 5) Éléments de correction et changements d'architecture
(Insérez ici la déclaration de réponse certifiée SANS GSC passe-partout.) Sur la base des expériences passées, je dirais ce qui suit:
Quelle que soit la façon dont vous gérez les réponses des clients, les notifications, les plans juridiques et futurs, je préfère me concentrer sur le problème principal à résoudre. La question initiale de l'OP ne concerne vraiment que les points 2 et 3, essentiellement, comment arrêter l'attaque, remettre les clients en ligne dès que possible dans leur état d'origine, qui a été bien couvert dans les réponses.
Les autres réponses sont excellentes et couvrent un grand nombre de meilleures pratiques identifiées et de moyens pour à la fois empêcher que cela se produise à l'avenir et mieux y répondre.
Cela dépend vraiment du budget du PO et du secteur dans lequel il se trouve, de la solution souhaitée, etc.
Peut-être qu'ils ont besoin d'embaucher une SA dédiée sur site. Ils ont peut-être besoin d'une personne chargée de la sécurité. Ou peut-être ont-ils besoin d'une solution entièrement gérée comme Firehost ou Rackspace Managed, Softlayer, ServePath, etc.
Cela dépend vraiment de ce qui fonctionne pour leur entreprise. Peut-être que leur compétence principale n'est pas la gestion de serveurs et cela n'a aucun sens pour eux d'essayer de développer cela. Ou, peut-être qu'ils sont déjà une organisation assez technique et peuvent prendre les bonnes décisions d'embauche et faire appel à une équipe dédiée à temps plein.
D'après mon expérience limitée, les compromis système sous Linux ont tendance à être plus "complets" qu'ils ne le sont sous Windows. Les kits racine sont beaucoup plus susceptibles d'inclure le remplacement des fichiers binaires du système par du code personnalisé pour masquer les logiciels malveillants, et la barrière aux correctifs à chaud du noyau est un peu plus faible. De plus, c'est le système d'exploitation domestique pour de nombreux auteurs de logiciels malveillants. Le conseil général est toujours de reconstruire le serveur affecté à partir de zéro, et c'est le conseil général pour une raison.
Formatez ce chiot.
Mais, si vous ne pouvez pas reconstruire (ou si les pouvoirs ne vous permettent pas de le reconstruire contre votre insistance acharnée qu'il en a besoin), que recherchez-vous?
Comme il semble que cela fait un moment que l'intrusion n'a pas été découverte et qu'une restauration du système a été effectuée, il est très probable que les traces de la façon dont ils sont entrés ont été piétinées dans la bousculade pour restaurer le service. Malheureux.
Le trafic réseau inhabituel est probablement le plus facile à trouver, car cela n'implique pas d'exécuter quoi que ce soit sur la boîte et peut être fait pendant que le serveur est en marche et fait quoi que ce soit. En supposant, bien sûr, que votre équipement de mise en réseau permette le transfert de ports. Ce que vous trouvez peut ou non être un diagnostic, mais au moins ce sont des informations. L'obtention d'un trafic inhabituel sera une preuve solide que le système est toujours compromis et doit être aplati. Il pourrait être suffisant de convaincre TPTB qu'un reformatage vaut vraiment, vraiment, le temps d'arrêt.
A défaut, prenez une copie jj de vos partitions système et montez-les sur une autre box. Commencez à comparer le contenu avec un serveur au même niveau de correctif que celui compromis. Cela devrait vous aider à identifier ce qui semble différent (ces sommes md5 à nouveau) et peut pointer vers des zones négligées sur le serveur compromis. C'est BEAUCOUP de passer au crible les répertoires et les fichiers binaires, et sera plutôt laborieux. Il peut même être plus exigeant en main-d'œuvre qu'un reformatage/reconstruction ne le serait, et peut être une autre chose pour convaincre TPTB de réellement faire le reformatage dont il a vraiment besoin.
Après être arrivé au travail et avoir regardé le serveur, nous avons réussi à comprendre le problème. Heureusement, les fichiers incriminés ont été téléchargés sur le système un dimanche, lorsque le bureau est fermé et aucun fichier ne doit être créé, à l'exception des journaux et des fichiers de cache. Avec une simple commande Shell pour savoir quels fichiers ont été créés ce jour-là, nous les avons trouvés.
Tous les fichiers incriminés semblent se trouver dans le dossier/images/de certains de nos anciens sites zencart. Il semble qu'il y avait une vulnérabilité de sécurité qui permettait (en utilisant curl) à n'importe quel idiot de télécharger des non-images dans la section de téléchargement d'images de la section admin. Nous avons supprimé les fichiers .php incriminés et corrigé les scripts de téléchargement pour interdire tout téléchargement de fichiers qui ne sont pas des images.
Rétrospectivement, c'était assez simple et j'ai posé cette question sur mon iPhone en route vers le travail. Merci pour votre aide.
Pour la référence de toute personne qui visite ce poste à l'avenir. Je pas recommande de retirer la fiche d'alimentation.
Je pense que tout se résume à ceci:
Si vous appréciez votre travail, vous feriez mieux d'avoir un plan et de le réviser régulièrement.
Ne pas planifier, c'est planifier l'échec, et ce n'est pas plus vrai ailleurs que dans la sécurité des systèmes. Lorsque <réputé> frappe le ventilateur, vous feriez mieux d'être prêt à y faire face.
Il y a un autre dicton (quelque peu cliché) qui s'applique ici: Mieux vaut prévenir que guérir .
Il y a eu un certain nombre de recommandations ici pour faire appel à des experts pour auditer vos systèmes existants. Je pense que cela pose la question au mauvais moment. Cette question aurait dû être posée lors de la mise en place du système et les réponses documentées. En outre, la question ne devrait pas être "Comment pouvons-nous empêcher les gens de s'introduire?" Cela devrait être "Pourquoi les gens devraient-ils pouvoir s'introduire?" L'audit d'un groupe de trous dans votre réseau ne fonctionnera que jusqu'à ce que de nouveaux trous soient trouvés et exploités. D'un autre côté, les réseaux qui sont conçus à partir de zéro pour ne répondre que de certaines manières à certains systèmes dans une danse soigneusement chorégraphiée ne bénéficieront pas du tout d'un audit et les fonds seront un gaspillage.
Avant de mettre un système sur Internet, posez-vous la question: faut-il que celui-ci soit accessible à 100% sur Internet? Sinon, non. Pensez à le placer derrière un pare-feu où vous pouvez décider de ce que voit Internet. Encore mieux, si ledit pare-feu vous permet d'intercepter les transmissions (via un proxy inverse ou un filtre pass-through d'une certaine sorte), envisagez de l'utiliser pour ne permettre que des actions légitimes.
Cela a été fait - il y a (ou il y avait) une configuration de banque en ligne quelque part qui a un proxy d'équilibrage de charge face à Internet qu'ils allaient utiliser pour repousser les attaques de leur pool de serveurs. L'expert en sécurité Marcus Ranum les a convaincus d'adopter l'approche inverse, en en utilisant le proxy inverse pour autoriser uniquement les URL valides connues et envoyer tout le reste à un serveur 404 . Cela a étonnamment bien résisté à l'épreuve du temps.
Un système ou un réseau basé sur un permis par défaut est voué à l'échec dès qu'une attaque que vous ne prévoyiez pas se produit. Le refus par défaut vous donne beaucoup plus de contrôle sur ce qui entre et ce qui ne l'est pas, car vous ne laisserez rien de l'intérieur être vu de l'extérieur à moins qu'il ne soit bien besoin d'être .
Cela dit, tout cela n'est pas une raison de faire preuve de complaisance. Vous devriez toujours avoir un plan en place pour les premières heures après une violation. Aucun système n'est parfait et les humains font des erreurs.
Un Nice onliner m'a aidé récemment à découvrir comment un attaquant pouvait compromettre un système. Certains crackers tentent de masquer leurs traces en forgeant le temps de modification sur les fichiers. En modifiant l'heure de modification, l'heure de modification est mise à jour (ctime). vous pouvez voir le ctime avec stat.
Ce dossier répertorie tous les fichiers triés par ctime:
find / -type f -print0 | xargs -0 stat --format '%Z :%z %n' | sort -nr > /root/all_files.txt
Donc, si vous connaissez approximativement l'heure du compromis, vous pouvez voir quels fichiers sont modifiés ou créés.