C'est toi qui fait de ton usage particulier une généralité.
Lol ... ah bon, tu crois que bidouiller sous Linux c'est un usage particulier ?
Et moi qui pensait que c'était un OS de bidouilleur...
Au delà de ça tu as exprimé une opinion qui relève de ton cas particulier. Si quelqu'un, un peu bidouilleur, appliquait ton opinion sans réfléchir, il se priverait d'une protection peut être inutile dans 90% des cas mais qui au final, ne mange pas de pain et qui peut sauver la mise un jour.
Au contraire, si on applique bêtement mon opinion, ça n'enlève rien à l'utilisateur, ça ne bride pas son utilisation d'internet, ça surcharge peu ou pas la machine ... en fait, c'est transparent. Juste, t'as une protection supplémentaire.
Un débutant n'installe pas de services (web, ssh, ou autre)
Bien souvent, des services font partie de l'installation par défaut.
donc pas de ports ouverts, sa machine est généralement sur un réseau privé derrière une box : le pare-feu y est totalement inutile.
Sache qu'il y a pas mal de protocole qui permettent de traverser ce genre de chose. DLNA en est un.
Et au delà de ça, faire une confiance aveugle en une box opérée et administrée par un FAI me parait quelque peu dangereux.
Dernière chose: quid des wifi public que tout le monde utilise de plus en plus ?
Le rôle du pare-feu (pour ton usage) est de bloquer ou filtrer l'accès à des ports ouverts qu'on ne veut pas laisser accessibles. C'est un usage légitime mais bien particulier
Euh ... je pensais que c'était pourtant la base d'un pare feu. Faudra que tu m'expliques quels sont les usages qui ne sont pas "bien particulier" dans ce cas. vraiment.
(Et si tu me parles du NAT, alors je te répondre qu'avec l'arrivée prochaine d'IPv6, on ne devrait donc plus avoir besoin de pare-feu ?)
et même dans ce cas on peut très bien se passer de pare-feu : il suffit de faire attention à ce que l'on installe et surtout comment on le configure. Et les services cela peut se lancer à la demande.
Bien sûr ... mais encore une fois, je préfère mettre directement un jeu de règle iptables qui me bloque tout par défaut plutôt que de faire des update-rc.d à gogo pour enlever des services du runlevel (d'autant que lors d'un update le rc.d sera réinstallé si je ne me trompe pas ...).
Le problème c'est qu'on a tellement bourré le crâne des gens avec la soi-disant nécessité absolue du pare-feu pour se protéger des « attaques » qu'ils se croient en sécurité
Rassure toi, ce n'est pas mon cas.
Au contraire.
En faisant la promotion d'un pare-feu, j'applique également un principe de base de la sécurité informatique: ne pas mettre tout ses oeufs dans le même panier.
Ce n'est pas pour rien que, lorsqu'on monte une infra réseau, on va généralement préférer utiliser des marques d'équipements différentes dans une même "chaine" réseau: si l'équipementier A a une faille et que tout le coeur de réseau s'appuie sur ses équipements, alors tout le réseau est vulnérable.
En mixant les équipementiers, on modère les impacts d'une éventuelle faille chez l'un d'entre eux.
A l'échelle d'un OS, on peut se dire qu'appliquer ce principe de précaution n'est pas totalement déconnant.
Imagine demain une régression dans le noyau qui fait que, par une manigance habile, on parvienne à arriver à accéder à un service qui n'écoute que sur localhost ?
Un parefeu aurait tout son intérêt.
alors qu'ils oublient d'appliquer les principes de base : ne pas faire tourner de services inutiles, séparation des privilèges, droits d'accès minimaux, etc.
Je suis d'accord, un pare-feu ne doit pas se substituer à une rigueur dans la gestion de son système.
Cependant, comme je te le disais:
1. C'est toujours une protection supplémentaire qui peut être utile.
2. Une machine de travail d'un dév bidouilleur finira, par nature, un peu en vrac ;-)
Ton exemple avec Wordpress le montre bien : si le service est accessible de l'Internet aucune règle iptables ne peut te prémunir contre cette faille, les principes que j'évoque le peuvent (ou au moins minimiser son impact).
On est d'accord.
Mais on est d'accord aussi sur le fait que le sujet ici, c'est un pare-feu sur un poste de travail.
Hors, je ne pense pas qu'il soit souhaitable de laisser accessible quoi que ce soit sur ce type de setup.
Donc on reste bien dans une démarche de se protéger de soi-même et d'éventuels oublis suite à expérimentation.
[^] # Re: Commencer par le début
Posté par LaBienPensanceMaTuer . En réponse au message IPtables -configuration. Évalué à 2.
Lol ... ah bon, tu crois que bidouiller sous Linux c'est un usage particulier ?
Et moi qui pensait que c'était un OS de bidouilleur...
Au delà de ça tu as exprimé une opinion qui relève de ton cas particulier. Si quelqu'un, un peu bidouilleur, appliquait ton opinion sans réfléchir, il se priverait d'une protection peut être inutile dans 90% des cas mais qui au final, ne mange pas de pain et qui peut sauver la mise un jour.
Au contraire, si on applique bêtement mon opinion, ça n'enlève rien à l'utilisateur, ça ne bride pas son utilisation d'internet, ça surcharge peu ou pas la machine ... en fait, c'est transparent. Juste, t'as une protection supplémentaire.
Bien souvent, des services font partie de l'installation par défaut.
Sache qu'il y a pas mal de protocole qui permettent de traverser ce genre de chose. DLNA en est un.
Et au delà de ça, faire une confiance aveugle en une box opérée et administrée par un FAI me parait quelque peu dangereux.
Dernière chose: quid des wifi public que tout le monde utilise de plus en plus ?
Euh ... je pensais que c'était pourtant la base d'un pare feu. Faudra que tu m'expliques quels sont les usages qui ne sont pas "bien particulier" dans ce cas. vraiment.
(Et si tu me parles du NAT, alors je te répondre qu'avec l'arrivée prochaine d'IPv6, on ne devrait donc plus avoir besoin de pare-feu ?)
Bien sûr ... mais encore une fois, je préfère mettre directement un jeu de règle iptables qui me bloque tout par défaut plutôt que de faire des
update-rc.dà gogo pour enlever des services du runlevel (d'autant que lors d'un update le rc.d sera réinstallé si je ne me trompe pas ...).Rassure toi, ce n'est pas mon cas.
Au contraire.
En faisant la promotion d'un pare-feu, j'applique également un principe de base de la sécurité informatique: ne pas mettre tout ses oeufs dans le même panier.
Ce n'est pas pour rien que, lorsqu'on monte une infra réseau, on va généralement préférer utiliser des marques d'équipements différentes dans une même "chaine" réseau: si l'équipementier A a une faille et que tout le coeur de réseau s'appuie sur ses équipements, alors tout le réseau est vulnérable.
En mixant les équipementiers, on modère les impacts d'une éventuelle faille chez l'un d'entre eux.
A l'échelle d'un OS, on peut se dire qu'appliquer ce principe de précaution n'est pas totalement déconnant.
Imagine demain une régression dans le noyau qui fait que, par une manigance habile, on parvienne à arriver à accéder à un service qui n'écoute que sur localhost ?
Un parefeu aurait tout son intérêt.
Je suis d'accord, un pare-feu ne doit pas se substituer à une rigueur dans la gestion de son système.
Cependant, comme je te le disais:
1. C'est toujours une protection supplémentaire qui peut être utile.
2. Une machine de travail d'un dév bidouilleur finira, par nature, un peu en vrac ;-)
On est d'accord.
Mais on est d'accord aussi sur le fait que le sujet ici, c'est un pare-feu sur un poste de travail.
Hors, je ne pense pas qu'il soit souhaitable de laisser accessible quoi que ce soit sur ce type de setup.
Donc on reste bien dans une démarche de se protéger de soi-même et d'éventuels oublis suite à expérimentation.