> Tech > Améliorer la sécurité avec ISA Server 2004

Améliorer la sécurité avec ISA Server 2004

Tech - Par iTPro.fr - Publié le 24 juin 2010
email

par Mark Minasi - Mis en ligne le 14/06/06 - Publié en Février 2005

Recherchez-vous un moyen d’améliorer sensiblement la sécurité de vos applications et services Microsoft face à Internet ? Si oui, jetez un coup d’oeil à Microsoft ISA (Internet and Security Acceleration) Server 2004, qui va bien plus loin que son prédécesseur, ISA Server 2000. ISA Server 2004 offre un pare-feu réseau à filtrage « stateful » (au niveau de la couche transport 4 et au-dessous du modèle OSI – Open System Interconnection) et un filtrage au niveau de la couche application (couche 7) « stateful » sur toutes les interfaces installées.

Améliorer la sécurité avec ISA Server 2004

Beaucoup d’entreprises possèdent déjà une infrastructure pare-feu mais veulent néanmoins jouir de la sécurité supérieure d’ISA Server 2004. Le pare-feu ISA Server 2004 est extrêmement souple et peut être déployé de diverses manières.
L’un des modes de déploiement les plus usuels et les plus sûrs est une configuration pare-feu dos à dos : un parefeu physique basé sur le filtrage de paquets de type classique, placé en frontal, assure le filtrage stateful de base pour protéger la zone démilitarisée (DMZ) entre le pare-feu et l’interface LAN; et un pare-feu ISA Server 2004 à l’arrière assure le filtrage et l’inspection au niveau de la couche application stateful, pour protéger les noyaux des ressources de gestion.
Filtrer l’accès à distance aux services Microsoft Exchange Server est un scénario classique pour ISA Server, et plusieurs des nouvelles technologies du pare-feu offrent un niveau de protection unique pour les services Exchange face à Internet, particulièrement Microsoft OWA (Outlook Web Access). Si vous envisagez de placer un pare-feu ISA Server derrière un pare-feu physique à base de filtrage de paquets existants, ce scénario donne un bon exemple des procédures requises à cet effet. La figure 1 montre une vue d’ensemble du modèle de pare-feu dos à dos. Voyons les principales caractéristiques de la topologie du réseau et du pare-feu :

• Un pare-feu physique de filtrage de paquets stateful (basé sur ASIC – applicationspecific integrated circuit), que j’appellerai le pare-feu physique, est placé en frontal.
Ce pare-feu rudimentaire assure la protection couche 4 et au-dessous pour les hôtes situés sur le réseau de périmètre entre le pare-feu physique et le pare-feu ISA Server 2004, que j’appellerai pare-feu ISA. Ce segment DMZ est un segment non authentifié : alors que les serveurs publics placés dans la DMZ nécessiteront parfois l’authentification locale au niveau du serveur, aucune authentification n’est requise pour entrer dans le segment.
• Un pare-feu de filtrage stateful et un pare-feu ISA de filtrage au niveau de la couche application (couche 7) stateful est placé à l’arrière. Ce pare-feu, qui est plus proche des ressources d’entreprise vitales, doit offrir un niveau de protection supérieur à celui du pare-feu physique. Le pare-feu ISA atteint cet objectif en pratiquant le même filtrage stateful que le pare-feu physique, mais surpasse le pouvoir de protection du pare-feu physique en ajoutant une inspection au niveau de la couche application stateful. En outre, une stricte authentification basée sur les utilisateurs et les groupes est nécessaire pour toutes les connexions qui traversent le pare-feu ISA dans les deux sens.
• Le pare-feu ISA possède trois interfaces réseau : une interface externe qui se connecte au segment DMZ, une interface interne qui se connecte à un segment de services d’infrastructure réseau contenant les serveurs d’infrastructure centrale (comme un serveur DC – domain controller et GC – global catalog – un serveur Exchange frontal, un serveur Exchange d’arrière plan), et une autre interface interne qui se connecte à un segment de réseau contenant les systèmes client. Aucune connexion non authentifiée n’est autorisée de l’interface externe au segment des services d’infrastructure et aucune connexion n’est autorisée à partir du segment client sauf si elle est nécessaire pour utiliser les services réseau. Un tel modèle protège les serveurs de l’infrastructure réseau contre les attaques externes mais aussi contre les attaques lancées par des hôtes sur le segment client.
• Le système ISA Server est un membre du domaine réseau interne. Selon certains experts, l’appartenance au domaine pourrait menacer la sécurité interne du réseau dans le cas où le système ISA Server serait lui-même compromis.
En réalité, si cela se produit, l’appartenance au domaine du serveur a peu d’effet sur les dégâts qu’un assaillant peut causer. La protection que l’on obtient en rendant le système ISA Server membre du domaine dépasse largement les avantages théoriques qu’il y aurait à ne pas le faire.
• Le pontage SSL (Secure Sockets Layer) à SSL sur le pare-feu ISA est utilisé pour empêcher toute dissimulation à l’intérieur des tunnels SSR. Le client Web distant emprunte un tunnel au travers du pare-feu physique et termine sa session SSL par l’interface externe du pare-feu ISA. Le pare-feu ISA décrypte les paquets, procède au filtrage de la couche applicative stateful sur les communications, et recrypte les paquets pour les envoyer sur une seconde liaison SSL établie entre l’interface interne du pare-feu ISA et le serveur Exchange frontal.
• Le pare-feu ISA est configuré de manière à obliger la présentation d’un certificat client au site Web OWA du serveur Exchange frontal. Cette exigence protège le serveur Exchange frontal contre un assaillant qui essaierait d’utiliser une autre machine (par exemple, par l’intermédiaire d’une adresse IP usurpée) pour imiter le pare-feu ISA et transmettre les connexions au serveur Exchange frontal.
Comme un tel attaquant n’aura pas de certificat client valide, la tentative de connexion échouera même si l’attaquant a des références utilisateur OWA légitimes. A noter que le client Web ne présente pas un certificat client au serveur Exchange ou au pare-feu ISA ; seul le pare-feu ISA présente un certificat client quand il établit la liaison SSL entre lui-même et le serveur Exchange frontal.
• Le DC sur le segment des services d’infrastructure exécute Microsoft Certificate Services et est configuré comme une CA (Certification Authority) d’entreprise. Une CA d’entreprise est préférable à une CA autonome pour plusieurs raisons. Principalement, le fait que l’on puisse utiliser le Web Site Certificate Request Wizard pour solliciter et installer un certificat de site Web sur le serveur Exchange frontal et que le certificat CA racine de la CA d’entreprise soit automatiquement placé dans le stockage des certificats Trusted Root Certification Authority des membres du domaine.

