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.
J'utilise depuis longtemps Kerio v2 et quelques, et je vois que personne n'en parle.
Si si, moi j'en ai parlé, comme solution de repli si je ne trouvais rien d'autre ;)
Est-il urgent que je change ? ;-)
Ca dépend. Kerio est vieux et il avait déjà quelques problèmes à l'époque. Pour te faire une idée, tu peux aller regarder ce qu'ils pensent de Sunbelt sur le comparatif pointé dans la discussion <http://www.matousec.com/projects/firewall-challenge/results.php>. Comme Sunbelt a repris Kerio, ce dernier passerait encore moins bien les tests. Cela étant dit, les tests effectués concernent en fait le comportement annexe et non le seul filtrage IP. Donc si tu as une utilisation saine de ton ordinateur, ce qui te mets à l'abris de 95% des virus/trojan et compagnie, tu n'as pas besoin de ces comportements annexes[1] et Kerio est parfaitement valable.
[1] A titre d'exemple, certains firewall sont maintenant capable de détecter qu'une application tierce est venue se greffer sur un programme autorisé à utiliser internet. Si tu ne risques pas d'avoir de malware, tu ne risques pas non plus d'avoir une application tierce qui viendrait se greffer blablabla. Du coup tu n'as pas non plus besoin de cette protection de la mort qui tue qu'elle est vachement super mais inutile pour toi.
siger devait dire quelque chose comme ceci :
J'utilise depuis longtemps Kerio v2 et quelques, et je vois que
personne n'en parle.
Si si, moi j'en ai parlé, comme solution de repli si je ne trouvais
rien d'autre ;)
Est-il urgent que je change ? ;-)
Ca dépend. Kerio est vieux et il avait déjà quelques problèmes à
l'époque. Pour te faire une idée, tu peux aller regarder ce qu'ils
pensent de Sunbelt sur le comparatif pointé dans la discussion
<http://www.matousec.com/projects/firewall-challenge/results.php>.
Comme Sunbelt a repris Kerio, ce dernier passerait encore moins bien
les tests.
Cela étant dit, les tests effectués concernent en fait le comportement
annexe et non le seul filtrage IP. Donc si tu as une utilisation saine
de ton ordinateur, ce qui te mets à l'abris de 95% des virus/trojan et
compagnie, tu n'as pas besoin de ces comportements annexes[1] et Kerio
est parfaitement valable.
[1]
A titre d'exemple, certains firewall sont maintenant capable de
détecter qu'une application tierce est venue se greffer sur un
programme autorisé à utiliser internet. Si tu ne risques pas d'avoir de
malware, tu ne risques pas non plus d'avoir une application tierce qui
viendrait se greffer blablabla. Du coup tu n'as pas non plus besoin de
cette protection de la mort qui tue qu'elle est vachement super mais
inutile pour toi.
J'utilise depuis longtemps Kerio v2 et quelques, et je vois que personne n'en parle.
Si si, moi j'en ai parlé, comme solution de repli si je ne trouvais rien d'autre ;)
Est-il urgent que je change ? ;-)
Ca dépend. Kerio est vieux et il avait déjà quelques problèmes à l'époque. Pour te faire une idée, tu peux aller regarder ce qu'ils pensent de Sunbelt sur le comparatif pointé dans la discussion <http://www.matousec.com/projects/firewall-challenge/results.php>. Comme Sunbelt a repris Kerio, ce dernier passerait encore moins bien les tests. Cela étant dit, les tests effectués concernent en fait le comportement annexe et non le seul filtrage IP. Donc si tu as une utilisation saine de ton ordinateur, ce qui te mets à l'abris de 95% des virus/trojan et compagnie, tu n'as pas besoin de ces comportements annexes[1] et Kerio est parfaitement valable.
[1] A titre d'exemple, certains firewall sont maintenant capable de détecter qu'une application tierce est venue se greffer sur un programme autorisé à utiliser internet. Si tu ne risques pas d'avoir de malware, tu ne risques pas non plus d'avoir une application tierce qui viendrait se greffer blablabla. Du coup tu n'as pas non plus besoin de cette protection de la mort qui tue qu'elle est vachement super mais inutile pour toi.
Christophe Bachmann
Stephane Catteau a écrit :
Pascal Hambourg devait dire quelque chose comme ceci :
5c) Le filtre IP rejète salement la connexion, il drop le paquet, ce qui coupe la connexion au niveau de la machine d'origine.
Les ports "stealth" à la Gibson rajoute un option : 5d) Le filtre IP refuse la connexion mais décide que c'est au client de la couper.
Dans les cas 5b et 5c, l'espace alloué est aussitôt libéré. Mais dans le cas 5d, l'espace alloué reste utilisé pendant une trentaine de seconde, délais moyen avant que le client ne décide qu'il y a TimeOut pour la connexion.
Je comprends mal la différence entre le 5c et le 5d. En quoi le fait de dropper le paquet et laisser mourir la connection par time-out diffère-t-il de bloquer le paquet et laisser mourir la connection par time-out, du point de vue de la machine appelante ?
Et dans ce cas, pourquoi implémenter spécifiquement un cas 5d et ne pas utiliser un cas 5c ? -- Greetings, Salutations, Guiraud Belissen, Château du Ciel, Drachenwald, Chris CII, Rennes, France
Stephane Catteau a écrit :
Pascal Hambourg devait dire quelque chose comme ceci :
5c) Le filtre IP rejète salement la connexion, il drop le paquet, ce
qui coupe la connexion au niveau de la machine d'origine.
Les ports "stealth" à la Gibson rajoute un option :
5d) Le filtre IP refuse la connexion mais décide que c'est au client de
la couper.
Dans les cas 5b et 5c, l'espace alloué est aussitôt libéré.
Mais dans le cas 5d, l'espace alloué reste utilisé pendant une
trentaine de seconde, délais moyen avant que le client ne décide qu'il
y a TimeOut pour la connexion.
Je comprends mal la différence entre le 5c et le 5d. En quoi le fait de
dropper le paquet et laisser mourir la connection par time-out
diffère-t-il de bloquer le paquet et laisser mourir la connection par
time-out, du point de vue de la machine appelante ?
Et dans ce cas, pourquoi implémenter spécifiquement un cas 5d et ne pas
utiliser un cas 5c ?
--
Greetings, Salutations,
Guiraud Belissen, Château du Ciel, Drachenwald,
Chris CII, Rennes, France
Pascal Hambourg devait dire quelque chose comme ceci :
5c) Le filtre IP rejète salement la connexion, il drop le paquet, ce qui coupe la connexion au niveau de la machine d'origine.
Les ports "stealth" à la Gibson rajoute un option : 5d) Le filtre IP refuse la connexion mais décide que c'est au client de la couper.
Dans les cas 5b et 5c, l'espace alloué est aussitôt libéré. Mais dans le cas 5d, l'espace alloué reste utilisé pendant une trentaine de seconde, délais moyen avant que le client ne décide qu'il y a TimeOut pour la connexion.
Je comprends mal la différence entre le 5c et le 5d. En quoi le fait de dropper le paquet et laisser mourir la connection par time-out diffère-t-il de bloquer le paquet et laisser mourir la connection par time-out, du point de vue de la machine appelante ?
Et dans ce cas, pourquoi implémenter spécifiquement un cas 5d et ne pas utiliser un cas 5c ? -- Greetings, Salutations, Guiraud Belissen, Château du Ciel, Drachenwald, Chris CII, Rennes, France
Fabien LE LEZ
>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...
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).
- La pile TCP (ou TCP/IP) est le mécanisme de suivi des connexions TCP en cours.
Par ailleurs, par "connexion", on entend "connexion TCP" -- il y a peut-être d'autres types en laboratoire, mais pas dans la nature.
Quand la machine-source veut ouvrir une connexion TCP sur la machine-cible, elle lui envoie un paquet SYN.
Si la machine-cible le reçoit, elle vérifie : - que le(s) filtre(s) IP le considère(nt) comme acceptable ; - qu'une application est en mesure d'accepter la connexion (i.e. écoute sur le port).
Si toutes les connexions sont réunies, la machine-cible alloue les ressources sur la pile TCP pour gérer la connexion, et envoie un paquet SYN-ACK.
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.
Ça, c'est bien sûr dans le cas idéal. Si le firewall est foireux, il peut refuser la connexion (avec ou sans envoi de RST), mais laisser la pile TCP de la machine allouer de l'espace pour la connexion "fantôme". Mais c'est un bug du logiciel en question, pas un problème avec la méthode.
Voilà donc ce que j'ai compris. Est-ce exact ? Complètement faux ? Autre chose ?
Merci d'avance pour vos commentaires...
>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...
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).
- La pile TCP (ou TCP/IP) est le mécanisme de suivi des connexions TCP
en cours.
Par ailleurs, par "connexion", on entend "connexion TCP" -- il y a
peut-être d'autres types en laboratoire, mais pas dans la nature.
Quand la machine-source veut ouvrir une connexion TCP sur la
machine-cible, elle lui envoie un paquet SYN.
Si la machine-cible le reçoit, elle vérifie :
- que le(s) filtre(s) IP le considère(nt) comme acceptable ;
- qu'une application est en mesure d'accepter la connexion (i.e.
écoute sur le port).
Si toutes les connexions sont réunies, la machine-cible alloue les
ressources sur la pile TCP pour gérer la connexion, et envoie un
paquet SYN-ACK.
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.
Ça, c'est bien sûr dans le cas idéal. Si le firewall est foireux, il
peut refuser la connexion (avec ou sans envoi de RST), mais laisser la
pile TCP de la machine allouer de l'espace pour la connexion
"fantôme". Mais c'est un bug du logiciel en question, pas un problème
avec la méthode.
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...
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).
- La pile TCP (ou TCP/IP) est le mécanisme de suivi des connexions TCP en cours.
Par ailleurs, par "connexion", on entend "connexion TCP" -- il y a peut-être d'autres types en laboratoire, mais pas dans la nature.
Quand la machine-source veut ouvrir une connexion TCP sur la machine-cible, elle lui envoie un paquet SYN.
Si la machine-cible le reçoit, elle vérifie : - que le(s) filtre(s) IP le considère(nt) comme acceptable ; - qu'une application est en mesure d'accepter la connexion (i.e. écoute sur le port).
Si toutes les connexions sont réunies, la machine-cible alloue les ressources sur la pile TCP pour gérer la connexion, et envoie un paquet SYN-ACK.
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.
Ça, c'est bien sûr dans le cas idéal. Si le firewall est foireux, il peut refuser la connexion (avec ou sans envoi de RST), mais laisser la pile TCP de la machine allouer de l'espace pour la connexion "fantôme". Mais c'est un bug du logiciel en question, pas un problème avec la méthode.
Voilà donc ce que j'ai compris. Est-ce exact ? Complètement faux ? Autre chose ?
Merci d'avance pour vos commentaires...
Fabien LE LEZ
On Sun, 19 Apr 2009 20:42:12 +0200, Stephane Catteau :
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, 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.
Sunbelt
Rien à voir. Sunbelt est basé sur Kerio 4.x, qui n'a pas ce problème.
On Sun, 19 Apr 2009 20:42:12 +0200, Stephane Catteau
<steph.nospam@sc4x.net>:
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, 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.
Sunbelt
Rien à voir. Sunbelt est basé sur Kerio 4.x, qui n'a pas ce problème.
On Sun, 19 Apr 2009 20:42:12 +0200, Stephane Catteau :
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, 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.
Sunbelt
Rien à voir. Sunbelt est basé sur Kerio 4.x, qui n'a pas ce problème.
Pascal Hambourg
Stephane Catteau a écrit :
Résumé du fonctionnement standard d'une connexion entrante :
1) La machine d'origine essaie de se connecter sur le port xy 2) La machine cible reçoit une demande de connexion vers le port xy 3) La pile IP prend en charge cette demande de connexion et alloue l'espace nécessaire pour la traiter. 4) Le filtre IP prend le relais et décide de ce qu'il va faire.
Dans l'infrastructure netfilter du noyau Linux utilisée par iptables, ce n'est pas comme ça que ça marche. Le hook d'entrée d'iptables se trouve en amont du code de la couche TCP. Si le paquet de demande de connexion est rejeté avec une réponse à l'émetteur (cible REJECT) ou bloqué silencieusement (cible DROP), alors le code de la couche TCP ne le voit pas et n'alloue rien. A noter que si iptables rejette le paquet avec un TCP RST ou un ICMP destination unreachable, c'est le code d'iptables et non de la couche TCP de la pile qui envoie le paquet de réponse.
5c) Le filtre IP rejète salement la connexion, il drop le paquet, ce qui coupe la connexion au niveau de la machine d'origine.
Les ports "stealth" à la Gibson rajoute un option : 5d) Le filtre IP refuse la connexion mais décide que c'est au client de la couper.
Comme Christophe j'ai du mal à voir la différence entre les deux.
Stephane Catteau a écrit :
Résumé du fonctionnement standard d'une connexion entrante :
1) La machine d'origine essaie de se connecter sur le port xy
2) La machine cible reçoit une demande de connexion vers le port xy
3) La pile IP prend en charge cette demande de connexion et alloue
l'espace nécessaire pour la traiter.
4) Le filtre IP prend le relais et décide de ce qu'il va faire.
Dans l'infrastructure netfilter du noyau Linux utilisée par iptables, ce
n'est pas comme ça que ça marche. Le hook d'entrée d'iptables se trouve
en amont du code de la couche TCP. Si le paquet de demande de connexion
est rejeté avec une réponse à l'émetteur (cible REJECT) ou bloqué
silencieusement (cible DROP), alors le code de la couche TCP ne le voit
pas et n'alloue rien. A noter que si iptables rejette le paquet avec un
TCP RST ou un ICMP destination unreachable, c'est le code d'iptables et
non de la couche TCP de la pile qui envoie le paquet de réponse.
5c) Le filtre IP rejète salement la connexion, il drop le paquet, ce
qui coupe la connexion au niveau de la machine d'origine.
Les ports "stealth" à la Gibson rajoute un option :
5d) Le filtre IP refuse la connexion mais décide que c'est au client de
la couper.
Comme Christophe j'ai du mal à voir la différence entre les deux.
Résumé du fonctionnement standard d'une connexion entrante :
1) La machine d'origine essaie de se connecter sur le port xy 2) La machine cible reçoit une demande de connexion vers le port xy 3) La pile IP prend en charge cette demande de connexion et alloue l'espace nécessaire pour la traiter. 4) Le filtre IP prend le relais et décide de ce qu'il va faire.
Dans l'infrastructure netfilter du noyau Linux utilisée par iptables, ce n'est pas comme ça que ça marche. Le hook d'entrée d'iptables se trouve en amont du code de la couche TCP. Si le paquet de demande de connexion est rejeté avec une réponse à l'émetteur (cible REJECT) ou bloqué silencieusement (cible DROP), alors le code de la couche TCP ne le voit pas et n'alloue rien. A noter que si iptables rejette le paquet avec un TCP RST ou un ICMP destination unreachable, c'est le code d'iptables et non de la couche TCP de la pile qui envoie le paquet de réponse.
5c) Le filtre IP rejète salement la connexion, il drop le paquet, ce qui coupe la connexion au niveau de la machine d'origine.
Les ports "stealth" à la Gibson rajoute un option : 5d) Le filtre IP refuse la connexion mais décide que c'est au client de la couper.
Comme Christophe j'ai du mal à voir la différence entre les deux.
MELMOTH
Ce cher mammifère du nom de Fabien LE LEZ nous susurrait, le dimanche 19/04/2009, dans nos oreilles grandes ouvertes mais un peu sales tout de même, et dans le message , les doux mélismes suivants :
J'ai de gros problèmes pour comprendre ton message, et j'aimerais bien qu'on m'explique...
+ 1... Je n'ai _jamais_ rien compris au baratin de Catteau !... Il devrait pourtant bien savoir que "ce qui se conçoit bien s'énonce *clairement* "...
-- Car avec beaucoup de science, il y a beaucoup de chagrin ; et celui qui accroît sa science, accroît sa douleur. [Ecclésiaste, 1-18] MELMOTH - souffrant
Ce cher mammifère du nom de Fabien LE LEZ nous susurrait, le dimanche
19/04/2009, dans nos oreilles grandes ouvertes mais un peu sales tout
de même, et dans le message
<gdumu49udliaml9kk8iekeba9r96o55ohm@4ax.com>, les doux mélismes
suivants :
J'ai de gros problèmes pour comprendre ton message, et j'aimerais
bien qu'on m'explique...
+ 1...
Je n'ai _jamais_ rien compris au baratin de Catteau !...
Il devrait pourtant bien savoir que "ce qui se conçoit bien s'énonce
*clairement* "...
--
Car avec beaucoup de science, il y a beaucoup de chagrin ; et celui qui
accroît sa science, accroît sa douleur.
[Ecclésiaste, 1-18]
MELMOTH - souffrant
Ce cher mammifère du nom de Fabien LE LEZ nous susurrait, le dimanche 19/04/2009, dans nos oreilles grandes ouvertes mais un peu sales tout de même, et dans le message , les doux mélismes suivants :
J'ai de gros problèmes pour comprendre ton message, et j'aimerais bien qu'on m'explique...
+ 1... Je n'ai _jamais_ rien compris au baratin de Catteau !... Il devrait pourtant bien savoir que "ce qui se conçoit bien s'énonce *clairement* "...
-- Car avec beaucoup de science, il y a beaucoup de chagrin ; et celui qui accroît sa science, accroît sa douleur. [Ecclésiaste, 1-18] MELMOTH - souffrant
Pascal Hambourg
MELMOTH a écrit :
Il devrait pourtant bien savoir que "ce qui se conçoit bien s'énonce *clairement* "...
Le type qui a proféré cette énormité n'a sûrement jamais fait d'informatique.
MELMOTH a écrit :
Il devrait pourtant bien savoir que "ce qui se conçoit bien s'énonce
*clairement* "...
Le type qui a proféré cette énormité n'a sûrement jamais fait
d'informatique.
Il devrait pourtant bien savoir que "ce qui se conçoit bien s'énonce *clairement* "...
Le type qui a proféré cette énormité n'a sûrement jamais fait d'informatique.
Nicolas Boileau ? Non en effet :-)
-- Vivien Moreau / Tuxicomane
MELMOTH
Ce cher mammifère du nom de Pascal Hambourg nous susurrait, le lundi 20/04/2009, dans nos oreilles grandes ouvertes mais un peu sales tout de même, et dans le message <gshdo5$m6d$, les doux mélismes suivants :
Le type qui a proféré cette énormité n'a sûrement jamais fait d'informatique.
-- Car avec beaucoup de science, il y a beaucoup de chagrin ; et celui qui accroît sa science, accroît sa douleur. [Ecclésiaste, 1-18] MELMOTH - souffrant
Ce cher mammifère du nom de Pascal Hambourg nous susurrait, le lundi
20/04/2009, dans nos oreilles grandes ouvertes mais un peu sales tout
de même, et dans le message <gshdo5$m6d$3@saria.nerim.net>, les doux
mélismes suivants :
Le type qui a proféré cette énormité n'a sûrement jamais fait
d'informatique.
--
Car avec beaucoup de science, il y a beaucoup de chagrin ; et celui qui
accroît sa science, accroît sa douleur.
[Ecclésiaste, 1-18]
MELMOTH - souffrant
Ce cher mammifère du nom de Pascal Hambourg nous susurrait, le lundi 20/04/2009, dans nos oreilles grandes ouvertes mais un peu sales tout de même, et dans le message <gshdo5$m6d$, les doux mélismes suivants :
Le type qui a proféré cette énormité n'a sûrement jamais fait d'informatique.
-- Car avec beaucoup de science, il y a beaucoup de chagrin ; et celui qui accroît sa science, accroît sa douleur. [Ecclésiaste, 1-18] MELMOTH - souffrant
Az Sam
"Fabien LE LEZ" a écrit dans le message de news:
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.
moi ce que j'ai compris dans l'explication de S. Catteau, c'est ce qu'il decrit _sur la machine cible_ en fin de paragraphe. c'est a dire que en cas de drop, l'espace est libéré sur la machine qui recoit tandis qu'en cas de stealth, l'expace reste alloué jusqu'a time out.
Maintenant est ce bien ce meccanisme (time out de la cible ??), je vous lis avec attention ;-)
-- Cordialement, Az Sam.
"Fabien LE LEZ" <gramster@gramster.com> a écrit dans le message de news:
gdumu49udliaml9kk8iekeba9r96o55ohm@4ax.com...
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.
moi ce que j'ai compris dans l'explication de S. Catteau, c'est ce qu'il decrit
_sur la machine cible_ en fin de paragraphe.
c'est a dire que en cas de drop, l'espace est libéré sur la machine qui recoit
tandis qu'en cas de stealth, l'expace reste alloué jusqu'a time out.
Maintenant est ce bien ce meccanisme (time out de la cible ??), je vous lis avec
attention ;-)
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.
moi ce que j'ai compris dans l'explication de S. Catteau, c'est ce qu'il decrit _sur la machine cible_ en fin de paragraphe. c'est a dire que en cas de drop, l'espace est libéré sur la machine qui recoit tandis qu'en cas de stealth, l'expace reste alloué jusqu'a time out.
Maintenant est ce bien ce meccanisme (time out de la cible ??), je vous lis avec attention ;-)
