Tirez le réseau ou l'alimentation? (pour conserver un serveur rooté)


11

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é:

  1. Protéger les victimes de nouveaux dommages
  2. Exécution de criminalistique réussie
  3. (Peut-être) Protéger des données précieuses sur le serveur

Edit: 5 hypothèses

En supposant:

  1. Vous avez détecté tôt: 24 heures.
  2. Vous souhaitez récupérer tôt: 3 jours de 1 administrateur système sur le chantier (criminalistique et récupération).
  3. 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.
  4. Vous décidez de ne pas tenter de poursuivre.
  5. Vous pensez que l'attaquant peut utiliser une forme de logiciel (éventuellement sophistiquée) et que ce logiciel fonctionne toujours sur le serveur.

2
Vous voudrez peut-être aussi venir ici: security.stackexchange.com
sysadmin1138


2
@Tom - ce n'est pas une dupe, c'est une discussion d'extension d'un point spécifique de cette question.
mfinni

3
@ sysadmin1138, essayez en particulier security.stackexchange.com/q/181/33
AviD

Réponses:


6

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.


16

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:

  1. Lorsque vous faites de la criminalistique dans un système piraté, vous "faites un pas partout sur la scène du crime"
  2. Le kit racine continue de fonctionner - pas si difficile pour les malicieux d'exécuter quelque chose (par exemple, effacement du système) lors de l' événement Network Link Down .

Kyle Rankin a donné une belle introduction à la criminalistique - là, il recommande de tirer le câble d'alimentation.


+1 pour "franchir la scène du crime". À moins que vous ne sachiez exactement ce que vous faites ou que vous ne vous souciez pas vraiment de recueillir des preuves médico-légales exactes, vous voudrez peut-être appeler les experts plutôt que de polluer les preuves pendant que vous apprenez à faire de la médecine légale ...
dunxd

10

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é.


3
Vous pouvez (et devriez probablement) faire des analyses judiciaires hors ligne (A) via un CD live, (B) en déplaçant le disque dur vers un autre système, ou (C) après avoir pris des images des disques durs affectés (via un CD live) .
Aleksandr Levchuk

3
Souvent, des preuves utiles sont en mémoire. Cela doit être autorisé avant toute perte de puissance est conseillée.
Sirex

Pensez également à déconnecter l'interface LOM par sécurité :)
Kedare

7

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.


+1 pour la VM. Si vous débranchez le réseau, le rootkit continue de fonctionner - pas si difficile pour le malveillant d'exécuter quelque chose (par exemple, effacement du système) lors de l' événement Network Link Down
Aleksandr Levchuk

6
Les instantanés de l'état du système en cours d'exécution sont une si bonne idée que je m'en veux de ne pas y avoir pensé.
jgoldschrafe

@Alexsandr - J'ai essayé de penser à l'exemple réel et je dessine un blanc, mais il me semble me souvenir d'un rootkit qui reste entièrement en mémoire et serait donc perdu lorsque la fiche est retirée. Je pense que c'est dans tous les cas qu'il y a un risque de perdre des preuves.
Rob Moir

6

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.


Si vous débranchez le réseau, le rootkit continue de fonctionner - pas si difficile pour le code malveillant d'exécuter quelque chose (par exemple, effacement du système) lors d'un événement Network Link Down .
Aleksandr Levchuk

C'est certainement vrai, et c'est une chance que vous devez évaluer et décider si vous voulez prendre en fonction de la sensibilité de la situation. Certains rootkits ne résident que dans la mémoire, et si vous coupez l'alimentation du système, vous éliminez toute chance de comprendre comment il y est arrivé. Vous pouvez essayer de bloquer le trafic hors du port du commutateur tout en conservant l'état de la liaison, mais tout rootkit est un logiciel et peut faire tout ce que tout autre logiciel peut faire - rien ne les empêche de sonder la passerelle par défaut et de déclencher la même bombe si elle est inaccessible.
jgoldschrafe

4

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à.


