Je suis tombé par hasard sur cet article :
<news:mh1m211388f9uimvticeiflj55a6dt5n3l@4ax.com>
Il fait référence à la page
<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/HTHardTCP.asp>
Et plus particulièrement à la section
> Additional Protections
>
> All of the keys and values in this section are located under the registry key
> HKLM\System\CurrentControlSet\Services\Tcpip\Parameters.
> [...]
>
> Avoid Accepting Fragmented Packets
>
> Processing fragmented packets can be expensive. Although it is rare for a
> denial of service to originate from within the perimeter network, this setting
> prevents the processing of fragmented packets.
>
> Value: EnableFragmentChecking
>
> Recommended value data: 1
>
> Valid values: 0 (disabled), 1 (enabled)
>
> Description: Prevents the IP stack from accepting fragmented packets.
En gros, une modification dans la base de registres permettrait
d'interdire les paquets fragmentés, et donc d'ignorer le bug de Kerio
2.1.5.
Les avis semblent partagés sur comp.security.firewalls, et sur le site
de Microsoft, je n'ai pas compris de quelle version de Windows ils
parlaient. À vrai dire, je n'ai même pas compris s'il fallait mettre
la valeur à 1 ou à 0 pour être protégé... et je ne ferai pas de tests
aujourd'hui, Morphée s'impatiente.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
LaDDL
On 21 Apr 2005 05:08:45 GMT, Fabien LE LEZ wrote:
Bonjour,
Bonjour,
Je suis tombé par hasard sur cet article : <news:
Il fait référence à la page <http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/HTHardTCP.asp>
C'est un howto indispensable pour ceux qui connaissent la BDR et veulent durcir leur OS.
Et plus particulièrement à la section
Additional Protections
All of the keys and values in this section are located under the registry key HKLMSystemCurrentControlSetServicesTcpipParameters. [...]
Avoid Accepting Fragmented Packets
Processing fragmented packets can be expensive. Although it is rare for a denial of service to originate from within the perimeter network, this setting prevents the processing of fragmented packets.
Value: EnableFragmentChecking
Recommended value data: 1
Valid values: 0 (disabled), 1 (enabled)
Description: Prevents the IP stack from accepting fragmented packets.
En gros, une modification dans la base de registres permettrait d'interdire les paquets fragmentés, et donc d'ignorer le bug de Kerio 2.1.5.
Sur du 95, 98, Me je ne suis pas sûr. Va falloir tester. Sur un XP SP2 c bon. Faut tester sur les autres OS : NT et 2000
Les avis semblent partagés sur comp.security.firewalls, et sur le site de Microsoft, je n'ai pas compris de quelle version de Windows ils parlaient.
Cf mon propos ci-haut.
À vrai dire, je n'ai même pas compris s'il fallait mettre la valeur à 1 ou à 0 pour être protégé...
0 = désactiver 1 = activer
Tu mets 1.
et je ne ferai pas de tests aujourd'hui, Morphée s'impatiente.
C'est tellement bon quand elle nous prend dans ses bras. ;)
Quelqu'un a-t-il un avis sur la question ?
J'espère t'avoir aidé.
-- We have no control over the length of Our lives but We can control the width and depth of Our lives.
On 21 Apr 2005 05:08:45 GMT, Fabien LE LEZ <gramster@gramster.com> wrote:
Bonjour,
Bonjour,
Je suis tombé par hasard sur cet article :
<news:mh1m211388f9uimvticeiflj55a6dt5n3l@4ax.com>
Il fait référence à la page
<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/HTHardTCP.asp>
C'est un howto indispensable pour ceux qui connaissent la BDR et veulent
durcir leur OS.
Et plus particulièrement à la section
Additional Protections
All of the keys and values in this section are located under the
registry key
HKLMSystemCurrentControlSetServicesTcpipParameters.
[...]
Avoid Accepting Fragmented Packets
Processing fragmented packets can be expensive. Although it is rare for
a
denial of service to originate from within the perimeter network, this
setting
prevents the processing of fragmented packets.
Value: EnableFragmentChecking
Recommended value data: 1
Valid values: 0 (disabled), 1 (enabled)
Description: Prevents the IP stack from accepting fragmented packets.
En gros, une modification dans la base de registres permettrait
d'interdire les paquets fragmentés, et donc d'ignorer le bug de Kerio
2.1.5.
Sur du 95, 98, Me je ne suis pas sûr. Va falloir tester.
Sur un XP SP2 c bon.
Faut tester sur les autres OS : NT et 2000
Les avis semblent partagés sur comp.security.firewalls, et sur le site
de Microsoft, je n'ai pas compris de quelle version de Windows ils
parlaient.
Cf mon propos ci-haut.
À vrai dire, je n'ai même pas compris s'il fallait mettre
la valeur à 1 ou à 0 pour être protégé...
0 = désactiver
1 = activer
Tu mets 1.
et je ne ferai pas de tests
aujourd'hui, Morphée s'impatiente.
C'est tellement bon quand elle nous prend dans ses bras. ;)
Quelqu'un a-t-il un avis sur la question ?
J'espère t'avoir aidé.
--
We have no control over the length of Our lives but We can control the
width and depth of Our lives.
Il fait référence à la page <http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/HTHardTCP.asp>
C'est un howto indispensable pour ceux qui connaissent la BDR et veulent durcir leur OS.
Et plus particulièrement à la section
Additional Protections
All of the keys and values in this section are located under the registry key HKLMSystemCurrentControlSetServicesTcpipParameters. [...]
Avoid Accepting Fragmented Packets
Processing fragmented packets can be expensive. Although it is rare for a denial of service to originate from within the perimeter network, this setting prevents the processing of fragmented packets.
Value: EnableFragmentChecking
Recommended value data: 1
Valid values: 0 (disabled), 1 (enabled)
Description: Prevents the IP stack from accepting fragmented packets.
En gros, une modification dans la base de registres permettrait d'interdire les paquets fragmentés, et donc d'ignorer le bug de Kerio 2.1.5.
Sur du 95, 98, Me je ne suis pas sûr. Va falloir tester. Sur un XP SP2 c bon. Faut tester sur les autres OS : NT et 2000
Les avis semblent partagés sur comp.security.firewalls, et sur le site de Microsoft, je n'ai pas compris de quelle version de Windows ils parlaient.
Cf mon propos ci-haut.
À vrai dire, je n'ai même pas compris s'il fallait mettre la valeur à 1 ou à 0 pour être protégé...
0 = désactiver 1 = activer
Tu mets 1.
et je ne ferai pas de tests aujourd'hui, Morphée s'impatiente.
C'est tellement bon quand elle nous prend dans ses bras. ;)
Quelqu'un a-t-il un avis sur la question ?
J'espère t'avoir aidé.
-- We have no control over the length of Our lives but We can control the width and depth of Our lives.
Cedric Blancher
Le Thu, 21 Apr 2005 05:08:45 +0000, Fabien LE LEZ a écrit :
Avoid Accepting Fragmented Packets En gros, une modification dans la base de registres permettrait
d'interdire les paquets fragmentés, et donc d'ignorer le bug de Kerio 2.1.5.
Mouais. Ça s'appelle la politique de l'autruche. Il y a des outils qui n'ont pas de problème de fragmentation. Casser un mécanisme juste pour utiliser des outils pourris me semble bête et dangereux.
D'autant que la fragmentation, ça existe, et que c'est à la station finale de la gérer, pas à l'infrastructure réseau, même si beaucoup de firewalls défragmentent.
Quelqu'un a-t-il un avis sur la question ?
C'est pas RFC compliant, donc à priori mal. Les exemples de "protections" de ce type sont légion. En tête, filtrer les erreurs ICMP, ce qui revient à casser le PMTU Discovery et aboutir aux problèmes de freeze de connexion que tous les gars qui ont un LAN derrière un lien ADSL PPPoE ont connu. Tiens, je remarque d'ailleurs que MS annonce une mauvaise gestion du PMTU Discovery. Ils pourraient nous mettre une clé de registre pour ignorer ce mécanisme, non ?
-- je me fais un réveil matin qui m'énonce les SC6 et SC7 de word98 [avec le Speech de MacsBug]. Si je me lève pas pour l'éteindre, je suis sûr que ma femme le fera .-) -+- BL in Guide du Macounet Pervers : Tyran domestique ! -+-
Le Thu, 21 Apr 2005 05:08:45 +0000, Fabien LE LEZ a écrit :
Avoid Accepting Fragmented Packets
En gros, une modification dans la base de registres permettrait
d'interdire les paquets fragmentés, et donc d'ignorer le bug de Kerio
2.1.5.
Mouais.
Ça s'appelle la politique de l'autruche. Il y a des outils qui n'ont pas
de problème de fragmentation. Casser un mécanisme juste pour utiliser
des outils pourris me semble bête et dangereux.
D'autant que la fragmentation, ça existe, et que c'est à la station
finale de la gérer, pas à l'infrastructure réseau, même si beaucoup de
firewalls défragmentent.
Quelqu'un a-t-il un avis sur la question ?
C'est pas RFC compliant, donc à priori mal.
Les exemples de "protections" de ce type sont légion. En tête, filtrer
les erreurs ICMP, ce qui revient à casser le PMTU Discovery et aboutir
aux problèmes de freeze de connexion que tous les gars qui ont un LAN
derrière un lien ADSL PPPoE ont connu. Tiens, je remarque d'ailleurs que
MS annonce une mauvaise gestion du PMTU Discovery. Ils pourraient nous
mettre une clé de registre pour ignorer ce mécanisme, non ?
--
je me fais un réveil matin qui m'énonce les SC6 et SC7 de word98 [avec
le Speech de MacsBug]. Si je me lève pas pour l'éteindre, je suis sûr
que ma femme le fera .-)
-+- BL in Guide du Macounet Pervers : Tyran domestique ! -+-
Le Thu, 21 Apr 2005 05:08:45 +0000, Fabien LE LEZ a écrit :
Avoid Accepting Fragmented Packets En gros, une modification dans la base de registres permettrait
d'interdire les paquets fragmentés, et donc d'ignorer le bug de Kerio 2.1.5.
Mouais. Ça s'appelle la politique de l'autruche. Il y a des outils qui n'ont pas de problème de fragmentation. Casser un mécanisme juste pour utiliser des outils pourris me semble bête et dangereux.
D'autant que la fragmentation, ça existe, et que c'est à la station finale de la gérer, pas à l'infrastructure réseau, même si beaucoup de firewalls défragmentent.
Quelqu'un a-t-il un avis sur la question ?
C'est pas RFC compliant, donc à priori mal. Les exemples de "protections" de ce type sont légion. En tête, filtrer les erreurs ICMP, ce qui revient à casser le PMTU Discovery et aboutir aux problèmes de freeze de connexion que tous les gars qui ont un LAN derrière un lien ADSL PPPoE ont connu. Tiens, je remarque d'ailleurs que MS annonce une mauvaise gestion du PMTU Discovery. Ils pourraient nous mettre une clé de registre pour ignorer ce mécanisme, non ?
-- je me fais un réveil matin qui m'énonce les SC6 et SC7 de word98 [avec le Speech de MacsBug]. Si je me lève pas pour l'éteindre, je suis sûr que ma femme le fera .-) -+- BL in Guide du Macounet Pervers : Tyran domestique ! -+-
LaDDL
On 21 Apr 2005 09:14:15 GMT, Cedric Blancher wrote:
[...]
Tiens, je remarque d'ailleurs que MS annonce une mauvaise gestion du PMTU Discovery. Ils pourraient nous mettre une clé de registre pour ignorer ce mécanisme, non ?
C'est précisé dans le bulletin MS05-19. ;)
Ce qui est conseillé (si ce n'était pas déjà fait par certains avant la publication de ce bulletin).
Ouvrir son éditeur de BDR, allez ici : HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters
Ajouter la valeur DWORD : EnablePMTUDiscovery. Indiquer le paramètre 0 pour la valeur.
On 21 Apr 2005 09:14:15 GMT, Cedric Blancher <blancher@cartel-securite.fr>
wrote:
[...]
Tiens, je remarque d'ailleurs que
MS annonce une mauvaise gestion du PMTU Discovery. Ils pourraient nous
mettre une clé de registre pour ignorer ce mécanisme, non ?
C'est précisé dans le bulletin MS05-19. ;)
Ce qui est conseillé (si ce n'était pas déjà fait par certains avant la
publication de ce bulletin).
Ouvrir son éditeur de BDR, allez ici :
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters
Ajouter la valeur DWORD : EnablePMTUDiscovery. Indiquer le paramètre 0
pour la valeur.
On 21 Apr 2005 09:14:15 GMT, Cedric Blancher wrote:
[...]
Tiens, je remarque d'ailleurs que MS annonce une mauvaise gestion du PMTU Discovery. Ils pourraient nous mettre une clé de registre pour ignorer ce mécanisme, non ?
C'est précisé dans le bulletin MS05-19. ;)
Ce qui est conseillé (si ce n'était pas déjà fait par certains avant la publication de ce bulletin).
Ouvrir son éditeur de BDR, allez ici : HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters
Ajouter la valeur DWORD : EnablePMTUDiscovery. Indiquer le paramètre 0 pour la valeur.
Cedric Blancher
Le Thu, 21 Apr 2005 10:13:06 +0000, LaDDL a écrit :
C'est précisé dans le bulletin MS05-19. ;) Ce qui est conseillé (si ce n'était pas déjà fait par certains avant la publication de ce bulletin). Ouvrir son éditeur de BDR, allez ici : HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters Ajouter la valeur DWORD : EnablePMTUDiscovery. Indiquer le paramètre 0 pour la valeur.
OK, donc pour résumer :
. on désactive le PMTU discovery . on désactive le support des paquets fragmentés
Hummm. Je sens que ça va bien passer pour les gens directement connectés à Internet...
-- BOFH excuse #260:
We're upgrading /dev/null
Le Thu, 21 Apr 2005 10:13:06 +0000, LaDDL a écrit :
C'est précisé dans le bulletin MS05-19. ;)
Ce qui est conseillé (si ce n'était pas déjà fait par certains avant la
publication de ce bulletin).
Ouvrir son éditeur de BDR, allez ici :
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters
Ajouter la valeur DWORD : EnablePMTUDiscovery. Indiquer le paramètre 0
pour la valeur.
OK, donc pour résumer :
. on désactive le PMTU discovery
. on désactive le support des paquets fragmentés
Hummm. Je sens que ça va bien passer pour les gens directement
connectés à Internet...
Le Thu, 21 Apr 2005 10:13:06 +0000, LaDDL a écrit :
C'est précisé dans le bulletin MS05-19. ;) Ce qui est conseillé (si ce n'était pas déjà fait par certains avant la publication de ce bulletin). Ouvrir son éditeur de BDR, allez ici : HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters Ajouter la valeur DWORD : EnablePMTUDiscovery. Indiquer le paramètre 0 pour la valeur.
OK, donc pour résumer :
. on désactive le PMTU discovery . on désactive le support des paquets fragmentés
Hummm. Je sens que ça va bien passer pour les gens directement connectés à Internet...
-- BOFH excuse #260:
We're upgrading /dev/null
LaDDL
On 21 Apr 2005 11:09:08 GMT, Cedric Blancher wrote:
Le Thu, 21 Apr 2005 10:13:06 +0000, LaDDL a écrit : C'est précisé dans le bulletin MS05-19. ;) Ce qui est conseillé (si ce n'était pas déjà fait par certains avant la publication de ce bulletin). Ouvrir son éditeur de BDR, allez ici : HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters Ajouter la valeur DWORD : EnablePMTUDiscovery. Indiquer le paramètre 0 pour la valeur.
OK, donc pour résumer :
. on désactive le PMTU discovery . on désactive le support des paquets fragmentés
Hummm. Je sens que ça va bien passer pour les gens directement connectés à Internet...
Tout dépend bien entendu du contexte/environnement de chacun.
Je n'incite pas tout le monde à suivre ces modifications dans sa BDR sans avoir pris le soin de vérifier s'ils ont besoin de réduire la taille maximale des paquets envoyés afin d'avoir une latence plus faible.
Pour information : 0 pour la valeur DWORD : EnablePMTUDiscovery signifie que vous fixez le MTU à 576.
Plus d'éléments ici sur EnablePMTUDiscovery : http://www.microsoft.com/resources/documentation/Windows/2000/server/reskit/en-us/Default.asp?url=/resources/documentation/Windows/2000/server/reskit/en-us/regentry/58752.asp
-- We have no control over the length of Our lives but We can control the width and depth of Our lives.
On 21 Apr 2005 11:09:08 GMT, Cedric Blancher <blancher@cartel-securite.fr>
wrote:
Le Thu, 21 Apr 2005 10:13:06 +0000, LaDDL a écrit :
C'est précisé dans le bulletin MS05-19. ;)
Ce qui est conseillé (si ce n'était pas déjà fait par certains avant la
publication de ce bulletin).
Ouvrir son éditeur de BDR, allez ici :
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters
Ajouter la valeur DWORD : EnablePMTUDiscovery. Indiquer le paramètre 0
pour la valeur.
OK, donc pour résumer :
. on désactive le PMTU discovery
. on désactive le support des paquets fragmentés
Hummm. Je sens que ça va bien passer pour les gens directement
connectés à Internet...
Tout dépend bien entendu du contexte/environnement de chacun.
Je n'incite pas tout le monde à suivre ces modifications dans sa BDR sans
avoir pris le soin de vérifier s'ils ont besoin de réduire la taille
maximale des paquets envoyés afin d'avoir une latence plus faible.
Pour information : 0 pour la valeur DWORD : EnablePMTUDiscovery signifie
que vous fixez le MTU à 576.
Plus d'éléments ici sur EnablePMTUDiscovery :
http://www.microsoft.com/resources/documentation/Windows/2000/server/reskit/en-us/Default.asp?url=/resources/documentation/Windows/2000/server/reskit/en-us/regentry/58752.asp
--
We have no control over the length of Our lives but We can control the
width and depth of Our lives.
On 21 Apr 2005 11:09:08 GMT, Cedric Blancher wrote:
Le Thu, 21 Apr 2005 10:13:06 +0000, LaDDL a écrit : C'est précisé dans le bulletin MS05-19. ;) Ce qui est conseillé (si ce n'était pas déjà fait par certains avant la publication de ce bulletin). Ouvrir son éditeur de BDR, allez ici : HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters Ajouter la valeur DWORD : EnablePMTUDiscovery. Indiquer le paramètre 0 pour la valeur.
OK, donc pour résumer :
. on désactive le PMTU discovery . on désactive le support des paquets fragmentés
Hummm. Je sens que ça va bien passer pour les gens directement connectés à Internet...
Tout dépend bien entendu du contexte/environnement de chacun.
Je n'incite pas tout le monde à suivre ces modifications dans sa BDR sans avoir pris le soin de vérifier s'ils ont besoin de réduire la taille maximale des paquets envoyés afin d'avoir une latence plus faible.
Pour information : 0 pour la valeur DWORD : EnablePMTUDiscovery signifie que vous fixez le MTU à 576.
Plus d'éléments ici sur EnablePMTUDiscovery : http://www.microsoft.com/resources/documentation/Windows/2000/server/reskit/en-us/Default.asp?url=/resources/documentation/Windows/2000/server/reskit/en-us/regentry/58752.asp
-- We have no control over the length of Our lives but We can control the width and depth of Our lives.
MELMOTH
Cedric Blancher nous susurrait le 21/04/05, dans le message , les troubles mélismes suivants :
. on désactive le PMTU discovery
La ligne n'existait pas dans mon win98se...je l'ai donc rajoutée et mis la valeur à 0
. on désactive le support des paquets fragmentés
Ça par contre, je ne sais pas comment faire...merci pour l'aide... [N.B. : J'utilise Kerion 2.1.5...les versions 4 ont *toujours* fait planter ma bécane]....
Cedric Blancher nous susurrait le 21/04/05, dans le message
<pan.2005.04.21.11.08.24.581600@cartel-securite.fr>, les troubles
mélismes suivants :
. on désactive le PMTU discovery
La ligne n'existait pas dans mon win98se...je l'ai donc rajoutée et mis
la valeur à 0
. on désactive le support des paquets fragmentés
Ça par contre, je ne sais pas comment faire...merci pour l'aide...
[N.B. : J'utilise Kerion 2.1.5...les versions 4 ont *toujours* fait
planter ma bécane]....
Cedric Blancher nous susurrait le 21/04/05, dans le message , les troubles mélismes suivants :
. on désactive le PMTU discovery
La ligne n'existait pas dans mon win98se...je l'ai donc rajoutée et mis la valeur à 0
. on désactive le support des paquets fragmentés
Ça par contre, je ne sais pas comment faire...merci pour l'aide... [N.B. : J'utilise Kerion 2.1.5...les versions 4 ont *toujours* fait planter ma bécane]....
LaDDL nous susurrait le 22/04/05, dans le message , les troubles mélismes suivants :
Plus d'éléments ici sur EnablePMTUDiscovery : http://www.microsoft.com/resources/documentation/Windows/2000/server/reskit/en-us/Default.asp?url=/resources/documentation/Windows/2000/server/reskit/en-us/regentry/58752.asp
Donc, si j'ai bien compris, la modife que je bien de faire sur mon win98se ne convient pas ! ...Celle que tu donnes semblant ne concerner que win2000 ? ...
Melmoth - perdu
LaDDL nous susurrait le 22/04/05, dans le message
<opspmli2pt79c1rn@d61u75e74>, les troubles mélismes suivants :
Plus d'éléments ici sur EnablePMTUDiscovery :
http://www.microsoft.com/resources/documentation/Windows/2000/server/reskit/en-us/Default.asp?url=/resources/documentation/Windows/2000/server/reskit/en-us/regentry/58752.asp
Donc, si j'ai bien compris, la modife que je bien de faire sur mon
win98se ne convient pas ! ...Celle que tu donnes semblant ne concerner
que win2000 ? ...
LaDDL nous susurrait le 22/04/05, dans le message , les troubles mélismes suivants :
Plus d'éléments ici sur EnablePMTUDiscovery : http://www.microsoft.com/resources/documentation/Windows/2000/server/reskit/en-us/Default.asp?url=/resources/documentation/Windows/2000/server/reskit/en-us/regentry/58752.asp
Donc, si j'ai bien compris, la modife que je bien de faire sur mon win98se ne convient pas ! ...Celle que tu donnes semblant ne concerner que win2000 ? ...
Melmoth - perdu
LaDDL
On 24 Apr 2005 18:39:39 GMT, MELMOTH wrote:
Plus d'éléments ici sur EnablePMTUDiscovery : http://www.microsoft.com/resources/documentation/Windows/2000/server/reskit/en-us/Default.asp?url=/resources/documentation/Windows/2000/server/reskit/en-us/regentry/58752.asp
Donc, si j'ai bien compris, la modife que je bien de faire sur mon win98se ne convient pas !
Cette vulnérabilité n'est pas considérée par MS comme critique sur les OS 98, 98se et Me. Tu peux configurer ton FW afin de bloquer tout traffic ICMP.
Maintenant rien ne t'empêche d'effectuer ces modifications dans ta BDR : - à lire en premier : http://support.microsoft.com/kb/183437/fr - puis : http://support.microsoft.com/kb/158474/fr
...Celle que tu donnes semblant ne concerner que win2000 ?
Oui. Mais rien ne t'empêche d'effectuer une recherche concernant ton OS dans la KB de MS. Plus d'infos sur la KB de MS : http://support.microsoft.com/kb/242450/fr
-- We have no control over the length of Our lives but We can control the width and depth of Our lives.
On 24 Apr 2005 18:39:39 GMT, MELMOTH <theomonk@free.fr> wrote:
Plus d'éléments ici sur EnablePMTUDiscovery :
http://www.microsoft.com/resources/documentation/Windows/2000/server/reskit/en-us/Default.asp?url=/resources/documentation/Windows/2000/server/reskit/en-us/regentry/58752.asp
Donc, si j'ai bien compris, la modife que je bien de faire sur mon
win98se ne convient pas !
Cette vulnérabilité n'est pas considérée par MS comme critique sur les OS
98, 98se et Me. Tu peux configurer ton FW afin de bloquer tout traffic
ICMP.
Maintenant rien ne t'empêche d'effectuer ces modifications dans ta BDR :
- à lire en premier : http://support.microsoft.com/kb/183437/fr
- puis : http://support.microsoft.com/kb/158474/fr
...Celle que tu donnes semblant ne concerner que win2000 ?
Oui.
Mais rien ne t'empêche d'effectuer une recherche concernant ton OS dans la
KB de MS. Plus d'infos sur la KB de MS :
http://support.microsoft.com/kb/242450/fr
--
We have no control over the length of Our lives but We can control the
width and depth of Our lives.
Plus d'éléments ici sur EnablePMTUDiscovery : http://www.microsoft.com/resources/documentation/Windows/2000/server/reskit/en-us/Default.asp?url=/resources/documentation/Windows/2000/server/reskit/en-us/regentry/58752.asp
Donc, si j'ai bien compris, la modife que je bien de faire sur mon win98se ne convient pas !
Cette vulnérabilité n'est pas considérée par MS comme critique sur les OS 98, 98se et Me. Tu peux configurer ton FW afin de bloquer tout traffic ICMP.
Maintenant rien ne t'empêche d'effectuer ces modifications dans ta BDR : - à lire en premier : http://support.microsoft.com/kb/183437/fr - puis : http://support.microsoft.com/kb/158474/fr
...Celle que tu donnes semblant ne concerner que win2000 ?
Oui. Mais rien ne t'empêche d'effectuer une recherche concernant ton OS dans la KB de MS. Plus d'infos sur la KB de MS : http://support.microsoft.com/kb/242450/fr
-- We have no control over the length of Our lives but We can control the width and depth of Our lives.
