Sécurité

Gestion du pare-feu Windows Vista

Jesper M. Johansson

 

Vue d'ensemble:

• Types de règles et scénarios
• Profils de pare-feu
• Règles d'isolation de domaine
• Problèmes du filtrage sortant

Il y a quelque temps de cela, j'ai écrit un article sur le pare-feu de Windows Vista dans mon blog. Cet article décrivait simplement certaines des fonctionnalités conviviales du pare-feu mais ne donnait pas de conseils spécifiques sur la façon de le déployer.

Dans le présent article, j'examinerai plus en détails certaines des fonctionnalités du pare-feu Windows Vista® qui sont spécifiquement conçues pour faciliter la gestion d'entreprise. J'inclurai également quelques conseils sur la façon dont vous pouvez les utiliser pour vous simplifier la tâche et garantir une plus grande sécurité pour vos utilisateurs.

Avec la publication récente du SP1 pour Windows Vista, le déploiement en entreprise de Windows Vista est susceptible de devenir plus généralisé. Les entreprises attendent généralement la sortie du premier Service Pack avant de migrer vers un nouveau système d'exploitation. Si vous faites partie des professionnels de l'informatique qui envisagent plus sérieusement de déployer Windows Vista dans votre environnement d'entreprise, je vous conseille de jeter un meilleur coup d'œil au pare-feu. Une fois que vous vous rendrez compte des capacités du pare-feu de Windows Vista, vous voudrez peut-être renégocier l'accord sur votre suite de logiciels de sécurité tiers pour supprimer le pare-feu.

Historique des pare-feu Windows

Le pare-feu inclus dans la version originale de Windows® XP laissait beaucoup à désirer. Bien qu'il était équivalent à la fonctionnalité de sécurité des pare-feu commerciaux basés sur des hôtes de l'époque, il n'apportait rien de nouveau ni d'innovant.

Le produit de remplacement livré avec Windows XP SP2 a été complètement modifié. Il est spécifiquement conçu pour faciliter la gestion d'entreprise. Le pare-feu Windows XP SP2 est très attrayant car il est léger, gérable de façon centralisée, efficace et non encombrant. Mais son atout essentiel est le suivant : le pare-feu Windows XP SP2 protège le système au démarrage.

Ce dernier point est crucial. Dans le passé, j'ai vu beaucoup de systèmes être infectés pendant le démarrage, même avec un pare-feu activé. En effet, pendant l'épidémie de Blaster, les taux d'attaques étaient de l'ordre d'une toutes les quatre minutes. En d'autres termes, si vous laissiez un ordinateur non protégé sur Internet, il risquait d'être infecté, en moyenne, toutes les quatre minutes. Avec un pare-feu ne protégeant pas le système au démarrage, 1 système sur 12 aurait été infecté au redémarrage. Ce sont ces chiffres qui ont conduit Microsoft à inclure une protection du système au démarrage dans le pare-feu Windows XP SP2.

Dans Windows Vista, le pare-feu a subi une autre transformation totale. La nouveauté la plus évidente, du point de vue de la gestion, est que les interfaces de gestion des protocoles IPSec (Internet Protocol Security) et le pare-feu ont été fusionnés. Cette modification est très logique. IPSec et le pare-feu sont tous deux conçus pour bloquer les éléments qui ne sont pas autorisés. La différence est que dans le pare-feu, les paramètres qui définissent ce qui est autorisé ou pas ne sont pas très granulaires, tandis qu'avec IPSec, il n'est pas facile de bloquer ou d'autoriser de grands groupes d'espaces d'adresse.

Avec les deux fonctionnalités réunies dans une même interface de gestion, les administrations peuvent utiliser les deux technologies de façon continue, sans s'inquiéter de savoir si une règle IPSec ou un filtre de pare-feu est requis. Bref, vous avez une vue unique de la surface d'attaque de réseau sur le système, ce qui réduit le risque d'erreurs.

SP1 pour Windows Vista apporte une fiabilité améliorée aux fonctions de pare-feu. Il ajoute également de nouveaux algorithmes, notamment les algorithmes Suite B, destinés à être utilisés dans IPSec. Il s'agit d'une série d'algorithmes de chiffrement, comprenant la norme de chiffrement avancé AES (Advanced Encryption System), le système de cryptographie de courbe elliptique ECC (Elliptic Curve Cryptography) et l'algorithme de hachage SHA (Secure Hash Algorithm) 256 et 384.

Plus important encore, le Service Pack 1 inclut maintenant la prise en charge de la protection de l'accès réseau (NAP). NAP est un outil de mise en application de stratégie qui s'assure que les clients gérés et non compromis sont à jour avec les dernières stratégies de sécurité, mises à jour et définitions anti-logiciels malveillants avant qu'ils ne soient autorisés à se connecter au réseau. NAP ne peut pas empêcher les hôtes malveillants de se connecter au réseau, mais il garantit que tous les hôtes gérés sont entièrement conformes tant qu'ils ne sont pas activement compromis.

Le pare-feu de Windows Vista, appelé Pare-feu Windows avec sécurité avancée, est également inclus dans Windows Server® 2008. Toutes les fonctionnalités peuvent en outre être gérées à distance et configurées sur un réseau à l'aide de la stratégie de groupe.

Types de règles et scénarios

La combinaison des fonctionnalités du pare-feu et IPSec dans l'interface de gestion signifie qu'il existe maintenant deux types de règles différents : les règles directionnelles et les règles de connexion. Les règles directionnelles sont des règles de pare-feu standard qui définissent quel trafic autoriser dans la direction appropriée. Les règles de connexion définissent les paramètres de protection pour les connexions entre les ordinateurs. Pour utiliser une analogie, les règles directionnelles sont un peu comme les règles des pare-feu précédents tandis que les règles de connexion sont plus comme les règles IPSec utilisées conjointement avec le pare-feu de Windows XP SP2.

La combinaison du pare-feu et d'IPSec dans la même interface permet plusieurs scénarios très intéressants. Par exemple, l'isolation des systèmes sur le réseau est l'un des concepts de sécurité les plus importants aujourd'hui. Microsoft appelle ce concept « l'isolation de serveur et de domaine ».

L'isolation de serveur et de domaine utilise les fonctionnalités IPSec et du pare-feu. Dans cet esprit, la nouvelle interface de gestion de pare-feu inclut une fonctionnalité spécifique pour les règles d'isolation. Celles-ci sont appropriées si vous voulez par exemple limiter la connexion en fonction des attributs des systèmes source ou de destination, comme l'appartenance à un domaine.

Comme vous pouvez le voir dans la figure 1, l'Assistant Nouvelle règle de sécurité de connexion commence par vous demander quel type de règle vous voulez créer. Si vous sélectionnez Isolation, l'Assistant préconfigure certains paramètres qui sont appropriés pour une règle d'isolation.

Figure 1** Utilisation de l'Assistant Nouvelle règle de sécurité de connexion pour créer une règle d'isolation **(Cliquez sur l'image pour l'agrandir)

Vous remarquerez peut-être aussi dans la figure 1 que la règle d'isolation mentionne l'état d'intégrité. Les règles utilisées pour l'isolation de serveur et de domaine sont en réalité les mêmes règles que celles que vous utilisez pour NAP.

Vous ne pouvez pas appliquer l'authentification pour certains types de trafic. Par exemple, il est probable que vous n'ayez pas besoin de l'authentification pour la résolution DNS. Pour les points de terminaison de ce type de trafic, vous avez besoin d'une règle d'exemption d'authentification. Une règle d'exemption d'authentification fait exactement ce que son nom indique : elle exempte le trafic des exigences IPSec.

En revanche, le nom de règle serveur est plutôt mal choisi. Bien qu'elles soient plus couramment utilisées avec les serveurs, elles peuvent également être utilisées avec des clients. Une règle serveur à serveur configure simplement une connexion de façon à demander l'authentification. Ceci diffère d'une règle d'isolation dans la mesure où non seulement une règle d'isolation nécessite l'authentification, mais elle nécessite également que certains critères supplémentaires soient remplis, comme l'appartenance à un domaine ou un état d'intégrité.

Une règle de tunnel définit essentiellement un réseau privé virtuel de site à site (VPN) et le tunnel entre les passerelles. Les règles de tunnel sont rarement utilisées avec Windows Vista, car il est peu probable que vous utilisiez Windows Vista avec une passerelle. Vous pouvez créer des règles entièrement personnalisées, ce qui signifie que vous pouvez personnaliser chaque paramètre d'une règle.

Classement des règles

Le classement des règles semble à première vue un peu compliqué. La clé pour comprendre le classement des règles est d'oublier l'idée de classement. L'important n'est pas tant de classer mais plutôt d'effectuer une sélection correspondante. Prenons comme exemple le trafic entrant. Le trafic entrant qui ne correspond à aucune règle qui l'autorise est bloqué par défaut. Vous pourriez considérer cela comme un classement qui décrète que « les règles d'autorisation sont examinées en premier, » mais cette supposition serait inexacte. Si un paquet spécifique correspond à une règle d'autorisation et une règle de bloc, la règle de bloc gagne. En termes plus simples, ceci signifie que la correspondance est la suivante :

