UrlScan RemoveServerHeader Property Vs HKLMSYSTEMCurrentControlSetServicesHTTPParpametersDisableServerHeader
Cela fait plusieurs fois qu'une incompréhension résulte en l'ouverture d'un incident au support Microsoft. Il est avéré que la clé "HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parpameters\DisableServerHeader" est sensée supprimer le header "Server" renvoyé par IIS. Or, cette clé ne permet pas de supprimer les headers positionnés au niveau User-Mode mais seulement ceux positionnés au niveau du driver HTTP.sys.
De manière plus précise, lorsqu'une requête arrive sur un serveur IIS, elle est d'abord prise en charge par le driver HTTP.sys qui est le driver Kernel de IIS qui gère toutes les connexions entrantes sur le serveur. En fonction de la requête, elle peut être soit directement traitée par HTTP.sys, soit être envoyée vers le User-Mode de IIS (processus W3WP.exe pour simplifier). Quand elle passe par le User-Mode, le header renvoyé est "Server: Microsoft-IIS/7.5". C'est ce header que la plupart des gens cherchent à supprimer. Cependant, lorsqu'elle passe uniquement par le Kernel-Mode, le header qui est normalement renvoyé est "Server: Microsoft-HTTPAPI/2.0". En positionnant la clé "DisableServerHeader" à 1, c'est ce header que vous allez supprimer.
Pour supprimer le header "Server: Microsoft-IIS/7.5", il faut utiliser UrlScan. UrlScan est un excellent outil pour renforcer la sécurité d'un serveur web et généralement la suppression de ce header fait partie de cette optique. Il suffit donc de positionner le paramètre RemoveServerHeader à 1 comme ci-dessous dans le fichier UrlScan.ini (C:\Windows\System32\inetsrv\urlscan) :
RemoveServerHeader=1 ; If 1, remove the 'Server' header from
; response. The default is 0.
Toutefois, si actuellement vous n'utilisez pas UrlScan, il est possible que la configuration par défaut modifie le comportement de votre serveur et empêche ainsi le bon fonctionnement de certaines applications. Ayant déjà rencontré ce problème, vous trouverez à la fin de cet article le fichier UrlScan.txt (à renommer en UrlScan.ini) qui devrait avoir pour conséquence de "désactiver" l'ensemble des paramètres d'UrlScan sauf le RemoveServerHeader. Si vous le désirez, vous pouvez tester ce fichier et vérifier qu'il correspond bien à vos attentes.
Note 1 : Avant d'effectuer le test :
- Quelques modifications vont devoir être apportées au fichier. En particulier les points 8 & 10 qu'il vous faudra adapter à vos besoins.
- Pensez à sauvegarder le fichier UrlScan.ini d'origine afin de pouvoir effectuer rapidement un retour arrière si quelque chose ne se passe pas correctement.
Note 2 : Je vous conseille de redémarrer le serveur après avoir remplacé le fichier UrlScan.ini afin d'être certain que l'ensemble des paramètres ont bien été appliqués.
Avertissement : Je tiens à souligner que désactiver l'ensemble des fonctionnalités n'est pas une idée judicieuse pour la sécurité du serveur IIS. Cette procédure n'est fournie qu'à titre de test afin de vérifier la suppression du header "Server: Microsoft-IIS/7.5" sans impacter le fonctionnement du serveur IIS. Il n'est bien entendu pas recommandé de faire tourner un serveur IIS en production avec cette configuration d'UrlScan. Si vous décidez d'utiliser cette procédure en production et qu'un incident survient à cause de cette dernière, le support Microsoft ne pourra pas en être tenu responsable.
En complément, voici quelques explications sur ce que j'ai fait au niveau de la configuration d'UrlScan :
- 1- UseAllowVerbs
If 1, use [AllowVerbs] section, else use the [DenyVerbs] section. The default is 1.
Si ce paramètre est activé, UrlScan ne va autoriser que les verbes présents dans la section [AllowVerbs]. Afin d'éviter de lister tous les verbes qui existent dans cette section, j'ai positionné le paramètre à 0 et commenté l'ensemble des verbes contenus dans la section [DenyVerbs]. Ainsi nous laisserons passer tous les verbes qui ne sont pas listés, et comme il n'y en a pas, on laissera tout passer.
- 2- UseAllowExtensions
If 1, use [AllowExtensions] section, else use the [DenyExtensions] section. The default is 0.
Même principe que le précédent, paramètre à 0 et on commente ce qu'il y a dans la section [DenyExtensions].
- 3- NormalizeUrlBeforeScan
If 1, canonicalize URL before processing. The default is 1. Note that setting this to 0 will make checks based on extensions, and the URL unreliable and is therefore not recommend other than for testing.
Le principe est de décoder une URL qui a été encodée avant de l'analyser. Par exemple, le caractère d'espacement sera encodé avec un %20. Une URL du type "https://myserver/My%20Dir/My%20File.htm" sera décodée par UrlScan comme "https://myserver/My Dir/My File.htm" et une fois cette opération effectuée, UrlScan l'analysera. Laisser ce paramètre à 1 ne devrait pas impacter l'application. Cependant, j'ai passé le paramètre à 0 car cela devrait arrêter le procédé de décodage qui est inutile dans le scénario que vous souhaitez mettre en place. On gagnera certainement en temps de traitement.
- 4- VerifyNormalization
If 1, canonicalize URL twice and reject request if a change occurs. The default is 1.
Même principe que précédemment, sauf qu'ici une deuxième tentative de décodage est effectuée au cas où un élément de l'URL serait doublement encodé. Si à la deuxième tentative de décodage l'URL est la même, l'accès est autorisé, sinon la requête est rejetée. J'ai mis ce paramètre à 0 étant donné que la première vérification est désactivée.
- 5- AllowHighBitCharacters
If 1, allow high bit (ie. UTF8 or MBCS) characters in URL. The default is 0.
Si ce paramètre est à 0, il va bloquer les requêtes qui contiennent un caractère non-ASCII. Cela peut avoir un impact pour des fichiers tout à fait normaux comme par exemple ceux avec des noms non-Anglais. Je l'ai passé à 1 pour le désactiver.
- 6- AllowDotInPath
If 1, allow dots that are not file extensions. The default is 0. Note that setting this property to 1 will make checks based on extensions unreliable and is therefore not recommended other than for testing.
Si ce paramètre est à 0, il va bloquer les requêtes qui contiennent plusieurs points (.) afin d'éviter des tentatives d'accès à des mauvais fichiers masqués dans une URL vers un fichier tout à fait sûr. Par exemple : https://servername/BadFile.exe/SafeFile.htm. Je l'ai passé à 1 pour le désactiver.
- 7- RemoveServerHeader
Je vais passer sur ce paramétrage car vous savez parfaitement ce qu'il implique. Je l'ai positionné à 1 pour l'activer.
- 8- EnableLogging
If 1, log UrlScan activity. The default is 1. Changes to this property will not take effect until UrlScan is restarted.
Par défaut UrlScan génère un fichier de log de toutes les requêtes qui ont été bloquées dans "%WINDIR%\System32\inetsrv\URLScan". Je vous recommande de le laisser activé dans un premier temps afin de vérifier qu'aucune requête n'est bloquée par UrlScan. Je l'ai toutefois désactivé dans le fichier afin qu'il ne soit pas oublié à 1 inutilement.
- 9- PerProcessLogging
This property is deprecated for UrlScan 3.0 and later. UrlScan 3.0 and later can safely log output from multiple processes to the same log file. Changes to this property will not take effect until UrlScan is restarted.
Comme indiqué ce paramètre est déprécié à partir d'UrlScan 3.0. Je l'ai donc laissé désactivé.
- 10- AllowLateScanning
If 1, then UrlScan will load as a low priority filter. The default is 0. Note that this setting should only be used in the case where there another installed filter is modifying the URL and you wish to have UrlScan apply its rules to the rewritten URL. Changes to this property will not take effect until UrlScan is restarted.
Ici, il s'agit de définir la priorité à apporter au filtre ISAPI UrlScan. Si vous laissez le paramètre à 0, ce filtre ISAPI sera exécuté en premier. Si vous passez le paramètre à 1, il passera après que des filtres ISAPI comme les FPSE ou URLRewritte aient modifiés la requête. C'est donc à vous de définir si ce paramètre doit être à 0 ou à 1. J'ai laissé la valeur par défaut dans le fichier qui est 0.
- 11- PerDayLogging
If 1, UrlScan will produce a new log each day with activity in the form 'UrlScan.010101.log'. If 0, UrlScan will log activity to urlscan.log. The default is 1. Changes to this setting will not take effect until UrlScan is restarted.
Ce paramètre permet à UrlScan de générer un fichier de log par jour. J'ai positionné le paramètre à 0. Normalement vous ne devriez pas avoir de logs générés, cependant si cela été le cas, on évitera d'avoir plein de petits fichiers.
- 12- UseFastPathReject
If 1, then UrlScan will not use the RejectResponseUrl. On IIS versions less than 6.0, this will also prevent IIS from writing rejected requests to the W3SVC log. UrlScan will log rejected requests regardless of this setting. The default is 0.
Que ce paramètre soit à 0 ou à 1, cela ne changera rien pour l'application étant donné que celui-ci s'applique uniquement une fois qu'il a été décidé de bloquer la requête. La différence principale réside dans la manière dont va être bloquée l'URL. Je vous recommande de laisser ce paramètre à 0 car si une requête est rejetée, vous obtiendrez certainement plus d'informations que si le paramètre est à 1 pour comprendre le pourquoi du blocage.
- 13- LogLongUrls
This property is deprecated for UrlScan 3.0 and later. UrlScan 3.0 and later will always include the complete URL in its log file.
Comme indiqué ce paramètre est déprécié à partir d'UrlScan 3.0. Je l'ai donc laissé désactivé.
- 14- UnescapeQueryString
If 1, UrlScan will perform two passes on each query string scan, once with the raw query string and once after unescaping it. If 0, UrlScan will only look at the raw query string as sent by the client. The default is 1. Note that if this property is set to 0, then checks based on the query string will be unreliable.
Comme le but n'est pas de scanner de la manière la plus sûre possible les requêtes avec query string mais de n'avoir que le paramètre RemoveServerHeader d'activé, j'ai désactivé ce paramètre en le passant à 0.
J'ai ensuite commenté le contenu des sections pour lesquelles nous n'avons pas fait de traitement :
- RequestLimits
- DenyHeaders
- DenyUrlSequences
- DenyQueryStringSequences
Les paramètres restants peuvent être ignorés car inutilisés ou inutiles dans le cas d'une désactivation complète des tous les paramètres d'UrlScan sauf le RemoveServerHeader:
- RejectResponseUrl=
- LoggingDirectory=Logs
- Ici vous pouvez changer l'emplacement par défaut des logs si vous le désirez
- AlternateServerName=
- RuleList
En espérant que cet article vous soit utile.
Sylvain Lecerf