La version du Pare-feu de connexion Internet introduite avec Windows XP filtrait uniquement le trafic IPv4. Le Pare-feu de connexion Internet IPv6 a été introduit avec Advanced Networking Pack pour Windows XP. Avec Windows Server 2003 Service Pack 1, le Pare-feu de connexion Internet et le Pare-feu de connexion Internet IPv6 sont intégrés dans un même composant appelé Pare-feu Windows.

Du fait de cette modification, tout changement de configuration s'applique à la fois au trafic IPv4 et au trafic IPv6. Par exemple, si un port statique est ouvert, il est ouvert à la fois au trafic IPv4 et au trafic IPv6.

Cette modification facilite la gestion de la configuration et la compatibilité des applications.

Le service Pare-feu de connexion Internet est supprimé du système et remplacé par le service Pare-feu Windows, qui filtre à la fois le trafic IPv4 et le trafic IPv6. Toutes les interfaces API de pare-feu sont remplacées par les nouvelles interfaces API fournies avec Windows Server 2003 Service Pack 1.

Pour plus d'informations, voir la section « Dois-je modifier mon code pour utiliser Windows Server 2003 Service Pack 1 ? », plus loin dans ce document.

Le Pare-feu Windows est activé par défaut seulement lors des nouvelles installations de Windows Server 2003 qui contiennent un Service Pack (également appelées versions intégrées). Le Pare-feu Windows fournit une protection réseau pendant que les utilisateurs mettent à jour leur système avec les derniers correctifs à l'aide de la fonction de mise à jour de sécurité après installation. Dès que les mises à jour sont terminées, le pare-feu est désactivé s'il n'a pas été explicitement activé.

Si un serveur exécutant Windows Server 2003 est mis à jour ou mis à niveau vers le Service Pack 1, le pare-feu est désactivé par défaut et la fonction des mises à jour de sécurité après installation n'est pas utilisée.

En activant par défaut le Pare-feu Windows lors de nouvelles installations, les ordinateurs bénéficient d'une meilleure protection contre les nombreuses attaques qui se servent du réseau pendant leur configuration. Par exemple, si le Pare-feu Windows avait été activé par défaut, l'impact de l'attaque par le virus MSBlaster aurait été considérablement amoindri, que les utilisateurs aient installé ou non les mises à jour appropriées.

Après la nouvelle installation d'une version intégrée de Windows Server 2003 Service Pack 1, le Pare-feu Windows est activé par défaut et le trafic entrant est bloqué jusqu'à ce que les Mises à jour de sécurité post-installation soient terminées. Cela peut créer des conflits avec les applications ou les services qui n'utilisent pas le filtrage avec état par défaut.

Exécutez les Mises à jour de sécurité post-installation, qui vont automatiquement désactiver le pare-feu, avant de réaliser d'autres tâches de configuration de serveur.

Il est également possible de configurer le pare-feu pour qu'il fonctionne avec les applications et les services que vous devez utiliser si vous ne voulez pas exécuter immédiatement les mises à jour de sécurité après installation.

La méthode conseillée pour l'activation du Pare-feu Windows et sa configuration initiale pour Windows Server 2003 Service Pack 1 consiste à utiliser l'Assistant Configuration de la sécurité (SCW, Security Configuration Wizard). Cet Assistant active automatiquement le Pare-feu Windows et crée les paramètres appropriés en fonction des impératifs de votre serveur. Pour plus d'informations sur l'Assistant Configuration de la sécurité, voir la section « Assistant Configuration de la sécurité » dans ce document.

Certains composants et applications serveur ne doivent pas être utilisés avec le Pare-feu Windows ou doivent être utilisés dans des configurations très spécifiques. L'Assistant Configuration de la sécurité a été conçu pour vous aider à déterminer les paramètres recommandés du Pare-feu en fonction de votre environnement.

Dans les précédentes versions de Windows, un intervalle de temps s'écoulait entre le démarrage de la pile réseau et la mise en place de la protection du pare-feu de connexion Internet. Par conséquent, un paquet pouvait être reçu et livré à un service sans être filtré par le pare-feu, exposant ainsi l'ordinateur à des vulnérabilités. Cela était dû au fait que le pilote du pare-feu commençait le filtrage uniquement lorsque le service en mode utilisateur du pare-feu était chargé et avait appliqué les paramètres de stratégie appropriés. Or, le service du pare-feu comporte plusieurs dépendances qui doivent être résolues avant que le service ne transmette la stratégie au pilote. La durée de cet intervalle de temps dépend de la vitesse de l'ordinateur.

Dans Windows Server 2003 Service Pack 1, les pilotes des pare-feu IPv4 et IPv6 effectuent le filtrage avec état selon une règle statique. Cette règle statique est appelée stratégie de démarrage. Elle permet à l'ordinateur d’effectuer des fonctions réseau de base telles que DNS et DHCP, et de communiquer avec un contrôleur de domaine pour obtenir les paramètres de la stratégie. Une fois le service Pare-feu Windows exécuté, il charge et applique les paramètres de la stratégie au moment de l'exécution. Il n'est pas possible de configurer la stratégie de démarrage.

La sécurité au démarrage n'est pas appliquée si le service Pare-feu Windows (qui est répertorié sous le nom Pare-feu Windows/Partage de connexion Internet dans le Gestionnaire de contrôle des services) est défini sur Manuel ou Désactivé.

Grâce à cette modification, l'ordinateur est moins exposé aux attaques lors des processus de démarrage et d'arrêt.

Si le service du Pare-feu Windows ne démarre pas, la sécurité au démarrage est toujours mise en œuvre. Ce qui signifie que toutes les connexions entrantes sont bloquées. Dans ce cas, l'administrateur ne peut pas dépanner les ordinateurs à distance, car tous les ports sont fermés, y compris le port utilisé par le Bureau à distance.

Si un service tente de démarrer avant le service de pare-feu, une « condition race » peut en résulter. Si un service nécessaire est bloqué par cette condition, vous devrez désactiver le Pare-feu Windows.

Pour désactiver la sécurité au démarrage, arrêtez le service Pare-feu Windows/Partage de connexion Internet et définissez son type de démarrage sur Manuel ou Désactivé.