1. Règles de blocage : si un paquet ou une connexion correspond à l'une de ces règles, il est rejeté.
2. Règles d’autorisation : si un paquet ou une connexion correspond à l'une de ces règles, il est accepté.
3. Comportement du profil directionnel par défaut : Si aucune règle de bloc ou d'autorisation ne correspond, le trafic est traité selon le comportement spécifié par défaut dans ce profil pour le trafic dans cette direction. Dans la direction entrante, dans tous profils, cela signifie que le trafic est bloqué dans une configuration par défaut. Dans la direction sortante, par défaut, cela signifie que le trafic est autorisé dans la configuration par défaut.

Le processus correspondant est géré par des règles de contournement authentifiées (IPSec). Avec ce type de règle, tout trafic authentifié qui correspond aux autres paramètres de la règle est autorisé, qu'il corresponde ou non à d'autres autres règles. Les règles de contournement authentifiées sont des règles directionnelles pour lesquelles l'option Substituer les règles de blocage est sélectionnée, comme le montre la figure 2. Ces règles sont examinées en premier, de façon à toujours autoriser le trafic authentifié à atteindre le système. Cet aspect est essentiel si vous voulez facilement autoriser le trafic provenant d'hôtes authentifiés tout en bloquant le trafic d'autres sources. Vous pouvez considérer cette règle comme 0 dans le classement. Ainsi, l'ordre complet des règles est le suivant :

Figure 2** Activation de l'option Substituer les règles de blocage pour configurer une règle de contournement authentifiée **(Cliquez sur l'image pour l'agrandir)

0. Règles de contournement authentifié

1. Règles de blocage

2. Règles d’autorisation

3. Comportement du profil directionnel par défaut

Le fait que plusieurs règles dans chaque classe correspondent au schéma de trafic n'a pas d'importance. Dès qu'une règle correspond au trafic, le traitement de cette règle est arrêté.

Profils public, privé et de domaine

Ressources de mise en réseau

• Centre de sécurité TechNet Security Center
• Utilisation de l'outil de ligne de commande Netsh Advfirewall
• Règles de sécurité pour le pare-feu Windows et pour les connexions IPsec dans Windows Vista et dans Windows Server 2008
• Vigilance sécurité Utilisation de l'Assistant Configuration de la sécurité dans Windows Server 2008

Le nouveau pare-feu comprend trois profils : public, privé et de domaine. Le pare-feu Windows XP SP2 a, lui, deux profils de réseau : standard et de domaine. Le profil de domaine est automatiquement appelé lorsque l'ordinateur détecte le contrôleur de domaine. Dans Windows XP, le profil standard était utilisé autrement. Cette fonctionnalité puissante permettait à un administrateur de la sécurité de verrouiller l'ordinateur complètement lors d'une opération d'itinérance tout en autorisant la fonctionnalité de gestion à distance nécessaire sur le réseau de l'entreprise. Cette approche présentait cependant certains problèmes pour certains utilisateurs, en particulier pour ceux disposant de réseaux privés chez eux. Étant donné que le profil standard était toujours utilisé si le système était incapable d'atteindre le contrôleur de domaine, le système était verrouillé depuis le domicile de l'utilisateur.

Le nouveau profil privé inclus dans Windows Vista permet de résoudre ce problème. À présent, lorsque vous connectez le système à un nouveau réseau, il demande si ce réseau est public (il s'agit simplement du nouveau nom de l'ancien profil standard) ou privé et configure le système en conséquence. Le système se rappelle de cela chaque fois qu'il se connecte à ce réseau particulier, selon des paramètres de réseau qui lui sont présentés par les serveurs d'infrastructure sur le réseau. Cette méthode n'est pas totalement infaillible, mais elle est utile dans la mesure où elle autorise plus de réseaux à être mieux verrouillés.

La logique de détection de la présence d'un système sur le domaine a été également améliorée. Le résultat est une transition plus fiable et plus rapide et un nombre réduit de systèmes qui pensent pouvoir utiliser les profils public ou privé lorsqu'ils sont sur le domaine.

Vous pouvez lier vos règles à un type particulier de réseau, ce qui empêche le système de révéler trop d'informations et de tenter de se connecter aux systèmes sur des réseaux non fiables. C'est un domaine où l'intégration du pare-feu et d'IPSec porte ses fruits.

Grace à ces nouvelles règles, vous pouvez fournir certaines restrictions qui n'étaient pas possibles auparavant. Par exemple, pendant plusieurs années, les pirates ont tenté d'inciter des attaques en faisant en sorte que les utilisateurs effectuent des connexions SMB (bloc de message serveur), pour la mise en réseau Windows, à des hôtes non autorisés, ce qui forçait une séquence d'authentification à leur donner une paire défi-réponse pouvant être utilisée pour craquer les mots de passe. Les versions antérieures de cette attaque étaient également utilisées pour désactiver l'authentification de texte ou refléter la paire défi-réponse de l'utilisateur à l'ordinateur source. La première technique a été arrêtée il y a plusieurs années. La dernière technique a été atténuée grâce à Windows XP SP2, mais gardez à l'esprit que la divulgation de paires défi-réponse est néanmoins imprudente.

Pour empêcher cela, vous pourriez utiliser une autre nouvelle fonction du pare-feu de Windows Vista : le filtrage sortant. Un administrateur peut décider, par exemple, de bloquer toutes les connexions SMB sortantes (qui se terminent aux ports TCP 135, 139, 445 et UDP 137, 138, 445) dans le profil public. Il serait alors plus difficile pour un système d'être utilisé dans une attaque pour obtenir les paires de défi-réponse ou d'empêcher son accès aux fichiers partagés Windows non fiables sur l'Internet.

Encore une fois, cette méthode n'est certainement pas infaillible. Par exemple, si le système a déjà été compromis, cette règle n'arrêterait pas le système de communiquer vers l'extérieur car le pirate pourrait simplement désactiver la règle. Cependant, elle peut être très utile comme mesure de protection des systèmes légitimes mais potentiellement exposés.

Il est important de mentionner dans ce contexte que, tout comme dans Windows XP SP2, seul un profil peut être actif à la fois sur Windows Vista et Windows Server 2008. S'il y a deux interfaces de réseau en direct dans le système et que l'une d'elles est sur le domaine tandis que l'autre est sur un réseau public, le profil de pare-feu public est appliqué aux deux. Le profil le plus restrictif est toujours utilisé. Comme vous pouvez le deviner, le profil public est plus restrictif que le profil privé, et le profil privé est plus restrictif que le profil de domaine. Soyez donc conscient que la règle de blocage SMB sortant peut arrêter beaucoup de trafic sur des connexions VPN.

Pour activer le trafic sur une connexion VPN lorsque l'ordinateur est sur un réseau public ou privé, vous devez créer des règles directionnelles qui s'appliquent seulement aux interfaces VPN. Pour que cela fonctionne, les interfaces VPN doivent être reconnues comme telles par Windows. Si vous n'utilisez pas le serveur VPN des services de routage et d'accès à distance Microsoft®, testez cette fonctionnalité avant de la déployer à grande échelle. Il s'agit principalement d'un problème concernant le trafic entrant vers le client et les règles sortantes personnalisées que vous créez.

Création de règles de pare-feu

La création d'une règle de pare-feu est beaucoup plus facile avec le nouveau pare-feu. L'Assistant Nouvelle règle, illustré à la figure 3, vous permet de définir tous les types habituels de règles. Il inclut également des règles prédéfinies pour les services particuliers.

Figure 3** Règles prédéfinies de l'Assistant Nouvelle règle **(Cliquez sur l'image pour l'agrandir)

Les règles prédéfinies sont particulièrement importantes. L'isolation de serveur consiste essentiellement à limiter les services de telle façon qu'ils sont seulement disponibles pour les systèmes qui en ont besoin. Sur les produits serveur, l'assistant Configuration de Sécurité de Windows (SCW) peut être utilisé pour faciliter cette opération, bien qu'il n'élimine pas tous les problèmes (j'ai abordé le SCW dans le numéro de mars 2008 de TechNet Magazine).

Les versions client de Windows n'ont jusqu'à présent pas inclus de fonctionnalité similaire. Lorsque vous utilisez le type de règle prédéfini, une bonne partie du travail est faite pour vous, c'est-à-dire la tâche de déterminer quels points de terminaison un service utilise. Le pare-feu est non seulement conscient de l'application dans la mesure où il sait quel programme le « service iSCSI » représente, mais il contient également des règles prédéfinies qui décrivent certaines fonctionnalités. Vous pouvez alors vous concentrer sur les ordinateurs qui doivent être couverts par une règle. Cette tâche reste longue et difficile, mais au moins elle est unique à votre environnement.

Il existe également une règle personnalisée (masquée par la liste déroulante dans la figure 3) qui vous offre toute la flexibilité qu'un pare-feu d'authentification peut offrir. Par exemple, si vous voulez une règle qui autorise seulement le trafic IPSec chiffré, sélectionnez l'option qui autorise uniquement les connexions sécurisées sur la page Action de l'assistant illustrée à la figure 2.

