Les virus dans GNU / Linux: fait ou mythe?

Chaque fois que le débat est terminé virus y GNU / Linux il ne faut pas longtemps à l'utilisateur pour apparaître (généralement Windows) que dés:

«Sous Linux, il n'y a pas de virus car les créateurs de ces programmes malveillants ne perdent pas de temps à faire quelque chose pour un système d'exploitation que presque personne n'utilise »

À quoi j'ai toujours répondu:

"Le problème n'est pas cela, mais les créateurs de ces programmes malveillants ne perdront pas de temps à créer quelque chose qui sera corrigé avec la première mise à jour du système, même en moins de 24 heures"

Et je ne me suis pas trompé, car cet excellent article publié dans le Numéro 90 (Année 2008) par Todo Linux Magazine. Son acteur david santo orcero nous fournit de manière technique (mais facile à comprendre) l'explication de pourquoi GNU / Linux manque ce type de logiciel malveillant.

100% recommandé. Désormais, ils auront plus que du matériel convaincant pour faire taire quiconque s'exprime sans une base solide sur ce sujet.

Télécharger l'article (PDF): Mythes et faits: Linux et les virus

ÉDITÉ:

Voici l'article transcrit, car nous considérons qu'il est beaucoup plus confortable à lire de cette manière:

=============================================== =======================

Le débat sur Linux et les virus n'est pas nouveau. De temps en temps, nous voyons un e-mail sur une liste demandant s'il existe des virus pour Linux; et automatiquement quelqu'un répond par l'affirmative et prétend que s'ils ne sont pas plus populaires, c'est parce que Linux n'est pas aussi répandu que Windows. Il existe également de fréquents communiqués de presse de développeurs d'antivirus indiquant qu'ils publient des versions de virus Linux.

Personnellement, j'ai eu des discussions occasionnelles avec différentes personnes par mail, ou par liste de distribution, concernant la question de savoir si des virus existent ou non sous Linux. c'est un mythe, mais il est complexe de démolir un mythe ou plutôt un canular, surtout s'il est causé par l'intérêt économique. Quelqu'un est intéressé à transmettre l'idée que si Linux n'a pas ce genre de problèmes, c'est parce que très peu de gens l'utilisent.

Au moment de publier ce rapport, j'aurais aimé rédiger un texte définitif sur l'existence de virus sous Linux. Malheureusement, lorsque la superstition et l'intérêt économique sont endémiques, il est difficile de construire quelque chose de définitif.
Cependant, nous essaierons de présenter ici un argument raisonnablement complet pour désarmer les attaques de quiconque veut le faire valoir.

Qu'est-ce qu'un virus?

Tout d'abord, nous allons commencer par définir ce qu'est un virus. Il s'agit d'un programme qui se copie et s'exécute automatiquement, et qui vise à modifier le fonctionnement normal d'un ordinateur, sans l'autorisation ou la connaissance de l'utilisateur. Pour ce faire, les virus remplacent les fichiers exécutables par d'autres infectés par leur code. La définition est standard et est un résumé en une ligne de l'entrée Wikipédia sur les virus.
La partie la plus importante de cette définition, et celle qui différencie le virus des autres logiciels malveillants, est qu'un virus s'installe, sans l'autorisation ni la connaissance de l'utilisateur. s'il ne s'installe pas, ce n'est pas un virus: il peut s'agir d'un rootkit, ou d'un cheval de Troie.

Un rootkit est un correctif du noyau qui vous permet de masquer certains processus des utilitaires de la zone utilisateur. En d'autres termes, il s'agit d'une modification du code source du noyau dont le but est que les utilitaires qui nous permettent de voir ce qui est en cours d'exécution à un moment donné n'affichent pas un certain processus, ou un certain utilisateur.

Un cheval de Troie est analogue: il s'agit d'une modification du code source d'un service spécifique pour masquer certaines activités frauduleuses. Dans les deux cas, il est nécessaire d'obtenir le code source de la version exacte installée sur la machine Linux, de corriger le code, de le recompiler, d'obtenir les privilèges d'administrateur, d'installer l'exécutable corrigé et d'initialiser le service - dans le cas du cheval de Troie - ou le système d'exploitation. complet - dans le cas de
rootkit–. Le processus, comme nous le voyons, n'est pas anodin, et personne ne peut faire tout cela "par erreur". Les deux exigent dans leur installation qu'une personne disposant des privilèges d'administrateur, consciemment, exécute une série d'étapes pour prendre des décisions de nature technique.

