Générer un serveur IIS 7.0 personnalisé

  • Article

Auteur : Mike Volodarsky

Introduction

IIS 6.0 et les versions précédentes intègrent la plupart des fonctionnalités de serveur largement utilisées dans le serveur lui-même. En revanche, le moteur de serveur Web IIS 7.0 et les versions supérieures présentent une architecture modulaire sur laquelle pratiquement toutes les fonctions du serveur sont fournies sous forme de composants enfichables. Cela permet d'améliorer considérablement l'ensemble du panneau, notamment :

  • La possibilité de contrôler exactement quel ensemble de fonctionnalités est chargé ou utilisé sur le serveur, en supprimant les fonctionnalités inutiles pour réduire la surface d'exposition et l'empreinte mémoire du serveur
  • La possibilité de remplacer chaque fonctionnalité par des solutions tierces ou personnalisées
  • La possibilité de spécialiser le serveur en fonction de son rôle dans la topologie du serveur
  • Le contrôle avancé de l'ensemble des fonctionnalités du serveur, à la fois au niveau du grain fin et au niveau de l'application.

Ces composants serveur, appelés modules, sont chargés pendant l'initialisation du processus de travail du pool d'applications et fournissent des services de traitement des demandes sur le serveur. Chaque application IIS 7.0 et version ultérieure est une combinaison de services fournis par des modules activés pour l'application, et de contenu associé utilisé par ces services. Le serveur fournit deux rôles majeurs joués par les modules :

  • Fourniture des services de requête, tels que l'authentification ou la mise en cache de la sortie (similaire aux filtres ISAPI dans IIS 6.0)
  • Traitement des requêtes, comme le traitement des fichiers statiques, des CGI ou des pages ASP.NET (similaire aux extensions ISAPI dans IIS 6.0)

En activant différents modules, le serveur peut être configuré pour fournir les services requis par les applications sur le serveur.

Cet article illustre les tâches suivantes :

  • Examen de la configuration du serveur, de la valeur par défaut et de l'ensemble de modules chargés sur le serveur par défaut
  • Suppression de tous les modules pour réduire le serveur à sa configuration minimale, et examen de l'effet sur l'empreinte.
  • Génération d'un serveur personnalisé en ajoutant de façon incrémentielle des modules pour prendre en charge un scénario spécifique

Révision de la configuration du module par défaut

La configuration principale du serveur est contenue dans le fichier applicationHost.config, situé dans le répertoire de configuration IIS %windir%\system32\inetsrv\config\. Nous examinons la configuration suivante contenue dans le groupe de section <system.webServer> :

Section <globalModules> Cette section au niveau du serveur contient la liste des modules chargés par le processus de travail du serveur et les DLL natives associées qui mettent en œuvre leurs fonctionnalités.

Section <modules> Cette section au niveau de l'application contient la liste des modules activés pour une application particulière. Cette section permet de sélectionner le sous-ensemble de modules chargés qui doivent être actifs dans une application et de charger des modules supplémentaires au niveau de l'application.

Section <handlers> Cette section au niveau de l'URL contient les mappages de gestionnaires que le serveur utilise pour mapper les requêtes entrantes à un module particulier qui le traitera. Il s'agit d'un système similaire aux scriptmaps d'IIS 6.0 ou d'ASP.NET, qui permet d'unifier le mappage des requêtes vers les gestionnaires de types de contenu natifs et gérés.

La description complète de tous les modules IIS est disponible dans la vue d'ensemble des modules IIS 7.0 et versions ultérieures.

Créer une sauvegarde de configuration

Tout d'abord, nous sauvegardons la configuration du serveur afin de pouvoir la restaurer si nécessaire. Exécutez la commande suivante à partir d'une invite de commandes exécutée en tant qu'Administrateur :

%windir%\system32\inetsrv\appcmd add backup initial

Nous pouvons ensuite restaurer la configuration du serveur à l'état initial en exécutant :

%windir%\system32\inetsrv\appcmd restore backup initial

Examiner la liste par défaut des modules

Naviguez jusqu'à la section <system.webServer>/<globalModules>. Cette section, qui ne peut être configurée qu'au niveau du serveur, contient les modules chargés par chaque processus de travail du serveur. Chaque entrée configure un module avec un nom spécifique et la DLL qui met en œuvre la fonctionnalité de ce module :

<globalModules>

    <!--several modules omitted -->

    <add name="BasicAuthenticationModule" image="…\authbas.dll" />

    <add name="WindowsAuthenticationModule" image="…\authsspi.dll" />

</globalModules>

Examinez les noms des différents modules dans la configuration du serveur par défaut – nous voyons des services familiers fournis en tant qu'éléments du serveur dans IIS 6.0 :

Module d'authentification Windows, demande d'authentification NTLM

<add name="WindowsAuthenticationModule" image="…\authsspi.dll" />

Module du descripteur de fichier statiques, service de fichiers statiques

<add name="StaticFileModule" image="…\static.dll" />

Module de compression dynamique, compression des réponses

<add name="DynamicCompressionModule" image="…\compdyn.dll" />

Naviguez jusqu'à la section <system.webServer>/<modules>. Cette section, qui peut être configurée au niveau du serveur ou de l'application, spécifie les modules chargés dans la section <globalModules> pour une application particulière. Pour l'essentiel, nous constatons que cette section énumère les noms des modules que nous avons vus dans la section, en les activant par défaut pour toutes les applications.

Remarque

Il existe quelques éléments supplémentaires à la fin de la liste : il s'agit de modules gérés et développés à l'aide du modèle d'extensibilité ASP.NET. Pour en savoir plus sur la création de modes gérés, consultez le guide Développer un module à l'aide de .NET.

Naviguez jusqu'à la section <system.webServer>/<handlers. Cette section, qui peut être configurée au niveau du serveur, de l'application ou de l'URL, spécifie la façon dont les requêtes sont gérées. Les modules participent généralement à chaque requête, tandis que les gestionnaires obtiennent uniquement des demandes pour une URL particulière.

Le module de compression est une illustration de ce type de module. Le module de compression examine chaque réponse et la compresse si nécessaire. Le gestionnaire de pages ASP.NET est un bon exemple de gestionnaire. Il ne reçoit que les requêtes qui lui sont associées, par exemple les requêtes portant l'extension .aspx. La liste <handlers> définit les correspondances entre une demande basée sur l'URL et le verbe. De plus, elle définit un module de traitement qui sera utilisé pour traiter cette demande. Il existe également des informations supplémentaires qui sont utilisées pour configurer chaque mappage, ce qui n'est pas l'objet de ce sujet.

<handlers>
    <!-- certain details omitted -->
    <add name="CGI-exe" path="*.exe" verb="*" modules="CgiModule" ... />
    <add name="ISAPI-dll" path="*.dll" verb="*" modules="IsapiModule" ... />
    <add name="ASPClassic" path="*.asp" verb="GET,HEAD,POST"  modules="IsapiModule" ... />
</handlers>

Examen de l'empreinte du serveur

  1. Ouvrez Internet Explorer et effectuez une demande au serveur en spécifiant l'URL suivante et en appuyant sur Entrer :

    http://localhost/iisstart.htm

    Cette action démarre le pool d'applications serveur et sert le document iisstart.htm.

  2. Démarrez le Gestionnaire des tâches et accédez à l'onglet Processus. Étant donné que le processus de travail IIS s'exécute sous un autre compte d'utilisateur, vous devez vérifier la section « Afficher les processus pour tous les utilisateurs ». Notez la taille du processus de travail du serveur w3wp.exe.
    Capture d’écran montrant le Gestionnaire des tâches Windows. L’onglet Processus est sélectionné.
    Figure 1 : Gestionnaire de tâches montrant le processus de travail IIS

  3. Exécutez ensuite la ligne de commande suivante :

    TASKLIST /fi "imagename eq w3wp.exe" /m

    Nous constatons que plus de 90 DLL sont chargées par le processus de travail. La plupart d'entre elles se trouvent dans le répertoire ...intersrv\ – beaucoup sont des DLL de module que nous avons examinées dans la première tâche en regardant la section <globalModules>. De plus, d'autres prennent en charge le cadre .NET et l'exécution du serveur lui-même.

Supprimer le serveur

Dans la tâche précédente, nous avons examiné la liste par défaut des composants chargés par le serveur, qui contenait plus de 35 modules fournissant divers services allant de l'authentification au service de fichiers statiques. Chacun des composants chargés dans le serveur a un impact sur l'empreinte du serveur, sa surface d'attaque, ses performances d'exécution, et bien sûr, l'ensemble de fonctionnalités activé.