Si l'ordinateur est en mode de sécurité au démarrage parce que le service du pare-feu n'a pas démarré, l'administrateur doit se connecter à l'ordinateur, trouver la raison de l'échec du démarrage du pare-feu, puis démarrer manuellement le service du pare-feu.

Lorsque le serveur est démarré en mode sans échec, l'état du pare-feu est conservé.

Votre ordinateur est moins vulnérable aux attaques lors du démarrage en mode sans échec avec connectivité réseau.

Dans les précédentes versions, le pare-feu de connexion Internet n'était pas disponible lors de l'exécution en mode sans échec.

Dans les précédentes versions de Windows, le pare-feu de connexion Internet était configuré en fonction de l'interface. Ainsi, chaque connexion réseau possédait son propre jeu de paramètres de pare-feu, par exemple un jeu de paramètres pour les connexions sans fil et un autre jeu de paramètres pour les connexions Ethernet. Cela rendait difficile la synchronisation des paramètres de pare-feu entre les connexions. De plus, les changements de configuration dont faisaient l'objet les connexions existantes n'étaient pas appliqués aux nouvelles connexions. Les connexions réseau non standard, telles que celles créées par les numéroteurs propriétaires (par exemple, les connexions d'accès réseau à distance configurées par les fournisseurs de services Internet) ne pouvaient pas être protégées.

Avec la configuration globale dans le Pare-feu Windows, tout changement de configuration est automatiquement appliqué à toutes les connexions réseau figurant dans le dossier Connexions réseau, ainsi qu'aux connexions configurées par des numéroteurs non Microsoft. La configuration est également appliquée aux nouvelles connexions créées. Le Pare-feu Windows peut encore être configuré en fonction des interfaces. En effet, la configuration globale concerne uniquement les connexions réseau non standard. Les changements de configuration sont également appliqués aux connexions IPv4 et IPv6.

Une configuration globale permet aux utilisateurs de gérer facilement leur stratégie de pare-feu sur toutes les connexions réseau et rend possible la configuration via la stratégie de groupe. Cela permet également de faire fonctionner des applications sur n'importe quelle interface à l'aide d'une seule option de configuration.

Dans les précédentes versions de Windows Server, le pare-feu était configuré en fonction de l'interface. Dans Windows Server 2003 Service Pack 1, la configuration s'effectue de manière globale et est appliquée aux connexions IPv4 et IPv6.

Si votre application ou service nécessite des ouvertures statiques pour fonctionner, ouvrez les ports de manière globale en suivant les indications fournies plus loin, dans « Dois-je modifier mon code pour utiliser Windows Server 2003 Service Pack 1 ? ».

L'enregistrement d'audit permet de suivre les modifications apportées aux paramètres du Pare-feu Windows et de voir les applications et les services qui ont demandé à votre ordinateur d'écouter un port. Une fois l'enregistrement d'audit activé, les événements d'audit sont consignés dans le journal des événements de sécurité. L'enregistrement d'audit peut être activé sur les ordinateurs clients exécutant Windows XP Service Pack 2 et les serveurs exécutant Windows Server 2003 Service Pack 1. Vous pouvez suivre la procédure ci-dessous pour permettre l'enregistrement d'audit sur votre ordinateur.

1. Ouvrez une session à l'aide d'un compte d'administrateur local.

2. Cliquez sur Démarrer, sur Panneau de configuration, puis sur Outils d'administration.

3. Dans Outils d'administration, double-cliquez sur Stratégie de sécurité locale pour ouvrir la console Paramètres de sécurité locaux.

4. Dans l'arborescence de la console Paramètres de sécurité locaux, cliquez sur Stratégies locales, puis sur Stratégie d'audit.

5. Dans le volet d'informations de la console Paramètres de sécurité locaux, double-cliquez sur Auditer les modifications de stratégie. Sélectionnez Réussite et Échec, puis cliquez sur OK.

6. Dans le volet d'informations de la console Paramètres de sécurité locaux, double-cliquez sur Auditer le suivi des processus. Sélectionnez Réussite et Échec, puis cliquez sur OK.

Vous pouvez également activer l'enregistrement d'audit pour plusieurs ordinateurs d'un domaine de service d'annuaire Active Directory à l'aide de la stratégie de groupe. Pour ce faire, modifiez les paramètres Auditer les modifications de stratégie et Auditer le suivi des processus dans Configuration ordinateur\Paramètres Windows\Paramètres de sécurité\Stratégies locales\Stratégie d'audit des objets de stratégie de groupe présents dans les conteneurs système du domaine approprié.

Une fois l'enregistrement d'audit activé, vous pouvez utiliser le composant logiciel enfichable Observateur d'événements pour afficher les événements d'audit dans le journal des événements de sécurité.

Le Pare-feu Windows utilise les identificateurs d'événement suivants :

• 848 - Affiche la configuration de démarrage du Pare-feu Windows.
  
• 849 - Affiche une configuration des exceptions d'application.
  
• 850 - Affiche une configuration des exceptions de port.
  
• 851 - Affiche une modification apportée à la liste des exceptions d'application.
  
• 852 - Affiche une modification apportée à la liste des exceptions de port.
  
• 853 - Affiche une modification apportée au mode de fonctionnement du Pare-feu Windows.
  
• 854 - Affiche une modification apportée aux paramètres de journalisation du Pare-feu Windows.
  
• 855 - Affiche une modification apportée aux paramètres ICMP.
  
• 856 - Affiche une modification apportée au paramètre Empêcher les réponses monodiffusion pour des requêtes multidiffusion ou diffusion.
  
• 857 - Affiche une modification apportée au paramètre Administration à distance.
  
• 858 - Affiche l'application des paramètres de la stratégie de groupe du Pare-feu Windows.
  
• 859 - Affiche la suppression des paramètres de la stratégie de groupe du Pare-feu Windows.
  
• 860 - Affiche une modification apportée à un autre profil.
  
• 861 - Affiche une application tentant d'écouter le trafic entrant.
  

L'audit de l'activité du Pare-feu Windows fait partie d'une stratégie défensive approfondie, car il peut être utilisé pour vous alerter lorsqu'un logiciel malveillant tente de modifier les paramètres du pare-feu. En outre, l'audit aide souvent les administrateurs à déterminer les besoins réseau de leurs applications et à mettre en œuvre une stratégie appropriée pour les déployer vers un grand nombre d'utilisateurs.

