Filtres de ports et de paquets de Windows NT
L'un des meilleurs moyens de protéger des ordinateurs mis en réseau consiste à restreindre les types de trafic réseau qu'ils reçoivent et traitent, ce qui nécessite généralement d'utiliser un filtre de paquets. Lorsqu'ils conçoivent des stratégies de filtrage des paquets, les administrateurs se concentrent surtout sur les routeurs et les goulots d'étranglement. Windows NT comporte cependant une fonction de filtrage des paquets connue sous le nom de sécurité TCP/IP. Bien que la protection fournie par cette fonction ne soit pas suffisante en soi, elle constitue une parfaite couche de défense secondaire lorsqu'elle est associée à des dispositifs dynamiques de filtrage de paquets
Le principal avantage des caractéristiques de sécurité TCP/IP intégrées à Windows NT vient de ce que des caractéristiques sont appliquées au sein de la pile TCP/IP du réseau en tant que partie intégrante des pilotes de protocole. L'intérêt de cette intégration en profondeur tient à ce que tous les paramètres sont actifs aussi longtemps que les interfaces protégées le sont. Il n'existe aucune période, comme par exemple au démarrage, pendant laquelle le trafic réseau n'est pas filtré. La sécurité TCP/IP est transparente pour les applications bien qu'elle puisse entrer en conflit avec certains logiciels de pare-feu personnels.
En dépit de son nom, la sécurité TCP/IP permet le filtrage port par port des protocoles TCP et UDP (User Datagram Protocol) et d'autres protocoles IP. Les filtres actifs bloquent le trafic entrant mais autorisent le trafic sortant et les réponses aux connexions TCP initiées par l'hôte local. Certaines limites existent cependant.
| • | Les filtres de port autorisent ou bloquent le trafic pour tous les hôtes. Il n'est pas possible d'établir un niveau de contrôle granulaire plus fin comme c'est le cas avec la fonctionnalité IP Security (IPsec) Extensions incorporée à Windows 2000, Windows XP et Microsoft Windows Server™ 2003. |
| • | Les filtres ne sont pas véritablement dynamiques et ne peuvent pas être liés de façon dynamique pour autoriser le trafic pour les connexions secondaires. Dans les versions ultérieures de Windows, l'implémentation IPsec permet d'autoriser les connexions secondaires comme le font la plupart des pare-feu matériels. |
En plus de la simple fonctionnalité de filtrage des ports qui vient d'être décrite, la pile TCP/IP de Windows NT offre de nombreux paramètres réglables particulièrement utiles pour stopper ou minimiser le trafic dangereux sur le réseau. Au fil du temps, diverses attaques ont été développées qui exploitent les failles du code de mise en réseau TCP/IP de Windows NT 4.0. Bien que ces failles aient été corrigées par des Service Packs et des mises à jour de sécurité, il peut être néanmoins utile d'appliquer ces changements pour protéger encore plus votre réseau. En général, ces réglages nécessitent la modification directe du registre à l'aide des outils regedit32 ou regedit. L'article 120642 de la Base de connaissances de Microsoft intitulé "TCP/IP and NBT Configuration Parameters for Windows 2000 or Windows NT" (Paramètres de configuration NBT et TCP/IP pour Windows 2000 ou Windows NT) disponible sur le site http://support.microsoft.com/kb/120642 fournit une liste détaillée des paramètres modifiables. Les paramètres intervenant au premier chef dans la sécurité du réseau et du système sont présentés dans les sections suivantes.
Trey Research a défini le filtrage des ports et des paquets de ses hôtes anciens de façon à interdire au trafic provenant de ports ne figurant pas dans l'article 150543 de la Base de connaissance intitulé "Windows NT, Terminal Server, and Microsoft Exchange Services Use TCP/IP Ports" (Les services Windows NT, Terminal Server et Microsoft Exchange utilisent les ports TCP/IP) disponible à l'adresse http://support.microsoft.com/kb/150543 ou utilisés par d'autres applications de son réseau de quitter le réseau interne pour gagner Internet. Ceci empêche la diffusion de tout trafic sensible provenant du réseau sur un réseau non contrôlé.
Protection contre les saturations SYN
La saturation SYN (synchronisation) est un vecteur classique d'attaque contre les services TCP. Quand un client TCP veut lancer une nouvelle connexion, il envoie des paquets TCP vides portant l'indicateur SYN indiquant qu'il demande une nouvelle connexion à un serveur d'écoute. Le serveur renvoie un paquet de réponse comportant à la fois l'indicateur SYN et l'indicateur ACK (accusé de réception). Le client répond alors par un paquet ACK, ce qui conclut le processus de connexion en trois étapes et ouvre la connexion.
Tant que l'accusé de réception final n'a pas été reçu, le pilote TCP/IP affecte le statut SYN_RCVD (SYN reçue) à cette connexion. Si, pour une raison ou une autre, Windows ne reçoit pas de réponse au paquet SYN+ACK le système patientera une seconde (valeur par défaut) avant de retransmettre le paquet SYN+ACK. Un seconde retransmission a lieu après un autre délai de trois secondes, puis une retransmission finale au bout de six autres secondes. Chaque demande de connexion oblige le serveur à allouer une certaine quantité de mémoire et d'autres structures du noyau. Un grand nombre de requêtes entrantes peut rapidement épuiser ces ressources et entraîner un déni de service. Les clés de registre concernées sont les suivantes :
HKLMSYSTEMCurrentControlSetServices
TcpipParametersSynAttackProtect (REG_DWORD) :
| • | 0 = Désactivé (valeur par défaut) |
| • | 1 = Retarder la création de l'entrée du cache de routage jusqu'à ce que la connexion soit établie |
| • | 2 = Retarder la notification au pilote Winsock jusqu'à ce que la connexion en trois étapes soit terminée (recommandé) |
HKLMSYSTEMCurrentControlSetServices
TcpipParametersTcpMaxHalfOpen (REG_DWORD) :
| • | Cette clé détermine le nombre maximum de tentatives de connexion que la pile IP autorisera à conserver l'état SYN_RCVD avant de déclencher l'état SynAttack. La valeur par défaut est 100. |
HKLMSYSTEMCurrentControlSetServicesTcpip
ParametersTCPMaxHalfOpenRetried (REG_DWORD) :
| • | Cette clé détermine le nombre maximum de connexions présentant l'état SYN_RCVD et ayant été retransmises plus d'une fois avant le déclenchement de l'état SynAttack. La valeur par défaut est 80. |
HKLMSYSTEMCurrentControlSetServicesTcpip
ParametersTCPMaxPortsExhausted (REG_DWORD) :
| • | Cette clé détermine le nombre de demandes de connexion refusées provoquées par l'absence de backlog avant le déclenchement de l'état SynAttack. La valeur par défaut est 5. |
HKLMSYSTEMCurrentControlSetServicesTcpipParameters
TCPMaxConnectResponseRetransmissions (REG_DWORD) :
| • | Cette clé précise le nombre de tentatives de retransmissions pendant l'état SYN_RCDV. La valeur par défaut est 3, ce qui permet trois retransmissions. Si cette valeur est réglée sur 1, une seule tentative de retransmission aura lieu. |
L'article 146241 de la base de connaissances intitulé "Internet Server Unavailable Because of Malicious SYN Attacks" (Indisponibilité du serveur Internet du fait d'attaques SYN) et disponible à l'adresse http://support.microsoft.com/kb/142641 explique ces paramètres plus en détail.
Sur ses anciens systèmes, Trey Research a renforcé les paramètres de toutes les clés de registre précédemment répertoriées, réduisant ainsi le risque qu'une attaque SYN ne les affecte négativement. Trey Research n'a pas utilisé les paramètres les plus restrictifs car il est véritablement nécessaire de laisser le trafic SYN normal traverser le réseau. La société ne désire pas non plus interrompre le transit du trafic réseau normal. Les administrateurs de systèmes de la société Trey sont conscients que les modifications apportées aux paramètres par défaut devront peut-être être revues et ils surveillent de façon proactive la quantité de trafic SYN sur leur réseau.
Contrôle de la taille du backlog
Les applications qui se servent de TCP/IP utilisent l'interface de programmation d'application (API) fournie par afd.sys, le pilote de mode noyau Winsock. L'API Winsock offre aux applications les mécanismes permettant d'ouvrir des connexions client et d'établir des écoutes sur les ports pour les connexions serveur. La fonction listen() permet d'indiquer à Winsock qu'il faut surveiller les tentatives de connexions à un port précis et les transférer vers l'application.
L'un des paramètres que cette fonction doit définir est la taille du backlog, file d'attente contenant les connexions entrantes mises en attente jusqu'à ce que la pile puisse les traiter. Le backlog détermine la longueur maximale de la file d'attente. Par défaut, sa valeur est égale à 200 sur Windows NT Server et à 5 sur Windows NT Workstation. Le Service Pack 2 (SP2) pour Windows NT 4.0 introduit la fonction de backlog dynamique qui permet à la pile TCP/IP d'ajuster la taille de la file d'attente du backlog pour l'adapter aux conditions actuelles du réseau.
Par défaut, la fonctionnalité d'ajustement de la file d'attente du backlog est désactivée et doit être activée à l'aide des entrées de registre suivantes. En outre, l'application appelante doit demander une file d'attente du backlog supérieure au paramètre MinimumDynamicBacklog pour bénéficier de cette fonction. Les clés de registre concernées sont les suivantes :
HKLMSYSTEMCurrentControlSetServicesAFD
ParametersEnableDynamicBacklog (REG_DWORD) :
| • | 0 = Désactivé (valeur par défaut) |
| • | 1 = Activé (recommandé) |
HKLMSYSTEMCurrentControlSetServices
AFDParametersMinimumDynamicBacklog (REG_DWORD) :
| • | Cette clé précise le nombre minimum d'entrées dans la file d'attente du backlog ; si le nombre d'entrées disponibles tombe sous ce seuil minimum, vous devez créer davantage d'entrées. La valeur recommandée est 20. |
HKLMSYSTEMCurrentControlSetServices
AFDParametersMaximumDynamicBacklog (REG_DWORD) :
| • | Cette clé précise le nombre maximum d'entrées pouvant être créées dans la file d'attente du backlog. Définir ce nombre sur une valeur supérieure à 5 000 pour une mémoire vive du système d'une taille de 32 Mo peut provoquer un épuisement de la mémoire en cas d'attaque. N'oubliez pas qu'une file d'attente de backlog individuelle est créée pour chaque service réseau. Étant donné que les serveurs cibles de Trey Research disposent d'une mémoire vive de 512 Mo, la formule utilisée pour déterminer la limite supérieure de cette valeur de registre est : |
| • | (512/32)*5000=144000. |
| • | Pour les stations de travail (qui disposent toutes de 256 Mo de mémoire vive), la valeur calculée est (256/32)*5000 = 72000. |
HKLMSYSTEMCurrentControlSetServicesAFD
ParametersDynamicBacklogGrowth-Delta (REG_DWORD) :
| • | Cette clé indique le nombre de nouvelles connexions à ajouter au backlog en une fois lorsqu'il en faut davantage. La valeur recommandée est 10. |
L'article 146241 de la base de connaissances intitulé "Internet Server Unavailable Because of Malicious SYN Attacks" (Indisponibilité du serveur Internet du fait d'attaques SYN) et disponible à l'adresse http://support.microsoft.com/kb/142641 explique ces paramètres plus en détail.
Trey Research a décidé de définir les valeurs recommandées de toutes les clés de registre précédemment répertoriées de façon à contrôler le nombre de connexions entrantes afin que les systèmes de la société ne soient pas saturés par les demandes entrantes.
Directive Keep Alive TCP
La directive Keep Alive TCP constitue une fonctionnalité TCP avancée qui maintient les connexions "longue durée" actives. Cette fonction est particulièrement importante pour les connexions qui traversent les pare-feu et les dispositifs de traduction d'adresses réseau qui suppriment régulièrement les entrées anciennes de leurs tables de connexions et d'usurpation d'identité.
Windows NT offre une fonction permettant d'activer et de définir les délais d'expiration de la directive Keep Alive TCP. Le choix d'une valeur plus basse permet d'éviter que des connexions inactives n'accaparent trop longtemps des ressources. Servez-vous des clés de registre suivantes pour définir cette valeur :
HKLMSYSTEMCurrentControlSetServices
TcpipParametersKeepAliveTime (REG_DWORD) :
| • | Cette clé indique le nombre de millisecondes entre les contrôles Keep Alive ; par défaut, cette valeur est de 7 200 000 (deux heures). |
HKLMSYSTEMCurrentControlSetServices
TcpipParametersKeepAliveInterval (REG_DWORD) :
| • | Cette clé définit le nombre de millisecondes entre les retransmissions d'un paquet Keep Alive quand aucune réponse n'a été reçue ; par défaut, cette valeur est égale à 1000 (une seconde). |
Trey Research n'a pas modifié les paramètres de sa directive Keep Alive TCP car, jusqu'à présent, elle n'a pas eu de problème avec la durée d'utilisation de ses connexions.
Recherche de l'unité maximale de transfert d'un chemin
La recherche de l'unité maximale de transfert (MTU) d'un chemin est une fonctionnalité qui permet à Windows de rechercher automatiquement la plus grande taille de paquet prise en charge entre les hôtes sur tous les segments du réseau. Elle fonctionne en envoyant des paquets volumineux comportant un bit appelé "do not fragment" (ne pas fragmenter). Lorsqu'un routeur ne peut pas relayer ce paquet car sa taille est supérieure à l'unité maximale de transfert du segment, il renvoie un message d'erreur ICMP (Internet Control Message Protocol). Windows réduit ensuite la taille du paquet et essaie à nouveau jusqu'à ce que le paquet soit acheminé jusqu'à sa destination.
En définissant une unité maximale de transfert appropriée pour les hôtes distants, Windows évite de générer des paquets fragmentés qui réduisent les performances et augmentent le risque de perte de données et de retransmissions. Les paquets fragmentés peuvent aussi être une source de risques. Les gestionnaires de paquets sont couramment à l'origine de dépassements de capacité de la mémoire tampon et une fonction de filtrage des fragments à la frontière peut fortement réduire les attaques. La recherche de l'unité maximale de transfert d'un chemin devrait être activée, mais cela implique que les messages ICMP type 3, code 4 seront routés à travers les pare-feu. Servez-vous des clés de registre suivantes pour définir cette valeur :
HKLMSYSTEMCurrentControlSetServices
TcpipParametersEnablePathMTUDiscovery (REG_DWORD) :
| • | 1 = Activé (valeur par défaut, recommandée) |
| • | 0 = Désactivé |
Une valeur égale à 0 définit une taille d'unité maximale de transfert de 576 octets pour tout le trafic à l'extérieur des sous-réseaux locaux configurés. De plus, avec ce paramètre, Windows n'honorera pas les demandes de modification de l'unité maximale de transfert.
HKLMSYSTEMCurrentControlSetServices
TcpipParametersEnablePathMTUBHDetect (REG_DWORD) :
| • | 0 = Désactivé (valeur par défaut) |
| • | 1 = Activé |
Une valeur égale à 1 permet à Windows de tenter de détecter des routeurs "trou noir" pendant la recherche de l'unité maximale de transfert d'un chemin ; ces routeurs ignorent automatiquement les paquets portant le bit indicateur "do not fragment" s'ils sont trop volumineux au lieu de renvoyer la réponse ICMP adéquate. Si cette valeur est activée, le nombre de retransmissions risque d'être plus important.
Trey Research n'a pas modifié les valeurs par défaut de la recherche de l'unité maximale de transfert d'un chemin car la désactivation de cette fonctionnalité pourrait rendre certains systèmes distants inaccessibles. Trey Research ne veut pas risquer que les transactions commerciales s'interrompent si les systèmes se trouvant sur le chemin de communication ne prennent pas en charge la réduction de la taille de l'unité maximale de transfert.
Routage source
Le routage source permet aux applications de passer outre les tables de routage et indiquent une ou plusieurs destinations intermédiaires pour les datagrammes sortants. Bien que cette capacité présente une utilité marginale en cas de dépannage, il est vivement déconseillé de l'utiliser sur des réseaux de production modernes. Des attaquants peuvent exploiter cette fonctionnalité pour diriger de façon indétectable tout le trafic réseau vers un point de collecte centralisé pour capturer les paquets. Désactivez le routage source à l'aide de la clé de registre mentionnée ci-dessous ; assurez-vous également que les routeurs de frontière sont configurés afin d'abandonner tous les datagrammes IP dont l'option de routage source est définie.
HKLMSYSTEMCurrentControlSetServices
TcpipParametersDisableIPSourceRouting (REG_DWORD) :
| • | 0 = Activé (valeur par défaut) |
| • | 1 = Désactivé lorsque le transfert IP est activé |
| • | 2 = Complètement désactivé (recommandé) |
Trey Research a désactivé le routage source sur tous les hôtes sous son contrôle pour empêcher la capture de données réseau par des attaquants.
Détection de passerelle inactive
La détection de passerelle inactive permet à Windows de remarquer les cas où une passerelle par défaut semble ne plus répondre et de basculer vers d'autres passerelles configurées par défaut. Dans la pratique, cette capacité est rarement utilisée car elle offre des opportunités d'attaques par déni de service. Servez-vous des clés de registre suivantes pour contrôler cette fonction :
HKLMSYSTEMCurrentControlSetServices
TcpipParametersEnableDeadGWDetect (REG_DWORD) :
| • | 0 = Désactivé (recommandé) |
| • | 1 = Activé (valeur par défaut) |
Trey Research a activé la détection de passerelle inactive sur tous ses hôtes afin de réduire les possibilités d'attaque par déni de service sur son réseau.
Recherche de routeur
La recherche de routeur ICMP utilise les messages de recherche de routeur ICMP pour localiser et configurer les routes et passerelles par défaut. Une fois encore, les attaquants peuvent mettre à profit cette fonctionnalité pour rediriger le trafic réseau à diverses fins, notamment pour espionner et lancer des attaques du type de l'homme au milieu. Les routeurs qui prennent cette fonctionnalité en charge doivent envoyer un message IRDP ICMP qui devrait être désactivé. En outre, le protocole DHCP doit être configuré avec l'option appropriée pour que l'interface accepte les messages IRDP.
Il convient d'éditer la clé de registre suivante pour empêcher des modifications mal intentionnées de la configuration ; si la capacité d'utiliser plusieurs routeurs est vraiment indispensable, envisagez de déployer le module RRAS complémentaire et d'utiliser un protocole de routage sécurisable.
HKLMSYSTEMCurrentControlSetServices
TcpipParametersPerformRouterDiscovery (REG_DWORD) :
| • | 0 = Désactivé (recommandé) |
| • | 1 = Activé |
Trey Research a désactivé la recherche de routeur sur tous ses hôtes afin d'empêcher des modifications non autorisées de la configuration au sein de son réseau.
Redirections ICMP
Les redirections ICMP sont une autre source de vulnérabilité potentielle car elles permettent à un expéditeur arbitraire de falsifier des paquets et de modifier les tables de routage de sa victime. Cette fonctionnalité est activée par défaut. Il est recommandé de la désactiver à l'aide de la clé suivante pour éviter toute utilisation malveillante :
HKLMSYSTEMCurrentControlSetServices
TcpipParametersEnableICMPRedirect (REG_DWORD) :
| • | 0 = Désactivé (recommandé) |
| • | 1 = Activé (valeur par défaut) |
Trey Research a désactivé les redirections ICMP sur tous ses hôtes pour protéger la table de routage de chacun d'eux.
Fermetures de port RPC
Par défaut, beaucoup de services sont à l'écoute sur les interfaces réseau, y compris sur l'interface de bouclage locale. Ainsi, le mappeur de port RPC de Microsoft est à l'écoute sur les ports TCP/135, UDP/135, TCP/1027 et TCP/1028. Trois de ces services —le client RPC, le serveur RPC et le mappeur de point final RPC— peuvent être configurés pour fermer tous les ports ouverts. Cependant ces modifications doivent être vérifiées avec soin car elles peuvent gêner certaines fonctionnalités, non seulement auprès des hôtes distants mais aussi entre les services locaux.
Microsoft Exchange et Microsoft SQL Server™ sont les applications requérant l'appel de fonction RPC le plus couramment déployées. En outre, les appels RPC servent lors de la gestion à distance des serveurs. Les utilitaires incorporés courants qui dépendent des services RPC sont les suivants :
| • | Gestionnaire DHCP |
| • | Administrateur DNS |
| • | Gestionnaire WINS |
| • | Analyseur de performances |
| • | Observateur d’événements |
| • | Éditeur du Registre |
| • | Gestionnaire de serveurs |
| • | Gestionnaire d'utilisateurs |
Pour savoir si une utilisation utilise l'appel de fonction RPC, installez l'agent et les outils de surveillance réseau de Windows NT 4.0 depuis le CD et servez-vous en pour déterminer si l'application utilise les appels RPC sur les ports précédemment cités.
Supprimez les clés de registre suivantes pour désactiver le client RPC :
HKLMSOFTWAREMicrosoftRPCClientProtocolsncacn_ip_tcp
HKLMSOFTWAREMicrosoftRPCClientProtocolsncacn_ip_udp
Supprimez les clés de registre suivantes pour désactiver le client RPC :
HKLMSOFTWAREMicrosoftRPCServerProtocolsncacn_ip_tcp
HKLMSOFTWAREMicrosoftRPCServerProtocolsncacn_ip_udp
Le mappeur de point final RPC (rpcss.exe) ouvre plusieurs ports si le serveur RPC est activé, mais il peut aussi être configuré pour rejeter les tentatives de connexion DCOM (Distributed Component Object Model) qui ne sont pas locales. Attention, toutefois : ceci aura un fort impact sur votre capacité à gérer vos systèmes à distance. L'extension du client Directory Services décrite au chapitre 4 dans la section "Renforcement de Windows NT 4.0" sera particulièrement affectée car elle dépend beaucoup des fournisseurs WMI (Windows Management Instrumentation) qui sont des objets DCOM. Vous pouvez désactiver les connexions DCOM qui ne sont pas locales à l'aide des clés de registre suivantes :
HKLMSOFTWAREMicrosoftOLEEnableDCOM (REG_SZ) :
| • | Paramétrez la valeur sur "N " pour désactiver les connexions DCOM distantes. |
Trey Research n'a pas modifié les ports de ses hôtes internes car ces ports doivent demeurer actifs pour permettre l'utilisation de nombreux services réseau. De plus, la fermeture des hôtes RPC rendrait plusieurs applications inaccessibles aux utilisateurs.
Implémentation
Conditions requises
Pour que ces implémentations prennent correctement effet, vous devez avoir implémenté l'infrastructure de base de Trey Research telle qu'elle a été décrite au chapitre 2 intitulé "Application d'une discipline de gestion du risque de sécurité au scénario Trey Research".
Présentation
Pour implémenter ce scénario de solution, il convient de réaliser les opérations suivantes :
| • | Configurer le filtrage de port natif de Windows NT 4.0. |
| • | Configurer les paramètres de réglage IP de Windows NT 4.0. |
Pour la plupart de ces paramètres, les fichiers de registre sont présentés dans la section Outils et modèles de ce guide.
Configuration du filtrage de port natif de Windows NT 4.0
Avant d'activer le filtrage de port TCP/IP sur vos serveurs Windows NT, vous devez savoir avec exactitude quel trafic est indispensable au fon fonctionnement de ce serveur dans son rôle précis. Microsoft fournit une liste de base des ports connus qu'utilise Windows NT 4.0, laquelle est disponible sous le titre "Port Reference for MS TCP/IP" (Référence des ports affectés au TCP/IP par MS) à l'adresse http://www.microsoft.com/technet/prodtechnol
/winntas/support/port_nts.mspx.
Pour les autres applications, consultez la documentation qui devrait les accompagner. En ce qui concerne les systèmes Windows Server, vous pouvez consulter l'article 832017 de la Base de connaissances intitulé "Port Requirements for the Microsoft Windows Server System" (Configuration des ports pour le système serveur Microsoft Windows) à l'adresse http://support.microsoft.com/kb/832017. Pour d'autres applications qui ne figurent pas dans ces listes, consultez la documentation de l'application remise par le fournisseur ou utilisez un outil de surveillance du trafic réseau tel que Netmon.exe (qui est un composant de Windows NT 4.0), Netstat (un utilitaire incorporé à Windows NT qui indique quels ports sont en cours d'utilisation) ou TCPView (un outil gratuit disponible auprès de Sysinternals à l'adresse www.sysinternals.com) pour vérifier quels ports sont utilisés par l'application.
La configuration du filtrage de ports de Windows NT est un processus simple qui s'effectue comme indiqué ci-dessous.
Pour configurer le filtrage de port natif de Windows NT
1. | Pour ouvrir le Panneau de configuration réseau, cliquez sur Démarrer, sélectionnez Paramètres, cliquez sur Panneau de configuration et cliquez deux fois sur Réseau. |
2. | Sur l'onglet Protocoles, sélectionnez l'onglet Protocole TCP/IP puis cliquez sur Propriétés. |
3. | Sur l'onglet Adresse IP, cliquez sur Avancé. |
4. | Dans la boîte de dialogue Adressage IP avancé, cochez la case Activer la sécurité. |
5. | Cliquez sur Configurer. |
6. | Dans la boîte de dialogue Sécurité TCP/IP, sélectionnez l'adaptateur adéquat (s'il s'agit d'un serveur multi-résident). |
7. | Par défaut, aucun filtre n'est défini et tout le trafic TCP, UDP et IP est autorisé (voir la Figure 3.1). Pour activer les filtres, cochez la case Autoriser seulement du protocole TCP, UDP ou IP et ajoutez les numéros de port et de protocole sur lesquels vous voulez autoriser le trafic. Veillez à permettre l'exécution des services d'infrastructure de base. |
Configuration des paramètres de réglage IP de Windows NT 4.0
Configurer les paramètres de réglage IP de Windows NT IP consiste à modifier les paramètres de registre suivants.
Attention : une modification des paramètres servant à régler la pile TCP/IP change la façon dont le sous-système réseau communique avec les routeurs, les commutateurs et les autres ordinateurs du réseau. Ces modifications peuvent affecter les performances ou la stabilité des applications de production. Avant d'effectuer une quelconque modification de l'environnement de production, vous devriez tester avec soin les modifications proposées dans un environnement de laboratoire reproduisant le comportement et la configuration de vos serveurs et clients de production.
Pour configurer les paramètres de réglage IP pour serveur de Windows NT
1. | Exécutez l’Éditeur de Registre (Regedt32.exe). | ||||||||||||||||||||||||||
2. | Vérifiez que les entrées de registres suivantes (TCP_Params.reg) sont appliquées à la clé HKLMSYSTEMCurrentControlSetServicesTcpipParameters :
| ||||||||||||||||||||||||||
3. | Vérifiez que les entrées de registre suivantes (AFD_Params.reg) sont appliquées à la clé HKLMSYSTEMCurrentControlSetServicesAFDParameters :
| ||||||||||||||||||||||||||
4. | Vérifiez que les entrées de registre suivantes (DisableDCOM.reg) sont appliquées à la clé HKLMSOFTWAREMicrosoftOLE :
| ||||||||||||||||||||||||||
5. | Si vous êtes certain qu'aucun service, application ou utilitaire non basé sur RPC n'est en cours d'utilisation, supprimez les sous-clés suivantes :
| ||||||||||||||||||||||||||
6. | Quittez l'Éditeur de registre. |
Pour configurer les paramètres de réglage IP pour station de travail de Windows NT
1. | Exécutez l’Éditeur de Registre (Regedt32.exe). | ||||||||||||||||||||||||||
2. | Vérifiez que les entrées de registre suivantes (NT4WS_TCP_Params.reg) sont appliquées à la clé HKLMSYSTEMCurrentControlSetServicesTcpipParameters :
| ||||||||||||||||||||||||||
3. | Vérifiez que les entrées de registre suivantes (NT4WS_AFD_Params.reg) sont appliquées à la clé HKLMSYSTEMCurrentControlSetServicesAFDParameters :
| ||||||||||||||||||||||||||
4. | Quittez l'Éditeur de registre. |
Résumé
La mise en application du concept d'un réseau de périmètre est un moyen efficace de sécuriser des systèmes anciens. Il offre une protection supplémentaire intégrée à la conception et à la configuration d'ensemble de tout le réseau. Ces goulots d'étranglement naturels, associés au contrôle du trafic fourni par les logiciels de pare-feu personnels et les fonctionnalités de réglage IP et de filtrage natif des ports de Windows NT 4.0 vous offrent plusieurs couches de protection qui consolident les méthodes de renforcement spécifiques présentées dans les prochains chapitres de ce guide.
Pour plus d'informations, cliquer ci-dessous: