Mettre en oeuvre URLScan

On peut télécharger diverses
versions d’URLScan sur le site
Web Microsoft. Quand vous lirez ces
lignes, Microsoft devrait avoir annoncé
l’installer URLScan pour IIS 5.0. Vous
avez moins de raison d’utiliser
URLScan sur IIS 6.0 parce que IIS 6.0
possède déjà  l ‘essentiel de la protection
qu’offre l’utilitaire.
URLScan compare l’URL entrante
avec les règles que vous configurez
dans urlscan.ini (situé avec le \%systemroot%system32\inetsrv\urlscan) et
autorise ou rejette la requête d’après
ces règles. Vous pouvez, par exemple,
configurer URLScan pour n’autoriser
que les requêtes pour des fichiers qui
finissent avec vos propres extensions
de fichier. Une règle aussi simple pourrait
déjouer bon nombre des exploits
IIS les plus fameux.
IIS les plus fameux.
Vous pouvez aussi configurer
URLScan pour rejeter toutes les requêtes
qui contiennent certains entêtes
HTTP, comme les en-têtes
WebDAV dans le segment de fichier
urlscan.ini suivant (merci à  Mark
Burnett pour ses améliorations à  cette
liste) :

[DenyHeaders]
Translate:
DAV:
Depth:
Destination:
If:
Label:
Lock-Down:
Overwrite:
TimeOut:
TimeType:
DAVTimeOutVal:
Other:

URLScan peut aussi refuser les URL qui

• contiennent des caractères d’ordre
  élevé

• contiennent des caractères désignés
  ou des chaînes de caractères

• dépassent une certaine longueur
• contiennent des en-têtes client qui
  dépassent une certaine longueur

• contiennent certains verbes HTTP

On peut utiliser URLScan pour
journaliser toutes les requêtes refusées
dans un fichier log, puis consulter le
log avec Log Parser Tool 2.0, disponible
à  http://www.microsoft.com/downloads,
ou Log Parser 2.1, livré avec le
Microsoft Windows Server 2003
Resource Kit ; envoyer toutes les requêtes
rejetées dans une page .asp
custom pour traitement ; accepter les
requêtes mais journaliser les événements
spécifiques comme s’ils étaient
des requêtes rejetées et supprimer ou
changer la bannière du serveur qu’IIS
envoie au client.
En ce qui concerne la possibilité
d’URLScan de refuser les URL qui dépassent
une certaine longueur, la plupart
des URL IIS sont courtes par rapport
à  la longueur d’une URL capable
de provoquer un débordement du buffer.
En étudiant la longueur des URL requises
pour vos sites Web et en imposant
la règle URLScan qui rejette toutes
les requêtes qui dépassent vos besoins,
vous améliorerez nettement la sécurité
de votre serveur. Cette seule règle peut
prévenir de nombreuses attaques
parce que vous obligez le pirate à  se
munir d’une URL dotée de certaines
caractéristiques (par exemple, se terminant
par une extension de fichier
particulière, ne contenant que des
verbes HTTP spécifiés, ne contenant
pas de composants comme des bits
d’ordre élevé, des points supplémentaires,
ou des barres obliques, ne pas dépasser 400 caractères de long).
La liste des possibilités URLScan est
impressionnante pour un binaire
d’empreinte au sol aussi petite, sans
vulnérabilités connues, et un effet négligeable
sur la performance. Rappelons
qu’outre le fait de changer la
bannière du serveur (et l’effet potentiel
sur les applications qui dépendent
de la bannière), URLScan se contente
de rejeter les requêtes vers le serveur –
l’utilitaire n’interfère nullement avec
vos applications, pas plus qu’il ne provoque
une instabilité soudaine du serveur
Web. On peut facilement supprimer
URLScan ou le placer en mode
moniteur, dans lequel URLScan enregistre
les rejets mais ne les impose pas.