Le Pare-feu de connexion Internet autorisait le trafic pour les exceptions à entrer via n'importe quelle adresse IPv4. Avec le Pare-feu Windows de Windows Server 2003 Service Pack 1, vous pouvez également configurer une exception pour autoriser uniquement le trafic provenant d'adresses directement accessibles en sélectionnant l'option d'étendue Uniquement mon réseau (ou sous-réseau) (en fonction des entrées figurant dans la table de routage IPv4 et IPv6), ou provenant de plages d'adresses IPv4 spécifiques en sélectionnant l'option d'étendue Liste personnalisée.

Pour les ordinateurs d'un groupe de travail, certaines exceptions sont limitées par défaut à des adresses accessibles localement. Ces exceptions sont celles requises pour le partage de fichiers et d'imprimantes, ainsi que pour la structure UPnP. De plus, lorsque ces exceptions sont ouvertes pour des adresses accessibles localement sur un hôte de partage de connexion Internet, elles ne seront pas ouvertes sur l'interface publique du partage de connexion Internet. Si vous activez ces exceptions pour toutes les adresses possibles, elles seront ouvertes sur l'interface publique du partage de connexion Internet, ce qui n'est pas conseillé. Lorsque l'exception intégrée de partage de fichiers et d'imprimantes est activée avec l'interface API NetShare, les demandes entrantes de connexion de partage de fichiers et d'imprimantes, effectuées par l'Assistant Configuration du réseau ou via l'interface utilisateur du Pare-feu Windows, peuvent par défaut provenir uniquement d'adresses accessibles directement.

Si vous activez le Pare-feu Windows sur un serveur déjà configuré pour le partage de fichiers et d'imprimantes, il se peut que l'exception correspondante soit activée automatiquement. Il est recommandé d'appliquer la restriction aux adresses accessibles localement à toute exception utilisée pour communiquer sur le réseau local. Cela peut être fait par programme dans la ligne de commande de l'application d'assistance Netsh du Pare-feu Windows ou en cliquant sur Pare-feu Windows dans le Panneau de configuration.

Remarques

Il est conseillé d'identifier les étendues personnalisées avec des adresses ou des sous-réseaux spécifiques pour les exceptions que vous définissez pour le Pare-feu Windows. Lorsque vous configurez et activez une exception, vous demandez au Pare-feu Windows d'autoriser le trafic entrant non sollicité spécifique envoyé de l'étendue spécifiée (une adresse quelconque, une adresse accessible directement ou une liste personnalisée). Pour n'importe quelle étendue, l'activation d'une exception rend l'ordinateur vulnérable aux attaques basées sur le trafic entrant non sollicité provenant d'ordinateurs auxquels les adresses autorisées sont affectées et d'ordinateurs malintentionnés usurpant le trafic. Il n'y a aucun moyen d'éviter les attaques d'usurpation provenant d'Internet des adresses IPv4 publiques affectées aux connexions, à moins de désactiver l'exception. Par conséquent, efforcez-vous de configurer les options d'étendue de sorte que le nombre d'ordinateurs autorisés à envoyer du trafic non sollicité par le biais d'une exception soit le plus faible possible. Vous réduirez ainsi, sans les éliminer toutefois, les risques d'attaque d'usurpation. Si la stratégie de sécurité de votre organisation vous impose de garantir que personne en dehors de votre réseau ne peut accéder à une ressource, vous devez envisager d'employer une approche comme IPsec, qui prend en charge l'authentification d'homologue au niveau du réseau, l'authentification de l'origine des données, l'intégrité des données, la confidentialité des données (cryptage) et la protection contre la relecture.

Certaines applications doivent communiquer uniquement avec d'autres ordinateurs sur le réseau local et non pas avec des ordinateurs sur Internet. Le fait de configurer le Pare-feu Windows afin d'autoriser uniquement le trafic provenant d'adresses accessibles localement ou de plages d'adresses spécifiques correspondant à des sous-réseaux connectés localement a pour effet de limiter le jeu d'adresses à partir desquelles le trafic entrant non sollicité peut être accepté. Ceci permet de limiter, mais pas d'éliminer les attaques liées à des exceptions activées.

Lorsque l'exception intégrée de partage de fichiers et d'imprimantes ou d'infrastructure UPnP est activée à l'aide du Panneau de configuration sur un ordinateur membre d'un groupe de travail, l'étendue des adresses accessibles localement est appliquée aux ports ouverts. Si une application ou un service utilise également ces ports, cette application ou ce service pourra communiquer uniquement avec d'autres nœuds auxquels des adresses accessibles localement sont affectées. Si l'ordinateur est membre d'un domaine, l'étendue globale est toutefois appliquée.

Si ces exceptions sont activées à l'aide d'un appel d'API ou de Netsh.exe plutôt que dans le Panneau de configuration, les paramètres d'étendue par défaut sont les adresses accessibles localement, que l'ordinateur soit ou non un membre d'un groupe de travail ou d'un domaine.

Si votre application ou votre service ne peut pas fonctionner avec ce type de restriction, ouvrez le port pour n'importe quel ordinateur en suivant les indications fournies dans la section « Dois-je modifier mon code pour utiliser Windows Server 2003 Service Pack 1 ? », ci-après.

L'application d'assistance Netsh du Pare-feu Windows a été ajoutée à Windows XP dans le module Advanced Networking Pack. Cette application concernait uniquement le Pare-feu Windows IPv6. Avec Windows Server 2003 Service Pack 1, la structure et la syntaxe de l'application d'assistance ont été modifiées et étendues pour permettre de configurer également le Pare-feu Windows IPv4. Avec l'application d'assistance Netsh, vous pouvez entièrement configurer le Pare-feu Windows, notamment :

• configurer l'état par défaut du Pare-feu Windows (Désactivé, Activé, Activé sans exceptions) ;
  
• configurer les ports qui doivent être ouverts ;
  
• configurer les ports pour activer l'accès global ou pour restreindre l'accès au sous-réseau local ;
  
• définir les ports devant être ouverts sur toutes les interfaces ou sur une interface spécifique seulement ;
  
• configurer les options de journalisation ;
  
• configurer les options ICMP (Internet Control Message Protocol) ;
  
• configurer et activer des exceptions basées sur des programmes.
  

