Question Comment puis-je traiter avec un serveur compromis?


C'est un Question canonique à propos de Server Security - Réponse 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 informatique, un virus ou un autre mécanisme:

  • Quels sont mes premiers pas? Lorsque j'arrive sur le site, dois-je déconnecter le serveur, préserver les "preuves"? Existe-t-il d'autres considérations initiales?
  • Comment puis-je obtenir des services en ligne?
  • Comment puis-je empêcher la même chose de se produire immédiatement à nouveau?
  • Existe-t-il des meilleures pratiques ou méthodologies pour apprendre de cet incident?
  • Si je voulais élaborer un plan de réponse aux incidents, par quoi commencerais-je? Est-ce que cela devrait faire partie de mon plan de reprise après sinistre ou de continuité de l'activité?

Version originale 

2011.01.02 - Je suis sur le chemin du travail à 21h30 un dimanche parce que notre serveur a été compromis en quelque sorte et a abouti à un    DOS attaque sur notre fournisseur. Les serveurs accèdent à Internet   a été arrêté, ce qui signifie que plus de 5 à 600 de nos sites clients sont maintenant   vers le bas. Maintenant, cela pourrait être un piratage FTP, ou une faiblesse dans le code   quelque part. Je ne suis pas sûr jusqu'à ce que j'y arrive.

Comment puis-je retrouver cela rapidement? Nous sommes dans beaucoup de   contentieux si je ne fais pas la sauvegarde du serveur dès que possible. Toute aide est   apprécié. Nous exécutons Open SUSE 11.0.


2011.01.03 - Merci à tous pour votre aide. Heureusement, je n'étais pas le seul responsable de ce serveur, juste le plus proche. On a géré   résoudre ce problème, même s’il peut ne pas s’appliquer à beaucoup d’autres   situation différente. Je vais détailler ce que nous avons fait.

Nous avons débranché le serveur du net. C'était performant (en essayant de   effectuer) une attaque par déni de service sur un autre serveur indonésien,   et le coupable était également basé là-bas.

Nous avons d'abord essayé d'identifier d'où venait le serveur,   considérant que nous avons plus de 500 sites sur le serveur, nous nous attendions à être   travail au noir pendant un certain temps. Cependant, avec l’accès SSH encore, nous avons exécuté une   commande pour trouver tous les fichiers édités ou créés au moment des attaques   commencé. Heureusement, le fichier incriminé a été créé pendant l'hiver   vacances, ce qui signifie que peu d’autres fichiers ont été créés sur le   serveur à cette époque.

Nous avons ensuite pu identifier le fichier incriminé qui se trouvait à l’intérieur du   dossier des images téléchargées dans un ZenCart site Internet.

Après une courte pause cigarette, nous avons conclu que, en raison des fichiers   l’emplacement, il doit avoir été téléchargé via une installation de téléchargement de fichier qui   était inadequetly sécurisé. Après quelques recherches sur Google, nous avons constaté qu'il y avait   une faille de sécurité qui permettait de télécharger des fichiers, dans le   Panneau d'administration ZenCart, pour une photo d'une maison de disques. (La section   qu’il n’a jamais vraiment utilisé), poster ce formulaire vient de télécharger   fichier, il n’a pas vérifié l’extension du fichier et n’a même pas   vérifiez si l'utilisateur était connecté.

Cela signifie que tous les fichiers peuvent être téléchargés, y compris un fichier PHP pour   l'attaque. Nous avons sécurisé la vulnérabilité avec ZenCart sur les personnes infectées.   site et supprimé les fichiers incriminés.

Le travail était terminé et j'étais chez moi pendant 2 heures du matin.


Le moral   - Appliquez toujours des correctifs de sécurité pour ZenCart ou tout autre système CMS à cet égard. Comme lorsque les mises à jour de sécurité sont publiées, l’ensemble   le monde est sensibilisé à 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 un message panicy sur le serveur   Faute.


578
2018-01-02 21:31


origine


Je sais ce que vous ressentez - nous avons eu beaucoup de chance avec les pirates "utiles" de ce site, qui nous disent ce qu'ils ont fait! Je suis impatient d'obtenir d'excellentes réponses à cette question, juste au cas où nous aurions des invités "pas si utiles" à l'avenir. - Jarrod Dixon♦
Appelez un professionnel pour aider! - marcog
Je ne veux pas paraître intelligent ou antipathique (je ne suis pas non plus), et bien sûr, je ne connais pas les détails de votre situation, mais si vous êtes le seul responsable de la configuration d'un site 500-600, il se peut que être un défaut fondamental dans la façon dont ce serveur est exécuté. Certaines entreprises emploient un administrateur système dédié qui ne fait rien d’autre de la journée mais entretient des serveurs - une tâche difficile à réaliser. ne pas automatiquement dans la portée du programmeur, même si cela peut paraître ainsi. Peut-être que cela mérite d'être pris en compte lorsque la crise sera terminée Quoi qu'il en soit, pour le moment, je souhaite la meilleure des chances pour résoudre la situation. - Pekka 웃
Ne présumez pas nécessairement que vous avez un kit racine du noyau complet et que votre mot de passe root est compromis. C'est peut-être juste un script sournois bash / perl, et il est possible de le nettoyer sans le formater malgré ce que dit la chorale ici ... serverfault.com/questions/639699/… - Hayden Thring


Réponses:


Il est difficile de donner des conseils précis à partir de ce que vous avez posté ici, mais j'ai quelques conseils génériques basés sur un message que j'ai écrit il y a longtemps, alors que je pouvais encore avoir la peine de bloguer.

Ne paniquez pas

Tout d’abord, il n’existe pas de «solution miracle» autre que la restauration du système à partir d’une sauvegarde effectuée avant l’intrusion, ce qui pose au moins deux problèmes.

  1. Il est difficile de savoir quand l'intrusion s'est produite.
  2. Cela ne vous aide pas à combler le "trou" qui leur a permis d'entrer la dernière fois, ni à gérer les conséquences de tout "vol de données" qui aurait également eu lieu.

Cette question est fréquemment posée par les victimes d'intrusion de pirates sur leur serveur Web. Les réponses changent très rarement, mais les gens continuent à poser la question. Je ne sais pas pourquoi. Peut-être que les gens n'aiment pas les réponses qu'ils ont trouvées 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% de 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 questions et réponses lorsque leur cas est assez proche de la même chose comme celui qu'ils lisent en ligne.

Cela m'amène à la première pépite d'information importante. J'apprécie vraiment que vous soyez un flocon de neige unique et spécial. J'apprécie que votre site Web soit aussi, car il reflète votre entreprise et à tout le moins votre travail acharné pour le compte d'un employeur. Mais pour quelqu'un de l'extérieur qui regarde, qu'il s'agisse d'un responsable de la sécurité informatique qui essaie de vous aider ou même de l'attaquant lui-même, il est très probable que votre problème soit au moins identique à 95% à tous les autres cas qu'ils ont rencontrés. jamais regardé.

Ne prenez pas l'attaque personnellement, et ne prenez pas les recommandations qui suivent ici ou que vous recevez personnellement d'autres personnes. Si vous lisez ceci après être juste devenu la 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 temps de laisser votre ego vous empêcher de faire ce dont vous avez besoin faire.

Vous venez de découvrir que votre serveur a été piraté. Maintenant quoi?

Ne panique pas. Absolument, n'agissez pas dans la précipitation, et n'essayez absolument pas de faire comme si rien ne s'était jamais passé et de ne rien faire du tout.

Premièrement: comprenez que le désastre est déjà arrivé. Ce n'est pas le moment de nier; il est temps d'accepter ce qui s'est passé, d'être réaliste 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 détails), peu m'importe si vous ignorez tout ou partie de ces étapes, à vous de décider. Mais les suivre correctement améliorera les choses à la fin. Le médicament a peut-être un goût désagréable, mais vous devez parfois l'ignorer si vous voulez vraiment que le traitement guérisse.

Empêchez le problème de devenir pire qu’il ne l’est déjà:

  1. La première chose à faire est de déconnecter les systèmes affectés d’Internet. Quels que soient vos autres problèmes, laisser le système connecté au Web ne permettra que l'attaque se poursuive. Je veux dire cela littéralement; demandez à quelqu'un de se rendre physiquement sur 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.
  2. Modifiez tous vos mots de passe pour tous les comptes sur tous les ordinateurs du 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'autre part, il se pourrait que non. Vous ne savez pas de toute façon, et vous?
  3. Vérifiez vos autres systèmes. Portez une attention particulière aux autres services Internet et à ceux qui détiennent des données financières ou autres données sensibles sur le plan commercial.
  4. Si le système contient des données personnelles, informez immédiatement le responsable de la protection des données (si ce n'est pas vous) et DEMANDEZ 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 régler ce problème sous le tapis, mais elles devront le faire face - et doivent le faire en gardant un œil sur toutes les lois pertinentes en matière de protection de la vie privée.

Même si vos clients sont agacés par le fait que vous leur parliez d'un problème, ils le seront encore plus si vous ne le leur dites pas, et ils ne le découvriront que lorsque quelqu'un facturera pour 8 000 $ de biens à l'aide des détails de leur carte de crédit. volé de votre site.

Tu te souviens de 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 si vous vous en sortez bien.

Comprenez bien le problème:

  1. Ne remettez PAS les systèmes concernés en ligne tant que cette étape n'est pas complètement terminée, à moins que vous ne souhaitiez être la personne dont le message a été le point de basculement pour moi qui ai décidé d'écrire cet article. Je ne ferai pas de lien vers ce message pour que les gens puissent bien rire, mais la vraie tragédie est lorsque les gens ne tirent pas les leçons de leurs erreurs.
  2. Examinez les systèmes "attaqués" pour comprendre comment les attaques ont compromis votre sécurité. Faites tout ce qui est en votre pouvoir pour savoir d'où proviennent les attaques, afin de comprendre les problèmes que vous rencontrez et que vous devez résoudre pour sécuriser votre système à l'avenir.
  3. Examinez à nouveau les systèmes "attaqués", cette fois pour comprendre où les attaques ont eu lieu, afin de comprendre quels systèmes ont été compromis lors de l'attaque. Assurez-vous de suivre tous les indicateurs suggérant que les systèmes compromis pourraient devenir un tremplin pour attaquer vos systèmes.
  4. 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, vous devez non seulement fermer la ligne de code défectueuse qu’ils ont interrompue, mais vous souhaitez également vérifier l’ensemble de votre code pour voir si le même type d’erreur a été faite ailleurs).
  5. Comprenez que les attaques peuvent réussir en raison de plusieurs défauts. Souvent, les attaques réussissent non pas en trouvant un bug 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 que le site Web / l'application que vous attaquez est exécuté dans le contexte d'un utilisateur administratif et utiliser les droits de ce compte comme point de départ 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 commises par les gens".

Pourquoi ne pas simplement "réparer" l'exploit ou le rootkit que vous avez détecté et remettre le système en ligne?

Dans ce genre de situation, 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 au système une fois que les intrus ont pris le contrôle (en fait, ce n'est pas inouï 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 l’installation de leur rootkit).

Élaborez un plan de reprise pour remettre votre site Web en ligne et respectez-le:

Personne ne veut être déconnecté plus longtemps que nécessaire. C'est une donnée. Si ce site Web génère des revenus, la pression pour le remettre en ligne rapidement sera intense. Même si la réputation de votre entreprise est la seule en jeu, cela va toujours générer beaucoup de pression pour que les choses reprennent rapidement.

Cependant, ne cédez pas à la tentation de revenir en ligne trop rapidement. Déplacez-vous plutôt vite que possible pour comprendre la cause du problème et le résoudre avant de retourner en ligne, sinon vous serez à nouveau victime d'une intrusion et rappelez-vous, "se faire pirater une fois peut être qualifié de malheur; se faire pirater de nouveau tout de suite après ressemble à de l'insouciance "(avec nos excuses à Oscar Wilde).

  1. Je suppose que vous avez compris tous les problèmes qui ont conduit à l'intrusion réussie avant même de commencer cette section. Je ne veux pas exagérer le cas, mais si vous ne l'avez pas déjà fait, vous devez le faire. Pardon.
  2. Ne payez jamais de chantage / protection. C'est le signe d'une marque facile et vous ne voulez pas que cette phrase soit jamais utilisée pour vous décrire.
  3. Ne soyez pas tenté de remettre les mêmes serveurs en ligne sans une reconstruction complète. Il devrait être beaucoup plus rapide de créer un nouveau boîtier ou de "réorganiser le serveur en orbite et de procéder à une nouvelle installation" sur l'ancien matériel, plutôt que de procéder à l'audit de 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 réellement de s’assurer que le système est entièrement nettoyé, ou que les procédures de déploiement de votre site Web sont un foutoir désastreux. Vous avez probablement des sauvegardes et des déploiements de test de votre site que vous pouvez simplement utiliser pour créer le site en direct, et si vous ne le faites pas, alors votre piratage informatique n'est pas votre plus gros problème.
  4. Soyez très prudent lors de la réutilisation de données "en direct" sur le système au moment du piratage. Je ne dirai pas "ne le fais jamais" parce que vous allez simplement m'ignorer, mais franchement, je pense que vous devez prendre en compte les conséquences de la conservation des données lorsque vous savez que vous ne pouvez pas garantir leur intégrité. Idéalement, vous devriez restaurer ceci à partir d'une sauvegarde effectuée avant l'intrusion. Si vous ne pouvez pas ou ne voulez pas faire cela, vous devez être très prudent avec ces données car elles sont corrompues. Vous devez en particulier être conscient des conséquences pour les autres si ces données appartiennent à des clients ou à des visiteurs du site plutôt que directement à vous.
  5. Surveillez attentivement le (s) système (s). Vous devez vous résoudre à le faire en tant que processus continu à l'avenir (voir ci-dessous), mais vous prenez des efforts supplémentaires pour être vigilant pendant la période qui suit immédiatement la remise en ligne de votre site. Les intrus seront certainement de retour, et si vous pouvez les repérer en essayant de vous replonger, vous pourrez certainement voir rapidement si vous avez réellement comblé tous les trous qu’ils avaient utilisés auparavant et tous ceux qu’ils ont faits pour eux-mêmes, et vous pourriez vous en servir. informations que vous pouvez transmettre à vos forces de l'ordre locales.

Réduire les risques à 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 orienté Internet. Vous ne pouvez pas, par la suite, appliquer plusieurs couches sur votre code comme bon marché. peindre. Pour être correctement sécurisés, un service et une application doivent être conçus dès le départ, avec cet objectif à l'esprit, comme l'un des objectifs majeurs du projet. Je me rends compte que c’est ennuyeux et que vous avez déjà entendu tout cela et que je "ne réalise tout simplement pas la pression" pour que votre service bêta web2.0 (bêta) 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 que cela a été dit et que ce n'est pas encore devenu un mensonge.

Vous ne pouvez pas éliminer les risques. Vous ne devriez même pas essayer de faire ça. Cependant, vous devez savoir quels risques de sécurité vous importent et comment gérer et réduire l'impact du risque et la probabilité qu'il se produise.

Quelles mesures pouvez-vous prendre pour réduire la probabilité qu'une attaque réussisse?

Par exemple:

  1. La faille qui permettait aux personnes de pénétrer sur votre site était-elle un bogue connu dans le code du fournisseur, pour lequel un correctif était disponible? Si tel est le cas, avez-vous besoin de repenser votre approche pour patcher les applications sur vos serveurs Internet?
  2. La faille qui permettait aux personnes de pénétrer sur votre site était-elle un bogue inconnu dans le code du fournisseur, pour lequel aucun correctif n'était disponible? Je ne préconise certainement pas de changer de fournisseur chaque fois que quelque chose de ce genre vous dérange, car ils ont tous des problèmes et vous allez manquer de plates-formes dans un an au maximum si vous adoptez cette approche. Toutefois, si un système vous laisse constamment tomber, vous devez migrer vers quelque chose de plus robuste ou au moins restructurer votre système pour que les composants vulnérables restent enveloppés dans du coton et le plus loin possible des yeux hostiles.
  3. La faille était-elle un bug du code développé par vous (ou par un contractant travaillant pour vous)? Si tel est le cas, devez-vous repenser votre approche pour approuver le code à déployer sur votre site actif? Le bogue a-t-il été détecté avec un système de test amélioré ou avec des modifications de votre "norme" 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 ).
  4. 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? Ils sont d'une grande aide pour maintenir un état de "base" cohérent sur tous vos serveurs, en minimisant la quantité de travail personnalisé à effectuer sur chacun d'eux et, partant, en espérant minimiser les risques d'erreur. Il en va de même pour le déploiement de code: si vous souhaitez effectuer une opération "spéciale" pour déployer la dernière version de votre application Web, essayez de l'automatiser et assurez-vous que l'opération est toujours effectuée de manière cohérente.
  5. L'intrusion aurait-elle pu être détectée plus tôt avec une meilleure surveillance de vos systèmes? Bien sûr, une surveillance 24 heures sur 24 ou un système "sur appel" pour votre personnel peut ne pas être rentable, mais certaines entreprises peuvent surveiller votre service Web et vous alerter en cas de problème. Vous pouvez décider que vous ne pouvez pas vous le permettre ou que vous n'en avez pas besoin et c'est très bien ... prenez-le en considération.
  6. Utilisez des outils tels que tripwire et nessus, le cas échéant - mais ne les utilisez pas simplement à l'aveuglette car je l'ai dit. Prenez le temps d'apprendre à utiliser quelques outils de sécurité adaptés à votre environnement, mettez-les à jour et utilisez-les régulièrement.
  7. Envisagez de faire appel à des experts en sécurité pour «auditer» régulièrement la sécurité de votre site Web. Encore une fois, vous pouvez décider que vous ne pouvez pas vous le permettre ou que vous n'en avez pas besoin et c'est très bien ... prenez-le 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 au rez-de-chaussée de votre maison est élevé, mais pas assez élevé pour justifier un déménagement, vous devriez au moins déplacer les héritages irremplaçables de la famille à l’étage supérieur. Droite?

  1. Pouvez-vous réduire la quantité de services directement exposés à Internet? Pouvez-vous maintenir une sorte de décalage entre vos services internes et vos services Internet? Cela garantit que même si vos systèmes externes sont compromis, les chances de l'utiliser comme un tremplin pour attaquer vos systèmes internes sont limitées.
  2. Stockez-vous des informations que vous n'avez pas besoin de stocker? Stockez-vous ces informations "en ligne" quand 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 n'avez pas, et le deuxième point est que moins vous stockez, moins vous avez besoin de maintenir et de coder, et il y a donc moins de chances que des bugs se glissent votre code ou conception de systèmes.
  3. Utilisez-vous les principes du "moindre accès" pour votre application Web? Si les utilisateurs n'ont besoin que de lire à partir d'une base de données, assurez-vous que le compte utilisé par l'application Web pour la gérer dispose uniquement d'un accès en lecture, n'autorisez pas l'accès en écriture et certainement pas au niveau du système.
  4. Si vous n’êtes pas très expérimenté et qu’il n’est pas essentiel à votre entreprise, envisagez de l’externaliser. En d'autres termes, si vous exploitez 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 de "sous-traiter" votre système de commande par carte de crédit à quelqu'un comme Paypal.
  5. Dans la mesure du possible, intégrez dans votre plan de reprise après sinistre la restauration des systèmes compromis. Ceci est sans doute un autre "scénario catastrophe" que vous pourriez rencontrer, simplement un avec ses propres problèmes et problèmes distincts de l'habituel 'salle des serveurs pris feu' / 'a été envahi par le genre de chose que les serveurs géants mangent.

... Et enfin

J'ai probablement laissé de nombreuses choses que d'autres considèrent comme importantes, mais les étapes ci-dessus devraient au moins vous aider à résoudre les problèmes si vous êtes assez malchanceux pour être 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.


988
2018-01-02 21:46



+1 pour un excellent poste à avoir pour faire démarrer les gens dans une direction. Je sais à quel point il est courant que les administrateurs de serveur amateurs se lancent dans ce mode de panique la première fois qu’ils subissent un «piratage». C'est un énorme erreur d'être à cet endroit, mais cela arrive. L'espoir serait que cela n'arrive pas à la même personne, deux fois. - Andrew Barber
+1 "... mais ce n'est pas le moment de laisser votre ego vous empêcher de faire ce que vous devez faire." Il est important que les administrateurs système comprennent parfois. Peu importe votre niveau de connaissance, il y a toujours des personnes (parfois malicieuses) qui sont plus informées ou intelligentes que vous. - Grahamux
Très bonne réponse. Je ne suis pas sûr de savoir pourquoi tout le monde considère l’étape "appeler les forces de l'ordre" comme facultative. Si vous êtes responsable des données d'autres personnes (et que vous vous inquiétez de litiges), cela devrait être l'une des premières choses sur votre liste de choses à faire. - wds
Très bonne rédaction, un seul casse-tête - "faire une divulgation complète et franche à toute personne potentiellement touchée à la fois". Honorable, mais pas toujours correct. En réponse à un compromis, vous devrez peut-être réduire certains aspects de la gouvernance et votre entreprise vous laissera généralement un peu de temps, mais ... la divulgation ou non, en particulier lorsque des implications en matière de protection des données peuvent être au-dessus de votre niveau de rémunération et pourrait avoir des implications juridiques. Il peut être préférable de suggérer que vous en informiez immédiatement le responsable de la protection des données (si ce n’est pas vous) et DEMANDE INSTAMMENT une divulgation complète. - TheoJones
Les hôtes des machines virtuelles @GilesRoberts ont généralement un panneau de configuration qui vous permet de manipuler les paramètres de leurs invités, et même de les contrôler à distance sans utiliser RDP ou SSH pour vous connecter à l'invité. Vous devriez pouvoir isoler l'invité à l'aide des commandes de l'hôte, puis utiliser ses outils de visualisation à distance pour examiner l'invité à votre guise. - Rob Moir


On dirait qu'ils sont légèrement au-dessus de votre tête; c'est bon. Appelez votre patron et commencez à négocier un budget de réponse d'urgence à la sécurité. 10 000 $ pourrait être un bon endroit pour commencer. Ensuite, vous devez faire appel à une personne (un PFY, un collègue, un responsable) pour contacter 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 leur expliquer ce qui se passe, ce qui est fait pour gérer la situation et pour répondre à leurs questions.

Ensuite, vous devez ...

  1. Reste calme. Si vous êtes responsable de la réponse aux incidents, ce que vous faites maintenant doit faire preuve d'un professionnalisme et d'un leadership sans faille. Documentez tout ce que vous faites et informez votre responsable et votre équipe de direction des principales actions que vous prenez. Cela comprend le travail avec une équipe de réponse, la désactivation des serveurs, la sauvegarde des données et la remise en ligne de certains éléments. Ils n'ont pas besoin de détails sanglants, mais ils devraient vous entendre toutes les 30 minutes environ.

  2. Être réaliste. Vous n'êtes pas un professionnel de la sécurité et vous ne savez pas certaines choses. C'est bon. Lorsque vous vous connectez à des serveurs et consultez des données, vous devez comprendre vos limites. Marchez doucement. Au cours de votre enquête, veillez à ne pas piétiner des informations vitales ou à modifier quelque chose qui pourrait être nécessaire ultérieurement. Si vous vous sentez mal à l'aise ou si vous devinez, c'est un bon endroit pour faire une pause et demander à un professionnel expérimenté de prendre la relève.

  3. Obtenez une clé USB propre et des disques durs disponibles. Vous allez collecter des preuves ici. Faites des sauvegardes de tout ce que vous jugez pertinent. communication avec votre FAI, vidage réseau, etc. Même si les forces de l'ordre ne sont pas impliquées, vous souhaiterez, en cas de litige, prouver que votre entreprise a géré l'incident de sécurité de manière professionnelle et appropriée.

  4. 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 de réseau; si vous ne pouvez pas, alors tirez le pouvoir.

  5. Ensuite, vous devez supprimer l'attaquant et fermer le (s) trou (s). Vraisemblablement, l'attaquant n'a plus d'accès interactif parce que vous avez utilisé le réseau. Vous devez maintenant identifier, documenter (avec des sauvegardes, des captures d'écran et vos notes d'observation personnelles; ou de préférence en retirant les disques des serveurs affectés et en créant une copie complète de l'image disque), puis en supprimant le code et les processus qu'il a laissés. . Cette prochaine partie sera nulle si vous n'avez pas de sauvegardes; Vous pouvez essayer de dégager 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 solution consiste à identifier la vulnérabilité qu’il a utilisée pour entrer, à créer des copies d’image des disques affectés, puis à effacer les systèmes affectés et à recharger à partir d’une sauvegarde en bon état. Ne faites pas aveuglément confiance à votre sauvegarde. vérifiez-le! Réparez ou fermez la vulnérabilité avant que le nouvel hôte ne soit à nouveau connecté au réseau, puis mettez-la en ligne.

  6. Organisez toutes vos données dans un rapport. À ce stade, la vulnérabilité est fermée et vous avez un peu de temps pour 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 ne va pas, la réaction de votre équipe et les mesures que vous prenez pour éviter que cet incident ne se reproduise. Soyez aussi précis que possible. ce n'est pas juste pour vous, mais pour votre gestion et comme défense dans un procès potentiel.

C'est une révision sans précédent de ce qu'il faut faire; l'essentiel du travail consiste simplement en de la documentation et du traitement des sauvegardes. Ne paniquez pas, vous pouvez faire ce genre de choses. je fortement vous recommandons de faire appel à une aide de sécurité professionnelle Même si vous pouvez gérer ce qui se passe, leur aide sera précieuse et ils viennent généralement avec du matériel pour rendre le processus plus facile et plus rapide. Si votre patron résiste au coût, rappelez-lui que c'est très petit comparé au traitement d'un procès.

Vous avez mes consolations pour votre situation. Bonne chance.


199
2018-01-02 22:16



+1 excellente réponse. Il semble que le PO ne dispose pas d'une "réponse d'urgence" prédéfinie et votre message, entre autres bonnes choses, devrait les orienter vers la mise en place de cette configuration. - Rob Moir


CERT a un document Procédure de récupération à partir d'un compromis système UNIX ou NT ça c'est bon. Les détails techniques spécifiques de ce document sont quelque peu dépassés, mais de nombreux conseils généraux s'appliquent toujours directement.

Voici un résumé rapide des étapes de base.

  • Consultez votre politique de sécurité ou de gestion.
  • Prenez le contrôle (mettez l'ordinateur hors ligne)
  • Analyser l'intrusion, obtenir des journaux, comprendre ce qui a mal tourné
  • Trucs de réparation
    • 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 à la ligne.
  • Mettre à jour les systèmes pour que cela ne se reproduise plus
  • Reprendre les opérations
  • Mettre à jour votre politique pour l'avenir et documenter

Je voudrais vous indiquer spécifiquement la section E.1.

E.1.   Gardez à l'esprit que si une machine est   compromis, rien sur ce système   aurait pu être modifié, y compris   le noyau, les fichiers binaires, les fichiers de données,   processus en cours, et mémoire. Dans   général, le seul moyen de faire confiance à un   la machine est libre de backdoors et   modifications d'intrus est de réinstaller   le fonctionnement

Si vous ne possédez pas déjà de système tel que tripwire, vous ne pouvez absolument pas être sûr à 100% que vous avez nettoyé le système.


105
2018-05-08 09:02



Même dans ce cas, tripwire peut être trompé avec des modules de noyau et autres. Réinstaller. - reconbot
La question connexe à propos de comment réagir en cas de crise peut également être utile ici. - Zoredache


  1. Identifier le problème. Lire les journaux.
  2. Contenir. Vous avez déconnecté le serveur, c'est donc fait.
  3. Éradiquer. Réinstallez le système affecté, le plus probablement. N'effacez pas le disque dur du disque piraté, utilisez-en un nouveau. C'est plus sûr, et vous aurez peut-être besoin de l'ancien pour récupérer les horribles hacks qui n'ont pas été sauvegardés et pour faire de la médecine légale afin de découvrir ce qui s'est passé.
  4. Récupérer. Installez ce dont vous avez besoin et récupérez des sauvegardes pour mettre vos clients en ligne.
  5. Suivre. Déterminez quel était le problème et évitez qu'il ne se reproduise.

64
2018-01-02 21:49





La réponse de Robert à la "pilule amère" est précise mais parfaitement générique (comme ce fut votre question). On dirait que vous avez un problème de gestion et que vous avez un besoin urgent d’un administrateur système à temps plein si vous avez un serveur et 600 clients, mais cela ne vous aide pas pour le moment.

Je dirige une société d’hébergement qui fournit un peu de prise en main dans cette situation. Je gère donc beaucoup de machines compromises, mais je traite également de la meilleure pratique pour la nôtre. Nous disons 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 souhaitait une rampe de lancement pour les attaques par déni de service, ou des videurs IRC, ou quelque chose de complètement indépendant des sites et des données de vos clients. Par conséquent, à titre de mesure temporaire pendant la reconstruction, vous pouvez envisager de mettre en place un pare-feu sortant lourd sur votre boîte. Si vous pouvez bloquer toutes les connexions UDP et TCP sortantes qui ne sont pas absolument nécessaires au fonctionnement de vos sites, vous pouvez facilement rendre votre boîte compromise inutile pour quiconque l'emprunte, et atténuer à zéro l'effet sur le réseau de votre fournisseur.

Ce processus peut prendre quelques heures si vous ne l'avez pas encore fait et si vous n'avez jamais envisagé de pare-feu, mais pourrait vous aider à restaurer le service de vos clients. au risque de continuer à donner à l'attaquant l'accès aux données de vos clients. Puisque vous dites que vous avez des centaines de clients sur une seule machine, j'imagine que vous hébergez des sites Web de petites brochures pour les petites entreprises et non pas 600 systèmes de commerce électronique remplis de numéros de cartes de crédit. Si tel est le cas, cela peut constituer un risque acceptable pour vous et remettez votre système en ligne plus rapidement que l'audit de 600 sites pour détecter les bogues de sécurité. avant vous rapportez rien. Mais vous saurez quelles données sont disponibles et dans quelle mesure vous prendrez cette décision avec facilité.

Ce n’est absolument pas une bonne pratique, mais si ce n’est pas ce qui se passe chez votre employeur jusqu’à présent, agitez-le du doigt et demandez des dizaines de milliers de livres à une équipe SWAT pour quelque chose qu’elle pourrait penser de votre faute (même si elle est injustifiée!). ) ne ressemble pas à l'option pratique.

L'aide de votre FAI ici sera cruciale - certains FAI fournir un serveur de console et un environnement d'initialisation réseau (branchez, mais au moins vous savez quel type d’installation à rechercher) qui vous permettra d’administrer le serveur tout en étant déconnecté du réseau. S'il s'agit d'une option, demandez-la et utilisez-la.

Mais à long terme, vous devriez prévoir une reconstruction du système basée sur le poste de Robert et un audit de chaque site et de sa configuration. Si vous ne parvenez pas à ajouter un administrateur système à votre équipe, recherchez un hébergement géré Lorsque vous payez votre fournisseur d’accès pour obtenir de l’aide système et une réponse 24 heures sur 24 pour ce genre de problème. Bonne chance :)


49
2018-01-03 13:48





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 altérés. J'ai écrit ce qui suit en python: http://frw.se/monty.py ce 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é changé, puis affiche les fichiers modifiés et ceux modifiés dans les fichiers.

Cela pourrait être pratique pour vous, pour voir si les fichiers étranges sont changés régulièrement.

Mais la seule chose que vous devriez faire maintenant, est de supprimer votre ordinateur d’Internet.


38
2018-05-08 08:02



Alors ... vous avez implémenté tripwire. - womble♦
Oui, quelque chose ne va pas avec ça? - Filip Ekberg
+1 pour débrancher, analyser (demander à quelqu'un de faire de la vraie criminalistique dessus) et effacer - Oskar Duveborn
Si vous avez le choix entre un script Python anonyme et une solution standard bien comprise et documentée, (quelque peu) prise en charge, vous espérez qu'ils choisiront la première? - tripleee


REMARQUE: Ceci n'est pas une recommandation. Mon spécifique Réponse à un incident protocole probablement pas ne s'applique pas sans modification au cas de Grant unwin.

Dans nos établissements universitaires, environ 300 chercheurs ne font que des calculs. Vous avez 600 clients avec des sites Web, votre protocole sera probablement différent.

Les premiers pas de notre Lorsqu'un serveur obtient un protocole compromis est:

  1. Identifier que l'attaquant a pu obtenir un compte root (privilèges élevés)
  2. Débranchez le ou les serveurs affectés. Réseau ou pouvoir? S'il te plait regarde une discussion séparée.
  3. Vérifier tous les autres systèmes
  4. Démarrer le (s) serveur (s) affecté (s) à partir d’un cd en direct
  5. (optionnel) Saisissez les images de tous les lecteurs du système avec dd
  6. Commencez à faire la criminalistique post-mortem. Consultez les journaux, déterminez l'heure de l'attaque, recherchez les fichiers modifiés à cette heure. Essayez de répondre à la Comment? question.

    • En parallèle, planifiez et exécutez votre récupération.
    • Réinitialiser tous les mots de passe root et utilisateur avant de reprendre le service

Même si "toutes les portes dérobées et les rootkits sont nettoyés", ne faites pas confiance à ce système - réinstallez-le à partir de zéro.


34
2018-05-18 22:36



-1 Débranchez le serveur du pouvoir? Vous venez de perdre la moitié de vos données médico-légales! - Josh Brower
@Josh, j'ai ajusté ma réponse - elle est maintenant neutre sur la question de quoi débrancher. - Aleksandr Levchuk
Les analyses judiciaires RAM (par exemple, / dev / shm) peuvent être utiles. Je préfère débrancher le câble d’alimentation (mais essayez de vous connecter et rsync / proc juste avant). Nous pouvons également introduire des instantanés de VM fréquents pour permettre une analyse judiciaire de la RAM. Les raisons d’utiliser le câble d’alimentation sont les suivantes: (1) lorsque vous procédez à une analyse judiciaire dans un système piraté, vous "parcourez la scène du crime"; (2) Le kit racine continue de fonctionner - il n’est pas si difficile pour le malicieux d’exécuter quelque chose (par exemple, le nettoyage du système) sur Lien réseau vers le bas un événement. Kyle Rankin dans son discours d’introduction à la criminalistique (goo.gl/g21Ok) recommandé de tirer le câble d'alimentation. - Aleksandr Levchuk
Il n'y a pas de solution unique pour tous les protocoles IR - Certaines organisations peuvent avoir besoin de garder le système compromis en ligne plus longtemps, pour une raison quelconque. (Informations légales sur les journaux RAM et temporaires, interagissant avec les intrus, etc.) Mon objectif est qu’il serait préférable de recommander un protocole IR générique (comme Jakob Borgs ci-dessus) plutôt que celui qui commence par «Déconnectez le cordon d’alimentation du serveur compromis. " - Josh Brower