Lorsque vous sélectionnez cette option, vous avez également la possibilité d'activer le chiffrement. Si vous laissez cette option vide, le trafic utilise ESP-NUL (charge utile de sécurité encapsulée avec une clé NULL). Il s'agit de la méthode recommandée pour utiliser IPSec pour l'authentification. Elle permet à la plupart des outils de gestion de réseau de continuer à fonctionner car le trafic traverse le réseau sans chiffrement, et si vous voulez ajouter le chiffrement, il vous suffit de cocher la case correspondante.

Dans beaucoup de situations, le chiffrement du trafic réseau n'est pas aussi important que le fait de ne pas accepter un trafic provenant d'hôtes malveillants. Le fait de chiffrer le trafic sur le réseau empêche les pirates ayant eu accès au réseau de voir ce qui est contenu dans le paquet. L'authentification peut vous empêcher d'envoyer le paquet et ainsi de subir une attaque tout court. Bien entendu, il y a des situations où le chiffrement au niveau du réseau est important, mais dans beaucoup d'autres, l'authentification suffit.

Création de règles d'isolation de domaine

Dans la plupart des environnements, il est préférable qu'un nombre limité d'ordinateurs puisse envoyer le trafic à un poste de travail. Tout au moins, tous les postes de travail doivent être configurés avec des règles d'isolation de domaine. Cette procédure était compliquée dans Windows XP, mais elle est facile dans Windows Vista.

Tout d'abord, ouvrez l'outil de gestion de votre choix et sélectionnez le nœud Règles de sécurité de connexion. Cliquez sur le nœud avec le bouton droit de la souris et sélectionnez Nouvelle Règle pour ouvrir la boîte de dialogue illustrée à la figure 1. Sélectionnez la règle d'isolation et cliquez sur Suivant. Vous devez maintenant définir si vous voulez que la règle soit obligatoire ou pas. Dans la plupart des cas sur les postes de travail, il est préférable de demander l'authentification pour le trafic entrant. Ceci empêche tout ordinateur qui n'est pas joint au domaine d'envoyer du trafic au poste de travail. Cependant, pour demander des services d'infrastructure, le système doit permettre à un minimum de trafic sortant de passer. La meilleure option est par conséquent de requérir l'authentification pour les connexions entrantes et de demander l'authentification pour les connexions sortantes.

Choisissez ensuite la méthode d'authentification. La sélection par défaut porte le nom Par défaut (ce qui n'est pas particulièrement explicite). Vous pouvez configurer la méthode d'authentification par défaut par ordinateur dans les propriétés IPSec (cliquez avec le bouton droit de la souris sur le nœud Pare-feu Windows avec sécurité avancée et sélectionnez les propriétés). La méthode d'authentification par défaut est toujours Kerberos parce qu'il s'agit de la plus simple et de la plus sécurisée. Cependant, pour des raisons de clarté, je vous recommande de la sélectionner lorsque vous créez vos règles. Normalement, vous n'authentifiez que l'ordinateur et pas l'utilisateur. Si vous nécessitez les deux, il se peut que vous ne puissiez pas accepter certains types de trafic de gestion, comme le trafic SNMP transmis anonymement.

Après avoir sélectionné la méthode d'authentification, il vous reste seulement à sélectionner les profils dans lesquelles vous voulez que cette règle soit disponible. Étant donné qu'il s'agit d'une règle qui s'applique aux ordinateur joints au domaine, qui peuvent présenter un ticket Kerberos, cela n'a pas de sens de l'utiliser pour les profils privé ou public. Pour finir, enregistrez la règle.

Les règles fondamentales d'isolation ne sont plus compliquées. Cependant, pour tirer parti de la puissance d'IPSec pour l'isolation, vous devez implémenter l'isolation de serveur, même sur vos postes de travail. Vous pouvez ainsi empêcher vos postes de travail d'écouter les autres clients. Ils répondront seulement aux stations de gestion appropriées. Imaginez à quel point vous pourriez réduire l'impact des attaques de programmes malveillants si les systèmes client refusaient d'écouter d'autres clients.

Écriture du script de pare-feu

Le nouveau pare-feu est fourni avec une API substantielle qui vous permet d'écrire le script de déploiement et d'évaluation. Idéalement, vous devez utiliser la Stratégie de groupe pour le déploiement, mais étant donné que la Stratégie de groupe n'est pas toujours disponible, il est important d'avoir un jeu d'API approprié pour configurer le pare-feu. Les API sont groupées sous le jeu d'API INetFWPolicy2. Le Kit de développement logiciel et MSDN® Library contiennent plus de détails sur la façon de les utiliser, mais quelques exemples illustrent bien ce point.

