Présentation du produit

1.1 Présentation d’ISA Server et bref historique

ISA signifie Internet Security & Acceleration Server. C’est un produit de la gamme serveur de Microsoft cumulant plusieurs rôles :

  • Pare-feu multicouches
  • Serveur de proxy
  • Serveur VPN

ISA est le descendant direct de Microsoft Proxy Server 1.0 (sorti en 1996) qui n’était à l’origine qu’un serveur de proxy conçu pour fonctionner sous Windows NT 4.

La version 2.0 de Proxy Server apporte principalement la gestion de la mise en cache distribuée via des groupes de serveurs. Cette édition permet de mettre en place un équilibrage de la charge réseau et une tolérance de panne au niveau de l’accès Web (FTP et HTTP), fonctionnalité innovante dans le domaine des proxys à l’époque de la sortie du produit (pour cela Microsoft a développé un protocole spécifique, dont il est propriétaire nommé CARP) !

La troisième mouture de Proxy Server se veut plus ambitieuse que ses prédécesseurs car le but n’est pas seulementd’accélérer l’accès Web (fonction de serveur proxy) mais aussi de le sécuriser (fonction de pare-feu et de serveur VPN). Cette version, nommée ISA Server 2000 propose de puissantes fonctions de surveillance (détection d’intrusions, rapports HTML, alertes…), de filtrage (filtres de paquets, règles de sites et de contenu…) et de gestion de la bande passante.

La dernière édition de proxy server, nommée ISA Server 2004 apporte de nombreuses améliorations : configuration simplifiée (nouvelle console MMC, gestion simplifiée des règles, multiples assistants de configuration), sécurité renforcée (filtrage au niveau applicatif, mise en quarantaine des clients VPN, support des méthodes d’authentification RSA SecureID et RADIUS…) et fonctionnalités supplémentaires sont de la partie (compression HTTP, sauvegarde au format XML, mode tunnel IPSec, monitoring en temps réel… ).

1.2 Les nouveautés offertes par ISA Server 2006

ISA Server 2006 est une évolution logique d’ISA Server 2004. A ce titre, toutes les fonctionnalités incluses dans ISA Server 2004 SP2 (gestion du QoS avec Diffserv, mise en cache du protocole BITS, compression HTTP…) sont reprises dans la nouvelle version du produit. Voici une liste non exhaustive des principales nouveautés et améliorations apportées depuis la version 2004 :

  • Intégration de l’authentification par formulaire Web pour les règles de publication Web
  • Implémentation d’un système d’ouverture de session unique (SSO) lorsque plusieurs sites Web sont publiés (OWA, SharePoint…)
  • Nouveaux assistants de publication pour les serveurs Web, SharePoint et les serveurs de messagerie
  • Meilleure gestion des certificats sur les ports d’écoute Web
  • Intégration de filtres Web supplémentaires
  • Intégration d’un assistant permettant de configuration automatiquement une connexion VPN dans un site distant
  • Synchronisation entre les serveurs ISA et les serveurs CSS améliorée
  • Nouveau système de gestion des flux permettant de détecter des attaques DoS

1.3 Les différentes éditions d’ISA Server 2006

A l’instar des versions précédentes d’Internet Security & Acceleration, ISA 2006 est disponible en édition Standard mais aussi en édition Entreprise. Comme aujourd’hui avec ISA 2004, les deux versions seront très proches hormis quelques fonctionnalités réservées à la version entreprise. Voici la liste des spécificités de cette dernière version :

  • Support de plus de quatre processeurs physiques

  • Système de stockage centralisé permettant d’appliquer une configuration uniforme sur de nombreux serveurs ISA

  • Support du Network Load Balancing (NLB) avec basculement automatique (y compris sur les liaisons VPN site-à-site)

  • Support de la mise en cache hiérarchisée via le protocole CARP (Cache Array Routing Protocol)

1.4 L’intégration aux Appliances : un enjeu important pour l’avenir

Introduction

Pour augmenter les ventes de son pare-feu, mais aussi pour séduire les amateurs de pare-feu “matériels”, Microsoft s’est associé avec de grands constructeurs pour fournir des “appliances” basées sur Windows Server 2003 et ISA Server 2004. On peut citer Hewlett Packard (HP), Celestix, Corrent, Network Engines, RimApp ou bien encore SecureGuard. Une liste complète des partenaires de Microsoft sur les appliances ISA Server 2004 est disponibleici.

Les appliances actuellement basées sur ISA Server 2004 intègrent une version optimisée de Windows Server 2003 ainsi que l’édition standard d’ISA (à l’heure actuelle aucune appliance n’intègre l’édition entreprise).

Pour rappel une appliance est un système prêt à l’emploi et dédié à exécuter une tâche bien précise (serveur Web, serveur d’impression, pare-feu…). Ci-contre l’appliance de la société Network Engines.

Un système clés en main ?

Sur une appliance l’administrateur n’a pas directement accès au système et à la console de configuration classique d’ISA Server. En effet la plupart du temps le constructeur de l’appliance développe une interface Web spécifique. La capture d’écran ci-dessous présente l’interface intégrée à l’appliance MSA4000 de Celestix :

Outre ce système d’administration via interface Web, les appliances proposent de nombreux avantages :

  • matériel spécialement sélectionné et soigneusement dimensionné (l’appliance HP Proliant DL320 intègre par exemple un processeur Pentium4 cadencé à 3GHz, 1Go de RAM, un disque dur de 80Go en SATA ainsi que plusieurs cartes réseau gigabit utilisant l’interface PCI-X).

  • sécurité de la configuration garantie par le constructeur (la version de Windows Server 2003 incluse dans les appliances a été configurée par les ingénieurs de la marque de manière à être la plus sécurisée possible; de plus le constructeur fourni généralement un système de mise à jour automatique – cela induit donc un gros gain de temps pour l’administrateur qui n’a pas besoin de se soucier de la sécurité du système)

  • déploiement rapide du service (la plupart des appliances sont opérationnelles en quelques minutes !)

ci-dessus, les appliances de Celestix et de Pyramid Computer

