Pour renforcer un site web IIS, l'important est d'utiliser les contrôles d'accès disponibles.
Les changements que Microsoft a apportés à la sécurité avec Windows Server 2003 permettent aux administrateurs d’installer et de mettre en route un serveur IIS 6.0 avec peu d’efforts. Même IIS 5.0, après un rapide durcissement à l’aide de l’IIS Lockdown Tool, offre une sécurité relativement bonne.
Mais il ne faudrait pas que cette absence de problèmes de sécurité vous rende complaisants. Même si Microsoft a tout fait pour réduire considérablement la surface d’attaque des serveurs IIS, des intrusions ont encore lieu. Mais, en raison du manque de vulnérabilités publiées, les attaques ont changé de cible : au lieu d’exploiter la plate-forme, elles exploitent les applications et la configuration du serveur. Cela m’a conduit à recenser quelques conseils et meilleures pratiques susceptibles de rendre votre serveur IIS encore plus résistant aux attaques.
Pour renforcer un site Web IIS, l’important est d’utiliser les contrôles d’accès disponibles. En effet, IIS permet de restreindre l’accès en limitant les types de fichiers autorisés et les verbes HTTP utilisés avec chaque type de fichier, en définissant des restrictions IP pour un contenu, et en autorisant ou en interdisant la lecture, l’écriture et l’accès aux répertoires. Vous pouvez configurer ce paramétrage au moyen de l’UI IIS Manager d’IIS 6.0 ou au moyen du snap-in Microsoft Management Console (MMC) IIS dans IIS 6.0 et versions antérieures.
Tirez aussi parti de la granularité des permissions de fichiers NTFS et instaurez des permissions individuelles pour chaque type de contenu et zone du site Web. Prenez le temps d’établir des permissions sur les fichiers individuels. Ainsi, peu de gens savent qu’il n’est pas nécessaire d’autoriser l’accès en lecture aux fichiers .asp ; par conséquent, utilisez la console IIS Manager pour supprimer l’option Read pour tous les fichiers .asp, comme le montre la figure 1, Figure disponible sur le Club Abonnés.
NTFS permet de définir un ACL sur un dossier avec des permissions distinctes pour celui-ci, les éventuels objets enfants (fichiers, par exemple) et les éventuels conteneurs d’enfants (sous-répertoires, par exemple). Vous pouvez donc établir des permissions strictes sur un répertoire, pour empêcher l’accès aux objets enfants, puis changer explicitement les permissions sur chaque fichier de ce répertoire pour autoriser l’accès dont les utilisateurs ont besoin. Cela fait, les utilisateurs pourront accéder aux fichiers individuels,
mais quand quelqu’un d’autre créera un nouveau fichier dans ce répertoire, le fichier en question héritera des permissions strictes que vous aurez instaurées sur le répertoire.
Le compte IUSR traite les requêtes anonymes de ressources Web. Quand vous établissez les permissions NTFS, accordez l’accès Read pour le compte IUSR pour l’accès anonyme et l’accès Read pour des utilisateurs ou des groupes spécifiques pour l’accès authentifié. Si vous refusez l’accès Read du compte IUSR à, par exemple, index.html, les utilisateurs Web anonymes ne pourront pas accéder à ce fichier.
Mais il ne faudrait pas que cette absence de problèmes de sécurité vous rende complaisants. Même si Microsoft a tout fait pour réduire considérablement la surface d’attaque des serveurs IIS, des intrusions ont encore lieu. Mais, en raison du manque de vulnérabilités publiées, les attaques ont changé de cible : au lieu d’exploiter la plate-forme, elles exploitent les applications et la configuration du serveur. Cela m’a conduit à recenser quelques conseils et meilleures pratiques susceptibles de rendre votre serveur IIS encore plus résistant aux attaques.
Téléchargez cette ressource
Guide de Threat Intelligence contextuelle
Ce guide facilitera l’adoption d’une Threat Intelligence - renseignement sur les cybermenaces, cyberintelligence - adaptée au "contexte", il fournit des indicateurs de performance clés (KPI) pour progresser d' une posture défensive vers une approche centrée sur l’anticipation stratégique