Un exemple courant est le besoin de déterminer si un groupe de règles est activé. Par exemple, supposons qu'une application ou un administrateur doive déterminer si le partage de fichiers et d'imprimante est autorisé depuis un système. Pour cela, vous pouvez utiliser INetFWPolicy2::IsRuleGroupCurrentlyEnabled. La figure 4 fournit un échantillon de VBScript qui démontre cette fonction.

Figure 4 Utilisation de INetFWPolicy2::IsRuleGroupCurrentlyEnabled

' Create the FwPolicy2 object.
Dim fwPolicy2
Set fwPolicy2 = CreateObject("HNetCfg.FwPolicy2")

' Get the Rules object
Dim RulesObject
Set RulesObject = fwPolicy2.Rules

'Create a profile object
Dim CurrentProfile
CurrentProfile = fwPolicy2.CurrentProfileTypes

'Check whether File and Printer Sharing is on, and turn it on if not
if fwPolicy2.IsRuleGroupEnabled(CurrentProfile, "File and Printer Sharing") <> TRUE then
    fwPolicy2.EnableRuleGroup CurrentProfile, "File and Printer Sharing", TRUE
end if

Si le partage de fichiers et d'imprimante est désactivé et que vous devez l'activer, vous devez d'abord vous assurer que c'est possible et que cela ne sera pas annulé par la Stratégie de groupe. Pour cela, utilisez l'API INetFWPolicy2::LocalPolicyModifyState. La structure, qui peut être remplie avec du code, est donnée ici :

Const NET_FW_MODIFY_STATE_OK = 0
Const NET_FW_MODIFY_STATE_GP_OVERRIDE = 1
Const NET_FW_MODIFY_STATE_NO_EXCEPTIONS = 2

Dim PolicyModifyState
PolicyModifyState = fwPolicy2.LocalPolicyModifyState
Select Case PolicyModifyState
  Case NET_FW_MODIFY_STATE_OK
  Case NET_FW_MODIFY_STATE_GP_OVERRIDE
  Case NET_FW_MODIFY_STATE_NO_EXCEPTIONS
End Select

Ligne de commande et types d'interfaces

Aucun pare-feu ne serait complet sans une ligne de commande correcte pour la gestion. Il y a un sous-contexte sous netsh, appelé advfirewall. Le contexte advfirewall vous donne accès par une ligne de commande à tout ce que vous pouvez faire dans l'interface utilisateur graphique. Par exemple, si vous voulez implémenter le bloc sortant sur le port 445, vous pouvez exécuter la commande suivante à partir d'une invite de commande élevée :

netsh advfirewall firewall add rule name="Block CIFS Out in the Public profile"
dir=out action=block enable=yes profile=public
localIP=any remoteIP=any remoteport=445 protocol=TCP interfacetype=any

Vous devez alors exécuter la même commande, en remplaçant TCP par UDP pour compléter le bloc. À ce stade, vous avez terminé la mise en œuvre de la règle.

L'une des fonctionnalités les plus utiles du pare-feu est la capacité à configurer des règles basées sur le type d'interface de réseau. N'oubliez pas que certaines règles peuvent avoir un impact sur les connexions VPN. Tant que Windows reconnaît l'interface comme une interface VPN, vous pouvez utiliser ce type de règle pour exempter le trafic sur cette interface :

netsh advfirewall firewall add rule name="Allow CIFS on VPN interfaces"
dir=out action=allow enable=yes profile=public localIP=any
remoteIP=any remoteport=445 protocol=TCP interfacetype=RAS

Vous pouvez également le faire dans l'interface utilisateur graphique, mais pas avant d'avoir créé la règle. Vous devez ensuite cliquer sur la règle avec le bouton droit de la souris, sélectionner des propriétés et cliquer sur l'onglet Avancé. Cet onglet contient une section de types d'interface qui vous permet de sélectionner les types d'interface appropriés.

Filtrage sortant

Le fait que le pare-feu Windows XP SP2 n'inclut pas de filtrage sortant a été utilisé pour démontrer que le pare-feu intégré était inadéquat pour la sécurité. Des milliers d'articles ont été écrits sur le manque de filtrage sortant du pare-feu Windows XP SP2, et ce malgré le fait qu'aucun pare-feu sous Windows XP ne pourrait fournir de façon sécurisée un filtrage sortant.