Ce qui n'est pas une nuance sémantique sans importance: pour qu'un virus s'installe, tout ce que nous avons à faire est d'exécuter un programme infecté en tant qu'utilisateur commun. D'autre part, pour l'installation d'un rootkit ou d'un cheval de Troie, il est essentiel qu'un humain malveillant entre personnellement dans le compte racine d'une machine et, de manière non automatisée, effectue une série d'étapes potentiellement détectables. un virus se propage rapidement et efficacement; un rootkit ou un cheval de Troie en a besoin pour nous poursuivre spécifiquement.

Transmission de virus sous Linux:

Le mécanisme de transmission d'un virus est donc ce qui le définit réellement en tant que tel et constitue la base de leur existence. un système d'exploitation est plus sensible aux virus, plus il est facile de développer un mécanisme de transmission efficace et automatisé.

Supposons que nous ayons un virus qui veut se propager. Supposons qu'il ait été lancé par un utilisateur normal, innocemment, lors du lancement d'un programme. Ce virus a exclusivement deux mécanismes de transmission:

• Se répliquer en touchant la mémoire d'autres processus, en s'ancrant sur eux lors de l'exécution.
• Ouverture des exécutables du système de fichiers et ajout de leur code –payload– à l'exécutable.

Tous les virus que l'on peut considérer comme tels possèdent au moins un de ces deux mécanismes de transmission. O les deux. Il n'y a plus de mécanismes.
En ce qui concerne le premier mécanisme, rappelons-nous l'architecture de mémoire virtuelle de Linux et le fonctionnement des processeurs Intel. Ceux-ci ont quatre anneaux, numérotés de 0 à 3; plus le nombre est bas, plus les privilèges du code qui s'exécute dans cet anneau sont élevés. Ces anneaux correspondent aux états du processeur et, par conséquent, à ce qui peut être fait avec un système se trouvant dans un anneau spécifique. Linux utilise l'anneau 0 pour le noyau et l'anneau 3 pour les processus. il n'y a pas de code de processus qui s'exécute sur l'anneau 0, et il n'y a pas de code de noyau qui s'exécute sur l'anneau 3. Il n'y a qu'un seul point d'entrée vers le noyau à partir de l'anneau 3: l'interruption 80h, qui permet de sauter de la zone où il se trouve le code utilisateur de la zone où se trouve le code du noyau.

L'architecture d'Unix en général et de Linux en particulier ne rend pas possible la propagation de virus.

Le noyau utilisant la mémoire virtuelle fait croire à chaque processus qu'il a toute la mémoire pour lui-même. Un processus - qui fonctionne dans l'anneau 3 - ne peut voir que la mémoire virtuelle qui a été configurée pour lui, pour l'anneau dans lequel il opère. Ce n'est pas que la mémoire des autres processus soit protégée; est que pour un processus, la mémoire des autres est en dehors de l'espace d'adressage. Si un processus battait toutes les adresses mémoire, il ne serait même pas en mesure de référencer une adresse mémoire d'un autre processus.

Pourquoi cela ne peut-il pas être triché?
Modifier ce qui a été commenté - par exemple, générer des points d'entrée dans l'anneau 0, modifier les vecteurs d'interruption, modifier la mémoire virtuelle, modifier LGDT… - cela n'est possible qu'à partir de l'anneau 0.
Autrement dit, pour qu'un processus puisse toucher la mémoire d'autres processus ou le noyau, il doit être le noyau lui-même. Et le fait qu'il y ait un point d'entrée unique et que les paramètres soient passés par les registres complique le piège - en fait, ce qui doit être fait est passé par registre, qui est ensuite implémenté comme un cas dans la routine d'attention. l'interruption de 80h.
Un autre scénario est le cas des systèmes d'exploitation avec des centaines d'appels non documentés pour sonner 0, où cela est possible - il peut toujours y avoir un appel oublié mal implémenté sur lequel un trap peut être développé - mais dans le cas d'un système d'exploitation avec un mécanisme à pas si simple, ce n’est pas le cas.

Pour cette raison, l'architecture de mémoire virtuelle empêche ce mécanisme de transmission; aucun processus - pas même ceux qui ont des privilèges root - n'a un moyen d'accéder à la mémoire des autres. Nous pourrions argumenter qu'un processus peut voir le noyau; il l'a mappé à partir de son adresse de mémoire logique 0xC0000000. Mais, en raison de l'anneau de processeur sur lequel il s'exécute, vous ne pouvez pas le modifier; générerait un piège, car ce sont des zones de mémoire appartenant à un autre anneau.