Les appliances sont donc des produits livrés “clés en main” contrairement aux serveurs ISA “classiques” qui nécessitent de longues et fastidieuses phases de configuration. En effet avant d’arriver à un système parfaitement fonctionnel et sécurisé sur un serveur ISA il faut passer par les étapes suivantes :

  • Prise de renseignements pour dimensionner/construire le serveur en fonction des besoins (nombre de clients, bande passante de la connexion Internet, mise en ouvre de la haute disponiblité…)

  • Installation matérielle et logicielle du serveur

  • Sécurisation du pare-feu (principalement au niveau du système d’exploitation)

  • Configuration d’ISA Server

  • Optimisation des performances

  • Avec une appliance, l’utilisateur final n’a pas à se soucier de toutes ces étapes : la seule chose à faire est de raccorder la machine au réseau, puis de la configurer à l’aide de l’interface Web dédiée. De plus le coût du matériel et des licences logicielles pour Windows Server 2003 et ISA se fondent au sein d’une seule et même facture ce qui est plus pratique à gérer.

    Des options supplémentaires…

    Pour se démarquer de la concurrence, la plupart des constructeurs intègrent des matériels spécifiques ou bien incluent des fonctionnalités supplémentaires au sein de leur produits ! Ainsi il n’est pas rare de voir des appliances intégrant en standard un anti-virus, un anti-spam ou bien encore un système de filtrage des URLs (dans le but de bloquer les URLs utilisées à but promotionnel ou malveillant : phishing, trojans, etc.). Le matériel peut aussi être adapté et certains constructeurs comme HP ajoutent des cartes accélératrices SSL pour augmenter les performances du chiffrement, des systèmes ou bien des systèmes de tolérances de panne matériel !

    Quid des appliances avec ISA 2006 ?

    Le marché des appliances étant florissant, le concept des appliances basées sur ISA restera bien sur d’actualité avec la nouvelle mouture du pare-feu de la firme de Redmond ! Cette fois-ci, il sera possible d’acheter une appliance basée sur l’édition standard d’ISA 2006 mais aussi sur l’édition entreprise ! De plus les appliances ISA 2006 intégreront directement Windows Server 2003 R2 plutôt que Windows Server 2003 SP1.

    Les appliances intégrant ISA 2006 devraient être encore plus nombreuses que celles basées sur ISA 2004 (actuellement on dénombre une dizaine de marques commercialisant des appliances ISA 2004). En effet, d’autres partenaires devraient rejoindre les constructeurs travaillant actuellement avec Microsoft.

    1.5 Vers un produit plus fiable et plus complet ?

    La version actuelle d’ISA Server 2006 intègre une section nommée “programme d’amélioration du produit”. Le but de ce système de feedback, mis en place avec le Service Pack 2 d’ISA Server 2004, est bien évidemment d’améliorer la qualité et la fiabilité des produits Microsoft. Il est présent au sein de cette beta mais devrait toujours être intégré à la version finale du produit !

    Cela montre vraiment la volonté qu’à Microsoft de se détacher de cette image de développeur commercialisant des produits peu fiables et remplis de bugs ! En effet, grâce à ce système l’équipe technique d’ISA 2006 est automatiquement averti au moindre bug rencontré par l’utilisateur. Cela devrait permettre une vitesse de correction des bugs dans un temps record !

    Bien entendu, toutes les informations collectées sont totalement anonymes et ne concernent en rien l’identité de l’utilisateur ou bien l’utilisation qu’il fait de sa machine ! Il est tout à fait possible de ne pas participer à ce programme (c’est d’ailleurs le cas par défaut). De plus, ceux qui ont activés l’option peuvent revenir en arrière à tout moment !

    1.6 Essayez ISA Server 2006 gratuitement !

    Une fois n’est pas coutume, la Beta1 du produit est ouverte au public ! Sans doute une autre manière de montrer la volonté d’ouverture de Microsoft qui se rapproche de plus en plus du monde du libre… du moins lorsqu’il s’agit de trouver un maximum de testeurs pour ses produits. Cette version Beta est utilisable pendant 210 jours ce qui est sans doute une indication sur la commercialisation du produit (officiellement durant le 2ème semestre 2006) même sicette page du site officiel de Microsoft mentionne plutôt l’été 2006.

    Les deux éditions d’ISA Server 2006 peuvent être téléchargéesdirectement sur le site de Microsoft. Vous devrez bien sur posséder un compte Passport .net pour accéder à la page de téléchargement. Le fichier, d’une taille de 49,9 Mo quelle que soit l’édition considérée est disponible uniquement en version anglaise. Avis aux développeurs, le kit de développement (SDK) est également disponible !

    Dans la suite de cet article l’édition Standard sera souvent nommée SE (pour Standard Edition) et l’édition entreprise EE (pour Enterprise Edition).

    Déploiement d’ISA Server 2006

    2.1 Configuration minimale

    Voici la configuration minimale requise pour exécuter ISA Server 2006 :

    Minimum requis
    processeur Pentium III 550 MHz ou plus puissant
    mémoire vive Au moins 256Mo (plus si la mise en cache est activée)
    disque dur 150Mo d’espace libre pour l’installation De l’espace supplémentaire est nécessaire pour la mise en cache Les partitions doivent être formatées en NTFS
    carte réseau Deux cartes réseaux ou plus pour les fonctionnalités liées au pare-feu Une seule carte réseau si ISA est uniquement utilisé en tant que serveur de proxy
    système d’exploitation Windows Server 2003 SP1 (sauf édition Web) Windows Server 2003 R2 (toute édition)
    navigateur Internet Explorer 6.0 ou une version supérieure

    Les pré-requis sont identiques à ceux d’ISA Server 2004 sauf pour la partie logicielle ! En effet si ISA 2004 pouvait être déployé sous Windows 2000 Server ça n’est plus le cas d’ISA 2006 qui nécessite au moins Windows Server 2003 SP1.

    2.2 Installation d’ISA Server 2006 édition standard

    Avant de commencer l’installation d’ISA Server 2006, l’administrateur doit s’assurer que la résolution de noms et le routage des paquets fonctionnent correctement à travers le serveur. Il faut aussi passer par une phase de renforcement de la sécurité au niveau du système d’exploitation (installation des correctifs, désactivation des composants inutiles sur les cartes réseau, désactivation des services inutiles…).

    Une fois ces pré-requis remplis, il suffit d’insérer le CD-ROM d’ISA, puis de lancer la procédure d’installation à l’aide du lien Install ISA Server 2006. La suite de la procédure d’installation est strictement identique à celle d’ISA Server 2004 SE; c’est pourquoi elle ne sera pas expliquée ici. Néanmoins, si vous souhaitez connaître tous les détails de la procédure, vous pouvez consulter ce petit pas-à-pas !

    La seule différence notable avec ISA 2004 est la disparition du “Filtreur de message” et du “Partage du logiciel client pare-feu” dans la liste des composants disponibles. En ce qui concerne le partage, cette suppression est surement voulue étant donné que le but premier du serveur ISA n’est pas de jouer le rôle de point de distribution logiciel (serveur de fichiers) !

    Il n’est donc pas possible, à l’heure actuelle, de bloquer des emails en fonction des expéditeurs, des pièces jointes ou bien encore de certains mots clefs (car ces fonctionnalités sont inhérentes au composant filtreur de message) ! Microsoft n’a pas encore communiqué quoi que ce soit sur ce point; cependant nul doute que les fonctionnalités anti-spam d’ISA Server 2004 sont en train d’être revues à la hausse et apparaîtront dans les prochaines versions du serveur. On peut supposer que le système de filtrage des courriers non-sollicités se rapprochera du système IMF (Intelligent Message Filter) intégré au sein du SP2 d’Exchange Server 2003.

    Pour les administrateurs désirant automatiser l’installation du serveur ISA, il est toujours possible de créer un fichier de réponse contenant tous les paramètres du processus d’installation voire de créer un script installant automatiquement un serveur ISA préconfiguré dans un site distant. Quel que soit le type de déploiement (manuel ou automatisé), il est recommandé de vérifier les points suivants une fois l’installation terminée :

    • Vérification des services ISA (les services Contrôle de Microsoft ISA Server, Pare-feu Microsoft, Planificateur de tâches Microsoft ISA Server et Espace de stockage Microsoft ISA Server doivent être installés et doivent être démarrés)

    • Vérification des services MSDE (les services MSSQL$MSFW et MSSQLServerADHelper doivent être présents si le composant Journalisation avancée a été choisi)

    • Vérification des fichiers journaux d’installation (les trois fichiers ISAWRAP_xxx, ISAMSDE_xxx et ISAFWSV_xxx situé dans le répertoire %WINDIR%\temp contiennent les détails du processus d’installation et doivent indiquer que l’installation s’est correctement déroulée)

    Il est aussi intéressant de consulter le journal Application grâce à l’Observateur d’évènements. L’évènement 11707 (Type: Information, source : MsiInstaller) indiquant que l’installation s’est bien déroulée doit normalement être présent (cf. capture d’écran ci-contre).

    2.3 Installation d’ISA Server 2006 édition entreprise

    Pour déployer ISA Server 2006 édition entreprise (EE) les options d’installations sont similaires à celles d’ISA 2004 EE ce qui laisse quatre choix à l’opérateur :

    • Installer uniquement les services ISA Server

    • Installer uniquement un serveur de stockage de configuration

    • Installer un serveur de stockage de configuration ainsi que les services ISA Server

    • Installer uniquement la console d’administration

    La suite de la procédure est identique à celle d’ISA Server 2004 EE (hormis la disparition des composants “Filtreur de message” et “partage du logiciel client pare-feu” – cf. section ci-dessus) et ne présente aucune difficulté. Si vous n’avez jamais installé l’édition entreprise d’ISA Server 2004, nous vous conseillons de consulter cette page qui détaille toute la procédure !

    Avec ISA Server 2006 EE, les paramètres des services ISA sont stockés sur un serveur dédié nommé serveur de stockage de configurations ou CSS (Configuration Storage Server) et non plus dans le registre local ! C’est grâce à cette fonctionnalité qu’il est possible de déployer une configuration standardisée sur de multiples serveurs ISA. Si vous n’êtes pas familier avec la notion de serveur CSS, ni avec le Mode Application Active Directory (ADAM), vous pouvez consulter cet article sur ISA Server 2004 édition entreprise.

    Remarque : Lorsque l’on souhaite installer un serveur ISA 2006 EE au sein d’un groupe de travail, on doit créer la grappe de serveurs en même temps que le serveur ISA (en effet si on crée la grappe à l’avance, le type d’authentification est automatiquement configuré à Authentification Windows et il est impossible d’ajouter le serveur ISA au sein de la grappe). Il est dommage que ce bug, hérité d’ISA Server 2004, n’ai pas été corrigé ! 🙁

    2.4 Les différents scénarios de mise à jour vers ISA 2006

    Il est bien entendu possible de mettre à jour une infrastructure ISA Server 2004 vers ISA 2006. Cela est aussi faisable à partir d’ISA 2000; cependant il faut passer par ISA Server 2004 en tant que système intermédiaire (nous supposons que la licence de migration ISA 2000 vers 2004 est offerte à l’instar des migrations de Windows NT 3.51 vers Windows XP Professionnel où la licence transitoire pour Windows NT 4.0 est offerte) ! L’installeur d’ISA 2006 ne propose d’ailleurs plus d’assistant permettant de sauvegarder la configuration d’ISA 2000 dans un fichier XML (il faut donc utiliser l’assistant de migration inclus dans ISA 2004 – pour plus d’informations sur la migration d’ISA 2000 vers ISA 2004,vous pouvez consultez cette procédure).

    Remarque : l’utilisation de Windows Server 2003 SP1 est un pré-requis à la migration vers ISA Server 2006 ! Il est donc impossible de mettre à jour un serveur ISA 2000/2004 sous Windows Server 2000 sans mettre à jour au préalable le système d’exploitation. Il est aussi recommandé d’installer le SP2 d’ISA Server 2004 avant de lancer la migration vers ISA 2006.

    Le tableau suivant récapitule les différentes possibilités pour mettre à jour ISA 2000/2004 vers ISA Server 2006 :

    système d’origine Mise à vers vers ISA 2006 SE Mise à vers vers ISA 2006 EE
    ISA 2000 SE
    ISA 2000 EE
    ISA 2004 SE
    ISA 2004 EE

    Il est toujours impossible de passer de l’édition standard d’ISA 2006 à l’édition entreprise d’ISA 2006 sans désinstaller complètement l’édition standard. Microsoft a aussi précisé que les personnes ayant installé cette version Beta1 d’ISA 2006 pourront effectuer une mise à jour vers la version Release Candidate (RC), puis finalement vers la version Release To Manufacturing (RTM) ou version finale du produit !!! 🙂

    Etant donné qu’ils ne sont actuellement plus implémentés au sein d’ISA Server 2006, il faut impérativement désinstaller les composants “Filtreur de message” et “Partage du logiciel client pare-feu” si ils sont activés ! Lorsque l’un de ces composants est présent sur le serveur ISA, la fenêtre d’avertissement ci-contre apparaît.

    Si vous souhaitez obtenir plus d’informations sur ces deux composants, merci de vous référez à la section ci-dessus (2.2 Installation d’ISA Server 2006 édition standard).

    Durant le processus de mise à jour les services ISA sont inopérants !!! Il est donc obligatoire de déconnecter la connexion Internet avant de lancer la migration vers ISA Server 2006 !!! Il est aussi FORTEMENT RECOMMANDE de sauvegarder la configuration du serveur ISA au format XML avant l’opération !

    2.5 Mise à jour vers ISA Server 2006 SE à partir d’ISA Server 2004 SE SP2

    Dans le cadre de la mise à jour d’un serveur exécutant Microsoft ISA Server 2004 édition standard, deux options sont offertes à l’administrateur :

    • Installer directement ISA Server 2006 sur ISA 2004 (on parle de mise à jour sur place)
    • Installer ISA Server 2006 sur un nouveau serveur matériel, puis importer la configuration du serveur ISA 2004

    Dans tous les cas, il est recommandé de sauvegarder la configuration du serveur ISA 2004 au format XMLmais aussi les fichiers journaux. En effet, les fichiers journaux d’ISA Server 2004 sont incompatibles avec ceux de la nouvelle édition !

    Le fonctionnement simultané d’ISA 2004 SE et d’ISA 2006 SE sur le même réseau ne pose bien évidemment aucun problème ! Cependant cela entraînera un effort administratif supplémentaire étant donné que les deux versions de la console Gestion ISA Server devront être déployés sur les postes utilisés pour la configuration des serveurs ISA. En effet il n’est malheureusement pas possible d’utiliser la console ISA 2006 pour paramétrer un serveur exécutant ISA 2004 et inversement.

    2.6 Mise à jour vers ISA Server 2006 EE à partir d’ISA Server 2004 EE SP2

    Avant de mettre à jour des serveurs exécutant ISA Server 2004 EE, il faut au préalable “mettre à jour” le serveur de stockage de configurations (CSS). Voici la procédure à suivre pour réaliser cette opération :

  • Sauvegarde de la configuration de l’entreprise ISA Server à l’aide de la console MMC

  • Désinstallation d’ISA Server 2004 sur le serveur CSS principal

  • Installation d’ISA Server 2006 sur le serveur CSS principal

  • Importation de l’entreprise ISA Server à l’aide de la console MMC

  • Si l’Entreprise ISA Server est hébergée sur d’autres serveurs CSS (réplicas), il faut désinstaller ISA 2004 sur ces machines, puis créer de nouveaux réplicas sous ISA Server 2006. A partir du moment où les serveurs CSS exécutent ISA Server 2006, aucun serveur ISA 2004 n’est capable de se synchroniser (il fonctionnent uniquement avec la configuration mise en cache localement). Il faut alors réaliser une mise à jour sur place ou mise à jour sur site (in-place upgrade) sur chacun des serveurs ISA ! Avant de migrer les serveurs ISA, il faut penser à les déconnecter du réseau (Internet).

    Pour qu’une grappe de serveurs soient fonctionnelle, tous les serveurs ISA membre de cette grappe doivent impérativement exécuter la même version d’ISA (ISA 2004 ou ISA 2006). Il possible de faire cohabiter des grappes de serveurs sous ISA 2004 avec des grappes de serveurs sous ISA 2006. Cependant un tel environnement mixte nécessite l’utilisation de deux serveurs de stockage de configurations :

    • Un serveur CSS hébergeant les paramètres de l’Entreprise ISA Server 2004
    • Un serveur CSS hébergeant les paramètres de l’Entreprise ISA Server 2006

    Pour l’administration des serveurs, il faudra aussi utiliser les consoles MMC adéquates (la console ISA 2004 pour l4entreprise ISA 2004 et la console ISA 2006 pour l’Entreprise ISA 2006).

    Gestion de la publication sous ISA Server 2006

    3.1 Présentation des nouveaux assistants de publication

    Par rapport à ISA Server 2004, les assistants permettant de créer les règles de publication ont été revus. On dispose maintenant des cinq assistants suivants :

    • Publication d’un accès Web Exchange : cet assistant permet de configurer un accès OWA (Outlook Web Access), OMA (Outlook Mobile Access), ActiveSync ou RPC over HTTP – l’assistant prend aussi en compte la version d’Exchange utilisée (5.5, 2000, 2003 et Exchange 12 !)
    • Publication d’un serveur de courrier : cet assistant permet de configurer un accès client “classique” via les protocoles SMTP, POP3, IMAP4 et RPC (pour les clients MAPI). Il permet aussi de configurer la communication entre serveurs de messagerie (SMTP ou NNTP)
    • Publication d’un site SharePoint : cet assistant permet de configurer l’accès à un portail SharePoint 2003
    • Publication d’un site Web : cet assistant permet de configurer l’accès à un site Web (HTTP) ou à un site Web sécurisé (HTTPs). Plusieurs options sont disponibles : publication d’un seul site Web, publication d’une ferme de serveurs utilisant l’équilibrage de la charge réseau (NLB), publication de plusieurs sites Web simultanément.
    • Publication de serveur : cet assistant permet de publier n’importe quel type de serveur utilisant un protocole basé sur TCP/IP

    3.2 Gestion des certificats sur les ports d’écoute Web

    Un système de vérification a aussi inclut au niveau de la validité des certificats numériques ! Ainsi le serveur ISA vérifie…

    • Le nom commun du certificat (il doit être identique au nom public de la règle de publication)

    • Le modèle du certificat (il doit correspondre au modèle “Serveur Web”)

    • La date d’expiration du certificat

    • La présence de la clé privée (le serveur ISA a besoin de la clé privée pour déchiffrer les données)

    Lorsque l’une de ces conditions n’est pas remplie, un message d’avertissement expliquant le problème est automatiquement affiché dans l’onglet Port d’écoute de la règle de publication. Voici un exemple de message :

    De plus, deux nouvelles alertes nommées “le certificat du serveur ISA va bientôt expirer” et “le serveur ISA du serveur ISA est invalide” permettent de dépanner plus facilement les problèmes liés à l’expiration des certificats et à l’utilisation de certificats invalides !

    3.3 Gestion de la traduction de liens dans ISA 2006

    Rappels sur la traduction de liens :

    La traduction de liens est utile lorsqu’un site Web ou une application Web renvoie des références au nom interne du serveur. En effet dans le cadre d’une publication de serveur, il faut impérativement que l’internaute reçoive un nom public (ex. : http://www.laboms.com/images/2567.jpg) et non un nom interne (ex. http://WEB2:8082/images/2567.jpg).

    La traduction de liens permet justement de modifier à la volée les références au nom interne du serveur pour les remplacer par le nom public (lorsque le serveur Web renverra un lien vers une ressource de type http://WEB2:8082/images/2567.jpg, le serveur ISA sera capable de remplacer « WEB2:8082 » par « www.laboms.com » pour obtenir une URL utilisable par le client externe). La traduction de lien se configure uniquement au niveau des règles de publication Web et est souvent utilisée dans le cadre de la publication d’un site Web OWA (notamment lorsque le site OWA est hébergé sur un port “exotique”).

    Pour configurer des mappages spécifiques, il suffit d’activer la traduction de liens dans les propriétés de la règle, puis de créer des mappages à l’aide du bouton Configure… (cf. capture d’écran ci-à-droite).

    Gestion de la traduction de liens au sein d’ISA 2006

    Lorsque la traduction de liens est activée au niveau d’une règle de publication Web (publication d’un site Sharepoint, d’un serveur OWA, d’un site Web SSL…), ISA Server crée automatiquement un dictionnaire contenant tous les mappages implicites (par exemple la configuration de l’adresse IP du serveur Web dans l’onglet To engendre automatiquement la création d’un mappage) ainsi que ceux explicitement définis par l’administrateur (à l’aide du bouton Configure…).

    Un dictionnaire général est aussi créé au niveau de chaque grappe de serveurs ISA. Ce dictionnaire correspond tout simplement à la concaténation de tous les dictionnaires spécifiques aux règles de publications définies au niveau de la grappe !

    Avec ISA Server 2006, il est dorénavant possible de concaténer les dictionnaires de plusieurs grappes en activant la traduction de liens inter-grappes directement au niveau de l’entreprise ISA Server. Cela peut notamment s’avérer utile lorsque le même site Web (ou du moins avec un nom public identique) est publié au niveau de deux grappes différentes.

    En cas de conflit entre un mappage défini au niveau d’une règle et un mappage général, c’est toujours le mappage définit au niveau de la règle qui s’applique !

    Visualisation des mappages à l’aide de l’interface Web

    La principale nouveautés apportée par ISA 2006 au niveau de la traduction de liens, reste l’intégration d’une interface Web permettant de visualiser directement les URLs AVANT ET APRES translation. Cela permet à l’administrateur de pouvoir s’y retrouver plus facilement, surtout lorsque de nombreux mappages et de nombreuses règles de publication Web sont configurées. Pour accéder à cette interface, il suffit de cliquer sur le bouton Mappings…dans l’onglet Link Translation (littéralement traduction de liens) d’une règle de publication Web. La capture d’écran ci-dessous présente une partie de cette interface Web :

    Autre différence par rapport à ISA Server 2004 : les types de contenus sur lesquels s’applique la traduction de liens se configurent maintenant dans la section Configuration / Général et non dans les propriétés de la règle de publication !

    3.4 Publication d’une ferme de serveurs Web

    Avantage d’ISA Server 2006 par rapport aux version précédentes

    ISA Server 2004 permet bien évidemment de publier une ferme de serveurs Web utilisant l’équilibrage de la charge réseau (NLB). Dans ce cas, le serveur ISA se contente de rediriger les requêtes HTTP vers l’adresse IP virtuel du cluster NLB.Avec ISA Server 2006 la mise en place d’une ferme de serveur Web est revue !En effet, la répartition de charge n’est plus assurée par les serveurs Web en eux-mêmes mais directement par le serveur ISA ! Avec ce système il n’est donc plus nécessaire de mettre en place le NLB sur les serveurs Web ce qui simplifie énormément la mise en place d’un site Web hautement disponible (En revanche à partir du moment où la haute disponibilité est impérativement recherchée, il faut aussi assurer une tolérance de panne au niveau du serveur ISA ainsi qu’au niveau de la connexion Internet) !

    Configuration de l’élément de stratégie

    Pour mettre en place une répartition de charge au niveau du serveur ISA 2006, il faut dans un premier temps, créer un élément de stratégie de type “ferme de serveur”, puis, dans un second temps, créer une règle de publication Web utilisant cet élément de stratégie.

    L’élément de stratégie de type Ferme de serveurs doit être crée dans la section Objets de réseau. Durant sa création les informations suivantes doivent être indiquées :

    • Liste des serveurs Web de la ferme

    • Méthode utilisée pour vérifier que tous les serveurs Web de la ferme sont actifs (trois méthodes sont disponibles : envoie d’une requête d’écho, envoi d’une requête HTTP GET ou bien établissement d’une connexion TCP sur un port donné)

    Lorsqu’un objet Ferme de serveurs est crée dans la console Gestion ISA Server, un vérificateur de connectivité est automatiquement crée pour chaque serveur Web présent dans l’élément de stratégie. Ces vérificateurs de connectivités permettent au serveur ISA d’être automatiquement averti lorsque l’un des serveurs Web de la ferme est hors ligne (cela revient à la notion de pulsation ou “heartbeats” avec le clustering). Lorsque l’un des serveurs Web ne répond plus, le serveur ISA cesse de lui envoyer des requêtes et re-répartie automatiquement le trafic réseau entre les serveurs Web restants !

    Dans l’exemple ci-dessous, deux fermes de serveurs nommées “Site du laboratoire Microsoft” et “Test” ont été crée. Chacune de ces fermes contient trois serveurs Web. Un total de six vérificateurs de connectivité a donc été crée (un vérificateur par serveur Web).

    Configuration de la règle de publication

    Durant la création de la règle de publication, il faut choisir l’option “Publish a server farm of load-balanced Web servers” pour que le serveur ISA puisse répartir les requêtes entre les serveurs Web, puis sélectionner un mode pour l’affinité entre les clients externes et le serveur ISA. Deux paramètres sont disponibles :

    • Affinité basée sur les cookies
    • Affinité basée sur les adresses IP

    Selon le type de site Web publié, mieux vaut utiliser une méthode plutôt qu’une autre. Par exemple dans le cadre de la publication d’un site OWA ou Sharepoint, il est recommandé d’utiliser l’affinité basée sur les cookies alors que dans le cadre de la publication d’un accès à la messagerie RPC over HTTP l’autre méthode s’avère plus efficace.

    Maintenance d’une ferme de serveurs

    Lorsque l’administrateur souhaite effectuer des tâches de maintenance sur l’un des serveurs Web de la ferme de serveurs, cela ne pose aucun problème. En effet, il suffit de définir la machine comme étant en pause (état “Drained” dans la capture d’écran ci-contre); ainsi, le serveur ISA cesse d’envoyer de nouvelles requêtes à ce serveur Web. En revanche toutes les sessions actuellement actives entre des clients externes et ce serveur Web continueront à être traitée par la machine.

    Ce système de “désactivation” ou de mise hors ligne de l’un des serveurs de la ferme évite de devoir mettre fin brusquement à toutes les sessions ouvertes sur ce serveur et permet d’interrompre le moins possible la disponibilité du service pour les clients ! Pour que le système soit encore plus efficace l’administrateur doit planifier ses interventions (par exemple en désactivant le serveur 24h avant la manipulation).

    Mise en place de l’authentification dans le cadre d’une publication

    4.1 Introduction au mécanisme d’authentification

    La mise en place d’un système d’authentification permet d’augmenter fortement le niveau de sécurité global d’une entreprise et ce à tout niveau (authentification pour l’accès au partages de fichiers, pour l’accès Internet, pour l’accès au réseau sans fil, pour l’accès VPN…). Malheureusement cet aspect est trop souvent négligé (notamment sur les réseaux sans fil où les méthodes d’authentification i802.11x sont rarement implémentées). Conscient de ce problème, Microsoft tente de sensibiliser les administrateurs à ce sujet et essaye de faciliter la mise en place de l’authentification au sein de ses produits. ISA Server 2006 intègre d’ailleurs de nombreuses nouveautés en terme d’authentification comme…

    • Le support de l’authentification basée sur les formulaire
    • Le support de l’authentification Active Directory – LDAP
    • L’ouverture de session unique (SSO)
    • Etc.

    4.2 Intégration de l’authentification basées sur les formulaires

    ISA Server 2004 implémente une méthode d’authentification nommée OWA Forms-based permettant d’authentifier les clients Outlook Web Access directement au niveau du serveur ISA plutôt qu’au niveau du serveur Exchange. Ce concept d’authentification par formulaire Web a été largement amélioré au sein d’ISA Server 2006. En effet, il est dorénavant possible d’utiliser ce système sur n’importe quel site Web (HTTP / HTTPs) sans aucune contrainte. Le gros avantage est bien sur de pouvoir authentifier les utilisateurs directement au niveau du serveur ISA ce qui améliore les performances et évite de gaspiller de la bande passante. La capture d’écran ci-dessous présente l’interface Web d’authentification utilisée par défaut avec ISA Server 2006 :

    A l’instar d’Outlook Web Access, deux modes de connexions sont proposées selon le type de machine utilisée : ordinateur privé ou ordinateur public/partagé. Lorsque le paramètre “ordinateur public ou partagé” est utilisée, aucune information confidentielle (sous la forme de cookie par exemple) n’est conservée sur le poste client ce qui permet d’augmenter la sécurité.

    Lorsque l’administrateur souhaite utiliser l’authentification par formulaire Web sur un ou plusieurs règles de publication, il doit aussi sélectionner la base de compte ainsi que la méthode d’accès à cette base de compte. Voici la listes des options actuellement disponibles :

    • Active Directory (Windows)
    • Active Directory (LDAP)
    • RADIUS
    • RADIUS OTP
    • RSA SecureID

    Il est bien sur possible de modifier le formulaire par défaut de manière à personnaliser la fenêtre d’authentification aux couleurs de l’entreprise (comme c’est d’ailleurs le cas avec le système d’authentification par formulaire intégré à Exchange). On peut aussi paramétrer un certain nombre d’options comme la gestion des cookies ou bien encore la durée de vie d’une session inactive (cette TTL peut être différente selon que l’accès est réalisé à partir d’un ordinateur “public” ou “privé”).

    4.3 Implémentation de l’ouverture de session unique (SSO) sur un port d’écoute Web

    Il arrive fréquemment qu’une entreprise utilise un seul nom de domaine pour publier plusieurs sites Web internes (cela permet de réduire les coûts car il suffit d’acheter un unique domaine DNS). Cette fonctionnalité est fournie par l’intégration d’un système de traduction de liens au niveau des règles de publication Web (exactement le même que celui d’ISA 2004). La traduction de lien permet par exemple :

    ISA Server 2006 va encore plus loin car il permet de mettre en place une ouverture de session unique ou SSO (Single Sign On)sur tous les sites Web publiés au niveau du serveur ISA ! Ainsi lorsqu’un utilisateur a entré une fois ses informations d’indentifications, elles ne lui sont plus demandées pour toute la durée de sa session et ce, même si il passe d’un site Web à l’autre. Par exemple lorsqu’un utilisateur s’authentifie sur http://site1.laboms.com, il n’a pas besoin de se ré-authentifier pour accéder au sitehttp://site2.laboms.com !

    Ce système d’ouverture de session unique n’est supporté que lorsque l’authentification par formulaire a été choisie ! Pour l’activer, il suffit de côcher la case Enable Single Sign On dans l’onglet SSO du port d’écoute Web considéré.

    L’administrateur doit aussi lister tous les domaines au niveau desquels l’ouverture de session unique doit être activée ! Dans l’exemple ci-contre, le SSO est activé pour le domaine Active Directory *.laboms.com. Cela permet aux utilisateurs du site OWA (http://mail.laboms.com) de ne pas avoir à se ré-authentifier lorsqu’ils accèdent au site Web http://www.laboms.com !

    4.4 Rappels sur les différentes méthodes d’authentification intégrée à ISA 2006

    Voici un récapitulatif de toutes les méthodes d’accès utilisables sur une règle de publication avec ISA Server 2006 :

    Méthode Explication
    De base Cette méthode envoie l’identifiant et le mot de passe de l’utilisateur en clair sur le réseau. Il ne faut donc jamais l’utiliser sauf si on l’utilise de concert avec le protocole SSL (Secure Socket Layer) pour chiffrer les données !
    Digest Cette méthode est plus sécurisée que l’authentification de base car le mot de passe est envoyé de façon hachée (cryptage non réversible). Pour fonctionner, le protocole Digest à besoin de deux pré-requis :
    • Les contrôleurs de domaine doivent exécuter Windows 2000 Server ou Windows Server 2003
    • Les contrôleurs de domaine doivent stocker les mots de passe des utilisateurs avec un cryptage réversible (cette option est configurable dans la partie « Configuration Ordinateur / Paramètres Windows / Paramètres de sécurité / Stratégie de compte / Stratégie de mot de passe » d’un objet stratégie de groupe)

    L’utilisation de Digest est donc à proscrire car elle fait énormément baisser le niveau de sécurité du domaine Active Directory (en effet les mots de passe ne doivent pas être stockés de manière réversible).

    ISA Server 2004 supporte aussi la méthode WDigest qui est une évolution de Digest. Pour activer cette méthode, il suffit de côcher la case « Digest » et d’utiliser uniquement des contrôleurs de domaines et des serveurs ISA sous Windows Server 2003. L’avantage de WDigest est qu’il ne nécessite pas que les mots de passe soient stockés de manière réversible dans Active Directory.

    Intégrée à Windows Cette méthode utilise le protocole d’authentification Kerberos V5 (ou bien le protocole NTLM). Son niveau de sécurité est élevé (il utilise le hachage des données et propose une authentification mutuelle). Cependant il nécessite que tous les clients utilisent Internet Explorer. Les clients pare-feu utilisent toujours l’authentification intégrée à Windows et il n’est pas possible de modifier ce paramètre.
    certificat numérique Cette méthode utilise des certificats numériques pour identifier les utilisateurs. Pour mettre en place cette méthode, il faut donc disposer d’une infrastructure à clés publiques ou infrastructure PKI et posséder une ou plusieurs autorités de certification internes (des autorités de certification commerciales peuvent éventuellement être utilisées). Un certificat de type « Utilisateur » doit être attribué à chaque utilisateur. Ce sont les informations contenues dans ce certificat qui permettront d’identifier l’utilisateur. Cette méthode d’authentification n’est pas supportées par les clients du proxy Web (ni par les clients pare-feu qui n’utilisent que l’authentification intégrée à Windows) mais elle est souvent utilisée dans le cadre d’une publication de serveur Web (cf. section 5 sur la publication).
    RADIUS RADIUS est un protocole d’authentification standardisé qui peut être utilisé dans de nombreux scénarios. Ainsi il permet d’authentifier, les clients du proxy Web mais aussi les utilisateurs VPN, les utilisateurs du réseau sans fil et les utilisateurs externes dans le cadre d’une publication de serveur Web.

    Pour que le serveur ISA utilise l’authentification RADIUS, il faut le configurer pour pointer vers un serveur RADIUS situé dans le réseau interne. En effet, avec cette méthode, ce n’est pas le serveur ISA qui authentifie les clients mais le serveur RADIUS (le serveur ISA se contente de rediriger les demandes d’authentification vers le serveur RADIUS).

    Pour augmenter la sécurité du trafic d’authentification, il est recommandé d’utiliser IPSec pour chiffrer les données entre le serveur ISA et le serveur RADIUS.

    Lorsque l’authentification RADIUS est utilisée avec les clients du proxy Web ou bien dans le cadre d’une règle de publication, les requêtes sont encapsulées dans le protocole HTTP. Cela est permis par le filtre d’authentification RADIUS (radiusauth.dll).

    RSA SecureID RSA SecureID est la méthode d’authentification à deux facteurs la plus utilisée au monde. Pour s’authentifier l’utilisateur doit utiliser un objet qu’il possède (l’authentificateur) ainsi qu’une information qu’il connaît (un code pin). L’authentificateur est un périphérique permettant de générer un code utilisable une fois (on parle de clé physique) et le code pin est généralement un numéro à 4 ou 6 chiffres connu uniquement de l’utilisateur. Cette méthode d’authentification est uniquement disponible pour les règles de publication Web et ne s’applique pas aux règles d’accès. Contrairement aux 5 méthodes précédemment étudiées, l’authentification RSA SecureID s’active au niveau d’un port d’écoute Web (cf. section 5). Le support de cette méthode d’authentification spécifique est fourni par le filtre SecureID (sdisa.dll).
    RADIUS OTP RADIUS OTP (pour One Time Password) est une méthode d’authentification multifactorielle permettant d’utiliser une carte à puce ainsi que son pin pour valider les informations d’identification de l’utilisateur. Pour plus de renseignements, vous pouvez consulter la RFC 1938.
    LDAP (Active Directory) Cette méthode est très proche de l’authentification intégrée à Windows. La principale différence est qu’elle peut être utilisée pour valider les informations d’identification des comptes stocké dans l’annuaire Active Directory même si le serveur ISA appartient à un groupe de travail ! En effet avec l’authentification intégrée à Windows, le serveur ISA doit impérativement être membre du domaine.

    Déploiement d’ISA Server 2006 dans un site distant

    5.1 Problématique du déploiement d’ISA Server 2004 EE dans un site distant

    La mise en place d’ISA Server 2004 SE (standard Edition) dans un site distant est relativement aisée. En effet l’administrateur peut par exemple prendre le contrôle du serveur à distance à l’aide du Bureau à distance, puis lancez l’installation du produit. ISA Server 2004 détecte automatiquement que l’installation se déroule au sein d’une session RDP et modifie la stratégie système de manière à ce que l’accès au serveur ISA via les services Terminal Server soit autorisé à partir de la machine de l’opérateur. Une fois l’installation terminée, il suffit de prendre le contrôle à distance du serveur ISA et de le configurer ! De plus lorsqu’aucun accès distant n’est disponible, l’administrateur a toujours la possibilité d’automatiser l’installation du serveur ISA à l’aide d’un fichier de réponse.

    Configuration d’ISA Server 2004 EE dans un site distant

    En revanche à partir du moment où l’on souhaite implémenter ISA Server 2004 EE (enterprise edition) dans un site distant, le challenge s’avère bien plus ardu. En effet avec l’édition entreprise, la configuration du serveur ISA n’est plus stockée dans une ruche du registre local mais au sein d’un serveur dédié nommé serveur de stockage de configurations. La plupart du temps le but est de synchroniser tous les serveurs ISA quel que soit leur site géographique auprès du serveur CSS (Configuration Storage Server) situé dans le site principal. Deux possibilité sont alors offertes à l’administrateur :

    • Configurer dans un premier temps un tunnel VPN site-à-site avec la console Routage et accès distant, installer ISA Server 2004 EE et configurer le serveur ISA pour récupérer ses informations de configuration auprès du serveur CSS situé dans le site principal

    • Installer directement ISA Server 2004 EE ainsi qu’un serveur CSS provisoire dans le site distant, créer un tunnel VPN site-à-site avec la console de gestion ISA, puis basculer le serveur ISA du site distant de manière à ce qu’il utulise le serveur CSS du site distant (enfin la dernière étape consiste généralement à supprimer le serveur CSS du site distant ou alors à le reconfigurer de manière à ce qu’il devienne un réplica de celui présent dans le site principal)

    Les deux scénarios compliquent fortement la tâche de l’administrateur surtout lorsque l’entreprise possède de nombreuses succursales et qu’ISA Server 2004 EE doit être déployé dans chaque succursale !

    Remarque : Si vous souhaitez obtenir obtenir plus de renseignements à propos de la mise en place d’ISA Server 2004 EE dans un site distant vous pouvez consulter cet article !

    5.2 Déploiement automatisé d’ISA Server 2006 SE/EE dans un site distant

    Conscient des difficultés de déploiement rencontrées par les administrateurs système, Microsoft a développé un outil permettant de simplifier au maximum le déploiement d’ISA Server 2006 SE mais aussi d’ISA Server 2006 EE dans un site distant. Cet outil nommé AppCfgWzd.exe est présent dans le répertoire d’installation d’ISA Server 2006 et permet d’automatiser entièrement l’installation d’ISA (lorsqu’il est associé avec un fichier de réponse pour ISA). Lorsqu’il est exécuté, il effectue les opérations suivantes sans nécessiter aucune intervention de la part de l’administrateur :

  • Création d’un tunnel VPN site-à-site entre le serveur ISA local et celui du site principal

  • Ajout du serveur ISA au domaine Active Directory situé dans le site principal (optionnel)

  • Configuration du serveur ISA local de manière à ce qu’il se synchronise auprès du serveur CSS du site principal

  • Ajout du serveur ISA local à l’une des grappes de serveurs de l’Entreprise ISA Server

  • Bien entendu avant d’exécuter cet outil dans un site distant, il faut renseigner toutes les informations nécessaires à la configuration du tunnel VPN et de l’Entreprise ISA Server. Cela passe par la configuration d’un fichier de réponse. Comme souvent chez Microsoft, un assistant est fourni pour faciliter la configuration du fichier de réponse. Dans le cas d’ISA Server, il suffit d’exécuter la commande appcfgwzd.exe -create_answer_file pour lancer l’assistant de configuration. Voici une liste non exhaustive des paramètres qui doivent être configurés par l’administrateur au sein de cet assistant :

    • Protocole de tunneling (L2TP/IPsec ou IPSec tunnel mode)

    • FQDN du serveur de stockage de configurations principal

    • Grappe de serveurs auquel le serveur ISA distant va appartenir

    • Etc.

    Une fois l’assistant terminé, le fichier de réponse est automatiquement enregistré dans le répertoire %SYSTEMROOT%\Temp sous le nom isaconfig_*.inf (le caratère “*” représente un chiffre aléatoire). Voici un exemple de fichier de configuration permettant de créer un tunnel VPN site-à-site utilisant le protocole IPSec Tunnel Mode, ajoutant le serveur ISA dans le domaine laboms.lan et le configurant pour appartenir à la grappe de serveurs nommée NANTES :

    [Appliance_Parameters]

    #Configuration de tous les paramètres en rapport avec la connexion VPN site-à-site ConnectionType=VPN VpnProtocol=IPSec RemoteSiteNetworkName=PARIS RemoteSIteIpOrName=81.110.223.17 LocalGatewayIp=81.110.223.16 S2SNetIpRanges=192.168.64.0-192.168.64.255 VPNAuthenticationType=PresharedKey PresharedKey=Ceci_Est_Une_Clé_PréPartagée

    #Configuration du serveur ISA pour joindre le domaine du site principal JoinDomainAction=JoinDomain JoinDomainName=laboms.lan JoinDomain_UserAccount=loic.thobois JoinDomain_Password=Passw0rd

    #Configuration du serveur ISA pour utiliser le CSS du site principal et pour appartenir à l’une des grappes ISA STORAGESERVER_COMPUTERNAME=css.laboms.lan STORAGESERVER_CONNECT_ACCOUNT=LABOMS\AdminCSS STORAGESERVER_CONNECT_PWD=Passw0rd ARRAY_MODE=Join ARRAY_NAME=NANTES ARRAY_AUTHENTICATIONMETHOD=Windows

    Lorsque l’assistant est exécuté sur un serveur ISA distant, la première étape consiste à créer le tunnel VPN site-à-site. Une fois la création du tunnel terminée, une règle réseau interconnectant le réseau Interne (la succursale) avec le réseau distant (le site principal) est automatiquement crée (cette relation utilise du routage IP et est donc bidirectionnelle). De plus la stratégie système du serveur ISA présent dans la succursale est modifiée de manière à ce que le serveur ISA de la succursale puisse…

    • Résoudre les noms d’hôte (DNS)
    • Accéder aux contrôleurs de domaine du site principal (RPC, LDAP, LDAP GC, Kerberos)

    L’étape suivante dans l’assistant est optionnelle et consiste à configurer le serveur ISA de manière à rejoindre un domaine Active Directory (manipulation rendue possible par la stratégie système qui autorise les bons protocoles). Enfin la dernière étape consiste à configurer le serveur ISA de manière à ne plus utiliser le serveur CSS temporaire local (ADAM est d’ailleurs désinstallé au cours de l’opération) et à basculer vers le serveur CSS du site principal pour rejoindre l’une des grappes de serveurs ISA.

    La capture d’écran ci-contre montre la fin de l’exécution de l’assistant de configuration des sites distants (“Branch Office VPN Connectivity Wizard”). On remarque que le serveur ISA est en train de basculer vers le serveur ISA du site principal.

    5.3 Procédure de déploiement pas-à-pas d’un serveur ISA 2006 dans un site distant

    Le but de cette mini-procédure est d’expliquer toutes les étapes nécessaires au déploiement d’un serveur ISA 2006 EE dans un site distant dans leur grandes lignes. On supposera que l’on dispose d’un site principal (site de Paris) possédant un serveur ISA 2006 EE déjà en production et que l’on souhaite ajouter un serveur ISA dans un site distant (site de Nantes). Le but est de simplifier au maximum le déploiement dans le site distant (Nantes) de manière à ce qu’un employé, même peu qualifié en informatique, soit capable de déployer le serveur ISA grâce à quelques indications de l’administrateur.

    1) La première chose à faire est bien entendu de configurer manuellement le serveur ISA du site principal (Paris) de manière à paramétrer toutes les options nécessaires au déploiement d’un second serveur ISA. Cela passe par la création…

    • Du tunnel VPN entre Paris et Nantes de manière à ce que les deux sites puissent communiquer

    • D’une règle de réseau de type routage (entre Nantes et Paris)

    • D’une ou plusieurs règles d’accès autorisant certains trafic réseau en fonction de conditions définies par l’administrateur (authentification, planification, type de contenus…)

    • D’une grappe de serveurs nommée NANTES qui ne contient pour l’instant aucun serveurs (mais qui contiendra le futur serveur ISA du site distant)

    • De la configuration de la grappe de serveurs NANTES de manière à autoriser tous le trafic adéquat

    2) La deuxième chose à faire au niveau du site de Paris reste de créer un fichier de réponse permettant d’installer un serveur ISA ainsi qu’un serveur CSS de manière automatisée ainsi qu’un fichier de réponse pour l’assistant AppCfgWzd.exe.

    3) La dernière manipulation consiste a envoyer sur le site distant le CD-ROM d’ISA Server 2006 EE, les deux fichiers de réponse ainsi qu’une procédure expliquant les manipulation à effectuer. L’opérateur situé dans le site distant devra uniquement une commande pour installer ISA ainsi que l’assistant de configuration (qui sera préconfiguré à l’aide du fichier de réponse).

    Une fois ces trois grandes étapes effectuées, le serveur ISA du site distant est pleinement fonctionnel. Il suffit à l’administrateur de modifier les options la grappe de serveurs NANTES à l’aide de la console de gestion pour configurer le nouveau serveur !

    5.4 Intégration des nouveautés du Service Pack 2 d’ISA Server 2004

    Bien évidemment toutes les nouveautés incluses dans le SP2 d’ISA 2004 en rapport avec la gestion des sites distants sont conservées au sein d’ISA Server 2006. les trois principales innovations sont le support de la mise en cache BITS, le gestion de la compression pour le trafic HTTP ainsi que l’intégration d’un système de priorité pour le trafic Web basé sur le protocole DiffServ.

    La mise en cache du contenu BITS

    Le service de téléchargement intelligent en arrière plan encore appelé BITS (Background Intelligent Transfert Service) permet de transférer localement les mises à jour sur un poste client à partir du site Microsoft Update. BITS offre des transferts rapides et sûrs grâce au téléchargement des fichiers par petits segments (les fichiers sont recomposés lorsque tous segments ont été rapatriés) et grâce à un fonctionnement “en arrière plan” (seule la bande passante inutilisée est mise à contribution de manière à ne pas perturber les autres applications).

    Sous ISA Server 2004 SP1, le protocole BITS n’était pas bien gérer et la mise en cache du contenu du site Microsoft Update n’était donc pas efficace. Avec ISA Server 2006, il est possible de créer des règles de mises en cache BITS destinées à stocker en cache l’intégralité des mises à jour et autres correctifs du site Microsoft Update. Cette fonctionnalité s’avère extrêmement intéressante dans le cadre d’une petite structure (ou d’un site distant) où aucun serveur WSUS / SMS n’est disponible.

    Compression HTTP

    La compression HTTP/HTTPs permet à ISA Server 2006 de réduire l’utilisation de la bande passante WAN ou LAN tout en augmentant les performances grâce à un compactage dynamique des données. Cette fonctionnalité est notamment appréciable dans le cadre d’une règle de publication Web. La compression est gérée grâce à un filtre Web nommé filtre de compression (comphp.dll) et se configure dans la section Configuration / Général de la console Gestion ISA Server.

    Système de priorité

    Sous ISA 2006 la gestion des priorités de trafic s’applique uniquement au trafic Web (HTTP). Elle permet de s’assurer que certaines applications critiques ont bien un accès au réseau, et ce, quel que soit le trafic engendré à ce moment là par d’autres applications. Cette gestion de la Qualité de Service (ou QoS) est fournie par le protocole DiffServ implémenté sous la forme d’un filtre Web (DffServ.dll).

    Protection de l’accès Web et fonctionnalités de monitoring associées

    6.1 La problématique

    Le but d’une attaque de type DoS (Denial of Service) ou DDoS (Distributed Denial of Service) est tout simplement de rendre indisponible un service. L’exemple typique est représenté par les serveurs Web qui sont très souvent victimes de ce type d’attaque ! Pour rendre le site Web indisponible, les pirates tentent tout simplement de surcharger le serveur en lui envoyant un maximum de requêtes HTTP. Lorsque ces multiples requêtes sont envoyées par de nombreuses machines différentes, on parle alors d’attaques DDoS.

    Notez bien :

    • DoS va envoyer des paquets provenant de la même adresse IP vers un ou plusieurs serveurs
    • DDoS est une variante de DDoS dans le sens où toutes ces requêtes simultanées destinées à un ou plusieurs serveurs vont provenir de plusieurs adresses IP

    La plupart des pirates prennent le contrôle de centaines, de milliers voir de dizaines de milliers de postes à l’aide de programmes spécifiques comme des chevaux de Troie ou des vers. A une heure H, le pirate donne l’ordre à l’ensemble des machines qu’il contrôle d’envoyer des requêtes HTTP en boucle à la même URL. Le serveur Web est bien entendu incapable de répondre à ce flot continu de requêtes, ce qui le rend quasiment inaccessible (timeout, erreurs 404….).

    Bien sur les attaques de type DoS et DDoS peuvent aussi viser d’autres services comme la messagerie, les accès VPN ou bien encore l’accès aux serveurs DNS (le but est alors de faire “tomber” l’infrastructure DNS mondiale, mais ces attaques, de grande envergure, sont relativement rares).

    En revanche les attaques de type DoS / DDoS sur les serveurs Web sont de plus en plus fréquentes ! Parmi les nombreux vers les utilisant on peut citer les “fameux”Blaster etSasser qui ont fait coulé beaucoup d’encre… Pour rappel le but de ces deux vers était de faire tomber les sites Web suivants : http://windowsupdate.microsoft.com pour Blaster et http://www.sco.com pour Sasser. Le schéma ci-dessus illustre une attaque de type DDoS (Blaster).

    Remarque :Ce qui va différencier un vers d’un virus va être sa capacité à se propager sur d’autres ordinateurs à l’insu de l’utilisateur, en utilisant notamment les mails, les logiciels de messagerie instantanée, les réseaux peer to peer, etc. Un ver de ce type va initialement effectuer des attaques de type DoS puis va rapidement, au fur et à mesure qu’il se propage, effectuer des attaques de types DDoS.

    6.2 La réduction du flood

    Il n’existe rien dans ISA Server 2004 permettant de lutter efficacement contre ce type d’attaques, en revanche un limiteur de flood a été implémenté dans ISA Server 2006. L’architecture d’ISA Server 2006 a été spécialement optimisée pour résister aux attaques de type DoS ou DDoS ! Le but du système de contrôle des flux implémenté dans ISA Server 2006 est que le serveur reste disponible pour les clients mais aussi pour l’administration en cas d’attaque de ce type.

    Le principe de base de ce limiteur de flood est des plus simples : dès lors que le serveur ISA reçoit un nombre trop important de requêtes provenant de la même adresse IP dans un laps de temps trop court (1 minute), toutes les requêtes suivantes provenant de cette adresse sont bloquées et une alerte est créée dans la console de gestion d’ISA Server 2006.

    Ce filtre est par défaut activé mais il est possible de le désactiver en décochant la case “Enable mitigation for flood attacks and worm propagation“. Dans le cas où l’on souhaite utiliser ce filtre, il est possible de spécifier le type de trafic ou de connexion que l’on va souhaiter bloquer.

    Certaines applications utilisées en entreprise utilisent un grand nombre de connexions simultanées au même serveur et il pourrait être gênant de les bloquer. Pour palier à ce problème, ISA Server 2006 nous donne la possibilité de spécifier des limites différentes pour certains ensemble d’ordinateurs : les exceptions. Ces exceptions sont générales à tous les paramètres du limiteur de flood. En revanche il ne sera possible d’appliquer une limite différente que sur certains paramètres. Dans le cas où il n’y a pas de champs prévu pour spécifier une limite de nombre de connexions, cela signifie que les exceptions configurées n’auront pas de limites.

    Le champ permettant de configurer le nombre maximum de connexions s’intitule “Limit” et celui permettant de fixer la limite des exceptions s’intitule ‘Custom limit“.

    Les paramètres ne bénéficiant pas de champs “Custom limit” sont “Non-TCP new sessions per minute, per rule“, “TCP half-open connections” et “Set event trigger for denied packets“.

    Les paramètres configurables avec ce limiteur de flood sont :

    • TCP connect requests per minute, per IP address : Lorsque le même client, ou plusieurs clients avec la même adresse IP vont tenter de se connecter un nombre de fois supérieur à ce qui a été défini dans ce paramètre dans la même minute, toutes les demandes de connexions qu’ils vont tenter de faire seront refusées.

    • TCP concurrent connections per IP address : Un client a la possibilité d’ouvrir plusieurs sessions TCP en simultané à partir de la même adresse IP, mais lorsque ce nombre devient supérieur à ce qui a été configuré dans ce paramètre et qu’il n’y a pas ou pas assez de connexions fermées, le client va voir ses demandes refusées par le serveur ISA.

    • TCP half-open connections : Lorsqu’un client se connecte sur un serveur via le protocole TCP, il va envoyer un paquet SYN, le serveur est ensuite sensé répondre au client en envoyant un paquet SYN-ACK, mais si le paquet envoyé initialement au serveur contient une adresse IP source invalide ou inexistante, le serveur ne va pas pouvoir renvoyer de paquet SYN-ACK et va stocker en mémoire les demandes de connexions SYN, d’où le terme connexion semi-ouverte. Si un client envoie un grand nombre de ces paquets au serveur, sa mémoire va très rapidement saturer et il ne sera plus capable de répondre aux requêtes des clients. Ce paramètre permet de configurer le nombre de demandes de connexions SYN que le serveur va pouvoir garder en mémoire avant de les supprimer. A l’inverse des autres paramètres, on ne peut pas le configurer directement, sa valeur va être la moitié de la valeur tronquée du paramètre “TCP concurrent connections per IP address“.

    • HTTP requests per minute, per IP address : Ce paramètre devrait limiter le nombre de requêtes HTTP passant par le serveur ISA par minute et par adresse IP mais il n’a apparemment pas été implémenté dans cette version beta1.

    • Non-TCP new sessions per minute, per rule : Il est possible d’effectuer des attaques DDoS avec des protocoles utilisant UDP, comme DNS par exemple. Le principe est toujours le même, il s’agit de surcharger le serveur avec des requêtes DNS trop grandes afin qu’il ne soit plus capable de répondre aux requêtes des clients. Ce paramètre va permettre de bloquer le trafic lorsque le serveur ISA reçoit trop de requêtes dans la même minute sur un ou des protocoles définis dans la même règle d’accès.

    • UDP concurrent sessions per IP address : Un client a la possibilité d’ouvrir plusieurs sessions UDP en simultané à partir de la même adresse IP, notamment lorsqu’il va faire du streaming, mais lorsque ce nombre devient supérieur à ce qui a été configuré dans ce paramètre et qu’il n’y a pas ou pas assez de connexions fermées, le client va voir ses demandes refusées par le serveur ISA.

    • Set event trigger for denied packets : ???

    6.3 Test des fonctionnalités de monitoring

    Comme dans la version 2004, on peut trouver dans l’item “Monitoring” un onglet “Alerts” qui permet de visualiser toutes les alertes relatives au fonctionnement du serveur ISA.

    En revanche de nouvelles définitions d’alertes ont étés implémentées. Il s’agit de définitions permettant de déclencher un évènement lorsqu’une alerte apparait suite à une tentative d’attaque via une technique DoS ou DDoS. A chaque paramètre de la limitation de flood correspond une définition d’alertes. Par exemple on trouvera la définition “Concurrent TCP connections from one IP adresse limit exceeded” qui correspondera au paramètre du réducteur de flood “TCP concurrent connections per IP address“.

    Afin de tester les outils de monitoring et de gestion des alertes, nous avons volontairement infecté une machine avec des vers, virus, spywares et autres rootkits. Le test a été réalisé sur une machine virtuelle fonctionnant sous Windows 2000 SP4 et connectée directement à Internet sans pare-feu ni antivirus. Après quelques minutes passées à surfer sur des sites savamment choisis, nous avons récolté une belle collection de virus en tout genre, puis avons configuré la machine en tant que client SecureNAT sur notre serveur ISA 2006. Aussitôt connectée, elle a tenté de plusieurs manières différentes de se connecter sur des sites internet du réseau externe via le serveur ISA qui a automatiquement détecté des tentatives d’attaques du serveur ISA et a bloqué toutes les connexions au delà de la limite fixée. (cf. capture ci-dessous).

    Comme on peut le voir sur cette capture, le serveur ISA a clairement identifié le type d’attaque ainsi que l’adresse IP de l’assaillant. Les trois alertes en question ont été déclenchées car le client infecté a tenté d’effectuer:

    • un nombre trop important de connexions TCP en une minute
    • trop de connexions simultanées alors que les premières n’étaient pas terminées
    • de manière plus générale trop de connexions non-autorisée en une minute

    De la même manière que sous ISA Server 2004, il est possible de spécifier des actions à effectuer lorsqu’une alerte est déclenchée : envoyer un mail, exécuter un programme, inscrire un événement dans le journal d’événements, d’arrêter ou de démarrer un service, et ce dans le but de tenter de minimiser les conséquences de la tentative d’attaque.

    6.4 Un produit encore en version beta…

    Depuis environ deux ans, les attaques de type DoS et DDoS ont réellement tendance à se généraliser et à devenir de plus en plus courantes (windowsupdate.microsoft.com, www.sco.com, www.akamai.com, etc.), il était donc nécessaire que Microsoft en tienne compte lors du développement des nouvelles fonctionnalités d’ISA Server. C’est désormais chose faite ! Cependant, certaines des fonctionnalités liées à la réduction du flood souffrent de bugs; bugs que l’on imputera à la jeunesse de la fonctionnalité :

    • Lorsque l’on ajoute manuellement un ou plusieurs ensembles d’ordinateurs comme exceptions, il est impossible de tous les supprimer par la suite sous peine de recevoir un message d’erreur.

    • Le paramètre du réducteur de flood “HTTP requests per minute, per IP address” semble pas fonctionner. En effet malgré tous nos tests, il a toujours été impossible de limiter le nombre de connexions provenant d’une adresse IP sans jouer sur les autres paramètres ainsi que de déclencher l’alerte associée à ce paramètre.

    Conclusion

    7.1 Nos impressions sur la Beta1 d’ISA Server 2006

    A l’heure actuelle ISA Server 2006 se positionne plus comme étant un “gros service pack” pour ISA 2004 plutôt qu’un produit entièrement nouveau ! En effet toutes les fonctionnalités de la version 2004 ont été implémentées de manière identique; et hormis le système de publication, le non initié aura du mal à voir une différence entre les deux produits. Cela est en partie du au fait que l’interface d’ISA 2004, excellente au demeurant, a été conservée telle quelle (aucune modification n’a été faite dans l’arborescence par défaut).

    Il est aussi dommage que certains défauts d’ISA Server 2004 que nous avions signalés dans nos précédents articles, n’aient pour l’instant pas été corrigés ! Voici une petite liste des erreurs ergonomiques et autres “bugs” qui restent à l’ordre du jour dans cette Beta1 :

    • Il est toujours impossible modifier à la volée plusieurs en-têtes HTTP avec le filtre HTTP (on ne peut en modifier qu’un seul) !
    • Rien a été fait pour simplifier l’utilisation du filtre HTTP qui est pourtant un élément très important en termes de sécurité ! Il serait par exemple très simple de préconfigurer la liste des méthodes HTTP, des en-têtes HTTP et des signatures logicielles les plus utilisées !
    • Toujours au niveau du filtre HTTP, il est impossible d’autoriser UNIQUEMENT une liste de signatures HTTP (on peut seulement bloquer certaines signatures; toutes les autres signatures étant autorisées par défaut…)
    • La procédure pour implémenter la mise en quarantaine des clients VPN est toujours aussi fastidieuse et Microsoft n’a intégré aucun script de vérification de la conformité au sein d’ISA ! De plus il serait une bonne idée de retravailler le système de quarantaine de manière à ce que la vérification de la conformité des postes soit faite côté serveur plutôt que côté client (à l’instar de ce que proposent certains plugins pour ISA Server comme QSS de Frédéric Esnouf) !
    • Lors du déploiement d’ISA Server 2006 édition entreprise, il n’est pas possible de créer à l’avance une grappe de serveurs ISA, puis d’ajouter le premier serveur ISA dans cette grappe si il est dans un groupe de travail et que le protocole LDAP over SSL est utilisé ! La seule solution est de créer la grappe de serveurs durant l’installation du premier serveur ISA de la grappe. Il est dommage que ce “bug” n’ait pas été corrigé.
    • Au niveau du filtre FTP, il serait aussi intéressant de pouvoir configurer la liste des commandes FTP autorisées et bloquées plutôt que de se limiter au choix entre “Accès total” et “Lecture seule”.
    • Il est impossible de mettre en place une configuration spécifique à chaque règle pour le filtreur de message SMTP (la configuration est générale pour toute les règles).
    • La configuration des exceptions et des limites de requêtes HTTP pour une même adresse IP par minute ne fonctionne pas (cf. section 6.4).
    • Etc.

    7.2 Que pouvons-nous attendre pour l’avenir ?

    Cependant ne boudons pas notre plaisir car toutes les modifications opérées dans cette nouvelle version vont dans le bon sens et permettent de faciliter l’administration. On peut notamment citer la gestion des certificats avec le système d’alerte permettant de prévenir l’administrateur lorsqu’un certificat arrive à expiration, les nouveaux assistants de publication ainsi que le système de gestion des flux qui permet de se protéger contre les attaques de type DoS/DDoS. La possibilité de gérer la répartition de charge d’une ferme de serveurs Web au niveau du serveur ISA est aussi une bonne chose.

    De plus d’autres fonctionnalités devraient apparaître d’ici la commercialisation du produit ! Certaines rumeurs font état de la gestion des tunnels VPN / SSL pour l’accès des clients… De plus un nouveau filtre Web sera certainement inclut dans les versions ultérieures du produit. En effet Microsoft a récemment acquis le filtre DynaComm i:filter de la société FutureSoft. Ce composant devrait offrir des fonctionnalités de filtrage avancées : comme la possibilité de se protéger des sites “douteux” par le biais d’une liste noire (URL blackilist), la possibilité de restreindre la durée de navigation de chaque utilisateur (par exemple limiter les utilisateurs à surfer 2 heures par jour au maximum)… Pour obtenir plus d’informations sur ce filtre, vous pouvez consulter directementle site de FutureSoft ou bien cette interviewsur le site de Microsoft.

    Bien entendu nous vous tiendrons au courant de toutes les évolutions d’ISA Server 2006 par le biais de notre rubrique actualités et par de prochains articles ! 🙂

    pas-à-pas est en cours de rédaction…

    pas-à-pas est en cours de rédaction…