Bien entendu on peut configurer l’infrastructure pare-feu et réseau de bien d’autres manières. Par exemple, beaucoup d’administrateurs de pare-feu exigent qu’il n’y ait pas de serveurs face à Internet sur un réseau qui contient le DC et autres serveurs d’infrastructure réseau principaux. Dans ce cas, vous pourriez ajouter une quatrième interface réseau au pare-feu ISA, placer le serveur Exchange frontal sur un segment de réseau périphérique en accès seulement, authentifié et dédié, et utiliser les règles d’accès du pare-feu ISA pour n’autoriser que les protocoles requis à partir du serveur Exchange frontal vers le serveur Exchange d’arrière plan et le serveur DC/GC dans le segment des services d’infrastructure.
Mais continuons cette discussion à l’aide de notre exemple de configuration. Cette configuration suppose que votre CA d’entreprise est dans le même domaine que vos serveurs Exchange. Les procédures suivantes sont nécessaires pour publier le site OWA de votre serveur Exchange frontal aux utilisateurs distants sur Internet :

1. Configurer le DNS public pour retransmettre les connexions OWA entrantes vers la bonne adresse.
2. Configurer le pare-feu physique pour transmettre les connexions du port TCP 443 entrantes vers le pare-feu ISA. 3. Demander et lier un certificat de site Web au site Web OWA sur le serveur Exchange frontal.
4. Exporter le certificat du site Web vers un fichier.
5. Configurer les répertoires OWA de manière à ce qu’ils utilisent l’authentification Basic, forcer les connexions SSL et exiger un certificat client de la part du pare-feu ISA.
6. Créer un compte utilisateur pour le pare-feu ISA.
7. Demander un certificat client pour le proxy Web du parefeu ISA.
8. Importer le certificat du site Web dans le stockage des certificats machine du pare-feu ISA.
9. Importer le certificat client du pare-feu ISA dans le stockage des certificats personnels du service du pare-feu ISA. 10. Créer la règle de publication Web OWA sur le pare-feu ISA.
11. Renforcer la règle de publication Web OWA en configurant le filtre de sécurité HTTP.
12. Créer un fichier HOSTS sur le pare-feu ISA qui corresponde au FQDN (fully qualified domain name) du site OWA vers l’adresse IP interne du site OWA.
13. Demander et installer le certificat CA racine sur le client navigateur Web.

Commençons par les cinq premières de ces étapes. Les suivantes feront l’objet d’un autre article.

Téléchargez gratuitement cette ressource

Protection des Données : 10 Best Practices

Protection des Données : 10 Best Practices

Le TOP 10 des meilleures pratiques, processus et solutions de sécurité pour mettre en œuvre une protection efficace des données et limiter au maximum les répercutions d’une violation de données.

Tech - Par iTPro.fr - Publié le 24 juin 2010