J'ai déjà posté ce mot hier, mais ne le voyant pas arriver sur le
forum, je le re-poste.
Excusez moi s'il finit par arriver en double !
Je viens d'apprendre que Kerio 2.1.5, qui passait (notamment sur ce
forum) pour être le meilleur choix, laisse passer les paquets
fragmentés sans les voir, et peut donc se révéler une passoire (cf plus
bas)
Du coup, quel pf peut être conseillé, qui soit à la fois
- gratuit
- paramétrable
- contrôle entrant et sortant (donc pas le pf de Win XP...)
- efficace (donc pas kerio 2.1.5...)
Merci de vos avis
- motivés
- éclairés
- et documentés.
Pour ce qui est du pb de Kerio, voila le test très simple que l'on m'a
suggéré... et dont le résultat fait peur :
- Créer une règle Kerio qui interdise tout le ICMP entrant (donc les
retours de ping), et mettre cette règle en premier
- ping qui_vous_voulez : aucun retour, "délai d'attente dépassé". OK,
donc.
- ping -l 5000 qui_vous_voulez : oh horreur, ça passe ! (le paramètre
-l en forçant une taille de paquet au dessus du MTU a obligé à
fragmenter...)
Plus grave encore : ne mettez même pas cette règle, mais avec l'icône
de la systray, faites le choix "Arreter le trafic"
Même dans ce cas, le ping fragmenté part et revient très bien...
L> Je viens d'apprendre que Kerio 2.1.5, qui passait (notamment sur ce L> forum) pour être le meilleur choix, laisse passer les paquets L> fragmentés sans les voir, et peut donc se révéler une passoire (cf plus L> bas)
L> Du coup, quel pf peut être conseillé, qui soit à la fois L> - gratuit L> - paramétrable L> - contrôle entrant et sortant (donc pas le pf de Win XP...) L> - efficace (donc pas kerio 2.1.5...)
L> Merci de vos avis L> - motivés L> - éclairés L> - et documentés.
L> Pour ce qui est du pb de Kerio, voila le test très simple que l'on m'a L> suggéré... et dont le résultat fait peur : L> - Créer une règle Kerio qui interdise tout le ICMP entrant (donc les L> retours de ping), et mettre cette règle en premier L> - ping qui_vous_voulez : aucun retour, "délai d'attente dépassé". OK, L> donc. L> - ping -l 5000 qui_vous_voulez : oh horreur, ça passe ! (le paramètre L> -l en forçant une taille de paquet au dessus du MTU a obligé à L> fragmenter...)
L> Plus grave encore : ne mettez même pas cette règle, mais avec l'icône L> de la systray, faites le choix "Arreter le trafic" L> Même dans ce cas, le ping fragmenté part et revient très bien...
Est-ce que tu ne confonds pas? Quand je Pinge, j'aime bien une réponse. C'est quand on me Pinge que je dénie:
=== Begin Windows Clipboard == [C:TEMP]ping 81.243.175.1
Envoi d'une requête 'ping' sur 81.243.175.1 avec 32 octets de données :
Réponse de 81.243.175.1 : octets2 temps ms TTLd Réponse de 81.243.175.1 : octets2 temps ms TTLd Réponse de 81.243.175.1 : octets2 temps ms TTLd Réponse de 81.243.175.1 : octets2 temps ms TTLd
Statistiques Ping pour 81.243.175.1: Paquets : envoyés = 4, reçus = 4, perdus = 0 (perte 0%), Durée approximative des boucles en millisecondes : Minimum = 10ms, Maximum = 15ms, Moyenne = 13ms === End Windows Clipboard == Que vois-tu d'anormal ci-dessus?
Tu veux me Pinger pour voir si tu me violes? :-) Essaie au 81.243.175.167 (hâte-toi, parce que je ne suis pas statique).
-- Laurent Jumet - Point de Chat, Liège, BELGIUM KeyID: 0xCFAF704C [Restore address to laurent.jumet for e-mail reply.]
L> Je viens d'apprendre que Kerio 2.1.5, qui passait (notamment sur ce
L> forum) pour être le meilleur choix, laisse passer les paquets
L> fragmentés sans les voir, et peut donc se révéler une passoire (cf plus
L> bas)
L> Du coup, quel pf peut être conseillé, qui soit à la fois
L> - gratuit
L> - paramétrable
L> - contrôle entrant et sortant (donc pas le pf de Win XP...)
L> - efficace (donc pas kerio 2.1.5...)
L> Merci de vos avis
L> - motivés
L> - éclairés
L> - et documentés.
L> Pour ce qui est du pb de Kerio, voila le test très simple que l'on m'a
L> suggéré... et dont le résultat fait peur :
L> - Créer une règle Kerio qui interdise tout le ICMP entrant (donc les
L> retours de ping), et mettre cette règle en premier
L> - ping qui_vous_voulez : aucun retour, "délai d'attente dépassé". OK,
L> donc.
L> - ping -l 5000 qui_vous_voulez : oh horreur, ça passe ! (le paramètre
L> -l en forçant une taille de paquet au dessus du MTU a obligé à
L> fragmenter...)
L> Plus grave encore : ne mettez même pas cette règle, mais avec l'icône
L> de la systray, faites le choix "Arreter le trafic"
L> Même dans ce cas, le ping fragmenté part et revient très bien...
Est-ce que tu ne confonds pas?
Quand je Pinge, j'aime bien une réponse. C'est quand on me Pinge que je
dénie:
=== Begin Windows Clipboard == [C:TEMP]ping 81.243.175.1
Envoi d'une requête 'ping' sur 81.243.175.1 avec 32 octets de données :
Réponse de 81.243.175.1 : octets2 temps ms TTLd
Réponse de 81.243.175.1 : octets2 temps ms TTLd
Réponse de 81.243.175.1 : octets2 temps ms TTLd
Réponse de 81.243.175.1 : octets2 temps ms TTLd
Statistiques Ping pour 81.243.175.1:
Paquets : envoyés = 4, reçus = 4, perdus = 0 (perte 0%),
Durée approximative des boucles en millisecondes :
Minimum = 10ms, Maximum = 15ms, Moyenne = 13ms
=== End Windows Clipboard ==
Que vois-tu d'anormal ci-dessus?
Tu veux me Pinger pour voir si tu me violes? :-)
Essaie au 81.243.175.167 (hâte-toi, parce que je ne suis pas
statique).
--
Laurent Jumet - Point de Chat, Liège, BELGIUM
KeyID: 0xCFAF704C
[Restore address to laurent.jumet for e-mail reply.]
L> Je viens d'apprendre que Kerio 2.1.5, qui passait (notamment sur ce L> forum) pour être le meilleur choix, laisse passer les paquets L> fragmentés sans les voir, et peut donc se révéler une passoire (cf plus L> bas)
L> Du coup, quel pf peut être conseillé, qui soit à la fois L> - gratuit L> - paramétrable L> - contrôle entrant et sortant (donc pas le pf de Win XP...) L> - efficace (donc pas kerio 2.1.5...)
L> Merci de vos avis L> - motivés L> - éclairés L> - et documentés.
L> Pour ce qui est du pb de Kerio, voila le test très simple que l'on m'a L> suggéré... et dont le résultat fait peur : L> - Créer une règle Kerio qui interdise tout le ICMP entrant (donc les L> retours de ping), et mettre cette règle en premier L> - ping qui_vous_voulez : aucun retour, "délai d'attente dépassé". OK, L> donc. L> - ping -l 5000 qui_vous_voulez : oh horreur, ça passe ! (le paramètre L> -l en forçant une taille de paquet au dessus du MTU a obligé à L> fragmenter...)
L> Plus grave encore : ne mettez même pas cette règle, mais avec l'icône L> de la systray, faites le choix "Arreter le trafic" L> Même dans ce cas, le ping fragmenté part et revient très bien...
Est-ce que tu ne confonds pas? Quand je Pinge, j'aime bien une réponse. C'est quand on me Pinge que je dénie:
=== Begin Windows Clipboard == [C:TEMP]ping 81.243.175.1
Envoi d'une requête 'ping' sur 81.243.175.1 avec 32 octets de données :
Réponse de 81.243.175.1 : octets2 temps ms TTLd Réponse de 81.243.175.1 : octets2 temps ms TTLd Réponse de 81.243.175.1 : octets2 temps ms TTLd Réponse de 81.243.175.1 : octets2 temps ms TTLd
Statistiques Ping pour 81.243.175.1: Paquets : envoyés = 4, reçus = 4, perdus = 0 (perte 0%), Durée approximative des boucles en millisecondes : Minimum = 10ms, Maximum = 15ms, Moyenne = 13ms === End Windows Clipboard == Que vois-tu d'anormal ci-dessus?
Tu veux me Pinger pour voir si tu me violes? :-) Essaie au 81.243.175.167 (hâte-toi, parce que je ne suis pas statique).
-- Laurent Jumet - Point de Chat, Liège, BELGIUM KeyID: 0xCFAF704C [Restore address to laurent.jumet for e-mail reply.]
Laurent
Laurent Jumet a écrit le 06/03/2005 :
Est-ce que tu ne confonds pas? Quand je Pinge, j'aime bien une réponse. C'est quand on me Pinge que je dénie:
Relis donc mon post. Le pb n'est pas dans le Ping, mais dans le fait que Kerio ne traite pas correctement les paquets fragmentés. En temps normal, effectivement, le laisse passer les retours de ping (et j'interdis aux autres de me pinguer). Mon test a juste pour but de mettre en évidence que même si j'ai interdit le retour de ping, il passe qd même dabns certaines circonstances.
-- Laurent GRENET
Laurent Jumet a écrit le 06/03/2005 :
Est-ce que tu ne confonds pas?
Quand je Pinge, j'aime bien une réponse. C'est quand on me Pinge que je
dénie:
Relis donc mon post. Le pb n'est pas dans le Ping, mais dans le fait
que Kerio ne traite pas correctement les paquets fragmentés.
En temps normal, effectivement, le laisse passer les retours de ping
(et j'interdis aux autres de me pinguer).
Mon test a juste pour but de mettre en évidence que même si j'ai
interdit le retour de ping, il passe qd même dabns certaines
circonstances.
Est-ce que tu ne confonds pas? Quand je Pinge, j'aime bien une réponse. C'est quand on me Pinge que je dénie:
Relis donc mon post. Le pb n'est pas dans le Ping, mais dans le fait que Kerio ne traite pas correctement les paquets fragmentés. En temps normal, effectivement, le laisse passer les retours de ping (et j'interdis aux autres de me pinguer). Mon test a juste pour but de mettre en évidence que même si j'ai interdit le retour de ping, il passe qd même dabns certaines circonstances.
-- Laurent GRENET
Laurent Jumet
Hello !
Laurent wrote:
L> Relis donc mon post. Le pb n'est pas dans le Ping, mais dans le fait L> que Kerio ne traite pas correctement les paquets fragmentés. L> En temps normal, effectivement, le laisse passer les retours de ping L> (et j'interdis aux autres de me pinguer). L> Mon test a juste pour but de mettre en évidence que même si j'ai L> interdit le retour de ping, il passe qd même dabns certaines L> circonstances.
Et tu crois que c'est une "faille" ?
-- Laurent Jumet - Point de Chat, Liège, BELGIUM KeyID: 0xCFAF704C [Restore address to laurent.jumet for e-mail reply.]
L> Relis donc mon post. Le pb n'est pas dans le Ping, mais dans le fait
L> que Kerio ne traite pas correctement les paquets fragmentés.
L> En temps normal, effectivement, le laisse passer les retours de ping
L> (et j'interdis aux autres de me pinguer).
L> Mon test a juste pour but de mettre en évidence que même si j'ai
L> interdit le retour de ping, il passe qd même dabns certaines
L> circonstances.
Et tu crois que c'est une "faille" ?
--
Laurent Jumet - Point de Chat, Liège, BELGIUM
KeyID: 0xCFAF704C
[Restore address to laurent.jumet for e-mail reply.]
L> Relis donc mon post. Le pb n'est pas dans le Ping, mais dans le fait L> que Kerio ne traite pas correctement les paquets fragmentés. L> En temps normal, effectivement, le laisse passer les retours de ping L> (et j'interdis aux autres de me pinguer). L> Mon test a juste pour but de mettre en évidence que même si j'ai L> interdit le retour de ping, il passe qd même dabns certaines L> circonstances.
Et tu crois que c'est une "faille" ?
-- Laurent Jumet - Point de Chat, Liège, BELGIUM KeyID: 0xCFAF704C [Restore address to laurent.jumet for e-mail reply.]
Pano
Bonsoir,
Vous avez des données ou applications hyper-sensibles sur votre machine ? Non, parce que la probabilité de tomber sur un &ùù*$)! de hacker qui justement saura, sur VOTRE machine, trouver la faille de VOTRE pare-feu est infiniment faible.
C'est vraiment de la paranoïa... Enfin....
"Laurent" a écrit dans le message de news:
J'ai déjà posté ce mot hier, mais ne le voyant pas arriver sur le forum, je le re-poste. Excusez moi s'il finit par arriver en double !
Je viens d'apprendre que Kerio 2.1.5, qui passait (notamment sur ce forum) pour être le meilleur choix, laisse passer les paquets fragmentés sans les voir, et peut donc se révéler une passoire (cf plus bas)
Du coup, quel pf peut être conseillé, qui soit à la fois - gratuit - paramétrable - contrôle entrant et sortant (donc pas le pf de Win XP...) - efficace (donc pas kerio 2.1.5...)
Merci de vos avis - motivés - éclairés - et documentés.
Pour ce qui est du pb de Kerio, voila le test très simple que l'on m'a suggéré... et dont le résultat fait peur : - Créer une règle Kerio qui interdise tout le ICMP entrant (donc les retours de ping), et mettre cette règle en premier - ping qui_vous_voulez : aucun retour, "délai d'attente dépassé". OK, donc. - ping -l 5000 qui_vous_voulez : oh horreur, ça passe ! (le paramètre -l en forçant une taille de paquet au dessus du MTU a obligé à fragmenter...)
Plus grave encore : ne mettez même pas cette règle, mais avec l'icône de la systray, faites le choix "Arreter le trafic" Même dans ce cas, le ping fragmenté part et revient très bien...
-- Laurent GRENET
Bonsoir,
Vous avez des données ou applications hyper-sensibles sur votre machine ?
Non, parce que la probabilité de tomber sur un &ùù*$)! de hacker qui
justement saura, sur VOTRE machine, trouver la faille de VOTRE pare-feu est
infiniment faible.
C'est vraiment de la paranoïa...
Enfin....
"Laurent" <Laurent.Grenet.Enlevez-Ca@Voila.fr> a écrit dans le message de
news:mn.32c67d531b477a7f.2067@Voila.fr...
J'ai déjà posté ce mot hier, mais ne le voyant pas arriver sur le
forum, je le re-poste.
Excusez moi s'il finit par arriver en double !
Je viens d'apprendre que Kerio 2.1.5, qui passait (notamment sur ce
forum) pour être le meilleur choix, laisse passer les paquets
fragmentés sans les voir, et peut donc se révéler une passoire (cf plus
bas)
Du coup, quel pf peut être conseillé, qui soit à la fois
- gratuit
- paramétrable
- contrôle entrant et sortant (donc pas le pf de Win XP...)
- efficace (donc pas kerio 2.1.5...)
Merci de vos avis
- motivés
- éclairés
- et documentés.
Pour ce qui est du pb de Kerio, voila le test très simple que l'on m'a
suggéré... et dont le résultat fait peur :
- Créer une règle Kerio qui interdise tout le ICMP entrant (donc les
retours de ping), et mettre cette règle en premier
- ping qui_vous_voulez : aucun retour, "délai d'attente dépassé". OK,
donc.
- ping -l 5000 qui_vous_voulez : oh horreur, ça passe ! (le paramètre
-l en forçant une taille de paquet au dessus du MTU a obligé à
fragmenter...)
Plus grave encore : ne mettez même pas cette règle, mais avec l'icône
de la systray, faites le choix "Arreter le trafic"
Même dans ce cas, le ping fragmenté part et revient très bien...
Vous avez des données ou applications hyper-sensibles sur votre machine ? Non, parce que la probabilité de tomber sur un &ùù*$)! de hacker qui justement saura, sur VOTRE machine, trouver la faille de VOTRE pare-feu est infiniment faible.
C'est vraiment de la paranoïa... Enfin....
"Laurent" a écrit dans le message de news:
J'ai déjà posté ce mot hier, mais ne le voyant pas arriver sur le forum, je le re-poste. Excusez moi s'il finit par arriver en double !
Je viens d'apprendre que Kerio 2.1.5, qui passait (notamment sur ce forum) pour être le meilleur choix, laisse passer les paquets fragmentés sans les voir, et peut donc se révéler une passoire (cf plus bas)
Du coup, quel pf peut être conseillé, qui soit à la fois - gratuit - paramétrable - contrôle entrant et sortant (donc pas le pf de Win XP...) - efficace (donc pas kerio 2.1.5...)
Merci de vos avis - motivés - éclairés - et documentés.
Pour ce qui est du pb de Kerio, voila le test très simple que l'on m'a suggéré... et dont le résultat fait peur : - Créer une règle Kerio qui interdise tout le ICMP entrant (donc les retours de ping), et mettre cette règle en premier - ping qui_vous_voulez : aucun retour, "délai d'attente dépassé". OK, donc. - ping -l 5000 qui_vous_voulez : oh horreur, ça passe ! (le paramètre -l en forçant une taille de paquet au dessus du MTU a obligé à fragmenter...)
Plus grave encore : ne mettez même pas cette règle, mais avec l'icône de la systray, faites le choix "Arreter le trafic" Même dans ce cas, le ping fragmenté part et revient très bien...
Vous avez des données ou applications hyper-sensibles sur votre machine ? Non, parce que la probabilité de tomber sur un &ùù*$)! de hacker qui justement saura, sur VOTRE machine, trouver la faille de VOTRE pare-feu est infiniment faible.
C'est vraiment de la paranoïa...
Oui peut-être, mais si on ne l'est pas un peu (parano), on ne met pas de parefeux... et on est sur d'avoir des pb ! Le pb n'est pas seulement l'accès à mes données, mais la destruction des données, ou l'utilisation de ma machine pour des actes délictueux. Dès lors que qqun a pris le contrôle de ta machine...
Quant à "trouver la faille de VOTRE pare-feu" comme tu dis, si Kerio 2.1.5 a une telle faille, tous les "&ùù*$)! de hacker" la connaissent...
-- Laurent GRENET
Pano a écrit le 06/03/2005 :
Vous avez des données ou applications hyper-sensibles sur votre machine ?
Non, parce que la probabilité de tomber sur un &ùù*$)! de hacker qui
justement saura, sur VOTRE machine, trouver la faille de VOTRE pare-feu est
infiniment faible.
C'est vraiment de la paranoïa...
Oui peut-être, mais si on ne l'est pas un peu (parano), on ne met pas
de parefeux... et on est sur d'avoir des pb !
Le pb n'est pas seulement l'accès à mes données, mais la destruction
des données, ou l'utilisation de ma machine pour des actes délictueux.
Dès lors que qqun a pris le contrôle de ta machine...
Quant à "trouver la faille de VOTRE pare-feu" comme tu dis, si Kerio
2.1.5 a une telle faille, tous les "&ùù*$)! de hacker" la
connaissent...
Vous avez des données ou applications hyper-sensibles sur votre machine ? Non, parce que la probabilité de tomber sur un &ùù*$)! de hacker qui justement saura, sur VOTRE machine, trouver la faille de VOTRE pare-feu est infiniment faible.
C'est vraiment de la paranoïa...
Oui peut-être, mais si on ne l'est pas un peu (parano), on ne met pas de parefeux... et on est sur d'avoir des pb ! Le pb n'est pas seulement l'accès à mes données, mais la destruction des données, ou l'utilisation de ma machine pour des actes délictueux. Dès lors que qqun a pris le contrôle de ta machine...
Quant à "trouver la faille de VOTRE pare-feu" comme tu dis, si Kerio 2.1.5 a une telle faille, tous les "&ùù*$)! de hacker" la connaissent...
-- Laurent GRENET
Laurent Jumet
Hello !
"Sniper" wrote:
Quant à "trouver la faille de VOTRE pare-feu" comme tu dis, si Kerio 2.1.5 a une telle faille, tous les "&ùù*$)! de hacker" la connaissent...
S> Depuis le temps que j'utilise Kerio 2.1.5 et que ma bécane est en S> ligne, j'aurais dû (selon toi) être vérolé depuis longtemps. Or ce S> n'est pas le cas, bien que mes logs de tentatives d'intrusions S> ressemblent aux OEuvres complètes de Balzac au bout de 3 ou 4 jours. S> Cette pseudo-faille est quasiment inexploitable sinon elle aurait été S> bouchée depuis longtemps. Il y a bien plus à craindre d'une corruption S> venant de l'intérieur (Trojan) à cause d'un clic malheureux ou d'un S> test de logiciel avec un antivirus pas à jour.
C'est ce que je pense aussi.
-- Laurent Jumet - Point de Chat, Liège, BELGIUM KeyID: 0xCFAF704C [Restore address to laurent.jumet for e-mail reply.]
Hello !
"Sniper" <stop.le.spam@wanamou.fr> wrote:
Quant à "trouver la faille de VOTRE pare-feu" comme tu dis, si Kerio
2.1.5 a une telle faille, tous les "&ùù*$)! de hacker" la connaissent...
S> Depuis le temps que j'utilise Kerio 2.1.5 et que ma bécane est en
S> ligne, j'aurais dû (selon toi) être vérolé depuis longtemps. Or ce
S> n'est pas le cas, bien que mes logs de tentatives d'intrusions
S> ressemblent aux OEuvres complètes de Balzac au bout de 3 ou 4 jours.
S> Cette pseudo-faille est quasiment inexploitable sinon elle aurait été
S> bouchée depuis longtemps. Il y a bien plus à craindre d'une corruption
S> venant de l'intérieur (Trojan) à cause d'un clic malheureux ou d'un
S> test de logiciel avec un antivirus pas à jour.
C'est ce que je pense aussi.
--
Laurent Jumet - Point de Chat, Liège, BELGIUM
KeyID: 0xCFAF704C
[Restore address to laurent.jumet for e-mail reply.]
Quant à "trouver la faille de VOTRE pare-feu" comme tu dis, si Kerio 2.1.5 a une telle faille, tous les "&ùù*$)! de hacker" la connaissent...
S> Depuis le temps que j'utilise Kerio 2.1.5 et que ma bécane est en S> ligne, j'aurais dû (selon toi) être vérolé depuis longtemps. Or ce S> n'est pas le cas, bien que mes logs de tentatives d'intrusions S> ressemblent aux OEuvres complètes de Balzac au bout de 3 ou 4 jours. S> Cette pseudo-faille est quasiment inexploitable sinon elle aurait été S> bouchée depuis longtemps. Il y a bien plus à craindre d'une corruption S> venant de l'intérieur (Trojan) à cause d'un clic malheureux ou d'un S> test de logiciel avec un antivirus pas à jour.
C'est ce que je pense aussi.
-- Laurent Jumet - Point de Chat, Liège, BELGIUM KeyID: 0xCFAF704C [Restore address to laurent.jumet for e-mail reply.]
JacK [MVP]
Laurent avait énoncé :
J'ai déjà posté ce mot hier, mais ne le voyant pas arriver sur le forum, je le re-poste. Excusez moi s'il finit par arriver en double !
Je viens d'apprendre que Kerio 2.1.5, qui passait (notamment sur ce forum) pour être le meilleur choix, laisse passer les paquets fragmentés sans les voir, et peut donc se révéler une passoire (cf plus bas)
Du coup, quel pf peut être conseillé, qui soit à la fois - gratuit - paramétrable - contrôle entrant et sortant (donc pas le pf de Win XP...) - efficace (donc pas kerio 2.1.5...)
Merci de vos avis - motivés - éclairés - et documentés.
Pour ce qui est du pb de Kerio, voila le test très simple que l'on m'a suggéré... et dont le résultat fait peur : - Créer une règle Kerio qui interdise tout le ICMP entrant (donc les retours de ping), et mettre cette règle en premier
'lut,
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.
Vois en envoyant vers ton IP depuis un poste distant un echo request avec des packets fragmentés après avoir créé la règle ; si les packets passent à travers ton FW et pour ça il te faut un sniffer : si ça passe à travers, tu n'auras évidemment pas de traces du trafic dans ton FW d'où la nécessité d'un sniffer ;)
-- 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 avait énoncé :
J'ai déjà posté ce mot hier, mais ne le voyant pas arriver sur le forum, je
le re-poste.
Excusez moi s'il finit par arriver en double !
Je viens d'apprendre que Kerio 2.1.5, qui passait (notamment sur ce forum)
pour être le meilleur choix, laisse passer les paquets fragmentés sans les
voir, et peut donc se révéler une passoire (cf plus bas)
Du coup, quel pf peut être conseillé, qui soit à la fois
- gratuit
- paramétrable
- contrôle entrant et sortant (donc pas le pf de Win XP...)
- efficace (donc pas kerio 2.1.5...)
Merci de vos avis
- motivés
- éclairés
- et documentés.
Pour ce qui est du pb de Kerio, voila le test très simple que l'on m'a
suggéré... et dont le résultat fait peur :
- Créer une règle Kerio qui interdise tout le ICMP entrant (donc les retours
de ping), et mettre cette règle en premier
'lut,
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.
Vois en envoyant vers ton IP depuis un poste distant un echo request
avec des packets fragmentés après avoir créé la règle ; si les packets
passent à travers ton FW et pour ça il te faut un sniffer : si ça passe
à travers, tu n'auras évidemment pas de traces du trafic dans ton FW
d'où la nécessité d'un sniffer ;)
--
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
J'ai déjà posté ce mot hier, mais ne le voyant pas arriver sur le forum, je le re-poste. Excusez moi s'il finit par arriver en double !
Je viens d'apprendre que Kerio 2.1.5, qui passait (notamment sur ce forum) pour être le meilleur choix, laisse passer les paquets fragmentés sans les voir, et peut donc se révéler une passoire (cf plus bas)
Du coup, quel pf peut être conseillé, qui soit à la fois - gratuit - paramétrable - contrôle entrant et sortant (donc pas le pf de Win XP...) - efficace (donc pas kerio 2.1.5...)
Merci de vos avis - motivés - éclairés - et documentés.
Pour ce qui est du pb de Kerio, voila le test très simple que l'on m'a suggéré... et dont le résultat fait peur : - Créer une règle Kerio qui interdise tout le ICMP entrant (donc les retours de ping), et mettre cette règle en premier
'lut,
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.
Vois en envoyant vers ton IP depuis un poste distant un echo request avec des packets fragmentés après avoir créé la règle ; si les packets passent à travers ton FW et pour ça il te faut un sniffer : si ça passe à travers, tu n'auras évidemment pas de traces du trafic dans ton FW d'où la nécessité d'un sniffer ;)
-- 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]
Pano a écrit le 06/03/2005 :
Oui peut-être, mais si on ne l'est pas un peu (parano), on ne met pas de parefeux... et on est sur d'avoir des pb ! Le pb n'est pas seulement l'accès à mes données, mais la destruction des données, ou l'utilisation de ma machine pour des actes délictueux. Dès lors que qqun a pris le contrôle de ta machine...
'lut,
Si la faille est avérée, ce qu'elle peut causer, c'est un DDoS, à condition de s'y mettre à plusieurs ça peut entraîner la paralysie de ta connexion, rien de plus.
-- 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
Pano a écrit le 06/03/2005 :
Oui peut-être, mais si on ne l'est pas un peu (parano), on ne met pas de
parefeux... et on est sur d'avoir des pb !
Le pb n'est pas seulement l'accès à mes données, mais la destruction des
données, ou l'utilisation de ma machine pour des actes délictueux. Dès lors
que qqun a pris le contrôle de ta machine...
'lut,
Si la faille est avérée, ce qu'elle peut causer, c'est un DDoS, à
condition de s'y mettre à plusieurs ça peut entraîner la paralysie de
ta connexion, rien de plus.
--
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
Oui peut-être, mais si on ne l'est pas un peu (parano), on ne met pas de parefeux... et on est sur d'avoir des pb ! Le pb n'est pas seulement l'accès à mes données, mais la destruction des données, ou l'utilisation de ma machine pour des actes délictueux. Dès lors que qqun a pris le contrôle de ta machine...
'lut,
Si la faille est avérée, ce qu'elle peut causer, c'est un DDoS, à condition de s'y mettre à plusieurs ça peut entraîner la paralysie de ta connexion, rien de plus.
-- 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
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.
La meilleure preuve : bloque donc en IN les "Echo Reply" et met une règle qui laisse passer TOUT le ICMP en OUT, et tu verras que tes ping n'auront AUCUNE réposnse... sauf si tu pingue "fragmenté".
Vois en envoyant vers ton IP depuis un poste distant un echo request avec des packets fragmentés après avoir créé la règle ; si les packets passent à travers ton FW et pour ça il te faut un sniffer : si ça passe à travers, tu n'auras évidemment pas de traces du trafic dans ton FW d'où la nécessité d'un sniffer ;)
Bien sur que j'ai déjà fait le test dans ce sens là également. Avec une règle qui interdise tout ICMP sortant (quel qu'il soit), il suffit de faire un ping "fragmenté" pour qu'il sorte (et pas besoin de sniffer pour cela, si la machine pinguée répond, c'est bien que mon "Echo request" est sorti...)
Réfléchis qd même à deux fois avant d'écrire que les autres ne comprennent rien...
-- Laurent GRENET
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.
La meilleure preuve : bloque donc en IN les "Echo Reply" et met une
règle qui laisse passer TOUT le ICMP en OUT, et tu verras que tes ping
n'auront AUCUNE réposnse... sauf si tu pingue "fragmenté".
Vois en envoyant vers ton IP depuis un poste distant un echo request avec des
packets fragmentés après avoir créé la règle ; si les packets passent à
travers ton FW et pour ça il te faut un sniffer : si ça passe à travers, tu
n'auras évidemment pas de traces du trafic dans ton FW d'où la nécessité d'un
sniffer ;)
Bien sur que j'ai déjà fait le test dans ce sens là également.
Avec une règle qui interdise tout ICMP sortant (quel qu'il soit), il
suffit de faire un ping "fragmenté" pour qu'il sorte (et pas besoin de
sniffer pour cela, si la machine pinguée répond, c'est bien que mon
"Echo request" est sorti...)
Réfléchis qd même à deux fois avant d'écrire que les autres ne
comprennent rien...
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.
La meilleure preuve : bloque donc en IN les "Echo Reply" et met une règle qui laisse passer TOUT le ICMP en OUT, et tu verras que tes ping n'auront AUCUNE réposnse... sauf si tu pingue "fragmenté".
Vois en envoyant vers ton IP depuis un poste distant un echo request avec des packets fragmentés après avoir créé la règle ; si les packets passent à travers ton FW et pour ça il te faut un sniffer : si ça passe à travers, tu n'auras évidemment pas de traces du trafic dans ton FW d'où la nécessité d'un sniffer ;)
Bien sur que j'ai déjà fait le test dans ce sens là également. Avec une règle qui interdise tout ICMP sortant (quel qu'il soit), il suffit de faire un ping "fragmenté" pour qu'il sorte (et pas besoin de sniffer pour cela, si la machine pinguée répond, c'est bien que mon "Echo request" est sorti...)
Réfléchis qd même à deux fois avant d'écrire que les autres ne comprennent rien...
