DetailPage-MSS-KB

Base de connaissances

Numéro d'article: 326444 - Dernière mise à jour: lundi 7 juillet 2008 - Version: 6.1

 
Nous vous recommandons vivement de que tous les utilisateurs mettre à niveau pour Microsoft Internet Information Services (IIS) version 7.0 s'exécutant sur Microsoft Windows Server 2008. IIS 7.0 augmente considérablement la sécurité de l'infrastructure Web. Pour plus savoir sujets liés à la sécurité IIS, reportez-vous au adresse site Web de Microsoft à l'adresse suivante :
http://www.microsoft.com/technet/security/prodtech/IIS.mspx (http://www.microsoft.com/technet/security/prodtech/IIS.mspx)
Pour plus d'informations sur IIS 7.0, reportez-vous au site de Web Microsoft suivant :
http://www.iis.net/default.aspx?tabid=1 (http://www.iis.net/default.aspx?tabid=1)

Sommaire

Résumé

Cet article étape par étape explique comment configurer l'outil URLScan pour protéger votre serveur Web contre les attaques et les menaces.

Installer URLScan

Pour installer URLScan, reportez-vous au site le développeur de Microsoft suivant site Web de Network (MSDN) :
http://msdn2.microsoft.com/en-us/library/aa302368.aspx (http://msdn2.microsoft.com/en-us/library/aa302368.aspx)
Pour plus d'informations, cliquez sur les numéros ci-dessous pour afficher les articles correspondants dans la Base de connaissances Microsoft :
307608  (http://support.microsoft.com/kb/307608/ ) L'utilisation de URLScan sur IIS

Modifier le fichier URLScan.ini

Tous les configuration de l'outil URLScan est exécutée via L'urlscan.ini fichier, ce qui se trouve dans le dossier %WINDIR%\System32\Inetsrv\URLscan. Pour configurer URLScan, ouvrez ce fichier dans un éditeur de texte tel que le bloc-notes, apportez les modifications appropriées, puis enregistrez le fichier.

note Vous devez redémarrer Internet Information Services (IIS) pour que les modifications soient prises en compte. Une façon, vous pouvez le faire rapidement consiste à exécuter la commande IISRESET à partir d'une invite de commandes.

Le fichier URLScan.ini contient les sections suivantes :
  • [options] : Cette section décrit les options générales URLScan.
  • [AllowVerbs] et [DenyVerbs] : cette section définit les verbes (également connu sous le nom des méthodes HTTP) qui permet de URLScan.
  • [DenyHeaders] : Cette section répertorie les en-têtes HTTP qui ne sont pas autorisés dans une demande HTTP. Si une requête HTTP comporte un des en-têtes HTTP qui sont répertoriés dans cette section, URLScan rejette la demande.
  • [AllowExtensions] et [DenyExtensions] : cette section définit les extensions que URLScan autorise.
  • [DenyURLSequences] : Cette section répertorie les chaînes qui ne sont pas autorisés dans un HTTP demande. URLScan refuse les demandes HTTP qui contiennent une chaîne qui s'affiche dans cette section.
Chaque section est décrites en détail dans ce document.

La section [Options]

Dans la section [options] , vous pouvez configurer un certain nombre d'options URLScan. Chaque ligne dans cette section a le format suivant :
OptionName=OptionValue
Les options disponibles et leurs valeurs par défaut sont les suivantes :
  • UseAllowVerbs = 1

    Par défaut, cette option est définie sur 1. Si cette option est définie sur 1, URLScan autorise uniquement les demandes HTTP qui utilisent les verbes qui sont répertoriés dans la section [AllowVerbs] . URLScan bloque les demandes qui n'utilisent pas ces verbes. Si cette option est définie sur 0, URLScan ignore la section [AllowVerbs] et au lieu de cela bloque uniquement les demandes qui utiliser verbes qui sont répertoriés dans la section [DenyVerbs] .
  • UseAllowExtensions = 0

    Par défaut, cette option est définie sur 0. Si cette option est définie sur 0, URLScan bloque demande pour extensions de nom de fichiers qui sont répertoriées dans la section [DenyExtensions] , mais autorise les requêtes pour les autres extensions de nom de fichier. Si cette option est définie sur 1, URLScan permet uniquement les demandes de fichiers portant les extensions qui sont répertoriées dans la section [AllowExtensions] et il bloque les demandes de tous les autres fichiers.
  • NormalizeUrlBeforeScan = 1

    Services Internet (IIS) reçoit des demandes qui sont des URL codée. Cela signifie que certains caractères peuvent être remplacés par un signe pourcentage (%) suivi d'un nombre spécifique. Par exemple, 20 % correspond à un espace, une demande de http://myserver/My%20Dir/My%20File.htm est identique à une demande de http://myserver/My Dir/My File.htm. La normalisation est le processus de décodage demandes codée en URL. Par défaut, cette option est définie sur 1. Si l'option NormalizeUrlBeforeScan est définie sur 1, URLScan analyse la demande décodée. Si elle est définie sur 0, URLScan analyse la demande undecoded au lieu de cela. Si cette option 0 diminue la possibilité de l'outil URLScan de bloquer certains types d'attaques.
  • VerifyNormalization = 1

    Étant donné que le signe de pourcentage (%) lui-même peut être des URL codée, un utilisateur malveillant peut soumettre une demande soigneusement créée sur un serveur qui est fondamentalement double codé. Dans ce cas, IIS peut accepter une demande de qui il serait sinon rejeter comme non valides. Par défaut, cette option est définie sur 1. Si l'option VerifyNormalization est définie sur 1, URLScan normalise l'URL deux fois. Si l'URL après la première normalisation est différent de l'URL après la normalisation deuxième, URLScan rejette la demande. Cela empêche les attaques qui reposent sur demandes codées double.
  • AllowHighBitCharacters = 0

    Par défaut, cette option est définie sur 0. Si cette option est définie sur 0, URLScan refuse les demandes qui contiennent des caractères non-ASCII. Cela peut empêcher certains types d'attaques, mais peuvent également bloquer les demandes de certains fichiers légitimes, tels que des fichiers avec des noms non anglais.
  • AllowDotInPath = 0

    Par défaut, cette option est définie sur 0. Si cette option est définie sur 0, URLScan rejeter toute demande contient plusieurs points (.). Cela empêche les tentatives de dissimuler les demandes d'extensions de nom de fichier dangereux en plaçant une extension de fichier sans échec dans la chemin d'accès d'informations ou une requête chaîne partie de l'URL. Par exemple, si cette option est définie sur 1, URLScan peut permettre une demande de http://servername/BadFile.exe/SafeFile.htm car il pense qu'il est une requête pour une page HTML, lorsqu'elle est en fait une demande d'un fichier exécutable (.exe) portant le nom d'une page HTML dans la zone PATH_INFO. Lorsque cette option est définie à 0, URLScan peut-être également refuser des demandes de répertoires qui contiennent les périodes.
  • RemoveServerHeader = 0

    Par défaut, un serveur Web renvoie un en-tête qui identifie le logiciel de serveur Web, il s'exécute dans toutes les réponses. Cela peut augmenter le problème de sécurité serveur car un utilisateur malveillant peut déterminer qu'un serveur exécute IIS et puis attaques connus des problèmes de services Internet (IIS), au lieu d'essayer d'attaquer un serveur IIS en utilisant exploits qui sont conçus pour les autres serveurs Web. Par défaut, cette option est définie sur 0. Si vous définissez l'option RemoveServerHeader à 1, vous empêchez votre serveur de l'envoi de l'en-tête qui l'identifie comme un serveur IIS. Si vous définissez RemoveServerHeader à 0, cet en-tête est encore envoyé.
  • AlternateServerName =(not specified by default)

    Si RemoveServerHeader est définie sur 0, vous pouvez spécifier une chaîne de l'option AlternateServerName pour spécifier ce qui sera passée revenir dans l'en-tête du serveur. Si RemoveServerHeader est définie sur 1, cette option est ignorée.
  • EnableLogging = 1

    Par défaut, URLScan conserve un journal complète de toutes les demandes bloquées dans % WINDIR%\System32\Inetsrv\URLScan. Vous pouvez définir EnableLogging à 0 si vous ne souhaitez pas conserver ce journal.
  • PerProcessLogging = 0

    Par défaut, cette option est définie sur 0. Si cette option est définie sur 1, URLScan crée un journal distinct pour chaque processus qui héberge URLScan.dll. Si elle est définie sur 0, tous les processus se connecter au même fichier.
  • PerDayLogging = 1

    Par défaut, cette option est définie sur 1. Si cette valeur est définie sur 1, URLScan crée un nouveau fichier de journal chaque jour. Chaque fichier journal est nommé .log URLScan. MMDDYY, où MMDDYY agit de la date du fichier journal. Si cette valeur est définie sur 0, tous les enregistrement est enregistré dans le même fichier, indépendamment de la date.
  • AllowLateScanning = 0

    Par défaut, cette option est définie sur 0. Si cette option est définie sur 0, URLScan s'exécute comme un filtre priorité haute, qui signifie qu'il s'exécute avant les autres Application Programming Interface ISAPI (Internet Server) filtre qui est installés sur le serveur. Si cette option est définie sur 1, URLScan s'exécute en tant que filtre priorité faible, afin que les autres filtres peuvent modifier l'URL avant URLScan effectue les analyse. FrontPage Server Extensions (FPSE) nécessite que cette option pour être définir à 1.
  • RejectResponseUrl =(not specified by default)

    Cette option spécifie le chemin d'accès virtuel à un fichier qui s'exécute lorsque URLScan bloque une demande. Cela permet de personnaliser la réponse est envoyée au client pour les demandes bloquées. Vous devez spécifier RejectResponseUrl comme un chemin d'accès virtuel vers le fichier approprié, par exemple /Path/To/RejectResponseHandler.asp. Vous pouvez spécifier un fichier qui URLScan généralement bloque, tel qu'une page ASP (Active Server Pages). Vous pouvez également utiliser les variables serveur suivantes à partir de la page :
    • HTTP_URLSCAN_STATUS_HEADER : il indique pourquoi la demande a été bloquée.
    • HTTP_URLSCAN_ORIGINAL_VERB : il spécifie l'action d'origine de la demande bloquée (par exemple, GET, POST, HEAD ou DEBUG).
    • HTTP_URLSCAN_ORIGINAL_URL : il spécifie l'URL d'origine de la demande bloquée.
    Si vous définissez RejectResponseUrl sur la valeur spéciale de / ~ * , URLScan utilise le mode journalisation-uniquement. Ceci permet à IIS pour répondre à toutes les demandes, mais il ajoute une entrée dans le journal URLScan pour les demandes qui sont généralement bloquées. Ceci est utile si vous souhaitez tester votre URLScan.ini fichier.

    Si vous ne spécifiez pas une valeur pour RejectResponseUrl , URLScan utilise la valeur par défaut de /<Rejected-By-UrlScan>.

  • UseFastPathReject = 0

    Par défaut, cette option est définie sur 0. Si cette option est définie sur 1, URLScan ignore le paramètre RejectResponseUrl et renvoie immédiatement un message d'erreur 404 au navigateur. C'est plus rapide que traitement RejectResponseUrl , mais il n'autorise pas autant d'options enregistrement. Si cette option est définie sur 0, URLScan utilise le paramètre RejectResponseUrl pour traiter la demande.

[AllowVerbs] et les sections [DenyVerbs]

Les sections [AllowVerbs] et [DenyVerbs] permet de définir les verbes HTTP (également connu sous le nom des méthodes) qui permet de URLScan. Verbes HTTP courants incluent GET, POST, HEAD et PUT. Autres applications, tels que FPSE et Web Distributed Authoring and Versioning (WebDAV), utilisez verbes supplémentaires.

À la fois le [AllowVerbs] et les sections [DenyVerbs] ont la même syntaxe. Ils sont effectués haut d'une liste de HTTP verbes et chaque action s'affiche sur sa propre ligne.

URLScan décide quelle section à utiliser selon la valeur de l'option UseAllowVerbs dans la section [options] . Par défaut, cette option est définie sur 1. Si UseAllowVerbs est définie sur 1, URLScan permet uniquement de demandes qui utiliser les verbes qui sont répertoriés dans la section [AllowVerbs] . Une demande qui n'utilise pas un de ces verbes est rejetée. Dans ce cas, la section [DenyVerbs] est ignorée.

Si UseAllowVerbs est définie sur 0, URLScan refuse les demandes qui utiliser verbes qui sont explicitement répertoriées dans la section [DenyVerbs] . Les demandes qui utilisent des verbes qui n'apparaissent pas dans cette section sont autorisées. Dans ce cas, URLScan ignore la section [AllowVerbs] .

La section [DenyHeaders]

Lorsqu'un client demande une page à partir d'un serveur Web, il envoie généralement sur des en-têtes HTTP qui contiennent plus d'informations sur la demande. Les en-têtes HTTP courants sont les suivants :
  • hôte :

    Cet en-tête contient le nom du serveur Web.
  • accepter :

    Cet en-tête définit les types de fichiers le client peut gérer.
  • utilisateur-agent :

    Cet en-tête contient le nom de l'Explorateur qui demande la page.
  • autorisation :

    Cet en-tête définit les méthodes d'authentification qui prend en charge le client.
Clients peuvent envoyer autres en-têtes sur le serveur pour spécifier des informations supplémentaires.

Dans la section [DenyHeaders] , vous définissez des en-têtes HTTP URLScan rejette. Si URLScan reçoit une demande contenant un en-tête est répertorié dans cette section, elle rejette la demande. Cette section se compose d'une liste de HTTP les en-têtes, avec chaque en-tête apparaissant sur sa propre ligne. Noms d'en-tête doivent être suivies d'un signe deux-points (:)) (par exemple, nom de l'en-tête : ).

[AllowExtensions] et les sections [DenyExtensions]

La plupart des fichiers comporte une extension de nom qui identifie le type de fichier qu'ils sont. Par exemple, les noms de fichiers pour Word documents généralement fin de .doc, noms de fichiers HTML généralement terminent dans .htm ou .HTML et noms de fichier au format texte brut se terminent en général par .txt. Les sections [AllowExtensions] et [DenyExtensions] permet de définir des extensions qu'URLScan ne bloque. Par exemple, vous pouvez configurer URLScan pour rejeter les demandes de fichiers .exe empêcher les utilisateurs Web de l'exécution d'applications sur votre système.

À la fois le [AllowExtensions] et les sections [DenyExtensions] ont la même syntaxe. Ils se composent d'une liste des extensions de noms de fichiers, et chaque extension apparaît sur sa propre ligne. L'extension commence par un point (.) (par exemple, .ext).

URLScan décide quelle section à utiliser en fonction de la valeur d' UseAllowExtensions dans la section [options] . Par défaut, cette option est définie sur 0. Si UseAllowExtensions est définie sur 0, URLScan refuse uniquement demandes de fichier extensions de nom qui sont répertoriées dans la section [DenyExtensions] . Les extensions de nom de fichiers ne sont pas répertoriées dans cette section sont autorisées. La section [AllowExtensions] est ignorée.

Si UseAllowExtensions est défini sur 1, URLScan refuse demandes de n'importe quel fichier extensions de nom qui ne sont pas explicitement répertoriées dans la section [AllowExtensions] . Requêtes uniquement pour une extension de nom de fichier qui est répertorié dans cette section sont autorisées. La section [DenyExtensions] est ignorée.

Pour plus d'informations sur la façon de configurer URLScan pour autoriser les demandes de fichiers qui ne portent pas une extension, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
312376  (http://support.microsoft.com/kb/312376/ ) Comment faire pour configurer URLScan pour autoriser les requêtes avec une extension nulle dans IIS

La section [DenyUrlSequences]

Vous pouvez configurer URLScan pour bloquer les demandes qui contiennent certaines séquences de caractères dans l'URL. Par exemple, vous pouvez bloquer des requêtes qui contiennent deux (.), périodes consécutives qui sont fréquemment utilisées avec exploits qui tirent parti des vulnérabilités de traversée de répertoire. Pour spécifier une séquence de caractères à bloquer, placez la séquence sur une ligne par lui-même dans la section [DenyUrlSequences] .

Notez que le ajoutant des séquences de caractères peut affecter affecter Outlook Web Access (OWA) pour Microsoft Exchange. Lorsque vous ouvrez un message dans OWA, la ligne objet du message est contenue dans l'URL qui est demandée à partir du serveur. Parce que le fichier URLScan.ini bloque les requêtes qui contiennent le signe de pourcentage (%) et le symbole esperluette (&), les utilisateurs s'afficher un message d'erreur 404 lorsque leur tentez d'ouvrir un message avec une ligne d'objet telles que « Ventes augmenter à 100 % » ou « Bob & Clara provenant à ville ». Pour résoudre ce problème, vous pouvez supprimer ces séquences de lasection [DenyUrlSequences] . Notez que cela réduit sécurité car elle autorise potentiellement dangereux demande pour atteindre le serveur.

Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
325965  (http://support.microsoft.com/kb/325965/ ) L'outil URLScan peut causer des problèmes dans Outlook Web Access

Configurer URLScan pour une utilisation avec les applications dépendant de IIS

Applications comme Exchange, FPSE et Microsoft Visual Studio .NET dépendent des services Internet (IIS) pour la fonctionnalité correcte. Si vous ne configurez pas correctement URLScan, ces applications peuvent cesser de fonctionner correctement.

Pour plus d'informations sur la façon de configurer URLScan pour fonctionner avec ces applications, cliquez sur les numéros ci-dessous pour afficher les articles correspondants dans la Base de connaissances Microsoft :
309508  (http://support.microsoft.com/kb/309508/ ) Configurations IIS Lockdown et URLscan dans un environnement Exchange
309394  (http://support.microsoft.com/kb/309394/ ) Comment faire pour utiliser URLScan avec FrontPage 2000
318290  (http://support.microsoft.com/kb/318290/ ) Comment faire pour utiliser URLScan avec FrontPage 2002
310588  (http://support.microsoft.com/kb/310588/ ) Trousse à outils de sécurité des sauts de débogage ASP.NET dans Visual Studio .NET

Plus d'informations

Si le URLScan.ini n'existe pas dans le dossier %WINDIR%\System32\Inetsrv\URLscan, le client reçoit une réponse d'erreur 404. Pour résoudre ce problème, restaurer le fichier URLScan.ini à partir d'une sauvegarde ou copiez le fichier URLScan.ini à partir d'un serveur identique.

Références

Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
325864  (http://support.microsoft.com/kb/325864/ ) Comment installer et utiliser l'Assistant IIS Lockdown Wizard

Les informations contenues dans cet article s'appliquent au(x) produit(s) suivant(s):
  • Microsoft Internet Information Server 4.0
  • Microsoft Internet Information Services 5.0
Mots-clés : 
kbmt kbhowtomaster KB326444 KbMtfr
Traduction automatiqueTraduction automatique
IMPORTANT : Cet article est issu du système de traduction automatique mis au point par Microsoft (http://support.microsoft.com/gp/mtdetails). Un certain nombre d’articles obtenus par traduction automatique sont en effet mis à votre disposition en complément des articles traduits en langue française par des traducteurs professionnels. Cela vous permet d’avoir accès, dans votre propre langue, à l’ensemble des articles de la base de connaissances rédigés originellement en langue anglaise. Les articles traduits automatiquement ne sont pas toujours parfaits et peuvent comporter des erreurs de vocabulaire, de syntaxe ou de grammaire (probablement semblables aux erreurs que ferait une personne étrangère s’exprimant dans votre langue !). Néanmoins, mis à part ces imperfections, ces articles devraient suffire à vous orienter et à vous aider à résoudre votre problème. Microsoft s’efforce aussi continuellement de faire évoluer son système de traduction automatique.
La version anglaise de cet article est la suivante: 326444  (http://support.microsoft.com/kb/326444/en-us/ )
L'INFORMATION CONTENUE DANS CE DOCUMENT EST FOURNIE PAR MICROSOFT SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE. L'UTILISATEUR ASSUME LE RISQUE DE L'UTILISATION DU CONTENU DE CE DOCUMENT. CE DOCUMENT NE PEUT ETRE REVENDU OU CEDE EN ECHANGE D'UN QUELCONQUE PROFIT.
Partager
Options de support supplémentaire
Forums du support Microsoft Community
Nous contacter directement
Trouver un partenaire Microsoft Certified Partner
Microsoft Store