Avant de construire notre propre serveur personnalisé avec uniquement les fonctionnalités requises dans la tâche suivante, nous construisons un serveur Web rapide, compact et sécurisé en supprimant tous les modules et en exécutant le serveur vide.

Si nous avons modifié le fichier applicationHost.config pendant la tâche précédente, nous pouvons le restaurer à l'état d'origine en exécutant %windir%\system32\inetsrv\appcmd restore backup initial à partir de la ligne de commande.

Il s'agit ensuite de démonter le serveur.

  1. Utilisez un éditeur de texte pour ouvrir %windir%\system32\inetsrv\config\applicationHost.config.

  2. Accédez à la section <system.webServer>/<globalModules>.

  3. Supprimez toutes les entrées de la collection afin que seule une définition de section vide reste :

    <globalModules> 
    <!—Remove Everything --> 
</globalModules>

  4. Collez les éléments dans une fenêtre de bloc-notes pour les utiliser ultérieurement. Répétez la même opération avec la section <system.webServer>/<modules>. Supprimez toutes les entrées de cette section et collez-les dans un bloc-notes pour une utilisation ultérieure. Cette action permet de s'assurer que nous n'activons pas de modules dont le chargement n'est plus nécessaire. Collez ces éléments découpés dans une fenêtre de bloc-notes pour les utiliser ultérieurement.

  5. Répétez la même opération avec la section <system.webServer>/<handlers>. Supprimez toutes les entrées de cette section pour vous assurer que nous ne spécifions aucun mappage de gestionnaire avec les modules que nous avons désactivés. Collez les éléments dans un bloc-notes pour une utilisation ultérieure. Enregistrez le fichier applicationHost.config pour appliquer les modifications.

Examiner l'empreinte du serveur supprimé

À ce stade, nous sommes prêts à charger notre serveur supprimé : nous répétons les étapes précédentes pour examiner la nouvelle empreinte du serveur.

  1. Ouvrez Internet Explorer et effectuez une demande au serveur en spécifiant l'URL suivante et en appuyant sur Entrer :

    http://localhost/iisstart.htm

    Cette opération devrait démarrer le pool d'applications du serveur et renvoyer une erreur au navigateur. En effet, aucun gestionnaire n'est enregistré pour servir la ressource que vous avez demandée.

  2. Exécutez le Gestionnaire des tâches, puis accédez à l'onglet Processus. Notez la taille du processus de travail du serveur w3wp.exe.

  3. Exécutez la ligne de commande suivante :

    TASKLIST /fi "imagename eq w3wp.exe" /m

    Notez que l'empreinte du serveur a été réduite à environ 8 Mo. Dans la période de temps du serveur, l'empreinte du serveur vide sera réduite.

    Seules 50 DLL sont chargées, contre 90 ou plus. Cela indique que le serveur n'a chargé aucune des DLL du module, ce qui justifie directement et indirectement la différence de nombre de DLL. Non seulement les services sont désactivés sur le serveur, mais aucun code pour ces fonctionnalités n'est chargé au cours du processus. Après l'optimisation, le nombre de DLL du serveur vide sera considérablement inférieur.

Dans la tâche suivante, nous allons générer le serveur personnalisé avec uniquement les fonctionnalités souhaitées.

Génération d'un serveur personnalisé

Dans la tâche précédente, nous avons réduit le serveur à sa configuration minimale, en ne faisant tourner que le moteur du serveur principal et en ne chargeant aucun module supplémentaire. À présent, nous créons le serveur personnalisé à utiliser comme serveur de fichiers Web sur un réseau d'entreprise. Pour ce faire, nous allons autoriser le serveur à fournir uniquement les services suivants :

  • Délivrer des fichiers statiques
  • Servir des listes de répertoire
  • Protéger le contenu avec des règles d'autorisation de base basées sur l'authentification et l'URL

Activer le serveur pour servir des fichiers statiques

Pour effectuer cette tâche, nous supposons que nous avons suivi la tâche précédente et que nous avons désinstallé le serveur en supprimant tous les modules qu'il exécutait. Dans cet état, le serveur renvoie toujours des réponses d'erreur 401 vides à toutes les demandes. Ceci s'explique par le fait qu'aucun module n'est chargé pour assurer un quelconque traitement des demandes.

  1. Utilisez un éditeur de texte pour ouvrir %windir%\system32\inetsrv\config\applicationHost.config.

  2. Naviguez jusqu'à la section <system.webServer>/<globalModules>. Ajoutez les 2 lignes en gras ci-dessous à l'intérieur de la collection : copiez-la à partir du pavé de montage utilisé précédemment pour enregistrer les éléments de collection par défaut. Cette opération charge le module du descripteur de fichier statique. Ce module est chargé de traiter les demandes de fichiers statiques et le module d'authentification anonyme, qui produit un jeton d'authentification par défaut pour la demande :

    <globalModules>
    <add name="StaticFileModule" image="%windir%\System32\inetsrv\static.dll" />
    <add name="AnonymousAuthenticationModule" image="%windir%\System32\inetsrv\authanon.dll" />
</globalModules>

  3. Naviguez jusqu'à la section <system.webServer>/<modules>. Activez le descripteur de fichier statique et les modes d'authentification anonyme en ajoutant la ligne en gras ci-dessous :

    <modules>

    <add name="AnonymousAuthenticationModule" />

    <add name="StaticFileModule" />

</modules>

  4. Naviguez jusqu'à la section <system.webServer>/<handlers. Mappez le descripteur de fichier statique à toutes les demandes de fichiers en ajoutant la ligne en gras ci-dessous :

    <handlers>
    <add name="StaticFile" path="*" verb="GET,HEAD"  modules="StaticFileModule" resourceType="Either" requireAccess="Read"/>
</handlers>

  5. Enregistrez le fichier applicationHost.config.

  6. Ouvrez Internet Explorer et envoyez une requête à l'URL suivante :

    http://localhost/iisstart.htm

    Le document demandé est ainsi servi. Nous avons correctement activé la fonctionnalité de service de fichiers statiques sur le serveur.

  7. Ensuite, demandez la liste du répertoire en effectuant une requête à l'URL suivante :

    http://localhost

    Nous obtenons une réponse vide parce qu'aucun gestionnaire n'est actuellement chargé, activé et mappé pour traiter les listes de l'annuaire – une réponse vide est envoyée (200 OK). Dans la tâche suivante, nous allons ajouter le gestionnaire.

Activer le serveur pour qu'il fournisse des listes de répertoire

Pour effectuer cette tâche, nous supposons que nous avons effectué les tâches précédentes, que nous avons réduit le serveur à néant et que nous avons ajouté la fonction de serveur de fichiers.

  1. Utilisez un éditeur de texte pour ouvrir %windir%\system32\inetsrv\config\applicationHost.config.

  2. Comme précédemment, ajoutez la configuration ci-dessous pour activer le module de navigation dans les répertoire. Ensuite, vous devez le configurer pour qu'il réponde aux requêtes de répertoire (la configuration cumulée sera exactement comme spécifiée ci-dessous après cette étape, en s'appuyant sur l'étape précédente) :

    <globalModules>
    <add name="AnonymousAuthenticationModule" image="%windir%\system32\inetsrv\authanon.dll" />
    <add name="StaticFileModule" image="%windir%\system32\inetsrv\static.dll" />
    <add name="DirectoryListingModule" image="%windir%\System32\inetsrv\dirlist.dll" />
</globalModules>

<modules>
    <add name="AnonymousAuthenticationModule" />
    <add name="StaticFileModule" />
    <add name="DirectoryListingModule" />
</modules>

<handlers>
    <add name="StaticFile" path="*" verb="GET,HEAD" modules="StaticFileModule,DirectoryListingModule"  resourceType="Either" requireAccess="Read" />
</handlers>

    À ce stade, nous avons activé la fonctionnalité de liste d'annuaires sur le serveur. Toutefois, pour des raisons de sécurité, cette fonction expose une configuration supplémentaire qui contrôle les autorisations d'inscription dans les répertoires. Cette configuration est spécifiée dans la section <system.webServer>/<directoryBrowse>.

  3. Remplacez l'entrée par <directoryBrowse enabled="true » />

  4. Enregistrez le fichier applicationHost.config.

  5. Ouvrez Internet Explorer et répétez la demande auprès de ce répertoire en utilisant l'URL suivante :

http://localhost

Cette opération permet d'afficher la liste du répertoire demandé. Nous avons effectivement activé la fonction d'inscription dans le répertoire sur le serveur.

Ensuite, nous ajoutons les services d'authentification et d'autorisation pour protéger le contenu sur le serveur contre l'accès non autorisé.