La "solution" serait un programme qui modifie le code du noyau lorsqu'il s'agit d'un fichier. Mais le fait que ceux-ci soient recompilés le rend impossible. Le binaire ne peut pas être patché, car il existe des millions de noyaux binaires différents dans le monde. Simplement que lors de la recompilation, ils avaient mis ou supprimé quelque chose de l'exécutable du noyau, ou ils avaient changé la taille de certaines des étiquettes qui identifient la version de compilation - ce qui est fait même involontairement - le patch binaire ne pouvait pas être appliqué. L'alternative serait de télécharger le code source sur Internet, de le corriger, de le configurer pour le matériel approprié, de le compiler, de l'installer et de redémarrer la machine. Tout cela devrait être fait par un programme, automatiquement. Tout un défi pour le domaine de l'intelligence artificielle.
Comme nous pouvons le voir, même un virus en tant que root ne peut franchir cette barrière. La seule solution qui reste est la transmission entre fichiers exécutables. Ce qui ne fonctionne pas non plus comme nous le verrons ci-dessous.

Mon expérience en tant qu'administrateur:

Depuis plus de dix ans que je gère Linux, avec des installations sur des centaines de machines dans des data centers, des laboratoires étudiants, des entreprises, etc.

• Je n'ai jamais attrapé de virus
• Je n'ai jamais rencontré quelqu'un qui a
• Je n'ai jamais rencontré quelqu'un qui a rencontré quelqu'un qui a

Je connais plus de gens qui ont vu le monstre du Loch Ness que de virus Linux.
Personnellement, j'avoue avoir été imprudent, et j'ai lancé plusieurs programmes que les «spécialistes» autoproclamés appellent «virus pour Linux» - désormais, je les appellerai virus, pour ne pas rendre le texte pédant -, de mon récit habituel contre ma machine, pour voir si un virus est possible: à la fois le virus bash qui y circule - et qui, d'ailleurs, n'a infecté aucun fichier - et un virus qui est devenu très célèbre, et est apparu dans la presse . J'ai essayé de l'installer; et après vingt minutes de travail, j'ai abandonné quand j'ai vu qu'une de ses demandes était d'avoir le répertoire tmp sur une partition de type MSDOS. Personnellement, je ne connais personne qui crée une partition spécifique pour tmp et la formate en FAT.
En fait, certains soi-disant virus que j'ai testés pour Linux nécessitent un haut niveau de connaissances et le mot de passe root pour être installés. Nous pourrions au moins qualifier de virus "merdique" s'il a besoin de notre intervention active pour infecter la machine. De plus, dans certains cas, ils nécessitent une connaissance approfondie d'UNIX et du mot de passe root; ce qui est assez éloigné de l'installation automatique qu'il est censé être.

Infecter des exécutables sous Linux:

Sous Linux, un processus peut simplement faire ce que son utilisateur effectif et son groupe efficace lui permettent. Il est vrai qu'il existe des mécanismes pour échanger le véritable utilisateur contre de l'argent, mais rien d'autre. Si nous regardons où se trouvent les exécutables, nous verrons que seul root a les privilèges d'écriture à la fois dans ces répertoires et dans les fichiers contenus. En d'autres termes, seul root peut modifier ces fichiers. C'est le cas sous Unix depuis les années 70, sous Linux depuis ses origines, et dans un système de fichiers qui supporte les privilèges, aucune erreur n'est encore apparue qui autorise d'autres comportements. La structure des fichiers exécutables ELF est connue et bien documentée, il est donc techniquement possible pour un fichier de ce type de charger la charge utile dans un autre fichier ELF ... tant que l'utilisateur effectif du premier ou le groupe effectif du premier dispose des privilèges d'accès. lecture, écriture et exécution sur le deuxième fichier. Combien d'exécutables du système de fichiers pourrait-il infecter en tant qu'utilisateur commun?
Cette question a une réponse simple, si nous voulons savoir combien de fichiers nous pourrions "infecter", nous lançons la commande:

$ find / -type f -perm -o=rwx -o \( -perm -g=rwx -group `id -g` \) -o \( -perm -u=rwx -user `id -u` \) -print 2> /dev/null | grep -v /proc

