Je viens d'installer le pack 2 de windows XP et je me pose cette question :
entre le pare feu de Bill et Sygate : comment faire pour bien choisir ? 8-o
Merci
<quote> "For a more specific example, consider the Windows XP SP2 firewall and its behavior regarding UDP broadcasts. A Windows XP SP2 system block all incoming traffic by default, but whenever it sends out a UDP broadcast packet, all UDP responses originating from the system's subnet, and with a destination port set to broadcast packet's source port, are allowed back through for three seconds following the broadcast. Because default XP SP2 systems will send UDP/137 and UDP/138 broadcasts periodically on their own, an attacker could repeatedly send spoofed packets to a host running XP SP2 and the traffic would eventually be allowed through." </quote>
En quoi la gestion des broadcasts UDP par le firewall de XP est-elle "pourrie" ? Est-ce une mauvaise idée d'accepter les réponses aux broadcasts UDP, ou bien est-ce la méthode qui est mauvaise ?
Dans un domaine voisin, je constate que le suivi de connexion de Netfilter ne reconnaît pas les réponses à un ICMP echo-request sur l'adresse de broadcast, elles sont marquées INVALID.
[Firewall XP SP2]
Tu pourrais expliquer en quoi la gestion des états UDP entraîne une
absence de protection de ces ports ?
Ce n'est pas une absence absolue de protection.
Je n'ai pas dit le contraire. :)
Juste une gestion pourrie des broadcasts UDP, couplée à l'habituel
bruit de fond généré par Windows sur un réseau local :
<quote>
"For a more specific example, consider the Windows XP SP2 firewall and
its behavior regarding UDP broadcasts. A Windows XP SP2 system block all
incoming traffic by default, but whenever it sends out a UDP broadcast
packet, all UDP responses originating from the system's subnet, and with
a destination port set to broadcast packet's source port, are allowed
back through for three seconds following the broadcast. Because default
XP SP2 systems will send UDP/137 and UDP/138 broadcasts periodically on
their own, an attacker could repeatedly send spoofed packets to a host
running XP SP2 and the traffic would eventually be allowed through."
</quote>
En quoi la gestion des broadcasts UDP par le firewall de XP est-elle
"pourrie" ? Est-ce une mauvaise idée d'accepter les réponses aux
broadcasts UDP, ou bien est-ce la méthode qui est mauvaise ?
Dans un domaine voisin, je constate que le suivi de connexion de
Netfilter ne reconnaît pas les réponses à un ICMP echo-request sur
l'adresse de broadcast, elles sont marquées INVALID.
<quote> "For a more specific example, consider the Windows XP SP2 firewall and its behavior regarding UDP broadcasts. A Windows XP SP2 system block all incoming traffic by default, but whenever it sends out a UDP broadcast packet, all UDP responses originating from the system's subnet, and with a destination port set to broadcast packet's source port, are allowed back through for three seconds following the broadcast. Because default XP SP2 systems will send UDP/137 and UDP/138 broadcasts periodically on their own, an attacker could repeatedly send spoofed packets to a host running XP SP2 and the traffic would eventually be allowed through." </quote>
En quoi la gestion des broadcasts UDP par le firewall de XP est-elle "pourrie" ? Est-ce une mauvaise idée d'accepter les réponses aux broadcasts UDP, ou bien est-ce la méthode qui est mauvaise ?
Dans un domaine voisin, je constate que le suivi de connexion de Netfilter ne reconnaît pas les réponses à un ICMP echo-request sur l'adresse de broadcast, elles sont marquées INVALID.
Nicob
On Mon, 09 May 2005 08:51:47 +0000, LaDDL wrote:
- a une gestion des états UDP complètement bidon
Certains services ont besoin d'utiliser certains ports UDP sur un domaine donc il suffit de mettre en place une politique de gestion du traffic IP soit analyser les paquets UDP.
Euh ... c'est peut-être le symptôme du Lundi matin, mais là, je dois reconnaître que je n'ai *rien* compris à ton propos :-(
Tu voulais dire quoi ?
Nicob
On Mon, 09 May 2005 08:51:47 +0000, LaDDL wrote:
- a une gestion des états UDP complètement bidon
Certains services ont besoin d'utiliser certains ports UDP sur un domaine
donc il suffit de mettre en place une politique de gestion du traffic IP
soit analyser les paquets UDP.
Euh ... c'est peut-être le symptôme du Lundi matin, mais là, je dois
reconnaître que je n'ai *rien* compris à ton propos :-(
Certains services ont besoin d'utiliser certains ports UDP sur un domaine donc il suffit de mettre en place une politique de gestion du traffic IP soit analyser les paquets UDP.
Euh ... c'est peut-être le symptôme du Lundi matin, mais là, je dois reconnaître que je n'ai *rien* compris à ton propos :-(
Tu voulais dire quoi ?
Nicob
Eric Masson
LaDDL writes:
C'est déjà pas mal. Au moins il protège les PC contre un certain nombre d'attaques et tous les ports sont stealthed.
Mis à part violer les rfc sur udp et tcp, c'est quoi l'intérêt ?
Oui et c'est pourquoi il faut configurer Windows Firewall. (cf Exceptions)
Même configuré, tu peux changer sa conf par programmation dans qu'un quelconque warning ne soit émis.
Éric Masson
-- Je cherche un site qui propose des cours de langues en ligne mais sur MACINTOSH, ce que je n'ai pas encore trouvé. Quelqu'un peut-il me renseigner ? -+-CLG in : <http://www.le-gnu.net> - Neuneu découvre le web -+-
LaDDL <bounce@localhost.fr> writes:
C'est déjà pas mal. Au moins il protège les PC contre un certain nombre
d'attaques et tous les ports sont stealthed.
Mis à part violer les rfc sur udp et tcp, c'est quoi l'intérêt ?
Oui et c'est pourquoi il faut configurer Windows Firewall. (cf
Exceptions)
Même configuré, tu peux changer sa conf par programmation dans qu'un
quelconque warning ne soit émis.
Éric Masson
--
Je cherche un site qui propose des cours de langues en ligne mais sur
MACINTOSH, ce que je n'ai pas encore trouvé. Quelqu'un peut-il me
renseigner ?
-+-CLG in : <http://www.le-gnu.net> - Neuneu découvre le web -+-
C'est déjà pas mal. Au moins il protège les PC contre un certain nombre d'attaques et tous les ports sont stealthed.
Mis à part violer les rfc sur udp et tcp, c'est quoi l'intérêt ?
Oui et c'est pourquoi il faut configurer Windows Firewall. (cf Exceptions)
Même configuré, tu peux changer sa conf par programmation dans qu'un quelconque warning ne soit émis.
Éric Masson
-- Je cherche un site qui propose des cours de langues en ligne mais sur MACINTOSH, ce que je n'ai pas encore trouvé. Quelqu'un peut-il me renseigner ? -+-CLG in : <http://www.le-gnu.net> - Neuneu découvre le web -+-
<quote> "For a more specific example, consider the Windows XP SP2 firewall and its behavior regarding UDP broadcasts. A Windows XP SP2 system block all incoming traffic by default, but whenever it sends out a UDP broadcast packet, all UDP responses originating from the system's subnet, and with a destination port set to broadcast packet's source port, are allowed back through for three seconds following the broadcast. Because default XP SP2 systems will send UDP/137 and UDP/138 broadcasts periodically on their own, an attacker could repeatedly send spoofed packets to a host running XP SP2 and the traffic would eventually be allowed through." </quote>
En quoi la gestion des broadcasts UDP par le firewall de XP est-elle "pourrie" ?
C'est marqué au dessus : quand la machine emets un broadcast UDP elle se met *aussi* a accepter les "réponses" en UDP sur le même port que celui ouvert pour l'émission pour peut que l'émetteur soit dans le même sous-réseau et ce pendant les trois secondes qui suivent le broadcast.
Est-ce une mauvaise idée d'accepter les réponses aux broadcasts UDP, ou bien est-ce la méthode qui est mauvaise ?
Ici ce qui est mauvais c'est que comme zinzin émets régulièrement les broadcast en UDP/137 UPD/138 et qu'il gère l'UDP de façon merdique, il ouvre grand la porte à une possible attaque sur une faille via ces ports.
Dans un domaine voisin, je constate que le suivi de connexion de Netfilter ne reconnaît pas les réponses à un ICMP echo-request sur l'adresse de broadcast, elles sont marquées INVALID.
Comportement modifiable (ex ipv4) dans /proc/sys/net/ipv4/ dans les réponses au broadcast et icmp. Tu aimes vraiment le smurf? :)
Eric.
Le Mon, 09 May 2005 08:51:47 +0000, Pascal@plouf a écrit :
<quote>
"For a more specific example, consider the Windows XP SP2 firewall and its
behavior regarding UDP broadcasts. A Windows XP SP2 system block all
incoming traffic by default, but whenever it sends out a UDP broadcast
packet, all UDP responses originating from the system's subnet, and with a
destination port set to broadcast packet's source port, are allowed back
through for three seconds following the broadcast. Because default XP SP2
systems will send UDP/137 and UDP/138 broadcasts periodically on their
own, an attacker could repeatedly send spoofed packets to a host running
XP SP2 and the traffic would eventually be allowed through." </quote>
En quoi la gestion des broadcasts UDP par le firewall de XP est-elle
"pourrie" ?
C'est marqué au dessus : quand la machine emets un broadcast UDP elle se
met *aussi* a accepter les "réponses" en UDP sur le même port que celui
ouvert pour l'émission pour peut que l'émetteur soit dans le même
sous-réseau et ce pendant les trois secondes qui suivent le broadcast.
Est-ce une mauvaise idée d'accepter les réponses aux
broadcasts UDP, ou bien est-ce la méthode qui est mauvaise ?
Ici ce qui est mauvais c'est que comme zinzin émets régulièrement les
broadcast en UDP/137 UPD/138 et qu'il gère l'UDP de façon merdique, il
ouvre grand la porte à une possible attaque sur une faille via ces ports.
Dans un domaine voisin, je constate que le suivi de connexion de Netfilter
ne reconnaît pas les réponses à un ICMP echo-request sur l'adresse de
broadcast, elles sont marquées INVALID.
Comportement modifiable (ex ipv4) dans /proc/sys/net/ipv4/ dans les
réponses au broadcast et icmp. Tu aimes vraiment le smurf? :)
<quote> "For a more specific example, consider the Windows XP SP2 firewall and its behavior regarding UDP broadcasts. A Windows XP SP2 system block all incoming traffic by default, but whenever it sends out a UDP broadcast packet, all UDP responses originating from the system's subnet, and with a destination port set to broadcast packet's source port, are allowed back through for three seconds following the broadcast. Because default XP SP2 systems will send UDP/137 and UDP/138 broadcasts periodically on their own, an attacker could repeatedly send spoofed packets to a host running XP SP2 and the traffic would eventually be allowed through." </quote>
En quoi la gestion des broadcasts UDP par le firewall de XP est-elle "pourrie" ?
C'est marqué au dessus : quand la machine emets un broadcast UDP elle se met *aussi* a accepter les "réponses" en UDP sur le même port que celui ouvert pour l'émission pour peut que l'émetteur soit dans le même sous-réseau et ce pendant les trois secondes qui suivent le broadcast.
Est-ce une mauvaise idée d'accepter les réponses aux broadcasts UDP, ou bien est-ce la méthode qui est mauvaise ?
Ici ce qui est mauvais c'est que comme zinzin émets régulièrement les broadcast en UDP/137 UPD/138 et qu'il gère l'UDP de façon merdique, il ouvre grand la porte à une possible attaque sur une faille via ces ports.
Dans un domaine voisin, je constate que le suivi de connexion de Netfilter ne reconnaît pas les réponses à un ICMP echo-request sur l'adresse de broadcast, elles sont marquées INVALID.
Comportement modifiable (ex ipv4) dans /proc/sys/net/ipv4/ dans les réponses au broadcast et icmp. Tu aimes vraiment le smurf? :)
Eric.
Cedric Blancher
Le Mon, 09 May 2005 08:51:47 +0000, a écrit :
Dans un domaine voisin, je constate que le suivi de connexion de Netfilter ne reconnaît pas les réponses à un ICMP echo-request sur l'adresse de broadcast, elles sont marquées INVALID.
Parce que ça fait un bail qu'on sait qu'on ne doit pas laisser passer les pings émis sur les adresses de broadcast (cf. attaques en amplification style Smurf). Même les RFCs (i.e. 2644) le savent, c'est dire...
-- BOFH excuse #315:
The recent proliferation of Nuclear Testing
Le Mon, 09 May 2005 08:51:47 +0000, Pascal@plouf a écrit :
Dans un domaine voisin, je constate que le suivi de connexion de
Netfilter ne reconnaît pas les réponses à un ICMP echo-request sur
l'adresse de broadcast, elles sont marquées INVALID.
Parce que ça fait un bail qu'on sait qu'on ne doit pas laisser passer les
pings émis sur les adresses de broadcast (cf. attaques en amplification
style Smurf). Même les RFCs (i.e. 2644) le savent, c'est dire...
Dans un domaine voisin, je constate que le suivi de connexion de Netfilter ne reconnaît pas les réponses à un ICMP echo-request sur l'adresse de broadcast, elles sont marquées INVALID.
Parce que ça fait un bail qu'on sait qu'on ne doit pas laisser passer les pings émis sur les adresses de broadcast (cf. attaques en amplification style Smurf). Même les RFCs (i.e. 2644) le savent, c'est dire...
-- BOFH excuse #315:
The recent proliferation of Nuclear Testing
Laurent Blume
LaDDL wrote:
Hein ?! C'est quoi le scanner en question qui t'oblige à tout désactiver/fermer ?
Non, le scanner en question (et j'utilise le mot «scanner» dans le sens lambda de «Epson Perfection 3270», hein, pas «scanner de port») oblige à utiliser Windows. Et la manière la plus facile de sécuriser Windows, plutôt que claquer 100¤ et quelques heures à installer des logiciels plus ou moins fiables, c'est de désactiver le réseau. Facile, vraiment :-)
Laurent
LaDDL wrote:
Hein ?!
C'est quoi le scanner en question qui t'oblige à tout désactiver/fermer ?
Non, le scanner en question (et j'utilise le mot «scanner» dans le sens lambda
de «Epson Perfection 3270», hein, pas «scanner de port») oblige à utiliser Windows.
Et la manière la plus facile de sécuriser Windows, plutôt que claquer 100¤ et
quelques heures à installer des logiciels plus ou moins fiables, c'est de
désactiver le réseau. Facile, vraiment :-)
Hein ?! C'est quoi le scanner en question qui t'oblige à tout désactiver/fermer ?
Non, le scanner en question (et j'utilise le mot «scanner» dans le sens lambda de «Epson Perfection 3270», hein, pas «scanner de port») oblige à utiliser Windows. Et la manière la plus facile de sécuriser Windows, plutôt que claquer 100¤ et quelques heures à installer des logiciels plus ou moins fiables, c'est de désactiver le réseau. Facile, vraiment :-)
En quoi la gestion des broadcasts UDP par le firewall de XP est-elle "pourrie" ?
C'est marqué au dessus : quand la machine emets un broadcast UDP elle se met *aussi* a accepter les "réponses" en UDP sur le même port que celui ouvert pour l'émission pour peut que l'émetteur soit dans le même sous-réseau et ce pendant les trois secondes qui suivent le broadcast.
Merci pour la traduction, mais j'avais compris. :) Ceci dit, tu ne fais que décrire le comportement du firewall de XP, cela n'explique toujours pas en quoi ce comportement est "pourri". J'aurais fait la même chose, sauf peut-être pour les 3 secondes qui me paraissent beaucoup sur un LAN.
Est-ce une mauvaise idée d'accepter les réponses aux broadcasts UDP, ou bien est-ce la méthode qui est mauvaise ?
Ici ce qui est mauvais c'est que comme zinzin émets régulièrement les broadcast en UDP/137 UPD/138
Soit, mais il s'agit de Netbios, pas du firewall.
et qu'il gère l'UDP de façon merdique, il ouvre grand la porte à une possible attaque sur une faille via ces ports.
Mais tu n'as toujours pas expliqué en quoi la gestion de l'UDP est merdique.
Dans un domaine voisin, je constate que le suivi de connexion de Netfilter ne reconnaît pas les réponses à un ICMP echo-request sur l'adresse de broadcast, elles sont marquées INVALID.
Comportement modifiable (ex ipv4) dans /proc/sys/net/ipv4/ dans les réponses au broadcast et icmp.
Je ne parle pas du comportement de la pile IP qui reçoit un broadcast IP mais du suivi d'état de Netfilter qui voit passer les réponses echo-reply (unicast) à un echo-request broadcast. La machine a émis un broadcast, les autres ont répondu, mais les réponses sont vues INVALID par le suivi d'état de connexion.
Tu aimes vraiment le smurf? :)
Quel rapport avec le comportement du suivi d'état de Netfilter face aux réponses à un ping broadcast ?
Parce que ça fait un bail qu'on sait qu'on ne doit pas laisser passer les pings émis sur les adresses de broadcast (cf. attaques en amplification style Smurf). Même les RFCs (i.e. 2644) le savent, c'est dire...
Si je ne m'abuse, cette restriction ne concerne que les routeurs face à un broadcast IP provenant d'un autre réseau. Où est-il écrit qu'il faut bloquer les réponses à ses propres broadcasts à l'intérieur d'un réseau local ?
En quoi la gestion des broadcasts UDP par le firewall de XP est-elle
"pourrie" ?
C'est marqué au dessus : quand la machine emets un broadcast UDP elle se
met *aussi* a accepter les "réponses" en UDP sur le même port que celui
ouvert pour l'émission pour peut que l'émetteur soit dans le même
sous-réseau et ce pendant les trois secondes qui suivent le broadcast.
Merci pour la traduction, mais j'avais compris. :)
Ceci dit, tu ne fais que décrire le comportement du firewall de XP, cela
n'explique toujours pas en quoi ce comportement est "pourri". J'aurais
fait la même chose, sauf peut-être pour les 3 secondes qui me paraissent
beaucoup sur un LAN.
Est-ce une mauvaise idée d'accepter les réponses aux
broadcasts UDP, ou bien est-ce la méthode qui est mauvaise ?
Ici ce qui est mauvais c'est que comme zinzin émets régulièrement les
broadcast en UDP/137 UPD/138
Soit, mais il s'agit de Netbios, pas du firewall.
et qu'il gère l'UDP de façon merdique, il
ouvre grand la porte à une possible attaque sur une faille via ces ports.
Mais tu n'as toujours pas expliqué en quoi la gestion de l'UDP est merdique.
Dans un domaine voisin, je constate que le suivi de connexion de Netfilter
ne reconnaît pas les réponses à un ICMP echo-request sur l'adresse de
broadcast, elles sont marquées INVALID.
Comportement modifiable (ex ipv4) dans /proc/sys/net/ipv4/ dans les
réponses au broadcast et icmp.
Je ne parle pas du comportement de la pile IP qui reçoit un broadcast IP
mais du suivi d'état de Netfilter qui voit passer les réponses echo-reply
(unicast) à un echo-request broadcast. La machine a émis un broadcast,
les autres ont répondu, mais les réponses sont vues INVALID par le suivi
d'état de connexion.
Tu aimes vraiment le smurf? :)
Quel rapport avec le comportement du suivi d'état de Netfilter face aux
réponses à un ping broadcast ?
Parce que ça fait un bail qu'on sait qu'on ne doit pas laisser passer les
pings émis sur les adresses de broadcast (cf. attaques en amplification
style Smurf). Même les RFCs (i.e. 2644) le savent, c'est dire...
Si je ne m'abuse, cette restriction ne concerne que les routeurs face à
un broadcast IP provenant d'un autre réseau. Où est-il écrit qu'il faut
bloquer les réponses à ses propres broadcasts à l'intérieur d'un réseau
local ?
En quoi la gestion des broadcasts UDP par le firewall de XP est-elle "pourrie" ?
C'est marqué au dessus : quand la machine emets un broadcast UDP elle se met *aussi* a accepter les "réponses" en UDP sur le même port que celui ouvert pour l'émission pour peut que l'émetteur soit dans le même sous-réseau et ce pendant les trois secondes qui suivent le broadcast.
Merci pour la traduction, mais j'avais compris. :) Ceci dit, tu ne fais que décrire le comportement du firewall de XP, cela n'explique toujours pas en quoi ce comportement est "pourri". J'aurais fait la même chose, sauf peut-être pour les 3 secondes qui me paraissent beaucoup sur un LAN.
Est-ce une mauvaise idée d'accepter les réponses aux broadcasts UDP, ou bien est-ce la méthode qui est mauvaise ?
Ici ce qui est mauvais c'est que comme zinzin émets régulièrement les broadcast en UDP/137 UPD/138
Soit, mais il s'agit de Netbios, pas du firewall.
et qu'il gère l'UDP de façon merdique, il ouvre grand la porte à une possible attaque sur une faille via ces ports.
Mais tu n'as toujours pas expliqué en quoi la gestion de l'UDP est merdique.
Dans un domaine voisin, je constate que le suivi de connexion de Netfilter ne reconnaît pas les réponses à un ICMP echo-request sur l'adresse de broadcast, elles sont marquées INVALID.
Comportement modifiable (ex ipv4) dans /proc/sys/net/ipv4/ dans les réponses au broadcast et icmp.
Je ne parle pas du comportement de la pile IP qui reçoit un broadcast IP mais du suivi d'état de Netfilter qui voit passer les réponses echo-reply (unicast) à un echo-request broadcast. La machine a émis un broadcast, les autres ont répondu, mais les réponses sont vues INVALID par le suivi d'état de connexion.
Tu aimes vraiment le smurf? :)
Quel rapport avec le comportement du suivi d'état de Netfilter face aux réponses à un ping broadcast ?
Parce que ça fait un bail qu'on sait qu'on ne doit pas laisser passer les pings émis sur les adresses de broadcast (cf. attaques en amplification style Smurf). Même les RFCs (i.e. 2644) le savent, c'est dire...
Si je ne m'abuse, cette restriction ne concerne que les routeurs face à un broadcast IP provenant d'un autre réseau. Où est-il écrit qu'il faut bloquer les réponses à ses propres broadcasts à l'intérieur d'un réseau local ?
Cedric Blancher
Le Wed, 11 May 2005 01:16:42 +0000, a écrit :
Où est-il écrit qu'il faut bloquer les réponses à ses propres broadcasts à l'intérieur d'un réseau local ?
J'ai lu trop vite, je n'ai pas fait attention que tu parlais des _réponses_ à une requête de l'hôte.
-- Ol: Vivement la WWDC qu'on en apprenne plus, quand même... EL: C'est sûr, on est au fond de la mine, on voit rien, juste du charbon partout. Beurk. ;-) -+ EL in Guide du Macounet Pervers : Les Nextiens préfèrent le jaune +-
Le Wed, 11 May 2005 01:16:42 +0000, Pascal@plouf a écrit :
Où est-il écrit qu'il faut bloquer les réponses à ses propres
broadcasts à l'intérieur d'un réseau local ?
J'ai lu trop vite, je n'ai pas fait attention que tu parlais des
_réponses_ à une requête de l'hôte.
--
Ol: Vivement la WWDC qu'on en apprenne plus, quand même...
EL: C'est sûr, on est au fond de la mine, on voit rien, juste du
charbon partout. Beurk. ;-)
-+ EL in Guide du Macounet Pervers : Les Nextiens préfèrent le jaune +-
Où est-il écrit qu'il faut bloquer les réponses à ses propres broadcasts à l'intérieur d'un réseau local ?
J'ai lu trop vite, je n'ai pas fait attention que tu parlais des _réponses_ à une requête de l'hôte.
-- Ol: Vivement la WWDC qu'on en apprenne plus, quand même... EL: C'est sûr, on est au fond de la mine, on voit rien, juste du charbon partout. Beurk. ;-) -+ EL in Guide du Macounet Pervers : Les Nextiens préfèrent le jaune +-
Cedric Blancher
Un élément de réponse... L'entrée créée dans la table de contrack est la suivante :
À partir de là, il ne doit pas récupérer la réponse comme valide en inversant le tuple, puisque 192.168.1.255 ne sera jamais en source, et de fait, la réponse ne correspondra pas à cette entrée...
J'ai posé la question sur la liste Netfilter Devel, on verra bien...
-- Je possède un T28S, et j'en suis content. Problème : mon chien aime aussi ce téléphone, particulièrement son mode d'emploi. Il l'a bouffé, et je me retrouve avec des notices anglaise, hollandaise et espagnole -+- JLP in <neuneu.mine.nu> : Utiliser une alimentation équillibrée -+-
Un élément de réponse... L'entrée créée dans la table de contrack
est la suivante :
À partir de là, il ne doit pas récupérer la réponse comme valide en
inversant le tuple, puisque 192.168.1.255 ne sera jamais en source, et de
fait, la réponse ne correspondra pas à cette entrée...
J'ai posé la question sur la liste Netfilter Devel, on verra bien...
--
Je possède un T28S, et j'en suis content. Problème : mon chien aime
aussi ce téléphone, particulièrement son mode d'emploi. Il l'a bouffé,
et je me retrouve avec des notices anglaise, hollandaise et espagnole
-+- JLP in <neuneu.mine.nu> : Utiliser une alimentation équillibrée -+-
À partir de là, il ne doit pas récupérer la réponse comme valide en inversant le tuple, puisque 192.168.1.255 ne sera jamais en source, et de fait, la réponse ne correspondra pas à cette entrée...
J'ai posé la question sur la liste Netfilter Devel, on verra bien...
-- Je possède un T28S, et j'en suis content. Problème : mon chien aime aussi ce téléphone, particulièrement son mode d'emploi. Il l'a bouffé, et je me retrouve avec des notices anglaise, hollandaise et espagnole -+- JLP in <neuneu.mine.nu> : Utiliser une alimentation équillibrée -+-
LaDDL
On Mon, 09 May 2005 12:36:19 +0200, Eric Masson wrote:
LaDDL writes: C'est déjà pas mal. Au moins il protège les PC contre un certain nombre d'attaques et tous les ports sont stealthed.
Mis à part violer les rfc sur udp et tcp, c'est quoi l'intérêt ?
L'intérêt amha réduire le traffic.
Maintenant le non respect des RFC n'est pas propre à Windows Firewall et encore moins MS. Tous les éditeurs et constructeurs de FW sont concernés aussi. Maintenant y en a qui gèrent mieux les réponses ICMP que d'autres.
Oui et c'est pourquoi il faut configurer Windows Firewall. (cf Exceptions)
Même configuré, tu peux changer sa conf par programmation dans qu'un quelconque warning ne soit émis.
Heureusement que l'on peut modifier la configuration de Windows Firewall notamment pour faciliter le déploiement de patchs, les mises à jour logicielles, l'administration, la maintenance, etc.
-- We have no control over the length of Our lives but We can control the width and depth of Our lives.
On Mon, 09 May 2005 12:36:19 +0200, Eric Masson <emss@free.fr> wrote:
LaDDL <bounce@localhost.fr> writes:
C'est déjà pas mal. Au moins il protège les PC contre un certain nombre
d'attaques et tous les ports sont stealthed.
Mis à part violer les rfc sur udp et tcp, c'est quoi l'intérêt ?
L'intérêt amha réduire le traffic.
Maintenant le non respect des RFC n'est pas propre à Windows Firewall et
encore moins MS. Tous les éditeurs et constructeurs de FW sont concernés
aussi. Maintenant y en a qui gèrent mieux les réponses ICMP que d'autres.
Oui et c'est pourquoi il faut configurer Windows Firewall. (cf
Exceptions)
Même configuré, tu peux changer sa conf par programmation dans qu'un
quelconque warning ne soit émis.
Heureusement que l'on peut modifier la configuration de Windows Firewall
notamment pour faciliter le déploiement de patchs, les mises à jour
logicielles, l'administration, la maintenance, etc.
--
We have no control over the length of Our lives but We can control the
width and depth of Our lives.
On Mon, 09 May 2005 12:36:19 +0200, Eric Masson wrote:
LaDDL writes: C'est déjà pas mal. Au moins il protège les PC contre un certain nombre d'attaques et tous les ports sont stealthed.
Mis à part violer les rfc sur udp et tcp, c'est quoi l'intérêt ?
L'intérêt amha réduire le traffic.
Maintenant le non respect des RFC n'est pas propre à Windows Firewall et encore moins MS. Tous les éditeurs et constructeurs de FW sont concernés aussi. Maintenant y en a qui gèrent mieux les réponses ICMP que d'autres.
Oui et c'est pourquoi il faut configurer Windows Firewall. (cf Exceptions)
Même configuré, tu peux changer sa conf par programmation dans qu'un quelconque warning ne soit émis.
Heureusement que l'on peut modifier la configuration de Windows Firewall notamment pour faciliter le déploiement de patchs, les mises à jour logicielles, l'administration, la maintenance, etc.
-- We have no control over the length of Our lives but We can control the width and depth of Our lives.