Les informations de configuration et d'état du Pare-feu Windows peuvent être extraites à partir de la ligne de commande à l'aide de Netsh.execontext: firewall.

Pour utiliser ce contexte, tapez netsh firewall à une invite de commande, puis utilisez d'autres commandes Netsh selon vos besoins.

Les commandes suivantes sont utiles pour recueillir des informations de configuration et d'état de votre pare-feu et, le cas échéant, pour résoudre ses problèmes de fonctionnement :

• Netsh firewall show state
  
• Netsh firewall show config
  

Les commandes suivantes permettent de modifier la configuration du Pare-feu Windows.

Le tableau suivant décrit en détail les commandes show prises en charge pour le Pare-feu Windows.

Vous pouvez comparer le résultat de ces commandes au résultat de la commande netstat –ano afin d'identifier les programmes qui peuvent avoir des ports d'écoute ouverts et qui n'ont pas les exceptions correspondantes dans la configuration du pare-feu.

L'interface de ligne de commande permet aux administrateurs de configurer le Pare-feu Windows sans passer par l'interface utilisateur graphique. L'interface de ligne de commande peut être utilisée pour les scripts d'ouverture de session et la gestion à distance.

Tout script créé avec l'application d'assistance Netsh fournie dans le module Advanced Networking Pack pour Windows XP ne fonctionne plus et doit être mis à jour.

Mettez à jour vos scripts pour qu'ils prennent en compte le nouveau contexte et la nouvelle syntaxe du pare-feu.

Le Pare-feu Windows peut être configuré de façon à autoriser du trafic entrant non sollicité spécifique. Cela s'avère nécessaire notamment lorsque des scénarios clés, comme le partage des fichiers et des imprimantes, doivent être activés. Si un problème de sécurité est découvert dans des services ou des applications d'écoute exécutés sur l'ordinateur, il est possible que ce dernier doive passer en mode client uniquement, c'est-à-dire en mode « Activé sans exceptions ». Lorsque l'ordinateur passe en mode client uniquement, le Pare-feu Windows empêche automatiquement tout trafic entrant non sollicité sans qu'il soit nécessaire de reconfigurer le pare-feu.

Lorsque ce mode est activé, toutes les exceptions sont temporairement désactivées et toute connexion existante est interrompue. Tout appel d'une interface API émis vers le Pare-feu Windows pour créer une exception est autorisé et la configuration de pare-feu demandée est stockée, mais elle n'est pas activée tant que le mode de fonctionnement normal n'est pas de nouveau activé. Toutes les demandes d'écoute émises par les applications sont également ignorées et les boîtes de notification ne sont pas affichées, empêchant ainsi l'application d'écouter un port pendant que l'ordinateur est dans ce mode.

Lorsqu'un système en réseau est attaqué par des virus, des vers ou d'autres attaquants, ceux-ci recherchent des services à exploiter. Le mode de fonctionnement « Sans exceptions » vous offre un moyen de verrouiller rapidement votre système en cas d'attaque, sans que des exceptions valides puissent être utilisées pour contourner la protection de votre ordinateur par le Pare-feu Windows.

Lorsque ce mode est activé, l'ordinateur ne peut pas écouter les requêtes provenant du réseau. Toute connexion entrante existante est interrompue. Seules les connexions sortantes sont encore possibles.

Lorsque ce mode est activé, il est normal que certaines fonctionnalités échouent du fait de la sécurité réseau particulièrement stricte qui est mise en place. Vous pouvez rétablir ces fonctionnalités en définissant le mode de fonctionnement sur Activé. L'utilisateur doit effectuer cette action uniquement lorsque la menace a été identifiée et atténuée, dans la mesure où cela contribue à amoindrir considérablement la sécurité de l'ordinateur.

Certains programmes (applications ou services) jouent à la fois un rôle de serveur et de client réseau. Lorsqu'un programme joue le rôle de serveur, il doit autoriser le trafic entrant non sollicité, étant donné qu'il ne sait pas à l'avance qui sera le client.

Dans les versions antérieures de Windows, un programme devait appeler les interfaces API du pare-feu pour permettre l'ouverture des ports d'écoute requis. Cela était particulièrement difficile dans les situations de type homologue à homologue où le port n'était pas connu à l'avance. Le programme devait ensuite refermer le port une fois la communication terminée. Si le programme se terminait de façon inattendue, des ports inutiles étaient ouverts dans le pare-feu.

La méthode précédente présentait également un autre inconvénient ; en effet, ces ports ne pouvaient être ouverts que si les programmes étaient exécutés dans le contexte de sécurité d'un administrateur local et non pas avec les privilèges minimaux requis (principe de sécurité de base), ce qui violait le principe des moindres privilèges.

Dans Windows Server 2003 Service Pack 1, il est possible d'ajouter à la liste des exceptions du Pare-feu Windows un programme qui doit écouter le réseau. Lorsqu'un programme est activé dans cette liste, le Pare-feu Windows ouvre et ferme automatiquement les ports d'écoute requis, quel que soit le contexte de sécurité du programme. Pour plus d'informations sur l'ajout de programmes à la liste des exceptions du Pare-feu Windows, voir la section « Comment contourner ces problèmes ? », plus loin dans ce document

Il n'est pas nécessaire de placer dans la liste des exceptions les programmes qui utilisent le filtrage avec état. Seuls les administrateurs peuvent ajouter un programme à la liste des exceptions du Pare-feu Windows.

Lorsqu'un programme figure dans la liste des exceptions du Pare-feu Windows, seuls les ports requis sont ouverts, et uniquement pendant l'intervalle de temps où le programme écoute sur ces ports.

Pour qu'un programme puisse écouter le réseau, il doit être activé dans la liste des exceptions du Pare-feu Windows. Sinon, le port requis n'est pas ouvert dans le Pare-feu Windows et le programme ne peut pas recevoir de trafic entrant non sollicité.

Il est possible de placer un programme dans la liste des exceptions du Pare-feu Windows de cinq manières :

1. Par programme. Il est recommandé aux éditeurs de logiciels de placer leurs programmes dans la liste des exceptions du Pare-feu Windows au cours de l'installation. Pour plus d'informations sur la façon d'ajouter par programmation un programme à la liste des exceptions, voir « Dois-je modifier mon code pour utiliser Windows Server 2003 Service Pack 1 ? », plus loin dans cette section.
   
