Sécurisation de votre serveur Web

Sur cette page

Dans ce module
Objectifs
S'applique à
Présentation
Menaces et contre-mesures
Méthodologie de sécurisation de votre serveur Web
Remarques sur l'installation d'IIS et de .NET Framework
Recommandations d'installation
Étapes de sécurisation de votre serveur Web
Étape 1. Correctifs et mises à jour
Étape 2. IISLockdown
Étape 3. Services
Étape 4. Protocoles
Étape 5. Comptes
Étape 6. Fichiers et répertoires
Étape 7. Partages
Étape 8. Ports
Étape 9. Registre
Étape 10. Audit et consignation
Étape 11. Sites et répertoires virtuels
Étape 12. Mappages de script
Étape 13. Filtres ISAPI
Étape 14. Métabase IIS
Étape 15. Certificats de serveur
Étape 16. Machine.config
Étape 17. Sécurité d'accès au code
Instantané d'un serveur Web sécurisé
Rester protégé
Administration distante
Simplification et automatisation de la sécurité
Résumé
Informations complémentaires

Dans ce module

Le serveur Web est le composant frontal de votre infrastructure d'hébergement. Il est directement connecté à Internet et est responsable de la réception des requêtes de vos clients, de la création des pages Web dynamiques et de l'envoi des réponses avec les données demandées.

Un serveur Web sécurisé constitue une base solide pour votre environnement d'hébergement et sa configuration y joue un rôle critique pour la sécurité globale de vos applications Web. Mais quels sont les éléments qui sécurisent un serveur Web ? Une partie du défi de la sécurisation de votre serveur Web consiste justement à reconnaître votre objectif. Dès que vous saurez ce qu'est un serveur Web sécurisé, vous pourrez apprendre à appliquer les paramètres de configuration nécessaires pour en créer un.

Ce module offre une approche systématique et transposable pour vous permettre de réussir la configuration d'un serveur Web sécurisé. La méthodologie présentée ici découpe la configuration de votre serveur en douze zones de sécurité. Chacune de ces zones de sécurité est traitée par une série d'actions de haut niveau. Les étapes sont modulaires et démontrent comment mettre la méthodologie en pratique.

Haut de page

Objectifs

Ce module vous permettra :

• d'apprendre ce qu'est un serveur Web sécurisé ;

• de sécuriser vos serveurs Web à l'aide d'une méthodologie éprouvée ;

• de connaître les éléments installés lors de l'installation de ISS et de .NET Framework par défaut sur Windows 2000 Server ;

• d'apprendre quels services peuvent être désactivés en toute sécurité sur un serveur Web sécurisé ;

• de configurer votre serveur Web en toute sécurité, y compris les protocoles du système d'exploitation, les comptes, les fichiers, les répertoires, les partages, les ports, les stratégies d'audit et la consignation ;

• de configurer en toute sécurité les composants de votre application de serveur Web (ici IIS), y compris les sites Web, les répertoires virtuels, les mappages de script, les filtres ISAPI, la métabase et les certificats de serveur ;

• de configurer en toute sécurité les paramètres .NET Framework, y compris le fichier Machine.config et la sécurité d'accès au code ;

• d'installer et d'utiliser de manière sécurisée les services Terminal Server pour l'administration à distance ;

• de connaître les mesures à prendre pour faire face aux menaces les plus courantes, parmi lesquelles le profilage, le refus de service, l'accès non autorisé, l'exécution arbitraire de code, l'augmentation des privilèges, les virus, les vers ou les chevaux de Troie.

Haut de page

S'applique à

Ce module s'applique aux produits et technologies suivants :

• Microsoft Windows Server 2000 et 2003

• Microsoft .NET Framework 1.1 et ASP.NET 1.1

• Microsoft Internet Information Services (IIS) 5.0 et 6.0

Haut de page

Présentation

Quels sont les éléments qui sécurisent un serveur Web ? Une partie du défi de la sécurisation de votre serveur Web consiste justement à reconnaître votre objectif. Dès que vous saurez ce qu'est un serveur Web sécurisé, vous pourrez apprendre à appliquer les paramètres de configuration nécessaires pour en créer un. Ce module offre une approche systématique et transposable qui vous servira à réussir la configuration d'un serveur Web sécurisé.

Ce module passe tout d'abord en revue les menaces les plus courantes auxquelles doivent faire face les serveurs Web. Ces données serviront ensuite à créer une méthodologie. Le module propose dans un troisième temps de mettre en pratique la méthodologie, en utilisant une approche étape par étape pour vous montrer comment améliorer la sécurité de vos serveurs Web. Bien que la méthodologie de base soit réutilisable d'une technologie à l'autre, ce module s'attarde sur la sécurisation d'un serveur Web sous Windows 2000, équipé de Microsoft .NET Framework.

Haut de page

Menaces et contre-mesures

La possibilité pour l'attaquant de porter un coup à distance fait du serveur Web une cible tentante à bien des égards. Comprendre les menaces de votre serveur Web et être capable d'identifier les contre-mesures appropriées vous permet d'anticiper de nombreuses attaques et de contrecarrer le nombre sans cesse croissant d'attaquants.

Les principales menaces du serveur Web sont les suivantes :

• Profil

• Refus de service

• Accès non autorisé

• Exécution arbitraire du code

• Élévation des privilèges

• Virus, vers et chevaux de Troie

La figure 16.1 résume les attaques les plus communes ainsi que les vulnérabilités courantes.

Figure 16.1
Menaces du serveur Web prédominantes et vulnérabilités courantes

Profil

Le profilage, ou énumération de sessions, est un processus d'exploration utilisé pour collecter des informations sur votre site Web. L'attaquant utilise ces informations pour attaquer vos points faibles connus.

Vulnérabilités

Les éléments suivants sont susceptibles de rendre votre serveur vulnérable aux tentatives de profilage :

• Protocoles inutiles

• Ports ouverts

• Serveurs Web fournissant des informations de configuration dans les bannières

Attaques

Parmi les attaques courantes utilisées pour le profilage figurent :

• L'analyse des ports

• Les balayages de Ping

• L'énumération NetBios et bloc de message serveur (SMB)

Contre-mesures

Les contre-mesures consistent à bloquer tous les ports inutiles, à arrêter le trafic ICMP (Internet Control Message Protocol) et à désactiver les protocoles inutiles tels que NetBIOS et SMB.

Refus de service

Les attaques par refus de service surviennent lorsque votre serveur est saturé par les requêtes de service. La menace réside dans le fait que votre serveur peut être trop submergé pour répondre aux requêtes de clients légitimes.

Vulnérabilités

Les éléments suivants sont susceptibles de rendre votre serveur plus vulnérable aux refus de service :

• Configuration faible de la pile TCP/IP

• Serveurs non mis à jour

Attaques

Les dispositifs de refus de service couramment utilisés pour lancer des attaques sont les suivants :

• Saturations SYN au niveau du réseau

• Dépassement de capacité de la mémoire tampon

• Saturation du serveur Web avec des requêtes issues d'emplacements distribués

Contre-mesures

Parmi les contre-mesures, on compte le renforcement de la pile TCP/IP et l'application cohérente des derniers correctifs logiciels et mises à jour sur le logiciel système.

Accès non autorisé

On parle d'accès non autorisé lorsqu'un utilisateur sans autorisation parvient à accéder aux informations protégées ou effectue une opération restreinte.

Vulnérabilités

Les vulnérabilités courantes pouvant entraîner un accès non autorisé sont les suivantes :

• Faibles contrôles d'accès au Web IIS, autorisations Web comprises

• Autorisations NTFS faibles

Contre-mesures

Les contre-mesures consistent à utiliser des autorisations Web sécurisées, les autorisations NTFS et les mécanismes de contrôle d'accès .NET Framework, tels que les autorisations d'URL.

Exécution arbitraire du code

Les attaques par exécution de code se produisent lorsqu'un attaquant exécute un code nuisible sur votre serveur pour en compromettre les ressources ou pour lancer d'autres attaques contre les systèmes en aval.

Vulnérabilités

Les vulnérabilités pouvant conduire à une exécution malveillante du code sont :

• Configuration IIS faible

• Serveurs non mis à jour

Attaques

Les attaques courantes par exécution du code sont les suivantes :

• Pénétration des répertoires

• Dépassement de capacité de la mémoire tampon menant à l'injection de code

Contre-mesures

Parmi les contre-mesures figurent la configuration d'IIS pour rejeter les URL contenant « ../ » pour éviter la pénétration des répertoires ; le verrouillage des commandes systèmes et des utilitaires avec des listes de contrôles d'accès restrictives (ACL) ; et l'installation des nouveaux correctifs et mises à jour.

Élévation des privilèges

On parle d'attaque par élévation des privilèges lorsqu'un attaquant exécute le code en utilisant un compte de processus privilégié.

Vulnérabilités

Les vulnérabilités courantes qui rendent votre serveur Web susceptible d'être victime d'attaques par élévation des privilèges sont les suivantes :

• Comptes de processus sur-privilégiés

• Comptes de services sur-privilégiés

Contre-mesures

Les contre-mesures consistent à exécuter les processus au moyen du compte le moins privilégié possible et d'utiliser des comptes utilisateurs et des services les moins privilégiés possible.

Virus, vers et chevaux de Troie

Le code nuisible peut revêtir diverses formes, parmi lesquelles :

• Les virus. Il s'agit de programmes conçus pour exécuter des actions nuisibles et provoquer l'interruption du système d'exploitation ou des applications.

• Les vers. Ce sont des programmes qui s'auto-répliquent et s'auto-entretiennent.

• Les chevaux de Troie. Il s'agit de programmes qui semblent utiles mais qui causent des dommages.

Dans la plupart des cas, le code nuisible passe inaperçu jusqu'à ce qu'il consomme les ressources du système et ralentisse ou interrompe l'exécution des autres programmes. Ainsi, le ver Code Red est l'un des codes nuisibles les plus connus pour IIS et repose sur la vulnérabilité de dépassement de capacité de la mémoire tampon dans un filtre ISAPI.

Vulnérabilités

Parmi les vulnérabilités qui vous fragilisent face aux virus, vers et chevaux de Troie, on compte les éléments suivants :

• Serveurs non mis à jour

• Exécution de services inutiles

• Filtres ISAPI et extensions inutiles

Contre-mesures

Les contre-mesures comprennent l'application des derniers correctifs logiciels, la désactivation des fonctionnalités non utilisées telles que les filtres ISAPI et extensions inutiles, ou encore, l'exécution des processus à l'aide de comptes peu privilégiés pour réduire l'étendue des dommages en cas d'infection.

Haut de page

Méthodologie de sécurisation de votre serveur Web

Pour sécuriser un serveur Web, vous devez appliquer plusieurs paramètres de configuration afin de réduire sa vulnérabilité aux attaques. Savez-vous où commencer et où vous arrêter ? La meilleure approche consiste à organiser en catégories les types de précaution à prendre et les paramètres à configurer. L'utilisation de catégories vous permet d'envisager le processus de sécurisation systématiquement et de A à Z ou de choisir une catégorie spécifique et d'exécuter les étapes qui s'y rapportent.

Catégories de configuration

La méthodologie de sécurisation de ce module a été organisée en catégories, illustrée en figure 16.2.

Figure 16.2
Catégories de configuration du serveur Web

La logique qui sous-tend ces catégories se présente comme suit :

• Correctifs et mises à jour
  De nombreuses menaces de sécurité sont à mettre sur le compte de vulnérabilités largement publiées et bien connues. Dans la plupart des cas, lorsqu'une nouvelle vulnérabilité est découverte, le code à exploiter est publié sur des forums Internet dans les heures qui suivent la première attaque réussie. Si vous n'appliquez pas les correctifs ni les mises à jour à votre serveur, vous fournissez aux attaquants des possibilités d'agir. L'application des correctifs logiciels et des mises à jour à votre logiciel serveur est la première étape critique sur la voie de la sécurisation de votre serveur Web.

• Services
  Les services sont au premier rang des points vulnérables pour les attaquants qui peuvent exploiter les privilèges et capacités d'un service pour accéder au serveur Web local et potentiellement aux autres serveurs en aval. Si un service n'est pas utile au fonctionnement de votre serveur Web, ne l'exécutez pas sur votre serveur. En revanche, si le service est nécessaire, sécurisez-le et maintenez-le. Pensez à contrôler tous les services pour vous assurer de leur disponibilité. Si votre logiciel de service n'est pas sécurisé mais que vous avez besoin du service, essayez de trouver une autre solution sécurisée.

• Protocoles
  Évitez d'utiliser des protocoles non sécurisés par nature. Si vous ne pouvez pas éviter d'utiliser ces protocoles, prenez les mesures appropriées pour fournir une authentification et des communications sécurisées à l'aide des stratégies IPSec, par exemple. Parmi les protocoles en clair, non sécurisés, on trouve : Telnet, POP3 (Post Office Protocol), SMTP (Simple Mail Transfer Protocol) et FTP (File Transfer Protocol).

• Comptes
  Les comptes garantissent l'accès authentifié à votre ordinateur et ils doivent être audités. Quel est l'objectif du compte utilisateur ? Quel accès a-t-il ? Un compte commun peut-il être la cible d'une attaque ? Est-ce le compte de service qui peut être corrompu et qui doit donc être limité ? Configurez les comptes avec le moins de privilèges possible pour éviter l'élévation de privilèges. Supprimez tous les comptes inutiles. Ralentissez les attaques par force brute et par dictionnaire en mettant en place des stratégies imposant des mots de passe sûrs, puis en effectuant des audits et en plaçant des alertes liées aux échecs de connexion.