1
Tout d'abord, je pense que l'on devrait décider de poursuivre ou non? . Kyle Rankin dans son discours ( goo.gl/g21Ok ). Commence par en discuter. Pour engager des poursuites, il faudrait fournir des preuves de pertes monétaires substantielles.
Aleksandr Levchuk

1
@Aleksander En général, vous devez savoir très, très tôt dans le processus si vous pouvez ou non réutiliser le matériel et les données compromis ou si vous devrez l'entreposer et construire un nouveau système à partir de pièces entièrement nouvelles. Cela est très probable avant même que vous ayez prouvé des pertes de réputation financière ou commerciale. La préservation de la chaîne de preuves doit se produire au moment où quelqu'un se rend compte qu'un événement potentiellement actionnable s'est produit.
sysadmin1138

Il est souvent préférable de commencer par garder les options ouvertes en cas de poursuite ou non, car vous ne savez peut-être pas s'il existe une perte monétaire.Ainsi, au début, en faisant tout par le livre, il est important de garder la chaîne de possession.
Rory Alsop

3

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.


+1 C'est une des raisons pour lesquelles avoir une passerelle est une bonne idée. Et si vous n'en avez pas? Si vous débranchez le câble réseau direct - le rootkit peut recevoir l' événement Network Link Down . Et la connexion au serveur enraciné et y faire quelque chose le jour 0 n'est-elle pas une mauvaise idée?
Aleksandr Levchuk

2

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


1

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:

  • Laissez le serveur opérationnel ...
  • Isolez-le du reste de votre réseau interne, d'autres serveurs, etc. - mais il est préférable de brancher une sorte de simulation, de sorte qu'il semble connecté.
  • Démarrez tranquillement la criminalistique en temps réel / réseau, exécutez des traces, etc.
  • Essayez de déterminer l'étendue et la durée des dommages (évidemment, c'est différent si cela s'est produit il y a 2 heures ou 2 mois).
  • Continuez à partir de là ... Ce n'est qu'après avoir atténué les dégâts réels , allez-y et nettoyez-le.
  • Bien sûr, n'oubliez pas d'étudier les causes profondes et d'appliquer les contrôles pour vous assurer que cela ne se reproduise plus ...

2
Je pense que cela peut fonctionner dans une situation où vous pouvez rapidement le déplacer vers un environnement simulé / isolé, mais si peu d'organisations peuvent le faire qu'en réalité elles veulent opter pour le côté `` minimiser l'impact '' des choses, donc débrancher l'alimentation ou le réseau est souvent la suppression instantanée de cette menace. (encore + t'a comme je souhaite que ce soit comme ça :-)
Rory Alsop

Le problème @Rory est que vous ne pouvez pas minimiser l'impact, le serveur est déjà alimenté. Vous ne récupérez pas cela, et toutes les données sensibles sont également potentiellement volées, car vous ne savez pas depuis combien de temps elles y ont accès. Cela dit, l'environnement simulé n'est que du givrage, c'est l'isolement qui est important - et je pense que la plupart des organisations ont un pare-feu solide en place, inversez quelques règles d'accès et vous êtes en or. C'est une autre raison pour laquelle les serveurs accessibles devraient être dans une zone démilitarisée - rend cette partie plus facile ....
AviD

En outre, je tiens à préciser quelque chose - ce qui précède s'applique lorsque le système d'exploitation est enraciné . S'il existe une forme de vulnérabilité au niveau de l'application (par exemple, injection SQL) exploitée dans votre site Web, fermez-la ABSOLUMENT et tirez sur tous les câbles sur lesquels vous pouvez mettre la main! Mais la racine du système d'exploitation est différente - ils contrôlent l'ensemble de l'infrastructure de votre machine. Vous n'avez plus aucun contrôle.
AviD

2
non, ce que je voulais dire était de minimiser l'impact au-delà de cette machine enracinée. Je suis d'accord qu'il est totalement perdu, mais à moins que vous ne puissiez l'isoler rapidement, vous n'avez aucun moyen de savoir ce que le contrôleur pourrait faire au reste de vos systèmes
Rory Alsop

0

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é.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.