2. Interface de ligne de commande. Cette méthode peut être utilisée par des administrateurs qui gèrent des systèmes Windows XP et Windows Server 2003 à l'aide de scripts ou d'autres outils de ligne de commande.
   
3. Paramètres de stratégie de groupe. Les administrateurs peuvent utiliser cette méthode pour ajouter un programme à la liste des exceptions via la stratégie de groupe.
   
4. Message de notification du Pare-feu Windows. Un utilisateur possédant des droits d'administrateur peut interagir avec le message de notification du Pare-feu Windows et ajouter l'application à la liste des exceptions.
   Lorsqu'une application effectue une opération d'écoute TCP ou une liaison UDP sur un port non générique, la pile du réseau transmet le nom de l'application et le port au Pare-feu Windows. Le pare-feu recherche alors le nom de l'application dans la liste des exceptions. Si elle y figure et qu'elle est activée, le port correspondant est ouvert dans le pare-feu. Si elle y figure mais qu'elle n'est pas activée, alors le port correspondant n'est pas ouvert dans le pare-feu. Si elle ne figure pas dans la liste des exceptions, il est demandé aux utilisateurs de faire un choix. S'ils possèdent des droits d'administrateur, ils peuvent :
   
   • débloquer l'application afin de l'autoriser à écouter le réseau. Elle est alors ajoutée à la liste des exceptions comme application activée et le port est ouvert ;
     
   • empêcher l'application d'écouter le réseau. Elle est alors ajoutée à la liste des exceptions comme application désactivée et le port n'est pas ouvert ;
     
   • demander que la question leur soit de nouveau posée ultérieurement. L'application est alors ajoutée à la liste des exceptions et le port n'est pas ouvert.
     
   Si l'utilisateur ne possède pas de droits d'administrateur, il est informé que l'application n'est pas autorisée à écouter le réseau et qu'un administrateur doit activer l'exception de programme. Si l'utilisateur active la case à cocher Ne pas me le demander, l'application est répertoriée dans la liste des exceptions comme étant désactivée.
   

   Remarques
   Les messages de notification sont utilisables uniquement avec les applications. Ils ne peuvent pas être utilisés avec les services.

5. Configuration manuelle. Les administrateurs peuvent activer un programme manuellement dans le Panneau de configuration du Pare-feu Windows, soit en le sélectionnant dans une liste générée à partir de la liste des programmes du menu Démarrer, soit en le recherchant directement dans le système.
   

La prise en charge de plusieurs profils dans le Pare-feu Windows vous permet de créer deux paramètres de stratégie de pare-feu : une pour les cas où l'ordinateur est connecté au réseau de l'entreprise, et une autre pour les cas où il ne l'est pas. Vous pouvez définir des paramètres moins stricts pour les cas où l'ordinateur est connecté au réseau de l'entreprise afin de permettre aux applications sectorielles de fonctionner. Vous pouvez également définir des paramètres de stratégie de sécurité plus agressifs pour les cas où l'ordinateur quitte le réseau d'entreprise, afin de protéger les utilisateurs itinérants.

Remarques
La prise en charge de plusieurs profils dans le Pare-feu Windows concerne uniquement les ordinateurs qui appartiennent à un domaine Active Directory. Les ordinateurs d'un groupe de travail utilisent un seul profil.

Il est préférable qu'un ordinateur mobile possède plusieurs configurations de pare-feu. Très souvent, une configuration sécurisée sur un réseau d'entreprise est susceptible d'être attaquée sur le réseau Internet. C'est pourquoi il est indispensable de pouvoir disposer de ports ouverts sur le réseau de l'entreprise mais pas sur d'autres réseaux : à tout moment, seuls les ports requis sont ainsi exposés.

Si une application doit être répertoriée dans la liste des exceptions du Pare-feu Windows pour fonctionner correctement, il est possible qu'elle ne fonctionne pas sur les deux réseaux, car les deux profils peuvent ne pas utiliser le même jeu de paramètres de stratégie. Pour qu'une application fonctionne sur tous les réseaux, elle doit être répertoriée dans les deux profils. Pour plus d'informations sur la liste des exceptions du Pare-feu Windows, voir la section précédente.

Si l'ordinateur appartient à un domaine, vous devez vous assurer que l'application est répertoriée dans les deux configurations du pare-feu. Envisagez la création des exceptions à l'aide de l'interface de la ligne de commande ou de la stratégie de groupe, puisque vous pouvez accéder au profil en cours d'exécution seulement via Pare-feu Windows dans le Panneau de configuration.

Dans les versions antérieures de Windows, le Pare-feu de connexion Internet bloquait les communications RPC (Remote Procedure Call). Ce pare-feu pouvait être configuré pour autoriser le trafic réseau vers le mappeur des points de terminaison RPC, mais le port utilisé par un serveur RPC était inconnu et l'application ne fonctionnait pas.

Un grand nombre de composants et d'applications d'entreprise ne fonctionnent pas si RPC n'est pas autorisé à communiquer via le réseau. Vous trouverez ci-après quelques exemples :

• l'administration à distance, telle que la fonction Gestion de l'ordinateur et la boîte de dialogue Sélectionner les utilisateurs, les ordinateurs ou les groupes, qui est utilisée par un grand nombre d'applications ;
  
• la configuration WMI (Windows Management Instrumentation) à distance ;
  
• les scripts qui gèrent des clients et des serveurs distants.
  

RPC ouvre plusieurs ports, puis expose un grand nombre de serveurs sur ces ports. Il demande alors au Pare-feu Windows de créer des exceptions associées pour ces ports. Si le Pare-feu Windows est configuré pour autoriser de telles demandes, les ports nécessaires seront ouverts aussi longtemps que RPC a besoin de l'exception (comme pour une exception de programme).

Afin de permettre les scénarios d'administration à distance, de nombreux déploiements effectués à l'échelle de l'entreprise nécessitent que les services système qui utilisent RPC fonctionnent par défaut avec le Pare-feu Windows.

Par défaut, RPC ne fonctionne pas via le Pare-feu Windows. Tous les services système qui utilisent RPC sont concernés. Néanmoins, le Pare-feu Windows peut être configuré de façon à autoriser RPC à fonctionner pour ces services au moyen du paramètre d'administration à distance. Ce paramètre active également des exceptions pour les requêtes d'écho du mappeur des points de terminaison RPC (TCP 135), de SMB sur TCP (TCP 445) et d'ICMP.