• Fichiers et répertoires
  Sécurisez les fichiers et les répertoires à l'aide d'autorisations NTFS restreintes pour n'autoriser l'accès qu'aux services Windows et aux comptes utilisateurs nécessaires. L'utilisation de l'audit Windows vous permet de détecter le déroulement d'une activité non autorisée.

• Partages
  Supprimez tous les partages de fichiers inutiles, y compris les partages administratifs par défaut s'ils ne sont pas nécessaires. Sécurisez tous les partages restants à l'aide d'autorisations NTFS réduites. Bien que les partages ne soient pas exposés directement sur Internet, une stratégie recherchée de défense (utilisant un nombre limité de partages sécurisés) permet de réduire les risques en cas de fragilisation du serveur.

• Ports
  Les services qui s'exécutent sur le serveur écoutent sur des ports spécifiques pour pouvoir répondre aux requêtes entrantes. Analysez régulièrement les ports de votre serveur pour veiller à ce qu'aucun service non sécurisé ou inutile ne soit actif sur votre serveur Web. Si vous détectez un port actif qui n'a pas été ouvert par un administrateur, c'est un signe indiscutable d'un accès non autorisé et d'une faille de sécurité.

• Registre
  La plupart des paramètres liés à la sécurité sont stockés dans le registre et par conséquent, vous devez sécuriser le registre. Pour ce faire, vous pouvez appliquer des listes de contrôle d'accès Windows restrictives et bloquer l'administration du registre à distance.

• Audit et journalisation
  L'audit est l'un de vos outils les plus importants pour identifier les intrus, les attaques en cours et trouver des preuves d'attaques qui ont eu lieu. Utilisez une combinaison de fonctions Windows et IIS pour configurer l'audit sur votre serveur Web. Les journaux d'événements et système vous aideront également à résoudre les problèmes de sécurité.

• Sites et répertoires virtuels
  Les sites et répertoires virtuels sont directement exposés à Internet. Même si la configuration sécurisée d'un pare-feu et les filtres défensifs ISAPI, tels que URLScan (livré avec l'outil de IIS Lockdown), permettent de bloquer les requêtes vers les fichiers de configuration limités ou les exécutables de programme, il est recommandé de mettre en œuvre une stratégie défensive approfondie. Déplacez les sites et les répertoires virtuels vers des partitions non système et utilisez les autorisations Web IIS pour limiter encore plus leur accès.

• Mappages de scripts
  Supprimez tous les mappages de script IIS inutiles associés à des extensions de fichiers facultatives afin d'éviter qu'un attaquant puisse exploiter les bogues des extensions ISAPI gérant ce type de fichiers. Les mappages d'extensions non utilisées sont souvent sous-estimés bien qu'ils représentent une vulnérabilité importante en matière de sécurité.

• Filtres ISAPI
  Des attaquants ont réussi à exploiter les vulnérabilités des filtres ISAPI. Supprimez les filtres ISAPI inutiles de votre serveur Web.

• Métabase IIS
  La métabase IIS conserve les paramètres de configuration IIS. Vous devez vous assurer que les paramètres liés à la sécurité sont correctement configurés et que l'accès au fichier de la métabase est limité grâce à des autorisations NTFS renforcées.

• Machine.config
  Le fichier Machine.config stocke les paramètres de configuration machine qui concernent les applications .NET Framework, y compris les applications Web ASP.NET. Modifiez les paramètres de Machine.config pour vous assurer que les paramètres par défaut sécurisés sont mis en œuvre pour toute application ASP.NET installée sur le serveur.

• Sécurité de l'accès au code
  Limitez les paramètres de la stratégie de sécurité d'accès au code pour vous assurer que le code téléchargé d'Internet ou d'un Intranet n'a aucune autorisation et ne sera donc pas autorisé à s'exécuter.

Haut de page

Remarques sur l'installation d'IIS et de .NET Framework

Avant de pouvoir sécuriser votre serveur Web, vous devez connaître les composants présents sur une machine Windows 2000 Server une fois que IIS et .NET Framework ont été installés. Cette section explique quels composants sont installés.

Quels éléments IIS installe-t-il ?

IIS installe un certain nombre de services, de comptes, de dossiers et de sites Web. Certains composants qu'IIS installe ne sont pas nécessairement utilisés par vos applications Web et leur seule présence sur le serveur peut rendre ce dernier plus vulnérable aux attaques. Le tableau 16.1 répertorie les services, les comptes et les dossiers créés par une installation complète d'IIS sur Windows 2000 Server, lorsque tous les composants sont sélectionnés.

Tableau 16.1 Installation IIS par défaut

Quels sont les éléments qu'installe .NET Framework ?

Lorsque vous installez .NET Framework sur un serveur hébergeant IIS, .NET Framework enregistre ASP.NET. Au cours de ce processus, un compte local, le moins privilégié possible et appelé ASPNET est créé. Il exécute le processus de travail ASP.NET (aspnet_wp.exe) et le service d'état de session (aspnet_state.exe) qui peut être utilisé pour gérer l'état d'une session utilisateur.

Remarque : sur les serveurs sous Windows 2000 et IIS 5.0, toutes les applications Web ASP.NET s'exécutent dans une seule instance du processus de travail ASP.NET et les domaines d'application assurent l'isolation. Sur Windows Server 2003, IIS 6.0 fournit une isolation au niveau du processus via l'utilisation de pools d'application.

Le tableau 16.2 montre les services, les comptes et les dossiers créés par l'installation par défaut de la version 1.1 de .NET Framework.

Tableau 16.2 Installation par défaut de .NET Framework

Haut de page

Recommandations d'installation

Par défaut, le programme d'installation de Windows 2000 Server installe IIS. Cependant, nous vous conseillons de ne pas installer IIS comme élément de l'installation du système d'exploitation mais de l'installer ultérieurement, une fois que vous aurez mis à jour votre système d'exploitation de base et appliqué les correctifs logiciels appropriés. Après avoir installé IIS, vous devez ré-appliquer les correctifs logiciels IIS et renforcer la configuration IIS pour vous assurer qu'il est bien sécurisé. C'est à ce stade seulement que vous pouvez connecter le serveur au réseau, en toute sécurité.

Recommandations sur l'installation d'IIS

Si vous installez et configurez un nouveau serveur Web, conformez-vous à la procédure présentée ici.

• Pour créer un nouveau serveur Web

  1. Installez Windows 2000 Server, mais n'installez pas IIS comme élément de l'installation du système d'exploitation.

  2. Appliquez les derniers correctifs et Service Packs au système d'exploitation. Si vous configurez plusieurs serveurs, reportez-vous à la rubrique « Ajout des Services Packs à l'installation de base », plus loin dans cette section.

  3. Installez IIS séparément via la commande Ajout/Suppression de programmes du panneau de configuration.

     Si vous n'avez pas besoin des services suivants, ne les installez pas lorsque vous installez IIS :

     • Serveur FTP (File Transfer Protocol)

     • Extensions Serveur Microsoft FrontPage® 2000

     • Gestionnaire de service Internet (HTML)

     • Service NNTP

     • Service SMTP

     • Prise en charge du déploiement à distance Visual Interdev RAD

     Remarque : en installant IIS sur un système d'exploitation entièrement à jour (correctifs et mises à jour), vous pouvez éviter les attaques et bénéficier des vulnérabilités connues (telles que NIMDA) qui n'ont pas encore été résolues dans un correctif.

Recommandations d'installation de .NET Framework

N'installez pas le kit de développement logiciel (SDK) .NET Framework sur un serveur de production. Ce kit contient des utilitaires dont le serveur n'a pas besoin. Si un attaquant parvient à accéder à votre serveur, il pourra utiliser certain de ces outils pour procéder à d'autres attaques.

Installez plutôt le package redistribuable que vous pouvez obtenir à partir du lien « Téléchargements » du site .NET Framework sur Microsoft.com à l'adresse http://www.microsoft.com/france/net.

Ajout des Service Packs à l'installation de base

Si vous devez créer plusieurs serveurs, vous pouvez intégrer les Service Packs à vos installations Windows. Les Service Packs comprennent un programme appelé Update.exe qui permet d'associer un Service Pack à vos fichiers d'installation Windows.

• Pour associer un Service Pack à une installation Windows

  1. Téléchargez le Service Pack le plus récent.

  2. Extrayez Update.exe du Service Pack en exécutant le programme d'installation du Service Pack avec l'option -x comme suit :

     w3ksp3.exe -x

  3. Intégrez le Service Pack à votre source d'installation Windows en exécutant update.exe avec l'option -s, suivi du chemin d'accès au dossier de votre installation Windows, comme suit :

     update.exe -s c:\VotreSourceInstallationWindows

Pour plus d'informations, reportez-vous à l'article MSDN « Customizing Unattended Win2K Installations », sur http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnw2kmag01/html/custominstall.asp.

Haut de page

Étapes de sécurisation de votre serveur Web

Les sections qui suivent vous guident tout au long du processus de sécurisation de votre serveur Web. Ces sections reposent sur les catégories de configuration présentées dans la section « Méthodologie de sécurisation de votre serveur Web » de ce module. Chaque étape de haut niveau peut contenir une ou plusieurs actions pour sécuriser une zone ou une fonction particulière.

Haut de page

Étape 1. Correctifs et mises à jour

Mettez à jour votre serveur à l'aide des Service Packs et correctifs les plus récents. Vous devez procéder à la mise à jour de l'ensemble des composants du serveur Web, y compris Windows 2000 (et IIS), .NET Framework et les composants Microsoft Data Access (MDAC).

Au cours de cette étape vous devez :

• Détecter et installer les correctifs et mises à jour requis.

• Mettre à jour .NET Framework.

Détection et installation des correctifs et mises à jour

Utilisez l'analyseur MBSA (Microsoft Baseline Security Analyzer) pour détecter les correctifs et mises à jour absentes de l'installation courante. MBSA compare votre installation à une liste de mises à jour disponibles, maintenue dans un fichier XML. Il peut télécharger le fichier XML lorsqu'il analyse votre serveur, mais vous pouvez également le télécharger manuellement sur le serveur ou le mettre à disposition sur un serveur réseau.

• Pour détecter et installer les correctifs et mises à jour

  1. Téléchargez et installez MBSA.

     Pour ce faire, rendez-vous sur la page d'accueil de MBSA http://www.microsoft.com/technet/security/tools/mbsahome.mspx.

     Si vous n'avez pas d'accès Internet lorsque vous exécutez MBSA, celui-ci ne peut pas récupérer le fichier XML contenant les derniers paramètres de sécurité sur le site Microsoft. Vous pouvez dans ce cas utiliser un autre ordinateur pour télécharger le fichier. Il vous suffira ensuite de le copier dans le répertoire du programme MBSA. Le fichier XML est disponible à l'adresse : http://download.microsoft.com/download/xml/security/1.0/nt5/en-us/mssecure.cab.

  2. Exécutez MBSA en cliquant deux fois sur l'icône sur le bureau ou en le sélectionnant à partir du menu Programmes.

  3. Cliquez sur Scan a computer. MBSA analyse par défaut l'ordinateur local.

  4. Désélectionnez toutes les cases à l'exception de la case Check for security updates. Cette option permet de détecter les correctifs et mises à jour manquants.

  5. Cliquez sur Start scan. Votre serveur est en cours d'analyse. Lorsque l'analyse est terminée, MBSA affiche un rapport de sécurité, également inscrit dans le répertoire %userprofile%\SecurityScans.

  6. Téléchargez et installez les mises à jour manquantes.
     Cliquez sur le lien Result details en regard de chaque échec de vérification pour afficher la liste des mises à jour de sécurité manquantes. Une boîte de dialogue affiche alors le numéro de référence du bulletin de sécurité Microsoft. Cliquez sur la référence pour en savoir plus sur le bulletin et télécharger la mise à jour.

     Pour plus d'informations sur l'utilisation de MBSA, consultez la rubrique « Procédure : utilisation de Microsoft Baseline Security Analyzer » de la section « Procédures » de ce guide.

Mise à jour de .NET Framework

À l'heure où nous écrivons cet article (mai 2003), MBSA ne peut pas détecter les mises à jour et correctifs .NET Framework. Vous devez donc détecter manuellement les mises à jour .NET Framework.

• Pour mettre à jour manuellement .NET Framework version 1.0.

  1. Déterminez quel Service Pack .NET Framework est installé sur votre serveur Web.
     Pour ce faire, reportez-vous à l'article 318785 de la base de connaissances Microsoft, intitulé « COMMENT FAIRE : Procédures pour déterminer si des Service Packs sont installés sur .NET Framework ».

  2. Comparez la version de .NET Framework installée avec le Service Pack courant.
     Pour ce faire, consultez les versions de .NET Framework répertoriées dans l'article 318836, « INFO : Comment obtenir le dernier Service Pack pour .NET Framework ».

Haut de page

Étape 2. IISLockdown

L'utilitaire IISLockdown vous permet d'automatiser certaines étapes de sécurité. Cet outil réduit considérablement la vulnérabilité des serveurs Web Windows 2000. Il vous permet de choisir un type spécifique de rôle de serveur, puis d'utiliser des modèles personnalisés pour améliorer la sécurité de ce serveur en particulier. Les modèles activent ou sécurisent différentes fonctions. En outre, IISLockdown installe le filtre ISAPI URLScan. Ce filtre permet aux administrateurs de site Web de restreindre le type de requêtes HTTP que peut traiter le serveur, sur la base d'un jeu de règles que contrôle l'administrateur. En bloquant certaines requêtes HTTP spécifiques, le filtre URLScan empêche les requêtes potentiellement nuisibles d'accéder au serveur et de l'endommager.

