Le petit câbleurModèles d'hôte fort et faible

Joseph Davies

Une configuration de plus en plus courante pour les hôtes réseau consiste à d'être connectés avec plusieurs interfaces réseau. Un hôte multirésident offre une connectivité améliorée parce qu'il peut être connecté simultanément à plusieurs réseaux, tel qu'un intranet ou Internet. Cependant, puisqu'ils peuvent être connectés à la fois à un intranet et à

Internet, les services qui s'exécutent sur des hôtes multirésidents peuvent être vulnérables aux attaques. Pour vous aider à empêcher les attaques et à comprendre comment le trafic IP est traité pour un hôte multirésident, je vais me pencher sur les modèles d'hôte fort et faible d'hôtes multirésidents, avant de décrire comment ces modèles sont pris en charge dans Windows®.

RFC 1122 est la spécification qui décrit ces deux modèles pour un hôte multirésident qui n'agit pas comme un routeur et se contente d'envoyer et de recevoir du trafic IP monodiffusion. Ces modèles, connus sous les noms d'hôte fort et d'hôte faible, indiquent si le trafic monodiffusion envoyé ou reçu doit être associé avec l'interface réseau empruntée par le trafic. Ces modèles déterminent la façon dont un hôte envoie et reçoit les paquets et influe sur la vulnérabilité des services s'exécutant sur l'hôte.

Bien que RFC 1122 définisse ces modèles pour IPv4, ils s'appliquent également à IPv6. Un exemple d'hôte multirésident pour IPv6 est un ordinateur utilisant IPv4 et IPv6 qui possède une carte réseau connectée à un intranet et une interface de tunnel IPv6.

Modèle d'hôte faible

Dans le modèle d'hôte faible, un hôte IP (IPv4 ou IPv6) peut envoyer des paquets sur une interface à laquelle l'adresse IP source du paquet en cours d'envoi n'est pas attribuée. On appelle cela le comportement d'envoi d'hôte faible. Un hôte IP peut également recevoir des paquets sur une interface à laquelle l'adresse IP de destination du paquet en cours de réception n'est pas attribuée. On appelle cela le comportement de réception d'hôte faible

Lorsque vous avez un hôte IP multirésident avec plusieurs interfaces, le fait d'activer le comportement d'envoi d'hôte faible sur les interfaces peut parfois rendre l'hôte vulnérable aux attaques multi-hébergement. Par exemple, la figure 1 illustre un hôte A connecté à la fois à Internet et à un intranet. L'hôte A possède l'adresse IPv4 publique 131.107.89.211 attribuée à son interface Internet et l'adresse IPv4 privée 192.168.17.48 assignée à son interface intranet.

Figure 1** Exemple d'ordinateur multirésident **

Avec le comportement d'envoi d'hôte faible activé sur ses interfaces Internet et intranet, l'hôte A peut envoyer des paquets de 131.107.89.211 sur son interface Internet, des paquets de 192.168.17.48 sur son interface Internet, des paquets de 131.107.89.211 sur son interface intranet et des paquets de 192.168.17.48 sur son interface intranet.

Avec le comportement de réception d'hôte faible activé, l'hôte A peut recevoir les types de paquets suivants (en supposant que les règles du pare-feu d'hôte permettent le trafic entrant) : des paquets vers 131.107.89.211 sur son interface Internet, des paquets vers 192.168.17.48 sur son interface Internet, des paquets vers 131.107.89.211 sur son interface intranet et des paquets vers 192.168.17.48 sur son interface intranet.

Lorsque le comportement de réception d'hôte faible est activé, un utilisateur malveillant sur Internet peut envoyer des paquets vers l'interface Internet de l'hôte A pour attaquer des services s'exécutant sur l'hôte A qui sont uniquement accessibles aux hôtes sur l'intranet. Ce type d'attaque peut survenir si l'infrastructure Internet prend en charge le transfert des paquets destinés à 192.168.17.48 vers l'interface Internet de l'hôte A. Vous pouvez empêcher ce type d'attaque en paramétrant des règles de pare-feu appropriées sur l'interface Internet de l'hôte A. Cependant, même si vous le faites, les services s'exécutant sur l'hôte A qui sont disponibles aux clients de l'intranet peuvent courir un risque.

Modèle d'hôte fort

Dans le modèle d'hôte fort, les comportements d'envoi et de réception sont différents. Avec l'envoi d'hôte fort, l'hôte peut uniquement envoyer des paquets sur une interface à laquelle l'adresse IP source du paquet en cours d'envoi est attribuée. Avec la réception d'hôte fort, l'hôte peut uniquement recevoir des paquets sur une interface à laquelle l'adresse IP source du paquet en cours de réception est attribuée.

Lorsque le comportement d'envoi d'hôte fort est activé sur ses interfaces Internet et intranet, l'hôte A de la figure 1 peut uniquement envoyer des paquets provenant de 131.107.89.211 sur son interface Internet, et provenant de 192.168.17.48 sur son interface intranet.

Lorsque le comportement de réception d'hôte fort est activé, l'hôte A peut uniquement recevoir des paquets à l'adresse 131.107.89.211 sur son interface Internet et à l'adresse 192.168.17.48 sur son interface intranet.

Dans la figure 1, le modèle d'hôte fort pour l'hôte A dépose tous les paquets entrants sur l'interface Internet qui sont adressées à 192.168.17.48 sans que vous ayez besoin de configurer des règles du pare-feu, isolant ainsi efficacement l'interface intranet de l'hôte A d'Internet.

Si vous choisissez le modèle d'hôte fort, gardez à l'esprit qu'il pourrait affecter certains types de connectivité conçus pour le comportement d'hôte faible. Par exemple, certaines implémentations d'équilibrage de charge peuvent utiliser le comportement de réception d'hôte faible pour recevoir des paquets sur n'importe quelle interface avant de les router de façon interne vers l'interface appropriée. Un hôte qui utilise l'envoi d'hôte faible pour envoyer le trafic à partir de n'importe quelle adresse source vers une interface correspondant à une connexion rapide peut également être affecté.

Envoi et réception d'hôte fort

Voyons maintenant le fonctionnement du processus d'envoi et de réception sur hôte générique pour IPv4 ou IPv6 lorsque vous autorisez l'activation et la désactivation de l'envoi et de la réception d'hôte fort en fonction de l'interface.

Pour les paquets en cours d'envoi, l'IP vérifie d'abord si une adresse source a déjà été spécifiée. Si ce n'est pas le cas, l'IP effectue une recherche non limitée de l'adresse de destination du paquet dans la table de routage. Dans une recherche non limitée, tous les itinéraires de la table de routage sont considérés. Selon l'itinéraire sélectionné pour la destination, l'IP détermine l'interface du saut suivant (l'interface utilisée pour placer le paquet sur la couche de laison) et l'adresse du saut suivant. Selon l'interface du saut suivant, l'IP utilise la procédure de sélection d'adresse définie dans RFC 3484 en fonction des besoins pour déterminer la meilleure adresse source. À ce stade, l'IP possède toutes les informations dont il a besoin pour envoyer le paquet : les adresses de source et de destination, l'interface du saut suivant et l'adresse du saut suivant.

Si l'adresse source a été spécifiée, l'interface source est connue. L'adresse source est attribuée à l'interface source. L'IP détermine ensuite si l'envoi d'hôte fort est activé sur l'interface source.

S'il est désactivé, l'IP effectue une recherche non limitée de l'adresse de destination du paquet dans la table de routage. Selon le meilleur itinéraire correspondant à la destination, l'IP détermine l'interface du saut suivant et l'adresse du saut suivant. L'IP dispose des adresses de source et de destination, de l'interface du saut suivant et de l'adresse du saut suivant. Notez que lorsque le comportement d'envoi d'hôte fort est désactivé sur l'interface source, il est possible que l'interface du saut suivant ne soit pas identique à l'interface source.

Si l'envoi d'hôte fort est activé sur l'interface source, l'IP effectue une recherche limitée de l'adresse de destination du paquet dans la table de routage. Dans une recherche limitée, seuls les itinéraires avec une interface de saut suivant de l'interface source sont considérés. Selon l'itinéraire sélectionné pour la destination, l'IP détermine l'adresse du saut suivant. L'IP dispose des adresses de source et de destination, de l'interface du saut suivant et de l'adresse du saut suivant. Notez que lorsque le comportement d'envoi d'hôte fort est activé sur l'interface source, l'interface du saut suivant est toujours identique à l'interface source. La figure 2 illustre le processus générique d'envoi IP par un hôte.

Figure 2** Processus générique d'envoi IP par un hôte **(Cliquer sur l'image pour l'agrandir)