Reportez-vous à la section « Dois-je modifier mon code pour utiliser Windows Server 2003 Service Pack 1 ? », plus loin dans ce document.

Auparavant, il n'y avait aucun moyen pour un utilisateur de réinitialiser la configuration du pare-feu de connexion Internet (ICF). Au fil du temps, il a été possible de faire en sorte que le pare-feu autorise le trafic entrant non sollicité sur des ports non utilisés par d'autres applications. Toutefois, il devenait souvent difficile pour l'utilisateur de revenir à la configuration d'origine.

Or, cette option permet à l'utilisateur de restaurer rapidement les valeurs par défaut des paramètres du Pare-feu Windows. De plus, ces paramètres peuvent être modifiés par les fabricants d'ordinateurs OEM et les entreprises afin de créer des options de configuration par défaut personnalisées.

Cette option permet aux utilisateurs finals de restaurer les valeurs par défaut d'origine des paramètres du Pare-feu Windows.

L'ajout de cette nouvelle fonction ne modifie en rien le fonctionnement du Pare-feu Windows. Cependant, l'utilisation de cette fonction a pour effet de désactiver le Partage de connexion Internet et le pont réseau.

Dans les précédentes versions de Windows, il n'était pas possible de configurer le Pare-feu de connexion Internet au cours de l'installation. Il était donc difficile pour les fabricants d'ordinateurs OEM et les entreprises de préconfigurer le pare-feu avant de distribuer un ordinateur aux utilisateurs finals. Dans Windows Server 2003 Service Pack 1, vous pouvez configurer les options suivantes du Pare-feu Windows par le biais de l'installation sans assistance :

• Mode opérationnel
  
• Applications dans la liste des exceptions du Pare-feu Windows
  
• Ports statiques dans la liste des exceptions
  
• Options ICMP
  
• Options d'ouverture de session
  

La possibilité de préconfigurer le Pare-feu Windows fournit aux revendeurs Windows et aux grandes entreprises une plus grande flexibilité et le moyen de personnaliser le pare-feu.

Grâce à cette fonction, l'utilisateur bénéficie d'une plus grande flexibilité pour configurer le Pare-feu Windows. L'ajout de cette nouvelle fonction ne modifie en rien le fonctionnement du Pare-feu Windows.

La syntaxe utilisée pour activer ou désactiver le pare-feu de connexion Internet dans un script sans assistance a été remplacée par la nouvelle syntaxe du Pare-feu Windows.

Les sections du fichier Unattend.txt pour la configuration du Pare-feu Windows sont les suivantes :

• [WindowsFirewall]
  Section obligatoire définissant les profils à utiliser et les paramètres du fichier journal du Pare-feu Windows.
  
• [WindowsFirewall.profile_name]
  La section du profil du domaine, [WindowsFirewall.Domain], contient des paramètres pour le cas où un ordinateur est connecté à un réseau comprenant les contrôleurs de domaine du domaine auquel appartient l'ordinateur. Le profil Standard, [WindowsFirewall.Standard], contient des paramètres pour le cas où un ordinateur n'est pas connecté à un réseau comprenant les contrôleurs de domaine du domaine auquel appartient l'ordinateur. Si vous ne souhaitez pas que le Pare-feu Windows soit utilisé, spécifiez Profiles = WindowsFirewall.TurnOffFirewall
  La section [WindowsFirewall.profile_name] est une section définie par l'utilisateur référencée par la section [WindowsFirewall] et qui permet de modifier la configuration par défaut du Pare-feu Windows, y compris les programmes, les services, les ports et les paramètres ICMP.
  
• [WindowsFirewall.program_name]
  Section définie par l'utilisateur qui permet d'ajouter un programme à la liste des exceptions du Pare-feu Windows.
  
• [WindowsFirewall.service_name]
  Section définie par l'utilisateur qui permet d'ajouter un service prédéfini à la liste des exceptions du Pare-feu Windows (tel que le Partage des fichiers et des imprimantes, l'Infrastructure UPnP, le Bureau à distance et l'Administration à distance).
  
• [WindowsFirewall.portopening_name]
  Section définie par l'utilisateur qui permet d'ajouter un port à la liste des exceptions du Pare-feu Windows.
  
• [WindowsFirewall.icmpsetting_name]
  Section définie par l'utilisateur qui permet d'ajouter des types de messages ICMP à la liste des exceptions du Pare-feu Windows.
  

Le trafic réseau de diffusion et de multidiffusion diffère du trafic de monodiffusion, car la réponse provient d'un hôte inconnu. Le filtrage avec état empêche donc la réponse d'être acceptée. Ceci a pour effet d'empêcher plusieurs scénarios de fonctionner, de la diffusion multimédia à la découverte.

Pour permettre à ces scénarios de fonctionner, le Pare-feu Windows autorise pendant trois secondes une réponse en monodiffusion depuis n'importe quelle adresse source directement accessible sur le même port que le port d'origine du trafic de diffusion ou de multidiffusion.

Cette modification permet aux applications et aux services qui utilisent la diffusion et la multidiffusion pour communiquer de fonctionner sans que l'utilisateur ou l'application/le service ne modifie la stratégie du pare-feu. Ceci est important par exemple pour le service NETBIOS sur TCP/IP, afin que des ports sensibles comme le port 135 ne soient pas exposés.

Dans Windows Server 2003, le Pare-feu de connexion Internet opérait un filtrage avec état sur le trafic de diffusion et de multidiffusion, et l'utilisateur devait donc ouvrir le port manuellement pour recevoir la réponse. Dans Windows Server 2003 Service Pack 1, le Pare-feu Windows accepte la réponse au trafic de diffusion ou de multidiffusion sans aucune configuration supplémentaire.

L'interface utilisateur du pare-feu a été mise à jour dans Windows Server 2003 Service Pack 1 afin de prendre en compte les nouvelles options de configuration et l'intégration du pare-feu de connexion Internet IPv6. Elle permet désormais à l'utilisateur de changer les états de fonctionnement, la configuration globale, les options de journalisation et les options ICMP.

