Internet Data Center : Conception de pare-feu
Sur cette page
.gif){kind=icon}
Microsoft Internet Data Center : Conception de pare-feu
Résumé
Introduction
Aperçu des pare-feu Internet Data Center
Flux TCP/IP élémentaire
Méthodes de filtrage de ISA Server
Filtres de paquets
Filtrage par inspection d'état
Filtrage de couche Application
Pare-feu périphérique et Conception de mise en cache
Configuration de ISA Server
Configuration matérielle requise
Service packs et correctifs à chaud
Multiconnexion
Itinéraires statiques
Configuration de la LAT
Publication Web
Équilibrage de charge et DNS cyclique
Contrôle des requêtes entrantes
Configuration SSL
Mise en cache inversée
Publication de serveur
Configuration IP
Clients NAT sécurisés pour la Publication de serveur
Sécurisation des pare-feu périphériques de ISA Server
Conception du pare-feu interne
Exigences de base
Exigences de trafic
Configuration des ports RPC Windows 2000
Exigences de conception de ISA Server
Configuration réseau
Trafic de publication de domaine à travers ISA
Désactivation de NetBIOS
Conception du service DNS
Conception du pare-feu de VPN
Adresses IP
Configuration de ISA Server
Assistant VPN ISA
Filtres de paquets
Configuration du service RRAS
Protocoles de VPN
Services de certificats
Configuration du serveur RRAS
Stratégie d'accès à distance
Journalisation de l'accès à distance
Conception de pare-feu à haute-disponibilité
Utilisation du service d'équilibrage de charge réseau avec ISA Server
Règles de port
Solutions de tierces parties
Résumé
Microsoft Internet Data Center : Conception de pare-feu
Cet article est tiré du Guide de référence Internet Data Center
Résumé
Ce chapitre décrit la conception de pare-feu Microsoft® Internet Data Center. Il fournit un aperçu des pare-feu et des aspects génériques relatifs à leur conception, ainsi que des détails sur les trois types de pare-feu utilisés dans l'architecture Internet Data Center : pare-feu périphérique, pare-feu interne et pare-feu de VPN. Il discute de la configuration de Microsoft ISA Server (Internet Security and Acceleration Server) pour les services de pare-feu et de mise en cache Web, y compris les implémentations de pare-feu à haute disponibilité grâce au service d'équilibrage de charge réseau ou à des solutions tierces.
Introduction
Un pare-feu est un mécanisme de contrôle du flux de données entre deux parties d'un réseau bénéficiant de niveaux d'approbation différents. Il existe de nombreuses façons d'utiliser les pare-feu pour aider à sécuriser un site Internet. Ils peuvent être placés devant ou derrière la ferme Web, ou une connexion supplémentaire peut être créée sur le pare-feu et les serveurs Web peuvent être placés sur ce réseau. La décision quant à l'utilisation des pare-feu dans la conception de réseau finale dépendra des exigences en matière d'application, de gestion et de disponibilité.
La conception Microsoft® Internet Data Center implémente des pare-feu redondants afin d'accroître la rapidité et la fiabilité des communications et de conserver une haute disponibilité dans une configuration de basculement.
Aperçu des pare-feu Internet Data Center
Les exigences d'application et de gestion de l'architecture Internet Data Center veulent que les serveurs placés dans le réseau de la DMZ soient multiconnectés. Pour cette raison, plusieurs pare-feu sont placés devant et derrière les serveurs d'application et les serveurs Web, créant ainsi un réseau de DMZ et apportant une protection supérieure aux serveurs du réseau interne. Pour finir, un ensemble de pare-feu est placé sur le VLAN de données et de gestion afin de satisfaire au besoin d'un point d'accès VPN sécurisé. Ceci veut dire que des pare-feu sont placés dans trois zones différentes de l'architecture Internet Data Center, comme illustré en Figure 1. Le premier pare-feu, placé devant les serveurs qui font face à Internet, est nommé "pare-feu périphérique" ou "pare-feu Internet". Le pare-feu suivant est installé derrière les serveurs qui font face à Internet ; on l'appelle "pare-feu interne". Le troisième pare-feu, le "pare-feu de VPN", donne accès au VPN et est installé sur le réseau de données et de gestion.
Le pare-feu périphérique et le commutateur créent la zone démilitarisée, ou VLAN de DMZ, et renforcent la protection en contrôlant le trafic en provenance d'Internet et le trafic entre les serveurs de ce VLAN. Le pare-feu interne inspecte le trafic entre les serveurs de la DMZ et les systèmes principaux et d'infrastructure. Le pare-feu de VPN gère les exigences de communication à distance pour la gestion à distance et toute application requise dans le cadre du développement du site Web. Une solution de pare-feu entièrement redondante est implémentée dans l'architecture, afin de garantir une haute disponibilité. La figure suivante montre l'implémentation des pare-feu Internet Data Center.
.gif)
Figure 1. Placement des pare-feu dans l'architecture Internet Data Center
Chacun des trois pare-feu est décrit en détail dans ce chapitre. La dernière section décrit quant à elle les options disponibles pour atteindre une haute disponibilité.
L'architecture Internet Data Center autorise l'utilisation de Microsoft ISA Server ou toute autre solution de pare-feu tierce pour les trois pare-feu. Pour démontrer la flexibilité de l'architecture Internet Data Center, le laboratoire Internet Data Center a utilisé ISA Server pour le pare-feu périphérique et le pare-feu de VPN, et un produit matériel tiers pour le pare-feu interne. Toute solution de pare-feu utilisée dans Internet Data Center doit au moins prendre en charge les couches ou méthodes de filtrage suivantes : filtrage de paquets, inspection d'état et filtrage au niveau application. Vous trouverez plus loin dans ce chapitre des détails sur l'implémentation de ces couches dans ISA Server.
Flux TCP/IP élémentaire
Cette section décrit comment TCP/IP empaquète ses informations, afin de montrer comment les pare-feu gèrent le trafic de manière sécurisé. Le filtrage de paquets est fondé sur des informations contenues dans les paquets TCP/IP. La figure suivante montre la composition élémentaire d'un paquet IP, avec les trois sections clés (en-tête IP, en-tête TCP ou UDP, et contenu du paquet). (L'utilisation de TCP ou de UDP dépend du protocole de niveau application : HTPP, par exemple, utilise TCP.) L'en-tête IP contient les adresses IP de la source (expéditeur) et de la destination (destinataire). L'en-tête TCP ou UDP contient le port source de l'expéditeur et le port de destination du destinataire, ainsi que d'autres informations telles que les numéros de séquence, les numéros d'accusés de réception et l'état de la conversation. Les ports TCP ou UDP de destination définissent les emplacements de livraison des données sur le serveur une fois le paquet arrivé à destination. Le port source est le port duquel l'expéditeur envoie le paquet, et également le port auquel répond le serveur de destination lors de la conversation. Le port de destination est le port à partir duquel le serveur de destination écoute et répond aux requêtes de l'expéditeur.
.gif)
Figure 2. Structure d'un paquet IP
Il est important de comprendre le flux de communication d'une conversation TCP/IP lorsque l'on configure un pare-feu. Lorsqu'un navigateur (par exemple) envoie une requête HTTP à un serveur Web, cette requête contient l'identité de l'ordinateur client, l'adresse IP source et le port source duquel la requête a été envoyée. Ce port est aussi celui sur lequel le client recevra une réponse du serveur Web. Le port source pour un client de ce type est généralement une valeur supérieure à 1024 (c'est-à-dire en dehors de la plage de ports TCP bien connue). De plus, la requête du client contient l'adresse IP de destination et le port de destination du serveur Web, dans ce cas le port 80, le port HTTP standard.
Méthodes de filtrage de ISA Server
ISA Server prend en charge trois couches de filtrage, pour une sécurité totale : le filtrage de paquets, l'inspection d'état et le filtrage au niveau application. Par défaut, ISA Server bloque tout trafic entrant sur son interface externe et ne laisse passer aucune donnée, à moins que des règles ne soient créées à cet effet. Les sections suivantes décrivent les trois couches de filtrage prises en charge par ISA Server.
Filtres de paquets
Le filtrage de paquets est le processus d'ouverture statique de certains ports ICMP, TCP ou UDP sur l'interface externe du pare-feu et la détermination de leur routage interne. Dans l'architecture Internet Data Center, des filtres de paquets sont implémentés si une application, telle que DNS, est installée directement sur l'ordinateur ISA Server. Si un segment de réseau supplémentaire est créé sur l'ordinateur ISA Server et que DNS est placé sur ce segment, un filtre est créé afin d'autoriser tout le trafic entrant sur le port UDP 53 (requête DNS) à destination de l'ordinateur ISA Server. La présence d'un filtre peut également aider à la résolution des problèmes relatifs à l'ordinateur ISA Server. Par défaut, ISA Server ne répond pas aux requêtes ping sur son interface externe. Pour que l'ordinateur ISA Server réponde aux requêtes ping, un filtre de paquets doit être créé. Les principaux attributs TCP/IP utilisés pour l'implémentation des règles de filtrage sont les suivants :
Adresses IP sources
Adresses IP de destination
Protocole IP
Ports TCP et UDP sources
Ports TCP et UDP de destination
L'interface où arrive le paquet
L'interface à laquelle le paquet doit être délivré
Filtrage par inspection d'état
L'inspection d'état consiste à inspecter les paquets lors de leur arrivée au pare-feu et à maintenir l'état de la connexion en autorisant ou en interdisant aux paquets de passer, en fonction de la stratégie d'accès définie. Pour mieux comprendre comment l'état est maintenu, examinons la figure suivante. Celle-ci illustre une conversation entre un client et un serveur à travers un ordinateur ISA Server. Dans ce scénario, la Publication Web a été configurée sur l'ordinateur ISA Server de façon à prendre en charge la redirection des requêtes Internet externes sur le port 80 vers le serveur IIS interne.
.gif)
Figure 3. Exemple de conversation à travers ISA Server
Voici le déroulement de la conversation :
Le client Internet initie une requête HTTP au serveur Web et envoie un paquet IP avec l'adresse et les ports sources et de destination.
L'ordinateur ISA Server reçoit la requête pour le serveur Web.
ISA Server modifie alors le paquet (il remplace l'adresse et le port sources par sa propre adresse interne) et définie l'adresse IP de destination sur l'adresse du vrai serveur IIS.
ISA Server ajoute les adresses et ports sources et de destination à sa propre table, afin d'effectuer le suivi de la conversation.
ISA Server envoie le paquet modifié au serveur IIS interne.
Le serveur IIS répond à la requête en utilisant ISA Server comme adresse de destination et le port TCP 5300.
ISA Server reçoit le paquet en provenance du serveur IIS et recherche 5300 dans sa table, ce qui correspond au client Internet.
ISA Server modifie ensuite le paquet et remplace le port et l'adresse IP sources du serveur IIS par ses propres port et adresse IP sources.
ISA Serve définit ensuite l'adresse IP et le port TCP de destination sur ceux du client Internet.
Le client Internet reste à l'écoute d'une réponse sur le port 5100.
En plus de maintenir la conversation TCP ou UDP en fonction des adresses IP et des ports, ISA Server vérifie également les indicateurs TCP et les numéros de séquence et d'accusés de réception dans les champs d'en-tête TCP, pour les conversations TCP. Les indicateurs représentent les différents états de la conversation, à savoir le début de la conversation (SYN), le milieu de la conversation (ACK), ou la fin de la conversation (FIN). Si l'un ou plusieurs des indicateurs sont mal ordonnés, ISA Server bloque la connexion. Les champs de séquence et d'accusés de réception fournissent les informations permettant de s'assurer que le paquet suivant reçu lors de la conversation est le bon. Là encore, toute requête ne correspondant pas à l'état de la conversation est bloquée.
Filtrage de couche Application
ISA Server est aussi un proxy de niveau application capable de lire les données des paquets destinés à une application spécifique et d'exécuter une action fondée sur un ensemble de règles. De plus, il contient des filtres d'application prédéfinis qui inspectent chaque paquet et en bloquent, redirigent ou modifient les données. Des règles de routage Web peuvent par exemple être implémentées afin que le serveur ISA redirige une requête HTTP vers un serveur IIS interne donné, en fonction de l'URL contenu dans le paquet. Le filtre de détection d'intrusion DNS constitue un autre exemple. Ce filtre bloque les paquets qui ne sont pas des requêtes DNS valides ou qui correspondent à certains types communs d'attaques DNS. Le filtrage d'application peut être invoqué sur ISA Server lorsque la Publication Web ou la Publication de serveur est configurée.
Pare-feu périphérique et Conception de mise en cache
Microsoft ISA Server 2000, tel qu'utilisé dans l'environnement Internet Data Center, offre deux fonctions Internet clés : la sécurité à base de pare-feu (tel que décrite plus haut) et des services de mise en cache Web. Le cache Web stocke les pages fréquemment consultées, ce qui améliore les performances du réseau et les temps de réponse pour les utilisateurs. Ces deux fonctions peuvent être implémentées sur le même serveur, ou placées sur des serveurs de pare-feu et de mise en cache dédiés.
Pour les ordinateurs ISA Server périphériques, le service d'équilibrage de charge réseau est utilisé pour configurer l'équilibrage de charge sur les interfaces externes à partir d'Internet (pour plus de détails, voir "Conception de pare-feu à haute disponibilité" plus loin dans ce chapitre). Les serveurs IIS de Publication Web tirent parti de cette configuration, dans laquelle l'adresse IP virtuelle peut être utilisée. Les ordinateurs ISA Server périphériques utilisent une configuration nommée "Publication de serveur" pour prendre en charge les applications autres que IIS, telles que le DNS externe. DNS ne pouvant à l'heure actuelle pas tirer parti du service d'équilibrage de charge réseau, les serveurs DNS sont configurés comme DNS cyclique afin d'apporter une redondance à ces services d'application.
Deux ordinateurs ISA Server sont déployés sur le réseau périphérique de l'architecture Internet Data Center, afin de bénéficier d'une fonctionnalité de pare-feu à inspection d'état et d'une mise en cache et d'un proxy d'application transparents. Lorsque ISA Server est déployé sur le réseau périphérique, tout le trafic Internet entrant est analysé et traité selon un ensemble de règles dans le cadre d'une solution hautement évolutive et à tolérance de pannes. La fonctionnalité Publication Web est implémentée pour les serveurs IIS afin de prendre en charge le trafic HTTP et HTTPS. La fonctionnalité Publication de serveur est implémentée afin de prendre en charge le trafic DNS externe. Les sections suivantes discute de l'implémentation Internet Data Center pour les solutions Publication Web et Publication de serveur sur le réseau périphérique.
Configuration de ISA Server
Les deux ordinateurs ISA Server sont configurés en mode autonome. Cette configuration signifie qu'il n'est pas nécessaire de disposer de serveurs supplémentaires si votre implémentation de l'architecture Internet Data Center prend en charge les domaines multiples. La configuration des deux serveurs ne diffère que légèrement ; la principale différence concerne les règles de Publication de serveur, car les adresses IP externes sont différentes. (Pour plus de détails, voir "Publication de serveur" plus loin dans ce chapitre.) En mode autonome, la stratégie est locale au serveur et ne peut pas être partagée par plusieurs ordinateurs ISA Server. La stratégie est stockée dans le Registre du serveur local. Les modifications doivent être apportées indépendamment aux deux ordinateurs ISA Server. Ces étapes peuvent être simplifiées, car chaque élément de stratégie peut être défini par un script à l'aide du système de développement Microsoft Visual Basic® ou du logiciel de développement Microsoft JScript® afin de tester ou de dupliquer rapidement une nouvelle configuration.
Chaque ordinateur ISA Server est configuré pour le mode intégré, afin de prendre en charge les architectures de mise en cache et de pare-feu. La mise en cache inversée offre de meilleurs temps de réponse pour les clients Internet et réduit le trafic réseau.
Configuration matérielle requise
Pour une solution haut de gamme, la configuration matérielle recommandée pour les ordinateurs ISA Server périphériques est la suivante. Chaque ordinateurs ISA Server déployé dans le périmètre gère les règles de pare-feu, implémente la mise en cache inversée pour les clients Internet et décharge SSL (Secure Sockets Layer) des serveurs IIS. Si l'on se base sur le rôle de l'ordinateur ISA Server, un serveur haut de gamme doit bénéficier au moins de la configuration suivante :
2 processeurs
2 gigaoctets (Go) de RAM
1 jeu de lecteurs mis en miroir afin de prendre en charge le système d'exploitation et la mise en cache, ou un second jeu de lecteurs mis en miroir pour prendre en charge uniquement la mise en cache (pour des performances accrues)
Plusieurs cartes Ethernet 100 Mo Duplex intégral (selon la configuration du réseau)
Service packs et correctifs à chaud
Avant de configurer les ordinateurs ISA Server, le Service pack le plus récent et tous les correctifs à chaud importants parus après le Service pack et disponibles pour le système d'exploitation doivent être appliqués à chaque serveur.
Remarque : Les correctifs à chaud pour ISA Server doivent être appliqués une fois l'installation de ISA Server terminée sur chaque serveur.
Multiconnexion
Tous les ordinateurs ISA Server sont multiconnectés. La carte réseau externe est reliée directement aux routeurs qui font face à Internet, et les cartes réseau internes sont reliées au VLAN interne, ce qui permet à ISA Server de contacter les serveurs de la DMZ avec des adresses privées. (Voir Figure 4.)Plusieurs VLAN sont créés dans la DMZ, avec les cartes réseau internes de ISA Server et les serveurs de Publication de serveur (tels que les serveurs DNS externes) tous regroupés sur le même VLAN 21. Les fermes de serveurs IIS sont sur les VLAN 22 et 23.
.gif)
Figure 4. Multiconnexion ISA Server et configuration des VLAN
Remarque : Par souci de clarté, la nature redondante de toutes les connexions réseau n'a pas été représentée dans les figures de ce chapitre.
Itinéraires statiques
Dans l'environnement Internet Data Center, la passerelle par défaut du routeur qui fait face à Internet est affectée aux cartes réseau qui font face à Internet. La carte réseau interne de chaque ordinateur ISA Server exige des itinéraires statiques permanents. Un itinéraire statique est créé pour les VLAN 22 et 23. Une fois ces itinéraires implémentés, les deux ordinateurs ISA Server peuvent exécuter une commande ping sur les serveurs des autres VLAN. La passerelle utilisée pour l'adressage interne de l'ordinateur ISA Server est le composant routeur du commutateur, défini pour chaque VLAN. La passerelle pour VLAN 21 a été définie sur 192.168.21.253.
Configuration de la LAT
Avant de pouvoir configurer des règles de pare-feu, l'ordinateur ISA Server doit être capable de détecter l'interface reliée à Internet public et celle reliée aux réseaux privés, y compris tous les réseaux privés internes avec lesquels l'ordinateur ISA Server a besoin de communiquer. Toutes ces informations sont maintenues dans la Table d'adresses locales (LAT, Local Address Table) de ISA Server. La configuration de la LAT indique à l'ordinateur ISA Server l'emplacement de tous les réseaux internes. Dans une implémentation à deux cartes réseau, lorsque l'une des cartes est désignée comme privée d'après les informations de la LAT, l'autre est considérée comme publique. ISA Server peut créer automatiquement la LAT en fonction des informations contenues dans la table de routage de Microsoft Windows® 2000, ou bien les réseaux peuvent être ajoutés manuellement. Dans l'architecture Internet Data Center, une entrée pour chaque VLAN de la figure ci-dessus (192.168.21.0, 192.168.22.0 et 192.168.23.0) est ajoutée manuellement.
Publication Web
La Publication Web permet aux ordinateurs ISA Server périphériques de se faire passer pour des serveurs Web internes aux yeux du monde extérieur. Ceci constitue un mécanisme de sécurité très fiable pour le contrôle des requêtes Web entrantes. De plus, les mécanismes de mise en cache transparents de ISA Server peuvent mettre en cache de manière active les objets fréquemment demandés, ce qui permet d'améliorer les performances et de réduire le trafic sur le réseau de la DMZ.
Lorsque la Publication Web est implémentée, les requêtes de services Web envoyées par des clients externes sont dirigées, via des entrées DNS externes, vers l'adresse IP virtuelle externe de la ferme de serveurs ISA Server à charge équilibrée. Ces requêtes sont ensuite traitées par ISA Server en fonction des règles de Publication Web, puis redirigées vers la ferme de serveurs Web internes appropriée. Ces règles sont composées d'éléments de stratégie parmi lesquels :
Ensembles de destination. Pour la Publication Web, un ensemble de destination est généralement le nom de domaine contenu dans un URL dont l'adresse IP est l'adresse externe de l'ordinateur ISA Server. La redirection d'URL avancée peut être implémentée grâce à la fonctionnalité de chemin d'accès des ensembles de destination. La batterie d'ordinateurs ISA Server périphériques peut être configurée de façon à publier le contenu Web en le répartissant sur différents serveurs Web ou fermes de serveurs Web à charge équilibrée.
Actions. Les actions déterminent la manière dont ISA Server traite les requêtes des clients externes pour une destination particulière. ISA Server peut ignorer la requête ou la rediriger vers un serveur Web interne. De plus, ISA Server peut traduire les ports lors de la connexion aux ressources FTP, SSL ou HTTP internes, et passer des informations d'en-tête d'hôte. ISA Server peut rediriger ces requêtes en fonction de l'adresse IP ou du nom de domaine complet.
Pontage. ISA Server peut rediriger les requêtes HTTP et SSL comme requêtes HTTP, SSL ou FTP, et peut exiger un canal sécurisé pour le site publié. ISA Server jouant le rôle de proxy pour les requêtes SSL publiées, un certificat valide doit être installé sur l'ordinateur ISA Server.
Pontage SSL. ISA Server offrant une réelle solution de proxy d'application, des considérations spéciales doivent être prises en compte lors de l'implémentation du trafic basé sur certificats. ISA Server possède une fonctionnalité intégrée de prise en charge du pontage SSL. SSL permet à ISA Server de crypter et de décoder une requête d'un client, et de la transmettre à un serveur Web de destination. Ceci nécessite l'installation de certificats appropriés sur l'ordinateur ISA Server.
Pontage d'en-tête d'hôte. Lorsque plusieurs sites Web sont publiés à partir d'une seule adresse IP sur un serveur Web interne, les règles de Publication Web sur la batterie de serveurs ISA Server périphériques peut être configurée pour envoyer les informations d'en-tête d'hôte d'origine.
Ensembles de clients. Les adresses des clients Internet externes peuvent être configurées pour autoriser ou refuser l'accès à la ferme de serveurs Web. Lorsque les ensembles de clients ne sont pas implémentés pour la Publication Web dans la conception Internet Data Center, tous les clients Internet ont accès aux fermes de serveurs Web.
Équilibrage de charge et DNS cyclique
Avant la création des règles de Publication Web, les ordinateurs ISA Server et les serveurs Web IIS doivent être configurés pour l'équilibrage de charge. L'équilibrage de charge réseau est installé et configuré sur l'interface externe des deux serveurs ISA Server périphériques, afin de bénéficier d'une solution redondante. De plus, les serveurs IIS internes sont regroupés en deux clusters d'équilibrage de charge réseau différents, chacun affecté d'une adresse IP virtuelle interne. Pour plus d'informations sur l'implémentation de l'équilibrage de charge réseau dans l'architecture Internet Data Center, voir "Conception de l'équilibrage de charge réseau" dans le Chapitre 2, "Conception de l'infrastructure réseau". Deux adresses IP virtuelles sont créées pour la connexion au serveur ISA Server externe, et ces deux adresses sont enregistrées dans le serveur DNS externe sous le même nom d'URL pour prendre en charge le DNS cyclique. La figure suivante illustre cette configuration :
.gif)
Figure 5. Configuration de l'équilibrage de charge de ISA Server
Pour la conception de Internet Data Center, l'objectif de la configuration des règles de Publication Web était de mapper chaque adresse IP virtuelle à chacun des clusters Web internes, de manière à ce que ISA Server redirige la requête du client vers l'un des clusters de serveurs Web internes lorsque le client Internet accède à l'une des entrées DNS, selon l'adresse externe utilisée. Pour configurer cela, deux ensembles de destination ont été créés pour chaque adresse IP virtuelle dans ISA Server. Ensuite, deux règles de Publication Web ont été créées afin de mapper chaque ensemble de destination à chaque adresse IP virtuelle de cluster Web. En gros, la configuration permet l'exécution des événements suivants :
Le client Internet envoie une requête DNS pour le nom de domaine du site et reçoit une adresse IP (par exemple 208.217.184.182).
client envoie une requête IP avec l'adresse et le port de destination : 208.217.184.182:80.
Server reçoit la requête et vérifie la règle de Publication Web dont l'ensemble de destination est 208.217.184.182, puis transmet la requête au cluster IIS 192.168.22.20.
La requête de client Internet suivante arrive sur 208.217.184.183:80.
Server vérifie la règle de Publication Web pour 208.217.184.183, et redirige la requête vers le cluster IIS 192.168.23.21.
Contrôle des requêtes entrantes
Les requêtes Web entrantes sont configurées en installant des écouteurs sur l'interface réseau externe des ordinateurs ISA Server. L'écouteur indique à ISA Server quelles adresses IP externes surveiller et quel trafic HTTP et HTTPS entrant accepter. Chaque ordinateur ISA Server à charge équilibrée est configuré pour utiliser des adresses IP individuelles, et reste à l'écoute (sur le port 80) de chacune des adresses IP définies dans la boîte de dialogue de requête Web entrante. Les deux ordinateurs ISA Server sont configurés pour détecter les requêtes entrantes sur 208.217.208.182 et 208.217.208.183. Toute requête entrante sur le port 80 pour l'une de ces adresses IP est traitée selon les règles de Publication Web, les règles de routage et les règles de filtre de paquets IP. Si ces écouteurs ne sont pas définies, ISA Server ne traite aucune requête Web externe.
Configuration SSL
Le pontage SSL fournit une connexion SSL sécurisée, entièrement redondante et à charge équilibrée entre les clients Internet et les fermes de serveurs IIS internes. Le terme "pontage" signifie qu'un client établit une connexion SSL à l'ordinateur ISA Server, et que celui-ci peut soit établir une nouvelle connexion SSL vers les serveurs Web internes, soit rediriger la requête du client au serveur Web à l'aide du protocole HTTP, soit rediriger la requête à l'aide du protocole FTP. Dans l'architecture Internet Data Center, les ordinateurs ISA Server périphériques sont configurés pour rediriger la requête SSL vers les fermes de serveurs IIS internes à l'aide du protocole HTPP (voir Figure 6).
Cette configuration offre les avantages suivants :
La charge SSL peut être transférée des serveurs IIS aux ordinateurs ISA Server. En fonction des exigences de performances, le traitement SSL peut également être déchargé de l'UC du serveur en installant des cartes accélératrices.
Les paquets de charge utile peuvent être examinés par les ordinateurs ISA Server afin de vérifier que ceux-ci ne constituent pas une attaque avant que les paquets ne soient délivrés aux serveurs IIS.
SSL peut fonctionner correctement avec l'équilibrage de charge réseau. Les serveurs IIS sont configurés comme clusters d'équilibrage de charge réseau, puis réglés sur l'affinité simple.Ceci permet aux requêtes SSL entrantes de toujours aboutir au même serveur IIS interne. Si cela n'était pas le cas, chaque requête pourrait être envoyée vers un serveur différent, ce qui entraînerait une charge supplémentaire car une connexion SSL devrait être rétablie à chaque fois. L'affinité simple ne vérifie que l'adresse IP source. L'ordinateur ISA Server effectuant une traduction d'adresse réseau, l'adresse IP source sera toujours l'adresse IP interne de l'ordinateur ISA Server, et toutes les requêtes sur cet ordinateur iront toujours au même serveur IIS interne.
.gif)
Figure 6. Configuration SSL
Pour prendre en charge le trafic SSL sur les ordinateurs ISA Server, ceux-ci sont configurés pour détecter les requêtes SSL et un certificat est installé sur chaque serveur. Chaque règle de Publication Web est mise à jour pour transmettre le paquet SSL entrant à la ferme de serveurs IIS internes à l'aide du protocole HTTP. Le certificat installé utilise une Autorité de certification racine fiable approuvée par tous les clients. Le nom commun du certificat doit correspondre à la requête entrante envoyée par le client Internet et au nom utilisé dans l'ensemble de destination.
Remarque : Certains sites souhaiteront peut-être prendre en charge le trafic SSL à travers ISA Server directement vers le serveur SSL interne. Ceci est possible grâce à l'implémentation de la fonctionnalité Publication de serveur.
Mise en cache inversée
L'un des autres avantages offerts par les ordinateurs ISA Server pour le site Internet est la capacité de mettre en cache le contenu statique des serveurs IIS internes. Ce mécanisme de mise en cache transparent s'appelle la mise en cache inversée. Grâce aux fonctionnalités de mise en cache de ISA Server avec les requêtes Web entrantes, ISA Server peut se faire passer pour un serveur Web aux yeux du monde extérieur et satisfaire les requêtes des clients pour le contenu Web qui se trouve dans son cache. Cette solution de mise en cache inversée fournit de meilleurs temps de réponse aux clients Internet et réduit le trafic sur le réseau de la DMZ.
Le service proxy Web de ISA Server maintient un cache d'objets et tente de satisfaire aux requêtes du client à partir du cache. La plupart du contenu du cache est stocké en mémoire, le contenu du cache étant écrit sur disque grâce à un mécanisme d'écriture différée. Ceci accroît les performances pour le client externe et, avantage supplémentaire du point de vue de la sécurité, réduit le volume de trafic qui traverse la DMZ. Pour des performances encore supérieures, la solution de cache peut être configurée sur un disque différent de celui utilisé pour les fichiers exécutables de ISA Server.
Pour l'architecture Internet Data Center, chaque instance de ISA Server est installée en mode autonome, chaque serveur maintenant son propre cache pour les requêtes entrantes. Vous pouvez visualiser le contenu du cache de chaque ordinateur ISA Server à l'aide de l'utilitaire cachedir.exe qui se trouve dans le répertoire d'Outils de support du CD de ISA Server.
Publication de serveur
La solution Internet Data Center nécessite des services Internet tels que DNS. Selon les exigences d'application du site Web, des services supplémentaires tels que la messagerie SMTP et FTP peuvent également être exigés. Pour prendre en charge ces applications supplémentaires dans la DMZ, des règles de Publication de serveur sont implémentées sur les ordinateurs ISA Server périphériques. La Publication de serveur permet de publier sur Internet les applications qui se trouvent derrière les ordinateurs ISA Server. Les clients Internet référencent le serveur interne en envoyant la requête à l'adresse IP externe de l'ordinateur ISA Server.
ISA Server reste à l'écoute du protocole et du port configuré dans la règle de Publication de serveur. Lorsqu'une requête satisfaisant à la règle arrive, ISA Server redirige le paquet IP vers le serveur interne. Vous pourriez par exemple créer une règle de Publication de serveur pour un serveur DNS interne qui demanderait à ISA Server de rester à l'écoute du port UDP 53 (requête DNS) sur son interface externe et de rediriger la requête vers l'adresse privée du serveur DNS interne, 192.168.21.50. Avant que ISA Server ne redirige la requête, des filtres d'application (tels que le filtre DNS) peuvent être invoqués afin que ISA Server puisse examiner le contenu des données du paquet et déterminer si celui-ci est suspect, auquel cas il serait rejeté avant que le serveur interne ne le reçoive.
Configuration IP
La configuration de Publication de serveur est légèrement différente de celle de Publication Web :
Les paquets TCP/IP sont gérés différemment par ISA Server lorsque des règles de Publication de serveur sont utilisées. Lorsqu'une requête arrive en provenance d'un client Internet, l'adresse IP source et le port source contenus dans le paquet IP d'origine ne sont pas remplacés par l'ordinateur ISA Server, et sont inclus dans le paquet IP qui est redirigé vers le serveur interne. Suivant les règles de Publication Web, ISA Server remplace l'adresse IP et le port sources du client Internet par l'adresse IP interne de l'ordinateur ISA Server et par un nouveau numéro de port.
L'équilibrage de charge réseau ne peut pas être implémenté pour la Publication de serveur. (À l'heure actuelle, l'équilibrage de la charge de la Publication de serveur nécessite une solution d'équilibrage de charge matérielle ou une solution d'équilibrage de charge logicielle tierce.) La configuration d'équilibrage de charge réseau implémentée pour la Publication Web à l'aide des adresses IP virtuelles externes ne peut pas être utilisée pour la Publication de serveur. Au lieu de cela, les adresses IP externes dédiées sur chaque ordinateurs ISA Server sont utilisées pour la Publication de serveur.
Pour ces raisons, la configuration IP du serveur interne publié sera différente de celle du serveur IIS. Dans la conception de Internet Data Center, tous les serveurs publiés sont placés sur le même VLAN (21) que les ordinateurs ISA Server, et les passerelles par défaut pour la moitié des serveurs d'application sont configurées de façon à pointer vers l'un des ordinateurs ISA Server, l'autre moitié pointant vers le second ordinateur ISA Server, tel qu'illustré en Figure 7.
.gif)
Figure 7. Configuration IP pour la Publication de serveur
Chaque paire de serveurs d'application est répartie sur chaque ordinateur ISA Server, à des fins de redondance pour le DNS cyclique. Chaque serveur d'application possède deux adresses IP enregistrées dans le DNS, qui correspondent aux adresses IP dédiées affectées à l'interface externe de chaque ordinateur ISA (208.217.184.180 et 208.217.184.181). Les clients Internet référencent ces adresses pour accéder à ces services. Les adresses IP virtuelles affectées aux ordinateurs ISA Server d'équilibrage de charge sont utilisées pour les règles de Publication Web. Une session qui traverse un ordinateur ISA Server pour accéder au serveur interne doit retourner à travers le même ordinateur ISA Server, car le contraire serait une violation des règles du pare-feu. C'est la raison pour laquelle les serveurs publiés pointent vers ISA Server comme passerelle par défaut. Pour les serveurs IIS, ISA Server remplace l'adresse IP source externe par sa propre adresse interne, ce qui permet aux serveurs IIS de répondre facilement au même ordinateur ISA Server.
Clients NAT sécurisés pour la Publication de serveur
Les clients NAT sécurisés sont faciles à implémenter, car il n'est pas nécessaire de charger des logiciels supplémentaires sur les serveurs internes. L'une des exigences de la traduction d'adresses réseau sécurisée est que le serveur interne doit toujours répondre à l'ordinateur ISA Server qui a redirigé une requête vers lui. Par exemple, si une requête en provenance d'Internet arrive à ISA Server et qu'il détermine que cette requête doit être redirigée vers un serveur IIS interne, le serveur IIS doit répondre à travers l'ordinateur ISA Server par lequel la requête est arrivée. Ceci ne constitue pas un problème pour la Publication de serveur, car ISA Server effectue la traduction d'adresses réseau en remplaçant l'adresse IP source du paquet IP par sa propre adresse interne avant d'envoyer la requête redirigée au serveur IIS interne. Lorsque le serveur IIS voit la requête, il répond avec l'adresse de l'ordinateur ISA Server interne comme adresse de destination dans le paquet IP. La communication aboutira tant que les paramètres IP du serveur interne sont correctement configurés, avec la bonne passerelle par défaut permettant au serveur IIS interne de répondre à l'ordinateur ISA Server.
Pour les raisons discutées plus haut, il est important que la passerelle par défaut des serveurs internes publiés, tels que les serveurs DNS, soit configurée de façon à pointer vers l'ordinateur ISA Server dont les règles de publication sont destinées à ce serveur DNS interne. Dans le cas contraire, la réponse de DNS échouera car le trafic ne sera pas repassé par le même pare-feu que lors de l'envoi de la requête.
Sécurisation des pare-feu périphériques de ISA Server
Les ordinateurs ISA Server sont la première ligne de contact avec Internet ; ils doivent donc être sécurisés en conséquence. Ce processus est souvent nommé "renforcement de serveur". Un modèle de sécurité a été créé afin d'automatiser l'application de règles de sécurité aux deux serveurs ISA Server. Ce modèle effectue les actions suivantes :
Suppression des partages de répertoires Admin
Désactivation des services non nécessaires
Restriction de l'accès anonyme
Application de mots de passe complexes
Configurations des journaux d'audit
Avant de procéder à l'implémentation de la sécurité, l'ordinateur ISA Server doit être entièrement sauvegardé. Le modèle peut ensuite être appliqué à ISA Server à l'aide de la commande secedit avec l'option /config, à partir de l'invite. Une fois sécurisés, les ordinateurs ISA Server doivent être redémarrés plusieurs fois et rigoureusement testés.
Conception du pare-feu interne
Cette section décrit tout d'abord les exigences générales de conception du pare-feu interne dans l'architecture Internet Data Center, puis les exigences spécifiques à l'utilisation de Microsoft ISA Server dans ce rôle.
Exigences de base
Le pare-feu apporte une protection supplémentaire aux serveurs qui se trouvent sur les VLAN internes, tels que les VLAN d'infrastructure et de données-gestion. En cas de violation de l'un des serveurs du VLAN de la DMZ, le pirate devrait ensuite traverser le pare-feu interne pour occasionner des dommages supplémentaires. En outre, NetBIOS est requis sur l'interface interne des serveurs qui se trouvent sur VLAN 11, et le pare-feu interne protège les serveurs du réseau interne en interdisant aux ports NetBIOS 137, 138 et 139 de traverser son interface.
Une solution de pare-feu redondante et hautement disponible doit être implémentée pour la conception du pare-feu interne.
Exigences de trafic
Des ports TCP et UDP spécifiques sont nécessaires à la communication entre les serveurs du réseau de la DMZ et ceux du réseau interne. Tous les serveurs du réseau de la DMZ sont membres du domaine Internet Data Center. Les contrôleurs de domaine de ce domaine se trouvent sur le réseau interne. De plus, les agents de gestion peuvent être installés sur les serveurs frontaux. Ces agents exigent la capacité de transférer les paquets vers des serveurs de gestion internes centralisés. Les serveurs d'application tels que IIS devront aussi communiquer avec les serveurs internes exécutant SQL Server et éventuellement avec les serveurs d'applications tels que BizTalk Server. Le tableau suivant répertorie les exigences de trafic entre les serveurs de la DMZ et les serveurs placés sur les VLAN internes. Ceci correspond à la configuration prise en charge par le pare-feu interne.
Définition de protocole |
Port |
Protocole |
Remarques |
Gestion (Agent de gestion d'applications) |
9979 9998 9999 +RPC |
TCP |
Nécessaire si l'Agent de gestion d'applications est installé sur les serveurs de l'interface Web frontale, et s'ils transmettent les données à un serveur de gestion interne. |
Gestion (Agent de gestion d'opérations) |
1270 |
TCP |
Nécessaire si l'Agent de gestion d'opérations est installé sur les serveurs de l'interface Web frontale, et s'ils transmettent les données aux serveurs de gestion internes. |
Gestion |
4243 4244 |
TCP |
Nécessaire si un serveur Application Center est utilisé pour gérer le contenu de chaque ferme Web. |
Gestion |
3389 |
TCP |
Permet aux administrateurs du réseau VPN de gestion d'accéder aux services Terminal Server sur tous les serveurs de l'interface Web frontale. |
Application |
1433 |
TCP |
Tous les serveurs IIS possèdent des entrées DNS qui pointent vers les clusters SQL Server virtuels sur VLAN 12. |
Application |
1801 |
TCP |
Message Queuing est installé sur tous les serveurs IIS, et ceux-ci transmettent le serveur en cluster interne Message Queuing sur VLAN 13. |
Infrastructure (Domaine – Kerberos) |
88 |
UDP |
Serveurs de la DMZ qui sont membres du domaine interne. |
Infrastructure (Domaine – NTP) |
123 |
UDP |
Serveurs de la DMZ qui sont membres du domaine interne. |
Infrastructure (Domaine – RPC Endpoint Mapper) |
135 |
TCP |
Serveurs de la DMZ qui sont membres du domaine interne. |
Infrastructure (Domaine – LDAP) |
389 |
TCP UDP |
Serveurs de la DMZ qui sont membres du domaine interne. |
Infrastructure (Domaine – SMB Direct Host) |
445 |
TCP |
Serveurs de la DMZ qui sont membres du domaine interne. |
Infrastructure (Domaine – NTDS) |
1026 |
TCP |
Serveurs de la DMZ qui sont membres du domaine interne. |
Configuration des ports RPC Windows 2000
Dans l'environnement Internet Data Center, il se peut que la prise en charge du trafic DCOM/RPC soit requise des serveurs de la DMZ aux serveurs du réseau interne. Par défaut, le protocole DCOM/RPC Windows 2000 utilise le port 135 (RPC Endpoint Mapper) pour négocier un port supérieur à 1023 pour le trafic DCOM/RPC. Lorsqu'un client a besoin de communiquer avec un serveur et qu'aucun port TCP bien connu n'est défini pour l'application serveur, le client formule une requête au serveur sur le port 135 afin de déterminer le port TCP/UDP sur lequel l'application est à l'écoute. Pour identifier l'application auprès du serveur, le client peut spécifier l'identificateur unique universel (UUID, Universally Unique Identifier) de l'application. Le serveur répond au client et lui indique le port à utiliser pour initier une conversation avec l'application interne. Le client effectue alors un autre appel au même serveur, mais cette fois-ci il utilise le port sur lequel l'application est à l'écoute afin d'initier une conversation.
Ces ports d'application peuvent changer à chaque redémarrage du serveur, ce qui rend plus difficile la configuration du pare-feu pour la prise en charge de ce trafic. Pour éviter tout problème lié au pare-feu et au trafic RPC, une plage de ports spécifique doit être utilisé pour ce trafic. Ceci permet au pare-feu d'ouvrir des plages de ports spécifiques entre les VLAN. Cette configuration peut être mise en oeuvre dans Windows 2000 en apportant les modifications suivantes au Registre :
Clé : HKLM\SOFTWARE\Microsoft\RPC\Internet
Valeur nommée : Ports
Type : REG_MULTI_SZ
Paramètre : Plage de ports. Peut s'étaler sur plusieurs lignes.
4001-4039
9001-9099
Valeur nommée : PortsInternetAvailable
Type : REG_SZ
Paramètre : Y
Valeur nommée : UseInternetPorts
Type : REG_SZ
Paramètre : Y
Exigences de conception de ISA Server
Si les ordinateurs ISA Server sont utilisés comme solution de pare-feu, des règles de Publication de serveur sont configurées afin de publier les ports des services d'annuaire Active Directory™ sur les serveurs de la DMZ. Des solutions d'équilibrage de charge matérielles ou logicielles doivent être implémentées devant et derrière les ordinateurs ISA Server internes afin de fournir une solution hautement disponible et entièrement redondante. Cette configuration est quelquefois qualifiée de "sandwich de pare-feu".
Configuration réseau
La conception du réseau de pare-feu ISA interne est une configuration multiconnectée, tout comme la conception du pare-feu ISA périphérique, avec l'interface externe reliée à VLAN 11 et l'interface interne reliée à VLAN 15. Des itinéraires statiques ont été créés sur l'interface interne vers VLAN 12 et VLAN 13, avec 192.168.15.253 comme passerelle par défaut. Le trafic en provenance des serveurs de la DMZ sur VLAN 11 ne peut atteindre les serveurs internes sur VLAN 12 et VLAN 13 que par l'intermédiaire de l'ordinateur ISA Server.
Trafic de publication de domaine à travers ISA
ISA Server doit être configuré afin d'écouter les ports TCP et UDP utilisés pour la communication vers les contrôleurs de domaine et pour leur publication sur son interface externe sur VLAN 11. Afin de publier les ports Active Directory sur ISA Server, tous les ports TCP et UDP utilisés pour l'authentification, tels que Kerberos et LDAP, doivent d'abord être définis dans la zone de définition de protocole de ISA Server. Une définition de protocole définit le Numéro de port, le Protocole IP utilisé (TCP ou UDP) et la Direction (Entrante ou Sortante pour TCP ; Envoi seulement, Réception seulement, Envoi et réception, Réception et envoi pour UDP). Une fois créée, une définition de protocole peut être utilisée dans les filtres de paquets, les règles de protocole et les règles de Publication de serveur. Ces définitions sont entrées dans les règles de Publication de serveur.
Une fois toutes les définitions de protocole créées pour l'annuaire Active Directory, les ports peuvent être publiés sur l'interface externe de ISA Server. Les règles de Publication de serveur mappent les requêtes entrantes vers les serveurs internes appropriés derrière le pare-feu ISA Server. ISA Server reste à l'écoute des requêtes entrantes sur son interface externe pour le compte du serveur interne, puis crée une nouvelle session entre lui-même et le serveur interne afin de gérer la session entre le client (serveurs de la DMZ) et le serveur interne (les contrôleurs de domaine).
Désactivation de NetBIOS
Afin de prendre en charge le trafic de domaine vers et en provenance des contrôleurs de domaine dans le VLAN d'infrastructure, le port SMB (Server Message Block) (port TCP 445) doit être l'un des ports publiés sur ISA Server et redirigés vers les contrôleurs de domaine internes. Pour que ISA Server reste à l'écoute du port TCP 445 sur son interface interne, ce port doit être entièrement désactivé sur l'ordinateur ISA Server. La seule manière de désactiver complètement NetBIOS et SMB sur ces ordinateurs est de désactiver le pilote de périphérique NetBIOS.
Conception du service DNS
L'architecture Internet Data Center tire parti d'une conception de service DNS sécurisée nommée "DNS fractionné-fractionné" Cette conception est décrite dans la section Conception du service DNS du Chapitre 2, "Conception de l'infrastructure réseau". Tout comme la conception DNS fractionné de l'architecture de base, cette architecture DNS est composée de serveurs DNS externes (services de publication et de résolution) qui fournissent la résolution de noms aux clients Internet, et de serveurs DNS internes qui ne desservent que l'espace de noms interne.
Une conception DNS fractionné-fractionné doit être utilisée lorsque ISA Server est utilisé comme pare-feu interne. En effet, il est impossible d'utiliser la Publication de serveur pour gérer le trafic DNS en provenance des serveurs de la DMZ et à destination des services DNS internes exécutés sur les contrôleurs de domaine placés sur le VLAN d'infrastructure. Ceci est dû au fait que les adresses IP renvoyées par les serveurs DNS internes ne peuvent pas être routées à travers les pare-feu internes car ISA Server joue le rôle de proxy pour ces requêtes.
Afin de fournir la résolution de noms aux serveurs de la DMZ, les fichiers de zone DNS qui se trouvent sur les serveurs DNS internes sont copiés sur les serveurs de résolution DNS externes situés dans la DMZ (voir Figure 8), puis ces fichiers de zone sont modifiés. Le placement des fichiers de zone internes sur les serveurs de résolution DNS externes apporte une protection contre toute menace provenant d'Internet, car ces serveurs sont configurés de façon à rejeter toute requête en provenance d'Internet. Les enregistrements d'hôte du fichier de zone sont modifiés de manière à pointer vers les adresses IP définies sur l'interface de VLAN 11 du pare-feu ISA Server. Les paramètres DNS des serveurs de la DMZ sont configurés pour pointer vers les serveurs de résolution DNS (192.168.11.16, 192.168.11.17) sur VLAN 11, afin de résoudre les noms pour les serveurs internes qui se trouvent derrière la pare-feu ISA Server.
.gif)
Figure 8. Configuration DNS fractionné-fractionné
Remarque : Pour des raisons de clarté, les VLAN sont représentés comme étant connectés à des commutateurs multicouches séparés. En réalité, tous les VLAN sont gérés sur un seul commutateur, un second commutateur étant configuré comme partenaire de redondance.
Conception du pare-feu de VPN
Un VPN (réseau privé virtuel) permet d'utiliser une infrastructure publique, telle qu'Internet, pour transporter une connexion ou un tunnel point à point privé et crypté. Les paquets sont encapsulés dans une enveloppe (ou en-tête) qui contient les informations de routage. Windows 2000 prend en charge les deux protocoles de tunnel communs de Couche 2: PPTP (Point-to-Point Tunneling Protocol) et L2TP (Layer 2 Tunneling Protocol). Dans l'architecture Internet Data Center, les serveurs de VPN permettent d'accéder au système pour la gestion à distance.
À des fins de redondance et de haute disponibilité, deux serveurs de VPN sont déployés. ISA Server est installé sur les deux serveurs de VPN afin de fournir un filtrage de paquets robuste, une inspection d'état des paquets et une détection d'intrusion, ce qui permet de renforcer la sécurité du trafic du VPN. Les étapes de configuration des serveurs de VPN avec ISA Server sont les suivantes :
configuration des paramètres de réseau IP ;
configuration de l'équilibrage de charge ;
installation de ISA Server ;
configuration du réseau VPN ;
implémentation des certificats.
Adresses IP
Les deux serveurs de VPN sont multiconnectés. Leur interface interne est reliée à VLAN 12, chaque serveur étant affecté d'une adresse IP interne statique, et leurs interfaces externes sont reliées au routeur qui fait face à Internet. Une adresse IP publique dédiée a été affectée à chaque serveur de VPN, et une adresse IP publique virtuelle a été affectée à l'interface qui fait face à Internet de chaque serveur de VPN lors de la configuration de l'équilibrage de charge réseau.
.gif)
Figure 9. Configuration de ISA Server pour le VPN
Dans cette configuration, la passerelle par défaut est configurée sur les deux serveurs de VPN pour pointer vers le routeur qui fait face à Internet, afin de permettre aux serveurs de VPN de répondre à n'importe quel client Internet. Des itinéraires statiques sont créés sur les interfaces internes des deux serveurs de VPN. L'ajout d'itinéraires vers VLAN 11 et VLAN 13 (192.168.11.0 et 192.168.13.0) permet aux administrateurs distants de se connecter aux serveurs qui ne se trouvent pas sur VLAN 12.
Configuration de ISA Server
Les serveurs de VPN et ISA Server sont configurés en mode autonome et sont configurés uniquement en mode pare-feu. La LAT est configurée pour les trois réseaux privés 192.168.13.0, 192.168.12.0 et 192.168.11.0. Grâce à celle-ci, ISA Server peut différencier le trafic Internet du trafic interne.
Assistant VPN ISA
Grâce à l'Assistant VPN ISA intégré, il est très simple de configurer ISA Server pour la prise en charge du trafic de VPN client via les protocoles PPTP et L2TP. Cet Assistant propose trois options de configuration de VPN :
réseau privé virtuel ISA Server local ;
réseau privé virtuel ISA Server distant ;
réseau privé virtuel ISA Server.
L'option "Réseau privé virtuel ISA" est sélectionnée afin de permettre aux utilisateurs itinérants de se connecter au serveur de VPN. Une fois cette option sélectionnée, ISA Server configure immédiatement les paramètres de VPN en configurant le filtrage de paquets de manière à autoriser le passage du trafic PPTP et L2TP. Durant cette configuration, ISA Server démarre le service RRAS (Routing and Remote Access Service), si celui-ci n'est pas déjà en marche, et modifie la dépendance de service de façon à ce que le démarrage du service RRAS dépende de ISA Server. La raison de cette dépendance est que ISA Server et le service RRAS implémentent tous deux le filtrage de paquets. Cependant, un seul de ces services peut détenir cette fonctionnalité sur un serveur donné. Cette dépendance désigne ISA Server comme propriétaire de cette fonctionnalité. Une fois la configuration terminée, vous devez manuellement modifier l'un des paramètres de la configuration de ISA Server afin d'autoriser le trafic PPTP à travers le pare-feu.
Filtres de paquets
Quatre filtres de paquets créés dans la configuration de ISA Server prennent en charge les trafics PPTP et L2TP. Ces filtres sont appliqués à l'interface externe de l'ordinateur ISA Server. Par défaut, l'Assistant ISA configurera ces filtres de manière à autoriser les trafics PPTP et L2TP grâce à l'adresse IP dédiée affectée à l'interface de ISA Server qui fait face à Internet. Ces filtres doivent être modifiés manuellement (remplacement de l'adresse IP dédiée par l'adresse IP virtuelle ou en cluster créée par l'équilibrage de charge réseau). Cette adresse sera celle configurée sur les clients de tous les utilisateurs du VPN.Le protocole L2TP n'étant pas pris en charge par cette version, les deux filtres de paquets L2TP automatiquement créés par l'Assistant de configuration de ISA Server doivent être supprimés ou désactivés.
Le tableau suivant répertorie les filtres créés par l'Assistant VPN ISA :
Filtre de paquets |
Protocole IP |
Direction |
Port |
Autorise les paquets IKE du protocole L2TP |
UDP
|
Les deux |
500 |
Autorise les paquets L2TP |
UDP |
Les deux |
1701 |
Autorise les paquets PPTP (clients) |
TCP |
Entrante |
1723 |
Autorise les paquets PPTP (serveur) |
TCP |
Sortante |
1723 |
Configuration du service RRAS
Une fois le serveur ISA Server configuré, deux étapes supplémentaires doivent être effectuées sur chaque serveur RRAS. Tout d'abord, le pool d'adresses IP doit être défini. Ces adresses sont affectées à chaque nouveau client du VPN qui atteint le serveur du VPN. Ceci peut être configuré soit à l'aide de DHCP (Dynamic Host Control Protocol), soit en affectant les adresses de manière statique. L'architecture Internet Data Center n'incluant pas de serveur DHCP, des plages d'adresses statiques différentes sont affectées sur chaque serveur, ce qui permet d'éviter tout conflit. Le premier serveur de VPN est configuré pour les adresses statiques 192.168.12.100 à 192.168.12.119, et le second serveur de VPN est configuré pour les adresses statiques 192.168.12.120 à 192.168.12.139.
La seconde modification apportée au serveur RRAS est le nombre de connexions simultanées prises en charge pour chaque protocole (PPTP et L2TP). Par défaut, cinq connexions sont configurées pour PPTP et pour L2TP sur chaque serveur. Il vous faudra peut-être modifier ces valeurs, selon l'usage des connexions VPN de votre implémentation. Dans l'architecture Internet Data Center, les connexions L2TP ont été supprimées pour les deux serveurs et le nombre de connexions PPTP a été modifié afin de prendre en charge dix utilisateurs simultanés.
Protocoles de VPN
Lors de la conception de la solution de VPN, vous avez le choix entre les deux principaux protocoles de VPN, PPTP et L2TP. La conception de Internet Data Center ne prend en charge que la connectivité PPTP avec authentification EAP (Extensible Authentication Protocol). Les concepteurs système préféreront peut-être utiliser PPTP au lieu de L2TP, car il peut être utilisé à travers les pare-feu à NAT. Dans certains cas, les administrateurs de Internet Data Center géreront le site à distance à partir d'un ordinateur portable d'entreprise (ou éventuellement à partir d'un ordinateur de bureau à leur domicile) ; ces deux ordinateurs devront alors être protégés par un pare-feu (d'entreprise ou personnel). Si ces pare-feu utilisent la traduction d'adresses réseau sur la connexion, le protocole L2TP sera inutilisable.
Remarque : Ceci n'est pas une limitation des périphériques de pare-feu ni du protocole L2TP, mais du fait que IPSec (qui est utilisé pour crypter le trafic L2TP) ne peut pas être utilisé avec la traduction d'adresses réseau. Ceci est applicable à tout pare-feu tiers ou implémentation d'IPSec.
Le protocole PPTP peut se révéler aussi sécurisé que L2TP lorsque le cryptage 128 bits et EAP sont utilisés avec des certificats ou des cartes à puces pour l'authentification. Pour sécuriser PPTP avec cryptage 128 bits mais sans EAP, vous devrez utiliser des mots de passe longs et complexes avec MS-CHAPV2. Ceci vous permettra d'effectuer une gestion à distance à partir des clients ne prenant pas en charge EAP, tels que les systèmes d'exploitation Microsoft Windows NT® version 4.0, Windows 95 ou Windows 98 qui utilisent le client d'Accès réseau à distance le plus récent.
La conception de Internet Data Center utilise PPTP avec l'authentification EAP par certificats comme option de VPN préférée, car cette solution représente la meilleure combinaison de sécurité et de flexibilité pour cette conception.
Remarque : Pour une solution encore plus sécurisée, vous pouvez utiliser l'authentification EAP avec des cartes à puce plutôt que la solution à certificats basée sur le Registre. Cette solution n'a pas été choisie pour l'architecture Internet Data Center car les lecteurs de cartes à puce ne sont pas encore très répandus sur les lieux de travail ou chez les particuliers.
Services de certificats
Un serveur de certificats est requis pour la prise en charge de l'authentification EAP avec certificats, c'est pourquoi un serveur de certificats interne a été implémenté. Cette solution a été choisie afin de permettre aux administrateurs internes de contrôler la révocation, les délais d'expiration et les sauvegardes de certificats.
La conception de serveur de certificats de Internet Data Center n'est utilisée que pour la prise en charge de l'authentification sur le VPN. L'architecture de déploiement du serveur de certificats pour ce scénario n'est pas destinée ni adaptée à un déploiement d'infrastructure PKI (Public Key Infrastructure) à grande échelle. Si les services de certificats étaient requis pour la prise en charge de scénarios plus complexes, tels que des scénarios interentreprises ou impliquant tous les employés d'une entreprise, ils seraient déployés différemment. Ceci n'étant pas le cas, une architecture très simple est implémentée afin de minimiser les frais de gestion.
Le serveur de certificats étant sauvegardé régulièrement et les certificats étant rarement requis (en raison du faible nombre d'administrateurs pour le site), les faibles besoins en disponibilité de ce serveur n'imposent pas la présence d'une architecture de basculement redondante pour ce service. Une autorité de certification d'entreprise est implémentée sur l'un des contrôleurs de domaine. En outre, le serveur IIS est exécuté sur ce contrôleur de domaine afin de prendre en charge l'inscription de certificats basés sur le Web par les utilisateurs et les stations de travail.
Les données et l'état du système sont sauvegardés chaque nuit sur bande, afin de garantir la sauvegarde des certificats, et en cas de panne leur restauration ne prendrait que quelques heures.
L'outil d'inscription de certificats basés sur le Web est exécuté sur le serveur de certificats et permet de desservir les demandes de certificat en provenance des utilisateurs et des stations de travail clientes. Le certificat racine de l'autorité de certification et un certificat d'ordinateur sont installés sur les deux serveurs de VPN, grâce à la création d'une unité d'organisation pour les serveurs du VPN dans Active Directory. La Stratégie de groupe est ensuite appliquée à cette unité d'organisation, ce qui inscrit automatiquement les ordinateurs contenus dans ce groupe pour les certificats d'ordinateur.
Configuration du serveur RRAS
Le protocole EAP étant utilisé comme mécanisme d'authentification pour PPTP, il est configuré comme seul mécanisme d'authentification accepté, et tous les autres mécanismes sont désactivés. Les utilisateurs ne sont donc pas en mesure de se connecter aux serveurs du VPN avec leur nom d'utilisateur et leur mot de passe. Ceci renforce la sécurité de la solution de VPN, mais exige des administrateurs système qu'ils demandent le certificat racine de l'autorité de certification et un certificat d'utilisateur lorsqu'ils se trouvent physiquement au bureau. Si les administrateurs demandent ce certificat à partir d'un ordinateur portable appartenant à l'entreprise, ils seront en mesure de se connecter au site, mais s'ils souhaitent administrer le système depuis leur domicile ils devront exporter des certificats sur une disquette, puis installer ceux-ci sur leur ordinateur personnel. En cas d'exportation d'un certificat sur disquette, l'option Marquer les clés comme étant exportables doit être sélectionnée lors de la demande de certificat. Dans le cas contraire, le certificat et sa clé privé ne pourront pas être exportés de l'ordinateur sur lequel ils ont été demandés.
Une fois le certificat importé sur la station de travail du domicile de l'administrateur, le certificat ou la clé présent(e) sur la disquette doit être supprimé(e) et la disquette détruite. La solution de sécurité la plus renforcée nécessiterait le stockage du certificat ou de la clé sur une carte à puce, mais les lecteurs de cartes à puce n'étant pas encore très répandus sur le marché, leur utilisation n'a pas été exigée dans l'architecture. Le certificat requis pour l'authentification EAP est un certificat d'utilisateur qui doit être placé dans la banque de certificats personnels utilisateur sur la station de travail Windows 2000.
Stratégie d'accès à distance
La Stratégie d'accès à distance est configurée de manière à accepter EAP pour l'authentification uniquement au niveau de cryptage le plus élevé autorisé. L'option la plus élevée permet aux connexions d'utiliser uniquement le cryptage IPSEC Triple DES ou MPPE 128 bits. Cette option nécessite l'installation du pack de cryptage 128 bits sur les clients et les serveurs.
Journalisation de l'accès à distance
Le service RADIUS (Remote Authentication Dial-In User Service) n'a pas été utilisé dans l'architecture car la comptabilité et la gestion centralisées des connexions au VPN n'étaient pas requises pour la prise en charge de l'accès distant par les administrateurs. Les requêtes de comptabilité (telles que démarrage et arrêt de comptabilité) et les requêtes d'authentification telles que Access-Accept ou Access-Reject, sont enregistrées dans un journal sur le serveur RRAS. Celui-ci dispose d'une fonction lui permettant d'enregistrer périodiquement l'état, comme par exemple les requêtes de comptabilité intérimaires. Cette fonction de journalisation n'est pas activée car elle peut engendrer des journaux de taille très importante. Un emplacement personnalisé (éloigné de l'emplacement par défaut) est spécifié pour le fichier journal, afin de renforcer la sécurité sur le répertoire.
Conception de pare-feu à haute-disponibilité
Comme nous l'avons vu plus haut, l'architecture Internet Data Center exige des solutions de pare-feu hautement disponibles et à tolérance de pannes. Cet objectif peut être atteint grâce à une combinaison de Microsoft ISA Server et du service d'équilibrage de charge réseau, ou de Microsoft ISA Server associé à une solution de clustering tierce. Les sections suivantes décrivent les problèmes de conception liés à la solution ISA Server/service d'équilibrage de charge réseau, et présentent un exemple d'une solution tierce complémentaire à ISA Server proposée par Stonesoft Corp.
Utilisation du service d'équilibrage de charge réseau avec ISA Server
Le service d'équilibrage de charge réseau peut fournir à la fois une tolérance de pannes et une évolutivité horizontale pour les ordinateurs ISA Server. Ce service comporte des règles de port qui peuvent être configurées pour remplir deux fonctions :
elles spécifient l'affinité et le comportement de gestion de la charge selon les ports ;
- elles fournissent un niveau de sécurité, dans le sens où ces règles sont traitées avant que les paquets n'atteignent la pile TCP/IP sur le serveur.
Par défaut, une seule règle est configurée dans le service d'équilibrage de charge réseau. Celle-ci définit les valeurs suivantes pour les paramètres correspondants :
Paramètre |
Valeur |
Plage de ports |
1-65535 |
Affinité |
Simple |
Mode de filtrage |
Hôtes multiples |
Charge |
Égale |
Protocoles |
Les deux |
Règles de port
La règle de port par défaut est supprimée car aucune affinité ne doit être utilisée sur les applications ou les protocoles sans état, afin d'obtenir la meilleure configuration d'équilibrage de charge. Au lieu de cela, les règles suivantes sont configurées sur les ordinateurs ISA Server :
Règle |
Début |
Fin |
Protocole |
Mode |
Charge |
Affinité |
1 |
0 |
442 |
Les deux |
Multiple |
Égale |
Aucune |
2 |
443 |
443 |
TCP |
Multiple |
Égale |
Simple |
3 |
444 |
65535 |
Les deux |
Multiple |
Égale |
Aucune |
Cette version de l'architecture fournit trois services à Internet :
HTTP. C'est un protocole sans état, à moins que l'état de session d'une application Web ne soit maintenue sur le serveur Web, ce qui est vivement déconseillé pour les fermes de serveurs. L'état de session d'application doit être maintenu de façon centralisée dans une base de données ou tout autre mécanisme de stockage accessible de manière centralisée.
HTTPS. Protocole orienté session.
DNS. Publié par le biais des ordinateurs ISA Server, DNS utilise donc l'adresse IP dédiée de ces ordinateurs, contournant toute configuration de port d'équilibrage de charge réseau.
Pour HTTPS, une session est établie à chaque fois qu'un client Internet se connecte à un pare-feu différent qui publie en dehors de la ferme Web. Si aucune affinité n'est utilisée pour HTTPS, le client devra peut-être recréer une session à chaque tentative de connexion à la ferme Web. Ceci est inacceptable.
Le port 443 est donc configuré pour l'affinité simple. Ainsi, une fois qu'un client a établi une session SSL avec un pare-feu, cette session demeure intacte jusqu'à ce que le client ait terminé ou que la session arrive à expiration.
L'affinité de Classe C constitue une autre option pour l'équilibrage de charge. Cette option est semblable à l'affinité simple, mais elle garantit que la charge des clients dont les adresses IP sont dans la même plage d'adresses de Classe C sera équilibrée sur le même pare-feu.
Solutions de tierces parties
Il est également possible de fournir une solution à haute disponibilité grâce à des solutions de tierces parties, telles que StoneBeat FullCluster for ISA Server de Stonesoft Corp. Cette solution offre un équilibrage de charge dynamique sur plusieurs pare-feu ISA Server. Bien qu'elle n'ait pas été testée dans le cadre de l'architecture Internet Data Center, nous la mentionnons afin de démontrer les autres possibilités qui s'offrent à vous pour votre propre implémentation. Pour plus de détails sur cette solution, consultez le site Stonesoft .gif)
.gif)
Résumé
La conception de pare-feu de Internet Data Center permet de bénéficier d'un environnement sécurisé et à tolérance de pannes. Ce chapitre a décrit les principes de fonctionnement des pare-feu, les problèmes courants associés à leur conception, ainsi que les types de pare-feu utilisés dans l'architecture Internet Data Center. Des détails ont été fournis quant à l'utilisation de Microsoft ISA Server comme pare-feu et cache Web. Des solutions de pare-feu à haute disponibilité utilisant ISA Server associé à des produits tiers ou au service d'équilibrage de charge réseau ont également été décrites.
Dernière mise à jour le vendredi 1 mars 2002
Pour en savoir plus