La fonctionnalité fondamentale qui fait du filtrage sortant un composant de sécurité utile plutôt qu'un simple « ralentisseur » (ou outil de mise en application de stratégie, comme mentionné précédemment) n'existe tout simplement pas dans Windows XP. Elle est cependant présente dans Windows Vista. Il est donc logique que le nouveau pare-feu utilise cette fonctionnalité. Par défaut, la plupart du trafic entrant est bloqué et la plupart du trafic sortant est autorisé.

Par défaut, le filtrage sortant dans le nouveau pare-feu de Windows Vista bloque uniquement le trafic inutile provenant des services. C'est tout ce que vous pouvez faire pour fournir une protection contre un compromis sur l'hôte qui fournit les filtres sortants, et il serait superflu de faire la même chose dans Windows XP.

Les services de Windows Vista peuvent s'exécuter avec un jeton extrêmement limité. En gros, chaque service a son propre identificateur de sécurité (SID), qui est unique pour ce service. Ce SID de service peut être utilisé pour limiter l'accès aux ressources, telles que les ports réseau. Il s'agit de la même fonctionnalité que nous avons vue précédemment lorsque nous avons examiné la restriction du trafic pour les utilisateurs. En conséquence, bien que deux services puissent s'exécuter comme NetworkService, ils ne peuvent pas gérer les processus de l'un l'autre et le pare-feu peut être configuré pour autoriser seulement l'un d'eux à communiquer vers l'extérieur. Si celui qui est bloqué est compromis, il ne peut pas détourner le service autorisé et utilise son port autorisé pour communiquer vers l'extérieur car le port est limité par le SID de service.

Cette fonctionnalité est un autre des composants de sécurité utiles ajoutés à Windows Vista, et le nouveau pare-feu l'utilise pour fournir une valeur de sécurité ajoutée grâce au filtrage de pare-feu sortant.

En effet, le filtrage de pare-feu sur les SID de service est activé par défaut dans le nouveau pare-feu. Cependant, il n'y a pas d'interface utilisateur pour le configurer. Les règles sont prédéfinies dans la clé de registre HKLM\System\CurrentControlSet\services\sharedaccess\parameters\firewallpolicy\RestrictedServices. Sachez cependant que la modification manuelle de cette clé n'est pas prise en charge.

Quel niveau de sécurité le filtrage sortant offre-t-il ?

Le niveau de sécurité offert par le filtrage sortant est souvent un sujet de malentendu dans la communauté des spécialistes de la sécurité. Jusqu'à présent, j'ai mentionné deux scénarios qui fournissent une sécurité par filtrage sortant, mais ils sont tous deux basés sur la nouvelle fonctionnalité de Windows Vista qui n'était auparavant pas disponible. Malgré cela, il y a une perception générale que le filtrage sortant est une bonne chose et doit être un facteur clé dans les décisions d'achat de pare-feu.

Ironiquement, dans beaucoup d'organisations, les capacités de filtrage sortant influencent la décision d'achat, alors qu'elles ne sont pas utilisées une fois le pare-feu implémenté. Cette décision est peu judicieuse et représente un gaspillage d'argent et d'efforts du groupe de sécurité de l'information. Elle semble être motivée plus par un désir de faire quelque chose pour la sécurité que par l'analyse d'une vraie menace. Trop souvent, ce type de sécurité conduit à des décisions qui devraient plutôt être basées sur des faits.

Il y a un fait très simple au sujet du filtrage sortant que ses partisans ne prennent pas en compte. L'argument habituel des fournisseurs de pare-feu basés sur hôte est que si un système est compromis (par un ver ou par un utilisateur malveillant interactif), le filtrage sortant empêche le ver d'infecter les autres systèmes ou le pirate de communiquer vers l'extérieur. Ce n'est pas vrai.

Ce qui est vrai c'est que, dans les mêmes conditions, le filtrage sortant aurait arrêté un logiciel malveillant déjà connu. Cependant, si Windows XP avait été fourni avec le filtrage sortant, les vers que nous avons vus jusqu'à présent auraient probablement été écrits pour le désactiver ou le contourner.

Sous Windows XP (et les versions précédentes de Windows), n'importe quel ver s'exécutant comme un service (et tous les vers courants étaient exécutés comme un service) aurait pu faire ceci. La seule raison pour laquelle cela n'a pas été fait est qu'il n'y avait pratiquement pas d'environnement utilisant le filtrage sortant et il aurait donc été inutile de le désactiver. Dans une attaque interactive, le pirate peut facilement contourner des filtres sortants. Si le pirate a la capacité d'exécuter le code arbitraire, c'est facile. Si nécessaire, le pirate peut également faire en sorte que l'utilisateur contourne les filtres.

