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
Réduire le traffic i.e. limiter les broadcasts sur un LAN ça ne te paraît pas légitime ?
Dans ce cas, tu utilises le mode natif de 2k/2k3, et tu n'appliques pas un cautère sur une jambe de bois.
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)
Ça casse le traceroute par exemple (les versions unix sont basées par défaut sur de l'udp)
Tu parles d'une modification légitime ou illégitime stp ?
Dans les deux cas.
Pour pouvoir modifier les paramétrages il faut disposer de tous les droits sur la machine.
Oui et ?
Dans le cas d'une installation hors AD, tu as les droits admin par défaut, dans le cas d'une installation AD, certains softs de production ne peuvent fonctionner s'ils ne sont pas opérés par un compte qui est admin local, alors, de fait, tu as les droits suffisants pour modifier le paramétrage du fw.
Éric Masson
-- Lu sur linux.wine.users :
I have a bottle of Haut Medoc from 1971 and wondered if anyone on this BB could advise as to possible value and drinkability. -+- PB in Guide du linuxien pervers - "Important ça, la drinkability !" -+-
LaDDL <bounce@localhost.fr> writes:
Réduire le traffic i.e. limiter les broadcasts sur un LAN ça ne te
paraît pas légitime ?
Dans ce cas, tu utilises le mode natif de 2k/2k3, et tu n'appliques pas
un cautère sur une jambe de bois.
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)
Ça casse le traceroute par exemple (les versions unix sont basées par
défaut sur de l'udp)
Tu parles d'une modification légitime ou illégitime stp ?
Dans les deux cas.
Pour pouvoir modifier les paramétrages il faut disposer de tous les
droits sur la machine.
Oui et ?
Dans le cas d'une installation hors AD, tu as les droits admin par
défaut, dans le cas d'une installation AD, certains softs de production
ne peuvent fonctionner s'ils ne sont pas opérés par un compte qui est
admin local, alors, de fait, tu as les droits suffisants pour modifier
le paramétrage du fw.
Éric Masson
--
Lu sur linux.wine.users :
I have a bottle of Haut Medoc from 1971 and wondered if anyone on this BB
could advise as to possible value and drinkability.
-+- PB in Guide du linuxien pervers - "Important ça, la drinkability !" -+-
Réduire le traffic i.e. limiter les broadcasts sur un LAN ça ne te paraît pas légitime ?
Dans ce cas, tu utilises le mode natif de 2k/2k3, et tu n'appliques pas un cautère sur une jambe de bois.
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)
Ça casse le traceroute par exemple (les versions unix sont basées par défaut sur de l'udp)
Tu parles d'une modification légitime ou illégitime stp ?
Dans les deux cas.
Pour pouvoir modifier les paramétrages il faut disposer de tous les droits sur la machine.
Oui et ?
Dans le cas d'une installation hors AD, tu as les droits admin par défaut, dans le cas d'une installation AD, certains softs de production ne peuvent fonctionner s'ils ne sont pas opérés par un compte qui est admin local, alors, de fait, tu as les droits suffisants pour modifier le paramétrage du fw.
Éric Masson
-- Lu sur linux.wine.users :
I have a bottle of Haut Medoc from 1971 and wondered if anyone on this BB could advise as to possible value and drinkability. -+- PB in Guide du linuxien pervers - "Important ça, la drinkability !" -+-
Eric Razny
Le Wed, 11 May 2005 01:16:42 +0000, a écrit :
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.
Yep. :-/
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.
Autant pour moi ça m'apprendra à parcourir un article sans le lire vraiment tout en faisant autre chose :
<quote> In contrast to sending "unsolicited traffic" into a protected network, a firewall could be bypassed in some circumstances by getting a protected host to "solicit" traffic from a malicious host on the outside, in which case the firewall would most likely allow the malicious host's response back through. For instance, an attacker could compromise a web site visited by the user of a protected host within the network, or could hijack or poison a DNS server and redirect that user's traffic to a malicious system. </quote>
Trad approx et partielle : au lieu d'essayer d'envoyer du traffic non sollicité on peu pousser une machine a soliciter du traffic de l'extérieur. Ex web site offenssif, hijacking d'une requete DNS ou DNS poisoning pour rediriger le traffic de l'utilisateur vers un système malin.
Et il donnait ensuite le verbiage sur les 137 & 138/UDP comme exemple.
Le problème est bien netbios qui est bavard à mort et pas vraiment le fw (enfin pour le fw le problème de laisser passer des paquets du LAN sans raison c'était pas mal non plus).
Tu aimes vraiment le smurf? :)
Quel rapport avec le comportement du suivi d'état de Netfilter face aux réponses à un ping broadcast ?
Celui de t'avoir mal lu. Sorry.
Eric
Le Wed, 11 May 2005 01:16:42 +0000, Pascal@plouf a écrit :
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.
Yep. :-/
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.
Autant pour moi ça m'apprendra à parcourir un article sans le lire
vraiment tout en faisant autre chose :
<quote>
In contrast to sending "unsolicited traffic" into a protected network, a
firewall could be bypassed in some circumstances by getting a protected
host to "solicit" traffic from a malicious host on the outside, in which
case the firewall would most likely allow the malicious host's response
back through. For instance, an attacker could compromise a web site
visited by the user of a protected host within the network, or could
hijack or poison a DNS server and redirect that user's traffic to a
malicious system.
</quote>
Trad approx et partielle : au lieu d'essayer d'envoyer du traffic non
sollicité on peu pousser une machine a soliciter du traffic de
l'extérieur. Ex web site offenssif, hijacking d'une requete DNS ou DNS
poisoning pour rediriger le traffic de l'utilisateur vers un système
malin.
Et il donnait ensuite le verbiage sur les 137 & 138/UDP comme exemple.
Le problème est bien netbios qui est bavard à mort et pas vraiment le fw
(enfin pour le fw le problème de laisser passer des paquets du LAN sans
raison c'était pas mal non plus).
Tu aimes vraiment le smurf? :)
Quel rapport avec le comportement du suivi d'état de Netfilter face aux
réponses à un ping broadcast ?
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.
Yep. :-/
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.
Autant pour moi ça m'apprendra à parcourir un article sans le lire vraiment tout en faisant autre chose :
<quote> In contrast to sending "unsolicited traffic" into a protected network, a firewall could be bypassed in some circumstances by getting a protected host to "solicit" traffic from a malicious host on the outside, in which case the firewall would most likely allow the malicious host's response back through. For instance, an attacker could compromise a web site visited by the user of a protected host within the network, or could hijack or poison a DNS server and redirect that user's traffic to a malicious system. </quote>
Trad approx et partielle : au lieu d'essayer d'envoyer du traffic non sollicité on peu pousser une machine a soliciter du traffic de l'extérieur. Ex web site offenssif, hijacking d'une requete DNS ou DNS poisoning pour rediriger le traffic de l'utilisateur vers un système malin.
Et il donnait ensuite le verbiage sur les 137 & 138/UDP comme exemple.
Le problème est bien netbios qui est bavard à mort et pas vraiment le fw (enfin pour le fw le problème de laisser passer des paquets du LAN sans raison c'était pas mal non plus).
Tu aimes vraiment le smurf? :)
Quel rapport avec le comportement du suivi d'état de Netfilter face aux réponses à un ping broadcast ?
Celui de t'avoir mal lu. Sorry.
Eric
LaDDL
On Fri, 13 May 2005 11:00:06 +0200, Eric Masson wrote:
LaDDL writes: Réduire le traffic i.e. limiter les broadcasts sur un LAN ça ne te paraît pas légitime ?
Dans ce cas, tu utilises le mode natif de 2k/2k3, et tu n'appliques pas un cautère sur une jambe de bois.
Bien sûr qu'un domaine doit être passé en mode natif. Mais excuse-moi je ne vois pas trop le rapport avec le sujet. Désolé. Peux-tu préciser stp le fond de ta pensée ?
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)
Ça casse le traceroute par exemple (les versions unix sont basées par défaut sur de l'udp)
De manière générale, sur un LAN je te rejoins complétement, les ports doivent émettre des réponses à toutes sortes de requêtes. Mais pour un PC isolé interconnecté au réseau des réseaux, je trouve amha normal que ses ports soient déclarés stealthed.
Tu parles d'une modification légitime ou illégitime stp ?
Dans les deux cas.
Une modification légitime des paramètres de Windows Firewall signifie pour moi que l'utilisateur et/ou l'administrateur autorise l'éxecution/injection de code. Amha pour éviter une modification illégitime il faut contrôler et surveiller l'éxecution/injection de code.
Pour pouvoir modifier les paramétrages il faut disposer de tous les droits sur la machine.
Oui et ?
Dans le cas d'une installation hors AD, tu as les droits admin par défaut, dans le cas d'une installation AD, certains softs de production ne peuvent fonctionner s'ils ne sont pas opérés par un compte qui est admin local, alors, de fait, tu as les droits suffisants pour modifier le paramétrage du fw.
Amha quelque soit le contexte, LAN ou PC isolé, la problématique est la même pour la modification des paramètres de Windows Firewall. Il faut contrôler et surveiller l'éxecution/injection de code.
-- We have no control over the length of Our lives but We can control the width and depth of Our lives.
On Fri, 13 May 2005 11:00:06 +0200, Eric Masson <emss@free.fr> wrote:
LaDDL <bounce@localhost.fr> writes:
Réduire le traffic i.e. limiter les broadcasts sur un LAN ça ne te
paraît pas légitime ?
Dans ce cas, tu utilises le mode natif de 2k/2k3, et tu n'appliques pas
un cautère sur une jambe de bois.
Bien sûr qu'un domaine doit être passé en mode natif. Mais excuse-moi je
ne vois pas trop le
rapport avec le sujet. Désolé. Peux-tu préciser stp le fond de ta pensée ?
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)
Ça casse le traceroute par exemple (les versions unix sont basées par
défaut sur de l'udp)
De manière générale, sur un LAN je te rejoins complétement, les ports
doivent émettre des réponses à toutes sortes de requêtes.
Mais pour un PC isolé interconnecté au réseau des réseaux, je trouve amha
normal que ses ports soient déclarés stealthed.
Tu parles d'une modification légitime ou illégitime stp ?
Dans les deux cas.
Une modification légitime des paramètres de Windows Firewall signifie pour
moi que l'utilisateur et/ou l'administrateur autorise
l'éxecution/injection de code.
Amha pour éviter une modification illégitime il faut contrôler et
surveiller l'éxecution/injection de code.
Pour pouvoir modifier les paramétrages il faut disposer de tous les
droits sur la machine.
Oui et ?
Dans le cas d'une installation hors AD, tu as les droits admin par
défaut, dans le cas d'une installation AD, certains softs de production
ne peuvent fonctionner s'ils ne sont pas opérés par un compte qui est
admin local, alors, de fait, tu as les droits suffisants pour modifier
le paramétrage du fw.
Amha quelque soit le contexte, LAN ou PC isolé, la problématique est la
même pour la modification des paramètres de Windows Firewall. Il faut
contrôler et surveiller l'éxecution/injection de code.
--
We have no control over the length of Our lives but We can control the
width and depth of Our lives.
On Fri, 13 May 2005 11:00:06 +0200, Eric Masson wrote:
LaDDL writes: Réduire le traffic i.e. limiter les broadcasts sur un LAN ça ne te paraît pas légitime ?
Dans ce cas, tu utilises le mode natif de 2k/2k3, et tu n'appliques pas un cautère sur une jambe de bois.
Bien sûr qu'un domaine doit être passé en mode natif. Mais excuse-moi je ne vois pas trop le rapport avec le sujet. Désolé. Peux-tu préciser stp le fond de ta pensée ?
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)
Ça casse le traceroute par exemple (les versions unix sont basées par défaut sur de l'udp)
De manière générale, sur un LAN je te rejoins complétement, les ports doivent émettre des réponses à toutes sortes de requêtes. Mais pour un PC isolé interconnecté au réseau des réseaux, je trouve amha normal que ses ports soient déclarés stealthed.
Tu parles d'une modification légitime ou illégitime stp ?
Dans les deux cas.
Une modification légitime des paramètres de Windows Firewall signifie pour moi que l'utilisateur et/ou l'administrateur autorise l'éxecution/injection de code. Amha pour éviter une modification illégitime il faut contrôler et surveiller l'éxecution/injection de code.
Pour pouvoir modifier les paramétrages il faut disposer de tous les droits sur la machine.
Oui et ?
Dans le cas d'une installation hors AD, tu as les droits admin par défaut, dans le cas d'une installation AD, certains softs de production ne peuvent fonctionner s'ils ne sont pas opérés par un compte qui est admin local, alors, de fait, tu as les droits suffisants pour modifier le paramétrage du fw.
Amha quelque soit le contexte, LAN ou PC isolé, la problématique est la même pour la modification des paramètres de Windows Firewall. Il faut contrôler et surveiller l'éxecution/injection de code.
-- We have no control over the length of Our lives but We can control the width and depth of Our lives.
Olivier Masson
Est-ce que cela signifie que n'importe quelle application peut modifier les règles sans prévenir? Si oui, quelles sont les protections? Ou est-ce que je comprends mal?
Laurent
Ca me fait plaisir de voir que ça étonne quelqu'un :) J'ai du faire un rapport sur le SP2 à la sortie de leur première béta (il y a plus d'un an maintenant) et j'avais du mal à comprendre que certains applications pouvaient passer outre le FW parce que... ben parce que je sais pas. Et que certaines appli SP2-aware pouvaient se déclarer elles-mêmes et autoriser dynamiquement des ports. Alors j'ai écrit à MS, qui ne m'a jamais répondu. J'ai écrit sur le forum de labo microsoft, où personne ne m'a jamais répondu (et d'ailleurs tout le monde semblait s'en foutre). Je n'ai toujours pas de réponse... et je désactive le FW de MS dans toutes mes politiques de sécurité :)
Est-ce que cela signifie que n'importe quelle application peut modifier les
règles sans prévenir? Si oui, quelles sont les protections?
Ou est-ce que je comprends mal?
Laurent
Ca me fait plaisir de voir que ça étonne quelqu'un :)
J'ai du faire un rapport sur le SP2 à la sortie de leur première béta
(il y a plus d'un an maintenant) et j'avais du mal à comprendre que
certains applications pouvaient passer outre le FW parce que... ben
parce que je sais pas. Et que certaines appli SP2-aware pouvaient se
déclarer elles-mêmes et autoriser dynamiquement des ports.
Alors j'ai écrit à MS, qui ne m'a jamais répondu. J'ai écrit sur le
forum de labo microsoft, où personne ne m'a jamais répondu (et
d'ailleurs tout le monde semblait s'en foutre).
Je n'ai toujours pas de réponse... et je désactive le FW de MS dans
toutes mes politiques de sécurité :)
Est-ce que cela signifie que n'importe quelle application peut modifier les règles sans prévenir? Si oui, quelles sont les protections? Ou est-ce que je comprends mal?
Laurent
Ca me fait plaisir de voir que ça étonne quelqu'un :) J'ai du faire un rapport sur le SP2 à la sortie de leur première béta (il y a plus d'un an maintenant) et j'avais du mal à comprendre que certains applications pouvaient passer outre le FW parce que... ben parce que je sais pas. Et que certaines appli SP2-aware pouvaient se déclarer elles-mêmes et autoriser dynamiquement des ports. Alors j'ai écrit à MS, qui ne m'a jamais répondu. J'ai écrit sur le forum de labo microsoft, où personne ne m'a jamais répondu (et d'ailleurs tout le monde semblait s'en foutre). Je n'ai toujours pas de réponse... et je désactive le FW de MS dans toutes mes politiques de sécurité :)
