Une chose m'intrigue dans les logs de mon Firewall: quand le FW bloque
des paquets entrants, je vois que mon ordinateur répond quand même à
ces requètes par des envois de paquets UDP (bloqués par le FW) à l'IP
d'origine. Comment peut-il répondre à ces paquets alors qu'ils ont été
(en principe) bloqués? (je n'y connais pas grand chose)
Par exemple:
1,[29/Oct/2003 10:34:30] Rule '445': Blocked: In TCP,
218.21.xx.yyy:10566->localhost:445, Owner: SYSTEM
1,[29/Oct/2003 10:34:30] Rule 'UDP sortant': Blocked: Out UDP,
localhost:137->218.21.xx.yyy:137, Owner: SYSTEM
1,[29/Oct/2003 10:34:32] Rule 'UDP sortant': Blocked: Out UDP,
localhost:137->218.21.xx.yyy:137, Owner: SYSTEM
1,[29/Oct/2003 10:34:33] Rule '445': Blocked: In TCP,
218.21.xx.yyy:10566->localhost:445, Owner: SYSTEM
1,[29/Oct/2003 10:34:33] Rule 'UDP sortant': Blocked: Out UDP,
localhost:137->218.21.xx.yyy:137, Owner: SYSTEM
autre exemple:
1,[29/Oct/2003 09:01:20] Rule 'UDP/TCP entrant': Blocked: In TCP,
211.36.xxx.zz:1497->localhost:139, Owner: SYSTEM
2,[29/Oct/2003 09:01:21] Rule 'UDP sortant': Blocked: Out UDP,
localhost:137->211.36.xxx.zz:137, Owner: SYSTEM
2,[29/Oct/2003 09:01:23] Rule 'UDP sortant': Blocked: Out UDP,
localhost:137->211.36.xxx.zz:137, Owner: SYSTEM
Une chose m'intrigue dans les logs de mon Firewall: quand le FW bloque des paquets entrants, je vois que mon ordinateur répond quand même à ces requètes par des envois de paquets UDP (bloqués par le FW) à l'IP d'origine. Comment peut-il répondre à ces paquets alors qu'ils ont été (en principe) bloqués? (je n'y connais pas grand chose)
1) Ton FW tente de résoudre le nom de l'hôte qui te contacte sur 445 tcp d'après son adresse IP. Perte de temps, désactive ça dans les paramètres du FW.
2) Pour cette résolution, ton système n'hésite pas à employer NetBIOS. Désactive ça dans les paramètres TCP/IP de ta connexion.
Voilou.
-- tchel
Une chose m'intrigue dans les logs de mon Firewall: quand le FW bloque
des paquets entrants, je vois que mon ordinateur répond quand même à
ces requètes par des envois de paquets UDP (bloqués par le FW) à l'IP
d'origine. Comment peut-il répondre à ces paquets alors qu'ils ont été
(en principe) bloqués? (je n'y connais pas grand chose)
1) Ton FW tente de résoudre le nom de l'hôte qui te contacte sur 445 tcp
d'après son adresse IP. Perte de temps, désactive ça dans les paramètres
du FW.
2) Pour cette résolution, ton système n'hésite pas à employer NetBIOS.
Désactive ça dans les paramètres TCP/IP de ta connexion.
Une chose m'intrigue dans les logs de mon Firewall: quand le FW bloque des paquets entrants, je vois que mon ordinateur répond quand même à ces requètes par des envois de paquets UDP (bloqués par le FW) à l'IP d'origine. Comment peut-il répondre à ces paquets alors qu'ils ont été (en principe) bloqués? (je n'y connais pas grand chose)
1) Ton FW tente de résoudre le nom de l'hôte qui te contacte sur 445 tcp d'après son adresse IP. Perte de temps, désactive ça dans les paramètres du FW.
2) Pour cette résolution, ton système n'hésite pas à employer NetBIOS. Désactive ça dans les paramètres TCP/IP de ta connexion.
Voilou.
-- tchel
Cedric Blancher
Dans sa prose, tchelaviek nous ecrivait :
1) Ton FW tente de résoudre le nom de l'hôte qui te contacte sur 445 tcp d'après son adresse IP. Perte de temps, désactive ça dans les paramètres du FW.
OK.
2) Pour cette résolution, ton système n'hésite pas à employer NetBIOS. Désactive ça dans les paramètres TCP/IP de ta connexion.
J'ai du mal à saisir le rapport en NetBIOS et la résolution DNS du nom d'une machine externe au réseau. En effet, si la résolution DNS peut passer par une résolution de nom NetBIOS, j'ai du mal à voir comment NetBIOS va bien pouvoir résoudre une IP perdue sur le net...
--
Parce qu'il y a des faux linux ? Bien sûr. Tous ceux qui n'ont pas les lettres «BSD» dans leurs noms.
Lima India November Delta Oscar Whisky Sierra ?
-+- TB in GFA : "Argh, TB m'a tuer." -+-
Dans sa prose, tchelaviek nous ecrivait :
1) Ton FW tente de résoudre le nom de l'hôte qui te contacte sur 445 tcp
d'après son adresse IP. Perte de temps, désactive ça dans les
paramètres du FW.
OK.
2) Pour cette résolution, ton système n'hésite pas à employer NetBIOS.
Désactive ça dans les paramètres TCP/IP de ta connexion.
J'ai du mal à saisir le rapport en NetBIOS et la résolution DNS du nom
d'une machine externe au réseau. En effet, si la résolution DNS peut
passer par une résolution de nom NetBIOS, j'ai du mal à voir comment
NetBIOS va bien pouvoir résoudre une IP perdue sur le net...
--
Parce qu'il y a des faux linux ?
Bien sûr. Tous ceux qui n'ont pas les lettres «BSD» dans leurs noms.
1) Ton FW tente de résoudre le nom de l'hôte qui te contacte sur 445 tcp d'après son adresse IP. Perte de temps, désactive ça dans les paramètres du FW.
OK.
2) Pour cette résolution, ton système n'hésite pas à employer NetBIOS. Désactive ça dans les paramètres TCP/IP de ta connexion.
J'ai du mal à saisir le rapport en NetBIOS et la résolution DNS du nom d'une machine externe au réseau. En effet, si la résolution DNS peut passer par une résolution de nom NetBIOS, j'ai du mal à voir comment NetBIOS va bien pouvoir résoudre une IP perdue sur le net...
--
Parce qu'il y a des faux linux ? Bien sûr. Tous ceux qui n'ont pas les lettres «BSD» dans leurs noms.
Lima India November Delta Oscar Whisky Sierra ?
-+- TB in GFA : "Argh, TB m'a tuer." -+-
tchelaviek
J'ai du mal à saisir le rapport en NetBIOS et la résolution DNS du nom d'une machine externe au réseau.
Moi aussi. Je me demande bien par quelle aberration sa machine estime indispensable d'invoquer 137 udp sur une connexion Internet à la suite d'un gethostbyaddr. ;)
-- tchel
J'ai du mal à saisir le rapport en NetBIOS et la résolution DNS du nom
d'une machine externe au réseau.
Moi aussi. Je me demande bien par quelle aberration sa machine estime
indispensable d'invoquer 137 udp sur une connexion Internet à la suite
d'un gethostbyaddr. ;)
J'ai du mal à saisir le rapport en NetBIOS et la résolution DNS du nom d'une machine externe au réseau.
Moi aussi. Je me demande bien par quelle aberration sa machine estime indispensable d'invoquer 137 udp sur une connexion Internet à la suite d'un gethostbyaddr. ;)
-- tchel
Stephane Catteau
Cedric Blancher nous disait récement dans fr.comp.securite <news: :
Dans sa prose, tchelaviek nous ecrivait :
2) Pour cette résolution, ton système n'hésite pas à employer NetBIOS. Désactive ça dans les paramètres TCP/IP de ta connexion.
J'ai du mal à saisir le rapport en NetBIOS et la résolution DNS du nom d'une machine externe au réseau. En effet, si la résolution DNS peut passer par une résolution de nom NetBIOS, j'ai du mal à voir comment NetBIOS va bien pouvoir résoudre une IP perdue sur le net...
C'est l'un des petits plaisirs de Windows ça. Lorsque le système n'arrive pas à résoudre un nom que l'on appèlera DNS pour simplifier, il essait de résoudre son nom NetBIOS. Dans l'esprit des gentils fumeu^Wprogrammeurs de Redmond, cela devait sans doute permettre de continuer à bénéficier de tous les petits plaisirs d'Internet si d'aventure l'ensemble des DNS tombait en panne. Etant entendu que seul le partage de fichier est un plaisir, évidement... Par contre, je ne comprend pas pourquoi KPF suivrait soudain la même logique. Ou alors le firewall d'XP est activé lui-aussi, et c'est lui qui chercherait à faire cette résolution. Je m'explique :
1) Le firewall d'XP étant avant KPF, il laisse passer les données, qui sont ensuite bloquées par KPF, qui les logs. 2) Les données concernant NetBIOS, le firewall d'XP se dit que ce serait une bonne idée d'avoir le nom (NetBIOS évidement) de la machine et charge le système d'envoyer une requête en ce sens. 3) KPF bloque et log la-dite requête.
Je ne garantie pas que ce soit ça, et ne m'explique pas comment le firewall d'XP arriverait à se placer devant KPF alors qu'il est sensé démarrer en premier, mais ça tient la route et c'est la seule explication plausible que je vois.
-- "Si ceux qui disent du mal de moi savaient exactement ce que je pense d'eux , ils en diraient bien davantage." Sacha Guitry
Cedric Blancher nous disait récement dans fr.comp.securite
<news:pan.2003.10.31.09.15.11.740859@cartel-securite.fr> :
Dans sa prose, tchelaviek nous ecrivait :
2) Pour cette résolution, ton système n'hésite pas à employer
NetBIOS. Désactive ça dans les paramètres TCP/IP de ta connexion.
J'ai du mal à saisir le rapport en NetBIOS et la résolution DNS du
nom d'une machine externe au réseau. En effet, si la résolution
DNS peut passer par une résolution de nom NetBIOS, j'ai du mal à
voir comment NetBIOS va bien pouvoir résoudre une IP perdue sur le
net...
C'est l'un des petits plaisirs de Windows ça. Lorsque le système
n'arrive pas à résoudre un nom que l'on appèlera DNS pour simplifier,
il essait de résoudre son nom NetBIOS. Dans l'esprit des gentils
fumeu^Wprogrammeurs de Redmond, cela devait sans doute permettre de
continuer à bénéficier de tous les petits plaisirs d'Internet si
d'aventure l'ensemble des DNS tombait en panne. Etant entendu que seul
le partage de fichier est un plaisir, évidement...
Par contre, je ne comprend pas pourquoi KPF suivrait soudain la même
logique. Ou alors le firewall d'XP est activé lui-aussi, et c'est lui
qui chercherait à faire cette résolution. Je m'explique :
1) Le firewall d'XP étant avant KPF, il laisse passer les données, qui
sont ensuite bloquées par KPF, qui les logs.
2) Les données concernant NetBIOS, le firewall d'XP se dit que ce
serait une bonne idée d'avoir le nom (NetBIOS évidement) de la
machine et charge le système d'envoyer une requête en ce sens.
3) KPF bloque et log la-dite requête.
Je ne garantie pas que ce soit ça, et ne m'explique pas comment le
firewall d'XP arriverait à se placer devant KPF alors qu'il est sensé
démarrer en premier, mais ça tient la route et c'est la seule
explication plausible que je vois.
--
"Si ceux qui disent du mal de moi savaient exactement ce que je
pense d'eux , ils en diraient bien davantage."
Sacha Guitry
Cedric Blancher nous disait récement dans fr.comp.securite <news: :
Dans sa prose, tchelaviek nous ecrivait :
2) Pour cette résolution, ton système n'hésite pas à employer NetBIOS. Désactive ça dans les paramètres TCP/IP de ta connexion.
J'ai du mal à saisir le rapport en NetBIOS et la résolution DNS du nom d'une machine externe au réseau. En effet, si la résolution DNS peut passer par une résolution de nom NetBIOS, j'ai du mal à voir comment NetBIOS va bien pouvoir résoudre une IP perdue sur le net...
C'est l'un des petits plaisirs de Windows ça. Lorsque le système n'arrive pas à résoudre un nom que l'on appèlera DNS pour simplifier, il essait de résoudre son nom NetBIOS. Dans l'esprit des gentils fumeu^Wprogrammeurs de Redmond, cela devait sans doute permettre de continuer à bénéficier de tous les petits plaisirs d'Internet si d'aventure l'ensemble des DNS tombait en panne. Etant entendu que seul le partage de fichier est un plaisir, évidement... Par contre, je ne comprend pas pourquoi KPF suivrait soudain la même logique. Ou alors le firewall d'XP est activé lui-aussi, et c'est lui qui chercherait à faire cette résolution. Je m'explique :
1) Le firewall d'XP étant avant KPF, il laisse passer les données, qui sont ensuite bloquées par KPF, qui les logs. 2) Les données concernant NetBIOS, le firewall d'XP se dit que ce serait une bonne idée d'avoir le nom (NetBIOS évidement) de la machine et charge le système d'envoyer une requête en ce sens. 3) KPF bloque et log la-dite requête.
Je ne garantie pas que ce soit ça, et ne m'explique pas comment le firewall d'XP arriverait à se placer devant KPF alors qu'il est sensé démarrer en premier, mais ça tient la route et c'est la seule explication plausible que je vois.
-- "Si ceux qui disent du mal de moi savaient exactement ce que je pense d'eux , ils en diraient bien davantage." Sacha Guitry
Thierry
Bonjour,
jeder a écrit :
(Windows XP home, avec l'adsl et Kerio)
J'ai Kerio/2K : En sniffant je me suis rendu compte que le port 135 (DCOM ou RPC) repondait aux requetes même avec TCP/UDP <-> 130-139, 445, 500 deny :-(
-- "MOI JE VEUX JOUER DE L'HELICON (PON PON PON PON)"
Bonjour,
jeder a écrit :
(Windows XP home, avec l'adsl et Kerio)
J'ai Kerio/2K : En sniffant je me suis rendu compte que le port 135 (DCOM
ou RPC) repondait aux requetes même avec TCP/UDP <-> 130-139, 445, 500 deny
:-(
--
"MOI JE VEUX JOUER DE L'HELICON (PON PON PON PON)"
J'ai Kerio/2K : En sniffant je me suis rendu compte que le port 135 (DCOM ou RPC) repondait aux requetes même avec TCP/UDP <-> 130-139, 445, 500 deny :-(
-- "MOI JE VEUX JOUER DE L'HELICON (PON PON PON PON)"
Stephane Catteau
Thierry nous disait récement dans fr.comp.securite <news: :
J'ai Kerio/2K : En sniffant je me suis rendu compte que le port 135 (DCOM ou RPC) repondait aux requetes même avec TCP/UDP <-> 130-139, 445, 500 deny :-(
Euh... :-( :-/ Tu as essayé en modifiant ta règle en 130, 131, 132, 133, etc, bref sans utiliser "130-139", dès fois que ce soit juste un problème de Kerio à ce niveau là ?
-- "Si ceux qui disent du mal de moi savaient exactement ce que je pense d'eux , ils en diraient bien davantage." Sacha Guitry
Thierry nous disait récement dans fr.comp.securite
<news:XnF9425A0CFDC635pouletetcetc@213.228.0.138> :
J'ai Kerio/2K : En sniffant je me suis rendu compte que le port
135 (DCOM ou RPC) repondait aux requetes même avec TCP/UDP <->
130-139, 445, 500 deny
:-(
Euh... :-( :-/ Tu as essayé en modifiant ta règle en 130, 131, 132,
133, etc, bref sans utiliser "130-139", dès fois que ce soit juste un
problème de Kerio à ce niveau là ?
--
"Si ceux qui disent du mal de moi savaient exactement ce que je
pense d'eux , ils en diraient bien davantage."
Sacha Guitry
Thierry nous disait récement dans fr.comp.securite <news: :
J'ai Kerio/2K : En sniffant je me suis rendu compte que le port 135 (DCOM ou RPC) repondait aux requetes même avec TCP/UDP <-> 130-139, 445, 500 deny :-(
Euh... :-( :-/ Tu as essayé en modifiant ta règle en 130, 131, 132, 133, etc, bref sans utiliser "130-139", dès fois que ce soit juste un problème de Kerio à ce niveau là ?
-- "Si ceux qui disent du mal de moi savaient exactement ce que je pense d'eux , ils en diraient bien davantage." Sacha Guitry
tchelaviek
Par contre, je ne comprend pas pourquoi KPF suivrait soudain la même logique.
Passqu'il s'appuie sur le système pour trouver le nom d'après l'IP. C'est pas de sa faute, à KPF. Ce que je tentais de dire à jeder, c'est qu'il/elle a deux paramètres à régler, l'un au niveau du FW, l'autre au niveau du système. Pour en savoir plus sur le comment, voir les docs de chacun.
Ou alors le firewall d'XP est activé lui-aussi, et c'est lui qui chercherait à faire cette résolution.
Intéressant, mais tu vas chercher trop loin. Pas besoin de firewall XP pour qu'un poste OuinOuin se comporte de la sorte.
Je ne garantie pas que ce soit ça, et ne m'explique pas comment le firewall d'XP arriverait à se placer devant KPF alors qu'il est sensé démarrer en premier
Aïe, ça me rappelle queukchose, ça. Thierry ?
-- tchel
Par contre, je ne comprend pas pourquoi KPF suivrait soudain la même
logique.
Passqu'il s'appuie sur le système pour trouver le nom d'après l'IP.
C'est pas de sa faute, à KPF.
Ce que je tentais de dire à jeder, c'est qu'il/elle a deux paramètres à
régler, l'un au niveau du FW, l'autre au niveau du système. Pour en
savoir plus sur le comment, voir les docs de chacun.
Ou alors le firewall d'XP est activé lui-aussi, et c'est lui
qui chercherait à faire cette résolution.
Intéressant, mais tu vas chercher trop loin. Pas besoin de firewall XP
pour qu'un poste OuinOuin se comporte de la sorte.
Je ne garantie pas que ce soit ça, et ne m'explique pas comment le
firewall d'XP arriverait à se placer devant KPF alors qu'il est sensé
démarrer en premier
Par contre, je ne comprend pas pourquoi KPF suivrait soudain la même logique.
Passqu'il s'appuie sur le système pour trouver le nom d'après l'IP. C'est pas de sa faute, à KPF. Ce que je tentais de dire à jeder, c'est qu'il/elle a deux paramètres à régler, l'un au niveau du FW, l'autre au niveau du système. Pour en savoir plus sur le comment, voir les docs de chacun.
Ou alors le firewall d'XP est activé lui-aussi, et c'est lui qui chercherait à faire cette résolution.
Intéressant, mais tu vas chercher trop loin. Pas besoin de firewall XP pour qu'un poste OuinOuin se comporte de la sorte.
Je ne garantie pas que ce soit ça, et ne m'explique pas comment le firewall d'XP arriverait à se placer devant KPF alors qu'il est sensé démarrer en premier
Aïe, ça me rappelle queukchose, ça. Thierry ?
-- tchel
Philippe Chatot
Cedric Blancher nous disait récement dans fr.comp.securite <news: :
Dans sa prose, tchelaviek nous ecrivait :
2) Pour cette résolution, ton système n'hésite pas à employer NetBIOS. Désactive ça dans les paramètres TCP/IP de ta connexion.
J'ai du mal à saisir le rapport en NetBIOS et la résolution DNS du nom d'une machine externe au réseau. En effet, si la résolution DNS peut passer par une résolution de nom NetBIOS, j'ai du mal à voir comment NetBIOS va bien pouvoir résoudre une IP perdue sur le net...
C'est l'un des petits plaisirs de Windows ça. Lorsque le système n'arrive pas à résoudre un nom que l'on appèlera DNS pour simplifier, il essait de résoudre son nom NetBIOS. Dans l'esprit des gentils fumeu^Wprogrammeurs de Redmond, cela devait sans doute permettre de continuer à bénéficier de tous les petits plaisirs d'Internet si d'aventure l'ensemble des DNS tombait en panne. Etant entendu que seul le partage de fichier est un plaisir, évidement... Par contre, je ne comprend pas pourquoi KPF suivrait soudain la même logique. Ou alors le firewall d'XP est activé lui-aussi, et c'est lui qui chercherait à faire cette résolution. Je m'explique :
1) Le firewall d'XP étant avant KPF, il laisse passer les données, qui sont ensuite bloquées par KPF, qui les logs. 2) Les données concernant NetBIOS, le firewall d'XP se dit que ce serait une bonne idée d'avoir le nom (NetBIOS évidement) de la machine et charge le système d'envoyer une requête en ce sens. 3) KPF bloque et log la-dite requête.
Je ne garantie pas que ce soit ça, et ne m'explique pas comment le firewall d'XP arriverait à se placer devant KPF alors qu'il est sensé démarrer en premier, mais ça tient la route et c'est la seule explication plausible que je vois.
Je confirme le phénomène avec Windows XP SP1, firewall intégré
désactivé, et Look'n'Stop 2.04 : lorsqu'un paquet est bloqué par Look'n'Stop, si j'ai demandé la résolution des noms dans son journal et que le DNS ne résoud pas l'adresse de l'expéditeur, Windows interroge l'émetteur sur le port 137. En abandonnant la résolution des noms dans la log du firewall, ce trafic Netbios disparaît.
Cedric Blancher nous disait récement dans fr.comp.securite
<news:pan.2003.10.31.09.15.11.740859@cartel-securite.fr> :
Dans sa prose, tchelaviek nous ecrivait :
2) Pour cette résolution, ton système n'hésite pas à employer
NetBIOS. Désactive ça dans les paramètres TCP/IP de ta connexion.
J'ai du mal à saisir le rapport en NetBIOS et la résolution DNS du
nom d'une machine externe au réseau. En effet, si la résolution
DNS peut passer par une résolution de nom NetBIOS, j'ai du mal à
voir comment NetBIOS va bien pouvoir résoudre une IP perdue sur le
net...
C'est l'un des petits plaisirs de Windows ça. Lorsque le système
n'arrive pas à résoudre un nom que l'on appèlera DNS pour simplifier,
il essait de résoudre son nom NetBIOS. Dans l'esprit des gentils
fumeu^Wprogrammeurs de Redmond, cela devait sans doute permettre de
continuer à bénéficier de tous les petits plaisirs d'Internet si
d'aventure l'ensemble des DNS tombait en panne. Etant entendu que seul
le partage de fichier est un plaisir, évidement...
Par contre, je ne comprend pas pourquoi KPF suivrait soudain la même
logique. Ou alors le firewall d'XP est activé lui-aussi, et c'est lui
qui chercherait à faire cette résolution. Je m'explique :
1) Le firewall d'XP étant avant KPF, il laisse passer les données, qui
sont ensuite bloquées par KPF, qui les logs.
2) Les données concernant NetBIOS, le firewall d'XP se dit que ce
serait une bonne idée d'avoir le nom (NetBIOS évidement) de la
machine et charge le système d'envoyer une requête en ce sens.
3) KPF bloque et log la-dite requête.
Je ne garantie pas que ce soit ça, et ne m'explique pas comment le
firewall d'XP arriverait à se placer devant KPF alors qu'il est sensé
démarrer en premier, mais ça tient la route et c'est la seule
explication plausible que je vois.
Je confirme le phénomène avec Windows XP SP1, firewall intégré
désactivé, et Look'n'Stop 2.04 : lorsqu'un paquet est bloqué par
Look'n'Stop, si j'ai demandé la résolution des noms dans son journal et
que le DNS ne résoud pas l'adresse de l'expéditeur, Windows interroge
l'émetteur sur le port 137.
En abandonnant la résolution des noms dans la log du firewall, ce trafic
Netbios disparaît.
Cedric Blancher nous disait récement dans fr.comp.securite <news: :
Dans sa prose, tchelaviek nous ecrivait :
2) Pour cette résolution, ton système n'hésite pas à employer NetBIOS. Désactive ça dans les paramètres TCP/IP de ta connexion.
J'ai du mal à saisir le rapport en NetBIOS et la résolution DNS du nom d'une machine externe au réseau. En effet, si la résolution DNS peut passer par une résolution de nom NetBIOS, j'ai du mal à voir comment NetBIOS va bien pouvoir résoudre une IP perdue sur le net...
C'est l'un des petits plaisirs de Windows ça. Lorsque le système n'arrive pas à résoudre un nom que l'on appèlera DNS pour simplifier, il essait de résoudre son nom NetBIOS. Dans l'esprit des gentils fumeu^Wprogrammeurs de Redmond, cela devait sans doute permettre de continuer à bénéficier de tous les petits plaisirs d'Internet si d'aventure l'ensemble des DNS tombait en panne. Etant entendu que seul le partage de fichier est un plaisir, évidement... Par contre, je ne comprend pas pourquoi KPF suivrait soudain la même logique. Ou alors le firewall d'XP est activé lui-aussi, et c'est lui qui chercherait à faire cette résolution. Je m'explique :
1) Le firewall d'XP étant avant KPF, il laisse passer les données, qui sont ensuite bloquées par KPF, qui les logs. 2) Les données concernant NetBIOS, le firewall d'XP se dit que ce serait une bonne idée d'avoir le nom (NetBIOS évidement) de la machine et charge le système d'envoyer une requête en ce sens. 3) KPF bloque et log la-dite requête.
Je ne garantie pas que ce soit ça, et ne m'explique pas comment le firewall d'XP arriverait à se placer devant KPF alors qu'il est sensé démarrer en premier, mais ça tient la route et c'est la seule explication plausible que je vois.
Je confirme le phénomène avec Windows XP SP1, firewall intégré
désactivé, et Look'n'Stop 2.04 : lorsqu'un paquet est bloqué par Look'n'Stop, si j'ai demandé la résolution des noms dans son journal et que le DNS ne résoud pas l'adresse de l'expéditeur, Windows interroge l'émetteur sur le port 137. En abandonnant la résolution des noms dans la log du firewall, ce trafic Netbios disparaît.
Paul GABORIT
À (at) 31 Oct 2003 15:23:06 GMT, Thierry écrivait (wrote):
Bonjour,
jeder a écrit :
(Windows XP home, avec l'adsl et Kerio)
J'ai Kerio/2K : En sniffant je me suis rendu compte que le port 135 (DCOM ou RPC) repondait aux requetes même avec TCP/UDP <-> 130-139, 445, 500 deny :-(
Dans Kerio, il y un onglet spécial pour les microsofteries... Si vous désactivez tout dans cet onglet, vos règles seront prises en compte.
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
À (at) 31 Oct 2003 15:23:06 GMT,
Thierry <yarglah@com.invalid> écrivait (wrote):
Bonjour,
jeder a écrit :
(Windows XP home, avec l'adsl et Kerio)
J'ai Kerio/2K : En sniffant je me suis rendu compte que le port 135 (DCOM
ou RPC) repondait aux requetes même avec TCP/UDP <-> 130-139, 445, 500 deny
:-(
Dans Kerio, il y un onglet spécial pour les microsofteries... Si vous
désactivez tout dans cet onglet, vos règles seront prises en compte.
--
Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
À (at) 31 Oct 2003 15:23:06 GMT, Thierry écrivait (wrote):
Bonjour,
jeder a écrit :
(Windows XP home, avec l'adsl et Kerio)
J'ai Kerio/2K : En sniffant je me suis rendu compte que le port 135 (DCOM ou RPC) repondait aux requetes même avec TCP/UDP <-> 130-139, 445, 500 deny :-(
Dans Kerio, il y un onglet spécial pour les microsofteries... Si vous désactivez tout dans cet onglet, vos règles seront prises en compte.
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
jeder
Le 31 Oct 2003 11:54:51 GMT, Stephane Catteau
Je ne garantie pas que ce soit ça, et ne m'explique pas comment le firewall d'XP arriverait à se placer devant KPF alors qu'il est sensé démarrer en premier, mais ça tient la route et c'est la seule explication plausible que je vois.
Non, le firewall d'XP n'est pas activé chez moi; ça semble bien être KPF qui lance (ou qui fait lancer au système) ces requètes (le problème disparaît si je désactive la résolution DNS dans KPF).
Jeder
Le 31 Oct 2003 11:54:51 GMT, Stephane Catteau <steph.nospam@sc4x.net>
Je ne garantie pas que ce soit ça, et ne m'explique pas comment le
firewall d'XP arriverait à se placer devant KPF alors qu'il est sensé
démarrer en premier, mais ça tient la route et c'est la seule
explication plausible que je vois.
Non, le firewall d'XP n'est pas activé chez moi; ça semble bien être
KPF qui lance (ou qui fait lancer au système) ces requètes (le
problème disparaît si je désactive la résolution DNS dans KPF).
Je ne garantie pas que ce soit ça, et ne m'explique pas comment le firewall d'XP arriverait à se placer devant KPF alors qu'il est sensé démarrer en premier, mais ça tient la route et c'est la seule explication plausible que je vois.
Non, le firewall d'XP n'est pas activé chez moi; ça semble bien être KPF qui lance (ou qui fait lancer au système) ces requètes (le problème disparaît si je désactive la résolution DNS dans KPF).
