Présentation générale d’ISA Server 2004

1.1 Introduction

La sortie d’Internet Security & Acceleration Server 2004 durant le mois de Juillet (2004) a été un évènement très important pour Microsoft. En effet ce logiciel apparaît comme étant l’élément clef de la politique de sécurité actuellement instaurée par la firme de Redmond (cf. : notre article).

Pour rappel, cette politique est essentiellement composée de quatre points :

  • Une augmentation du niveau de sécurité par défaut pour les applications (on peut par exemple citer le firewall de Windows XP qui s’active automatiquement dès l’installation du Service Pack 2).
  • Une maintenance et un déploiement facilité des mises à jour grâce à de nouveaux outils (SUS, MBSA, SMS, et bientôt WUS …).
  • Un meilleur niveau de sécurité dans le développement (Microsoft assure que le code de ses prochaines applications sera plus « sécurisé »).
  • Une meilleure sensibilisation des utilisateurs et notamment du grand public sur le problème de la sécurité via un site web dédié.

Après un tel discours et étant donné le contexte actuel (« pourriels », vers et virus sont devenus le quotidien des internautes et le cauchemar des administrateurs), Microsoft se devait de lancer une mise à jour convaincante de son logiciel phare concernant la sécurité. Cet article souhaite présenter ce nouveau produit sous toutes ses coutures.

1.2 Nouveautés par rapport à la version 2000

Pour commencer, rappelons qu’ISA Server ne joue pas simplement le rôle de pare-feu mais aussi de serveur de Proxy et de serveur VPN. Voici une liste non exhaustive des principales nouveautés et améliorations apportées depuis la version 2000 :

  • Une nouvelle interface graphique beaucoup plus ergonomique et intuitive.
  • Le paramétrage des règles de routage/NAT entre les différents réseaux connectés au serveur ISA a été révolutionné grâce à la création d’un assistant de configuration réseau qui permet de se décharger totalement de cette opération et permet ainsi de se concentrer sur le paramétrage des options liées à la sécurité.
  • La configuration des règles du pare-feu a été entièrement revue par rapport à la version 2000 notamment au niveau de l’ordre d’application des règles.
  • De nouveaux filtres applicatifs ont été ajoutés ou modifiés. Par exemple le filtre HTTP a été grandement remanié afin d’augmenter le niveau de sécurité des applications web comme IIS, Exchange ou bien encore Outlook.
  • Les possibilités au niveau de la surveillance (ou monitoring) ont été développées en profondeur. Ainsi on pourra visualiser les journaux (logs) et les sessions actives en temps réel, importer et exporter des rapports au format HTML, tester la connectivité réseau,…
  • Le serveur VPN est dorénavant totalement intégré au serveur ISA et son paramétrage en est d’autant plus facilité.
  • La possibilité d’importer et d’exporter la configuration du serveur ISA au format XML.

Si vous souhaitez prendre connaissance de l’ensemble de modifications et des nouveautés par cette nouvelle version, deux alternatives s’offrent à vous :

1.3 Configuration requise

Voici les caractéristiques logicielles et matérielles requises pour exécuter ISA Server 2004 :

  • processeur Pentium III 550 ou plus performant
  • 256Mo de mémoire vive
  • un nombre de cartes réseaux et/ou modems adéquats
  • une partition ou un volume formaté avec le système de fichier NTFS et disposant de 150Mo d’espace libre (bien entendu, si vous souhaitez activer la mise en cache, il faudra disposer de plus d’espace).
  • un minium de deux interfaces réseau (carte réseau, modem RNIS, modem ADSL,…)
  • Windows Server 2003 ou Windows 2000 Server SP4 (Attention : Microsoft recommande l’installation du correctif disponible sur la page suivante en plus du Service Pack 4)
  • Internet Explorer 6.0 ou supérieur

Bien entendu vous devrez tenir compte du nombre de clients connectés “derrière” le serveur ISA ainsi que des fonctions que vous activerez pour ajuster le matériel de votre serveur.


1.4 Les différentes versions disponibles

A l’heure actuelle ISA Server est uniquement disponible en version Standard (cette version ne peut gérer qu’un maximum de 4 processeurs physiques). La version Entreprise qui devrait bénéficier de fonctionnalité étendue n’a pas encore été commercialisée mais est déjà mentionnée sur le site américain.

En ce qui concerne la restriction appliquée au niveau du nombre de processeur, elle prend uniquement en compte les processeurs physiques. Ainsi il est possible d’utiliser l’édition standard du serveur ISA sur un système équipé de 4 processeurs bi-cores supportant l’hyperthreading. Le système d’exploitation reconnaîtra seize processeurs mais seulement 4 processeurs seront compté en ce qui concerne le licensing . Il est important de le préciser car tous les éditeurs de logiciels ne mènent pas la même politique vis-à-vis des processeurs supportant l’hyperthreading et/ou le multi-cores.

La version standard d’ISA Server 2004 ne comporta aucune restriction en ce qui concerne la mémoire vive. Les seules limitations à ce niveau seront celles du matériel et de l’OS (4Go sur la version standard de Windows Server 2003, 32Go sur la version Entreprise et jusqu’à 512Go sur la version 64 bits de Windows Server 2003 Datacenter Edition).

Pour acquérir ISA Server 2004 en France, il faut passer par le biais d’unrevendeur agrée Microsoft. Le coût d’une licence standard pour ISA 2004 est semblable à celui pratiqué au États-unis, soit environ 1499 euros. On se retrouve donc dans la même gamme de prix que pour la version 2000…

1.5 Évaluer ISA Server 2004 gratuitement

Conformément à la politique menée par Microsoft depuis quelques années, une version complète d’ISA Server 2004 limitée à 120 jours est disponible gratuitement sur le site de Microsoft. Vous devez posséder un compte passport .Net accéder à la page de téléchargement. Le fichier, d’une taille de 46,8 Mo est disponibleici en version française.

Conclusion

En conclusion, ISA Server 2004 s’inscrit dans la lignée de son prédécesseur tout en apportant un grand nombre d’améliorations. On peut citer la nouvelle interface intuitive grâce au système d’onglets et efficace grâce au système d’actualisation (le bouton Appliquer permet de rendre les modifications actives immédiatement ce qui n’était pas le cas sous ISA 2000…). L’intégration totale du serveur VPN dans la console de gestion ISA apporte de nombreux avantages :

  • configuration facilitée
  • interopérabilité des liaisons sites à sites à l’aide du protocole IPSec tunnel mode
  • meilleure sécurité avec le réseau clients VPN en quarantaine

De plus l’assistant modèle réseau ainsi que le nouveau système d’application des règles ont le mérite de clarifier le paramétrage quelque soit le type de règles (d’accès, de chaînage web, de cache,…). Le niveau de sécurité a lui aussi été amélioré de par le système de cryptage entre le nouveau logiciel client pare-feu Microsoft et le serveur ISA, et de par les améliorations effectuées sur les filtres applicatifs et les les filtres web. En ce qui concerne le monitoring, la refonte de l’interface et l’ajout des vérificateurs de connectivité et du tableau de bord permettent une meilleure surveillance de l’état et des connections du serveur.

Quelques remarques assombrissent tout de même ce tableau idyllique :

  • la stratégie système s’avère très pratique à l’usage mais reste une faille dans la sécurité du serveur puisqu’elle est activée par défaut
  • l’utilisation de MSDE demande plus de ressources matérielles que le système inclus dans ISA 2000
  • il n’est pas possible de voir en temps réel toutes les requêtes HTTP/HTTPS/FTP effectuées par les utilisateurs (des systèmes de ce type équipent déjà certains pare-feu matériel, tels ceux de la marque Arkoon, et s’avèrent très pratique à l’usage)
  • certaines fonctions avancées pourtant misent en avant par Microsoft déçoivent par leur implémentation difficile. On peut citer le filtre HTTP (aucune méthode, en-tête ou signature HTTP n’est définie par défaut, ce qui oblige l’administrateur a posséder une bonne connaissance du protocole HTTP et à utiliser un analyseur de trames) ou bien encore le système de mise en quarantaine (aucun script n’est fourni par Microsoft et un assistant de configuration aurait été le bienvenue étant donné le nombre d’étapes à réaliser…)

Espérons que la version entreprise d’ISA Server 2004 prévue pour le premier semestre 2005 corrigera ces quelques inconvénients qui n’enlèvent (presque) rien à la qualité du produit qui est globalement très bonne.

Installation et configuration initiale

2.1 Installation du logiciel

Contrairement à la version 2000 qui proposait 3 modes d’installation différents (mode cache, mode pare-feu et mode intégré), ISA Server 2004 ne propose qu’un seul mode d’installation. Dorénavant l’activation ou non de la mise en cache se paramètre dans la console de Gestion ISA et n’est plus tributaire du mode d’installation choisi au départ.

Après l’insertion du CD-ROM d’installation, le menu ci-contre apparaît. Il permet d’installer ISA Server 2004 ou bien de mettre à jour un serveur ISA 2000. Pour réalisez la migration d’ISA 2000 vers ISA Server 2004, le Service Pack 1 pour ISA 2000 doit être installé au préalable.

L’installation ne présentant aucunes difficultés (choix des composants à installer, définition de la table d’adresses locales, activation de la prise en charge des clients pare-feu utilisant l’ancienne version du client…) elle ne sera pas détaillée dans cette page. Cependant si vous souhaitez vraiment connaître tous les détails du processus d’installation vous pouvez tout de même consulter cette page.

Une fois l’installation terminée, six nouveaux services sont installés et doivent être démarrés pour que le serveur fonctionne correctement. Quatre de ces services concernent directement ISA Server :

  • Contrôle de Microsoft ISA Server : ce service est le service principal d’ISA 2004. Il se révèle très utile pour arrêter/démarrer le service pare-feu et le service Planificateur de tâches Microsoft ISA Server en une seule opération.

  • Pare-feu Microsoft : ce service est le plus important, il gère toutes les connexions faites au serveur, les règles du pare-feu, les règles de mise en cache, … S’il n’est pas démarré, aucune des fonctionnalité du serveur n’est assurée (mise en cache, pare-feu et serveur VPN).

  • Planificateur de tâches Microsoft ISA Server : ce service permet de planifier des rapports sur l’activité du serveur.

  • Espace de stockage Microsoft ISA Server : ce service gère notamment le système de surveillance intégré à ISA Server et l’espace mémoire nécessaire à la mise en cache .

Les deux autres services correspondent au moteur de SQL Server 2000. En effet, MSDE2000 version A (pour Microsoft SQL Server Desktop Engine) est utilisé afin de stocker les données (notamment les données des journaux et des rapports) :

  • MSSQL$MSFW

  • MSSQLServerADHelper

A l’issu du processus d’installation, il est conseillé de consulter les trois fichiers journaux générés dans le répertoire %WINDIR%\temp:

  • le fichier ISAWRAP_xxx contient un résumé du processus d’installation.

  • le fichier ISAMSDE_xxx contient des information détaillées concernant l’installation du moteur de base de données MSDE.

  • le fichier ISAFWSV_xxx contient des informations détaillées concernant l’installation d’ISA Server.

2.2 Une interface entièrement repensée

Tout comme pour la version 2000, on utilise une console MMC (Microsoft Management Console) pour gérer le serveur ISA. Cependant, ISA Server 2004 a fait l’objet d’une refonte totale au niveau graphique. Outre le nouvel aspect bien plus esthétique grâce à ses formes arrondies, cette console « nouvelle génération » apporte un réel plus en terme d’ergonomie par rapport à l’ancienne console qui possède une lourde interface composée d’une arborescence compliquée et de menu mal conçus.

La console de Gestion ISA version 2000

Comme vous pouvez vous en rendre compte le nouvel utilitaire de configuration conserve un système avec deux fenêtres. Cependant, la fenêtre de gauche présente dorénavant une arborescence bien plus simpliste composée de 4 menus principaux :

  • Surveillance

  • Stratégie de pare-feu

  • Réseaux privés virtuels (VPN)

  • Configuration (composée de 4 sous menus : Réseaux, Cache, Add-ins et Général)

Les autres options de configuration sont ensuite accessibles par le biais de la fenêtre de droite grâce à un système d’onglets très bien pensé.

La console de Gestion ISA version 2004

2.3 L’assistant modèle réseau

L’une des principales améliorations au niveau de l’interface concerne la configuration du NAT et/ou routage entre les différents réseaux connectés au serveur ISA. En effet, un assistant très efficace est désormais disponible pour mettre en place sans efforts administratifs les topologies réseau classiquement utilisées sur un pare-feu. Il suffit de lancer l’assistant et en 3 clics de souris, les règles qui permettent la communication entre les différents réseaux reliés au serveur sont automatiquement paramétrées. Cinq configurations sont prédéfinies :

  • Pare-feu de périmètre Dans cette configuration, le serveur ISA est un hôte bastion, c’est-à-dire un pare-feu interconnectant un réseau privé à un réseau public. C’est le scénario classique en entreprise lorsque l’on souhaite filtrer l’accès à Internet.
  • Périmètre en trois partiesLe serveur ISA possède trois interfaces chacune connectée à un sous réseau ou à un réseau différent : – la première est connectée au réseau interne de l’entreprise – la seconde à un réseau périphérique encore appelé zone démilitarisée ou DMZ (DeMilitarized Zone) – la dernière à un réseau public comme Internet.
  • Pare-feu avantDans ce scénario, le serveur ISA est configuré pour être le premier pare-feu d’un réseau équipé de deux pare-feu mis dos-à-dos. Le serveur ISA est l’ordinateur qui filtre les informations circulant entre le réseau périphérique (DMZ) et le réseau public (ex. : Internet).
  • Pare-feu arrièreDans ce scénario, le serveur ISA est configuré pour être le second pare-feu d’un réseau équipé de pare-feu dos-à-dos. Le serveur ISA est l’ordinateur qui filtre les informations circulant entre le réseau interne de l’Entreprise et le réseau Périphérique (DMZ).
  • Carte réseau uniqueDans cette configuration, ISA Server 2004 est paramétré pour assurer uniquement la fonction de mise en cache (serveur de Proxy). Il fonctionne sur le même réseau que le réseau interne et ne peut faire ni routage, ni serveur VPN, ni pare-feu.

Bien entendu l’administrateur du serveur a toujours la possibilité de créer ces règles réseaux et il peut aussi éditer manuellement toute la configuration. Cependant, l’assistant a le mérite de débarrasser l’administrateur de cette tâche supplémentaire ce qui lui permet de se concentrer sur les autres paramètres du serveur dédiés eux à la sécurité (mise en place de règles, d’alertes et de filtres).

On peut également noter qu’une configuration réseau peut être sauvegardée au format XML ce qui permet de pouvoir la restaurer très rapidement. La possibilité de pouvoir importer/exporter une configuration est d’ailleurs disponible pour tous les types de paramètres du serveur (ensemble de réseaux, règles de réseaux, règles de chaînage web, stratégies de pare-feu, configuration des clients VPN, règles de cache, filtres,… ). On peut supposer que cette possibilité s’étendra à tous les futurs produits Microsoft.

Pour accéder à l’onglet ci-contre, il suffit de développer l’arborescence et d’aller dans configuration/networks.

2.4 Chaînage de pare-feu et chaînage web

Le chaînage consiste à raccorder plusieurs serveurs ISA entres eux afin d’optimiser au maximum l’utilisation de la bande passante réseau. Cette fonctionnalité peut se révéler très utile dans le cas d’une entreprise possédant un site principal et plusieurs sites distants. Il existe deux types de chaînage sous ISA Server 2004 :

  • le chaînage web qui s’applique uniquement aux clients du Proxy web

  • le chaînage de pare-feu qui s’applique uniquement aux clients SecureNAT et aux clients pare-feu

Considérons une entreprise possédant un site principal et deux sites distants. Admettons que le site principal regroupent environ 2500 machines alors que les succursales en regroupent 50 chacune. Toutes les machines clientes sont configurées en tant que clients du Proxy web. Chaque succursale contient un serveur ISA fonctionnant en tant que serveur de proxy. Dans ce cas, il est possible d’accélérer grandement les performances de la navigation web dans les sites distants de la manière suivante :

  • utiliser la connexion Internet locale pour les requêtes HTTP destinées à des sites web français (c’est-à-dire des sites appartenant au domaine DNS *.fr)

  • rediriger toutes les autres requêtes vers le serveurs ISA du site principal afin de bénéficier du fichier de cache de ce serveur qui doit être plus conséquent et plus à jour étant donné le nombre de clients appartenant au site principal.

le chaînage de serveurs ISA

Le chaînage web route (ou redirige) les demandes des clients du Proxy web vers la connexion Internet locale, un autre serveur de Proxy situé en amont ou bien directement vers un serveur HTTP. ISA Server 2004 permet de définir des règles de chaînage web très flexible afin d’optimiser au maximum les performances de la navigation et la charge réseau. On peut par exemple rediriger les requêtes à destination d’une URL ou d’un ensemble d’URL donné vers un serveur de Proxy spécifique.

Le chaînage de pare-feu redirige les demandes des clients SecureNAT et des clients pare-feu vers la connexion Internet locale ou vers un autre serveur ISA situé en amont. Il n’est pas possible de définir de règles précises en ce qui concerne le chaînage de pare-feu.

Paramétrage du pare-feu

3.1 Introduction

Nous allons maintenant voir comment paramétrer le pare-feu du serveur ISA. En effet, depuis la version 2000, les options du pare-feu ont été profondément revues. Voici un rappel des nouveautés :

  • Interface et méthode de création des règles d’accès améliorées

  • Modification de l’ordre d’application des règles

  • Stratégie système

  • Remaniement des filtres d’application

3.2 Les éléments de stratégie

A l’instar d’ISA 2000, on utilise des éléments de stratégie définis préalablement afin de simplifier et de structurer la création de règles d’accès pour le pare-feu mais aussi pour la création de tous les autres types de règles existantes (règles de mise en cache, règles de stratégie système,…) comme nous le verrons ultérieurement. Les différents types d’éléments sont :

  • Protocoles

  • Utilisateurs

  • Types de contenus

  • Planifications

  • Objets de réseau

Un certain nombre d’éléments existent par défaut ce qui évite à l’administrateur de devoir tous les re-définir. On peut créer et visionner les éléments de stratégie dans l’ongle boîte à outils située dans le menu de la fenêtre de droite (ce menu s’affiche si l’on sélectionne stratégie de pare-feu dans l’arborescence).

Par défaut le nombre de protocoles préfinis est impressionnant. Ils sont classés par groupe ce qui facilite grandement les recherches. Ainsi si l’on souhaite paramétrer une règle pour autoriser ou refuser l’accès aux pages Web il faudra aller chercher dans le conteneur Web qui contient notamment les protocoles HTTP et HTTPS.

Cette classification se révèle très utile à l’usage. En effet, cela évite de devoir faire des recherches sur Internet lorsqu’on ne connaît pas le numéro de port et/ou les plages de ports utilisées par une application donnée. On peut citer quelques dossiers intéressants :

  • VPN et IPSec qui permet d’autoriser l’accès VPN (IKE, IPSec, L2TP, PPTP,…)
  • Terminal distant donne accès aux principaux protocoles d’administration à distance (RDP, Telnet, SSH,…)
  • Messagerie instantanée qui permet d’autoriser ou d’interdire rapidement l’accès aux principales applications (ICQ, AIM, MSN, IRC…)

Bien entendu on peut rajouter des définitions de protocoles à la liste présente au départ si le besoin s’en fait sentir.

L’onglet Utilisateurs permet de créer des groupes d’utilisateurs qui seront utiles lors de la création des règles du pare-feu. La grande nouveauté à ce niveau est la gestion des comptes contenus sur les serveurs RADIUS ou sur les serveurs gérant l’authentification via le protocole SecureID en plus des comptes de domaine Active Directory.
Un certain nombre de types de contenus existe par défaut, ce qui permet de simplifier la création de règles sur les contenus. On peut citer documents web, images, audio ou bien encore vidéo. Les éléments de stratégie Types de contenus se révèlent très utiles pour permettre à des utilisateurs de surfer tout en les empêchant de télécharger certains fichiers (comme les vidéos par exemple).
Les deux planifications types présentes par défaut sont simplistes et devront être retouchées afin de correspondre aux horaires de votre entreprise. Il ne faudra pas hésiter ici à créer plusieurs autres planifications comme pause ou repas qui permettront de paramétrer des règles d’accès spécifiques à certains moments de la journée.

Les objets réseaux sont très importants pour le paramétrage des différentes règles du serveur ISA. Les ensembles de réseaux et les réseaux sont crées automatiquement lors de la sélection d’un modèle réseau. Par exemple si vous choisissez le modèle pare-feu de périmètre les réseaux Interne, Externe, Clients VPN et Clients VPN en quarantaine seront ajoutés. Le réseau hôte local est toujours présent, il représente le serveur ISA.

Le “réseau” clients VPN en quarantaine contient l’ensemble des clients VPN dont la connexion a été refusée car leurs niveaux de sécurité n’était pas satisfaisant. Cette mise en quarantaine des clients “non sécurisés” est une nouveauté de la version 2004 d’ISA server. Nous aborderons la configuration de la mise en quarantaine dans le chapitre dédié au serveur VPN.

Une autre catégorie d’objet de réseau intéressante est la possibilité de créer des ensembles d’URL et des ensembles de noms de domaines. Cela va permettre de bloquer ou d’autoriser certains sites ou certaines pages. Si le nombre de sites web auquel vos utilisateurs doivent accéder est faible, il est fortement recommandé de créer un élément de stratégie nommé sites autorisés ce qui permettra à vos utilisateurs d’accéder uniquement à ces sites.

3.3 La création des règles du pare-feu

Par rapport à sa version 2000, la création des règles du pare-feu a été modifiée. Ainsi il n’y a plus qu’un seul type de règles contrairement aux trois types de règles (règles de protocoles, règles de sites et de contenu et filtres de paquets) d’ISA Server 2000. Voici les informations à rentrer pour paramétrer une règle type.

ACTION

PROTOCOLE

SOURCE / DESTINATION

APPLICATION

CONDITION

-refuser -autoriser

– ensemble de protocoles – port particulier

– ensemble de site – ensemble de noms de domaine – plage d’adresses IPs

– utilisateurs – groupes – personnalisée

-plage horaire -type de contenu

Cette nouveauté a le mérite de simplifier la configuration et la compréhension car on n’a beaucoup moins de règles à paramétrer. Par exemple pour autoriser l’accès à Internet avec ISA Server 2000 il faut créer deux règles (une règle de site et de contenu pour autoriser l’accès vers telle ou telle destination et une règle de protocoles pour autoriser les protocoles HTTP et HTTPS) alors qu’ISA Server 2004 ne nécessite qu’une seule règle pour arriver au même résultat.

L’onglet tâches contient l’ensemble des actions réalisables pour paramétrer le pare-feu. On y retrouve les possibilités s’appliquant aux règles d’accès (création, édition, désactivation, suppression), mais aussi tous les types de publication (publication d’un serveur Web, publication d’un serveur web sécurisé, publication d’un serveur de messagerie, publication de serveur).

On peut de plus afficher, modifier, importer et exporter les règles de la stratégie système. Ces règles sont définies par automatiquement et s’appliquent spécifiquement au serveur ISA qui correspond au “réseau” hôte local. Ces règles permettent par exemple au serveur ISA de joindre un serveur DHCP ou un contrôleur de domaine. Les règles de stratégie système sont donc essentielles au bon fonctionnement du serveur ISA.

Le lien définir les préférences d’IP permet quand à lui d’activer le routage IP et de paramétrer le filtre d’options IP. Le filtre d’options IP permet d’autoriser ou de refuser les paquets possédant des options spécifiques. Toutes les opérations d’importation et d’exportation utilisent le format XML. Des exemples de création de règles d’accès sont présentés dans la partie dédiée à cet effet.

3.4 Ordre d’application des règles