Le point d'entrée principal de l'interface utilisateur n'est plus la boîte de dialogue Propriétés de la connexion, mais une icône du Panneau de configuration. Cependant, un lien est toujours disponible à l'ancien emplacement. De plus, Windows Server 2003 Service Pack 1 crée un lien à partir du dossier Connexions réseau.

Les fonctionnalités ajoutées à Windows Server 2003 Service Pack 1 nécessitaient la mise à jour de l'interface utilisateur.

L'interface utilisateur, qui était accessible depuis l'onglet Paramètres avancés de la boîte de dialogue Propriétés de la connexion réseau, est maintenant représentée par une icône Pare-feu Windows spécifique dans le Panneau de configuration.

Dans les précédentes versions de Windows, le Pare-feu de connexion Internet était associé à un seul objet de stratégie de groupe : Interdire l'utilisation de pare-feu de connexion Internet sur le réseau de votre domaine DNS. Avec Windows Server 2003 Service Pack 1, toutes les options globales de configuration peuvent être définies via la stratégie de groupe. Vous trouverez ci-après quelques-unes des nouvelles options de configuration disponibles :

• Définir les exceptions de programmes
  
• Autoriser les exceptions de programmes locaux
  
• Autoriser les exceptions ICMP
  
• Empêcher les notifications
  
• Autoriser l'exception de partage de fichiers et d'imprimantes
  
• Autoriser la journalisation
  

Chacun de ces objets peut être défini à la fois pour le profil de l'entreprise et pour le profil standard. Pour plus d'informations sur les options de stratégie de groupe, voir « Déploiement des paramètres du Pare-feu Windows pour Microsoft Windows XP Service Pack 2 » (en anglais) dans le Centre de téléchargement Microsoft à l'adresse http://go.microsoft.com/fwlink/?linkid=23277. Ce document traite également des changements dans Windows Server 2003 Service Pack 1.

Il est primordial que les administrateurs puissent centraliser la gestion des paramètres de la stratégie du Pare-feu Windows pour permettre aux applications et aux scénarios de fonctionner dans l'environnement de l'entreprise.

L'administrateur peut désormais définir la stratégie par défaut du Pare-feu Windows. Il peut activer ou désactiver des applications et des scénarios. Cela autorise davantage de contrôle, mais les stratégies ne modifient en rien les fonctionnalités sous-jacentes du Pare-feu Windows.

Pour le grand public et les entreprises, un ordinateur est généralement un client sur le réseau. Un logiciel résidant sur l'ordinateur se connecte à un serveur (connexion sortante) et reçoit une réponse du serveur. Le Pare-feu Windows autorise toutes les connexions sortantes, mais applique des règles aux types des communications qui peuvent être renvoyées vers l'ordinateur.

Voici des exemples de tâches impliquant des applications Microsoft susceptibles de fonctionner ainsi :

• navigation sur le Web à l'aide de Microsoft Internet Explorer ;
  
• vérification du courrier électronique dans Outlook Express ;
  
• conversations dans MSN Messenger ou Windows Messenger.
  

Aucune. Le Pare-feu Windows autorisera automatiquement toutes les connexions sortantes, quels que soient le programme et le contexte utilisateur.

Remarques

Lorsqu'un ordinateur émet une requête de session TCP vers un ordinateur cible, il accepte uniquement une réponse provenant de cet ordinateur cible. Lorsqu'un ordinateur envoie des paquets UDP, le Pare-feu Windows autorise pendant environ 90 secondes l'envoi de réponses UDP vers le port à partir duquel les paquets UDP ont été émis, à partir de n'importe quelle adresse IP. Les réponses en monodiffusion au trafic de diffusion ou de multidiffusion sont autorisées via le Pare-feu Windows pendant trois secondes, si les réponses sont destinées au port à partir duquel le trafic a été envoyé et proviennent d'adresses IP appartenant au même réseau local que l'ordinateur. Un paramètre du pare-feu contrôle ce comportement, qui est activé par défaut.

Ce scénario met en œuvre une application qui exécute une opération d’écoute sur un socket TCP ou qui se lie à un socket UDP spécifique par l’intermédiaire de Winsock. Pour ce scénario, le Pare-feu Windows peut automatiquement ouvrir et fermer les ports requis par l’application.

Voici des exemples de tâches impliquant des applications Microsoft susceptibles de fonctionner ainsi :

• utilisation de l'audio et de la vidéo dans MSN Messenger ou Windows Messenger ;
  
• transfert de fichiers dans MSN Messenger ou Windows Messenger ;
  
• hébergement d'un jeu multijoueur.
  

Si vous développez une application qui doit écouter sur un ou plusieurs ports, Microsoft vous demande de mettre à jour votre code afin que l'utilisateur indique s'il veut autoriser l'application à ouvrir des ports dans le pare-feu :

• S'il accepte, l'application peut alors utiliser l'API INetFwAuthorizedApplication pour s'ajouter elle-même à la collection AuthorizedApplications en tant qu'application activée.
  
• S'il refuse, l'application doit alors utiliser l'API INetFwAuthorizedApplication pour s'ajouter elle-même à la collection AuthorizedApplications en tant qu'application désactivée.
  

Lorsque l'API INetFwAuthorizedApplication est utilisée pour ajouter une application à la collection AuthorizedApplications, les valeurs suivantes sont requises :

• Nom du fichier image. Il s'agit du fichier qui appelle Winsock pour écouter le trafic réseau. Il doit s'agir d'un chemin entièrement qualifié, pouvant cependant contenir des variables d'environnement.
  
• Nom convivial. Description de l'application qui sera visible dans l'interface utilisateur du Pare-feu Windows.
  

Pour plus d'informations sur l'API INetFwAuthorizedApplication, voir « INetFwAuthorizedApplication » dans le Kit de développement logiciel (SDK) de la plate-forme Microsoft sur le site Web MSDNà l'adresse http://go.microsoft.com/fwlink/?LinkId=32000 (en anglais).

Le Pare-feu Windows surveille Winsock pour déterminer quand les applications commencent et cessent d'écouter les ports. C'est pourquoi les ports sont automatiquement ouverts et fermés pour les applications, une fois que leurs entrées ont été activées dans la liste des exceptions du Pare-feu Windows. Cela signifie qu'aucune action n'est requise de la part des applications Winsock pour ouvrir et fermer les ports dans le pare-feu.

