Ubuntu Linux : quel antivirus et pare-feu choisir ?
29 réponses
Zetrader
J'ai bien envie d'essayer la dernière version d'ubuntu à la place de windows
sur le nouveau pc (je garderais un pc sous xp et tenterait l'expérience sous
le pc le plus récent), pour essayer de faire la transition petit à petit
vers cet OS si j'arrive à en tirer bon usage, mais j'ai deux questions avant
de me lancer dans l'aventure :
- quel antivirus utiliser ? j'ai vu que souvent les gens n'utilisent pas
d'antivirus sous linux, certains allant même jusqu'à dire que c'est inutile
sous linux.
- comment ça se passe au niveau du firewall (pare-feu) ?
Sebastiaan 'CrashandDie' Lauwers wrote in message <4668908d$0$16863$:
Vous pouvez faire encore moins argumenté ?
Il y a exactement autant d'arguments dans mon message que dans le tien.
octane
On 8 juin, 09:08, Sebastiaan 'CrashandDie' Lauwers
Configuration A: - Une machine lambda, Windows XP, peu importe le service pack, connecté sur internet par un modem USB, l'interface réseau possède sa propre adresse IP publique sur internet, tous les ports sont accessible depuis l'extérieur. Mais ma machine n'est pas importante, j'ai pas besoin de pare-feu... - Une faille est découverte dans RPC, un petit virus est écrit et cause le torpillage de toutes les stacks RPC des adresses IP voisine de la machine infectée. Dès que RPC est lancé, la machine est disponible pour un bon petit redémarrage à distance.
comment ne pas installer RPC? S'il est installe, comment le supprimer?
Un simple pare- feu qui bloque les ports non nécessaires aura permis de ne pas en prendre plein la gueule. Mais bon.
Le pare feu devient de fait obligatoire.
Configuration B: - Une machine lambda, Mandriva, peu importe la version, connecté sur internet de façon directe, accessible totalement par l'extérieur parcequ'elle est sur une IP DMZ. Tous les ports sont accessibles. L'utilisateur a cliqué aveuglement sur suivant suivant suivant, voyant "serveurs internet" pensait bien faire en l'installant.
Cela signifie: l'utilisateur est un gros veau.
Il se retrouve, comme par hasard avec une version de apache 1.3.x et PHP 4.0.6. Un attaquant passe par là, il lance un exploit sur la faille qui est contenue dans cette version de PHP, c'est à dire un exploit sur le stack POST de PHP, plante le daemon apache, et peut même exécuter du code arbitraire sur la machine... L'utilisateur ne le sait pas encore, mais sa machine vient de se transformer en node virtuellement indétectable d'un botnet, spam ou quoi que ce soit.
Alors l'utilisateur est un gros veau, mais il doit penser a
installer un pare feu. Ca me semble de toute facon incompatible.
Lorsque j'installe une machine, netstat -na | grep LISTEN m'affiche 0 ports ouverts!
Configuration C: - Une machine lambda, Mac OS X, un Macbook Pro, avec l'AirPort. L'utilisateur se dit que sur Mac, il n'y a pas de problèmes de sécurité, il ne pense pas à mettre à jour ses drivers, ses firmwa res. Un exploit dans le code d'origine des AirPort permet d'éteindre à distance le Mac, voire même d'éxecuter du code arbitraire dessus.
Ca, c'est quand meme l'arlesienne. Je crois que cette faille n'a jamais ete reellement vue. Lire par exemple: http://sid.rstack.org/blog/index.php/2006/08/26/113-du-lard-du-cochon-ou-ju ste-du-flan
(pour ceux qui ont la flemme de lire: -whaouh on a decouvert une super faille dans le driver wifi -montrez nous comment -croyez nous c'est vrai -Ok. comment? -si si c'est vrai. -... (...) apple sort curieusement peu de temps apres des correctifs sur la faille, sans qu'une correlation forte soit faite)
On attend toujours l'exploit.
Un pare feu aurait lui aussi comblé le problème (dépendant de la versi on de la faille).
Non. Cette arlesienne parlait d'un bug dans l'implementation
du driver. C'est a dire que tu envoies une trame, le driver se vautre, et execute du code. Nulle part on n'a touche la pile IP. J'attends par contre les slides de la session du SSTIC: EXPLOITATION EN ESPACE NOYAU par Stéphane DUVERGER (EADS CCR) qui au vu de la presentation semble s'en approcher.
Je pense que je pourrais continuer longtemps comme ça à réciter l'alphabet, mais je crois que vous avez compris le principe.
Peu importe l'OS, peu importe la machine, il y aura toujours des failles dans le logiciel qui tourne dessus.
Mais ce logiciel, comment l'atteindre? Si aucun serveur tourne l'attaque par le reseau est promise au neant, et le pare feu inutile.
Un pare-feu (matériel) ne consomme rien
qu'entends tu par pare feu materiel?
et c'est franchement pas du luxe. Un bon NAT, et c'est quasiment invisible.
C'est un premier pas. Un petit pas pour la securite reseau, mais un grand pas pour la protection des windows :)
Je dis pas que chaque PC doit être protégé comme ses enfants dans la cave derrière des tonnes d'explosifs et des gardes armés de fusil à pompe, je dis simplement qu'un peu de sécurité gratuite ça mange vraiment pas de pain.
D'ou le NAT. Mais il faut etre conscient de ses limites.
On 8 juin, 09:08, Sebastiaan 'CrashandDie' Lauwers
Configuration A:
- Une machine lambda, Windows XP, peu importe le service pack,
connecté sur internet par un modem USB, l'interface réseau possède sa
propre adresse IP publique sur internet, tous les ports sont
accessible depuis l'extérieur. Mais ma machine n'est pas importante,
j'ai pas besoin de pare-feu...
- Une faille est découverte dans RPC, un petit virus est écrit et
cause le torpillage de toutes les stacks RPC des adresses IP voisine
de la machine infectée. Dès que RPC est lancé, la machine est
disponible pour un bon petit redémarrage à distance.
comment ne pas installer RPC? S'il est installe, comment le
supprimer?
Un simple pare-
feu qui bloque les ports non nécessaires aura permis de ne pas en
prendre plein la gueule. Mais bon.
Le pare feu devient de fait obligatoire.
Configuration B:
- Une machine lambda, Mandriva, peu importe la version, connecté sur
internet de façon directe, accessible totalement par l'extérieur
parcequ'elle est sur une IP DMZ. Tous les ports sont accessibles.
L'utilisateur a cliqué aveuglement sur suivant suivant suivant, voyant
"serveurs internet" pensait bien faire en l'installant.
Cela signifie: l'utilisateur est un gros veau.
Il se
retrouve, comme par hasard avec une version de apache 1.3.x et PHP
4.0.6. Un attaquant passe par là, il lance un exploit sur la faille
qui est contenue dans cette version de PHP, c'est à dire un exploit
sur le stack POST de PHP, plante le daemon apache, et peut même
exécuter du code arbitraire sur la machine... L'utilisateur ne le sait
pas encore, mais sa machine vient de se transformer en node
virtuellement indétectable d'un botnet, spam ou quoi que ce soit.
Alors l'utilisateur est un gros veau, mais il doit penser a
installer un pare feu. Ca me semble de toute facon incompatible.
Lorsque j'installe une machine, netstat -na | grep LISTEN
m'affiche 0 ports ouverts!
Configuration C:
- Une machine lambda, Mac OS X, un Macbook Pro, avec l'AirPort.
L'utilisateur se dit que sur Mac, il n'y a pas de problèmes de
sécurité, il ne pense pas à mettre à jour ses drivers, ses firmwa res.
Un exploit dans le code d'origine des AirPort permet d'éteindre à
distance le Mac, voire même d'éxecuter du code arbitraire dessus.
Ca, c'est quand meme l'arlesienne. Je crois que cette faille
n'a jamais ete reellement vue.
Lire par exemple:
http://sid.rstack.org/blog/index.php/2006/08/26/113-du-lard-du-cochon-ou-ju ste-du-flan
(pour ceux qui ont la flemme de lire:
-whaouh on a decouvert une super faille dans le driver wifi
-montrez nous comment
-croyez nous c'est vrai
-Ok. comment?
-si si c'est vrai.
-...
(...) apple sort curieusement peu de temps apres
des correctifs sur la faille, sans qu'une correlation
forte soit faite)
On attend toujours l'exploit.
Un
pare feu aurait lui aussi comblé le problème (dépendant de la versi on
de la faille).
Non. Cette arlesienne parlait d'un bug dans l'implementation
du driver. C'est a dire que tu envoies une trame,
le driver se vautre, et execute du code. Nulle part on n'a
touche la pile IP.
J'attends par contre les slides de la session du SSTIC:
EXPLOITATION EN ESPACE NOYAU
par Stéphane DUVERGER (EADS CCR)
qui au vu de la presentation semble s'en approcher.
Je pense que je pourrais continuer longtemps comme ça à réciter
l'alphabet, mais je crois que vous avez compris le principe.
Peu importe l'OS, peu importe la machine, il y aura toujours des
failles dans le logiciel qui tourne dessus.
Mais ce logiciel, comment l'atteindre? Si aucun serveur tourne
l'attaque par le reseau est promise au neant, et le pare feu
inutile.
Un pare-feu (matériel) ne consomme rien
qu'entends tu par pare feu materiel?
et c'est franchement pas du luxe. Un bon NAT, et c'est
quasiment invisible.
C'est un premier pas. Un petit pas pour la securite reseau,
mais un grand pas pour la protection des windows :)
Je dis pas que chaque PC doit être protégé comme
ses enfants dans la cave derrière des tonnes d'explosifs et des gardes
armés de fusil à pompe, je dis simplement qu'un peu de sécurité
gratuite ça mange vraiment pas de pain.
D'ou le NAT. Mais il faut etre conscient de ses limites.
On 8 juin, 09:08, Sebastiaan 'CrashandDie' Lauwers
Configuration A: - Une machine lambda, Windows XP, peu importe le service pack, connecté sur internet par un modem USB, l'interface réseau possède sa propre adresse IP publique sur internet, tous les ports sont accessible depuis l'extérieur. Mais ma machine n'est pas importante, j'ai pas besoin de pare-feu... - Une faille est découverte dans RPC, un petit virus est écrit et cause le torpillage de toutes les stacks RPC des adresses IP voisine de la machine infectée. Dès que RPC est lancé, la machine est disponible pour un bon petit redémarrage à distance.
comment ne pas installer RPC? S'il est installe, comment le supprimer?
Un simple pare- feu qui bloque les ports non nécessaires aura permis de ne pas en prendre plein la gueule. Mais bon.
Le pare feu devient de fait obligatoire.
Configuration B: - Une machine lambda, Mandriva, peu importe la version, connecté sur internet de façon directe, accessible totalement par l'extérieur parcequ'elle est sur une IP DMZ. Tous les ports sont accessibles. L'utilisateur a cliqué aveuglement sur suivant suivant suivant, voyant "serveurs internet" pensait bien faire en l'installant.
Cela signifie: l'utilisateur est un gros veau.
Il se retrouve, comme par hasard avec une version de apache 1.3.x et PHP 4.0.6. Un attaquant passe par là, il lance un exploit sur la faille qui est contenue dans cette version de PHP, c'est à dire un exploit sur le stack POST de PHP, plante le daemon apache, et peut même exécuter du code arbitraire sur la machine... L'utilisateur ne le sait pas encore, mais sa machine vient de se transformer en node virtuellement indétectable d'un botnet, spam ou quoi que ce soit.
Alors l'utilisateur est un gros veau, mais il doit penser a
installer un pare feu. Ca me semble de toute facon incompatible.
Lorsque j'installe une machine, netstat -na | grep LISTEN m'affiche 0 ports ouverts!
Configuration C: - Une machine lambda, Mac OS X, un Macbook Pro, avec l'AirPort. L'utilisateur se dit que sur Mac, il n'y a pas de problèmes de sécurité, il ne pense pas à mettre à jour ses drivers, ses firmwa res. Un exploit dans le code d'origine des AirPort permet d'éteindre à distance le Mac, voire même d'éxecuter du code arbitraire dessus.
Ca, c'est quand meme l'arlesienne. Je crois que cette faille n'a jamais ete reellement vue. Lire par exemple: http://sid.rstack.org/blog/index.php/2006/08/26/113-du-lard-du-cochon-ou-ju ste-du-flan
(pour ceux qui ont la flemme de lire: -whaouh on a decouvert une super faille dans le driver wifi -montrez nous comment -croyez nous c'est vrai -Ok. comment? -si si c'est vrai. -... (...) apple sort curieusement peu de temps apres des correctifs sur la faille, sans qu'une correlation forte soit faite)
On attend toujours l'exploit.
Un pare feu aurait lui aussi comblé le problème (dépendant de la versi on de la faille).
Non. Cette arlesienne parlait d'un bug dans l'implementation
du driver. C'est a dire que tu envoies une trame, le driver se vautre, et execute du code. Nulle part on n'a touche la pile IP. J'attends par contre les slides de la session du SSTIC: EXPLOITATION EN ESPACE NOYAU par Stéphane DUVERGER (EADS CCR) qui au vu de la presentation semble s'en approcher.
Je pense que je pourrais continuer longtemps comme ça à réciter l'alphabet, mais je crois que vous avez compris le principe.
Peu importe l'OS, peu importe la machine, il y aura toujours des failles dans le logiciel qui tourne dessus.
Mais ce logiciel, comment l'atteindre? Si aucun serveur tourne l'attaque par le reseau est promise au neant, et le pare feu inutile.
Un pare-feu (matériel) ne consomme rien
qu'entends tu par pare feu materiel?
et c'est franchement pas du luxe. Un bon NAT, et c'est quasiment invisible.
C'est un premier pas. Un petit pas pour la securite reseau, mais un grand pas pour la protection des windows :)
Je dis pas que chaque PC doit être protégé comme ses enfants dans la cave derrière des tonnes d'explosifs et des gardes armés de fusil à pompe, je dis simplement qu'un peu de sécurité gratuite ça mange vraiment pas de pain.
D'ou le NAT. Mais il faut etre conscient de ses limites.
Nina Popravka
On Fri, 08 Jun 2007 00:45:07 -0700, wrote:
Alors l'utilisateur est un gros veau, mais il doit penser a installer un pare feu. Ca me semble de toute facon incompatible.
Donc si je suis le raisonnement, quand on laisse traîner des trucs troués sur un *nix, c'est l'utilisateur qui est un gros veau, et quand c'est sur un win c'est l'OS qui est un gros veau ? ;-> -- Nina
On Fri, 08 Jun 2007 00:45:07 -0700, octane@alinto.com wrote:
Alors l'utilisateur est un gros veau, mais il doit penser a
installer un pare feu. Ca me semble de toute facon incompatible.
Donc si je suis le raisonnement, quand on laisse traîner des trucs
troués sur un *nix, c'est l'utilisateur qui est un gros veau, et quand
c'est sur un win c'est l'OS qui est un gros veau ? ;->
--
Nina
Alors l'utilisateur est un gros veau, mais il doit penser a installer un pare feu. Ca me semble de toute facon incompatible.
Donc si je suis le raisonnement, quand on laisse traîner des trucs troués sur un *nix, c'est l'utilisateur qui est un gros veau, et quand c'est sur un win c'est l'OS qui est un gros veau ? ;-> -- Nina
octane
On 8 juin, 09:56, Nina Popravka wrote:
Alors l'utilisateur est un gros veau, mais il doit penser a installer un pare feu. Ca me semble de toute facon incompatible.
Donc si je suis le raisonnement, quand on laisse traîner des trucs troués sur un *nix, c'est l'utilisateur qui est un gros veau, et quand c'est sur un win c'est l'OS qui est un gros veau ? ;->
Nous sommes sur un groupe linux ;->
Mais plus serieusement, c'est a prendre dans l'autre sens. Un gros veau reste un gros veau, quel que soit l'OS. Ensuite, un user pas trop veau (meuhh), va pouvoir agir sur la securite de son systeme.
Je rappelle l'objectif: si aucun serveur ne tourne sur une machine, on a pas besoin de pare feu. Le contexte concerne les intrusions reseau.
Sous windows, il n'arrivera pas a supprimer tous les services qui tournent, donc il a besoin d'un pare feu. Sous linux, c'est possible de s'en passer.
On 8 juin, 09:56, Nina Popravka <N...@nospam.invalid> wrote:
Alors l'utilisateur est un gros veau, mais il doit penser a
installer un pare feu. Ca me semble de toute facon incompatible.
Donc si je suis le raisonnement, quand on laisse traîner des trucs
troués sur un *nix, c'est l'utilisateur qui est un gros veau, et quand
c'est sur un win c'est l'OS qui est un gros veau ? ;->
Nous sommes sur un groupe linux ;->
Mais plus serieusement, c'est a prendre dans l'autre sens.
Un gros veau reste un gros veau, quel que soit l'OS.
Ensuite, un user pas trop veau (meuhh), va
pouvoir agir sur la securite de son systeme.
Je rappelle l'objectif: si aucun serveur ne tourne sur une
machine, on a pas besoin de pare feu. Le contexte concerne
les intrusions reseau.
Sous windows, il n'arrivera pas a supprimer tous les services
qui tournent, donc il a besoin d'un pare feu. Sous linux, c'est
possible de s'en passer.
Alors l'utilisateur est un gros veau, mais il doit penser a installer un pare feu. Ca me semble de toute facon incompatible.
Donc si je suis le raisonnement, quand on laisse traîner des trucs troués sur un *nix, c'est l'utilisateur qui est un gros veau, et quand c'est sur un win c'est l'OS qui est un gros veau ? ;->
Nous sommes sur un groupe linux ;->
Mais plus serieusement, c'est a prendre dans l'autre sens. Un gros veau reste un gros veau, quel que soit l'OS. Ensuite, un user pas trop veau (meuhh), va pouvoir agir sur la securite de son systeme.
Je rappelle l'objectif: si aucun serveur ne tourne sur une machine, on a pas besoin de pare feu. Le contexte concerne les intrusions reseau.
Sous windows, il n'arrivera pas a supprimer tous les services qui tournent, donc il a besoin d'un pare feu. Sous linux, c'est possible de s'en passer.
Nina Popravka
On Fri, 08 Jun 2007 01:12:08 -0700, wrote:
Sous windows, il n'arrivera pas a supprimer tous les services qui tournent,
A part ça, pour être sérieux, effectivement on ne peut pas arrêter le port mapper sur le port 135, car ça interromperait les intéressantes conversations que Win a avec lui-même, et ça fonctionnerait beaucoup moins bien. Je te rappelle au passage que les RPCs sont une invention de Sun, autant que je sache, donc c'est réputé être *bien*, et il me semble que c'est utilisé par la plupart des OS modernes. Et pour revenir au port 135, il a déjà été tellement épluché et exploité qu'il doit plus y avoir grand chose à gratter dessus... -- Nina
On Fri, 08 Jun 2007 01:12:08 -0700, octane@alinto.com wrote:
Sous windows, il n'arrivera pas a supprimer tous les services
qui tournent,
A part ça, pour être sérieux, effectivement on ne peut pas arrêter le
port mapper sur le port 135, car ça interromperait les intéressantes
conversations que Win a avec lui-même, et ça fonctionnerait beaucoup
moins bien.
Je te rappelle au passage que les RPCs sont une invention de Sun,
autant que je sache, donc c'est réputé être *bien*, et il me semble
que c'est utilisé par la plupart des OS modernes.
Et pour revenir au port 135, il a déjà été tellement épluché et
exploité qu'il doit plus y avoir grand chose à gratter dessus...
--
Nina
Sous windows, il n'arrivera pas a supprimer tous les services qui tournent,
A part ça, pour être sérieux, effectivement on ne peut pas arrêter le port mapper sur le port 135, car ça interromperait les intéressantes conversations que Win a avec lui-même, et ça fonctionnerait beaucoup moins bien. Je te rappelle au passage que les RPCs sont une invention de Sun, autant que je sache, donc c'est réputé être *bien*, et il me semble que c'est utilisé par la plupart des OS modernes. Et pour revenir au port 135, il a déjà été tellement épluché et exploité qu'il doit plus y avoir grand chose à gratter dessus... -- Nina
octane
On 8 juin, 10:24, Nina Popravka wrote:
Sous windows, il n'arrivera pas a supprimer tous les services qui tournent,
A part ça, pour être sérieux, effectivement on ne peut pas arrête r le port mapper sur le port 135, car ça interromperait les intéressantes conversations que Win a avec lui-même, et ça fonctionnerait beaucoup moins bien.
c'est precisement la conclusion a laquelle je suis arrive. Donc il faut laisser ce port ouvert, donc il faut se proteger, donc firewall, etc etc..
Je te rappelle au passage que les RPCs sont une invention de Sun, autant que je sache, donc c'est réputé être *bien*, et il me semble que c'est utilisé par la plupart des OS modernes.
tout a fait. Sur mon mac, je peux le lancer, sur mon linux aussi[1]. Et oh surprise, ce service RPC a subi egalement beaucoup d'attaques, dont une qui visait explicitement les redhat 6.2 (je ne trouve plus le papier de reference, mais http://condor.depaul.edu/~jkristof/papers/igunda.pdf en est une bonne approche). Mais l'avantage de ces OS vient du fait que ces services sont _debrayables_ .
Et pour revenir au port 135, il a déjà été tellement épluché et exploité qu'il doit plus y avoir grand chose à gratter dessus...
Il restera le 445 :)
[1] tiens, au passage puisque tu es macounette, comment faire fonctionner un mac en client nfs sur un serveur nfs linux? sudo mount -t nfs 192.168.1.45:/var/export /Users/moi/linux/ ne fonctionne pas, je n'ai jamais compris pourquoi, j'ai pas vraiment cherche non plus, mais je profite de l'occasion...
On 8 juin, 10:24, Nina Popravka <N...@nospam.invalid> wrote:
Sous windows, il n'arrivera pas a supprimer tous les services
qui tournent,
A part ça, pour être sérieux, effectivement on ne peut pas arrête r le
port mapper sur le port 135, car ça interromperait les intéressantes
conversations que Win a avec lui-même, et ça fonctionnerait beaucoup
moins bien.
c'est precisement la conclusion a laquelle je suis arrive.
Donc il faut laisser ce port ouvert, donc il faut se proteger,
donc firewall, etc etc..
Je te rappelle au passage que les RPCs sont une invention de Sun,
autant que je sache, donc c'est réputé être *bien*, et il me semble
que c'est utilisé par la plupart des OS modernes.
tout a fait. Sur mon mac, je peux le lancer, sur mon linux
aussi[1]. Et oh surprise, ce service RPC a subi egalement
beaucoup d'attaques, dont une qui visait explicitement les
redhat 6.2 (je ne trouve plus le papier de reference,
mais http://condor.depaul.edu/~jkristof/papers/igunda.pdf
en est une bonne approche).
Mais l'avantage de ces OS vient du fait que ces services
sont _debrayables_ .
Et pour revenir au port 135, il a déjà été tellement épluché et
exploité qu'il doit plus y avoir grand chose à gratter dessus...
Il restera le 445 :)
[1] tiens, au passage puisque tu es macounette, comment
faire fonctionner un mac en client nfs sur un serveur nfs
linux?
sudo mount -t nfs 192.168.1.45:/var/export /Users/moi/linux/
ne fonctionne pas, je n'ai jamais compris pourquoi, j'ai
pas vraiment cherche non plus, mais je profite de l'occasion...
Sous windows, il n'arrivera pas a supprimer tous les services qui tournent,
A part ça, pour être sérieux, effectivement on ne peut pas arrête r le port mapper sur le port 135, car ça interromperait les intéressantes conversations que Win a avec lui-même, et ça fonctionnerait beaucoup moins bien.
c'est precisement la conclusion a laquelle je suis arrive. Donc il faut laisser ce port ouvert, donc il faut se proteger, donc firewall, etc etc..
Je te rappelle au passage que les RPCs sont une invention de Sun, autant que je sache, donc c'est réputé être *bien*, et il me semble que c'est utilisé par la plupart des OS modernes.
tout a fait. Sur mon mac, je peux le lancer, sur mon linux aussi[1]. Et oh surprise, ce service RPC a subi egalement beaucoup d'attaques, dont une qui visait explicitement les redhat 6.2 (je ne trouve plus le papier de reference, mais http://condor.depaul.edu/~jkristof/papers/igunda.pdf en est une bonne approche). Mais l'avantage de ces OS vient du fait que ces services sont _debrayables_ .
Et pour revenir au port 135, il a déjà été tellement épluché et exploité qu'il doit plus y avoir grand chose à gratter dessus...
Il restera le 445 :)
[1] tiens, au passage puisque tu es macounette, comment faire fonctionner un mac en client nfs sur un serveur nfs linux? sudo mount -t nfs 192.168.1.45:/var/export /Users/moi/linux/ ne fonctionne pas, je n'ai jamais compris pourquoi, j'ai pas vraiment cherche non plus, mais je profite de l'occasion...
Nina Popravka
On Fri, 08 Jun 2007 11:48:05 +0200, "Mihamina Rakotomandimby (R12y)" wrote:
C'est essentiellement le role de ClamAV: il ne cherche pas les virus qui attaquent Linux mais les virus "Windows".
ClamAV est d'une inefficacité redoutable ; encore pire que le truc de MS, ce qui n'est pas peu dire. Le seul truc sur lequel il s'en sorte à peu près, ce sont les virus qui se propagent par mail, manque de bol c'est une race qui se fait rare. -- Nina
On Fri, 08 Jun 2007 11:48:05 +0200, "Mihamina Rakotomandimby (R12y)"
<mihamina@rktmb.org> wrote:
C'est essentiellement le role de ClamAV: il ne cherche pas les virus qui
attaquent Linux mais les virus "Windows".
ClamAV est d'une inefficacité redoutable ; encore pire que le truc de
MS, ce qui n'est pas peu dire.
Le seul truc sur lequel il s'en sorte à peu près, ce sont les virus
qui se propagent par mail, manque de bol c'est une race qui se fait
rare.
--
Nina
On Fri, 08 Jun 2007 11:48:05 +0200, "Mihamina Rakotomandimby (R12y)" wrote:
C'est essentiellement le role de ClamAV: il ne cherche pas les virus qui attaquent Linux mais les virus "Windows".
ClamAV est d'une inefficacité redoutable ; encore pire que le truc de MS, ce qui n'est pas peu dire. Le seul truc sur lequel il s'en sorte à peu près, ce sont les virus qui se propagent par mail, manque de bol c'est une race qui se fait rare. -- Nina
Mihamina Rakotomandimby (R12y)
"Zetrader" <http://www.zetrader.fr> wrote:
- quel antivirus utiliser ? j'ai vu que souvent les gens n'utilisent pas d'antivirus sous linux,
Il y en a qui en utilisent, mais pour proteger les Machines Windows qu'il y a derriere. C'est essentiellement le role de ClamAV: il ne cherche pas les virus qui attaquent Linux mais les virus "Windows".
Quant à moi, j'ai quelques serveurs web+FTP+SMTP, avec juste un firewall basique (cahier des charges oblige) et aucun antivirus. Et pourtant ce qont des serveurs accessible publiquement. Le seul problème grave que j'ai rencontré, c'est quand un utilisateur a changé son mot de passe en la meme chose que son login: il (celui qui a deviné sont MDP) a pu se servir du SMTP (local) pour envoyer quelques dizaines de milliers de mails.
-- "Beaucoup de gens achètent des choses dont ils n'ont pas besoin avec de l'argent qu'il n'ont pas (crédits & emprunts) pour impressionner des gens qu'ils n'aiment pas." Inconnu
"Zetrader" <http://www.zetrader.fr> wrote:
- quel antivirus utiliser ? j'ai vu que souvent les gens n'utilisent pas
d'antivirus sous linux,
Il y en a qui en utilisent, mais pour proteger les Machines Windows qu'il y
a derriere.
C'est essentiellement le role de ClamAV: il ne cherche pas les virus qui
attaquent Linux mais les virus "Windows".
Quant à moi, j'ai quelques serveurs web+FTP+SMTP, avec juste un firewall
basique (cahier des charges oblige) et aucun antivirus.
Et pourtant ce qont des serveurs accessible publiquement.
Le seul problème grave que j'ai rencontré, c'est quand un utilisateur a
changé son mot de passe en la meme chose que son login: il (celui qui a
deviné sont MDP) a pu se servir du SMTP (local) pour envoyer quelques
dizaines de milliers de mails.
--
"Beaucoup de gens achètent des choses dont ils n'ont pas besoin
avec de l'argent qu'il n'ont pas (crédits & emprunts)
pour impressionner des gens qu'ils n'aiment pas."
Inconnu
- quel antivirus utiliser ? j'ai vu que souvent les gens n'utilisent pas d'antivirus sous linux,
Il y en a qui en utilisent, mais pour proteger les Machines Windows qu'il y a derriere. C'est essentiellement le role de ClamAV: il ne cherche pas les virus qui attaquent Linux mais les virus "Windows".
Quant à moi, j'ai quelques serveurs web+FTP+SMTP, avec juste un firewall basique (cahier des charges oblige) et aucun antivirus. Et pourtant ce qont des serveurs accessible publiquement. Le seul problème grave que j'ai rencontré, c'est quand un utilisateur a changé son mot de passe en la meme chose que son login: il (celui qui a deviné sont MDP) a pu se servir du SMTP (local) pour envoyer quelques dizaines de milliers de mails.
-- "Beaucoup de gens achètent des choses dont ils n'ont pas besoin avec de l'argent qu'il n'ont pas (crédits & emprunts) pour impressionner des gens qu'ils n'aiment pas." Inconnu
Nicolas George
Sebastiaan 'CrashandDie' Lauwers wrote in message :
Je pense que je pourrais continuer longtemps comme ça à réciter l'alphabet, mais je crois que vous avez compris le principe.
Oui, j'ai compris le principe : PEBKAC.
Peu importe l'OS, peu importe la machine, il y aura toujours des failles dans le logiciel qui tourne dessus.
De deux choses l'une : soit le logiciel correspond à un service qu'on souhaite ouvrir, et un firewall ne protégera pas d'une faille, soit il ne correspond pas à un service qu'on souhaite ouvrir, et dans ce cas on le ferme.
Sebastiaan 'CrashandDie' Lauwers wrote in message
<1181286526.844757.292050@p47g2000hsd.googlegroups.com>:
Je pense que je pourrais continuer longtemps comme ça à réciter
l'alphabet, mais je crois que vous avez compris le principe.
Oui, j'ai compris le principe : PEBKAC.
Peu importe l'OS, peu importe la machine, il y aura toujours des
failles dans le logiciel qui tourne dessus.
De deux choses l'une : soit le logiciel correspond à un service qu'on
souhaite ouvrir, et un firewall ne protégera pas d'une faille, soit il ne
correspond pas à un service qu'on souhaite ouvrir, et dans ce cas on le
ferme.
Sebastiaan 'CrashandDie' Lauwers wrote in message :
Je pense que je pourrais continuer longtemps comme ça à réciter l'alphabet, mais je crois que vous avez compris le principe.
Oui, j'ai compris le principe : PEBKAC.
Peu importe l'OS, peu importe la machine, il y aura toujours des failles dans le logiciel qui tourne dessus.
De deux choses l'une : soit le logiciel correspond à un service qu'on souhaite ouvrir, et un firewall ne protégera pas d'une faille, soit il ne correspond pas à un service qu'on souhaite ouvrir, et dans ce cas on le ferme.
Nicolas George
Nina Popravka wrote in message :
Donc si je suis le raisonnement, quand on laisse traîner des trucs troués sur un *nix, c'est l'utilisateur qui est un gros veau, et quand c'est sur un win c'est l'OS qui est un gros veau ? ;->
Exactement. Parce que windows est explicitement destiné à être utilisé par des utilisateurs non-spécialistes.
Nina Popravka wrote in message
<qh2i63l15rgq40iuuvebb856j3h3blvgm0@4ax.com>:
Donc si je suis le raisonnement, quand on laisse traîner des trucs
troués sur un *nix, c'est l'utilisateur qui est un gros veau, et quand
c'est sur un win c'est l'OS qui est un gros veau ? ;->
Exactement. Parce que windows est explicitement destiné à être utilisé par
des utilisateurs non-spécialistes.
Donc si je suis le raisonnement, quand on laisse traîner des trucs troués sur un *nix, c'est l'utilisateur qui est un gros veau, et quand c'est sur un win c'est l'OS qui est un gros veau ? ;->
Exactement. Parce que windows est explicitement destiné à être utilisé par des utilisateurs non-spécialistes.