Avec ISA Server 2000, lorsqu’une requête arrive au pare-feu, une procédure spécifique pour autoriser ou refuser le passage de la requête est réalisée :

  • Vérification de l’existence d’une règle de site et de contenu qui refuse la requête

  • Vérification de l’existence d’une règle de site et de contenu qui autorise explicitement la requête

  • Vérification de l’existence d’une de protocole qui refuse la requête

  • Vérification de l’existence d’une de protocole qui autorise explicitement la requête

  • Vérification de l’application d’un éventuel filtre de paquet

  • Avec la nouvelle version, cette procédure complexe est remplacée par un autre système. Dorénavant, chaque règle possède un numéro et lorsqu’une requête arrive au serveur, c’est la règle qui a le numéro le plus faible qui s’applique. Ce système a le mérite d’être beaucoup plus simpleà comprendre que l’ancien et il est d’ailleurs repris en ce qui concerne l’ensemble des règles que l’on peut créer avec ISA Server 2004 (règles de translation d’adresse et de routage, règles de pare-feu, règles de cache, …). Voici un exemple de règles que l’on peut paramétrer :

    On note la présence d’une règle spécifique ne portant pas de numéro et notée : «Dernier ». Comme vous pouvez le voir sur la capture d’écran ci-dessus, cette règle bloque tous les protocoles de toutes les sources vers toutes les destinations. Elle est toujours située à la fin et possède donc la priorité la plus basse.

    3.5 Les règles de stratégie système

    La stratégie système est un ensemble de règles qui permettent au serveur ISA de joindre certains services réseau fréquemment utilisés. Au premier abord, on pourrait considérer ces règles de stratégie système comme un trou de sécurité. Cependant la plupart de ces règles autorisent juste la communication entre l’hôte local et le réseau interne. En aucun cas, un utilisateur externe ne peut accéder au serveur ISA ou bien au réseau de l’entreprise via l’une de ces règles. Le but de Microsoft avec la stratégie système est de trouver un bon compromis entre connectivité et sécurité.

    Si la stratégie système n’existait pas, le serveur ISA ne pourrait communiquer avec aucune autre machine. Ceci empêcherait notamment le serveur ISA de réaliser les actions suivantes :

    • ouvrir une session sur le domaine
    • récupérer un bail DHCP
    • résoudre les noms de domaines pleinement qualifié en adresse IP
    • etc.

    Le scénario de l’installation à distance via une session Terminal Server permet de bien se rendre compte de l’utilité de la stratégie système du point de vu administratif. En effet, si la stratégie système n’existait pas, vous pourriez installer ISA 2004 sur une machine distante, mais dès le lancement du service pare-feu, la session Terminal Server serait immédiatement déconnectée car le protocole RDP serait bloqué. Cela obligerait ensuite l’administrateur a se déplacer sur le site distant pour créer une règle d’accès autorisant le protocole RDP ce qui peut s’avérer contraignant si le site distant est situé à 6000 kilomètres !

    extrait des règles de stratégie système

    Bien entendu, les règles de stratégie système inutiles doivent être désactivées afin de réduire la surface d’attaque. Pour ce faire, un assistant spécifique nommé Éditeur de stratégie système est disponible. Il permet de désactiver toutes les règles de stratégie système, mais aussi de les configurer.

    L’éditeur de stratégie système est accessible à partir de l’onglet Tâches

    3.6 Le filtrage applicatif

    Cette nouvelle version d’ISA Server met l’accent sur les filtres d’application qui sont maintenant plus nombreux et qui possèdent des fonctionnalités avancées. Contrairement aux filtres de paquets qui analysent uniquement l’en-tête des paquets IP pour savoir si le paquet doit être bloqué ou non, les filtres d’application analysent aussi le corps du paquet. Les filtres d’application sont au nombre de 12.

    exemple de filtres d’application

    Pour activer ou désactiver des filtres d’application, il faut utiliser la fenêtre présentée ci-dessus (cette fenêtre est située dans le menu configuration / Add-ins de l’arborescence). Par défaut tous les filtres d’application sont activés afin de procurer une sécurité maximale. Les filtres inutilisés peuvent être désactivés afin de ne pas faire chuter les performances sur une machine peu puissante.

    3.7 Conclusion

    Voici les points essentiels à retenir pour créer des règles d’accès sous ISA Server 2004 :

    • La création des règles d’accès fait appel à des éléments de stratégie

    • Chaque règle est appliquée dans un ordre bien précis

    • Des filtres spécifiques peuvent être appliqués sur les règles d’accès

    • Certaines règles sont présentent par défaut (stratégie système)

    Exemples de configuration

    4.1 Introduction

    Ce chapitre a pour but de présenter la configuration de certaines règles souvent mises en place (accès à Internet, autorisation/interdiction de MSN Messenger, …). Chaque sous partie se consacre à un exemple en particulier.

    4.2 Autoriser l’accès à Internet pour les clients du réseau interne

    Nous allons maintenant créer une règle autorisant l’accès à Internet (c’est-à-dire au réseau externe dans cet exemple) pour tous les clients pare-feu du réseau interne via le ports 21, 80, 443 et 1863 (le port utilisé par MSN Messenger pour la connexion et l’échange de messages).

    Il faut commencer par donner le nom le plus explicite possible à la règle que l’on souhaite créer. On doit ensuite sélectionner l’action a effectuer (autoriser ou refuser). Si l’on sélectionne Refuser, la possibilité de rediriger la requête vers une page web est offerte (cela permet de faire comprendre à l’utilisateur que la page a été bloquée intentionnellement par le pare-feu et que ce n’est donc pas un problème technique). Il faut choisir le ou les ports de destination pour le(s)quel(s) la règle va s’appliquer. Dans notre exemple, tous les protocoles sont prédéfins (ce sont des éléments de stratégie présent par défaut dans le serveur) et il suffit juste d’ajouter les protocoles nommés FTP, HTTP et HTTPS à l’aide du bouton adéquat. Il est possible de définir quels sont les ports sources à l’aide du bouton Ports… Dans notre exemple nous laissons l’option par défaut qui autorise tous les ports sources (ainsi les clients pourront accéder à des sites web et à des serveurs FTP quel que soit le logiciel client utilisé).

    L’étape suivante consiste à spécifier le réseau source et le réseau de destination. Dans notre exemple, le réseau source correspond àInterne (le réseau local de l’entreprise) et le réseau de destination correspond à Externe (Internet).

    Enfin on sélectionne les ensembles d’utilisateurs pour lesquels la règle entrera en action. Dans notre cas, le groupe nommé Tous les utilisateur authentifiés est retenu. Cependant, tous les groupes de sécurité définis dans le service d’annuaire Active Directory peuvent être utiliser pour créer une règle plus fine.

    Une fois l’assistant terminé, la règle est inopérante. Pour que qu’elle entre en action il suffit de cliquer sur le bouton Appliquer qui apparaît au milieu de l’interface de la console de gestion ISA.

    Et voilà ! Tous les utilisateurs de votre réseau ont maintenant accès à Internet, et ce quel que soit leur navigateur (Internet Explorer, Safari, Firefox, Opéra,…) ou bien leur client FTP (Internet Explorer, FileZilla,…). Bien entendu, certains pré-requis doivent être respectés pour que tout fonctionne correctement :

    • Les ordinateurs clients doivent être capable de joindre un serveur DNS résolvant les noms DNS “publiques”

    • Les ordinateurs client doivent être configurés pour joindre le serveur ISA

    • Le pare-feu présent sur les ordinateurs client doit lui aussi être configuré pour autoriser l’accès à Internet

    4.3 Interdire complètement l’accès à MSN Messenger

    A l’instar de Windows Messenger, MSN Messenger est une application de messagerie instantanée permettant d’accroître grandement la productivité des utilisateurs (chat, vidéoconférence, échange de fichiers aisé,…). Cependant l’utilisation de ce logiciel en entreprise peut entraîner quelques dérives… Si vous souhaitez empêcher certains utilisateurs de l’utiliser, plusieurs solutions sont envisageables :

    • créer deux règle d’accès interdisant la communication avec le serveur messenger.hotmail.com
    • configurer les clients pare-feu pour empêcher MSN Messenger d’accéder au réseau
    • configurer le filtre HTTP pour bloquer l’application MSN Messenger en analysant le paramètre adéquat

    Nous allons étudier les avantages et les inconvénients de chacune de ces méthodes.

    1ère méthode

    Étant donné que MSN Messenger utilise plusieurs ports ou plage de ports pour mettre en oeuvre ses différents services (texte, échange de fichier, son…). La solution la plus simple reste d’interdire le port TCP 1863 qui est utilisé l’échange de messages textuels mais surtout pour la connexion initiale. Pour cela, il n’est pas nécessaire de créer un élément de stratégie, puisque le protocole MSN Messenger est prédéfini dans ISA 2004. Il suffit donc de créer une règle d’accès bloquant le protocole MSN Messenger entre le réseau Interne et lé réseau Externe et s’appliquant au bon groupe d’utilisateurs.

    Cependant, une fois la règle d’accès correctement crée, tous les utilisateurs peuvent encore utiliser MSN Messenger !!! La connexion est un peu plus lente (environ 10 secondes d’écart), mais s’effectue tout de même, ce qui permet à des utilisateurs non autorisé de “chatter”. Une bonne méthode dans un cas comme celui-ci, est d’utiliser un programme pour analyser les trames envoyées par le logiciel MSN Messenger afin de mieux comprendre son fonctionnement. Il existe pour cela des outils gratuit tel que le Moniteur réseau Microsoft ou bien encore Ethereal. Voici les résultats d’une analyse de trames lancée au moment où l’utilisateur clique sur le bouton Ouvrir une session…

    On remarque que le logiciel (exécuté sur une machine dont l’adresse IP est 10.1.0.2) essaye de se connecter au serveur 207.46.104.20 (cette adresse correspond au FQDN messenger.hotmail.com) en utilisant le port 1863 du protocole TCP. L’opération est répétée trois fois consécutives si le serveur ne répond pas immédiatement. Ce port étant bloqué au niveau du pare-feu, la demande n’aboutie jamais. L’application essaye ensuite dans un second temps de se connecter à ce même serveur mais à l’aide du port 80 qui est normalement réservé au protocole HTTP. Ce port étant ouvert au niveau du pare-feu afin de permettre la navigation web, l’application réussi a se connecter et la session de l’utilisateur peut ensuite s’ouvrir.

    Ce problème peut se résoudre à l’aide d’une règle d’accès interdisant la communication entre les machines du réseau Interne et le serveur messenger.hotmail.com. Pour cela il faut créer au préalable un élément de stratégie pointant vers l’adresse IP du serveur messenger.hotmail.com ou bien directement vers le nom de domaine pleinement qualifié messenger.hotmail.com. Il est plus judicieux d’interdire le FQDN car même en cas de modification de l’adresse IP du serveur la règle restera valide. La fenêtre ci à gauche montre les propriétés d’un élément de stratégie. Il se nomme serveur MSN Messenger et pointe vers l’adresse IP 207.46.104.20.

    Une fois l’élément de stratégie correctement configuré, il suffit de créer une règle refusant les connexions au domaine messenger.hotmail.com et s’appliquant aux groupes appropriés. Bien entendu, on peut altérer la règle précédemment crée pour bloquer le port 1863 en ajoutant le protocole HTTP au protocole MSN Messenger et en précisant que la destination est serveur MSN Messenger. Cette règle va donc empêcher les paquets IP expédiés par le réseau Interne et à destination du serveur messenger.hotmail.com d’atteindre leur objectif quel que soit le port utilisé (1863 ou 80).

    Dans l’exemple ci-dessous les utilisateurs appartenant aux groupes Comptabilité, Production ou Recherche ne peuvent plus se connecter à l’aide du logiciel MSN Messenger.

    Cette première méthode est celle qui répond le mieux à la problématique car elle demande peu de ressources et reste simple à mettre en œuvre.

    2ème méthode

    Les clients pare-feu récupèrent à chaque démarrage une liste des logiciels autorisés ou non à accéder au réseau (lorsqu’un logiciel n’est pas mentionné dans cette liste il peut tout de même accéder au réseau). Il est possible de bloquer MSN Messenger par ce biais.

    Il suffit d’ouvrir la fenêtre Paramètre du client de pare-feu située en utilisant le conteneur Général de l’arborescence de la console de gestion ISA. Cette fenêtre montre toutes les applications pour lesquelles l’accès au réseau a été configuré. Pour bloquer une application, il suffit d’ajouter une entrée correspondante au nom du processus lancé par cette application (sans son extension), puis de donner la valeur 1 au paramètre Disable. Dans notre exemple le processus utilisé par MSN Messenger est msnmsgr.exe. Il faut donc créer une entrée nommée msnmsgr.

    Une fois la modification appliquée au niveau du serveur, il faut penser à redémarrer le service Agent du client de pare-feu à l’aide des commandes net stop fcwagent et net start fcwagent (ou bien en utilisant la console Services). Dès que cette opération est effectuée, le programme ne peut plus accéder au réseau et la fenêtre ci-dessous apparaît :

    Cette méthode est très rapide à mettre en oeuvre et est très efficace. Cependant elle possède deux inconvénients majeurs :

    • elle ne s’applique qu’aux clients de pare-feu (et pas aux clients SecureNAT et clients du proxy web)
    • elle ne permet pas d’interdire l’utilisation du logiciel à des utilisateurs donnés (tous les utilisateurs seront affectés par l’interdiction d’utilisation)

    3ème méthode

    Une dernière méthode consiste à utiliser un filtre web (le filtre HTTP en l’occurence). C’est le procédé le plus optimisé et le plus sure, cependant, il a le gros inconvénient de demander énormément de ressources système au serveur ISA. En effet, lorsque le filtrage web est activé, le serveur ISA analyse l’en-tête et/ou le contenu de chaque paquet IP provenant du réseau Interne et à destination du réseau Externe. C’est pourquoi il faut tenir compte des capacité matérielles du serveur avant d’activer cette option. Le thème du filtrage applicatif et du filtrage web étant trop vaste, nous ne détaillerons pas ici la configuration du filtre HTTP. Elle sera abordée dans un prochain article.

    méthode utilisée

    Filtre HTTP

    Règle d’accès

    Configuration du client pare-feu

    besoin en ressources sur le serveur ISA

    très fort

    faible

    quasi nul

    type de clients supportés

     pare-feu  secureNAT proxy web

    pare-feu  secureNAT proxy web

    pare-feu

    possibilité d’interdire l’usage du logiciel à un groupe donné ?

    oui

    oui

    non

    rapidité mise en place

    long (difficile à configurer et à tester)

    rapide

    assez long (il faut relancer le service agent du client de pare-feu sur l’ensemble des clients)

    Avantages et inconvénients des trois méthodes

    4.4 Interdire l’accès à MSN Web Messenger

    Une fois le logiciels MSN Messenger bloqué, les utilisateurs peuvent toujours accéder à ce service par le biais de sa version web. En effet, le site http://webmessenger.msn.com/ propose une interface reprenant la plupart des services de la version logicielle. Il peut donc s’avérer utile de bloquer l’accès à cette URL en complément de la désactivation de l’application. Pour cela il suffit de créer une règle interdisant le trafic entre le réseau interne et le domaine webmessenger.hotmail.com sur le port 80 en TCP. Bien entendu, on peut tout aussi bien bloquer l’URL http://webssenger.msn.com ou bien directement l’adresse IP (ci-contre l’ensemble de stratégie nommé sites de chat peut être utilisé pour interdire l’accès à webmessenger.msn.com).

    4.5 Conclusion

    Certaines règles ne sont pas évidentes à configurer, il faut parfois utiliser des connexions secondaires ou des éléments de stratégie supplémentaire. Certains logiciels devant être autorisés ou interdit sont parfois pas ou peu documentés. Une bonne méthode permettant de trouver les informations manquantes reste l’utilisation d’un analyseur de trames comme le Moniteur réseau Microsoft ou bien encore Ethereal.

    Ce chapitre va être prochainement modifié avec l’ajout de nouveaux exemples (autoriser toutes les fonction de MSN Messenger, autoriser eMule,….) et de vidéos express.

    Implémentation de la mise en cache

    5.1 Introduction

    A l’instar de la version 2000, ISA Server 2004 joue aussi le rôle de serveur de proxy. Tous les paramètres relatifs à la mise en cache se configurent dans une fenêtre spécifique accessible via l’arborescence principale (configuration / cache).

    5.2 Configuration de la mise en cache

    Un onglet “taches” récapitule les diverses actions possibles :

    • activer/désactiver la mise en cache
    • définir la taille maximale qu’occupera le fichier de cache sur chaque partition ou sur chaque volume
    • créer des règles de cache en utilisant les éléments de stratégie prédéfinis
    • importer/exporter les règles de cache
    • activer/désactiver et paramétrer la mise en cache active

    Les règles de cache s’appliquent avec le même système que les règles d’accès et que les règles de stratégie système. La règle qui possède le numéro le plus faible sera donc traitée en priorité. Il existe une règle par défaut qui met en cache tous les types d’objets HTTP et FTP demandés quel que soit le réseau source. Il aussi possible de planifier le téléchargement de certains contenus dans un onglet spécifique.

    Les paramètres de la mise en cache restent les même que sur ISA Server 2000 comme le montrent les deux captures d’écran ci-dessous :

    5.3 Conclusion

    Sur le plan de la mise en cache, la version 2004 n’apporte donc aucunes modifications par rapport à l’ancienne mouture si ce n’est l’ordre d’application des règles de cache et la centralisation de tous les paramètres de la mise en cache dans une même fenêtre.

    Mise en place d’un serveur VPN

    6.1 Introduction

    Avec ISA Server 2000, il est possible de mettre en place un serveur VPN directement dans la console de gestion ISA. Cependant ce même serveur doit être paramétré comme un serveur VPN « classique » c’est-à-dire dans la console « routage et accès distant ». Avec l’introduction d’ISA Server 2004, on doit réaliser l’intégralité de la configuration du serveur VPN dans la console de gestion ISA.

    Comme nous allons le voir dans la suite de ce chapitre, cette nouveauté permet une configuration plus aisée et surtout bien plus sécurisée.

    6.2 Un paramétrage simplifié

    Pour commencer, la fenêtre de paramétrage des réseaux privés virtuels peut être accédée directement à partir de l’arborescence de la console du serveur ISA.

    Cette fenêtre va permettre de mettre en place un serveur VPN en quelques clics. En effet, lorsque l’on sélectionne une topologie réseau avec l’assistant de configuration réseau, les paramètres du VPN sont automatiquement réglés pour une mise en production rapide.

    Ainsi lorsque l’on a choisi la topologie réseau pare-feu de périmètre, un serveur VPN est configuré afin d’écouter les éventuelles requêtes faites sur la carte réseau externe en utilisant le protocole PPTP et la méthode d’authentification MS-CHAP V2.0. De plus le serveur VPN assigne les adresses IP aux clients VPN en utilisant un serveur DHCP et accepte un maximum de 5 connexions.

    En résumé, pour rendre le serveur VPN fonctionnel lorsque l’on a choisi la topologie réseau pare-feu de périmètre, il faut simplement activer le serveur VPN (qui est paramétré automatiquement, mais pas activé) et choisir les groupes et/ou les utilisateurs qui ont le droit de se connecter à distance. On peut donc utiliser le serveur VPN intégré à ISA en trois clics de souris.

    Bien entendu, les options du serveur VPN peuvent être modifiées à loisir. Pour cela il faut utiliser l’onglet Tâches qui apparaît sur la fenêtre de configuration du VPN. Nous allons voir que le serveur VPN d’ISA possède des fonctions non implémentées dans celui intégré à Windows Server 2003.

    6.3 De nouvelles options

    Le menu Tâches, ci-contre, permet de paramétrer toutes les options du serveur VPN. L’option Configurer l’accès des clients VPN lance une fenêtre composée de quatre onglets :

    • Général : activer/désactiver l’accès des clients au serveur VPN et sélectionner le nombre de connexions simultanées (le nombre de connexion par défaut est de 5).
    • Groupes : choisir les groupes qui ont l’autorisation d’établir une connexion distante via le serveur VPN.
    • Protocoles : permet de choisir le protocole de tunnelling que l’on souhaite utiliser. Les choix disponibles sont PPTP et L2TP/IPSec (le protocole choisi par défaut est PPTP).
    • Mappage des utilisateurs : permet d’appliquer les règles de stratégie d’accès au pare-feu définies par défaut aux client VPN qui s’authentifient avec un protocole d’authentification non Windows (par exemple avec le protocole RADIUS ou le protocole EAP).

    Les quatre options situées dans Configuration VPN générale (Sélectionnez les réseaux, Sélectionnez les attributions d’adresses, Sélectionnez les méthodes d’authentification et Spécifier la configuration RADIUS) renvoient toutes à la même fenêtre qui se compose logiquement de quatre onglets.

    Le premier onglet nommé Réseaux d’accès (accessible en cliquant sur Sélectionnez les réseaux d’accès) permet de choisir à partir de quelle interface le serveur VPN sera accessible par les clients et/ou les autres serveurs VPN.

    Dans le cas du pare-feu de périmètre, le paramètre par défaut est le réseau externe.

    Cela est normal puisque avec cette topologie, on possède deux réseau : un réseau interne (le réseau privé de l’entreprise) et un réseau public (Internet). On souhaite bien entendu faire bénéficier les clients externes de l’accès à distance et non l’inverse.

    L’onglet Attribution d’adresses (accessible en cliquant sur Sélectionnez les réseaux d’accès) permet de forcer le serveur VPN a assigner lui-même les adresses IP aux clients VPN parmi une plage d’adresses prédéfinies ou bien à utiliser les adresses fournies par un serveur DHCP.

    Dans le second cas, on doit sélectionner l’interface sur laquelle le serveur VPN essayera de contacter un serveur DHCP et choisir (en cliquant sur le bouton Avancé) si les adresses IPs des serveur DNS et WINS seront dynamiques (c’est-à-dire attribuées par le serveur DHCP en même temps que l’adresse IP du client) ou bien statiques.

    L’onglet Authentification (accessible en cliquant sur Sélectionnez les méthodes d’authentification) propose un large choix de protocoles pour permettre l’authentification des clients d’accès distant.

    Le protocole sélectionné par défaut est MS-CHAP v2. On peut aussi utiliser EAP. D’autres méthodes, moins sécurisées, sont présentes mais uniquement à titre de compatibilité. On peut citer MS-CHAP, CHAP, SPAP et PAP.

    Enfin, il est possible d’utiliser une clé pré partagée si l’on utilise le protocole L2TP/IPsec.

    Une des principales nouveautés d’ISA Server 2004 est la possibilité de pouvoir utiliser un serveur RADIUS pour authentifier les clients d’accès distants.

    L’onglet RADIUS (accessible en cliquant sur Sélectionnez la configuration RADIUS) propose d’activer cette fonctionnalité. Dans le cas où ce paramètre est sélectionné on peut choisir d’enregistrer les évènements liés à l’établissement et à la fermeture des sessions VPN dans le journal du serveur RADIUS.

    Pour spécifier la liste de serveurs RADIUS a contacter il faut cliquer sur le bouton Serveurs RADIUS et entrer les serveurs dans l’ordre de priorité avec lequel ils doivent être utilisés.

    6.4 La fonction de mise en quarantaine

    Une des fonctionnalités les plus innovantes d’ISA Server 2004 reste la mise en quarantaine des clients VPN. En effet, la mise en place d’un serveur VPN pose un gros problème en ce qui concerne la sécurité malgré le fait que le processus d’authentification et que les échanges soient cryptés. La faille provient souvent des machines clientes car elles sont souvent infectées par divers virus, vers, chevaux de Troie et autres logiciels espions. Ces virus, par le biais du réseau privé virtuel, finissent par se retrouver sur le réseau de l’entreprise, ruinant ainsi tous les efforts des administrateurs réseau !

    La fonction de mise en quarantaine permet d’isoler les clients ne répondant à certains critères dans un réseau spécifique nommé clients VPN en quarantaine. Les critères de sélections doivent être définis dans un script qui s’exécute après l’authentification des clients. Ce script n’est pas fourni par Microsoft avec ISA Server et doit donc être développé par l’administrateur ce qui offre une plus grande flexibilité. Il est tout de même dommage que Microsoft ne se soit pas donné la peine de fournir des scripts prédéfinis pour certains scénarios. On peut notamment créer un script vérifiant si le pare-feu du client est actif et si son antivirus et son système sont à jour.

    En raison de la difficulté de mise en place de ce service et de l’envergure du sujet, nous traiterons la configuration de la mise en quarantaine dans un autre article qui lui sera dédié.

    6.5 Conclusion

    ISA Server 2004 apporte son lot de nouveautés en ce qui concerne la configuration du serveur VPN. Parmi celles-ci, on peut citer

    • le support de l’authentification RADIUS et SecureID

    • la fonction de mise en quarantaine

    • le protocole IPSec tunnel mode qui permet de créer un lien de site à site entre un serveur ISA et n’importe quel type de serveur VPN (routeur, machine Unix,…)

    Configuration des ordinateurs clients

    7.1 Introduction

    A l’instar d’ISA 2000, il est possible de configurer les ordinateurs clients de trois manières différentes. C’est pourquoi on en distingue trois types :

    • les clients de pare-feu

    • les clients du Proxy web

    • les clients SecureNAT

    Les possibilités offertes en terme de sécurité, de fonctionnalités mais aussi de déploiement diffèrent en fonction du type de client.

    7.2 Configurer un client SecureNAT

    Un client SecureNAT est un ordinateur configuré pour utiliser l’adresse IP du serveur ISA en tant que passerelle par défaut. Toute machine exécutant un système d’exploitation sur lequel la pile de protocole TCP/IP est supportée (UNIX, BSD, Linux, Windows,…) peut donc devenir un client SecureNAT. Bien évidemment lorsqu’un ou plusieurs routeurs séparent le client SecureNAT du serveur ISA, le client devra utiliser l’adresse IP du routeur le plus proche de lui en tant que passerelle par défaut. Ce type de client s’avère simple et rapide à implémenter lorsque le protocole DHCP est utilisé (en effet, il n’y a qu’une option a paramétrer au niveau du serveur DHCP pour que les clients SecureNAT fonctionnent).

    L’un des défauts majeur du client SecureNAT est labsence de système d’authentification. En effet, là où le client de pare-feu et le client du Proxy web permettent de retrouver l’identité de l’utilisateur, le client SecureNAT permet uniquement de retrouver l’adresse IP de la machine. Cela signifie que les restrictions sur les utilisateurs et les groupes d’utilisateurs ne s’appliquent pas aux clients SecureNAT. Ceci explique pourquoi ils sont utilisés uniquement lorsque cela est nécessaire :

    • dans le cas d’ordinateurs ne supportant pas le client pare-feu (c’est-à-dire sous Unix/Linux)

    • dans le cas de serveurs devant être publiés

    7.3 Configurer un client du Proxy web

    Un client du Proxy web est un ordinateur exécutant une application configurée pour utiliser le serveur ISA en tant que serveur de proxy. L’exemple type est un navigateur web comme Safari, Opéra ou bien encore Internet Explorer. Voici quelques caractéristiques des clients du Proxy web :
    • ils sont utilisables sur n’importe quel système d’exploitation (sauf les OS ne gérant pas TCP/IP et ne possédant aucun navigateur web…).
    • les seuls protocoles supportés sont HTTP, HTTPS et FTP sur HTTP (protocole permettant de consulter le contenu d’un serveur FTP à l’aide d’un navigateur web en saisissant des adresses du type ftp://nom_du_serveur dans la barre des URL).
    • Ils proposent d’authentifier ou non les utilisateurs.

    Ci-contre, la capture d’écran d’un ordinateur exécutant Internet Explorer et configuré en tant que client du Proxy web. Il suffit définir le nom du serveur ISA ainsi que le port utilisé dans le navigateur (cette fenêtre est est accessible via Outils / Options Internet / Connexions / Paramètres réseaux). Bien entendu, l’apparence et l’emplacement de ces paramètres changent d’un logiciel à l’autre.

    Lorsque le serveur ISA reçoit une requête sur le port 80, le client est toujours considéré comme un client du Proxy web, et ce quelque soit sa configuration réelle (SecureNAT, Proxy web ou pare-feu).

    Par défaut, ISA Server 2004 utilise le port 8080 pour communiquer avec les clients du Proxy web. Pour modifier ce paramètre, il faut afficher les propriétés du réseau Interne en développant Configuration / Réseaux dans l’arborescence de la console de Gestion ISA. L’onglet Proxy web permet de modifier les ports utilisés pour les protocoles HTTP et HTTPS (les valeurs par défaut sont respectivement 8080 et 8443).

    L’onglet Proxy web permet aussi d’activer ou non l’authentification des clients du Proxy web (il suffit de côcher la case Exiger que tous les utilisateurs s’authentifient). Plusieurs méthodes d’authentifications sont disponibles :
    • De base : Cette méthode est à proscrire absolument car les informations d’identification (identifiant et mot de passe) sont envoyées en clair !
    • Digest : Les informations d’identification sont hachées ce qui offre une meilleure sécurité que l’authentification de base. Lorsque l’on côche la case Digest et que le serveur ISA est installé sur un ordinateur exécutant Windows Server 2003, le protocole réellement utilisé est WDigest.
    • Intégrée : L’authentification dite Intégrée correspond au protocole Kerberos V5 (ou NTLM dans certains cas). Kerberos met en oeuvre le hachage des données et propose une authentification mutuelle.
    • Certificat SSL : Cette méthode vérifie l’identité du client et du serveur à l’aide de certificat numériques préalablement distribués par une autorité de certification. Le protocole de cryptage utilisé est SSL pour Secure Sockets Layer.
    • RADIUS : RADIUS signifie Remote Authentification Dial-In User Service. C’est un protocole d’authentification standard faisant intervenir le protocole de hachage MD5.
    La méthode d’authentification à privilégier au sein d’un domaine reste l’authentification intégrée à Windows en raison de son haut niveau de sécurité. La mise en place de l’authentification des clients du Proxy web ne doit pas être négligée sinon les restrictions des règles accès sur les utilisateurs et sur les groupes d’utilisateurs ne s’appliqueront pas. En outre, l’authentification permet d’obtenir des statistiques concernant les utilisateurs par le biais des rapports.

    Dès que l’une des méthodes d’authentification a été choisie, une fenêtre équivalente à celle présentée ci à droite apparaît. Deux possibilités s’offrent à l’utilisateur :

    • Renseigner les champs Nom d’utilisateur et Mot de passe à chaque nouvelle instance du navigateur
    • Mémoriser l’identifiant et le mot de passe pour ne plus avoir à les remplir

    7.4 Utilisation du protocole WPAD pour paramétrer automatiquement les clients du Proxy web

    Lorsque les ordinateurs utilisent Microsoft Internet Explorer, leurs configuration en tant que clients du Proxy web est facilité. En effet, il est possible de configurer les paramètres du Proxy à l’aide d’un objet stratégie de groupe ou GPO (Group Policy Object). Cela implique évidemment que les ordinateurs appartiennent à un domaine Active Directory. Les paramètres du Proxy (adresse IP, port, …) pour Internet Explorer sont configurables au niveau du compte d’utilisateur ou bien au niveau du compte d’ordinateur. Dans les deux cas, il faut développer Paramètres Windows / Maintenance de Internet Explorer / Connexion à l’aide de la console Éditeur de stratégie de groupe.

    Lorsqu’une application autre que Internet Explorer doit être configurée, la tâche se révèle plus contraignante puisqu’il n’existe aucun moyen de l’automatiser. Les clients doivent donc être configurés manuellement ce qui entraîne :

    • une perte de temps lors de la configuration initiale des applications

    • une perte de temps si le serveur de Proxy change d’adresse IP (il faut alors reconfigurer à la main toutes les applications alors qu’avec une GPO il n’y a qu’une valeur à modifier une seule fois)

    • une perte de temps si l’ordinateur qui héberge le programme est mobile. En effet, un cadre se déplaçant de succursale en succursale avec son ordinateur portable devra reconfigurer manuellement l’adresse IP du serveur de Proxy à chaque changement de site (en supposant qu’il y ait un serveur de Proxy par site). Dans ce cas bien précis, une GPO n’est d’aucun secours…

    Pour palier à cela, il est possible d’implémenter le protocole WPAD (Web Proxy AutoDetect) qui permet de configurer automatiquement les programmes pour pointer vers le bon serveur de proxy. Bien entendu les applications doivent être conçues pour supporter WPAD (tous les navigateurs récent tels Opéra, IE, Safari, Konqueror, Firefox ou bien encore Netscape Navigator le supportent). C’est par exemple le cas avec Internet Explorer depuis la version 5.0 et Netscape Navigator depuis la version 2.0. WPAD propose deux manière différente pour configurer automatiquement les applications web :

    • à l’aide d’un enregistrement de ressource spécifique dans le serveur DNS

    • à l’aide d’une option spécifique dans le serveur DHCP

    La première chose à faire avant même de configurer le serveur DNS ou bien le serveur DHCP est d’activer la prise en charge du protocole WPAD au niveau du serveur ISA. Pour cela, il suffit d’aller dans les propriétés du réseau Interne, puis de côcher la case Publier les informations de détection automatique, située dans l’onglet Détection automatique.
    Par défaut, les informations de configuration automatique sont publiées sur le port 80. Il est possible de modifier cette valeur mais cela n’est pas recommandé. En effet, certains programmes ne peuvent détecter automatiquement la configuration du serveur Proxy que via le port 80. C’est notamment le cas des navigateurs basés sur le moteur Gecko (Mozilla / Firefox / Netscape Navigator)

    Si vous choisissez d’utiliser un port différent avec ces navigateurs, il faudra spécifier l’adresse de configuration automatique du Proxy manuellement ce qui s’avère aussi contraignant que de définir l’adresse du serveur de Proxy de façon classique… L’utilisation du port 80 est donc de mise pour ce service sauf si une autre application utilise déjà ce port sur le serveur ISA.

    Ci-contre la fenêtre de configuration des paramètres de connexion du navigateur Firefox dans sa version 1.0. On remarque que l’option Détection automatique des paramètres du Proxy sur ce réseau a été activée ce qui signifie que Firefox essaye de se configurer automatiquement à l’aide du protocole WPAD en effectuant une recherche sur le port 80.

    Pour configurer un grand nombre de machines en tant que clients du Proxy web, l’utilisation du serveur DHCP se révèle la plus efficace. Pour cela il faut créer une nouvelle option DHCP (clic droit sur le nom du serveur, puis Définir les options prédéfinies… dans la console DHCP). Ci-contre, la fenêtre de création d’une option DHCP. Il faut définir plusieurs paramètres :
    • le nom de l’option
    • le type de données (la case à cocher tableau permet de créer des options multivaluées)
    • le code de l’option
    • une description (facultative)

    Il faut ensuite attribuer la valeurhttp://nom_du_serveur_de_proxy:port_utilisé/wpad.dat à l’option WPAD précédemment crée. Bien entendu, vous pourrez appliquer cette option au niveau du serveur, d’une étendue, d’une classe DHCP ou bien encore d’un client réservé.

    L’administrateur peut aussi utiliser le serveur DNS pour configurer automatiquement les ordinateurs clients en tant que clients du Proxy web. Il suffit simplement de créer un enregistrement de ressource de type Alias (CNAME) nommé WPAD pointant vers le nom de domaine pleinement qualifié (FQDN) du serveur de proxy.

    Cet enregistrement doit être créé dans le même domaine que les ordinateurs clients. Lorsque l’option DHCP 252 n’a pas été affectée, le client contacte le serveur DNS pour savoir si il existe un enregistrement de ressource nommé wpad.suffixe_dns_client. Le client récupère donc l’adresse IP du serveur de Proxy en deux étapes :

    • le client cherche le FQDN correspondant à wpad.laboms.net (le serveur DNS renvoie la réponse isa-2004.laboms.net)
    • le client cherche l’adresse IP correspondant à isa-2004.laboms.net (le serveur DNS renvoie la réponse 10.1.0.1)

    7.5 Déploiement et configuration du client pare-feu

    Un client pare-feu est un ordinateur sur lequel l’application client de pare-feu Microsoft est installée. Cette application configure automatiquement la machine pour accéder à Internet ou à un autre réseau par l’intermédiaire d’un serveur ISA. Il est possible de déployer ce logiciel de diverses manières :

    • via le partage \\serveur_isa_2004\mspclnt crée automatiquement lors de l’installation d’ISA
    • via un objet stratégie de groupe (GPO)
    • via un package System Management Server (SMS) 2003
    Le paramétrage du client de pare-feu est on ne peut plus simple. L’onglet Général permet de sélectionner manuellement ou automatiquement le serveur ISA. Dans le second cas, le protocole WSPAD (WinSock Proxy AutoDetect) est utilisé. WSPAD se configure de la même manière que WPAD (via un serveur DHCP ou un serveur DNS). L’onglet Navigateur Web permet quand à lui de configurer automatiquement Internet Explorer. Les paramètres appliqués au navigateur doivent être définis au niveau du serveur ISA.
    On peut configurer les paramètres du Proxy que va recevoir le navigateur (par l’intermédiaire du logiciel client de pare-feu Microsoft) dans les propriétés du réseau Interne. Trois choix sont possibles correspondant aux trois méthodes de configuration d’un client du Proxy web (partie 8.3) :
    • Détecter automatiquement les paramètres de connexion
    • Utiliser un script de configuration automatique
    • Utiliser un serveur Proxy web

    7.6 Interopérabilité avec le client pare-feu d’ISA 2000

    Le client pare-feu Microsoft d’ISA Server 2004 crypte les échanges entre le client et le serveur. Cette fonctionnalité n’est pas prise en charge avec le logiciel client de pare-feu Microsoft d’ISA Server 2000. Deux solutions s’offrent alors :
    • Mettre à jour le client (fortement recommandé)
    • Activer la prise en charge des connexions non cryptées. Pour cela, il faut développer Configuration / Général dans l’arborescence de la console de gestion ISA, puis cliquer sur Définir les paramètres de clients de pare-feu.

    7.7 Conclusion

    Il est difficile de déterminer quelle configuration est la plus adaptée en ce qui concerne les machines clientes. En effet, ce choix dépend fortement du type de machines déployées (Windows, Linux, Mac OS, BSD,…), des logiciels installés (notamment des navigateurs), du niveau de sécurité nécessaire, de l’infrastructure en place (domaine/groupe de travail; DMZ)… Voici un petit tableau récapitulatif des caractéristiques des différents clients :

    Pare-feu

    Proxy web

    SecureNAT

    Authentification des utilisateurs supportée

    Oui

    Oui si configurée

    Non

    S

    ystème d’exploitation supportés

    Windows

    Tous

    Tous

    P

    rotocoles supportés

    Tous

    HTTP / HTTPS / FTPover HTTP

    Tous

    Maintenance

    contraignante (nécessité de redémarrer le service dans certains cas)

    aisée (sauf quand le Proxy est configuré manuellement)

    aisée (rien à configurer sauf la passerelle)

    Configuration requise sur les clients

    installation et configuration d’un logiciel

    configuration du navigateur

    configuration de la passerelle par défaut

    De manière générale, l’utilisation de clients pare-feu est recommandée. Sur des configurations exotiques, l’utilisation des clients SecureNAT est de mise. Cependant, il peut s’avérer utile du point de vue de la sécurité de configurer les clients SecureNAT en tant que clients du Proxy web (pour bénéficier de l’authentification).

    Surveillance et monitoring d’ISA Server 2004

    8.1 Introduction

    En ce qui concerne les fonctionnalités liées au monitoring, ISA Server 2004 offre peu de nouveautés par rapport à la version 2000 :

    • une fenêtre résumant toutes les informations nommée tableau de bord
    • la possibilité de définir des vérificateurs de connectivité
    • l’interface de configuration est bien plus intuitive que celle de l’utilitaire de gestion ISA 2000
    • les modifications sont toujours appliquées immédiatement
    • par défaut, toutes les données sont stockées dans la base de donnée MSDE plutôt que dans des fichiers

    8.2 Vue d’ensemble du tableau de bord

    Le tableau de bord, accessible à la racine de l’arborescence récapitule les éléments essentiels sur le serveur
    • l’état des services et des vérificateurs de connectivité
    • les derniers rapports et alertes générés
    • les sessions actives classées par type
    • l’activité du serveur

    Ce panneau permet de diagnostiquer rapidement un éventuel problème car il se rafraîchit à intervalles réguliers (il est possible de forcer le rafraîchissement).

    le tableau de bord d’ISA Server 2004

    8.3 Configuration et utilisation des vérificateurs de connectivité

    Les vérificateurs de connectivité permettent de tester l’accessibilité à un serveur ou à une machine donnée. Le test peut prendre plusieurs formes :
    • une requête ICMP (ping)
    • une requête HTTP
    • une requête sur un port TCP choisi par l’administrateur

    Certains vérificateurs sont pré configurés et accessibles via une liste déroulante :

    • Active Directory (envoie une requête LDAP au contrôleur de domaine choisi)
    • Autre (propose une trentaine de port TCP communément utilisés comme FTP, PPTP, POP3, RDP…)
    • DHCP
    • DNS
    • Serveurs publiés
    • Web (Internet)

    Une fois le vérificateur créé, il est possible de définir un seuil au-delà duquel l’ordinateur est considéré comme injoignable (dans ce cas, une alerte est générée). La fenêtre connectivité liste les vérificateurs de connectivité et affiche leur état ainsi que diverses autres informations (seuil, type de requête, temps de réponse,…).

    8.4 Gestion de la journalisation

    De la même manière que sous ISA 2000, il est possible de créer automatiquement des rapports sur l’activité du serveur. Ils sont générés à partir des informations stockées dans les fichiers journaux et permettent notamment de vérifier les performances de la mise en cache etles accès non souhaités. Il est très important de bien choisir les champs qui doivent être sauvegardés dans les fichiers journaux. En effet par défaut quasiment tous les champs sont sélectionnés, ce qui génère de “gros” fichiers journaux. Voici les fichier journaux générés par un serveur ISA protégeant un réseau constitué de 35 postes clients sous Windows 2000 professionnel :

    On remarque que l’espace disque utilisé pour stocker les “logs” de trois jours distinct est de 1,4 Go ! Le nombre de champs enregistrés dans la base de données se configure dans l’onglet Journalisation de la fenêtreSurveillance.

    8.5 Génération de rapports

    Le processus de création de rapport d’ISA Server 2004 est similaire à celui de la version 2000. Il est possible de générer des rapports mensuels, hebdomadaires, quotidiens ou bien de les générer manuellement. Lors de la création du rapport un processus nommé IsaRepGen.exe parcourt l’intégralité des données de la base et compile les informations pour les rendre exploitable (en créant une page web). Les tâches de rapports ne doivent pas être exécutées au hasard, surtout sur un serveur en production ! En effet, la création de rapport demande beaucoup de ressources matérielles surtout en ce qui concerne le temps processeur, l’utilisation de la mémoire vive et les accès disque. D’où l’intérêt de planifier les tâches de rapport dans une plage horaire où le serveur ISA n’est pas ou peu utilisé (la nuit ou le week-end).

    Ci-contre la génération d’un rapport d’activité mensuel sur un serveur ISA gérant 30 machines clientes. La création a duré environ 2 heures alors que l’ordinateur utilise un processeur cadencé à 2 GHz, dispose de 512Mo de mémoire vive et utilise un disque dur tournant à 7200 tr/min ! On remarque que le processus accapare : 99% du temps processeur, 230Mo de mémoire vive et 256 Mo de mémoire virtuelle…

    Heureusement ce processus s’exécute en fond de tâche (et avec une priorité plus faible) ce qui permet au serveur de continuer à répondre aux demandes des clients.

    8.6 Conclusion

    Pour conclure, les capacité de monitoring d’ISA Server 2004 sont identiques à celles de la version 2000 malgré quelques améliorations sensibles en terme d’ergonomie et de performance (utilisation de MSDE au lieu des fichiers textes pour stocker les données). En revanche il faut se méfier des fonction de journalisation et de création de rapports qui demandent :

    • de fortes ressources matérielles
    • beaucoup d’espace disque

    Migration de ISA Server 2000 vers ISA Server 2004

    9.1 Prérequis

    Pour l’instant, la seule version de ISA Server 2004 disponible est la version standard. La migration d’un d’ISA 2000 Enterprise vers une ISA 2004 Standard est impossible. En résumé, la seule migration actuellement possible est ISA 2000 Standard vers ISA 2004 Standard.

    Pour réaliser cette migration, il est recommandé d’installer le service pack 2 pour ISA 2000 que vous trouverez ici. Il est néanmoins possible de se passer du service pack 2 en installant une mise à jour spécifique. Cette mise à jour nécessite l’installation :

    • du service pack 2 de Windows 2000 disponible ici

    • du service pack 1 de ISA Server 2000 disponible ici.

    La mise à jour est, quand à elle, téléchargeablegrâce à ce lien. Les installations des services pack et de la mise à jour pour ISA ne présentant aucune difficultés majeures, elles ne seront pas détaillées ici.

    Si vous souhaitez utiliser le filtre SMTP, le service SMTP de IIS doit être installé via la console Ajouter ou supprimer des composants Windows.

    9.2 Sauvegarde des paramètres du serveur ISA en vue d’une migration

    Lors d’une mise à jour du serveur ISA, il est possible de sauvegarder les paramètres de la version 2000 pour les réinjecter dans la version 2004.

    Une fois que le Cdrom est inséré, et si l’autorun est activé, il faut lancer l’Assistant Migration .

    Comme expliqué sur la capture d’écran, cet assistant permet d’exporter la configuration VPN et RAS dans un fichier XML, qui sera importé sur ISA Server 2004.

    Dès le début de la migration, l’assistant demande de choisir le nom du fichier XML qui servira lors de la sauvegarde.

    Lors de l’installation de ISA Server 2000, les clients ont, par défaut, la possibilité d’accéder à l’ordinateur exécutant ISA Server. Il est possible dans ISA Server 2004 de désactiver cette fonction afin de garantir un meilleur niveau de sécurité.

    Toutes les informations nécessaires à la sauvegarde des paramètres ont été collectées, la sauvegarde peut donc commencer vers le fichier que vous avez sélectionné lors de la première étape.

    Au bout de quelques secondes, vous disposez d’un fichier XML contenant toutes informations sur la configuration de votre serveur ISA 2000.

    L’Assistant Migration est maintenant terminé. Comme indiqué au début de la migration, toutes les opérations effectuées ont été enregistrées dans un fichier de log du même nom que votre fichier XML avec l’extension .log.

    Lors de l’ouverture de ce fichier, on peut constater que certaines mise à jour n’ont pas fonctionné. On peut notamment citer les alertes :

    • Composant d’installation manquant
    • Paquet IP ignoré
    • Le serveur n’est pas dans le site du groupe
    • Échec du fractionnement de flux actifs WMT
    • Violation de protocole IP

    Ces composants ne sont pas implémentés dans ISA Server 2004. C’est pourquoiil est impossible de les sauvegarder. En revanche, on peut constater tous les autres paramètres ont été exportés avec succès.

    9.3 Mise à niveau du serveur

    Maintenant que toutes les mises à jour et toutes les sauvegardes ont été effectuées, on peut sans craintes installer ISA Server 2004 grâce au menu principal. Il suffit de cliquer sur Installer ISA Server 2004.

    L’Assistant d’Installation ne va pas supprimer ISA Server 2000, il se contentera de mettre à jour les composants déjà présents.

    Le processus de mise à jour d’ISA 2000 vers ISA 2004 est quasiment identique à une installation classique. C’est pourquoi elle n’est détaillée dans cette page. Vous pouvez néanmoins consulter toutes les étapes sur cette page.

    9.4 Importation des paramètres précédemment sauvegardés dans ISA Server 2004

    Vous devez normalement avoir un ISA Server 2004 fonctionnel. Il faut maintenant importer le fichier XML contenant les sauvegardes.

    Ce fichier XML, nommé ISA2KExport.xml (si vous avez validé le choix par défaut), s’importe dans ISA Server 2004 grâce à une boite de dialogue accessible via un lien situé dans le bas de l’onglet Tâches : Importer depuis un fichier de configuration ISA Server exporté.

    Il suffit ici de sélectionner le fichier exporté précédemment et de cliquer sur importer afin de charger la configuration. Il est également possible d’importer les paramètres d’autorisations utilisateurs et ceux des lecteurs de cache et des certificats SSL. Une fois que les modifications ont été chargées, il suffit de cliquer sur Appliquer pour les rendre efficientes.

    Lors d’un chargement de fichier de sauvegarde, les services doivent être redémarrés pour appliquer ces modifications de configuration.