Remarques

Une application doit être exécutée dans le contexte d'un utilisateur doté de droits d'administrateur pour pouvoir s'ajouter à la liste des exceptions du Pare-feu Windows. Les ports sont automatiquement ouverts et fermés dans le pare-feu pour les applications Winsock autorisées, quel que soit le contexte utilisateur dans lequel elles sont exécutées. Les applications doivent obtenir l'accord de l'utilisateur avant de s'ajouter elles-mêmes à la collection INetFwAuthorizedApplications. Svchost.exe ne peut pas être ajouté à la collection INetFwAuthorizedApplications.

Bien qu'il soit recommandé aux développeurs d'utiliser les API INetFWAuthorizedApplication pour tous les autres scénarios, il est conseillé d'utiliser des API de port global dans le Pare-feu Windows pour les services qui écoutent des ports fixes. Dans la mesure où ces ports sont toujours ouverts, leur ouverture dynamique n’offrirait que peu d’avantages. En revanche, les utilisateurs ont la possibilité de personnaliser les paramètres du pare-feu pour ces ports fixes lorsque les interfaces API de port global sont utilisées.

Voici des exemples de services nécessitant des connexions entrantes :

• Partage de fichiers et d'imprimantes
  
• Architecture UPnP
  
• Bureau à distance
  

Lorsqu'un service doit écouter un port fixe, il doit demander à l’utilisateur s’il souhaite permettre au service d'ouvrir des ports dans le pare-feu. De préférence, ceci doit se faire lors de l'installation du service.

Si l'utilisateur accepte, le service doit alors utiliser l'API INetFwOpenPort pour ajouter des règles au Pare-feu Windows pour le ou les ports fixes dont il a besoin. Ces règles doivent être activées.

Si l'utilisateur refuse, le service doit alors quand même utiliser l'API INetFwOpenPort pour ajouter des règles au Pare-feu Windows pour le ou les ports fixes dont il a besoin. En revanche, ces règles ne doivent pas être activées.

Lors de l'utilisation de l'API INetFwOpenPort pour ajouter une ouverture de port au Pare-feu Windows, les valeurs suivantes sont requises :

• Protocole. Spécifie le protocole réseau utilisé par le service, TCP ou UDP.
  
• Port. Numéro du port devant être ouvert.
  
• Nom convivial. Description de l'ouverture du port qui sera visible dans l'interface utilisateur du Pare-feu Windows.
  

Pour plus d'informations sur l'API INetFwOpenPort, voir « InetFwOpenPort » dans le Kit de développement logiciel (SDK) de la plate-forme, sur le site Web MSDN à l'adresse http://go.microsoft.com/fwlink/?LinkId=35316 (en anglais).

Lorsqu'un service est désactivé, il doit quand c'est possible utiliser l'API INetFwOpenPort pour fermer les ports statiques qu'il a ouverts. Cela ne pose aucun problème lorsque les ports sont utilisés par un seul service. En revanche, si le service partage ces ports avec d'autres services, il doit fermer les ports uniquement s'il peut s'assurer qu'aucun autre service ne les utilise.

Une application doit être exécutée dans le contexte d'un utilisateur doté de droits d'administrateur pour pouvoir ouvrir des ports de manière statique dans le Pare-feu Windows.

Remarques
Lorsqu'il ouvre des ports de manière statique via l'API INetFw, un service doit quand c'est possible se limiter au trafic provenant du sous-réseau local. Les services doivent obtenir l'accord de l'utilisateur avant d'ouvrir des ports de manière statique dans le Pare-feu Windows. Un service ne doit jamais ouvrir de ports automatiquement sans en informer l'utilisateur.

Certains services système doivent utiliser des ports RPC, directement via DCOM ou RPC, pour les connexions entrantes. À cause des conséquences que l'ouverture de ports RPC peut avoir en matière de sécurité, ces ports sont traités de manière spéciale et les développeurs doivent s'efforcer d'activer des ports RPC pour les services système via le Pare-feu Windows uniquement lorsque c'est absolument nécessaire.

Le Pare-feu Windows peut être configuré de façon à permettre l'ouverture et la fermeture automatiques des ports RPC et DCOM pour les services système. Néanmoins, les ports RPC sont par défaut bloqués par le Pare-feu Windows. Ce qui signifie que les applications qui utilisent les ports RPC pour transférer des données vers des services système devront configurer le Pare-feu Windows en conséquence. Si une application doit activer cette fonction, elle doit demander à l’utilisateur s’il souhaite permettre aux services d’ouvrir des ports dans le pare-feu. Il est préférable que ceci soit fait au moment de l'installation.

Si l'utilisateur accepte que les ports RPC soient ouverts, alors le service doit utiliser l'API INetFwRemoteAdminSettings pour ouvrir les ports dont il a besoin.

S'il refuse, alors l'application ou le service ne doit pas configurer le Pare-feu Windows pour qu'il autorise les ports RPC.

Pour plus d'informations sur l'API INetFwRemoteAdminSettings, consultez « INetFwAuthorizedApplication » sur le site Web MSDN à l'adresse http://go.microsoft.com/fwlink/?linkid=32000 puis, dans le sommaire, cliquez sur la propriété « RemoteAddresses » de InetFwAuthorizedApplication (en anglais).

Remarques

Pour pouvoir activer ou désactiver l'ouverture automatique des ports RPC dans le Pare-feu Windows, une application ou un service doit être exécuté dans le contexte d'un utilisateur possédant des droits d'administrateur. Une application ou un service doit essayer d'autoriser les ports RPC via le Pare-feu Windows uniquement lorsque c'est absolument nécessaire. Si les ports RPC sont déjà ouverts, il n'est pas nécessaire que l'application ou le service effectue quoi que ce soit pour fonctionner correctement. Vous pouvez déterminer les ports déjà ouverts à l'aide de l'API IsPortAllowed. Le paramètre des ports RPC fonctionne uniquement sur les serveurs RPC exécutés dans le contexte du système local, du service réseau ou du service local. Les ports ouverts par les serveurs RPC exécutés dans d'autres contextes utilisateur ne pourront pas être activés par le biais de ce paramètre. Ces serveurs RPC devront à la place utiliser la liste des exceptions du Pare-feu Windows.