Au cours de cette étape vous devez :

• Installer et exécuter IISLockdown.

• Installer et configurer URLScan.

Installation et exécution de IISLockdown

Vous pouvez télécharger IISLockdown à partir du site Web de Microsoft à l'adresse : http://download.microsoft.com/download/iis50/Utility/2.1/NT45XP/EN-US/iislockd.exe.

Enregistrez IISlockd.exe dans un dossier local. IISlockd.exe est l'Assistant IISLockdown et non pas le programme d'installation. Vous pouvez annuler les modifications apportées par IISLockdown en exécutant IISlockd.exe une seconde fois.

Si vous verrouillez un ordinateur sous Windows 2000 hébergeant des pages ASP.NET, sélectionnez le modèle de serveur Web dynamique lorsque IISLockdown vous y invite. Lorsque vous sélectionnez le serveur Web dynamique, IISLockdown effectue les opérations suivantes :

• Il désactive les services Internet non sécurisés suivants :

  • FTP (File Transfer Protocol)

  • Service de messagerie (SMTP)

  • Service News (NNTP)

• Il désactive le mappage de script en mappant les extensions de fichier ci-dessous vers le fichier 404.dll :

  • Index Server

  • Interface Web (.idq, .htw, .ida)

  • Fichiers Include côté serveur (.shtml, .shtm, .stm)

  • Internet Data Connector (.idc)

  • script .HTR (.htr), impression Internet (.printer)

• Il supprime les répertoires virtuels suivants : IIS Samples, MSADC, IISHelp, Scripts et IISAdmin.

• Il restreint l'accès anonyme aux utilitaires système et limite la capacité d'écriture dans les répertoires de contenu via les autorisations Web.

• Il désactive WebDAV (Web Distributed Authoring and Versioning).

• Il installe le filtre ISAPI URLScan.

Remarque : si vous n'utilisez pas d'ASP classique, n'utilisez pas le modèle de serveur Web statique. Ce modèle supprime des fonctionnalités de base nécessaires aux pages ASP.NET, telles que la prise en charge de la commande POST.

Fichiers journaux

IISLockdown crée deux rapports qui répertorient les modifications effectuées :

• %windir%\system32\inetsrv\oblt-rep.log. Ce journal contient des informations de haut niveau.

• %windir%\system32\inetsrv\oblt-log.log. Ce journal contient des détails de bas niveau, tels que le nom des fichiers programmes configurés avec une entrée de contrôle d'accès (ACE) pour interdire aux comptes utilisateur Internet anonymes d'y accéder. Ce fichier journal est également utilisé pour prendre en charge la fonction d'annulation des modifications de IISLockdown.

Groupe Utilisateurs Web anonymes et groupe d'applications Web

IISLockdown crée le groupe Web Anonymous Users et le groupe Web Application. Le groupe Web Anonymous Users contient le compte IUSR_MACHINE. Le groupe Web Application comprend le compte IWAM_MACHINE. Les autorisations sont accordées aux outils système et aux répertoires de contenu sur la base de ces groupes et non pas directement aux comptes IURS et IWAM. Vous pouvez consulter les autorisations spécifiques dans le fichier journal de IISLockdown, %windir%\system32\inetsrv\oblt-log.log.

La dll 404

IISLockdown installe le fichier 404.dll vers lequel vous pouvez mapper les extensions de fichiers qui ne doivent pas être exécutées par le client. Pour plus d'informations, reportez-vous à la section « Étape 12 : Mappages de script ».

URLScan

Si vous installez un filtre ISAPI URLScan comme élément de IISLockdown, les paramètres URLScan sont intégrés dans le rôle de serveur que vous sélectionnez lorsque vous exécutez IISLockdown. Ainsi, si vous sélectionnez un serveur Web statique, URLScan bloque la commande POST.

Annulation des modifications IISLockdown

Pour annuler les modifications apportées par IISLockdown, exécutez IISLockd.exe une deuxième fois. Cette action ne supprime pas le filtre ISAPI URLScan. Pour plus d'informations, consultez la partie « Suppression d'URLSCan » dans la section " Procédures: Utilisation d'URLScan " de ce guide.

Informations complémentaires

Consultez les articles suivants pour plus d'informations sur l'outil IISLockdown :

• Pour plus d'informations sur l'exécution de IISLockdown, consultez l'article « Procédure : utilisation de IISLockdown.exe » de la section « Procédures » de ce guide.

• Pour plus d'informations sur le dépannage de IISLockdown, consultez l'article 325864, « COMMENT FAIRE : Installer et utiliser l'Assistant IIS Lockdown ». Le problème le plus courant réside dans le fait de recevoir des messages d'erreur inattendus « 404 Fichier non trouvé » après avoir exécuté IISLockdown.

• Pour plus d'informations sur le dépannage de IISLockdown, consultez l'article 310725, « How To: Run the IIS Lockdown Wizard Unattended in IIS ».

Installation et configuration de URLScan

URLScan est installé lorsque vous exécutez IISLockdown, mais vous pouvez le télécharger et l'installer séparément.

• Pour installer URLScan sans exécuter IISLockdown

  1. Téléchargez IISLockd.exe à partir de http://download.microsoft.com/download/iis50/Utility/2.1/NT45XP/EN-US/iislockd.exe

  2. Exécutez la commande suivante pour extraire le programme d'installation URLScan :

     iislockd.exe /q /c

URLScan bloque les requêtes contenant des caractères non fiables (ceux qui ont été utilisés pour exploiter des vulnérabilités, comme ".." qui a servi à des attaques de pénétration de répertoire). URLScan consigne les requêtes qui contiennent ces caractères dans le répertoire %windir%\system32\inetsrv\urlscan.

Vous pouvez configurer URLScan à l'aide des paramètres du fichier .ini %windir%\system32\inetsrv\urlscan\urlscan.ini.

URLScan ne sert pas uniquement à bloquer les requêtes et vous pouvez l'utiliser pour protéger le serveur des attaques par refus de service avant que les requêtes n'atteignent ASP.NET. Pour ce faire, définissez les limites des arguments MaxAllowedContentLength, MaxUrl et MaxQueryString dans le fichier URLScan.ini. Pour plus d'informations, consultez la rubrique « Procédure : utilisation d'URLScan » de la section « Procédures » de ce guide.

Annulation des modifications d'URLScan

Il n'existe pas d'opération automatique pour supprimer URLScan. Si vous avez des problèmes avec cet utilitaire, vous avez le choix entre le supprimer d'IIS ou analyser le problème en consignant les requêtes qui sont rejetées. Pour ce faire, utilisez l'option RejectResponseUrl=/~* dans le fichier .ini d'URLScan.

Pour plus d'informations sur la suppression de filtres ISAPI, reportez-vous à la section « Étape 13 : Filtres ISAPI », plus loin dans ce module.

Informations complémentaires

Consultez les articles suivants pour plus d'informations sur l'outil URLScan :

• Pour plus d'informations sur l'exécution d'URLScan, consultez la rubrique « Procédure : utilisation d'URLScan » de la section « Procédures » de ce guide.

• Pour plus d'informations sur la configuration d'URLScan et les paramètres du fichier URLScan.ini, consultez l'article 326444 de la base de connaissances Microsoft, « How To: Configure the URLScan Tool ».

Haut de page

Étape 3. Services

Les services qui n'authentifient pas les clients, les services utilisant des protocoles non sécurisés ou les services qui s'exécutent avec trop de privilèges présentent tous des risques. Si vous n'en avez pas besoin, ne les exécutez pas. En désactivant les services inutiles vous réduisez aisément et rapidement la surface d'attaque. Vous réduisez également la charge de travail en termes de maintenance (correctifs, comptes de service, etc.).

Si vous exécutez un service, veillez à ce qu'il soit sécurisé et maintenu à jour. Pour ce faire, exécutez le service avec un compte le moins privilégié possible et maintenez le service à jour en appliquant les correctifs appropriés.

Au cours de cette étape vous devez :

• Désactiver les services inutiles.

• Désactiver FTP, SMTP et NNTP sauf indication contraire.

• Désactiver le service d'état ASP.NET sauf indication contraire.

Désactiver les services inutiles.

Les services Windows sont vulnérables aux attaques pouvant exploiter les privilèges et les capacités des services ainsi qu'à celles permettant d'accéder aux ressources du système local et distant. Par mesure de protection, désactivez les services Windows dont votre système et vos applications n'ont pas besoin. Vous pouvez désactiver les services Windows en utilisant le composant logiciel enfichable MMC Services, situé dans le groupe de programmes Outils d'administration.

Remarque : avant de désactiver un service, veillez à d'abord tester son impact dans un environnement d'essai ou de pré-lancement.

Dans la plupart des cas, le serveur Web n'a pas besoin des services Windows par défaut ci-dessous : Services Alertes, Navigateur, Messenger, Accès réseau (requis uniquement pour les contrôleurs de domaine), services TCP/IP simples et Spouleur.

Le service Telnet est installé avec Windows mais n'est pas activé par défaut. Les administrateurs IIS l'activent souvent bien qu'il ne s'agisse pas d'un protocole sécurisé, et qu'il soit susceptible d'être exploité. Les services Terminal Server constituent une option d'administration à distance plus sûre. Pour plus d'informations sur l'administration distante, reportez-vous à la rubrique « Administration distante », plus loin dans ce module.

Désactivation de FTP, SMTP et NNTP sauf indication contraire

FTP, SMTP et NNTP sont des exemples de protocoles non sécurisés susceptibles d'être détournés. Si vous n'en avez pas besoin, ne les exécutez pas. Si vous les exécutez actuellement, essayez de trouver une autre solution plus sûre. Si vous n'avez pas d'autre choix que de les exécuter, sécurisez-les.

Remarque : IIS Lockdown fournit des options pour désactiver FTP, SMTP et NNTP.

Pour éliminer la possibilité d'exploiter FTP, désactivez le service FTP si vous ne l'utilisez pas. Si FTP est activé et disponible pour les connexions sortantes, un attaquant peut utiliser ce service pour télécharger des fichiers et des outils vers un serveur Web à partir de son propre système distant. Une fois ces outils et fichiers sur votre serveur Web, l'attaquant peut attaquer le serveur Web ou d'autres systèmes connectés.

Si vous utilisez le protocole FTP, ni le nom d'utilisateur et le mot de passe que vous utilisez pour accéder au site FTP ni les données que vous transférez ne sont codés ou cryptés. IIS ne prend pas en charge SSL pour FTP. S'il est important que vos communications soient sécurisées et que vous utilisez FTP comme protocole de transfert (au lieu de WebDav (World Wide Web Distributed Authoring and Versioning) sur SSL), envisagez de le mettre en œuvre sur un canal crypté, par exemple un réseau privé virtuel (VPN) sécurisé par le protocole PPTP (Point-to-Point Tunneling Protocol) ou IPSec (Internet Protocole Security).

Désactivation du service d'état ASP.NET sauf indication contraire

.NET Framework installe le service d'état ASP.NET (aspnet_state.exe) pour gérer l'état d'une session utilisateur hors processus pour les applications Web ASP.NET et les services Web. Par défaut, ce service est configuré sur le démarrage manuel et s'exécute comme le compte ASPNET local le moins privilégié. Si aucune de vos applications ne stocke l'état à l'aide de ce service, désactivez-le. Pour plus d'informations sur la sécurisation de l'état de session ASPNET, reportez-vous à la section « Etat de session » dans le module 19, « Sécurisation de votre application ASP.NET et de vos services Web ».

Haut de page

Étape 4. Protocoles

En interdisant l'utilisation des protocoles inutiles, vous réduisez les risques d'attaques. .NET Framework permet un contrôle minutieux des protocoles par l'intermédiaire des paramètres du fichier Machine.config. Vous pouvez contrôler, par exemple, l'utilisation de HTTP, GET, POST ou SOAP par vos services Web. Pour plus d'informations sur la configuration des protocoles dans Machine.config, reportez-vous à la section « Étape 16 : Machine.config ».

Au cours de cette étape vous devez :

• Désactiver ou sécuriser WebDav.

• Renforcer la pile TCP/IP.

• Désactiver NetBIOS et SMB.

Désactivation ou sécurisation de WebDav

IIS prend en charge le protocole WebDAV qui est une extension standard de HTTP 1.1 pour la publication de contenu collaboratif. Désactivez ce protocole sur les serveurs de production si vous ne l'utilisez pas.

Remarque : IISLockdown offre une option pour supprimer la prise en charge de WebDAV.

Du point de vue de la sécurité, il est préférable d'utiliser WebDAV à la place de FTP, mais vous devez sécuriser WebDAV. Pour plus d'informations, reportez-vous à l'article 323470 de la base de connaissances « How To: Create a Secure WebDAV Publishing Directory ».

Si vous n'avez pas besoin de WebDAV, reportez-vous à l'article 241520 de la base de connaissances Microsoft « Comment faire pour désactiver WebDAV pour les services Internet (IIS 5.0) ».

Renforcement de la pile TCP/IP.

