Comme le système est compromis, rien n'est digne de confiance via des outils. À moins que vous n'ayez les outils validés (par exemple, Tripwire FIM), votre meilleur pari est de prendre un système similaire, de copier ce qui est nécessaire, qui devrait fonctionner si les systèmes sont similaires en architecture, etc. Ce n'est cependant pas la méthode optimale. Étant donné que la machine est compromise, en fonction de vos prochaines étapes (juridiques, autorités, etc.), vous créerez une image médico-légale, puis traiterez ce qui s'est passé lorsque vous aurez votre copie. Une fois que vous avez votre copie, vous devez déterminer le risque associé à la remise en ligne du système, etc.
Si vous avez déterminé comment un attaquant est entré dans le système, vous devrez nettoyer ce "trou" (vulnérabilité, mauvaise configuration) afin d'être sûr qu'il ne revienne pas. Parfois, cela peut prendre plus de temps que d'installer un système propre. Mais disons que vous avez besoin de "ce" système. Vous pouvez réinstaller ps avec quelque chose comme :apt-get install --reinstall procps
il en va de même pour lsof. Vous voudriez vous assurer que vos dépôts n'ont pas été modifiés et que votre DNS ne pointe pas vers un dépôt non approuvé.
Pour l'essentiel pour répondre à votre question :Pouvons-nous faire confiance aux informations affichées par les commandes de l'utilitaire linux la réponse est que vous ne devriez absolument pas. Il ne faut pas faire confiance à ce système jusqu'à ce qu'une analyse approfondie soit effectuée.
Si votre système a été compromis, vous ne devriez pas faire confiance à rien .
Je pense que les utilitaires standard fonctionnent généralement correctement, mais omettent les éléments liés aux processus de l'attaquant. Les rootkits sont conçus de cette façon afin que vous soyez moins susceptible de remarquer que la machine est compromise. Donc je pense que vous pouvez généralement leur faire confiance pour examiner vos propres processus, mais pas pour vous assurer qu'un rootkit a disparu.
Si l'attaquant peut charger des modules du noyau, ou autrement modifier le noyau, même les appels système et /proc
L'API peut mentir. Ainsi, même une copie propre des utilitaires de l'espace utilisateur comme ps
, ou grep foo /proc/*/cmdline
, ne vous dira pas si un processus malveillant est en cours d'exécution. Tout rootkit digne de ce nom cachera ses propres processus.
Chaque fichier sur l'ensemble du système est comme un déchet radioactif , qui peut potentiellement contaminer d'autres choses si vous ne faites pas attention. par exemple. un attaquant pourrait avoir ajouté quelque chose à /home/*/.bashrc
pour réinfecter votre système au cas où vous réinstalleriez le système d'exploitation sans cocher /home
.
De même, il peut y avoir des choses désagréables dans la configuration de votre serveur Web, ou dans vos scripts CGI, etc. Comparez avec les sauvegardes et ne présumez pas que quelque chose est sûr si l'attaquant a pu y toucher.
Effectuez définitivement toutes les vérifications des données non fiables sur une machine connue et propre. Tant que vous n'exécutez rien à partir du système compromis, tout devrait bien se passer. (c'est-à-dire en supposant cmp
et diff
n'ont pas de vulnérabilités. Mais notez que strings
n'est pas sûr sur les fichiers non fiables, selon la version de libbfd
. Utilisez strings -a
.
Probablement, mais pas nécessairement. L'attaquant pourrait toujours remplacer les programmes par leurs propres versions modifiées s'ils disposaient d'un accès root.