Le 07/03/2005, JacK [MVP] a gravé dans les archives du groupe :Ton test ne prouve absolument rien : ce n'est pas parce que tu bloques le
ICMP entrant que tu n'as pas de réponse à une requête *sortante* que tu as
initiée ,pour ton FW c'est du OUT et pas du IN.
Il était temps que tu arrives, JacK :-)
Il nous sort le même baratin sur "Pare-feux" depuis hier >:|
Merci de tes explications techniques ;-)
Le 07/03/2005, JacK [MVP] a gravé dans les archives du groupe :
Ton test ne prouve absolument rien : ce n'est pas parce que tu bloques le
ICMP entrant que tu n'as pas de réponse à une requête *sortante* que tu as
initiée ,pour ton FW c'est du OUT et pas du IN.
Il était temps que tu arrives, JacK :-)
Il nous sort le même baratin sur "Pare-feux" depuis hier >:|
Merci de tes explications techniques ;-)
Le 07/03/2005, JacK [MVP] a gravé dans les archives du groupe :Ton test ne prouve absolument rien : ce n'est pas parce que tu bloques le
ICMP entrant que tu n'as pas de réponse à une requête *sortante* que tu as
initiée ,pour ton FW c'est du OUT et pas du IN.
Il était temps que tu arrives, JacK :-)
Il nous sort le même baratin sur "Pare-feux" depuis hier >:|
Merci de tes explications techniques ;-)
JacK [MVP] a écrit le 07/03/2005 :Ton test ne prouve absolument rien : ce n'est pas parce que tu bloques le
ICMP entrant que tu n'as pas de réponse à une requête *sortante* que tu as
initiée ,pour ton FW c'est du OUT et pas du IN.
Erreur votre honneur !
La réponse à un Ping est bien du IN (cce n'est pas le résultat de ton OUT,
mais bien un *nouveau* message, qui lui, est IN.
JacK [MVP] a écrit le 07/03/2005 :
Ton test ne prouve absolument rien : ce n'est pas parce que tu bloques le
ICMP entrant que tu n'as pas de réponse à une requête *sortante* que tu as
initiée ,pour ton FW c'est du OUT et pas du IN.
Erreur votre honneur !
La réponse à un Ping est bien du IN (cce n'est pas le résultat de ton OUT,
mais bien un *nouveau* message, qui lui, est IN.
JacK [MVP] a écrit le 07/03/2005 :Ton test ne prouve absolument rien : ce n'est pas parce que tu bloques le
ICMP entrant que tu n'as pas de réponse à une requête *sortante* que tu as
initiée ,pour ton FW c'est du OUT et pas du IN.
Erreur votre honneur !
La réponse à un Ping est bien du IN (cce n'est pas le résultat de ton OUT,
mais bien un *nouveau* message, qui lui, est IN.
Laurent a utilisé son clavier pour écrire :JacK [MVP] a écrit le 07/03/2005 :Ton test ne prouve absolument rien : ce n'est pas parce que tu bloques le
ICMP entrant que tu n'as pas de réponse à une requête *sortante* que tu as
initiée ,pour ton FW c'est du OUT et pas du IN.
Erreur votre honneur !
La réponse à un Ping est bien du IN (cce n'est pas le résultat de ton OUT,
mais bien un *nouveau* message, qui lui, est IN.
Non, pas du point de vue de ton FW, quel qu'il soit : consulter rfc1575
C'est bien possible que la rfc dise cela, je ne suis pas un
De même que si tu appelles une page depuis un serveur en envoyant HTTP une
requête sur le port 80, les données proviennent bien de l'extérieur mais
comme c'est bien toi qui a sollicité la connexion, ton FW considère que c'est
du OUT.
Sur ce point, je suis OK... et le comportement de Kerio aussi.
Par contre, si tu *réponds* à un Echo Request (ICMP Type 8) venant de
l'extérieur (cad du IN) les données envoyées en réponse depuis ton PC (Echo
Reply Type 0 ) sont considérées comme du IN par ton FW
Voir par RFC 792
Même réponse que sur ton 1er point
Je n'ai pas dit que la faille n'existait pas, je crois me souvenir l'avoir lu
quelque part il y a plus d'un an mais je n'utilise plus KPF depuis longtemps,
je signale simplement que si la faille est avérée et que si le FW laisse
passer les echo request remote fragmentés, tout ce que ça peut engendrer,
c'est un DDoS si ta machine est spécialement ciblée par un attaquant qui doit
déjà connaître ton IP, ce n'est en aucun cas une technique utilisée par les
SK pour trouver des machines vulnérables.
Si le seul pb est sur les ping fragmentés, bien sur qu'il n'y a quasi
Laurent a utilisé son clavier pour écrire :
JacK [MVP] a écrit le 07/03/2005 :
Ton test ne prouve absolument rien : ce n'est pas parce que tu bloques le
ICMP entrant que tu n'as pas de réponse à une requête *sortante* que tu as
initiée ,pour ton FW c'est du OUT et pas du IN.
Erreur votre honneur !
La réponse à un Ping est bien du IN (cce n'est pas le résultat de ton OUT,
mais bien un *nouveau* message, qui lui, est IN.
Non, pas du point de vue de ton FW, quel qu'il soit : consulter rfc1575
C'est bien possible que la rfc dise cela, je ne suis pas un
De même que si tu appelles une page depuis un serveur en envoyant HTTP une
requête sur le port 80, les données proviennent bien de l'extérieur mais
comme c'est bien toi qui a sollicité la connexion, ton FW considère que c'est
du OUT.
Sur ce point, je suis OK... et le comportement de Kerio aussi.
Par contre, si tu *réponds* à un Echo Request (ICMP Type 8) venant de
l'extérieur (cad du IN) les données envoyées en réponse depuis ton PC (Echo
Reply Type 0 ) sont considérées comme du IN par ton FW
Voir par RFC 792
Même réponse que sur ton 1er point
Je n'ai pas dit que la faille n'existait pas, je crois me souvenir l'avoir lu
quelque part il y a plus d'un an mais je n'utilise plus KPF depuis longtemps,
je signale simplement que si la faille est avérée et que si le FW laisse
passer les echo request remote fragmentés, tout ce que ça peut engendrer,
c'est un DDoS si ta machine est spécialement ciblée par un attaquant qui doit
déjà connaître ton IP, ce n'est en aucun cas une technique utilisée par les
SK pour trouver des machines vulnérables.
Si le seul pb est sur les ping fragmentés, bien sur qu'il n'y a quasi
Laurent a utilisé son clavier pour écrire :JacK [MVP] a écrit le 07/03/2005 :Ton test ne prouve absolument rien : ce n'est pas parce que tu bloques le
ICMP entrant que tu n'as pas de réponse à une requête *sortante* que tu as
initiée ,pour ton FW c'est du OUT et pas du IN.
Erreur votre honneur !
La réponse à un Ping est bien du IN (cce n'est pas le résultat de ton OUT,
mais bien un *nouveau* message, qui lui, est IN.
Non, pas du point de vue de ton FW, quel qu'il soit : consulter rfc1575
C'est bien possible que la rfc dise cela, je ne suis pas un
De même que si tu appelles une page depuis un serveur en envoyant HTTP une
requête sur le port 80, les données proviennent bien de l'extérieur mais
comme c'est bien toi qui a sollicité la connexion, ton FW considère que c'est
du OUT.
Sur ce point, je suis OK... et le comportement de Kerio aussi.
Par contre, si tu *réponds* à un Echo Request (ICMP Type 8) venant de
l'extérieur (cad du IN) les données envoyées en réponse depuis ton PC (Echo
Reply Type 0 ) sont considérées comme du IN par ton FW
Voir par RFC 792
Même réponse que sur ton 1er point
Je n'ai pas dit que la faille n'existait pas, je crois me souvenir l'avoir lu
quelque part il y a plus d'un an mais je n'utilise plus KPF depuis longtemps,
je signale simplement que si la faille est avérée et que si le FW laisse
passer les echo request remote fragmentés, tout ce que ça peut engendrer,
c'est un DDoS si ta machine est spécialement ciblée par un attaquant qui doit
déjà connaître ton IP, ce n'est en aucun cas une technique utilisée par les
SK pour trouver des machines vulnérables.
Si le seul pb est sur les ping fragmentés, bien sur qu'il n'y a quasi
Laurent a utilisé son clavier pour écrire :JacK [MVP] a écrit le 07/03/2005 :Ton test ne prouve absolument rien : ce n'est pas parce que tu bloques
le ICMP entrant que tu n'as pas de réponse à une requête *sortante* que
tu as initiée ,pour ton FW c'est du OUT et pas du IN.
Erreur votre honneur !
La réponse à un Ping est bien du IN (cce n'est pas le résultat de ton
OUT, mais bien un *nouveau* message, qui lui, est IN.
Non, pas du point de vue de ton FW, quel qu'il soit : consulter rfc1575
De même que si tu appelles une page depuis un serveur en envoyant HTTP une
requête sur le port 80, les données proviennent bien de l'extérieur mais
comme c'est bien toi qui a sollicité la connexion, ton FW considère que
c'est du OUT.
Par contre, si tu *réponds* à un Echo Request (ICMP Type 8) venant de
l'extérieur (cad du IN) les données envoyées en réponse depuis ton PC
(Echo Reply Type 0 ) sont considérées comme du IN par ton FW
Voir par RFC 792
Je n'ai pas dit que la faille n'existait pas, je crois me souvenir l'avoir
lu quelque part il y a plus d'un an mais je n'utilise plus KPF depuis
longtemps, je signale simplement que si la faille est avérée et que si le
FW laisse passer les echo request remote fragmentés, tout ce que ça peut
engendrer, c'est un DDoS si ta machine est spécialement ciblée par un
attaquant qui doit déjà connaître ton IP, ce n'est en aucun cas une
technique utilisée par les SK pour trouver des machines vulnérables.
--
http://www.optimix.be.tf MVP Windows Security http://websecurite.org
http://www.msmvps.com/XPditif/ http://experts.microsoft.fr/longhorn4u/
Helping you void your warranty since 2000
---**ANTISPAM**---
Click on the link to answer -Cliquez sur le lien pour répondre
http://www.cerbermail.com/?csaLJS6yvZ
@(0)@ JacK
Laurent a utilisé son clavier pour écrire :
JacK [MVP] a écrit le 07/03/2005 :
Ton test ne prouve absolument rien : ce n'est pas parce que tu bloques
le ICMP entrant que tu n'as pas de réponse à une requête *sortante* que
tu as initiée ,pour ton FW c'est du OUT et pas du IN.
Erreur votre honneur !
La réponse à un Ping est bien du IN (cce n'est pas le résultat de ton
OUT, mais bien un *nouveau* message, qui lui, est IN.
Non, pas du point de vue de ton FW, quel qu'il soit : consulter rfc1575
De même que si tu appelles une page depuis un serveur en envoyant HTTP une
requête sur le port 80, les données proviennent bien de l'extérieur mais
comme c'est bien toi qui a sollicité la connexion, ton FW considère que
c'est du OUT.
Par contre, si tu *réponds* à un Echo Request (ICMP Type 8) venant de
l'extérieur (cad du IN) les données envoyées en réponse depuis ton PC
(Echo Reply Type 0 ) sont considérées comme du IN par ton FW
Voir par RFC 792
Je n'ai pas dit que la faille n'existait pas, je crois me souvenir l'avoir
lu quelque part il y a plus d'un an mais je n'utilise plus KPF depuis
longtemps, je signale simplement que si la faille est avérée et que si le
FW laisse passer les echo request remote fragmentés, tout ce que ça peut
engendrer, c'est un DDoS si ta machine est spécialement ciblée par un
attaquant qui doit déjà connaître ton IP, ce n'est en aucun cas une
technique utilisée par les SK pour trouver des machines vulnérables.
--
http://www.optimix.be.tf MVP Windows Security http://websecurite.org
http://www.msmvps.com/XPditif/ http://experts.microsoft.fr/longhorn4u/
Helping you void your warranty since 2000
---**ANTISPAM**---
Click on the link to answer -Cliquez sur le lien pour répondre
http://www.cerbermail.com/?csaLJS6yvZ
@(0)@ JacK
Laurent a utilisé son clavier pour écrire :JacK [MVP] a écrit le 07/03/2005 :Ton test ne prouve absolument rien : ce n'est pas parce que tu bloques
le ICMP entrant que tu n'as pas de réponse à une requête *sortante* que
tu as initiée ,pour ton FW c'est du OUT et pas du IN.
Erreur votre honneur !
La réponse à un Ping est bien du IN (cce n'est pas le résultat de ton
OUT, mais bien un *nouveau* message, qui lui, est IN.
Non, pas du point de vue de ton FW, quel qu'il soit : consulter rfc1575
De même que si tu appelles une page depuis un serveur en envoyant HTTP une
requête sur le port 80, les données proviennent bien de l'extérieur mais
comme c'est bien toi qui a sollicité la connexion, ton FW considère que
c'est du OUT.
Par contre, si tu *réponds* à un Echo Request (ICMP Type 8) venant de
l'extérieur (cad du IN) les données envoyées en réponse depuis ton PC
(Echo Reply Type 0 ) sont considérées comme du IN par ton FW
Voir par RFC 792
Je n'ai pas dit que la faille n'existait pas, je crois me souvenir l'avoir
lu quelque part il y a plus d'un an mais je n'utilise plus KPF depuis
longtemps, je signale simplement que si la faille est avérée et que si le
FW laisse passer les echo request remote fragmentés, tout ce que ça peut
engendrer, c'est un DDoS si ta machine est spécialement ciblée par un
attaquant qui doit déjà connaître ton IP, ce n'est en aucun cas une
technique utilisée par les SK pour trouver des machines vulnérables.
--
http://www.optimix.be.tf MVP Windows Security http://websecurite.org
http://www.msmvps.com/XPditif/ http://experts.microsoft.fr/longhorn4u/
Helping you void your warranty since 2000
---**ANTISPAM**---
Click on the link to answer -Cliquez sur le lien pour répondre
http://www.cerbermail.com/?csaLJS6yvZ
@(0)@ JacK
"JacK [MVP]" a écrit dans le message de news:Laurent a utilisé son clavier pour écrire :JacK [MVP] a écrit le 07/03/2005 :Ton test ne prouve absolument rien : ce n'est pas parce que tu bloques le
ICMP entrant que tu n'as pas de réponse à une requête *sortante* que tu
as initiée ,pour ton FW c'est du OUT et pas du IN.
Erreur votre honneur !
La réponse à un Ping est bien du IN (cce n'est pas le résultat de ton OUT,
mais bien un *nouveau* message, qui lui, est IN.
Non, pas du point de vue de ton FW, quel qu'il soit : consulter rfc1575
De même que si tu appelles une page depuis un serveur en envoyant HTTP une
requête sur le port 80, les données proviennent bien de l'extérieur mais
comme c'est bien toi qui a sollicité la connexion, ton FW considère que
c'est du OUT.
Par contre, si tu *réponds* à un Echo Request (ICMP Type 8) venant de
l'extérieur (cad du IN) les données envoyées en réponse depuis ton PC (Echo
Reply Type 0 ) sont considérées comme du IN par ton FW
Voir par RFC 792
Je n'ai pas dit que la faille n'existait pas, je crois me souvenir l'avoir
lu quelque part il y a plus d'un an mais je n'utilise plus KPF depuis
longtemps, je signale simplement que si la faille est avérée et que si le
FW laisse passer les echo request remote fragmentés, tout ce que ça peut
engendrer, c'est un DDoS si ta machine est spécialement ciblée par un
attaquant qui doit déjà connaître ton IP, ce n'est en aucun cas une
technique utilisée par les SK pour trouver des machines vulnérables.
-- http://www.optimix.be.tf MVP Windows Security http://websecurite.org
http://www.msmvps.com/XPditif/ http://experts.microsoft.fr/longhorn4u/
Helping you void your warranty since 2000
---**ANTISPAM**---
Click on the link to answer -Cliquez sur le lien pour répondre
http://www.cerbermail.com/?csaLJS6yvZ
@(0)@ JacK
Bonsoir Jack,
Bien que tout à fait d'accord avec le principe du IN et du OUT que tu
exposes, je viens de faire quelques tests avec Kerio 2.1.5, et effectivement,
il semble que sa façon de gérer l'ICMP est plus conforme avec ce que dit
Laurent qu'avec la théorie :-(
A savoir : avec une règle ICMP Out, et le niveau de sécurité moyen
(demander), un ping sort bien, mais sa réponse est bloquée. (J'avais une
règle blocant l'ICMP In, désactivée temporairement pour faire le test)
Est-ce le bon paramétrage ?
"JacK [MVP]" <ihatespam@wanamou.fr> a écrit dans le message de news:
mn.3cd17d53e6483b82.26509@wanamou.fr...
Laurent a utilisé son clavier pour écrire :
JacK [MVP] a écrit le 07/03/2005 :
Ton test ne prouve absolument rien : ce n'est pas parce que tu bloques le
ICMP entrant que tu n'as pas de réponse à une requête *sortante* que tu
as initiée ,pour ton FW c'est du OUT et pas du IN.
Erreur votre honneur !
La réponse à un Ping est bien du IN (cce n'est pas le résultat de ton OUT,
mais bien un *nouveau* message, qui lui, est IN.
Non, pas du point de vue de ton FW, quel qu'il soit : consulter rfc1575
De même que si tu appelles une page depuis un serveur en envoyant HTTP une
requête sur le port 80, les données proviennent bien de l'extérieur mais
comme c'est bien toi qui a sollicité la connexion, ton FW considère que
c'est du OUT.
Par contre, si tu *réponds* à un Echo Request (ICMP Type 8) venant de
l'extérieur (cad du IN) les données envoyées en réponse depuis ton PC (Echo
Reply Type 0 ) sont considérées comme du IN par ton FW
Voir par RFC 792
Je n'ai pas dit que la faille n'existait pas, je crois me souvenir l'avoir
lu quelque part il y a plus d'un an mais je n'utilise plus KPF depuis
longtemps, je signale simplement que si la faille est avérée et que si le
FW laisse passer les echo request remote fragmentés, tout ce que ça peut
engendrer, c'est un DDoS si ta machine est spécialement ciblée par un
attaquant qui doit déjà connaître ton IP, ce n'est en aucun cas une
technique utilisée par les SK pour trouver des machines vulnérables.
-- http://www.optimix.be.tf MVP Windows Security http://websecurite.org
http://www.msmvps.com/XPditif/ http://experts.microsoft.fr/longhorn4u/
Helping you void your warranty since 2000
---**ANTISPAM**---
Click on the link to answer -Cliquez sur le lien pour répondre
http://www.cerbermail.com/?csaLJS6yvZ
@(0)@ JacK
Bonsoir Jack,
Bien que tout à fait d'accord avec le principe du IN et du OUT que tu
exposes, je viens de faire quelques tests avec Kerio 2.1.5, et effectivement,
il semble que sa façon de gérer l'ICMP est plus conforme avec ce que dit
Laurent qu'avec la théorie :-(
A savoir : avec une règle ICMP Out, et le niveau de sécurité moyen
(demander), un ping sort bien, mais sa réponse est bloquée. (J'avais une
règle blocant l'ICMP In, désactivée temporairement pour faire le test)
Est-ce le bon paramétrage ?
"JacK [MVP]" a écrit dans le message de news:Laurent a utilisé son clavier pour écrire :JacK [MVP] a écrit le 07/03/2005 :Ton test ne prouve absolument rien : ce n'est pas parce que tu bloques le
ICMP entrant que tu n'as pas de réponse à une requête *sortante* que tu
as initiée ,pour ton FW c'est du OUT et pas du IN.
Erreur votre honneur !
La réponse à un Ping est bien du IN (cce n'est pas le résultat de ton OUT,
mais bien un *nouveau* message, qui lui, est IN.
Non, pas du point de vue de ton FW, quel qu'il soit : consulter rfc1575
De même que si tu appelles une page depuis un serveur en envoyant HTTP une
requête sur le port 80, les données proviennent bien de l'extérieur mais
comme c'est bien toi qui a sollicité la connexion, ton FW considère que
c'est du OUT.
Par contre, si tu *réponds* à un Echo Request (ICMP Type 8) venant de
l'extérieur (cad du IN) les données envoyées en réponse depuis ton PC (Echo
Reply Type 0 ) sont considérées comme du IN par ton FW
Voir par RFC 792
Je n'ai pas dit que la faille n'existait pas, je crois me souvenir l'avoir
lu quelque part il y a plus d'un an mais je n'utilise plus KPF depuis
longtemps, je signale simplement que si la faille est avérée et que si le
FW laisse passer les echo request remote fragmentés, tout ce que ça peut
engendrer, c'est un DDoS si ta machine est spécialement ciblée par un
attaquant qui doit déjà connaître ton IP, ce n'est en aucun cas une
technique utilisée par les SK pour trouver des machines vulnérables.
-- http://www.optimix.be.tf MVP Windows Security http://websecurite.org
http://www.msmvps.com/XPditif/ http://experts.microsoft.fr/longhorn4u/
Helping you void your warranty since 2000
---**ANTISPAM**---
Click on the link to answer -Cliquez sur le lien pour répondre
http://www.cerbermail.com/?csaLJS6yvZ
@(0)@ JacK
Bonsoir Jack,
Bien que tout à fait d'accord avec le principe du IN et du OUT que tu
exposes, je viens de faire quelques tests avec Kerio 2.1.5, et effectivement,
il semble que sa façon de gérer l'ICMP est plus conforme avec ce que dit
Laurent qu'avec la théorie :-(
A savoir : avec une règle ICMP Out, et le niveau de sécurité moyen
(demander), un ping sort bien, mais sa réponse est bloquée. (J'avais une
règle blocant l'ICMP In, désactivée temporairement pour faire le test)
Est-ce le bon paramétrage ?
En principe, avec un FW à règles, l'echo reply IN doit être autorisé pour ton
ou tes outils tel outil de ping ou de tracert et bloqué pour tout le reste.
En principe, avec un FW à règles, l'echo reply IN doit être autorisé pour ton
ou tes outils tel outil de ping ou de tracert et bloqué pour tout le reste.
En principe, avec un FW à règles, l'echo reply IN doit être autorisé pour ton
ou tes outils tel outil de ping ou de tracert et bloqué pour tout le reste.
Bonsoir Jack,
Bien que tout à fait d'accord avec le principe du IN et du OUT que tu
exposes, je viens de faire quelques tests avec Kerio 2.1.5, et effectivement,
il semble que sa façon de gérer l'ICMP est plus conforme avec ce que dit
Laurent qu'avec la théorie :-(
Merci
A savoir : avec une règle ICMP Out, et le niveau de sécurité moyen
(demander), un ping sort bien, mais sa réponse est bloquée. (J'avais une
règle blocant l'ICMP In, désactivée temporairement pour faire le test)
Est-ce le bon paramétrage ?
Mes règles habituelles concernant l'ICMP sont :
Bonsoir Jack,
Bien que tout à fait d'accord avec le principe du IN et du OUT que tu
exposes, je viens de faire quelques tests avec Kerio 2.1.5, et effectivement,
il semble que sa façon de gérer l'ICMP est plus conforme avec ce que dit
Laurent qu'avec la théorie :-(
Merci
A savoir : avec une règle ICMP Out, et le niveau de sécurité moyen
(demander), un ping sort bien, mais sa réponse est bloquée. (J'avais une
règle blocant l'ICMP In, désactivée temporairement pour faire le test)
Est-ce le bon paramétrage ?
Mes règles habituelles concernant l'ICMP sont :
Bonsoir Jack,
Bien que tout à fait d'accord avec le principe du IN et du OUT que tu
exposes, je viens de faire quelques tests avec Kerio 2.1.5, et effectivement,
il semble que sa façon de gérer l'ICMP est plus conforme avec ce que dit
Laurent qu'avec la théorie :-(
Merci
A savoir : avec une règle ICMP Out, et le niveau de sécurité moyen
(demander), un ping sort bien, mais sa réponse est bloquée. (J'avais une
règle blocant l'ICMP In, désactivée temporairement pour faire le test)
Est-ce le bon paramétrage ?
Mes règles habituelles concernant l'ICMP sont :
Je n'ai pas dit que la faille n'existait pas, je crois me souvenir l'avoir
lu quelque part il y a plus d'un an mais je n'utilise plus KPF depuis
longtemps, je signale simplement que si la faille est avérée et que si le
FW laisse passer les echo request remote fragmentés, tout ce que ça peut
engendrer, c'est un DDoS si ta machine est spécialement ciblée par un
attaquant qui doit déjà connaître ton IP, ce n'est en aucun cas une
technique utilisée par les SK pour trouver des machines vulnérables.
Si le seul pb est sur les ping fragmentés, bien sur qu'il n'y a quasi pas de
pb.
Mais peut-être aussi que Kerio laisse passer *n'importe quoi* du moment que
c'est fragmenté. Y compris de l'UDP ou du TCP. C'est d'ailleurs ce qu'on m'a
dit sur le forum équivalent US (ou sur comp.security.firewall, je ne sais
plus exactement), en me suggérant de le vérifier par moi même en utilisant
l'outil fragroute.
L'utilisation de cet outil dépasse mes compétences, et voila pourquoi j'en
suis resté à mon test *simple* à base de ping. Mais je séais bien que le pb
n'est pas dans le ping !
Cela dit, avec ce ping, l'attaquant potentiel peut déjà facilement savoir que
j'existe. C'est le premier pas vers la vulnérabilité. Ce n'est pas moi qui le
dit, c'est Gibson sur son site grc.com (dont tu ne contesteras sans doute pas
l'autorité).
Je n'ai pas dit que la faille n'existait pas, je crois me souvenir l'avoir
lu quelque part il y a plus d'un an mais je n'utilise plus KPF depuis
longtemps, je signale simplement que si la faille est avérée et que si le
FW laisse passer les echo request remote fragmentés, tout ce que ça peut
engendrer, c'est un DDoS si ta machine est spécialement ciblée par un
attaquant qui doit déjà connaître ton IP, ce n'est en aucun cas une
technique utilisée par les SK pour trouver des machines vulnérables.
Si le seul pb est sur les ping fragmentés, bien sur qu'il n'y a quasi pas de
pb.
Mais peut-être aussi que Kerio laisse passer *n'importe quoi* du moment que
c'est fragmenté. Y compris de l'UDP ou du TCP. C'est d'ailleurs ce qu'on m'a
dit sur le forum équivalent US (ou sur comp.security.firewall, je ne sais
plus exactement), en me suggérant de le vérifier par moi même en utilisant
l'outil fragroute.
L'utilisation de cet outil dépasse mes compétences, et voila pourquoi j'en
suis resté à mon test *simple* à base de ping. Mais je séais bien que le pb
n'est pas dans le ping !
Cela dit, avec ce ping, l'attaquant potentiel peut déjà facilement savoir que
j'existe. C'est le premier pas vers la vulnérabilité. Ce n'est pas moi qui le
dit, c'est Gibson sur son site grc.com (dont tu ne contesteras sans doute pas
l'autorité).
Je n'ai pas dit que la faille n'existait pas, je crois me souvenir l'avoir
lu quelque part il y a plus d'un an mais je n'utilise plus KPF depuis
longtemps, je signale simplement que si la faille est avérée et que si le
FW laisse passer les echo request remote fragmentés, tout ce que ça peut
engendrer, c'est un DDoS si ta machine est spécialement ciblée par un
attaquant qui doit déjà connaître ton IP, ce n'est en aucun cas une
technique utilisée par les SK pour trouver des machines vulnérables.
Si le seul pb est sur les ping fragmentés, bien sur qu'il n'y a quasi pas de
pb.
Mais peut-être aussi que Kerio laisse passer *n'importe quoi* du moment que
c'est fragmenté. Y compris de l'UDP ou du TCP. C'est d'ailleurs ce qu'on m'a
dit sur le forum équivalent US (ou sur comp.security.firewall, je ne sais
plus exactement), en me suggérant de le vérifier par moi même en utilisant
l'outil fragroute.
L'utilisation de cet outil dépasse mes compétences, et voila pourquoi j'en
suis resté à mon test *simple* à base de ping. Mais je séais bien que le pb
n'est pas dans le ping !
Cela dit, avec ce ping, l'attaquant potentiel peut déjà facilement savoir que
j'existe. C'est le premier pas vers la vulnérabilité. Ce n'est pas moi qui le
dit, c'est Gibson sur son site grc.com (dont tu ne contesteras sans doute pas
l'autorité).
Hello,
En principe, avec un FW à règles, l'echo reply IN doit être autorisé pour
ton ou tes outils tel outil de ping ou de tracert et bloqué pour tout le
reste.
--
http://www.optimix.be.tf MVP Windows Security http://websecurite.org
http://www.msmvps.com/XPditif/ http://experts.microsoft.fr/longhorn4u/
Helping you void your warranty since 2000
---**ANTISPAM**---
Click on the link to answer -Cliquez sur le lien pour répondre
http://www.cerbermail.com/?csaLJS6yvZ
@(0)@ JacK
Hello,
En principe, avec un FW à règles, l'echo reply IN doit être autorisé pour
ton ou tes outils tel outil de ping ou de tracert et bloqué pour tout le
reste.
--
http://www.optimix.be.tf MVP Windows Security http://websecurite.org
http://www.msmvps.com/XPditif/ http://experts.microsoft.fr/longhorn4u/
Helping you void your warranty since 2000
---**ANTISPAM**---
Click on the link to answer -Cliquez sur le lien pour répondre
http://www.cerbermail.com/?csaLJS6yvZ
@(0)@ JacK
Hello,
En principe, avec un FW à règles, l'echo reply IN doit être autorisé pour
ton ou tes outils tel outil de ping ou de tracert et bloqué pour tout le
reste.
--
http://www.optimix.be.tf MVP Windows Security http://websecurite.org
http://www.msmvps.com/XPditif/ http://experts.microsoft.fr/longhorn4u/
Helping you void your warranty since 2000
---**ANTISPAM**---
Click on the link to answer -Cliquez sur le lien pour répondre
http://www.cerbermail.com/?csaLJS6yvZ
@(0)@ JacK
"JacK [MVP]" a écrit dans le message de news:
Hello,
En principe, avec un FW à règles, l'echo reply IN doit être autorisé pour
ton ou tes outils tel outil de ping ou de tracert et bloqué pour tout le
reste.
-- http://www.optimix.be.tf MVP Windows Security http://websecurite.org
http://www.msmvps.com/XPditif/ http://experts.microsoft.fr/longhorn4u/
Helping you void your warranty since 2000
---**ANTISPAM**---
Click on the link to answer -Cliquez sur le lien pour répondre
http://www.cerbermail.com/?csaLJS6yvZ
@(0)@ JacK
Merci,
Je vais voir cela. Du reste, quasiment toutes les règles de mon firewall sont
des règles d'application.
J'ai juste un problème avec le DNS entrant. Si je précise les adresses de mes
DNS en remote, cela fonctionne aléatoirement, voir pas du tout. J'avais lu
cette éventualité sur ton site mais je ne m'explique pas bien la chose. Cela
signifie-t-il que les réponses à mes requêtes DNS peuvent venir d'autres
serveurs que ceux à qui (théoriquement) je m'adresse ? (proxy ?)
"JacK [MVP]" <ihatespam@wanamou.fr> a écrit dans le message de news:
mn.3d167d530b9b80c8.26509@wanamou.fr...
Hello,
En principe, avec un FW à règles, l'echo reply IN doit être autorisé pour
ton ou tes outils tel outil de ping ou de tracert et bloqué pour tout le
reste.
-- http://www.optimix.be.tf MVP Windows Security http://websecurite.org
http://www.msmvps.com/XPditif/ http://experts.microsoft.fr/longhorn4u/
Helping you void your warranty since 2000
---**ANTISPAM**---
Click on the link to answer -Cliquez sur le lien pour répondre
http://www.cerbermail.com/?csaLJS6yvZ
@(0)@ JacK
Merci,
Je vais voir cela. Du reste, quasiment toutes les règles de mon firewall sont
des règles d'application.
J'ai juste un problème avec le DNS entrant. Si je précise les adresses de mes
DNS en remote, cela fonctionne aléatoirement, voir pas du tout. J'avais lu
cette éventualité sur ton site mais je ne m'explique pas bien la chose. Cela
signifie-t-il que les réponses à mes requêtes DNS peuvent venir d'autres
serveurs que ceux à qui (théoriquement) je m'adresse ? (proxy ?)
"JacK [MVP]" a écrit dans le message de news:
Hello,
En principe, avec un FW à règles, l'echo reply IN doit être autorisé pour
ton ou tes outils tel outil de ping ou de tracert et bloqué pour tout le
reste.
-- http://www.optimix.be.tf MVP Windows Security http://websecurite.org
http://www.msmvps.com/XPditif/ http://experts.microsoft.fr/longhorn4u/
Helping you void your warranty since 2000
---**ANTISPAM**---
Click on the link to answer -Cliquez sur le lien pour répondre
http://www.cerbermail.com/?csaLJS6yvZ
@(0)@ JacK
Merci,
Je vais voir cela. Du reste, quasiment toutes les règles de mon firewall sont
des règles d'application.
J'ai juste un problème avec le DNS entrant. Si je précise les adresses de mes
DNS en remote, cela fonctionne aléatoirement, voir pas du tout. J'avais lu
cette éventualité sur ton site mais je ne m'explique pas bien la chose. Cela
signifie-t-il que les réponses à mes requêtes DNS peuvent venir d'autres
serveurs que ceux à qui (théoriquement) je m'adresse ? (proxy ?)