Lorsque l'adresse source a été spécifiée, la recherche d'itinéraire limitée peut sélectionner un itinéraire avec une métrique plus élevée parmi les différents itinéraires de la table de routage qui correspondent le mieux à la destination. Par exemple, l'hôte A de la figure 1 possède deux itinéraires par défaut ; l'un pointe vers Internet avec une métrique de 10 et un autre point vers l'intranet avec une métrique de 20. Le comportement d'hôte fort est activé sur les deux interfaces de réseau local.

Si l'application d'envoi de l'hôte A ne spécifie pas d'adresse source, le résultat de la recherche d'itinéraire est l'itinéraire par défaut avec la métrique la plus faible ; l'hôte A envoie toujours le trafic depuis l'interface Internet avec l'adresse source 131.107.89.211. Cependant, si l'application d'envoi de l'hôte A spécifie une adresse source de 131.107.89.211, le résultat de la recherche est l'itinéraire par défaut pour l'interface Internet ; l'hôte A envoie le trafic depuis l'interface Internet. Si l'application d'envoi de l'hôte A spécifie une adresse source de 192.168.17.48, la recherche sélectionne l'itinéraire par défaut pour l'interface de l'intranet ; l'hôte A envoie le trafic depuis l'interface d'intranet. Avec la recherche d'itinéraire limitée, l'IP envoie le trafic avec une adresse source de 192.168.17.48 en utilisant l'itinéraire par défaut avec la métrique la plus élevée.