Nous excluons le répertoire / proc car il s'agit d'un système de fichiers virtuel qui affiche des informations sur le fonctionnement du système d'exploitation. Les fichiers de type fichier avec des privilèges d'exécution que nous trouverons ne posent pas de problème, car ce sont souvent des liens virtuels qui semblent être lus, écrits et exécutés, et si un utilisateur l'essaie, cela ne fonctionne jamais. Nous excluons également les erreurs, abondantes - car, en particulier dans / proc et / home, il existe de nombreux répertoires dans lesquels un utilisateur ordinaire ne peut pas entrer - Ce script prend beaucoup de temps. Dans notre cas particulier, dans une machine où travaillent quatre personnes, la réponse était:

/tmp/.ICE-unix/dcop52651205225188
/tmp/.ICE-unix/5279
/home/irbis/kradview-1.2/src
/kradview

La sortie montre trois fichiers qui pourraient être infectés si un virus hypothétique était exécuté. Les deux premiers sont des fichiers de type socket Unix qui sont supprimés au démarrage - et ne peuvent pas être affectés par un virus -, et le troisième est un fichier d'un programme de développement, qui est supprimé à chaque recompilation. Le virus, d'un point de vue pratique, ne se propagerait pas.
D'après ce que nous voyons, le seul moyen de répartir la charge utile est d'être root. Dans ce cas, pour qu'un virus fonctionne, les utilisateurs doivent toujours disposer des privilèges d'administrateur. Dans ce cas, il peut infecter des fichiers. Mais voici le problème: pour transmettre l'infection, vous devez prendre un autre exécutable, l'envoyer par courrier électronique à un autre utilisateur qui n'utilise la machine qu'en tant que root, et répéter le processus.
Dans les systèmes d'exploitation où il est nécessaire d'être administrateur pour des tâches courantes ou d'exécuter de nombreuses applications quotidiennes, cela peut être le cas. Mais sous Unix, il est nécessaire d'être administrateur pour configurer la machine et modifier les fichiers de configuration, de sorte que le nombre d'utilisateurs que le compte root utilise comme compte quotidien est petit. C'est plus; certaines distributions Linux n'ont même pas le compte root activé. Dans presque tous, si vous accédez à l'environnement graphique en tant que tel, l'arrière-plan devient rouge intense et des messages constants sont répétés pour vous rappeler que ce compte ne doit pas être utilisé.
Enfin, tout ce qui doit être fait en tant que root peut être fait avec une commande sudo sans risque.
Pour cette raison, sous Linux, un exécutable ne peut pas infecter les autres tant que nous n'utilisons pas le compte root comme compte d'utilisation courante; Et bien que les sociétés d'antivirus insistent pour dire qu'il existe des virus pour Linux, la chose la plus proche qui peut être créée sous Linux est un cheval de Troie dans la zone utilisateur. La seule façon dont ces chevaux de Troie peuvent affecter quelque chose sur le système est de l'exécuter en tant que root et avec les privilèges nécessaires. Si nous utilisons généralement la machine comme des utilisateurs ordinaires, il n'est pas possible qu'un processus lancé par un utilisateur commun infecte le système.

Mythes et mensonges:

Nous avons trouvé beaucoup de mythes, de canulars et de simples mensonges sur les virus sous Linux. Faisons une liste d'entre eux sur la base d'une discussion qui a eu lieu il y a quelque temps avec un représentant d'un fabricant d'antivirus pour Linux qui a été très offensé par un article publié dans ce même magazine.
Cette discussion est un bon exemple de référence, car elle touche à tous les aspects des virus sous Linux. Nous allons passer en revue tous ces mythes un par un tels qu'ils ont été discutés dans cette discussion spécifique, mais qui a été répété tant de fois dans d'autres forums.

Mythe 1:
"Tous les programmes malveillants, en particulier les virus, n'ont pas besoin de privilèges root pour infecter, en particulier dans le cas particulier des virus exécutables (format ELF) qui infectent d'autres exécutables ».

Réponse:
Quiconque fait une telle réclamation ne sait pas comment fonctionne le système de privilèges Unix. Pour affecter un fichier, un virus a besoin du privilège de lecture - il doit être lu pour le modifier - et d'écriture - il doit être écrit pour que la modification soit valide - sur le fichier exécutable qu'il veut exécuter.
C'est toujours le cas, sans exception. Et dans chacune des distributions, les utilisateurs non root n'ont pas ces privilèges. Alors simplement sans être root, l'infection n'est pas possible. Test empirique: Dans la section précédente, nous avons vu un script simple pour vérifier la gamme de fichiers qui peuvent être affectés par une infection. Si nous le lançons sur notre machine, nous verrons en quoi il est négligeable, et par rapport aux fichiers système, nul. En outre, contrairement aux systèmes d'exploitation tels que Windows, vous n'avez pas besoin de privilèges d'administrateur pour effectuer des tâches courantes avec les programmes couramment utilisés par les utilisateurs normaux.

Mythe 2:
"Ils n'ont pas non plus besoin d'être root pour entrer dans le système à distance, dans le cas de Slapper, un ver qui, exploitant une vulnérabilité dans le SSL d'Apache (les certificats qui permettent une communication sécurisée), a créé son propre réseau de machines zombies en septembre 2002 ».

Réponse:
Cet exemple ne fait pas référence à un virus, mais à un ver. La différence est très importante: un ver est un programme qui exploite un service pour qu'Internet se transmette. Cela n'affecte pas les programmes locaux. Par conséquent, cela n'affecte que les serveurs; pas à des machines particulières.
Les vers ont toujours été très peu nombreux et d'incidence négligeable. Les trois vraiment importants sont nés dans les années 80, une époque où Internet était innocent, et tout le monde faisait confiance à tout le monde. Rappelons-nous que ce sont eux qui ont affecté sendmail, fingerd et rexec. Aujourd'hui, les choses sont plus compliquées. Bien que nous ne puissions pas nier qu’ils demeurent et que, s’ils ne sont pas contrôlés, ils sont extrêmement dangereux. Mais maintenant, les temps de réaction aux vers sont très courts. C'est le cas du Slapper: un ver créé sur une vulnérabilité découverte - et corrigée - deux mois avant l'apparition du ver lui-même.
Même en supposant que tout le monde utilisant Linux avait installé et exécuté Apache tout le temps, la simple mise à jour mensuelle des packages aurait été plus que suffisante pour ne jamais courir aucun risque.
Il est vrai que le bogue SSL causé par Slapper était critique - en fait, le plus gros bogue trouvé dans toute l'histoire de SSL2 et SSL3 - et en tant que tel, il a été corrigé en quelques heures. Que deux mois après que ce problème ait été trouvé et résolu, quelqu'un a fait un ver sur un bug qui a déjà été corrigé, et que c'est l'exemple le plus puissant que l'on puisse donner comme vulnérabilité, du moins cela rassure.
En règle générale, la solution aux vers n'est pas d'acheter un antivirus, de l'installer et de perdre du temps informatique à le garder résident. La solution est d'utiliser le système de mise à jour de sécurité de notre distribution: une fois la distribution mise à jour, il n'y aura aucun problème. Exécuter uniquement les services dont nous avons besoin est également une bonne idée pour deux raisons: nous améliorons l'utilisation des ressources et nous évitons les problèmes de sécurité.

Mythe 3:
"Je ne pense pas que le noyau soit invulnérable. En fait, il existe un groupe de programmes malveillants appelés LRK (Linux Rootkits Kernel), qui sont précisément basés sur le fait qu'ils exploitent les vulnérabilités des modules du noyau et remplacent les binaires du système. ».

Réponse:
Un rootkit est fondamentalement un patch du noyau qui vous permet de cacher l'existence de certains utilisateurs et processus aux outils habituels, grâce au fait qu'ils n'apparaîtront pas dans le répertoire / proc. La chose normale est qu'ils l'utilisent à la fin d'une attaque, en premier lieu, ils exploiteront une vulnérabilité distante pour accéder à notre machine. Ensuite, ils entreprendront une séquence d'attaques, pour élever les privilèges jusqu'à ce qu'ils aient le compte root. Le problème quand ils l'obtiennent est de savoir comment installer un service sur notre machine sans être détecté: c'est là que le rootkit entre en jeu. Un utilisateur est créé qui sera l'utilisateur effectif du service que nous voulons cacher, ils installent le rootkit, et ils cachent à la fois ledit utilisateur et tous les processus appartenant audit utilisateur.
Comment cacher l'existence d'un utilisateur est utile à un virus est quelque chose dont nous pourrions discuter longuement, mais un virus qui utilise un rootkit pour s'installer semble amusant. Imaginons la mécanique du virus (en pseudocode):
1) Le virus pénètre dans le système.
2) Localisez le code source du noyau. Si ce n'est pas le cas, il l'installe lui-même.
3) Configurez le noyau pour les options matérielles qui s'appliquent à la machine en question.
4) Compilez le noyau.
5) Installez le nouveau noyau; modifier LILO ou GRUB si nécessaire.
6) Redémarrez la machine.

Les étapes (5) et (6) nécessitent des privilèges root. Il est quelque peu compliqué que les étapes (4) et (6) ne soient pas détectées par les personnes infectées. Mais ce qui est amusant, c'est qu'il y a quelqu'un qui croit qu'il existe un programme qui peut exécuter automatiquement les étapes (2) et (3).
En guise de point culminant, si nous rencontrons quelqu'un qui nous dit "quand il y aura plus de machines Linux, il y aura plus de virus", et nous recommande "d'avoir un antivirus installé et de le mettre constamment à jour", cela peut être lié à l'entreprise qui vend l'antivirus et les mises à jour. Soyez méfiant, peut-être le même propriétaire.

Antivirus pour Linux:

Il est vrai qu'il existe de bons antivirus pour Linux. Le problème est qu'ils ne font pas ce que soutiennent les défenseurs des antivirus. Sa fonction est de filtrer le courrier qui passe des malwares et virus à Windows, ainsi que de vérifier l'existence de virus Windows dans les dossiers exportés via SAMBA; donc si nous utilisons notre machine comme passerelle de messagerie ou comme NAS pour les machines Windows, nous pouvons les protéger.

Palourde-AV :

Nous ne terminerons pas notre rapport sans parler du principal antivirus pour GNU / Linux: ClamAV.
ClamAV est un antivirus GPL très puissant qui se compile pour la plupart des Unix disponibles sur le marché. Il est conçu pour analyser les pièces jointes aux messages électroniques passant par la station et les filtrer pour les virus.
Cette application s'intègre parfaitement à sendmail pour permettre le filtrage des virus qui peuvent être stockés dans les serveurs Linux qui fournissent du courrier aux entreprises; avoir une base de données virale mise à jour quotidiennement, avec un support numérique. La base de données est mise à jour plusieurs fois par jour, et c'est un projet vivant et très intéressant.
Ce programme puissant est capable d'analyser les virus même dans les pièces jointes dans des formats plus complexes à ouvrir, tels que RAR (2.0), Zip, Gzip, Bzip2, Tar, MS OLE2, les fichiers MS Cabinet, MS CHM (HTML COprinted) et MS SZDD.
ClamAV prend également en charge les fichiers courrier au format mbox, Maildir et RAW, ainsi que les fichiers exécutables portables compressés avec UPX, FSG et Petite. La paire Clam AV et spamassassin est la paire parfaite pour protéger nos clients Windows des serveurs de messagerie Unix.

CONCLUSION

À la question Existe-t-il des vulnérabilités dans les systèmes Linux? la réponse est certainement oui.
Personne de sensé n'en doute; Linux n'est pas OpenBSD. Une autre chose est la fenêtre de vulnérabilité d'un système Linux qui est correctement mise à jour. Si nous nous posons la question, existe-t-il des outils pour tirer parti de ces failles de sécurité et les exploiter? Eh bien, oui, mais ce ne sont pas des virus, ce sont des exploits.

Le virus doit surmonter plusieurs difficultés supplémentaires qui ont toujours été présentées comme une faille / problème Linux par les défenseurs de Windows, et qui compliquent l'existence de vrais virus - des noyaux qui sont recompilés, de nombreuses versions de nombreuses applications, de nombreuses distributions, des choses qui ils ne sont pas automatiquement transmis de manière transparente à l'utilisateur, etc.–. Les "virus" théoriques actuels doivent être installés manuellement à partir du compte root. Mais cela ne peut pas être considéré comme un virus.
Comme je le dis toujours à mes élèves: ne me croyez pas, s'il vous plaît. Téléchargez et installez un rootkit sur la machine. Et si vous en voulez plus, lisez le code source des "virus" du marché. La vérité est dans le code source. Il est difficile pour un virus "auto-proclamé" de continuer à le nommer ainsi après avoir lu son code. Et si vous ne savez pas lire le code, une seule mesure de sécurité simple que je recommande: n'utilisez le compte root que pour administrer la machine, et maintenez les mises à jour de sécurité à jour.
Avec cela seul, il est impossible que des virus vous pénètrent et il est très peu probable que des vers ou quelqu'un attaquent avec succès votre machine.