Windows 2000 prend en charge le contrôle détaillé de nombreux paramètres qui configurent son implémentation TCP/IP. Certains de ces paramètres par défaut sont configurés pour assurer la disponibilité du serveur et fournir d'autres fonctions spécifiques.

Pour plus d'informations sur le renforcement de la pile TCP/IP, consultez la rubrique « Procédure : renforcement de la pile TCP/IP » de la section « Procédures » de ce guide.

Désactivation de NetBIOS et de SMB

Désactivez tous les protocoles inutiles, y compris NetBIOS et SMB. Les serveurs Web n'ont pas besoin de NetBIOS ou de SMB sur leurs cartes d'interface réseau (NIC) exposées à Internet. Désactivez ces protocoles pour déjouer la menace d'énumération d'hôtes.

Remarque : le protocole SMB peut renvoyer à des utilisateurs non authentifiés une mine d'informations concernant un ordinateur, sur une session NULL. Vous pouvez bloquer les sessions NULL en définissant la clé de registre RestrictAnonymous comme décrit dans la section « Étape 9 : Registre ».

Désactivation de NetBIOS

NetBIOS utilise les ports suivants :

• Port TCP et UDP (User Datagram Protocol) 137 (service de noms NetBIOS)

• Port TCP et UDP 138 (service de datagrammes NetBIOS)

• Port TCP et UDP 139 (service de sessions NetBIOS)

La désactivation de NetBIOS ne suffit pas à empêcher les communications SMB car SMB utilise le port TCP 445 si le port standard NetBIOS n'est pas disponible. Ce port est appelé SMB Direct Port. Vous devez donc prendre les mesures requises pour désactiver séparément NetBIOS et SMB.

• Pour désactiver NetBIOS sur TCP/IP

Remarque : cette procédure désactive le pilote Nbt.sys et implique le redémarrage du système.

1. Sur le Bureau, cliquez avec le bouton droit sur Poste de travail et choisissez Gérer.

2. Développez Outils système, puis sélectionnez Gestionnaire de périphériques.

3. Cliquez avec le bouton droit sur le Gestionnaire de périphériques, choisissez Affichage puis Afficher les périphériques cachés.

4. Développez l'entrée Pilotes non Plug-and-Play.

5. Cliquez sur l'entrée NetBIOS sur TCP/IP avec le bouton droit de la souris, puis cliquez sur Désactiver.

   Cette procédure désactive l'écoute directe d'hôte NetBIOS sur TCP 445 et UDP 445.

Désactivation de SMB

SMB utilise les ports suivants :

• Port TCP 139

• Port TCP 445

Pour désactiver SMB, utilisez la boîte de dialogue des propriétés TCP/IP, dans vos propriétés Connexion au réseau local pour dissocier SMB du port exposé à Internet.

• Pour dissocier SMB du port exposé à Internet

  1. Cliquez sur le menu Démarrer, choisissez Paramètres, puis cliquez sur Connexion réseau et accès à distance.

  2. Cliquez avec le bouton droit de la souris sur votre connexion Internet, puis cliquez sur Propriétés.

  3. Désactivez la case Client pour les réseaux Microsoft.

  4. Désactivez la case Partage de fichiers et d'imprimantes pour les réseaux Microsoft.

Remarque : l'onglet WINS de la boîte de dialogue Paramètres TCP/IP avancés propose une option intitulée Désactiver NetBIOS avec TCP/IP. Si vous sélectionnez cette option, vous désactivez le service de session NetBIOS qui utilise le port TCP 139. Cette option ne désactive pas entièrement le protocole SMB. Pour ce faire, suivez la procédure décrite ci-dessus.

Haut de page

Étape 5. Comptes

Vous devez supprimer les comptes qui ne sont pas utilisés car un attaquant peut les découvrir et s'en servir. Imposez l'utilisation de mots de passe fiables. Les mots de passe simples accroissent les risques de réussite d'une attaque par force brute ou dictionnaire. Utilisez le moins de privilège possible. Un attaquant peut utiliser des comptes dotés de trop de privilèges et obtenir l'accès à des ressources non autorisées.

Au cours de cette étape vous devez :

• Supprimer ou désactiver les comptes inutilisés.

• Désactiver le compte Invité.

• Renommer le compte Administrateur.

• Désactiver le compte IUSR.

• Créer un compte Web anonyme.

• Imposer des stratégies de mot de passe fiable.

• Restreindre les connexions à distance.

• Désactiver les sessions NULL (sessions anonymes).

Suppression ou désactivation des comptes inutilisés

Un attaquant peut se servir de comptes inutilisés et de leurs privilèges pour obtenir l'accès à un serveur. Passez en revue les comptes locaux sur le serveur et désactivez ceux qui ne sont pas utilisés. Si la désactivation d'un compte ne pose pas de problème, supprimez-le. (Les comptes supprimés ne peuvent pas être récupérés.) Désactivez les comptes sur un serveur de test avant de les désactiver sur le serveur de production. Vérifiez que la désactivation d'un compte n'a pas d'impact négatif sur le fonctionnement de votre application.

Remarque : les comptes Administrateur et Invité ne peuvent pas être supprimés.

Désactivation du compte Invité

Le compte Invité est utilisé pour effectuer une connexion anonyme sur l'ordinateur. Pour empêcher les connexions anonymes à votre ordinateur, maintenez ce compte désactivé. Le compte invité est désactivé par défaut sur Windows 2000. Pour vérifier s'il est activé, affichez le dossier Utilisateurs de l'outil Gestion de l'ordinateur. Le compte Invité doit apparaître avec une icône barrée. S'il n'est pas désactivé, affichez sa boîte de dialogue de Propriétés et cochez la case Le compte est désactivé.

Changement du nom du compte Administrateur

Le compte Administrateur local par défaut est une cible pour les utilisateurs malintentionnés en raison du haut niveau de ses privilèges. Pour améliorer la sécurité, renommez-le et affectez-lui un mot de passe sûr.

Si vous avez l'intention d'effectuer l'administration en local, configurez le compte pour refuser les droits de connexion via le réseau et exiger que l'administrateur se connecte de manière interactive. Vous empêchez ainsi les utilisateurs (bien intentionnés ou non) d'utiliser le compte Administrateur pour se connecter au serveur à partir d'un ordinateur à distance. Si la stratégie consistant à effectuer l'administration en local est trop rigide, mettez en place une solution d'administration distante sécurisée. Pour plus d'informations, reportez-vous à la rubrique « Administration à distance », plus loin dans ce module.

Désactivation du compte IUSR

Désactivez le compte utilisateur Internet anonyme par défaut, IUSR_MACHINE. Ce compte est créé pendant l'installation d'IIS. MACHINE est le nom NetBIOS que prend votre serveur au moment de l'installation d'IIS.

Création d'un compte Web anonyme personnalisé

Si vos applications prennent en charge l'accès anonyme (parce qu'elles utilisent par exemple un mécanisme d'authentification personnalisé tel que l'authentification par formulaire), créez un compte anonyme le moins privilégié possible. Si vous exécutez IISLockdown, ajoutez votre utilisateur personnalisé au groupe Web Anonymous Users créé. IIS Lockdown refuse l'accès aux utilitaires systèmes et empêche le groupe Web Anonymous User d'écrire dans les répertoires de contenu Web.

Si votre serveur Web héberge plusieurs applications Web, vous souhaiterez peut-être utiliser plusieurs comptes Web anonymes (un par application) de manière à pouvoir sécuriser et auditer les opérations de chaque application indépendamment les unes des autres.

Pour plus d'informations sur l'hébergement de plusieurs applications Web, reportez-vous au module 20, « Hébergement de plusieurs applications Web ».

Application des stratégies de mot de passe fiable

Pour contrer les attaques de dictionnaire et de piratage de mots de passe contre votre application, mettez en place des stratégies de mots de passe fiable. Pour mettre en œuvre une stratégie de mot de passe fiable :

• Définissez la longueur du mot de passe et sa complexité. Exigez l'utilisation des mots de passe fiables pour réduire le risque d'attaques par découverte du mot de passe ou les attaques de dictionnaire. Les mots de passe fiables sont constitués de huit caractères ou plus et doivent comprendre des caractères alphabétiques et numériques.

• Définissez un délai d'expiration du mot de passe. Le changement régulier des mots de passe réduit la probabilité qu'un mot de passe soit utilisé pour un accès non autorisé. Le délai d'expiration est généralement fixé en fonction de la stratégie de sécurité de la société.

Le tableau 16.4 illustre les paramètres par défaut et recommandés pour la stratégie de mot de passe.

Tableau 16.4 Paramètres par défaut et recommandés de la stratégie de mot de passe

En outre, enregistrez les tentatives de connexion infructueuses de manière à détecter et à surveiller les comportements malveillants. Pour plus d'informations, reportez-vous à la rubrique « Étape 10 : Audit et journalisation ».

Limitation des connexions à distance.

Supprimez le privilège Accéder à cet ordinateur depuis le réseau du groupe Tout le monde pour limiter les connexions au serveur à distance.

Désactivation des sessions NULL (ouvertures de sessions anonymes)

Pour empêcher les accès anonymes, désactivez les sessions NULL. Il s'agit de toutes les sessions non authentifiées ou anonymes établies entre deux ordinateurs. Si les sessions NULL ne sont pas désactivées, un attaquant peut se connecter anonymement à votre serveur, c'est-à-dire sans être authentifié.

Une fois que l'attaquant a établi une session NULL, il peut effectuer toutes sortes d'attaques, et notamment employer des techniques d'énumération pour collecter les informations liées au système sur l'ordinateur cible, lesquelles l'aideront à réaliser de nouvelles attaques. Les sessions NULL permettent de récupérer des informations telles que les détails de domaine et de sécurisation, de partages, les données utilisateur (y compris les groupes et droits d'utilisateur), les clés du Registre, etc.

Limitez les sessions NULL en définissant RestrictAnonymous sur 1 dans le registre, au niveau de la sous-clé suivante :

HKLM\System\CurrentControlSet\Control\LSA\RestrictAnonymous=1

Pour plus d'informations, consultez l'article 246261 de la base de connaissances Microsoft, « Utilisation de la valeur de Registre RestrictAnonymous dans Windows 2000 ».

Remarques supplémentaires

Vous trouverez ci-dessous une liste d'étapes complémentaires que vous pouvez envisager de réaliser pour améliorer la sécurité sur votre serveur Web :

• Exigez que la délégation d'un compte passe par une approbation.
  Ne marquez pas les domaines comme étant approuvés pour la délégation dans Active Directory à moins que vous n'obteniez au préalable une approbation spéciale.

• N'utilisez pas de comptes partagés.
  Ne créez pas de compte partagé pour plusieurs personnes. Chaque personne autorisée doit disposer de son propre compte. Les activités de chacun pourront ainsi être surveillées séparément et l'appartenance aux groupes ainsi que l'accord de privilèges pourront être définis de manière appropriée.

• Limitez le nombre de membres du groupe local Administrateurs.
  Essayez de limiter à deux le nombre de comptes d'administration. La gestion en est ainsi facilitée. En outre, les mots de passe ne doivent pas être partagés par souci de facilité de gestion.

• Exigez que l'administrateur se connecte de manière interactive.
  Si vous ne réalisez l'administration qu'en local, vous pouvez exiger que votre compte administrateur se connecte de manière interactive en supprimant le privilège Accéder à cet ordinateur depuis le réseau.

Haut de page

Étape 6. Fichiers et répertoires

Installez Windows 2000 sur des partitions formatées avec le système de fichiers NTFS de manière à bénéficier des autorisations NTFS pour limiter l'accès. Utilisez des contrôles d'accès puissants pour protéger les fichiers et répertoires sensibles. Dans la plupart des cas, l'approche consistant à autoriser l'accès à des comptes spécifiques est plus efficace qu'une approche consistant à refuser l'accès à des comptes spécifiques. Dans la mesure du possible, définissez l'accès au niveau du répertoire. Tous les fichiers ajoutés au dossier héritent des autorisations accordées à ce dossier de sorte que vous n'avez pas besoin de vous en occuper.

Au cours de cette étape vous devez :

• Limiter le groupe Tout le monde.

• Limiter le(s) compte(s) Web anonyme(s).

• Sécuriser ou supprimer les outils, utilitaires et kits de développement (SDK).

• Supprimer les fichiers d'exemple.

Limitation du groupe Tout le monde

Les autorisations NTFS par défaut pour Windows 2000 accordent aux membres du groupe Tout le monde un accès total à un certain nombre d'emplacements clés tels que le répertoire racine, \inetpub et \inetpub\scripts.

Accordez tout d'abord au compte administrateur le CONTRÔLE TOTAL de la racine (\), puis supprimez les droits d'accès du groupe Tout le monde aux répertoires suivants :

• Racine (\)

• Répertoire système (\WINNT\system32)

• Répertoire des outils Framework (\WINNT\Microsoft.NET\Framework\{version})

• Répertoire racine du site Web et tous les répertoires de contenu (le répertoire par défaut est \inetpub\*)

Restriction de l'accès accordé au compte anonyme IIS

Le compte anonyme est bien connu et les attaquants le prennent pour cible pour leurs actions malveillantes. Pour sécuriser le compte anonyme :

• Refusez l'accès en écriture aux répertoires de contenu Web.
  Veillez à ce que ce compte ne puisse pas écrire dans les répertoires de contenu, pour rendre les sites Web illisibles.

• Restreignez l'accès aux partages requis.
  Restreignez en particulier l'accès aux outils de ligne de commande situés dans \WINNT\System32.

• Accordez des autorisations aux groupes et non à des comptes individuels.
  Il est préférable d'affecter des utilisateurs à des groupes et d'accorder les autorisations aux groupes plutôt que d'accorder ces autorisations à des comptes particuliers. Pour le compte anonyme, créez un groupe et ajoutez-y le compte, puis supprimez explicitement l'accès du groupe aux répertoires et fichiers clés. L'attribution d'autorisations à un groupe vous permet de modifier plus facilement le compte anonyme ou de créer d'autres comptes anonymes car il est alors inutile de recréer des autorisations.

  Remarque : IIS Lockdown refuse que le compte anonyme accède en écriture aux répertoires de contenu en appliquant une entrée de contrôle d'accès (ACE) aux groupes Anonymous Users et Web Applications. Il ajoute également une liste de contrôle d'accès pour interdire l'exécution des outils de ligne de commande.

• Utilisez des comptes distincts pour chaque application.
  Si votre serveur Web héberge plusieurs applications, utilisez un compte anonyme distinct pour chaque application. Ajoutez les comptes à un groupe d'utilisateurs Web anonymes, comme le groupe Web Anonymous Users créé par IIS Lockdown, puis configurez les autorisations NTFS à l'aide de ce groupe.

  Pour plus d'informations sur l'utilisation de plusieurs comptes anonymes et l'hébergement de plusieurs applications, reportez-vous au module 20, « Hébergement de plusieurs applications ASP.NET ».

Sécurisation ou suppression des outils, utilitaires et kits de développement (SDK)

Les kits de développement (SDK) et les kits de ressources ne doivent pas être installés sur un serveur Web de production. Supprimez-les le cas échéant.

• Vérifiez que seul le package redistribuable .NET Framework est installé sur le serveur et qu'aucun utilitaire SDK n'y figure. N'installez pas Visual Studio .NET sur les serveurs de production.

• Assurez-vous que l'accès aux outils systèmes puissants et aux utilitaires, tels que ceux du répertoire \Program Files, est restreint. IIS Lockdown se charge de cette vérification.

• Les outils de débogage ne doivent pas être à disposition sur le serveur Web. Si le débogage de production est nécessaire, vous devez créer un CD contenant les outils de débogage nécessaires.

Suppression des fichiers d'exemple

Les applications exemples ne sont généralement pas configurées avec un haut niveau de sécurité. Il est donc possible pour un attaquant d'exploiter une faiblesse inhérente à une application exemple ou à sa configuration pour attaquer un site Web. Supprimez les applications exemples pour réduire les zones sur lesquelles votre serveur Web peut être attaqué.

Remarques supplémentaires

Pensez également à supprimer les Noms de source de données (DSN). Ces noms contiennent en clair les détails de connexion utilisés par les applications pour se connecter aux sources de données OLE DB. Seuls les DSN requis par les applications Web doivent être installés sur le serveur Web.

Haut de page

Étape 7. Partages

Supprimez tous les partages non utilisés et renforcez les autorisations NTFS sur tous les partages essentiels. Par défaut, tous les utilisateurs ont un contrôle total sur les nouveaux partages de fichier lors de leur création. Renforcez ces autorisations par défaut de manière à vous assurer que seuls les utilisateurs autorisés peuvent accéder aux fichiers exposés par le partage. En plus des autorisations explicites de partage, utilisez les listes de contrôle d'accès NTFS sur les fichiers et dossiers exposés par le partage.

Au cours de cette étape vous devez :

• Supprimer les partages inutiles.

• Restreindre l'accès aux partages requis.

Suppression des partages inutiles

Supprimez les partages inutiles. Pour passer en revue les partages et autorisations associées, exécutez le composant logiciel enfichable MMC Gestion de l'ordinateur et sélectionnez Partages dans Dossiers partagés, comme l'illustre la figure 16.3.

Figure 16.3
Partages du composant logiciel enfichable MMC Gestion de l'ordinateur

Limitation de l'accès aux partages requis

Supprimez le groupe Tout le monde et accordez à la place des autorisations spécifiques. Tout le monde est utilisé lorsque vous n'imposez pas de restriction sur l'accès au partage.

Remarques supplémentaires

Si vous n'autorisez pas l'administration distante de votre serveur, supprimez les partages administratifs inutilisés, tels que C$ et Admin$.

Remarque : certaines applications peuvent nécessiter des partages administratifs. C'est le cas par exemple de Microsoft Systems Management Server (SMS) et de Microsoft Operations Manager (MOM). Pour plus d'informations, consultez l'article 318751 de la base de connaissances Microsoft, « How To: Remove Administrative Shares in Windows 2000 or Windows NT 4.0 ».

Haut de page

Étape 8. Ports

Les services qui s'exécutent sur le serveur écoutent sur des ports spécifiques pour pouvoir répondre aux requêtes entrantes. Fermez tous les ports inutiles et effectuez des audits réguliers afin de détecter les nouveaux ports en état d'écoute, ce qui pourrait être la preuve d'un accès non autorisé et d'une sécurité compromise.

Au cours de cette étape vous devez :

• Limiter les ports exposés à Internet aux seuls ports TCP 80 et 443.

• Crypter ou restreindre le trafic intranet.

Limitation des ports exposés à Internet aux seuls ports TCP 80 et 443

Limitez le trafic entrant du port 80 pour HTTP et du port 443 pour HTTPS (SSL).

Pour les cartes d'interface réseau sortantes (exposées à Internet), utilisez le filtrage TCP ou IPSec. Pour plus d'informations, consultez la rubrique « Procédure : utilisation d'IPSec » de la section « Procédures » de ce guide.

Cryptage ou restriction du trafic Intranet

Pour les cartes d'interface réseau internes (Intranet), si vous ne disposez pas de centre de données sécurisé et que des informations sensibles transitent entre les ordinateurs, vous devez envisager de crypter le trafic ou de restreindre les communications entre le serveur Web et les serveurs en aval (tels que le serveur d'application ou le serveur de base de données). Le cryptage du trafic réseau élimine le risque d'écoute clandestine du réseau. Si ce risque est très faible, vous pouvez choisir de ne pas crypter le trafic.

Le type de cryptage utilisé affecte également le type de menaces qu'il permet de contrer. Ainsi, SSL est un cryptage au niveau applicatif alors qu'IPSec est un cryptage de la couche de transport. SSL répond donc à la menace de récupération des données ou de divulgation des informations par un autre processus sur une même machine et plus particulièrement sur une machine exécutant un autre compte. SLL contre en outre la menace d'écoute clandestine du réseau.

Haut de page

Étape 9. Registre

Le registre est le référentiel de nombreux paramètres vitaux de configuration du serveur. En tant que tel, vous devez vous assurer que seuls les administrateurs autorisés y ont accès. Si un attaquant parvient à modifier le registre, il peut reconfigurer le serveur et en compromettre la sécurité.

Au cours de cette étape vous devez :

• Limiter l'administration à distance du registre.

• Sécuriser le SAM (serveurs autonomes uniquement).

Limitation de l'administration à distance du registre

La clé Winreg détermine si les clés du registre sont accessibles à distance. Par défaut, cette clé est configurée de manière à empêcher les utilisateurs d'afficher à distance la plupart des clés du registre et seuls les utilisateurs dotés de privilèges élevés peuvent la modifier. Sur Windows 2000, l'accès distant au registre est limité par défaut aux membres des groupes Administrateurs et Opérateurs de sauvegarde. Les administrateurs ont un contrôle total sur le registre et les opérateurs de sauvegarde ont un accès en lecture seule.

Les autorisations associées à l'emplacement de registre ci-dessous déterminent quels utilisateurs peuvent accéder à distance au registre.

HKLM\SYSTEM\CurrentControlSet\Control\SecurePipeServers\winreg

Pour afficher les autorisations de cette clé de registre, exécutez Regedt32.exe, accédez à la clé et choisissez Autorisations dans le menu Sécurité.

Remarque : certains services nécessitent un accès distant au registre. Reportez-vous à l'article 153183 de la base de connaissances Microsoft, « Procédures pour limiter l'accès au registre à partir d'un ordinateur distant », pour savoir si votre situation exige un accès distant au registre.

Sécurisation de SAM (serveurs autonomes uniquement).

Les serveurs autonomes stockent les noms de compte et les hachages unidirectionnels (non réversibles) de mots de passe (LMHash) dans la base de données du Gestionnaire de comptes de sécurité (SAM). Ce Gestionnaire de comptes de sécurité fait partie du registre. Généralement, seuls les membres du groupe Administrateurs ont accès aux informations des comptes.

Bien que les mots de passe ne soient pas réellement stockés dans le SAM et que les hachages de mots de passe ne soient pas réversibles, si un attaquant obtient une copie de la base de données SAM, il peut utiliser les techniques de piratage des mots de passe par force brute pour obtenir des noms d'utilisateur et des mots de passe valides.

Limitez le stockage LMHash dans la SAM en créant la clé (non la valeur) NoLMHash dans le registre, comme suit :

HKLM\System\CurrentControlSet\Control\LSA\NoLMHash

Pour plus d'informations, consultez l'article 299656 de la base de connaissances Microsoft, « How to Prevent Windows from Storing a LAN Manager Hash of Your Password in Active Directory and Local SAM Databases ».

Haut de page

Étape 10. Audit et consignation

L'audit n'empêche pas les attaques de système mais il offre une aide essentielle pour identifier les intrus, les attaques en cours et pour diagnostiquer les empreintes d'attaque. Activez un niveau d'audit minimal sur votre serveur Web et utilisez les autorisations NTFS pour protéger les fichiers journaux de telle sorte qu'un attaquant ne puisse pas masquer ses traces en supprimant les fichiers journaux ou en les mettant à jour d'une manière ou d'une autre. Utilisez l'audit du format de fichier journal étendu IIS W3C.

Au cours de cette étape vous devez :

• Consigner toutes les tentatives infructueuses de connexion.

• Consigner toutes les actions qui ont échoué dans le système de fichiers.

• Déplacer et sécuriser les fichiers journaux IIS.

• Archiver les fichiers journaux pour les analyser hors ligne.

• Analyser les accès au fichier MetaBase.bin.

Consignation de toutes les tentatives infructueuses de connexion

Vous devez consigner toutes les tentatives infructueuses de connexion pour pouvoir détecter et suivre tout comportement suspect.

• Pour analyser les tentatives infructueuses de connexion

  1. Démarrez l'outil de Stratégie de sécurité locale à partir du groupe de programmes Outils d'administration.

  2. Développez Stratégies locales, puis sélectionnez Stratégie d'audit.

  3. Double-cliquez sur Auditer les événements de connexion aux comptes.

  4. Cliquez sur Échec, puis sur OK.

Les échecs de connexion sont enregistrés comme événements dans le journal des événements de sécurité Windows. Les numéros d'événements suivants sont suspects :

• 531. Ce code signifie qu'une tentative de connexion a eu lieu à l'aide d'un compte désactivé.

• 529. Ce code signifie qu'une tentative de connexion a eu lieu via un compte utilisateur inconnu ou un compte utilisateur connu mais avec un mot de passe incorrect. L'augmentation inattendue du nombre d'événements de ce type peut traduire une tentative de recherche de mots de passe.

Consignation de toutes les actions qui ont échoué dans le système de fichiers.

Utilisez l'audit NTFS sur le système de fichiers pour détecter les tentatives potentiellement malveillantes. Il s'agit d'un processus en deux étapes.

• Pour activer la consignation

  1. Démarrez l'outil de Stratégie de sécurité locale à partir du groupe de programmes Outils d'administration.

  2. Développez Stratégies locales, puis sélectionnez Stratégie d'audit.

  3. Double-cliquez sur Auditer l'accès aux objets.

  4. Cliquez sur Échec, puis sur OK.

• Pour consigner toutes les actions qui ont échoué dans le système de fichiers

  1. Démarrez l'Explorateur Windows et placez-vous à la racine du système de fichiers.

  2. Cliquez avec le bouton droit et choisissez Propriétés.

  3. Cliquez sur l'onglet Sécurité.

  4. Cliquez sur l'onglet Paramètres avancés, puis sur l'onglet Audit.

  5. Cliquez sur Ajouter et entrez Tout le monde dans le champ Nom.

  6. Cliquez sur OK, puis cochez toutes les cases Échec pour auditer tous les événements ayant échoué.

     Par défaut, cette opération s'applique au dossier courant ainsi qu'à tous les sous-dossiers et fichiers.

  7. Cliquez sur OK trois fois pour refermer toutes les boîtes de dialogue ouvertes.
     Les événements ayant échoué sont consignés dans le journal des événements de sécurité Windows.

Déplacement et sécurisation des fichiers journaux IIS

En déplaçant et en renommant les fichiers journaux IIS, vous compliquez la tâche de l'attaquant qui cherche à effacer ses traces. En effet, l'attaquant doit localiser les fichiers journaux avant de pouvoir les modifier. Pour lui compliquer encore plus la tâche, utilisez les autorisations NTFS pour sécuriser les fichiers journaux.

Renommez le répertoire du fichier journal IIS et déplacez-le sur un volume autre que celui de votre site Web. N'utilisez pas le volume système. Appliquez ensuite les autorisations NTFS suivantes aux dossiers et sous-dossiers des fichiers journaux.

• Administrateurs : Contrôle total

• Système : Contrôle total

• Opérateurs de sauvegarde : Lire

Archivage des fichiers journaux pour l'analyse hors ligne

Pour faciliter l'analyse hors ligne des fichiers journaux IIS, vous pouvez utiliser un script qui automatise la suppression sécurisée des fichiers journaux d'un serveur IIS. Les fichiers journaux doivent être supprimés toutes les 24 heures au minimum. Un script automatisé peut utiliser FTP, SMTP, HTTP ou SMB pour transférer les fichiers journaux vers un ordinateur serveur. Toutefois, si vous activez l'un de ces protocoles, faites-le de manière sécurisée afin de ne pas ouvrir la porte à de nouvelles opportunités d'attaque. Utilisez une stratégie IPSec pour sécuriser les ports et les canaux.

Audit des accès au fichier MetaBase.bin

Analysez tous les échecs du groupe Tout le monde sur le fichier IIS Metabase.bin situé dans \WINNT\System32\inetsrv\. Procédez de même pour le dossier de sauvegarde \Metabase afin d'analyser les copies de sauvegarde de la métabase.

Remarques supplémentaires

Vous pouvez de surcroît configurer l'audit du format de fichier journal étendu IIS W3C. Sélectionnez Format de fichier journal étendu du W3C dans l'onglet Site Web de la boîte de dialogue des propriétés du site Web. Vous pouvez ensuite choisir des Propriétés étendues telles que Ressource URI et Requête URI.

Haut de page

Étape 11. Sites et répertoires virtuels

Il est recommandé de repositionner les répertoires racines Web et les répertoires virtuels sur une partition non système pour les protéger contre des attaques de pénétration de répertoire. Ces attaques permettent à l'attaquant d'exécuter des programmes et des utilitaires du système d'exploitation. Il n'est toutefois pas possible de passer ainsi d'une unité à une autre. Cette approche garantit par exemple l'échec de tout ver de canonisation permettant à un attaquant d'accéder aux fichiers système. Ainsi, si un attaquant formule une URL comportant le chemin suivant, la requête échoue :

/scripts/..%5c../winnt/system32/cmd.exe

Au cours de cette étape vous devez :

• Déplacer votre site Web sur un volume non système.

• Désactiver les paramètres des chemins d'accès parents.

• Supprimer tous les répertoires virtuels potentiellement dangereux.

• Supprimer ou sécuriser RDS.

• Définir les autorisations Web.

• Supprimer ou sécuriser les extensions FrontPage Server.

Déplacement de votre site Web sur un volume non système

N'utilisez pas le répertoire par défaut \inetpub\wwwroot. Si, par exemple, votre système est installé sur le disque C:, choisissez de déplacer votre site et le répertoire de contenu vers le disque D:. Vous réduisez ainsi les risques associés aux problèmes de canonisation imprévus et aux attaques de pénétration de répertoire.

Désactivation des paramètres des chemins d'accès parents

Ce paramètre IIS de la métabase empêche d'utiliser ".." dans les appels de script et de fonctions d'application, telles que MapPath. Vous vous protégez ainsi des attaques de pénétration de répertoire.

• Pour désactiver les chemins d'accès parents

  1. Démarrez IIS.

  2. Cliquez avec le bouton droit sur la racine du site Web et choisissez Propriétés.

  3. Cliquez sur l'onglet Répertoire de base.

  4. Cliquez sur Configuration.

  5. Cliquez dans l'onglet Options de l'application.

  6. Désélectionnez l'option Activer les chemins d'accès relatifs au répertoire parent.

Remarque : si vous utilisez le site d'administration de l'Application Center 2002, consultez l'article 288309 de la base de connaissances Microsoft, « PRB: Disabling Parent Paths Breaks User Interface ».

Suppression des répertoires virtuels potentiellement dangereux

Les applications exemples ne sont pas installées par défaut et ne doivent pas être installées sur des serveurs Web de production. Supprimez toutes les applications exemples, y compris celles dont l'accès ne s'effectue qu'à partir de l'ordinateur local avec http://localhost ou http://127.0.0.1.

Supprimez les répertoires virtuels suivants des serveurs de production : IISSamples, IISAdmin, IISHelp et Scripts.

Remarque : IIS Lockdown offre une option de suppression des répertoires virtuels Scripts, IISSamples, IISAdmin et IISHelp.

Suppression ou sécurisation de RDS

Remote Data Services (RDS) est un composant permettant d'accéder de manière contrôlée par Internet aux ressources de données distantes via IIS. L'interface RDS est fournie par Msadcs.dll qui est située dans le répertoire program files\common files\system\Msadc.

Suppression de RDS

Si vos applications n'utilisent pas RDS, supprimez-le.

• Pour supprimer la prise en charge de RDS

  1. Supprimez de Microsoft IIS le mappage vers le répertoire virtuel /MSADC.

  2. Supprimez les fichiers et sous-répertoires RDS de l'emplacement suivant :
     \Program Files\Common Files\System\Msadc

  3. Supprimez la clé de registre suivante :
     HKLM\System\CurrentControlSet\Services\W3SVC\Parameters\ADCLaunch

Remarque : IISLockdown offre une option pour supprimer le répertoire virtuel MSADC. Notez qu'IIS Lockdown supprime uniquement le répertoire virtuel et non les fichiers et la clé de registre.

Sécurisation de RDS

Si vos applications requièrent RDS, sécurisez ce composant.

• Pour sécuriser RDS

  1. Supprimez les exemples des emplacements suivants :
     \Progam Files\Common Files\System\Msadc\Samples

  2. Supprimez la clé de registre suivante :
     HKLM\System\CurrentControlSet\Services\W3SVC\Parameters\ADCLaunch\VbBusObj.VbBusObjCls

  3. Désactivez l'accès anonyme au répertoire virtuel MSADC dans IIS.

  4. Créez une clé de registre HandlerRequired à l'emplacement suivant :
     HKLM\Software\Microsoft\DataFactory\HandlerInfo\

  5. Créez une nouvelle valeur DWORD et définissez-la sur 1 (1 indique le mode sécurisé, 0 le mode non sécurisé).

Remarque : vous pouvez utiliser le fichier de script du registre Handsafe.reg pour modifier la clé de registre. Le fichier de script se trouve dans le répertoire msadc :

\Program Files\Common Files\System\msadc

Pour plus d'informations sur la sécurisation de RDS, visitez les pages suivantes :

• MS99-025 Microsoft Security Program: Unauthorized Access to IIS Servers through ODBC Data Access with RDS à l'adresse http://www.microsoft.com/technet/security/bulletin/ms99-025.mspx.

• MS98-004 Microsoft Security Program: Microsoft Security Bulletin: Unauthorized ODBC Data Access with RDS and IIS à l'adresse http://www.microsoft.com/technet/security/bulletin/MS98-004.mspx.

• Article 184375 de la Base de connaissances Microsoft, « PRB: Security Implications of RDS 1.5, IIS 3.0 or 4.0, and ODBC ».

Définition des autorisations Web

Les autorisations Web sont configurées via le composant logiciel enfichable IIS et conservées dans la métabase IIS. Il ne s'agit pas des autorisations NTFS.

Utilisez les autorisations Web suivantes :

• Autorisations de lecture. Limitez les autorisations de lecture des répertoires Include.

• Autorisations Écrire et Exécuter. Limitez les autorisations Écrire et Exécuter des répertoires virtuels qui autorisent l'accès anonyme.

• Accès à la source du script. Configurez les autorisations Accès à la source du script uniquement sur les dossiers autorisant la création de contenu.

• Écriture. Configurez les autorisations en écriture uniquement sur les dossiers autorisant la création de contenu. Accordez l'accès en écriture aux auteurs de contenu uniquement.

  Remarque : les dossiers qui prennent en charge la création de contenu doivent être configurés pour exiger l'authentification et SSL pour le cryptage.

Suppression ou sécurisation des extensions FrontPage Server

Si vous n'utilisez pas les extensions FrontPage Server (FPSE), désactivez-les. Dans le cas contraire, procédez comme suit pour améliorer la sécurité :

• Mettez à jour les extensions du serveur. Consultez les problèmes de sécurité traités dans l'article MSDN, « Microsoft FrontPage Server Extensions 2002 for Windows », à l'adresse http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnservext/html/fpse02win.asp

• Limitez l'accès à l'aide de la sécurité FrontPage. FPSE installe des groupes disposant d'autorisations sur les sites Web pour lesquels les extensions du serveur sont configurées. Ces groupes sont utilisés pour restreindre l'accès existant, en fonction du rôle de l'utilisateur. Pour plus d'informations, consultez le centre d'Assistance à l'adresse http://office.microsoft.com/assistance/2002/articles/fp_colmanagesecurity.aspx.

Haut de page

Étape 12. Mappages de script

Les mappages de script permettent d'associer une extension de fichier donnée, telle que .asp, vers l'extension ISAPI qui la gère, telle que Asp.dll. IIS est configuré pour prendre en charge un ensemble d'extensions parmi lesquelles .asp, .shtm, .hdc, etc. Les gestionnaires HTTP ASP.NET sont plus ou moins équivalents aux extensions ISAPI. Dans IIS, les extensions de fichier, telles que .aspx, sont tout d'abord mappées vers Aspnet_isapi.dll qui transfère ensuite la requête au processus de travail ASP.NET. Le véritable gestionnaire HTTP qui traite l'extension de fichier est ensuite déterminé par le mappage de <HttpHandler> dans Machine.config ou Web.config.

Les principaux problèmes de sécurité associés aux mappages de script sont les suivants :

• Un attaquant peut exploiter une vulnérabilité trouvée dans une extension.
  Ceci peut en effet se produire si la vulnérabilité de l'extension n'est pas corrigée. Les extensions non utilisées augmentent la surface d'attaque potentielle. Si, par exemple, vous n'utilisez pas une extension particulière, il est probable que vous ne prêterez pas attention aux mises à jour correspondantes.

• Les ressources côté serveur peuvent être téléchargées par le client.
  Ce genre d'incident se produit si une extension de fichier n'est pas mappée correctement. Les fichiers auxquels le client ne doit pas pouvoir accéder directement doivent être soit mappés vers le gestionnaire approprié en fonction de l'extension, soit supprimés.

Au cours de cette étape vous devez :

• Mapper les extensions de fichier IIS.

• Mapper les extensions de fichier .NET Framework.

Mappage des extensions de fichier IIS

Sur Windows 2000, les extensions de fichier IIS présentant de l'intérêt sont les suivantes : .asp, .asa, .cer, .cdx, .htr, .idc, .shtm, .shtml, .stm et .printer.

Si vous n'utilisez pas l'une de ces extensions, mappez-la vers 404.dll, qui est fournie par IISLockdown. Si, par exemple, vous ne souhaitez pas fournir des pages ASP aux clients, mappez .asp vers 404.dll.

Les mappages modifiés par IISLockdown dépendent du modèle de serveur que vous avez choisi :

• Serveur Web statique. Si vous exécutez IISLockdown et que vous choisissez l'option Serveur Web statique, toutes les extensions indiquées ci-dessus seront mappées vers 404.dll.

• Serveur Web dynamique. Si vous choisissez l'option Serveur Web dynamique, qui est l'option recommandée avec les pages ASP.NET, les extensions .htr, .idc, .shtm, .shtml, .stm et .printer sont mappées vers 404.dll mais .asp, .cer, .cdx et .asa ne le sont pas. Dans ce cas, vous devez mapper manuellement .cer, .cdx et .asa vers le fichier 404.dll. Si vous n'utilisez pas .asp, vous pouvez également mapper cette extension.

Pourquoi les extensions doivent-elles être mappées vers 404.dll ?

En mappant les extensions de fichier vers 404.dll, vous empêchez que les fichiers ne soient retournés ou téléchargés sur HTTP. Si l'utilisateur demande un fichier avec une extension mappée vers 404.dll, une page Web contenant le message « HTTP 404 - Fichier non trouvé » s'affiche. Nous vous conseillons de mapper les extensions non utilisées vers 404.dll plutôt que de supprimer le mappage. Si vous supprimez un mappage et qu'un fichier est laissé par inadvertance sur le serveur (ou placé là par erreur), il peut être affiché en clair lorsque l'utilisateur le demande car IIS ne sait pas comment le traiter.

• Pour mapper une extension de fichier vers 404.dll

  1. Démarrez IIS.

  2. Cliquez avec le bouton droit de la souris sur le nom de votre serveur dans la fenêtre de gauche et choisissez Propriétés.

  3. Vérifiez que WWWService est bien sélectionné dans la liste déroulante Propriétés principales, puis cliquez sur le bouton adjacent Modifier.

  4. Cliquez sur l'onglet Répertoire de base.

  5. Cliquez sur Configuration. La page à onglet, présentée en figure 16.4, s'affiche.

     

     Figure 16.4
     Mappage des extensions d'application

  6. Sélectionnez l'une des extensions dans la liste, puis cliquez sur Edition.

  7. Cliquez sur Parcourir pour atteindre \WINNT\system32\inetsrv\404.dll.

     Remarque : pour exécuter cette étape, vous devez au préalable avoir lancé IISlockd.exe, puisque le fichier 404.dll est installé par l'outil IISLockdown.

  8. Cliquez sur Ouvrir, puis sur OK.

  9. Répétez les étapes 6, 7 et 8 pour toutes les autres extensions de fichier.

Mappage des extensions de fichier .NET Framework

Les extensions de fichier .NET Framework qui suivent sont mappées vers aspnet_isapi.dll : .asax, .ascx, .ashx, .asmx, .aspx, .axd, .vsdisco, .jsl, .java, .vjsproj, .rem, .soap, .config, .cs, .csproj, .vb, .vbproj, .webinfo, .licx, .resx et .resources.

