Bon, j'ai honte, mais j'ai un peu perdu de vue tout ça, et me
retrouvant dans l'obligation de changer de firewall, je n'ai aucune
idée du choix à faire.
Je cherche quelque chose de souple, d'efficace, de gratuit et de
stable. L'idéal ce serait quelque chose comme Sunbelt Personnal
Firewall mais qui ne me claquerait pas dans les doigts tous les deux
jours en m'obligeant à le désinstaller et le réinstaller.
Expliquez moi comment votre Livebox filtrera iexplore.exe tout en laissant passer firefox.exe ?
Inutile d'un firewall pour cela...
Dans Internet explorer : Outils>options internet>contenu>Activer le contrôle d'accès Placer toutes les options sur "limité"
Au revoir...
Ah ? et comment ferez vous pour mechant-trojan.exe ?
-- Roland Garcia
Stephane Catteau
Fabien LE LEZ n'était pas loin de dire :
3) La pile IP prend en charge cette demande de connexion et alloue l'espace nécessaire pour la traiter.
J'ai de gros problèmes pour comprendre ton message, et j'aimerais bien qu'on m'explique...
Je vais essayer, mais le temps n'étant pas une denrée abondante en ce moment je ne suis pas sûr d'arriver à faire mieux que la dernière fois.
Si j'ai bien tout saisi, il y a deux acceptions différentes du mot "pile" ("stack") :
- La "pile IP" est l'organisation des différentes couches (par exemple, IP -> UDP -> application), avec la gestion des headers successifs (header IP -> header UDP -> données).
Je n'ai jamais vraiment compris pourquoi on l'appellait "pile", mais tu as bon. La pile IP est (devenue ?) l'ensemble du code gérant la couche réseau IP et les couches de transport utilisables sur IP.
- La pile TCP (ou TCP/IP) est le mécanisme de suivi des connexions TCP en cours.
Qui constitue donc une partie de la pile IP. Dans le lot il y a aussi la pile, non ordonnée, qui s'occupe de gérer les paquets fragmentés.
Par ailleurs, par "connexion", on entend "connexion TCP" -- il y a peut-être d'autres types en laboratoire, mais pas dans la nature.
vip.
[snip]
Dans le cas contraire, le paquet est ignoré, et il n'y a pas de connexion (du point de vue de la machine-cible). Un paquet RST est envoyé, ou pas. Si le paquet RST est bien envoyé, et si la machine-source le reçoit, elle sait immédiatement que la connexion est refusée ; sinon, elle attend le timeout, ce qui peut saturer sa propre pile TCP.
Le mode "stealth" consiste à ne pas envoyer de paquet RST. Ça a une influence sur la pile TCP de la machine-source, mais aucune sur celle de la machine-cible.
Vi. [Note pour moi-même: ne pas se lancer dans une réponse qui demande beaucoup de mots lorsque l'on a pas le temps :( ]
Pour ceux que ça intéresse, ma connerie venait de l'architecture de mon LAN, avec un routeur/filtre IP/Nat devant les machines serveurs. Je ne sais pas pourquoi je l'ai assimilé à la machine cible, ce qui m'a fait foirer en beauté.
Voilà donc ce que j'ai compris. Est-ce exact ? Complètement faux ? Autre chose ?
c'est exact.
Merci d'avance pour vos commentaires...
De rien.
Fabien LE LEZ n'était pas loin de dire :
3) La pile IP prend en charge cette demande de connexion et alloue
l'espace nécessaire pour la traiter.
J'ai de gros problèmes pour comprendre ton message, et j'aimerais bien
qu'on m'explique...
Je vais essayer, mais le temps n'étant pas une denrée abondante en ce
moment je ne suis pas sûr d'arriver à faire mieux que la dernière fois.
Si j'ai bien tout saisi, il y a deux acceptions différentes du mot
"pile" ("stack") :
- La "pile IP" est l'organisation des différentes couches (par
exemple, IP -> UDP -> application), avec la gestion des headers
successifs (header IP -> header UDP -> données).
Je n'ai jamais vraiment compris pourquoi on l'appellait "pile", mais
tu as bon. La pile IP est (devenue ?) l'ensemble du code gérant la
couche réseau IP et les couches de transport utilisables sur IP.
- La pile TCP (ou TCP/IP) est le mécanisme de suivi des connexions TCP
en cours.
Qui constitue donc une partie de la pile IP. Dans le lot il y a aussi
la pile, non ordonnée, qui s'occupe de gérer les paquets fragmentés.
Par ailleurs, par "connexion", on entend "connexion TCP" -- il y a
peut-être d'autres types en laboratoire, mais pas dans la nature.
vip.
[snip]
Dans le cas contraire, le paquet est ignoré, et il n'y a pas de
connexion (du point de vue de la machine-cible).
Un paquet RST est envoyé, ou pas.
Si le paquet RST est bien envoyé, et si la machine-source le reçoit,
elle sait immédiatement que la connexion est refusée ; sinon, elle
attend le timeout, ce qui peut saturer sa propre pile TCP.
Le mode "stealth" consiste à ne pas envoyer de paquet RST. Ça a une
influence sur la pile TCP de la machine-source, mais aucune sur celle
de la machine-cible.
Vi.
[Note pour moi-même: ne pas se lancer dans une réponse qui demande
beaucoup de mots lorsque l'on a pas le temps :( ]
Pour ceux que ça intéresse, ma connerie venait de l'architecture de
mon LAN, avec un routeur/filtre IP/Nat devant les machines serveurs. Je
ne sais pas pourquoi je l'ai assimilé à la machine cible, ce qui m'a
fait foirer en beauté.
Voilà donc ce que j'ai compris. Est-ce exact ? Complètement faux ?
Autre chose ?
3) La pile IP prend en charge cette demande de connexion et alloue l'espace nécessaire pour la traiter.
J'ai de gros problèmes pour comprendre ton message, et j'aimerais bien qu'on m'explique...
Je vais essayer, mais le temps n'étant pas une denrée abondante en ce moment je ne suis pas sûr d'arriver à faire mieux que la dernière fois.
Si j'ai bien tout saisi, il y a deux acceptions différentes du mot "pile" ("stack") :
- La "pile IP" est l'organisation des différentes couches (par exemple, IP -> UDP -> application), avec la gestion des headers successifs (header IP -> header UDP -> données).
Je n'ai jamais vraiment compris pourquoi on l'appellait "pile", mais tu as bon. La pile IP est (devenue ?) l'ensemble du code gérant la couche réseau IP et les couches de transport utilisables sur IP.
- La pile TCP (ou TCP/IP) est le mécanisme de suivi des connexions TCP en cours.
Qui constitue donc une partie de la pile IP. Dans le lot il y a aussi la pile, non ordonnée, qui s'occupe de gérer les paquets fragmentés.
Par ailleurs, par "connexion", on entend "connexion TCP" -- il y a peut-être d'autres types en laboratoire, mais pas dans la nature.
vip.
[snip]
Dans le cas contraire, le paquet est ignoré, et il n'y a pas de connexion (du point de vue de la machine-cible). Un paquet RST est envoyé, ou pas. Si le paquet RST est bien envoyé, et si la machine-source le reçoit, elle sait immédiatement que la connexion est refusée ; sinon, elle attend le timeout, ce qui peut saturer sa propre pile TCP.
Le mode "stealth" consiste à ne pas envoyer de paquet RST. Ça a une influence sur la pile TCP de la machine-source, mais aucune sur celle de la machine-cible.
Vi. [Note pour moi-même: ne pas se lancer dans une réponse qui demande beaucoup de mots lorsque l'on a pas le temps :( ]
Pour ceux que ça intéresse, ma connerie venait de l'architecture de mon LAN, avec un routeur/filtre IP/Nat devant les machines serveurs. Je ne sais pas pourquoi je l'ai assimilé à la machine cible, ce qui m'a fait foirer en beauté.
Voilà donc ce que j'ai compris. Est-ce exact ? Complètement faux ? Autre chose ?
c'est exact.
Merci d'avance pour vos commentaires...
De rien.
Stephane Catteau
Fabien LE LEZ devait dire quelque chose comme ceci :
Cela étant dit, les tests effectués concernent en fait le comportement annexe et non le seul filtrage IP.
Si j'ai bien compris, le gros souci avec Kerio 2.x,
Je les ai accumulé ce jour là :( J'étais parti sur Kerio 4.x
c'est qu'on peut envoyer un paquet IP en deux morceaux -- Windows reconstitue le paquet en aval de Kerio, ce qui fait que ce dernier ne voit pas le paquet en entier, et peut donc laisser passer des paquets dangereux.
C'est valable dans les deux sens, tous paquets fragmentés qui entre ou sort ne passe pas entre les mains de Kerio 2.x, ce qui constitue effectivement une faille. Cela dit, à l'heure actuelle il ne doit plus y avoir des masses d'attaques/malwares ciblants cette faille, mais il suffit d'une fois.
Fabien LE LEZ devait dire quelque chose comme ceci :
Cela étant dit, les tests effectués concernent en fait le comportement
annexe et non le seul filtrage IP.
Si j'ai bien compris, le gros souci avec Kerio 2.x,
Je les ai accumulé ce jour là :( J'étais parti sur Kerio 4.x
c'est qu'on peut envoyer un paquet IP en deux morceaux -- Windows
reconstitue le paquet en aval de Kerio, ce qui fait que ce dernier ne
voit pas le paquet en entier, et peut donc laisser passer des paquets
dangereux.
C'est valable dans les deux sens, tous paquets fragmentés qui entre ou
sort ne passe pas entre les mains de Kerio 2.x, ce qui constitue
effectivement une faille. Cela dit, à l'heure actuelle il ne doit plus
y avoir des masses d'attaques/malwares ciblants cette faille, mais il
suffit d'une fois.
Fabien LE LEZ devait dire quelque chose comme ceci :
Cela étant dit, les tests effectués concernent en fait le comportement annexe et non le seul filtrage IP.
Si j'ai bien compris, le gros souci avec Kerio 2.x,
Je les ai accumulé ce jour là :( J'étais parti sur Kerio 4.x
c'est qu'on peut envoyer un paquet IP en deux morceaux -- Windows reconstitue le paquet en aval de Kerio, ce qui fait que ce dernier ne voit pas le paquet en entier, et peut donc laisser passer des paquets dangereux.
C'est valable dans les deux sens, tous paquets fragmentés qui entre ou sort ne passe pas entre les mains de Kerio 2.x, ce qui constitue effectivement une faille. Cela dit, à l'heure actuelle il ne doit plus y avoir des masses d'attaques/malwares ciblants cette faille, mais il suffit d'une fois.
Stephane Catteau
Fabien LE LEZ devait dire quelque chose comme ceci :
Celui de ton système d'exploitation (firewall de Windows) couplé à celui de ta box (Freebox, etc...) est ahma bien suffisant.
Aucun des deux n'est capable d'empêcher un programme précis (par exemple, iexplore.exe) de sortir.
Pis je suis chez Free avec une box, *et* chez Orange avec un modem traditionnel, ce qui n'arrange rien au problème ;)
Fabien LE LEZ devait dire quelque chose comme ceci :
Celui de ton système d'exploitation (firewall de Windows)
couplé à celui de ta box (Freebox, etc...) est ahma bien
suffisant.
Aucun des deux n'est capable d'empêcher un programme précis (par
exemple, iexplore.exe) de sortir.
Pis je suis chez Free avec une box, *et* chez Orange avec un modem
traditionnel, ce qui n'arrange rien au problème ;)
Fabien LE LEZ devait dire quelque chose comme ceci :
Celui de ton système d'exploitation (firewall de Windows) couplé à celui de ta box (Freebox, etc...) est ahma bien suffisant.
Aucun des deux n'est capable d'empêcher un programme précis (par exemple, iexplore.exe) de sortir.
Pis je suis chez Free avec une box, *et* chez Orange avec un modem traditionnel, ce qui n'arrange rien au problème ;)
Stephane Catteau
Ludovic - F5PBG devait dire quelque chose comme ceci :
Aucun des deux n'est capable d'empêcher un programme précis (par exemple, iexplore.exe) de sortir.
Le but est d'éviter que cela rentre...
Ben non. Le but d'un firewall est d'éviter que cela rentre *et* que cela sorte.
Mais ta réponse est toutefois erronée en ce qui concerne la livebox qui filtre les ports en sortie, à condition bien sûr de paramétrer correctement le firewall de la livebox.
Sa réponse était au contraire tout ce qu'il y a de plus correct.
-- Il faudrait quand même voir à se rappeler que si j'ai aussi honte d'avoir posé cette question, c'est parce que j'étais l'auteur et le mainteneur de la FAQ du forum sur les firewalls
Ludovic - F5PBG devait dire quelque chose comme ceci :
Aucun des deux n'est capable d'empêcher un programme précis (par
exemple, iexplore.exe) de sortir.
Le but est d'éviter que cela rentre...
Ben non. Le but d'un firewall est d'éviter que cela rentre *et* que
cela sorte.
Mais ta réponse est toutefois erronée en ce qui concerne
la livebox qui filtre les ports en sortie, à condition bien sûr
de paramétrer correctement le firewall de la livebox.
Sa réponse était au contraire tout ce qu'il y a de plus correct.
--
Il faudrait quand même voir à se rappeler que si j'ai aussi honte
d'avoir posé cette question, c'est parce que j'étais l'auteur et le
mainteneur de la FAQ du forum sur les firewalls
Ludovic - F5PBG devait dire quelque chose comme ceci :
Aucun des deux n'est capable d'empêcher un programme précis (par exemple, iexplore.exe) de sortir.
Le but est d'éviter que cela rentre...
Ben non. Le but d'un firewall est d'éviter que cela rentre *et* que cela sorte.
Mais ta réponse est toutefois erronée en ce qui concerne la livebox qui filtre les ports en sortie, à condition bien sûr de paramétrer correctement le firewall de la livebox.
Sa réponse était au contraire tout ce qu'il y a de plus correct.
-- Il faudrait quand même voir à se rappeler que si j'ai aussi honte d'avoir posé cette question, c'est parce que j'étais l'auteur et le mainteneur de la FAQ du forum sur les firewalls
Stephane Catteau
Ludovic - F5PBG n'était pas loin de dire :
Expliquez moi comment votre Livebox filtrera iexplore.exe tout en laissant passer firefox.exe ?
Inutile d'un firewall pour cela...
Ah ?
Dans Internet explorer : Outils>options internet>contenu>Activer le contrôle d'accès Placer toutes les options sur "limité"
Alors prenons un cas bien plus intéressant :
Empécher les versions 6.x et 7.x d'Opera d'accéder aux serveurs de pub qui leur sont liés, tout en leur permettant un accès total au reste du vaste monde et en permettant aux autres navigateur d'y accéder, dès fois qu'il y ait des serveurs intéressants sur mes mêmes adresses IP.
Ludovic - F5PBG n'était pas loin de dire :
Expliquez moi comment votre Livebox filtrera iexplore.exe tout en
laissant passer firefox.exe ?
Inutile d'un firewall pour cela...
Ah ?
Dans Internet explorer :
Outils>options internet>contenu>Activer le contrôle d'accès
Placer toutes les options sur "limité"
Alors prenons un cas bien plus intéressant :
Empécher les versions 6.x et 7.x d'Opera d'accéder aux serveurs de pub
qui leur sont liés, tout en leur permettant un accès total au reste du
vaste monde et en permettant aux autres navigateur d'y accéder, dès
fois qu'il y ait des serveurs intéressants sur mes mêmes adresses IP.
Expliquez moi comment votre Livebox filtrera iexplore.exe tout en laissant passer firefox.exe ?
Inutile d'un firewall pour cela...
Ah ?
Dans Internet explorer : Outils>options internet>contenu>Activer le contrôle d'accès Placer toutes les options sur "limité"
Alors prenons un cas bien plus intéressant :
Empécher les versions 6.x et 7.x d'Opera d'accéder aux serveurs de pub qui leur sont liés, tout en leur permettant un accès total au reste du vaste monde et en permettant aux autres navigateur d'y accéder, dès fois qu'il y ait des serveurs intéressants sur mes mêmes adresses IP.
Stephane Catteau
Roland Garcia devait dire quelque chose comme ceci :
Expliquez moi comment votre Livebox filtrera iexplore.exe tout en laissant passer firefox.exe ?
Inutile d'un firewall pour cela...
Dans Internet explorer : Outils>options internet>contenu>Activer le contrôle d'accès Placer toutes les options sur "limité"
Au revoir...
Ah ? et comment ferez vous pour mechant-trojan.exe ?
Il a pas une option l'empéchant d'accéder au réseau ? Pff, il est mal fait...
Roland Garcia devait dire quelque chose comme ceci :
Expliquez moi comment votre Livebox filtrera iexplore.exe tout en
laissant passer firefox.exe ?
Inutile d'un firewall pour cela...
Dans Internet explorer :
Outils>options internet>contenu>Activer le contrôle d'accès
Placer toutes les options sur "limité"
Au revoir...
Ah ? et comment ferez vous pour mechant-trojan.exe ?
Il a pas une option l'empéchant d'accéder au réseau ? Pff, il est mal
fait...
Roland Garcia devait dire quelque chose comme ceci :
Expliquez moi comment votre Livebox filtrera iexplore.exe tout en laissant passer firefox.exe ?
Inutile d'un firewall pour cela...
Dans Internet explorer : Outils>options internet>contenu>Activer le contrôle d'accès Placer toutes les options sur "limité"
Au revoir...
Ah ? et comment ferez vous pour mechant-trojan.exe ?
Il a pas une option l'empéchant d'accéder au réseau ? Pff, il est mal fait...
Si, l'option existe : elle est dans les réglages de l'interface chaise-clavier.
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Pascal Hambourg
Stephane Catteau a écrit :
- La "pile IP" est l'organisation des différentes couches (par exemple, IP -> UDP -> application), avec la gestion des headers successifs (header IP -> header UDP -> données).
Je n'ai jamais vraiment compris pourquoi on l'appellait "pile"
Parce que c'est un empilement de couches : physique, liaison, réseau, transport...
Dans le lot il y a aussi la pile, non ordonnée, qui s'occupe de gérer les paquets fragmentés.
Ça fait partie de la couche IP.
Par ailleurs, par "connexion", on entend "connexion TCP" -- il y a peut-être d'autres types en laboratoire, mais pas dans la nature.
SCTP Notamment. Très séduisant, mais peu utilisé à cause de l'omniprésence de TCP.
Pour ceux que ça intéresse, ma connerie venait de l'architecture de mon LAN, avec un routeur/filtre IP/Nat devant les machines serveurs.
Dans ce cas la couche TCP du routeur n'intervient pas de toute façon pour les connexions dont il n'est pas la cible et qu'il ne fait que router/NATer.
Stephane Catteau a écrit :
- La "pile IP" est l'organisation des différentes couches (par
exemple, IP -> UDP -> application), avec la gestion des headers
successifs (header IP -> header UDP -> données).
Je n'ai jamais vraiment compris pourquoi on l'appellait "pile"
Parce que c'est un empilement de couches : physique, liaison, réseau,
transport...
Dans le lot il y a aussi
la pile, non ordonnée, qui s'occupe de gérer les paquets fragmentés.
Ça fait partie de la couche IP.
Par ailleurs, par "connexion", on entend "connexion TCP" -- il y a
peut-être d'autres types en laboratoire, mais pas dans la nature.
SCTP Notamment. Très séduisant, mais peu utilisé à cause de
l'omniprésence de TCP.
Pour ceux que ça intéresse, ma connerie venait de l'architecture de
mon LAN, avec un routeur/filtre IP/Nat devant les machines serveurs.
Dans ce cas la couche TCP du routeur n'intervient pas de toute façon
pour les connexions dont il n'est pas la cible et qu'il ne fait que
router/NATer.
- La "pile IP" est l'organisation des différentes couches (par exemple, IP -> UDP -> application), avec la gestion des headers successifs (header IP -> header UDP -> données).
Je n'ai jamais vraiment compris pourquoi on l'appellait "pile"
Parce que c'est un empilement de couches : physique, liaison, réseau, transport...
Dans le lot il y a aussi la pile, non ordonnée, qui s'occupe de gérer les paquets fragmentés.
Ça fait partie de la couche IP.
Par ailleurs, par "connexion", on entend "connexion TCP" -- il y a peut-être d'autres types en laboratoire, mais pas dans la nature.
SCTP Notamment. Très séduisant, mais peu utilisé à cause de l'omniprésence de TCP.
Pour ceux que ça intéresse, ma connerie venait de l'architecture de mon LAN, avec un routeur/filtre IP/Nat devant les machines serveurs.
Dans ce cas la couche TCP du routeur n'intervient pas de toute façon pour les connexions dont il n'est pas la cible et qu'il ne fait que router/NATer.
Stephane Catteau
Pascal Hambourg n'était pas loin de dire :
Pour ceux que ça intéresse, ma connerie venait de l'architecture de mon LAN, avec un routeur/filtre IP/Nat devant les machines serveurs.
Dans ce cas la couche TCP du routeur n'intervient pas de toute façon pour les connexions dont il n'est pas la cible et qu'il ne fait que router/NATer.
C'est une bête machine de récupération avec un packet filter dessus, donc sa fonction principale est de filtrer. Le nat est juste une conséquence de l'absence d'adresse IP routable attribuées aux machines qui sont derrière lui[1]. Comme la machine n'est pas configurée pour agir comme un bridge, il me semble peu probable qu'il y ait un transfert direct d'une interface à l'autre. Cela dit, maintenant que j'ai eu un peu plus de temps pour réfléchir au problème, le paquet ne doit probablement pas dépasser la couche réseau, puisque c'est à ce niveau là que la pile IP s'apercevra que le paquet ne lui est pas destiné et qu'elle le redirigera sur la bonne interface.
[1] D'ailleurs avant que la précédente machine ne me lache, c'était un simple filtre IP placé derrière la passerelle ; genre j'ai accumulé les raisons de bien m'embrouiller l'esprit au moment où j'allais avoir mon heure de gloire ;)
Pascal Hambourg n'était pas loin de dire :
Pour ceux que ça intéresse, ma connerie venait de l'architecture de
mon LAN, avec un routeur/filtre IP/Nat devant les machines serveurs.
Dans ce cas la couche TCP du routeur n'intervient pas de toute façon
pour les connexions dont il n'est pas la cible et qu'il ne fait que
router/NATer.
C'est une bête machine de récupération avec un packet filter dessus,
donc sa fonction principale est de filtrer. Le nat est juste une
conséquence de l'absence d'adresse IP routable attribuées aux machines
qui sont derrière lui[1]. Comme la machine n'est pas configurée pour
agir comme un bridge, il me semble peu probable qu'il y ait un
transfert direct d'une interface à l'autre.
Cela dit, maintenant que j'ai eu un peu plus de temps pour réfléchir
au problème, le paquet ne doit probablement pas dépasser la couche
réseau, puisque c'est à ce niveau là que la pile IP s'apercevra que le
paquet ne lui est pas destiné et qu'elle le redirigera sur la bonne
interface.
[1]
D'ailleurs avant que la précédente machine ne me lache, c'était un
simple filtre IP placé derrière la passerelle ; genre j'ai accumulé les
raisons de bien m'embrouiller l'esprit au moment où j'allais avoir mon
heure de gloire ;)
Pour ceux que ça intéresse, ma connerie venait de l'architecture de mon LAN, avec un routeur/filtre IP/Nat devant les machines serveurs.
Dans ce cas la couche TCP du routeur n'intervient pas de toute façon pour les connexions dont il n'est pas la cible et qu'il ne fait que router/NATer.
C'est une bête machine de récupération avec un packet filter dessus, donc sa fonction principale est de filtrer. Le nat est juste une conséquence de l'absence d'adresse IP routable attribuées aux machines qui sont derrière lui[1]. Comme la machine n'est pas configurée pour agir comme un bridge, il me semble peu probable qu'il y ait un transfert direct d'une interface à l'autre. Cela dit, maintenant que j'ai eu un peu plus de temps pour réfléchir au problème, le paquet ne doit probablement pas dépasser la couche réseau, puisque c'est à ce niveau là que la pile IP s'apercevra que le paquet ne lui est pas destiné et qu'elle le redirigera sur la bonne interface.
[1] D'ailleurs avant que la précédente machine ne me lache, c'était un simple filtre IP placé derrière la passerelle ; genre j'ai accumulé les raisons de bien m'embrouiller l'esprit au moment où j'allais avoir mon heure de gloire ;)