Pour le trafic reçu, l'IP détermine d'abord si le trafic est destiné à l'hôte. Sinon, l'IP rejette silencieusement le paquet parce que l'hôte ne sert pas de routeur. L'IP détermine ensuite si la réception d'hôte fort est activée sur l'interface entrante (l'interface sur laquelle le paquet a été reçu). Si elle est désactivée, l'IP traite le paquet. Si elle est activée, l'IP détermine si l'adresse de destination du paquet est attribuée à l'interface entrante. Si oui, l'IP traite le paquet. Sinon, l'IP rejette silencieusement le paquet. La figure 3 illustre le processus générique de réception par un hôte.

Figure 3** Processus de réception par un hôte **

Comportement d'hôte faible et fort dans Windows

Windows XP et Windows Server® 2003 utilisent le modèle d'hôte faible pour l'envoi et la réception pour toutes les interfaces IPv4, et le modèle d'hôte fort pour l'envoi et la réception pour toutes les interfaces IPv6. Vous ne pouvez pas configurer ce comportement. La pile TCP/IP nouvelle génération de Windows Vista et Windows Server 2008 prend en charge par défaut l'envoi et la réception d'hôte fort pour IPv4 et IPv6 sur toutes les interfaces, à part l'interface de tunnel Teredo pour un relais Teredo spécifique à l'hôte. La figure 4 répertorie les commandes que vous pouvez utiliser pour configurer le comportement d'envoi et de réception à la fois pour IPv4 et IPv6, interface par interface. Notez que InterfaceNameOrIndex est soit le nom de l'interface du dossier Connexions réseau, soit son index d'interface. Vous pouvez obtenir l'index d'interface d'une interface à partir de l'affichage de la commande :

Figure 4 Commandes permettant de configurer les comportements d'envoi et de réception fort et faible

netsh interface ipv6 show interface

Comportement d'hôte faible et fort et RFC 3484

Afin de fournir une méthode standardisée pour la sélection des adresses IPv6 et IPv4 de source et de destination avec lesquelles tenter des connexions, RFC 3484 définit deux algorithmes. Le premier est un algorithme de sélection d'adresse source pour choisir la meilleure adresse source à utiliser avec une adresse de destination. L'autre est un algorithme de sélection d'adresse de destination pour trier la liste des adresses de destination possibles par ordre de préférence.

Le comportement d'hôte fort et faible entre en scène lorsque l'hôte détermine la liste des adresses source candidates pour une adresse de destination donnée, et ceci affecte également la liste finale triée des adresses de destination. Pour le comportement d'envoi d'hôte fort, la liste des adresses source candidates est constituée d'adresses monodiffusion attribuées à l'interface d'envoi pour la destination. Pour le comportement d'envoi d'hôte faible, la liste des candidats peut inclure des adresses attribuées à n'importe quelle interface dont l'envoi d'hôte faible est activé. Pour plus d'informations de la sélection des adresses de source et de destination, veuillez consulter l'article de la page microsoft.com/technet/community/columns/cableguy/cg0206.mspx.

Par défaut, l'envoi et la réception d'hôte faible sont désactivés pour IPv4 et IPv6 pour toutes les interfaces sauf l'interface de tunnel Teredo pour un relais Teredo spécifique à l'hôte.

Pour plus d'informations sur RFC 3484, reportez-vous à l'encadré « Comportement d'hôte faible et fort et RFC 3484. »

Désactivation des itinéraires par défaut pour les connexions VPN d'accès distant

Un client de réseau privé virtuel (VPN) d'accès distant constitue un autre exemple d'hôte multirésident. Bien qu'il puisse n'avoir qu'une seule interface LAN connectée à Internet, lorsqu'un client VPN d'accès distant établit une connexion VPN, il est multirésident. Il possède deux interfaces : son interface LAN et une interface basée sur le protocole PPP (Point-to-Point Protocol) pour la connexion VPN. Il possège également deux adresses IPv4 : une adresse IPv4 attribuée par le fournisseur d'accès Internet pour l'interface de réseau local, et une autre adresse IPv4 attribuée par le serveur VPN pour l'interface PPP.

Pour s'assurer que le client VPN envoie le trafic d'itinéraire par défaut via la connexion VPN à l'intranet, Windows XP et Windows Server 2003 modifient la table de routage IPv4 en augmentant la métrique de l'itinéraire par défaut et en ajoutant un nouvel itinéraire par défaut avec une métrique inférieure qui utilise l'interface PPP. Ce comportement par défaut donne accès aux emplacements sur l'intranet et rend presque tous les emplacements sur Internet inaccessibles pendant la connexion VPN. Pour disposer d'un accès simultané aux emplacements Internet et intranet, il est possible de configurer un client VPN pour la tunnellisation fractionnée en n'ajoutant pas l'itinéraire par défaut pour la connexion VPN et en ajoutant des itinéraires spécifiques pour les destinations intranet. Cependant, il existe un risque que les clients VPN à tunnelisation fractionnée puissent router des paquets entre Internet et l'intranet. Pour plus d'informations, consultez l'article de la page microsoft.com/technet/community/columns/cableguy/cg1003.mspx.

Le comportement par défaut du client VPN sous Windows XP et Windows Server 2003 a été conçu pour un comportement d'envoi d'hôte faible. La recherche d'itinéraire utilise toujours l'itinéraire par défaut pour la connexion VPN parce qu'il possède la métrique la plus faible. Cependant, lorsque vous utilisez le comportement d'envoi d'hôte fort, l'itinéraire par défaut utilisé pour le trafic envoyé dépend de l'adresse IP source du paquet. La recherche d'itinéraire pour le trafic provenant de l'adresse IPv4 attribuée par le FAI utilisera l'itinéraire par défaut qui utilise l'interface de réseau local, rendant accessibles tous les emplacements Internet. La recherche d'itinéraire pour le trafic provenant de l'adresse IPv4 attribuée par le serveur VPN utilisera l'itinéraire par défaut qui utilise l'interface PPP, rendant accessibles tous les emplacements intranet. Par conséquent, lorsque vous utilisez le comportement d'envoi d'hôte fort, le client VPN possède une configuration de tunnelisation fractionnée et dispose d'un accès simultané à Internet et à l'intranet, même pour les applications qui n'ont pas de privilèges de niveau administrateur pour modifier directement la table de routage IPv4.

Pour empêcher le comportement d'envoi d'hôte fort de créer par défaut une configuration de tunnelisation fractionnée, le client VPN de Windows Vista® et Windows Server 2008 désactive automatiquement les itinéraires par défaut des interfaces de réseau local lorsque la connexion VPN est établie. Ce comportement garantit qu'il n'existe qu'un itinéraire par défaut actif dans la table de routage qui utilise l'interface PPP. Ce comportement garantit également que les applications sans privilèges de niveau administrateur ne peuvent pas exécuter une tunnelisation fractionnée.

Même si le trafic provenant de l'ordinateur client VPN doit provenir de l'adresse IPv4 attribuée par le serveur VPN, ce comportement fournit une meilleure isolation de l'intranet contre Internet. Lorsque la connexion VPN est terminée, les itinéraires par défaut désactivés sont activés.

Vous pouvez contrôler ce comportement par défaut avec la commande :

netsh interface ipv4 set interface [InterfaceNameOrIndex]
ignoredefaultroutes=enabled|disabled

Joseph Daviesest rédacteur technique chez Microsoft. Il enseigne et rédige des articles sur les questions relatives aux réseaux Windows depuis 1992. Il a écrit cinq livres pour Microsoft Press et est l'auteur de la chronique en ligne mensuelle Le petit câbleur de TechNet.

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