.NET Framework protège les extensions de fichiers qui ne doivent pas être appelés directement par les clients en les associant à System.Web.HttpForbiddenHandler dans Machine.config. Les extensions de fichier qui suivent sont mappées vers System.Web.HttpForbiddenHandler par défaut : .asax, .ascx, .config, .cs, .csproj, .vb, .vbproj, .webinfo, .asp, .licx, .resx et .resources.

Pour plus d'informations sur les gestionnaires HTTP, reportez-vous à la section « Étape 16 : Machine.config ».

Remarques supplémentaires

Comme IIS traite avant tout une requête Web, vous pouvez mapper directement vers 404.dll les extensions de fichier .NET Framework que les clients ne doivent pas appeler. Ce mappage a deux effets :

• Le fichier 404.dll traite et rejette les requêtes avant qu'elles ne soient transférées à ASP.NET et traitées par le processus de travail ASP.NET. Ceci supprime un traitement inutile par le processus ASP.NET. En outre, le blocage des requêtes au plus tôt est une bonne pratique de sécurité.

• Le fichier 404.dll renvoie le message « HTTP 404 - Fichier non trouvé » et System.Web.HttpForbiddenHandler retourne le message « Ce type de page n'est pas pris en charge ». On peut dire ici que le message « Fichier non trouvé » donne moins d'informations et qu'il peut donc être considéré comme plus sécuritaire.

Haut de page

Étape 13. Filtres ISAPI

Par le passé, les vulnérabilités des filtres ISAPI entraînaient une exploitation considérable d'IIS. Aujourd'hui il n'existe pas de filtre ISAPI inutile après une installation IIS propre, bien que .NET Framework installe le filtre ISAPI ASP.NET (Aspnet_filter.dll), qui est chargé dans l'espace d'adressage du processus IIS (Inetinfo.exe) et est utilisé pour prendre en charge la gestion de l'état des sessions sans cookies

Si vos applications ne prennent pas en charge l'état de sessions sans cookies et que vous ne définissez pas l'attribut cookieless sur true dans l'élément <sessionState>, ce filtre peut être supprimé.

Au cours de cette étape, vous allez supprimer les filtres ISAPI non utilisés.

Suppression des filtres ISAPI non utilisés

Supprimez tous les filtres inutilisés, comme expliqué dans la section qui suit.

