Comment détecter et supprimer un cheval de Troie Linux?

J'ai récemment (re) trébuché sur ceci:

  • Le cheval de Troie Linux passe inaperçu pendant près d'un an (Unreal IRCd)

Oui, je sais que l'ajout d'un PPA / logiciel random provenant d'une source non fiable request des problèmes (ou pire). Je ne le fais jamais, mais beaucoup le font (beaucoup de blogs Linux et de tabloïds favorisent l'ajout de PPA pour les applications fantaisistes, sans prévenir que cela pourrait briser votre système ou, pire encore, compromettre votre security).

Comment un cheval de Troie ou une application / script non fiable peut-il être détecté et supprimé?

Il n'y a pas de recette générale. Si votre système a été infecté par un cheval de Troie inconnu, tout ce que vous pouvez faire est de réinstaller.

Si vous savez que le cheval de Troie fonctionne d'une certaine manière – par exemple, vous savez que le cheval de Troie n'infecte pas le kernel – il peut y avoir un moyen less dur de récupérer. Mais cela dépend entièrement de savoir comment le cheval de Troie se comporte. Si tout ce que vous avez est les symptômes (comme l'envoi de spam par votre ordinateur sans votre consentement), il n'y a pas de technique générale: le détecteur de Troie doit être plus intelligent que le concepteur de Trojan (et chanceux). En ce qui concerne les chevaux de Troie, la détection et la dissimulation sont comme des armes et des armures: il y a une escalade technologique et aucune des parties n'a un avantage insortingnsèque (bien que les hiders aient une longueur d'avance).

De nombreux systèmes disposent d'un canal de dissortingbution sécurisé. Par exemple, lorsque vous installez un package à partir des référentiels Ubuntu avec les outils apt (apt-get, aptitude, synaptic, centre logiciel, …), l'outil vérifie que le package est signé par quelqu'un d'autre Ubuntu. (La plupart des dissortingbutions ont un mécanisme similaire.) Lorsque vous installez un package à partir d'un PPA, tout ce que vous pouvez savoir, c'est que le propriétaire du PPA a vérifié le package, ce qui n'aide pas si vous n'avez aucune raison de faire confiance au propriétaire du PPA.

À propos des chevaux de Troie et des portes dérobées, je vous recommand fortement de lire la conférence de Ken Thompson sur le prix Turing, Reflections on Trusting Trust . Pour résumer, il a changé le compilateur de sorte que lors de la compilation du programme de connection, il ajoutait du code lui permettant de se connecter avec un mot de passe secret; puis il a changé le compilateur de sorte que quand il s'est compilé, il insèrerait le code pour append la porte dérobée; puis il a recompilé l'set du système (en particulier le programme de connection et le compilateur); il a finalement restauré la source du compilateur à la source originale et incontestable. Encore une fois, lisez l'article de Ken Thompson ; alors vous pouvez aussi lire le contresharepoint David Wheeler , peut-être mieux appréhendé à travers l' article de blog de Bruce Schneier .

Si je comprends bien "trojan" décrit dans cet article n'a pas pu être découvert de façon "normale" comme un malware "normal". Cet IRCd se comportait normalement jusqu'à ce qu'il soit utilisé, donc l'administrateur ne pouvait find ce trou de security que lorsque: 1) il était utilisé et l'action effectuée par ce trou provoquait l'input dans les journaux ou était visible d'une autre manière; 2) lecture du code source.

Les logiciels malveillants Linux «réels» devraient également être détectés par les logiciels AV pour les disques de sauvetage LiveCD ou Linux LiveCD, afin de pouvoir parsingr l'ordinateur à l'aide de ce logiciel. Comme vous pouvez le voir dans SecureList dans la list, il y a 1941 inputs avec Linux dans le nom et ce logiciel devrait être détecté par le logiciel de Kaspersky. Un rapide coup d'œil à cette list montre que de nombreuses inputs concernent des outils DDoS, des exploits ou des outils qui ne peuvent pas se propager automatiquement et qui ne peuvent être utilisés que comme outils d'attaque.

Pour vérifier les backdoors / rootkits installés par cracker, vous pouvez utiliser un outil qui vérifie les sums de contrôle des files (vous devez générer la list des files et des sums de contrôle sur le système propre et le mettre à jour après la mise à jour du logiciel du server). Chaque nouveau file ou file avec une sum de contrôle erronée est suspect. La list de contrôle et l'outil qui le génèrent devraient être en lecture seule (le cracker pourrait aussi changer par exemple md5sum pour sa propre version qui affiche des sums de contrôle erronées). Cette façon de find des logiciels malveillants pourrait être utilisée sur des systèmes «stables» où le logiciel n'est pas mis à niveau tous les jours.

Certains logiciels malveillants peuvent être détectés en exécutant netstat localement pour vérifier le trafic réseau, mais si le système est infecté, datatables netstat par netstat peuvent également être modifiées. Dans ce cas, une solution consiste à surveiller le trafic réseau d'un autre ordinateur (par exemple, du routeur, pour vérifier quel trafic est envoyé à Internet).

SELinux et AppArmor existent pour la prévention de Trojan / rootkit et d'autres infections. Je parle de SELinux, que je connais mieux. Avec SELinux activé, vous donnez un context à tous les process (daemon inclus) que vous installez sur la machine. Vous étiquetez également le système de files pour qu'il fonctionne avec le context, en les associant. Lorsqu'un process tente de faire quelque chose qui n'est pas dans son context, vous recevez un message et, si SELinux est en mode d'application, l'action ne peut pas être terminée.
De cette façon, si votre cheval de Troie ircd était prêt à écraser la command ps ou quelque chose d'autre (stratégie commune pour les chevaux de Troie / rootkits / vers pour éviter la détection), je ne serais pas autorisé à le faire. Et vous seriez informé.
Je sais que c'est difficile à configurer, mais mes machines fonctionnent avec SELinux en ce moment, et mes deux ordinateurs portables Fedora peuvent faire tout ce dont un bureau a besoin sans trop de soucis.
Même mon server domestique est maintenant en mode d'application.
Une autre stratégie consiste à exécuter régulièrement des détecteurs de rootkit qui calculent une sum de contrôle pour les commands cirtical et vous informent des modifications apscopes aux commands de base.
Je travaille avec SELinux et le rkhunter activé (plus un antivirus clamav).

Cordialement

Une autre réponse affirmait que les «hiders» (furtivité) avaient un avantage insortingnsèque par rapport aux «détecteurs». Je ne suis pas d'accord. Cela est vrai si vous vous limitez à des approches de détection reposant sur des signatures ou des heuristiques pour la détection de logiciels malveillants. Mais il existe un autre moyen de détecter les logiciels malveillants: vérifier les produits connus. Tripwire, AIDE, etc. peuvent vérifier les files sur le disque. Second Look peut vérifier le kernel et les process en cours d'exécution. Second Look utilise la médecine légale pour inspecter directement le operating system, les services actifs et les applications. Il compare le code en memory à ce qui a été publié par le fournisseur de dissortingbution Linux. De cette façon, il peut immédiatement détecter les modifications malveillantes faites par les rootkits et les portes dérobées, ainsi que les programmes non autorisés qui s'exécutent (chevaux de Troie, etc.).

(Divulgation: Je suis le développeur principal de Second Look.)