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
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 :-(
Arf. Bon je vais essayer de formuler autrement mon propos. No Warranty ;)
Tu voulais dire quoi ?
Sur ton LAN t'as besoin de certains ports dont ceux cités précédemment soit 137 UDP et 138 UDP pour faire fonctionner certains services, etc. Bref...
Ensuite la question qui se pose ici c'est comment Windows Firewall filtre/gère ce traffic sur ces ports, ok ?
Windows Firewall par rapport à ICF est vraiment capable de suivre tous les différents datagrammes. Autrement dit, j'ai pas observé de problèmes dans les séquences de réponse ICMP. Donc pour moi le stateful (i.e. la gestion des états) de Windows Firewall fonctionne bien. Certes y a beaucoup mieux sur le marché comme FW mais il fait ce qu'on lui demande. Mais si tu as (ou les autres aussi) des infos complémentaires ou contradictoires ça m'interesse.
Amha c'est qu'une histoire de configuration et d'optimisation des paramètres ICMP de Windows Firewall.
-- 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 11:03:27 +0200, Nicob <nicob@I.hate.spammers.com>
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 :-(
Arf. Bon je vais essayer de formuler autrement mon propos.
No Warranty ;)
Tu voulais dire quoi ?
Sur ton LAN t'as besoin de certains ports dont ceux cités précédemment
soit 137 UDP et 138 UDP pour faire fonctionner certains services, etc.
Bref...
Ensuite la question qui se pose ici c'est comment Windows Firewall
filtre/gère ce traffic sur ces ports, ok ?
Windows Firewall par rapport à ICF est vraiment capable de suivre tous les
différents datagrammes. Autrement dit, j'ai pas observé de problèmes dans
les séquences de réponse ICMP. Donc pour moi le stateful (i.e. la gestion
des états) de Windows Firewall fonctionne bien. Certes y a beaucoup mieux
sur le marché comme FW mais il fait ce qu'on lui demande. Mais si tu as
(ou les autres aussi) des infos complémentaires ou contradictoires ça
m'interesse.
Amha c'est qu'une histoire de configuration et d'optimisation des
paramètres ICMP de Windows Firewall.
--
We have no control over the length of Our lives but We can control the
width and depth of Our lives.
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 :-(
Arf. Bon je vais essayer de formuler autrement mon propos. No Warranty ;)
Tu voulais dire quoi ?
Sur ton LAN t'as besoin de certains ports dont ceux cités précédemment soit 137 UDP et 138 UDP pour faire fonctionner certains services, etc. Bref...
Ensuite la question qui se pose ici c'est comment Windows Firewall filtre/gère ce traffic sur ces ports, ok ?
Windows Firewall par rapport à ICF est vraiment capable de suivre tous les différents datagrammes. Autrement dit, j'ai pas observé de problèmes dans les séquences de réponse ICMP. Donc pour moi le stateful (i.e. la gestion des états) de Windows Firewall fonctionne bien. Certes y a beaucoup mieux sur le marché comme FW mais il fait ce qu'on lui demande. Mais si tu as (ou les autres aussi) des infos complémentaires ou contradictoires ça m'interesse.
Amha c'est qu'une histoire de configuration et d'optimisation des paramètres ICMP de Windows Firewall.
-- We have no control over the length of Our lives but We can control the width and depth of Our lives.
Eric Masson
LaDDL writes:
L'intérêt amha réduire le traffic.
Et ça, c'est un intérêt suffisant pour casser des outils de diagnostic utiles ?
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.
Est-ce que tu lis ce à quoi tu réponds ?
Le problème est qu'aucun warning n'est levé lors de la modification du paramétrage, pas que celui-ci soit modifiable.
Éric Masson
-- Je dois faire un exposé pour mon cours de communication. Le sujet : les crottes de nez ou la spéléologie nasale. recherche donc toute expression, image, plan, document scientifique, photo, page ouèbe concernant ce sujet. -+- TT in : <http://www.le-gnu.net> - Encore un sujet à creuser -+-
LaDDL <bounce@localhost.fr> writes:
L'intérêt amha réduire le traffic.
Et ça, c'est un intérêt suffisant pour casser des outils de diagnostic
utiles ?
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.
Est-ce que tu lis ce à quoi tu réponds ?
Le problème est qu'aucun warning n'est levé lors de la modification du
paramétrage, pas que celui-ci soit modifiable.
Éric Masson
--
Je dois faire un exposé pour mon cours de communication. Le sujet : les
crottes de nez ou la spéléologie nasale. recherche donc toute expression,
image, plan, document scientifique, photo, page ouèbe concernant ce sujet.
-+- TT in : <http://www.le-gnu.net> - Encore un sujet à creuser -+-
Et ça, c'est un intérêt suffisant pour casser des outils de diagnostic utiles ?
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.
Est-ce que tu lis ce à quoi tu réponds ?
Le problème est qu'aucun warning n'est levé lors de la modification du paramétrage, pas que celui-ci soit modifiable.
Éric Masson
-- Je dois faire un exposé pour mon cours de communication. Le sujet : les crottes de nez ou la spéléologie nasale. recherche donc toute expression, image, plan, document scientifique, photo, page ouèbe concernant ce sujet. -+- TT in : <http://www.le-gnu.net> - Encore un sujet à creuser -+-
Nicob
On Wed, 11 May 2005 15:56:28 +0000, LaDDL wrote:
- a une gestion des états UDP complètement bidon
Sur ton LAN t'as besoin de certains ports dont ceux cités précédemment soit 137 UDP et 138 UDP pour faire fonctionner certains services, etc.
Bon OK, j'étais pas clair (autant dans mes mots que dans ma tête).
Ce qui me gêne dans le problème évoqué par eEye, ce n'est pas tant le fait qu'on ait un timer à 3 secondes pour l'acceptation des réponses aux broadcasts UDP, mais que cela, combiné à la délicate tradition consistant à polluer tout le LAN de broadcasts "indispensables", permet à tout utilisateur d'un LAN d'être *sûr* (!) de pouvoir atteindre les ports UDP/137 et UDP/138 de n'importe quel Windows XP SP2 (qui est pourtant le top en termes de sécurité Microsoft) de son réseau. Et cela malgré le demi-firewall censé au moins protéger l'inbound :-(
Nicob
On Wed, 11 May 2005 15:56:28 +0000, LaDDL wrote:
- a une gestion des états UDP complètement bidon
Sur ton LAN t'as besoin de certains ports dont ceux cités précédemment
soit 137 UDP et 138 UDP pour faire fonctionner certains services, etc.
Bon OK, j'étais pas clair (autant dans mes mots que dans ma tête).
Ce qui me gêne dans le problème évoqué par eEye, ce n'est pas tant le
fait qu'on ait un timer à 3 secondes pour l'acceptation des réponses
aux broadcasts UDP, mais que cela, combiné à la délicate tradition
consistant à polluer tout le LAN de broadcasts "indispensables", permet
à tout utilisateur d'un LAN d'être *sûr* (!) de pouvoir atteindre les
ports UDP/137 et UDP/138 de n'importe quel Windows XP SP2 (qui est
pourtant le top en termes de sécurité Microsoft) de son réseau. Et cela
malgré le demi-firewall censé au moins protéger l'inbound :-(
Sur ton LAN t'as besoin de certains ports dont ceux cités précédemment soit 137 UDP et 138 UDP pour faire fonctionner certains services, etc.
Bon OK, j'étais pas clair (autant dans mes mots que dans ma tête).
Ce qui me gêne dans le problème évoqué par eEye, ce n'est pas tant le fait qu'on ait un timer à 3 secondes pour l'acceptation des réponses aux broadcasts UDP, mais que cela, combiné à la délicate tradition consistant à polluer tout le LAN de broadcasts "indispensables", permet à tout utilisateur d'un LAN d'être *sûr* (!) de pouvoir atteindre les ports UDP/137 et UDP/138 de n'importe quel Windows XP SP2 (qui est pourtant le top en termes de sécurité Microsoft) de son réseau. Et cela malgré le demi-firewall censé au moins protéger l'inbound :-(
Nicob
Pascal
[réponses à un ping broadcast classées INVALID au lieu de ESTABLISHED par le suivi de connexion de Netfilter]
Un élément de réponse... L'entrée créée dans la table de contrack est la suivante :
J'avais vu, c'est même la première chose que j'ai vérifié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...
C'est ce que j'ai pensé aussi.
J'ai posé la question sur la liste Netfilter Devel, on verra bien...
Et la confirmation ne s'est pas fait attendre. Merci de cette initiative. Le suivi de connexion traite le broadcast et le multicast comme de l'unicast. C'est vrai que ça compliquerait pas mal les choses.
[réponses à un ping broadcast classées INVALID au lieu de ESTABLISHED par
le suivi de connexion de Netfilter]
Un élément de réponse... L'entrée créée dans la table de contrack
est la suivante :
J'avais vu, c'est même la première chose que j'ai vérifié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...
C'est ce que j'ai pensé aussi.
J'ai posé la question sur la liste Netfilter Devel, on verra bien...
Et la confirmation ne s'est pas fait attendre. Merci de cette initiative.
Le suivi de connexion traite le broadcast et le multicast comme de
l'unicast. C'est vrai que ça compliquerait pas mal les choses.
J'avais vu, c'est même la première chose que j'ai vérifié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...
C'est ce que j'ai pensé aussi.
J'ai posé la question sur la liste Netfilter Devel, on verra bien...
Et la confirmation ne s'est pas fait attendre. Merci de cette initiative. Le suivi de connexion traite le broadcast et le multicast comme de l'unicast. C'est vrai que ça compliquerait pas mal les choses.
Pascal
Ce qui me gêne dans le problème évoqué par eEye, ce n'est pas tant le fait qu'on ait un timer à 3 secondes pour l'acceptation des réponses aux broadcasts UDP, mais que cela, combiné à la délicate tradition consistant à polluer tout le LAN de broadcasts "indispensables", permet à tout utilisateur d'un LAN d'être *sûr* (!) de pouvoir atteindre les ports UDP/137 et UDP/138 de n'importe quel Windows XP SP2 (qui est pourtant le top en termes de sécurité Microsoft) de son réseau. Et cela malgré le demi-firewall censé au moins protéger l'inbound :-(
Mais ce "trou" n'est quand même pas imputable au suivi d'état du firewall. Il faut bien que les réponses puissent passer, et il n'y a pas cinquante façons de le faire.
AMA le défaut serait plutôt dans la couche Netbios qui utilise pour ces broadcasts UDP un port source identique au port destination d'après ce que j'ai constaté. Dans ces condition il est impossible pour le suivi d'état de distinguer une réponse au broadcast émis d'une requête unicast émise par une autre machine puisque les deux ont les mêms ports source et destination. Résultat, il laisse entrer les deux. La seule alternative serait de bloquer les deux, mais ça casserait des choses.
Il en serait différemment si le port source du broadcast était un port dynamique non privilégié. Ainsi le suivi d'état du firewall pourrait distinguer les réponses (avec port destination = port source dynamique du broadcast) des requêtes (avec port destination = 137 ou 138).
Qu'en pensez-vous ?
Ce qui me gêne dans le problème évoqué par eEye, ce n'est pas tant le
fait qu'on ait un timer à 3 secondes pour l'acceptation des réponses
aux broadcasts UDP, mais que cela, combiné à la délicate tradition
consistant à polluer tout le LAN de broadcasts "indispensables", permet
à tout utilisateur d'un LAN d'être *sûr* (!) de pouvoir atteindre les
ports UDP/137 et UDP/138 de n'importe quel Windows XP SP2 (qui est
pourtant le top en termes de sécurité Microsoft) de son réseau. Et cela
malgré le demi-firewall censé au moins protéger l'inbound :-(
Mais ce "trou" n'est quand même pas imputable au suivi d'état du
firewall. Il faut bien que les réponses puissent passer, et il n'y a pas
cinquante façons de le faire.
AMA le défaut serait plutôt dans la couche Netbios qui utilise pour ces
broadcasts UDP un port source identique au port destination d'après ce
que j'ai constaté. Dans ces condition il est impossible pour le suivi
d'état de distinguer une réponse au broadcast émis d'une requête unicast
émise par une autre machine puisque les deux ont les mêms ports source et
destination. Résultat, il laisse entrer les deux. La seule alternative
serait de bloquer les deux, mais ça casserait des choses.
Il en serait différemment si le port source du broadcast était un port
dynamique non privilégié. Ainsi le suivi d'état du firewall pourrait
distinguer les réponses (avec port destination = port source dynamique du
broadcast) des requêtes (avec port destination = 137 ou 138).
Ce qui me gêne dans le problème évoqué par eEye, ce n'est pas tant le fait qu'on ait un timer à 3 secondes pour l'acceptation des réponses aux broadcasts UDP, mais que cela, combiné à la délicate tradition consistant à polluer tout le LAN de broadcasts "indispensables", permet à tout utilisateur d'un LAN d'être *sûr* (!) de pouvoir atteindre les ports UDP/137 et UDP/138 de n'importe quel Windows XP SP2 (qui est pourtant le top en termes de sécurité Microsoft) de son réseau. Et cela malgré le demi-firewall censé au moins protéger l'inbound :-(
Mais ce "trou" n'est quand même pas imputable au suivi d'état du firewall. Il faut bien que les réponses puissent passer, et il n'y a pas cinquante façons de le faire.
AMA le défaut serait plutôt dans la couche Netbios qui utilise pour ces broadcasts UDP un port source identique au port destination d'après ce que j'ai constaté. Dans ces condition il est impossible pour le suivi d'état de distinguer une réponse au broadcast émis d'une requête unicast émise par une autre machine puisque les deux ont les mêms ports source et destination. Résultat, il laisse entrer les deux. La seule alternative serait de bloquer les deux, mais ça casserait des choses.
Il en serait différemment si le port source du broadcast était un port dynamique non privilégié. Ainsi le suivi d'état du firewall pourrait distinguer les réponses (avec port destination = port source dynamique du broadcast) des requêtes (avec port destination = 137 ou 138).
Qu'en pensez-vous ?
Pascal
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.
Il y a déjà un mécanisme prévu pour ça qui consiste à limiter le rythme d'émission des ICMP. Mais c'est sûr que bloquer aveuglément, c'est tellement plus facile.
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.
Et ne parlons pas des sites de scan de ports en ligne qui clignotent en rouge avec des messages d'alerte exagérément inquiétants dès qu'ils reçoivent le moindre ICMP ou RST en réponse à leur scan et martèlent qu'on n'est pas "en sécurité" si on n'est pas "stealth"...
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.
Il y a déjà un mécanisme prévu pour ça qui consiste à limiter le rythme
d'émission des ICMP. Mais c'est sûr que bloquer aveuglément, c'est
tellement plus facile.
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.
Et ne parlons pas des sites de scan de ports en ligne qui clignotent en
rouge avec des messages d'alerte exagérément inquiétants dès qu'ils
reçoivent le moindre ICMP ou RST en réponse à leur scan et martèlent
qu'on n'est pas "en sécurité" si on n'est pas "stealth"...
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.
Il y a déjà un mécanisme prévu pour ça qui consiste à limiter le rythme d'émission des ICMP. Mais c'est sûr que bloquer aveuglément, c'est tellement plus facile.
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.
Et ne parlons pas des sites de scan de ports en ligne qui clignotent en rouge avec des messages d'alerte exagérément inquiétants dès qu'ils reçoivent le moindre ICMP ou RST en réponse à leur scan et martèlent qu'on n'est pas "en sécurité" si on n'est pas "stealth"...
Nicob
On Thu, 12 May 2005 07:31:39 +0000, wrote:
Mais ce "trou" n'est quand même pas imputable au suivi d'état du firewall. Il faut bien que les réponses puissent passer, et il n'y a pas cinquante façons de le faire.
Yep. Mea culpa ...
Nicob
On Thu, 12 May 2005 07:31:39 +0000, Pascal@plouf wrote:
Mais ce "trou" n'est quand même pas imputable au suivi d'état du
firewall. Il faut bien que les réponses puissent passer, et il n'y a pas
cinquante façons de le faire.
Mais ce "trou" n'est quand même pas imputable au suivi d'état du firewall. Il faut bien que les réponses puissent passer, et il n'y a pas cinquante façons de le faire.
Yep. Mea culpa ...
Nicob
LaDDL
On Wed, 11 May 2005 23:19:48 +0200, Nicob wrote: - a une gestion des états UDP complètement bidon
Sur ton LAN t'as besoin de certains ports dont ceux cités précédemment soit 137 UDP et 138 UDP pour faire fonctionner certains services, etc.
Bon OK, j'étais pas clair (autant dans mes mots que dans ma tête).
Ce qui me gêne dans le problème évoqué par eEye, ce n'est pas tant le fait qu'on ait un timer à 3 secondes pour l'acceptation des réponses aux broadcasts UDP, mais que cela, combiné à la délicate tradition consistant à polluer tout le LAN de broadcasts "indispensables", permet à tout utilisateur d'un LAN d'être *sûr* (!) de pouvoir atteindre les ports UDP/137 et UDP/138 de n'importe quel Windows XP SP2 (qui est pourtant le top en termes de sécurité Microsoft) de son réseau. Et cela malgré le demi-firewall censé au moins protéger l'inbound :-(
Amha pour limiter les effets des broadcasts sur un LAN, il faut cloisonner en créant des sous-réseaux (aka subnet).
-- We have no control over the length of Our lives but We can control the width and depth of Our lives.
On Wed, 11 May 2005 23:19:48 +0200, Nicob
<nicob@I.hate.spammers.com> wrote:
- a une gestion des états UDP complètement bidon
Sur ton LAN t'as besoin de certains ports dont ceux cités précédemment
soit 137 UDP et 138 UDP pour faire fonctionner certains services, etc.
Bon OK, j'étais pas clair (autant dans mes mots que dans ma tête).
Ce qui me gêne dans le problème évoqué par eEye, ce n'est pas tant le
fait qu'on ait un timer à 3 secondes pour l'acceptation des réponses
aux broadcasts UDP, mais que cela, combiné à la délicate tradition
consistant à polluer tout le LAN de broadcasts "indispensables", permet
à tout utilisateur d'un LAN d'être *sûr* (!) de pouvoir atteindre les
ports UDP/137 et UDP/138 de n'importe quel Windows XP SP2 (qui est
pourtant le top en termes de sécurité Microsoft) de son réseau. Et cela
malgré le demi-firewall censé au moins protéger l'inbound :-(
Amha pour limiter les effets des broadcasts sur un LAN, il faut cloisonner
en créant des sous-réseaux (aka subnet).
--
We have no control over the length of Our lives but We can control the
width and depth of Our lives.
On Wed, 11 May 2005 23:19:48 +0200, Nicob wrote: - a une gestion des états UDP complètement bidon
Sur ton LAN t'as besoin de certains ports dont ceux cités précédemment soit 137 UDP et 138 UDP pour faire fonctionner certains services, etc.
Bon OK, j'étais pas clair (autant dans mes mots que dans ma tête).
Ce qui me gêne dans le problème évoqué par eEye, ce n'est pas tant le fait qu'on ait un timer à 3 secondes pour l'acceptation des réponses aux broadcasts UDP, mais que cela, combiné à la délicate tradition consistant à polluer tout le LAN de broadcasts "indispensables", permet à tout utilisateur d'un LAN d'être *sûr* (!) de pouvoir atteindre les ports UDP/137 et UDP/138 de n'importe quel Windows XP SP2 (qui est pourtant le top en termes de sécurité Microsoft) de son réseau. Et cela malgré le demi-firewall censé au moins protéger l'inbound :-(
Amha pour limiter les effets des broadcasts sur un LAN, il faut cloisonner en créant des sous-réseaux (aka subnet).
-- We have no control over the length of Our lives but We can control the width and depth of Our lives.
LaDDL
On Wed, 11 May 2005 19:56:27 +0200, Eric Masson wrote:
LaDDL writes:
L'intérêt amha réduire le traffic.
Et ça, c'est un intérêt suffisant pour casser des outils de diagnostic utiles ?
Réduire le traffic i.e. limiter les broadcasts sur un LAN ça ne te paraît pas légitime ?
Sinon peux-tu m'expliquer pourquoi le fait que des ports soient déclarés "stealthed" te "dérange" ? (PS merci de ne pas me ressortir le vieil argument des RFC, thx m8)
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.
Est-ce que tu lis ce à quoi tu réponds ?
Oui. Si tu ne me comprends pas il suffit de me dire pourquoi. Au moins on fait avancer le débat, nan ?
Le problème est qu'aucun warning n'est levé lors de la modification du paramétrage, pas que celui-ci soit modifiable.
Tu parles d'une modification légitime ou illégitime stp ?
Pour pouvoir modifier les paramétrages il faut disposer de tous les droits sur la machine.
-- We have no control over the length of Our lives but We can control the width and depth of Our lives.
On Wed, 11 May 2005 19:56:27 +0200, Eric Masson <emss@free.fr> wrote:
LaDDL <bounce@localhost.fr> writes:
L'intérêt amha réduire le traffic.
Et ça, c'est un intérêt suffisant pour casser des outils de diagnostic
utiles ?
Réduire le traffic i.e. limiter les broadcasts sur un LAN ça ne te paraît
pas légitime ?
Sinon peux-tu m'expliquer pourquoi le fait que des ports soient déclarés
"stealthed" te "dérange" ? (PS merci de ne pas me ressortir le vieil
argument des RFC, thx m8)
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.
Est-ce que tu lis ce à quoi tu réponds ?
Oui.
Si tu ne me comprends pas il suffit de me dire pourquoi. Au moins on fait
avancer le débat, nan ?
Le problème est qu'aucun warning n'est levé lors de la modification du
paramétrage, pas que celui-ci soit modifiable.
Tu parles d'une modification légitime ou illégitime stp ?
Pour pouvoir modifier les paramétrages il faut disposer de tous les droits
sur la machine.
--
We have no control over the length of Our lives but We can control the
width and depth of Our lives.
On Wed, 11 May 2005 19:56:27 +0200, Eric Masson wrote:
LaDDL writes:
L'intérêt amha réduire le traffic.
Et ça, c'est un intérêt suffisant pour casser des outils de diagnostic utiles ?
Réduire le traffic i.e. limiter les broadcasts sur un LAN ça ne te paraît pas légitime ?
Sinon peux-tu m'expliquer pourquoi le fait que des ports soient déclarés "stealthed" te "dérange" ? (PS merci de ne pas me ressortir le vieil argument des RFC, thx m8)
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.
Est-ce que tu lis ce à quoi tu réponds ?
Oui. Si tu ne me comprends pas il suffit de me dire pourquoi. Au moins on fait avancer le débat, nan ?
Le problème est qu'aucun warning n'est levé lors de la modification du paramétrage, pas que celui-ci soit modifiable.
Tu parles d'une modification légitime ou illégitime stp ?
Pour pouvoir modifier les paramétrages il faut disposer de tous les droits sur la machine.
-- We have no control over the length of Our lives but We can control the width and depth of Our lives.
LaDDL
On Thu, 12 May 2005 09:32:55 +0200, 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.
Il y a déjà un mécanisme prévu pour ça qui consiste à limiter le rythme d'émission des ICMP.
Yep avec une stratégie de groupe.
Mais c'est sûr que bloquer aveuglément, c'est tellement plus facile.
Certes. Mais tu peux aussi limiter les broadcasts en créant des sous-réseaux sur ton LAN.
-- We have no control over the length of Our lives but We can control the width and depth of Our lives.
On Thu, 12 May 2005 09:32:55 +0200, Pascal@plouf <pascal@plouf.invalid>
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.
Il y a déjà un mécanisme prévu pour ça qui consiste à limiter le rythme
d'émission des ICMP.
Yep avec une stratégie de groupe.
Mais c'est sûr que bloquer aveuglément, c'est tellement plus facile.
Certes.
Mais tu peux aussi limiter les broadcasts en créant des sous-réseaux sur
ton LAN.
--
We have no control over the length of Our lives but We can control the
width and depth of Our lives.