• Pour afficher les filtres ISAPI

  1. Pour démarrer IIS, sélectionnez Gestionnaire des services Internet dans le groupe de programmes Outils d'administration.

  2. Cliquez avec le bouton droit sur la machine (et non sur le site Web car les filtres s'appliquent à la machine), puis choisissez Propriétés.

  3. Cliquez sur Modifier.

  4. Cliquez sur l'onglet Filtres ISAPI. La page à onglet, présentée en figure 16.5, s'affiche :

     

  Figure 16.5
  Suppression des filtres ISAPI inutilisés

Haut de page

Étape 14. Métabase IIS

Les paramètres de sécurité et de configuration IIS sont conservés dans le fichier de la métabase IIS. Renforcez les autorisations NTFS sur la métabase IIS (et sur le fichier de la métabase de sauvegarde) pour être sûr que les attaquants ne peuvent pas modifier votre configuration IIS de quelque manière que ce soit (pour désactiver l'authentification d'un répertoire virtuel donné, par exemple).

Au cours de cette étape vous devez :

• Restreindre l'accès à la métabase à l'aide des autorisations NTFS.

• Limiter les informations de bannière renvoyées par IIS.

Limitation de l'accès à la métabase à l'aide des autorisations NTFS

Définissez les autorisations NTFS qui suivent dans le fichier de la métabase IIS (Metabase.bin) dans le répertoire \WINNT\system32\inetsrv.

• Système local : Contrôle total

• Administrateurs : Contrôle total

Limitation des informations de bannière renvoyées par IIS

Les informations figurant dans les bannières peuvent indiquer les versions des logiciels et fournir d'autres informations qui peuvent être utiles à un attaquant. Ces informations peuvent révéler les logiciels que vous exécutez et permettre à un attaquant d'exploiter les vulnérabilités connues de ces logiciels.

Lorsque vous extrayez une page statique, telle qu'un fichier .htm ou .gif, le système ajoute à la réponse un en-tête d'emplacement du contenu. Par défaut, cet en-tête de contenu indique à l'adresse IP et non au nom de domaine complet, ce qui signifie que votre adresse IP interne est exposée contre votre gré. L'en-tête de réponse HTTP ci-dessous montre, par exemple l'adresse IP en caractère gras :

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Content-Location: http://10.1.1.1/Default.htm
Date: Thu, 18 Feb 1999 14:03:52 GMT
Content-Type: text/html
Accept-Ranges: bytes
Last-Modified: Wed, 06 Jan 1999 18:56:06 GMT
ETag: "067d136a639be1:15b6"
Content-Length: 4325

Vous pouvez masquer l'emplacement du contenu que renvoient les en-têtes de réponse HTTP en modifiant une valeur dans la métabase IIS pour remplacer le comportement par défaut d'envoi des adresses IP par l'envoi du nom de domaine complet.

Pour plus d'informations sur le masquage de l'emplacement de contenu dans les réponses HTTP, reportez-vous à l'article 218180 de la base de connaissances Microsoft, « Internet Information Server renvoie l'adresse IP dans l'entête HTTP (Emplacement de contenu) ».

Haut de page

Étape 15. Certificats de serveur

Si votre application Web prend en charge HTTPS (SSL) sur le port 443, vous devez installer un certificat de serveur. Ce certificat est nécessaire dans le cadre du processus de négociation de session qui a lieu lorsqu'un client établit une session HTTPS sécurisée.

Un certificat valide fournit une authentification sécurisée de telle sorte que le client peut faire confiance au serveur avec lequel il communique et sécuriser la communication afin que les données sensibles restent confidentielles et infalsifiables sur le réseau.

Au cours de cette étape, vous allez valider votre certificat de serveur.

Validation de votre certificat de serveur

Vérifiez les quatre éléments qui suivent pour contrôler la validité de votre certificat de serveur Web :

• Vérifiez que les dates de début et de fin de validité sont dans la plage.

• Vérifiez que le certificat est correctement employé. S'il a été délivré comme certificat de serveur, il ne doit pas être utilisé pour les messages électroniques.

• Vérifiez que les clés publiques de la chaîne du certificat sont toutes valides et comprennent une racine fiable.

• Vérifiez qu'il n'a pas été révoqué. Il ne doit pas figurer sur la liste de révocation de certificats (CRL) du serveur qui l'a émis.

Haut de page

Étape 16. Machine.config

Cette section traite du renforcement des paramètres de configuration machine qui concernent toutes les applications. Pour en savoir plus sur le renforcement des paramètres spécifiques des applications, reportez-vous au module 19, « Sécurisation de votre application ASP.NET ».

Le fichier Machine.config contient un certain nombre de paramètres machine de l'environnement .NET Framework, la plupart d'entre eux affectant la sécurité. Machine.config est situé dans le répertoire suivant :

%windir%\Microsoft.NET\Framework\{version}\CONFIG

Remarque : vous pouvez utiliser tout éditeur de texte ou XML (Bloc-Notes, par exemple) pour modifier les fichiers de configuration XML. Sachant que la casse est prise en compte dans les balises XML, vous devez veiller à bien respecter la différence majuscules/minuscules.

Au cours de cette étape vous devez :

• Mapper les ressources protégées vers HttpForbiddenHandler.

• Vérifier que le traçage est désactivé.

• Vérifier que les fonctions de compilation de débogage sont désactivées.

• Vérifier que les erreurs ASP.NET ne sont pas renvoyées au client.

• Vérifier les paramètres d'état de la session.

Mappage des ressources protégées vers HttpForbiddenHandler

Les gestionnaires HTTP sont situés dans Machine.config sous l'élément <httpHandlers>. Ils sont responsables du traitement des requêtes Web pour des extensions de fichier données. Remoting ne doit pas être activé sur les serveurs Web frontaux. Activez-le uniquement sur les serveurs d'application de couche intermédiaire, complètement isolés d'Internet.

Les extensions de fichiers ci-dessous sont mappées dans Machine.config vers des gestionnaires HTTP :

• .aspx est utilisée pour les pages ASP.NET.

• .rem et .soap sont utilisées pour la communication à distance.

• .asmx est utilisée pour les services Web.

• .asax, .ascx, .config, .cs, .csproj, .vb, .vbproj, .webinfo, .asp, .licx, .resx et .resources sont des ressources protégées, mappées vers System.Web.HttpForbiddenHandler.

Pour les ressources .NET Framework, si vous n'utilisez pas d'extension de fichiers, mappez l'extension vers System.Web.HttpForbiddenHandler dans Machine.config, comme illustré dans l'exemple qui suit :

<add verb="*" path="*.vbproj" type="System.Web.HttpForbiddenHandler" />

Dans ce cas, l'extension de fichier .vbproj est mappée vers System.Web.HttpForbiddenHandler. Si un client demande un chemin qui se termine par .vbproj, ASP.NET renvoie un message qui stipule que « Ce type de page n'est pas pris en charge ».

Les directives suivantes s'appliquent à la gestion des extensions de fichier .NET Framework.

• Mappez les extensions que vous n'utilisez pas vers HttpForbiddenHandler. Si vous ne prenez pas en charge les pages ASP.NET, mappez .aspx vers HttpForbiddenHandler. Si vous n'utilisez pas les services Web, mappez .asmx vers HttpForbiddenHandler.

• Désactivez la communication à distance sur les serveurs Web exposés à Internet. Mappez les extensions de communication à distance (.soap et .rem) des serveurs exposés à Internet vers HttpForbiddenHandler.

Désactivation de .NET Remoting

Pour désactiver .NET Remoting, désactivez les requêtes des extensions .rem et .soap et utilisez les éléments suivants sous <httpHandlers> :

<add verb="*" path="*.rem" type="System.Web.HttpForbiddenHandler"/>
<add verb="*" path="*.soap" type="System.Web.HttpForbiddenHandler"/>

Remarque : cette désactivation n'empêche pas qu'une application Web sur le serveur Web se connecte à un objet en aval à l'aide de l'infrastructure Remoting. Elle empêche les clients de se connecter aux objets sur le serveur Web.

Vérification de l'état désactivé du traçage

Pour configurer le traçage dans Machine.config, vous devez utiliser l'élément <trace>. Utile sur les serveurs de développement et de test, le traçage ne doit pas être activé sur les serveurs de production car les informations système de traçage peuvent aider un attaquant à établir le profil d'une application et à rechercher ses points faibles.

Utilisez la configuration suivante sur les serveurs de production :

<trace enabled="false" localOnly="true" pageOutput="false" 
	 requestLimit="10" traceMode="SortByTime"/>

Définissez enabled="false" sur les serveurs de production. Si vous n'avez pas besoin de tracer les problèmes des applications actives, simulez le problème sur un environnement de test ou, si nécessaire, activez le traçage et définissez localOnly="true" pour éviter que les détails de traçage soient retournés aux clients à distance.

Vérification de l'état désactivé des compilations de débogage

Vous pouvez contrôler si le compilateur produit des versions debug qui comprennent des symboles de débogage à l'aide de l'élément <compilation>. Pour désactiver les compilations de débogage, définissez debug="false" comme indiqué ci-dessous :

<compilation debug="false" explicit="true" defaultLanguage="vb" />

Vérifier que les erreurs ASP.NET ne sont pas renvoyées aux clients

Vous pouvez utiliser l'élément <customErrors> pour configurer les messages d'erreur génériques et personnalisés qui seront renvoyés aux clients si une condition d'exception d'application se produit.

Vérifiez que le mode est bien défini sur "RemoteOnly" comme l'illustre l'exemple ci-dessous :

<customErrors mode="RemoteOnly" />

Après avoir installé une application ASP.NET, vous pouvez configurer le paramètre pour qu'il pointe sur une page d'erreur personnalisée comme l'illustre l'exemple ci-dessous :

<customErrors mode="On" defaultRedirect="YourErrorPage.htm" />

Vérification des paramètres d'état de la session

Si vous n'utilisez pas l'état de session, vérifiez que le mode d'état de session est désactivé dans Machine.config comme l'illustre l'exemple ci-dessous :

<sessionState mode="Off" . . . />

Vérifiez également que le service d'état ASP.NET est désactivé. Le mode par défaut de l'état de session est "InProc" et le service d'état ASP.NET est défini sur manuel. Pour plus d'informations sur la sécurisation de l'état de session si vous avez installé une application ASP.NET qui le nécessite, reportez-vous à la rubrique « État de session » du module 19, « Sécurisation de votre application ASP.NET et de vos services Web ».

Haut de page

Étape 17. Sécurité d'accès au code

La stratégie de sécurité d'accès au code au niveau de la machine est déterminée par les paramètres du fichier Security.config, situé dans le répertoire
%windir%\Microsoft.NET\Framework\{version}\CONFIG

Exécutez la commande qui suit pour vous assurer que la sécurité d'accès au code est bien activée sur votre serveur :

caspol -s On

Pour plus d'informations sur la configuration de la sécurité d'accès au code dans les applications Web ASP.NET, reportez-vous au module 9, « Utilisation de la sécurité d'accès au code dans ASP.NET ».

Au cours de cette étape, vous devez :

• Supprimer toutes les autorisations de la zone intranet locale.

• Supprimer toutes les autorisations de la zone Internet.

Suppression des autorisations de la zone intranet locale

La zone intranet locale applique des autorisations au code exécuté à partir de partages UNC ou de sites Web internes. Reconfigurez cette zone pour n'accorder aucune autorisation en l'associant au jeu d'autorisations Nothing.

• Pour Supprimer toutes les autorisations de la zone intranet locale

  1. Démarrez l'outil de configuration de Microsoft .NET Framework version 1.1 à partir du groupe de programmes Outils d'administration.

  2. Développez Stratégie de sécurité du runtime, Machine, puis Groupes de codes.

  3. Développez ensuite All_Code et sélectionnez LocalIntranet_Zone.

  4. Cliquez sur Edit Code Group Properties.

  5. Cliquez dans l'onglet Jeu d'autorisations.

  6. Sélectionnez Nothing dans la liste déroulante Autorisation.

  7. Cliquez sur OK.
     La boîte de dialogue, présentée en figure 16.6, s'affiche :

     

Figure 16.6
Configuration des autorisations de code LocalIntranet_Zone sur Nothing

Suppression de toutes les autorisations de la zone Internet

La zone Internet applique au code téléchargé par Internet les autorisations d'accès au code. Sur les serveurs Web, cette zone doit être configurée pour n'accorder aucune autorisation. Pour ce faire, vous devez l'associer au jeu d'autorisations Nothing.

Répétez les étapes présentées dans la section précédente, « Suppression de toutes les autorisations de la zone intranet locale », mais en définissant Internet_Zone sur le jeu d'autorisations Nothing.

Haut de page

Instantané d'un serveur Web sécurisé

Un instantané des attributs d'un serveur Web sécurisé vous permet de comparer rapidement et aisément ses paramètres avec ceux de votre propre serveur Web. Les paramètres présentés dans le tableau 16.5 reposent sur l'analyse de serveurs Web hébergeant des sites Web s'étant révélés particulièrement résistants aux attaques et ayant fait preuve de solides pratiques de sécurité. En suivant les étapes présentées plus haut, vous pouvez créer un serveur dont la configuration en matière de sécurité sera identique.

Tableau 16.5 : Instantané d'un serveur Web sécurisé

<httpHandlers>
<add verb="*" path="*.rem" 
	type="System.Web.HttpForbiddenHandler"/>  
<add verb="*" path="*.soap"       
	 type="System.Web.HttpForbiddenHandler"/>
 </httpHandlers>

<trace  enabled="false">

<compilation debug="false"/>

<customErrors mode="On" /> 

<sessionState  mode="Off" />

Haut de page

Rester protégé

Vous devez surveiller l'état de protection de votre serveur et le mettre à jour régulièrement pour empêcher que ne soient exploitées les toutes dernières vulnérabilités. Pour vous aider à conserver un serveur sécurisé :

• Procédez à l'audit des membres des groupes.

• Surveillez les journaux d'audit.

• Restez à jour en matière de Service Packs et de correctifs.

• Procédez à des évaluations de votre sécurité.

• Utilisez des services de notification de sécurité.

Audit des membres des groupes

Effectuez un suivi des membres de groupes d'utilisateurs, plus particulièrement pour les groupes privilégiés tels que les administrateurs. La commande suivante permet de répertorier les membres du groupe Administrateurs :

net localgroup administrateurs

Surveillance des journaux d'audit

Surveillez les journaux d'audit régulièrement et analysez les fichiers journaux en les consultant ou utilisez la technique décrite dans l'article 296085 de la Base de connaissances, « How To: Use SQL Server to Analyze Web Logs ».

À la pointe des Service Packs et des correctifs

Définissez un planning pour analyser vos logiciels de serveurs et souscrivez à des alertes de sécurité. Utilisez MBSA pour rechercher régulièrement les correctifs manquants sur votre serveur. Les liens suivants donnent accès aux mises à jour les plus récentes :

• Service packs Windows 2000. Les Service Packs les plus récents sont disponibles à l'adresse http://www.microsoft.com/windows2000/downloads/servicepacks/default.asp.

• Service Pack .NET Framework. Pour plus d'informations sur l'obtention des mises à jour .NET Framework les plus récentes, lisez l'article MSDN, « How to Get the Microsoft .NET Framework », à l'adresse http://msdn.microsoft.com/netframework/downloads/howtoget.asp

• Mises à jour critiques. Ces mises à jour permettent de résoudre les problèmes connus et vous aident à protéger votre ordinateur des vulnérabilités de sécurité connues. Les mises à jour critiques les plus récentes sont disponibles à l'adresse http://www.microsoft.com/windows2000/downloads/critical/default.asp.

• Mises à jour de sécurité avancées. Les mises à jour critiques les plus récentes sont disponibles à l'adresse http://www.microsoft.com/windows2000/downloads/critical/default.asp.

  Vous protégez ainsi votre ordinateur des vulnérabilités connues de sécurité.

Évaluation de votre sécurité

Utilisez l'outil MBSA pour rechercher régulièrement les vulnérabilités de sécurité et identifier les correctifs et mises à jour manquants. Planifiez l'exécution quotidienne de MBSA et analysez les résultats pour agir en conséquence. Pour plus d'informations sur l'automatisation de MBSA, consultez la rubrique « Procédure : utilisation de MBSA » de la section « Procédures » de ce guide.

Services de notification de sécurité

Utilisez les services Microsoft répertoriés dans le tableau 16.3 pour obtenir les bulletins de sécurité avec notification des vulnérabilités possible du système.

Tableau 16.3 Services de notification de sécurité

Vous pouvez également vous abonner aux services d'alerte de sécurité de l'industrie présentés dans le tableau 16.4. Ces services vous permettent d'évaluer les risques liés à une vulnérabilité lorsqu'un correctif n'est pas encore disponible.

Tableau 16.4 Services de notification de sécurité industrielle

Haut de page

Administration distante

Il n'est pas rare que les administrateurs aient besoin de pouvoir administrer plusieurs serveurs. Veillez à ce que les exigences de votre solution d'administration distante ne compromettent pas la sécurité. Si vous souhaitez profiter des capacités d'administration à distance, lisez les recommandations qui suivent pour améliorer la sécurité :

• Limitez le nombre de comptes administratifs. Il convient de restreindre le nombre de comptes administratifs et de comptes autorisés à se connecter à distance.

• Limitez les outils. Les principales options comprennent le Gestionnaire des services Internet et les services Terminal Server. L'administration Web est une autre option (via le répertoire virtuel IISAdmin) mais elle n'est pas recommandée. En outre, cette option est supprimée par IISLockdown.exe. Le Gestionnaire des services Internet et les services Terminal Server utilisent tous deux la sécurité Windows. Dans le cas présent, il convient surtout de restreindre le nombre de comptes Windows et les ports que vous utilisez.

• Limitez le nombre d'ordinateurs autorisés à administrer le serveur. Vous pouvez utiliser IPSec pour définir les ordinateurs autorisés à se connecter à votre serveur Web.

Sécurisation des services Terminal Server

Il est possible d'utiliser les services Microsoft Terminal Server pour administrer à distance et de façon sûre votre serveur Web.

Les services Terminal Server reposent sur le protocole propriétaire de Microsoft appelé RDP (Remote Desktop Protocol). RDP utilise le port TCP 3389 et supporte deux utilisateurs simultanés. Les sections qui suivent décrivent l'installation et la configuration des services Terminal Server pour une administration sécurisée :

• Installez les services Terminal Server.

• Configurez les services Terminal Server.

Installation des services Terminal Server

Pour installer les services Terminal Server :

1. Installez les services Terminal Server via la commande Ajout/Suppression de programmes du panneau de configuration. Utilisez l'option Ajout/Suppression de composants Windows. Il n'est pas nécessaire d'installer le service de licence des services Terminal Server pour l'administration distante.

2. Configurez les services Terminal Server pour le mode d'administration distante.

3. Supprimez le compte TsInternetUser créé au cours de l'installation des services Terminal Server. Ce compte est utilisé pour prendre en charge l'accès anonyme par Internet aux services Terminal Server et ne doit pas être activé sur le serveur.

Configuration des services Terminal Server

Utilisez le composant logiciel enfichable de configuration MMC des services Terminal Server, disponible dans le groupe de programme Outils d'administration pour configurer les éléments qui suivent :

1. Il existe trois niveaux (bas, moyen et élevé) de codage des connexions aux services Terminal Server. Définissez le codage sur la clé 128 bits. Notez que le pack Cryptage fort Windows doit être installé à la fois sur le serveur et sur le client.

2. Configurez la session de services Terminal Server pour qu'elle se déconnecte après une certaine durée d'inactivité. Définissez-la pour mettre fin à une session déconnectée. Une session est considérée comme déconnectée au bout de 10 minutes si l'utilisateur ferme l'application cliente des services Terminal Server sans se déconnecter.

3. Enfin, limitez les autorisations d'accès aux services Terminal Server. Utilisez l'onglet RDP permissions de la boîte de dialogue RDP. Par défaut, tous les membres du groupe Administrateurs sont autorisés à accéder aux services Terminal Server. Si vous ne souhaitez pas que tous les membres de ce groupe puissent y accéder, supprimez le groupe et ajoutez les comptes individuels pouvant y accéder. Notez que le compte SYSTEM doit figurer dans la liste.

Utilisez une connexion VPN entre le client et le serveur ou un tunnel IPSec pour plus de sécurité. Cette approche fournit une authentification mutuelle et la charge utile RDP est cryptée.

Copie des fichiers via RDP

Les services Terminal Server n'offrent pas de transfert de fichiers intégré. Vous pouvez toutefois installer l'utilitaire de copie de fichiers à partir du kit de ressources Windows 2000 Server pour ajouter la fonction de transfert de fichiers à la fonction de redirection du Presse-papiers dans Terminal Server. Pour plus d'informations sur l'utilitaire et les instructions d'installation, consultez l'article 244732 de la base de connaissances Microsoft, « COMMENT FAIRE : Installer l'outil de copie de fichiers inclus dans le Kit de ressources Windows 2000 ».

Haut de page

Simplification et automatisation de la sécurité

Ce module vous a montré comment configurer manuellement les paramètres d'un serveur Web ASP.NET. Ce processus manuel vous aide à comprendre la configuration mais peut prendre du temps. Utilisez les ressources suivantes pour automatiser les étapes présentées dans ce module :

• Pour plus d'informations sur l'automatisation de IISLockdown, consultez l'article 310725, « How To: Run the IIS Lockdown Wizard Unattended in IIS ».

• Vous pouvez créer et déployer des stratégies de sécurité à l'aide de modèles de sécurité. Pour plus d'informations, reportez-vous aux articles suivants de la base de connaissances Microsoft :

  • 313434, « How To: Define Security Templates in the Security Templates Snap-in in Windows 2000 »

  • 309689, « COMMENT FAIRE : Appliquer des modèles de sécurité prédéfinis dans Windows 2000 ».

  • 321679, « How To: Manage Security Templates in Windows 2000 Server ».

• La série Microsoft Solution for Securing Windows 2000 Server traite des rôles de serveur les plus courants, ainsi que des contrôleurs de domaine, des serveurs DNS, DHCP, Web IIS et des serveurs de fichiers et d'impression. L'approche de ce guide vous permet de vous baser sur une installation par défaut de Windows 2000 pour créer un serveur Web, dont la configuration variera en fonction de son rôle. Les administrateurs peuvent ensuite modifier la sécurité pour se conformer aux besoins de leur environnement particulier. Le guide fournit une base de recommandations élémentaires en matière de sécurité qui couvrent les services, les comptes, les stratégies de groupes, etc. ; vous pouvez les utiliser comme point de départ pour les rôles de serveurs courants.

Haut de page

Résumé

Un serveur Web sécurisé offre une base protégée pour héberger les applications Web. Ce module vous a montré les principales menaces ayant un impact sur votre serveur Web ASP.NET et vous a indiqué les étapes de sécurité nécessaires pour réduire ces risques. En exécutant la procédure de renforcement présentée dans ce module, vous pouvez créer une plate-forme sécurisée et héberger une infrastructure pour prendre en charge les applications Web ASP.NET et les services Web.

La méthodologie utilisée ici vous permet en outre de créer de A à Z un serveur Web sécurisé ou de renforcer la configuration de sécurité d'un serveur Web existant. L'étape suivante consiste à vous assurer que toutes les applications déployées sont correctement configurées.

Haut de page

Informations complémentaires

Vous trouverez des informations complémentaires en vous reportant aux ressources suivantes :

• Pour plus d'informations sur la sécurisation de la station de travail du développeur, consultez la rubrique « Procédure : sécurisation de la station de travail du développeur » de la section « Procédures » de ce guide.

• Pour plus d'informations sur la sécurisation des applications Web ASP.NET et des services Web, reportez-vous au module 19, « Sécurisation de votre application ASP.NET ».

• Pour plus d'informations sur la configuration de l'application Web Open Hack, reportez-vous à l'article MSDN « Building and Configuring More Secure Web Sites » à l'adresse http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/openhack.asp.

• Pour obtenir des ressources liées à la sécurité sur TechNet, consultez la page Sécurité de TechNet http://www.microsoft.com/france/technet/.

• Retrouvez la liste de contrôle que vous pouvez imprimer « Liste de contrôle : sécurisation de votre serveur Web » dans la section « Listes de contrôle » de ce guide.

Haut de page