Le contournement des filtres de pare-feu sortants basés sur hôte peut être accompli de plusieurs façons, selon le scénario de l'attaque. La façon la plus simple consiste à « demander » à un utilisateur superprivilégié de le faire pour vous. Trop d'environnements exécutent encore leurs utilisateurs comme administrateurs. Ces utilisateurs ont le droit de contourner les stratégies de sécurité à volonté. Il suffit au pirate de présenter à l'utilisateur un choix entre un avantage de sécurité intangible et non immédiat et quelque chose que l'utilisateur considère comme plus important.

Dans beaucoup de cas, l'utilisateur a été tellement inondé de ces types de boîtes de dialogue qu'il clique rapidement sans comprendre réellement ce qui se passe. C'est le problème principal du filtrage sortant. Entre la sécurité et la promesse de téléchargements attrayants, l'utilisateur choisira toujours ces derniers car la grande majorité des boîtes de dialogue demandant aux utilisateurs de prendre des décisions de sécurité sont dépourvues d'informations qui leur permettraient de prendre une telle décision.

Créer des boîtes de dialogue demandant à l'utilisateur de prendre des décisions de sécurité avec suffisamment d'informations est beaucoup plus difficile qu'il ne semble car cela nécessite que le produit de sécurité, comme le pare-feu, non seulement comprenne les ports, les protocoles et l'application qui fait la demande, mais également ce que l'application essaie vraiment de faire et ce que cela signifie pour l'utilisateur. Cette information est très difficile à obtenir par programmation. Par exemple, le fait que Microsoft Word tente de faire une connexion sortante n'est pas aussi intéressant que la raison pour laquelle Word cherche à établir cette connexion.

Nous devons réduire et non augmenter le nombre de boîtes de dialogue inutiles et les pare-feu avec filtrage sortant ne font rien pour aider la situation. Pour savoir ce qui se fait de mieux dans le domaine de l'information offerte à l'utilisateur, j'ai examiné la documentation de vente d'un fournisseur important de pare-feu basé sur hôte. La brochure vente la capacité de filtrage sortant et de conseil du pare-feu. La capacité de conseil détecte ce que l'utilisateur tente de faire et fournit le conseil approprié. Enfin, en théorie... Le texte de la brochure était accompagné d'une capture d'écran indiquant que la capacité de conseil n'est pas encore disponible avec ce programme. Les seules informations données sont des informations d'aide. Il semble que même dans le matériel marketing, les fournisseurs ne peuvent pas produire de boîtes de dialogue instructives.

Puisque les utilisateurs ne possèdent pas les informations suffisantes pour prendre les bonnes décisions de sécurité, il est de la responsabilité de l'administrateur de configurer tout le filtrage sortant car l'utilisateur final n'est pas en mesure de le faire. Ceci augmente considérablement la charge de l'administrateur.

Même si l'utilisateur clique sur une option du type « Me demander plus tard » lorsqu'il est sollicité par le pare-feu, le logiciel malveillant peut généralement contourner le pare-feu. Tant que l'utilisateur sous lequel le code malveillant s'exécute peut ouvrir des connexions sortantes sur un certain port, le code malveillant peut simplement utiliser ce port. Ainsi, n'importe quel processus peut s'accrocher à un processus existant. Cela est autorisé sur les systèmes d'exploitation secondaires. En commençant par Windows Vista, les processus peuvent être raisonnablement limités et c'est pour cette raison que les services, qui sont ceux limités par défaut, sont bloqués par les filtres sortants par défaut.

Malheureusement, la plupart des gens pensent que le filtrage sortant des pare-feu basés sur des hôtes empêche un élément compromis d'attaquer les autres. Cela n'est pas possible. Le fait d'appliquer des mesures protectives sur un élément compromis et de lui demander de ne pas compromettre les autres éléments ne fonctionne pas. La protection doit se situer au niveau de l'élément que vous tentez de protéger et non sur celui contre lequel vous voulez une protection. Demander à un cambrioleur de ne pas voler une fois qu'il a déjà cambriolé votre maison n'est pas aussi efficace que de l'empêcher en premier lieu d'entrer dans votre maison.

Jesper M. Johansson est architecte logiciel chargé du développement de logiciels de sécurité. Il contribue à l’élaboration de TechNet Magazine. Titulaire d'un doctorat en systèmes d'informations de gestion, il a plus de 20 ans d'expérience dans le domaine de la sécurité et est MVP Microsoft dans le domaine de la sécurité d'entreprise. Son dernier ouvrage s'intitule Windows Server 2008 Security Resource Kit.

© 2008 Microsoft Corporation and CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable..