Lorsqu'un serveur est enraciné ( par exemple une situation comme celle-ci ), l'une des premières choses que vous pouvez décider de faire est le confinement . Certains spécialistes de la sécurité conseillent de ne pas entrer immédiatement dans la correction et de garder le serveur en ligne jusqu'à ce que la criminalistique soit terminée. Ces conseils sont généralement pour APT . C'est différent si vous avez des violations occasionnelles de Script pour les enfants , vous pouvez donc décider de corriger (réparer les choses) tôt. L'une des étapes de la correction est le confinement du serveur. Citant la réponse de Robert Moir - "déconnectez la victime de ses agresseurs".
Un serveur peut être contenu en tirant sur le câble réseau ou le câble d'alimentation .
Quelle méthode est la meilleure?
Tenant compte de la nécessité:
- Protéger les victimes de nouveaux dommages
- Exécution de criminalistique réussie
- (Peut-être) Protéger des données précieuses sur le serveur
Edit: 5 hypothèses
En supposant:
- Vous avez détecté tôt: 24 heures.
- Vous souhaitez récupérer tôt: 3 jours de 1 administrateur système sur le chantier (criminalistique et récupération).
- Le serveur n'est pas une machine virtuelle ou un conteneur capable de prendre un instantané capturant le contenu de la mémoire du serveur.
- Vous décidez de ne pas tenter de poursuivre.
- Vous pensez que l'attaquant peut utiliser une forme de logiciel (éventuellement sophistiquée) et que ce logiciel fonctionne toujours sur le serveur.
Réponses:
Si vous êtes confronté à un APT, votre meilleure option consiste à configurer un pot de miel et à enquêter de manière approfondie sur tout le trafic entrant et sortant, en plus de surveiller le serveur.
La mesure de la mémoire est si coûteuse en termes de temps et d'efforts que cela ne vaut généralement pas la peine sauf si vous avez essayé toutes les autres méthodes, et si vous déterminez que cela en vaut la peine, il est généralement préférable de configurer un pot de miel qui vous permet de vider facilement l'état de la mémoire et du système sur une autre machine à la volée afin que vous puissiez effectuer une analyse avec moins de menace d'être détecté lorsque la machine est en marche.
J'ai eu une situation où l'attaquant a tout gardé en mémoire au point que, à l'exception des journaux, la machine ressemblait exactement à son image une fois éteinte puis rallumée. Ils pirataient ensuite et recommençaient à l'utiliser parce que la vulnérabilité était toujours là - ils n'avaient pas besoin de se laisser de portes dérobées pour eux-mêmes. Une évaluation de la mémoire aurait pu aider ici, mais regarder le trafic était suffisant dans ce cas pour identifier rapidement la vulnérabilité.
Par conséquent:
La seule raison pour éviter de couper le courant et d'effectuer une évaluation de disque hors ligne est si vous allez subir la douleur de faire une analyse approfondie de la mémoire de la menace lorsqu'elle est en place et fonctionne. Si vous êtes arrivé au point où cela est nécessaire, il n'y a aucune raison de retirer l'une ou l'autre fiche.
Si vous ne faites pas d'analyse de mémoire, il est préférable de tirer sur la prise d'alimentation - tirer sur Ethernet (ou en utilisant une commande d'arrêt) ne donnera qu'un préavis au logiciel de l'attaquant - ce qui importe parfois.
Donc:
Tirez-les tous les deux, sauf si vous faites une analyse de la mémoire, auquel cas, ne tirez pas non plus.
la source
La criminalistique RAM (par exemple / dev / shm) peut être utile.
Mais je préfère débrancher le câble d'alimentation (mais essayez de vous connecter et de rsync / proc juste avant).
Les raisons d'aller pour le câble d'alimentation sont:
Kyle Rankin a donné une belle introduction à la criminalistique - là, il recommande de tirer le câble d'alimentation.
la source
Déconnectez le réseau. L'attaquant ne peut pas extraire d'informations supplémentaires s'il n'y a pas de connexion réseau. Il est très difficile (lire: impossible) de faire de la médecine légale sans électricité.
la source
De nos jours, il pourrait s'agir d'une machine virtuelle, donc l'une ou l'autre méthode est facile et peut même être effectuée à distance. (Les machines virtuelles donnent également la possibilité d'utiliser des instantanés)
Je suggérerais de vous déconnecter du réseau comme première étape automatique, car cela vous donne le temps de réfléchir à la prochaine étape, que cette prochaine étape soit de tirer le cordon d'alimentation ou autre chose. Si vous savez que les «procédures de réponse de sécurité» de votre entreprise ne vous permettront pas de passer du temps à fouiller la machine en détail, la préservation du contenu de la RAM pourrait ne pas être si importante.
Je dirais que faire "séparer la victime de ses agresseurs" de quelque manière que ce soit est plus important que le comment, donc les deux approches sont valides. Je n'aurais aucun problème à tirer le cordon d'alimentation moi-même, disons-le de cette façon.
la source
Ce n'est pas une situation non plus. Vous voulez généralement faire les deux - vous voulez effectuer certaines analyses judiciaires (vidage des processus en cours d'exécution, sockets d'écoute, fichiers dans / tmp, etc.) sur un système qui a été supprimé du réseau, puis effectuez vos diagnostics restants à partir d'un coffre-fort l'environnement (c'est-à-dire un CD live). Il y a des situations où aucune approche n'est la bonne, cependant, et vous devez penser et comprendre ce que cela pourrait être dans votre organisation.
la source
Avant de faire quoi que ce soit, déterminez si vous devez conserver des preuves pour une éventuelle poursuite. La gestion des preuves est un sujet très délicat et pas pour les personnes peu formées. Une fois que vous avez répondu à cette question, le spécialiste de l'informatique judiciaire peut le suivre à partir de là.
la source
Pas besoin d'éteindre le serveur. Vous pouvez simplement désactiver la connectivité à partir de la passerelle / routeur frontalière. Une règle de pare-feu sera suffisante pour éliminer tout autre paquet envoyé / reçu.
la source
La réponse dépend en grande partie de ce que vous entendez par «enraciné». Tirer la tête du réseau est généralement une bonne idée, surtout si vous pensez qu'il s'agit d'un attaquant humain actif à la recherche d'informations sensibles.
Il est beaucoup plus difficile de répondre au pouvoir. Si vous pensez qu'un code malveillant en cours d'exécution peut couvrir ses traces, faites-le. Cependant, si vous pensez qu'il peut y avoir des signes d'une effraction dans la mémoire, laissez-le fonctionner.
Dans l'ensemble, cela dépend si vous traitez avec du code malveillant, du personnel mécontent ou quelqu'un avec une cible spécifique en tête.
Si vous vous trompez par prudence, coupez l'alimentation. Vous perdrez une petite quantité de preuves potentielles, mais vous pourrez empêcher la suppression massive d'autres preuves par du code automatisé.
- Là encore, si vous sentez que la machine a été compromise et que vous savez qu'elle ne contient pas de données sensibles, vous êtes très confiant de la sécurité de votre réseau ailleurs et comprenez les conséquences de le faire, peut-être obtenez un boffin médico-légal dès que possible et voyez si vous pouvez retracer ou comprendre l'attaque et partir de là. Ce n'est normalement pas une bonne idée, cependant
la source
Ma réponse était avant le montage, avec les 5 hypothèses.
Mon hypothèse était que si votre serveur était enraciné, vous avez affaire à un attaquant sophistiqué et ciblé, et que vous n'avez aucun moyen de savoir quand et d'où vient l'attaque. (La machine était ancrée, vous ne pouvez évidemment rien de confiance qu'il vous dit. Cependant, vous pourriez avoir des informations hors zone, par exemple IDS ...)
Je suppose que vous avez intérêt à traiter avec votre attaquant, et pas seulement en agitant lui comme une mouche gênante. Si l'attaquant supposé est un gamin script, ce serait différent. J'ai également supposé que, puisque l'attaquant est ciblé et sophistiqué, il est probable qu'il dispose d'un logiciel personnalisé s'exécutant sur votre machine, qui puisse répondre à vos actions dessus ...
Ni.
Consultez /security//q/181/33 , de toute façon, c'est une mauvaise idée.
C'est comme donner quelques pansements au chevalier noir ... trop peu, trop tard, ça n'aidera pas beaucoup.
Pour tous ceux qui pensent que cette réponse est trop éloignée, ou tout simplement pas suffisamment «soucieuse de la sécurité» - vous devez vous rendre compte qu'il est déjà trop tard .
Ce n'est plus votre serveur, même si vous le déconnectez complètement. Même si vous arrêtez, exécutez tous vos AV et quoi que ce soit - vous ne les possédez plus, ils le font.
C'est un peu la définition de "enraciné".
Maintenant, en supposant qu'ils le possèdent et qu'ils peuvent vous cacher leur propriété, vous devez considérer - qu'est-ce qui le déconnectera?
La seule chose qu'il obtiendra - car il continuera d'être enraciné malgré tout - est de faire savoir à votre adversaire que vous êtes sur lui. Ce qui met simplement leurs gardes en place et les oblige à commencer à nettoyer après eux (s'ils ne l'ont pas déjà fait), ce qui ne fera que tuer tout espoir de criminalistique.
Vous ne protégez toujours pas ce serveur, ni aucune de ses données. Depuis combien de temps il été enraciné? Comment saurais tu?
Ce que vous feriez mieux de faire:
la source
Après avoir examiné vos hypothèses, faites les deux. Utilisez un support basé sur CD / DVD pour vider l'état actuel. Vous voudrez surtout pouvoir déterminer comment vous avez été compromis. Vous pouvez également essayer de récupérer les données utilisateur qui ne se trouvent pas sur vos images de sauvegarde. Yo
Reconstruisez ensuite le système à partir du dernier support de sauvegarde non contaminé. Vérifiez cela avec des sommes de contrôle si possible. Vous pouvez également réinstaller le logiciel à partir du support d'installation et reconfigurer. La reconfiguration doit être automatique si vous avez utilisé Puppet ou cfEngine pour configurer votre serveur.
Rechargez les données utilisateur et recherchez les composants du kit racine. Vérifiez que vous n'avez aucun programme setuid ou setgid dans les répertoires de données.
Déterminez et fermez la méthode d'accès utilisée pour infecter le système. Réactivez l'étape du serveur en laissant le temps de vérifier que les applications fonctionnent comme prévu. Surveillez attentivement les nouvelles tentatives d'infection.
Tout cela suppose que l'infection est au niveau de la racine. Les infections Web peuvent être effectuées en modifiant le code exécuté par le serveur Web. Autoriser le serveur Web à accéder en écriture à son code peut faciliter cette opération. Vous pouvez toujours vouloir traiter ce cas comme si le compte root avait été compromis.
Si root sur un système a été compromis sur un système, vous pouvez avoir plus de systèmes compromis. Réfléchissez soigneusement aux systèmes auxquels vous pouvez accéder sans mot de passe du système infecté.
la source