Protection des ressources avec autorisation d'URL

Pour effectuer cette tâche, il est supposé que nous avons suivi les tâches précédentes, réduit le serveur à néant et ajouté la fonctionnalité de référencement des fichiers et des répertoires.

  1. Utilisez un éditeur de texte pour ouvrir %windir%\system32\inetsrv\config\applicationHost.config.

  2. Cette fois, nous ajoutons deux modules :

    • Le module d'authentification de base, qui prend en charge le schéma d'authentification de base via http1.1 par rapport aux informations d'identification Windows du serveur.
    • Le module d'autorisation URL, qui prend en charge le contrôle d'accès basé sur des règles d'utilisateur et de rôle

  3. Pour ajouter ces modules, ajoutez les entrées de chargement de module à la section <system.webServer>/<globalModules>. Ensuite, activez les modules dans la section <system.webServer>/<modules>, comme nous l'avons fait précédemment pour le descripteur de fichier statique et le navigateur de répertoires.

    Remarque

    Cette fois-ci, nous n'avons pas besoin d'ajouter quoi que ce soit à la section <system.webServer>/<handlers, car ces modules ne gèrent pas les requêtes. Ils fournissent uniquement des services de requête à toutes les requêtes. Votre configuration finale après l'ajout des éléments ci-dessous en gras se présente comme suit :

    <globalModules>
    <add name="AnonymousAuthenticationModule" image="%windir%\system32\inetsrv\authanon.dll" /> 
    <add name="StaticFileModule" image="%windir%\system32\inetsrv\static.dll" /> 
    <add name="DirectoryListingModule" image="%windir%\system32\inetsrv\dirlist.dll" /> 
    <add name="UrlAuthorizationModule" image="%windir%\System32\inetsrv\urlauthz.dll" />      
    <add name="BasicAuthenticationModule" image="%windir%\System32\inetsrv\authbas.dll" /> 
</globalModules> 

<modules> 
    <add name="AnonymousAuthenticationModule" /> 
    <add name="StaticFileModule" /> 
    <add name="DirectoryListingModule" /> 
    <add name="BasicAuthenticationModule" /> 
    <add name="UrlAuthorizationModule" /> 
</modules>

    Afin d'utiliser les fonctionnalités ajoutées, nous devons les configurer.

  4. Activez le service d'authentification de base. Accédez à l'élément <basicAuthentication> et définissez l'attribut activé sur True :

    <basicAuthentication enabled="true" />

  5. Désactivez l'authentification anonyme. Accédez à l'élément <anonymousAuthentication> et définissez l'attribut activé sur false :

    <anonymousAuthentication enabled="false" userName="IUSR" />

    Cette action désactive l'authentification anonyme, et nécessite que le module d'authentification de base authentifie l'utilisateur avant que l'accès ne soit accordé.

  6. Enregistrez le fichier applicationHost.config.

  7. Ouvrez Internet Explorer et répétez la demande auprès de ce répertoire en utilisant l'URL suivante :

    http://localhost

    Il s'agit d'une demande de liste de répertoire. Étant donné que le navigateur ne nous a pas authentifiés, le module d'autorisation d'URL rejette la demande. Le module d'authentification de base intercepte le rejet et déclenche un défi d'authentification de base sur le navigateur, ce qui entraîne l'affichage de la boîte de dialogue de connexion d'authentification de base.

  8. Connectez-vous avec des informations d'identification non valides. La demande est rejetée et une nouvelle demande d'informations d'identification est formulée.

  9. Connectez-vous avec le compte Administrateur que vous avez utilisé pour vous connecter à l'ordinateur. La liste du répertoire s'affiche, indiquant que vous avez ajouté efficacement les fonctions d'authentification et d'autorisation au serveur.

Résumé

Cet article traite de la nature des composants du serveur, examine les fonctions IIS fournies et explique comment construire un serveur Web personnalisé ne comportant que les services dont l'utilisateur peut avoir besoin.

Avant d'utiliser à nouveau le serveur, annulez les modifications apportées à la configuration du serveur dans le cadre de cette procédure. Si vous avez créé une sauvegarde précédemment, restaurez-la en exécutant %windir%\system32\inetsrv\appcmd restore backup initial à partir de la ligne de commande.

Pour plus d'informations, consultez les liens suivants :