Depuis un certain temps, je lis un peu partout que les virus mail sont l'apanage de Windows et que si tout le monde utilisait Linux, il n'y aurait plus de problème.
Est-ce aussi vrai que ça ?
J'ai tapé quelques réflexions sur le sujet dans un texte en pièce jointe.
Note du modérateur: Cliquez sur le nombre de commentaire pour lire la suite.
Linux est-il à l'abri des virus ?
Depuis un certain temps, je lis un peu partout que les virus mail sont l'apanage de Windows et que si tout le monde utilisait Linux, il n'y aurait plus de problème.
Voyons voir de plus prêt les caractéristiques d'un virus mail :
- La propagation
- Les dégats
- 1 - La propagation
Sous Windows, Outlook est le client mail le plus utilisé. Il utilise l'API Microsoft de messagerie, MAPI, qui permet d'envoyer des messages et de travailler avec le carnet d'adresse. Cette API est accessible depuis quasiment tous les langages de programmation : depuis le C jusqu'au VBS. Cette API avait (à mon avis) pour but de permettre à n'importe quel logiciel d'envoyer facilement des messages en utilisant les informations déjà saisies dans Outlook (Par exemple Word propose un menu "Envoyer ce document"). Le problème est que Microsoft n'avait pas pévu qu'elle serait utilisée à des fins moins avouables... (Souvenez-vous de "I Love You").
Envoyer des mails c'est bien, mais encore faut-il avoir des cibles, c'est à dire accéder au carnet d'adresse. Là, Outlook est victime de son succès : tout le monde utilisant le même client mail, tout le monde stocke ses adresses de la même façon et comme l'accès à ce carnet d'adresse par MAPI est facile et incontrôlable, point de salut.
Quand est-il sous Linux ? Envoyer des mails par programmation n'est pas bien difficile : je ne l'ai jamais fait mais je sais que c'est possible avec un simple script shell.
En ce qui concerne le carnet d'adresse, pour le moment aucun client mail ne semble être leader incontesté, donc il n'y a pas de façon simple d'y accéder, mais si on imagine un monde où Linux aurait pris la place de Windows, il est fort possible d'imaginer qu'un client mail se démarque du lot et devienne utilisé par 95% des gens.
Je prends l'exemple de KMail car c'est le client mail que j'utilise. Si j'ouvre le fichier ~/.kde/share/apps/kmail/addressbook... quelle surprise, mon carnet d'adresse en clair ! Ca va pas être très dur de l'exploiter...
- 2 - Les dégats
Pour un virus, se diffuser c'est bien, foutre un peu la zone c'est mieux...
Sous Windows, comme chacun le sait, tout le monde il est gentil, tout le monde il est bô, donc tout le monde il est root. Ce qui signifie qu'un virus malfaisant (Pléonasme ?) pourra s'attaquer au système et aux données de tous les utilisateurs de la machine.
Sous Linux, nous sommes un peu mieux loti, mais pas trop : Je ne parle pas du cas de l'utilisateur qui travaille tout le temps en tant que root, s'il lui arrive un pépin, il l'aura bien cherché...
Dans le cas d'un virus exécuté par l'utilisateur normal, il ne pourra s'attaquer ni au système, ni aux données des autres utilisateurs... par contre en ce qui concerne les données de l'utilisateur... il pourra faire ce qu'il veut. Si le fait de protéger le système et les données des autres est déjà un pas en avant très important (Je suis bien content qu'un virus ne puisse pas détruire mon /etc/X11/XF86Config que j'ai mis au point avec amour), la sécurité ne me semble pas encore suffisante.
Prenons le cas d'une utilisation en entreprise : de la secrétaire qui utilise un traîtement de texte, au chef de projet qui travaille sur son outil de planning en passant par l'ingénieur en génie mécanique qui fait du dessin industriel, la perte du système d'exploitation constitue certe une nuisance, mais après appel du service informatique, tout rentre dans l'ordre (normalement :o). Par contre, la perte de documents produits par ces personnes est catastrophique. On peut toujours récupérer une sauvegarde, mais perdre une journée de boulot reste grave. Rappelez vous ce slogan (de Packard-Bell je crois, corrigez-moi si je me trompe) : "L'important ce n'est pas ce que l'ordinateur peut faire, c'est ce que vous pouvez en faire".
Quelles solutions alors ?
Je ne suis pas (du tout) expert en sécurité, mais voici quand même quelques idées :
La plus simple à mettre en oeuvre serait d'avoir deux comptes : un compte internet et un compte de travail. Le compte de travail ayant accès aux fichiers du compte internet, mais pas l'inverse. Cette solution me paraît efficace, mais reste contraignante.
L'autre solution serait un système proche de celui des applets Java : une applet Java non signée n'a pas le droit d'accéder aux disques ou aux périphériques de la machine qu l'exécute. On pourrait donc imaginer que le client mail permettrait isolerait l'exécution de pièces jointes dans un "linux virtuel" qui ne donnerait accès à aucune donnée sensible. Il me semble avoir déjà entendu parler de systèmes de ce genre (linux on linux) mais je n'ai aucune idée des difficultés d'implémentations...
Et vous, qu'en pensez-vous ?
Linux est-il à l'abri des virus ?
2
déc.
2000
# ...
Posté par Anonyme . Évalué à 1.
Executer un script contenu dans un fichier joint ?
Si l'auteur l'execute, ça parait evidemment qu'il doit en assumer les conséquences... De même que s'il tape rm -rf ~/ ...
Je pense que la parade contre celà, c'est de ne pas être demeuré mental.
Une solution qui me parait logique, et pas compliquée à implémenter, l'utilisation par le client mail d'un compte utilisateur/groupe particulier pour les executions de scripts. Un compte qui n'aurait aucun droits d'écriture et des droits de lecture très limités.
Il ne me semble pas avoir besoin d'aller très loin pour mettre en oeuvre celà.
[^] # Re: ...
Posté par Anonyme . Évalué à 0.
il y a deja eu une alerte sur les mailing listes d'administration linux au sujet d'un script propagé par mail ET EXECUTE AUTOMATIQUEMENT PAR LE CLIENT MAIL. je ne sais plus si c'etait mutt et pine ...
Ce qui est sur, c'est que PERSONNE NE DEVRAIT LIRE DE MAIL DEPUIS LE COMPTE ROOT. Y compris le mail de root qui devrait etre redirigé (merci /etc/aliases) vers un "user normal".
Les reflexions de l'auteur sont fondées et justes.
Pour ce qui est de linux over linux, je ne comprend pas trop si il s'agit du kernel en mode user ? en tout cas il y a des solutions simples a mettre en oeuvre pour les paranos:
1/ user dedié au mail/irc/... comme expliqué par l'auteur de la news.
2/ client mail "blindé" qui s'execute dans un environnement restreint (chroot).
... et surement d'autres ...
[^] # Re: ...
Posté par Anonyme . Évalué à 0.
Tu peux donner des détails ? A priori, ça semble pas évident.
[^] # Re: ...
Posté par Anonyme . Évalué à 0.
# virus linux
Posté par Anonyme . Évalué à 1.
De plus, comme la majorité de Windoziens font du PC à la simplissime, il faut que tout se lance dès que l'on clique... d'où l'ouverture quasi automatique des pièces jointes, etc, etc...
# linux et environnement integre
Posté par Loic Jaquemet . Évalué à 1.
En effet le probleme sous win se pose parce que y a un environnement entier derriere outlook et que outlook EST le client mail le plus utilise ..( Monopole ?..mais nooon :) )
Or sous GNU/linux il n'existe pour l'instant pas d'environnement ( rectifiez si je me trompe ) aussi developpe et aussi global(?) que sous win..
Enfin .. ceci est a relativise car avec KDE/Gnome/etc.. (Je pense surtout a Koffice) on arrive de plus en plus à des environnements qui englobent tout et n'importe koi pour le plus grand plaisir (...) de l'utilisateur.On pourra peut etre bientot s'inquieter ...
L'histoire de script shell ..sa tient pas la route .. je suis d'accord avec le commentaire ci-dessus.
[^] # Re: linux et environnement integre
Posté par Anonyme . Évalué à 0.
Tout et n'importe quoi, vraiment ? Je trouve au contraire que cela est salutaire, tres positifs pour Linux, et bien pratique ! Si des problemes de sécurité voient le jour, il faut les prévenir, les corriger : bref contourner ces difficultés potentielles... et pas s'interdire de réaliser de tels environnements ! Là comme ailleurs, les problèmes potentiels ne doivent pas arreter le progres ! Et KDE est un incontestable progres ! Idem pour Gnome ! La division, ie 2 environnements, par contre... Sauf erreur, de grandes societes soutiennent à la fois KDE et Gnome... Lorsqu'elles ne soutiendront plus qu'un environnement, nous saurons alors de quel coté la balance de l'uniformisation aura penché... Suivez mon regard : KDE ? Mais bon, on sort du prb des virus, là, c'est vrai ! Toutefois, j'aimerais savoir si KDE et Gnome réalise dès aujourd'hui des environnements dans lequels l'aspect "sécurité" est présent ? Un plus coté sécurité est un plus pour un environnement ! Ce peut être déterminant dans les choix que les utilisateurs et les induistriels feront (font?)... ET ces choix sont d'importance, car les choix de grandes entreprises auront une grande force d'entrainement... Il faudrait donc qu'au moins un environnement soit bien sécurisé, afin que sur ce plan là aussi Linux soit une belle alternative à... MSWindows !
[^] # Re: linux et environnement integre
Posté par Loic Jaquemet . Évalué à 1.
C'etait juste pour signaler la grande activite de dévéloppement que l'on peut retrrouver aussi bien pour KDE que pour Gnome.
Enfin..on s'eloigne la ...
# degat
Posté par T Sang Neuf . Évalué à 1.
a) un simple utilisateur peut faire tomber le systeme en lancant une serie de processus gloutons en memoire.
b) il semblerait (source fr.comp.os.linux.moderated) qu'un : rm -fr / lance par un simple utilisateur fasse suffisamment de casse pour que l'utilisateur s'arrache les cheveux. Je n'ai pas essaye de tester, a vrai dire... ;o)
[^] # Re: degat
Posté par Loic Jaquemet . Évalué à 1.
[^] # Re: degat
Posté par T Sang Neuf . Évalué à 1.
<<
[limit & ulimit]
Venons-en maintenant aux mauvaises nouvelles. Du point de vue de l'administration système, les limitations des ressources UNIX sont tout à fait inutiles. Tout d'abord, les limitations matérielles sont souvent cablées dans le noyau et ne peuvent être modifiées par l'administrateur système. De plus, les utilisateurs peuvent toujours modifier leurs propres limitations logicielles. Tout ce que peut faire un administrateur système est de placer les commandes désirées dans les fichiers .profile et .cshrc des utilisateurs en espérant qu'ils ne le modifieront pas. Par ailleurs, les limitations sont établies sur la base d'un seul processus. Malheureusement, de nombreuses taches comportent plusieurs processus et il n'existe aucun mecanisme pour imposer des limitations sur un processus pere et tous ses processus fils. Pour terminer, dans la plupart des cas, les limitations ne sont mises en vigueur; c'est particulièrement vrai pour les limitations importantes, à savoir la consommation de temps CPU et l'utilisation de la memoire.
>>
En bref, on est bien oblige de faire confiance aux users, on joue la carte Security Through Obscurity en modifiant en douce les .profiles, et on se doit de rester 24h/24 devant la console a faire des `ps' pour surveiller le moindre depart d'un process fou.
Ceci dit, ma version du bouquin est ancienne. Et il se pourrait peut etre qu'il soit apparu depuis d'autres mecanismes de limitations dont je n'ai pas encore eu vent.
[^] # Re: degat (limitation des users)
Posté par Leto . Évalué à 1.
En tous cas, sous FreeBSD (au moins) on doit pouvoir s'en sortir avec les classes d'utilisateurs contenues dans le /etc/login.conf (mais bon je ne suis pas expert BSD)
[^] # Re: degat (limitation des users)
Posté par T Sang Neuf . Évalué à 1.
Cela n'inclurait donc pas de nouveau mecanisme de limitation des ressources. D'autre part, Toto a toujours un acces en lecture sur le fichier /etc/passwd, qu'on pourrait raisonnablement considerer comme un fichier nominatif, a la maniere d'un carnet d'adresse.
[^] # Re: degat
Posté par Anonyme . Évalué à 0.
De toute façon, quand on a du boulot sérieux sur sa machine, ou en entreprise, on execute pas le premier coucou.exe qui arrive en attachement. C'est surtout le manque de rigueur au travail des gens qui mettent les entreprises dans la merde, un particulier qui a des documents importants sur sa machine ferra plus gaffe que la secrétaire qui fini le boulot à 1X heure et qui en a rien a fouttre de compromettre la sécurité de sa machine ou de l'entreprise. En cas de pépin elle pleurnichera sur les méchants virus. Dans une boîte sérieuse il doit y avoir une politique de la machine de travail utilisée UNIQUEMENT à des fins professionnelles.
Par contre il n'est pas normal que des scripts puissent être auto-executés par le client mail, rien qu'en recevant le message, ou uniquement en lisant son contenu.
[^] # Re: degat
Posté par T Sang Neuf . Évalué à 1.
Je ne connaissais pas, merci. :)
C'est # chattr +i le-fichier
Apparement, c'est root qui doit le lancer et c'est dependant d'ext2fs. je n'ai pas trouve `chattr' sur Tru64 ni SunOS.
Sinon, chmod -w le-fichier ne protege pas vraiment l'acces en ecriture pour quelqu'un qui a les droits en lecture sur le fichier et en ecriture sur le repertoire, ce qui est generalement le cas de Toto et de son ~Toto/.profile. Il faut faire une manip tordue, mais on arrive a faire des modifs.
Pour PAM, je ne connais pas non plus. je regarderais. Merci encore. :)
[^] # Re: degat
Posté par Babou . Évalué à 1.
d'un process, son pourcentage d'utilisation CPU,
ainsi que le nombre de process par utilisateur,
groupe d'utilisateur, la durée en temps CPU d'un
process ... alors il est tout à fait possible de
limiter les dégâts potentiels.
Ceci dépend notamment des utilisateurs: est-ce des
chercheurs, des étudiants, des employés de bureau, ... ? Ceci est à prendre en compte pour savoir quel niveau de paranoïa on doit appliquer.
Après, il est peu courant à ma connaissance que les admins utilisent ulimit (à l'université de Pau ils s'en servent en tout cas, ça m'a fait bizarre de voir mon telnet dégagé après quelques jours)
[^] # Re: degat
Posté par Loic Jaquemet . Évalué à 1.
Si le systeme est bien administre avec les droits tout comme y faut ...normalement ya pas trop de casse sauf dans le rep utilisateur (quoique sa depend de l'utilisation de la machine).
A part /tmp ( je pense au .X-lock etc... ) a priori rien de grave ...
Pour la a) je suis d'accord ..on ne peut rien rellement limiter .. apart l'espace disque..
[^] # Re: degat
Posté par gle . Évalué à 1.
Quant à ulimit, il me semble qu'on ne peut que réduire la limite si on n'est pas root.
Pour les pertes de données, il y a les backups.
Quelqu'un sait-il s'il existerait des solutions un peut comme la sandbox du runtime Java? Genre une commande quipermettrait de faire tourner le client mail et les applications pas sûres dans un environnemnt chroot avec un shell restreint, etc? Si quelqu'un s'y connaît là-dessus, je pense que faire un HOWTO serait une bien belle façon de contribuer à Linux...
[^] # Re: degat
Posté par Anonyme . Évalué à 0.
cat /dev/zero > /tmp/zero (avec éventuellement des ruses comme > /tmp/.zero etc...)
Existe-t-il un moyen de s'en prémunir??
[^] # Re: degat
Posté par Anonyme . Évalué à 0.
c'est a dire /tmp n'est pas sur le filesysteme / (root ou racine). En general cela suffit a te proteger. Les utilisateurs lambda ne doivent pas avoir de droit en ecriture sur le filesysteme /.
Ensuite tu peux mettre des ulimit (nbr de process, memoire, ...) qui sont incontournables par les utilisateurs "normaux". Enfin un petit coup de quota y compris sur /tmp et hop le tour est joué.
# Arf
Posté par Anonyme . Évalué à 0.
Comme kifont ceux qui bossent tts la journee sur le net (administration de serveur en SSH par exemple???)
:-D
[^] # Re: Arf
Posté par Knarf . Évalué à 1.
# Robuste depuis 30 ans !
Posté par Pierre Jarillon (site web personnel) . Évalué à 1.
ou http://www.atlantic-line.fr/~jarillon/redac/virus.html(...) (c'est la meme page)
ainsi que http://www.csn.net/~bediger/virefs.html(...)
# Situation de Linux envers les virus
Posté par Leto . Évalué à 1.
"Non-Microsoft operating systems such as Linux are invulnerable to macro attacks, immune to viruses"
Cet article a d'ailleurs fait courir beaucoup d'électrons, mais au final tout le monde s'est accordé sur cet état de fait. De toutes façons, quel que soit le système, les données des utilisateurs dépendront toujours des actions de l'utilisateur, mais au moins sous Linux on est tranquille pour le système.
[^] # Re: Situation de Linux envers les virus
Posté par Anonyme . Évalué à 0.
Et a noter que le dernier virus en date(Shockwave), c'est un executable, donc il faut cliquer dessus pour le lancer, qu'on utilise outlook ou pas le resultat est le meme, a la difference que si on n'a pas outlook, il lit pas le fichier d'adresse.
90% des problemes de virus sous Win sont du au fait que les utilisateurs sont des ignares en informatique(et ils ont raison, c'est pas ce qu'on leur demande) donc quand on leur dit "clique ici" ben ils le font sans connaitre les consequences potentielles.
Sous Linux la plupart des users ont un niveau de connaissances informatiques superieur a la secretaire sous Windows, et de plus personne n'envoie de scripts Unix comme virus en attachement, donc il n'y a pas de probleme.
Le jour ou Linux sera present en masse sur les desktop, ca va nous retomber sur la gueule cette histoire de "Linux insensible aux virus".
[^] # Re: Situation de Linux envers les virus
Posté par oliv . Évalué à 1.
Sous NT, tout le monde est administrateur de la machine après quelques mois, car l'admin en a marre qu'on lui casse sans arrêt les pieds toutes les 5 minutes.
[^] # Re: Situation de Linux envers les virus
Posté par Joël-Alexis Bialkiewicz . Évalué à 1.
[^] # Re: Situation de Linux envers les virus
Posté par oliv . Évalué à 1.
J'ai la flemme de reparcourir les news, mais c'est dans un commentaire qui a environ 3 semaines
[^] # Re: Situation de Linux envers les virus
Posté par bleh . Évalué à 1.
Lorsque tu dis ça c'est un peu comme si je disais que Unix n'est pas sécurisé sous pretexte que l'admin d'où je travaille donne à tout le monde le mot de passe root, moi dans ce cas je dirais plutôt que l'administrateur est complètement nul mais il n'y aurait aucune raison que je mette en cause le système d'explotation.
Donc je suis d'accord pour dire que NT bien administré peut se reveler assez sécurisé (même si, comme il a été dit plus haut, il y'a toujours des failles)
[^] # Re: Situation de Linux envers les virus
Posté par Leto . Évalué à 1.
>les windows, sous NT/Win2000, il n'y a pas plus
>de risque que sous Linux, les consequences sont
>les memes.
Je ne suis pas d'accord. Il y a eu dans le passé et il y aura surement encore dans le futur avec des systèmes de type NT de graves problèmes d'exécution de code utilisateur dans un environnement administrateur. La, je parle de *vrais* virus, pas les petits virus d'opérette ajoutés par l'utilisation maligne des utilisateurs et dont le but est de virer quelques fichiers. Non, j'ai en tete des virus capable de casser un disque dur, flasher un BIOS, faire imploser un écran, anéantir Redmond (WA) avec une bombe nucléaire (euh, là, je m'égare).
Là où les systèmes UNIX en général et Linux en particulier sont intéressant, c'est qu'il existe la séparation très distincte d'environnement entre le user space et le kernel space : deux environnements qui ne se chevauchent en aucun cas, et quand on a besoin de faire des opérations dans le kernel space on est *obligés* de passer par des appels systèmes.
On en revient à nos "vieux" virus sous NT où il était possible d'exécuter du code dans le kernel space en étant simple utilisateur.
Désolé, mais moi je n'appelle pas ça de la sécurité.
[^] # Re: Situation de Linux envers les virus
Posté par Knarf . Évalué à 1.
Pour en etre certains, essayez donc de lancer le .exe en attachement de votre mail sous Linux ;-)
Ca ne veut pas dire que Linux est insensible aux virus, mais comme la majorité des virus affectent Windows, statistiquement Linux a moins de chances d'etre affecté.
Dans le meme ordre d'idées, mon ZX81 est insensible aux virus Windows. Ca ne veut pas dire qu'il faut que tout le monde travaille avec des ZX81, je me fais bien comprendre ??
[^] # Re: Situation de Linux envers les virus
Posté par Anonyme . Évalué à 0.
Comme quoi la souplesse de Linux ('fin, des systèmes à base de Linux) permet à peu près tout, même de se faire un Windows !
[^] # Re: Situation de Linux envers les virus
Posté par Gaël . Évalué à 1.
# Pourquoi il n'y a pas de virus sous Linux.
Posté par Anonyme . Évalué à 0.
Toutefois avec le linux grand public, on va retrouver les mêmes problèmes que sous windows (à part peut être l'execution des scripts automatique dans les mails).
Mais argumenter que Linux c'est bien parce que s'il y a un virus on perd que ses fichiers et pas le système est la plus grosses connerie jamais entendue.
Personnellement, l'install du système ca prend 1/2 heure et je la fais souvent...mais la seule partition que j'efface pas entre 2 distrib, c'est /home, faut être logique, je préfère 1000 fois que le système tout entier soit down que perdre ma semaine de boulot dans /home.
Alors, stop aux polèmiques stériles win VS linux, la polémique c'est abrutis VS intelligents (a part pour les scripts auto-executables par outlook, là les abrutis c'est vraiment MS).
[^] # Re: Pourquoi il n'y a pas de virus sous Linux.
Posté par ufoot (site web personnel) . Évalué à 1.
# noir et blanc
Posté par T Sang Neuf . Évalué à 1.
- sendmail (Internet Worm)
- finger
- passwd -f
Elle poursuit:
<<
Qu'ont donc en commun ces differents cas de figures ? Ils illustrent tous le fait qu'UNIX considère que le système fonctionne dans un environnement sûr, peuplé de gens raisonnables. Dans les trois cas, les programmes ne prévoyaient pas, ni ne vérifiaient, que leurs possibilités étaient utilisées de manière détournée. Il ne faut pas considérer ces problèmes comme d'anciens bogues qui ont mis longtemps à être réparés, mais plutôt comme une caractéristique inhérente du système d'exploitation UNIX présente à un niveau trés profond du système. Cette croyance apparait de manière évidente dans le mode de conception des commandes UNIX que l'on considère comme de simples outils qui effectuent une tache ou un type de tache de manière générale et optimale.
>>
En fait, personnellement, je trouve que c'est bien agreable de bosser sur Unix lorsqu'on est dans un `environnement sûr, peuplé de gens raisonnables'.
Mais j'ai l'impression que ca doit etre un cauchemard a administrer si, à cause d'un compte vérolé, l'environnement devient hostile.
Que faut il alors interdire au vilain Toto: l'acces au reseau ? l'acces a Perl et gcc ? l'acces aux editeurs vi/emacs ? quelle partie de l'arborescence est sensible ? a t il le droit de lancer X, d'imprimer ? et aussi, comment trier le bon grain de l'ivraie entre ce qu'on accepte pour les gentils et ce qu'on refuse pour les mechants ?
[^] # Re: noir et blanc
Posté par Anonyme . Évalué à 0.
[^] # Re: noir et blanc
Posté par Babou . Évalué à 1.
des plus fiables. Bien sûr, reste à le configurer
potablement (pas de .forward, utiliser procmail,
define(`confPRIVACY_FLAGS', `goaway'), ...)
A propos de finger, ça me semble AVOIR ETE un bug
corrigé depuis longtemps.
Pour finger, il ne faut pas l'autoriser, ça va
de soit !
Bien entendu il existe des centaines de trous de
sécurité potentiels dans les systèmes Unix and co.
Reste à ne pas les mettre "à disposition".
Inutile de nous pondre le contenu d'un bouquin. Tout bon admin. sys. les connaît (j'ai **bon** admin, hein ?! :) et s'adapte en conséquence.
# C'est pas si simple...
Posté par Knarf . Évalué à 1.
C'est dur à admettre mais beaucoup de gens croient savoir utiliser linux, alors qu'ils n'en ont qu'une vision très superficielle, limitée à X, Gnome, KDE ou encore le dernier freeware débile qui réalise toutes le taches d'admin qu'on a toujours revé de pouvoir faire sous un environnement graphique ou web.
Le post initial de cette news qui part sans doute d'un bon sentiment, ne tient pas compte de ces fameux composants 3rd party qui font souvent notre bonheur. Parfois, il s'agit même de trucs inclus dans la distro, BIND (voir les pb recencés sur des versions TRES récentes sur isc.org), WU-Ftpd, NFS ou Sendmail par exemple. C'est souvent par ici qu'arrivent les pb. On peut considérer ca comme un virus, mais c'est plutot des pb des sécurité. Pour peu qu'on laisse tourner plus de 3 mois (et encore) une release, on est déja out of date d'une part et vulnérable d'autre part. Il n'y a qu'à visiter par exemple securityfocus.com pour s'en assurer (bin oui il y a aussi une rubrique linux)
Un premier pas, c'est utiliser des outils comme ipchains qui peuvent permettre de bloquer certains ports. Ce n'est pas la solution miracle mais ca aide. Ensuite, on controle avec des commandes hyper utiles comme lsof -i qui donne la liste des ports ouverts sur la machine.
Tout ca n'est en aucun cas un remède à la betise, on est quand meme censé jeter un oeil à son /etc/inetd.conf pour virer les lignes qui vont bien et ne laisser que ce qui SERT VRAIMENT. Et ce qui reste, l'analyser sous toutes les coutures, lire les derniers bugtraq sur les produits en question et REGARDER SES LOGS.
Je conseille à tout le monde l'utilisation de 2 produits très simples et très utiles, LogCheck et Portsentry que j'utilise sur toutes les infrastructures machines que j'administre. Ils sont dispo sur psionic.com.
Autre lecture saine pour les utilisateurs de RH, mais que les utilisateurs d'autres distros ne doivent pas ignorer, le fameux "Securing & Optimizing Red Hat Linux" dispo ici: http://www.openna.com/books/registration.htm(...)
Il faut s'enregistrer mais c'est gratuit. C'est un bouquin qui explique les diverses étapes de config d'un système RH avec tout ce qui va bien pour fare fonctionner un serveur très complet.
Bonne lecture.
[^] # Re: C'est pas si simple...
Posté par Anonyme . Évalué à 0.
sinon les worms sous linux peuvent etre tres efficace car passant par 2-3 faille de securite classique il peuvent passer de system en system et exploitant la faille il sont root donc peuvent faire tres mal
effectivement portsentry et logcheck sont assez sympa, par contre portsentry peut se retourner contre soit si une personne a juste envie de bloquer tous car il lui suffit de forger des packets venant de tous internet qui simule une attaque et la on se retrouve isoler
++ banux
[^] # Re: C'est pas si simple...
Posté par patrick barthel . Évalué à 1.
# chroot ?
Posté par GuiJEmonT . Évalué à 1.
[^] # virus unix
Posté par Anonyme . Évalué à 0.
EN environement unix, il est possible d'infecter les process apartenant a l'utilisateur et les infectes pour voler des password lors de 'su', de detecter des erreurs sur les acl du filesystem et de contaminer l'executable ELF par des redirections sur le point d'entree du programme , etc.. (pour les techniciens, je conseille www.big.net.au/~silvio, la page de silvio sur les virii unix) . UNIX etant un system un peu plus complexe a aprehender que windows nt, il arrive moins que des utilisateurs inexperimentes cliques sur des fichiers joints ou autres . Si linux se repend en tant que station de travail dans les annees a venir, je pense que le marche des antivirus unix va se developper , tout comme sous windows .
++ mayM
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.