> Tech > Protéger IIS contre les attaques

Protéger IIS contre les attaques

Tech - Par iTPro.fr - Publié le 24 juin 2010
email

par Darren Mar-Elia - Mis en ligne le 13/01/2005 - Publié en Décembre 2003

Microsoft IIS tient une curieuse place dans une infrastructure réseau. S'agissant d'un code qui s'exécute en mode utilisateur étroitement intégré à  l'OS, IIS utilise des protocoles Internet pour délivrer applications et contenu aux utilisateurs distants. Pour sécuriser IIS, il faut prendre en compte tous les aspects de l'installation : réseau, application, serveur et OS ...Croyez-en mon expérience : quand vous aurez fini l'opération, vous verrez le mot défense avec d'autres yeux.
Il est étonnant de voir combien d'argent les entreprises consacrent à  la protection de leurs serveurs, tout en négligeant de se protéger contre un quidam accédant physiquement à  la machine et utilisant une disquette 3,5 pouces pour l'initialiser. Pour cet article, je suppose que vous n'avez pas besoin d'un rappel sur l'accès physique, les systèmes sans correctifs, la complexité des mots de passe, et le changement des mots de passe par défaut sur les systèmes administratifs (moniteurs de systèmes, chariots, par exemple). Pourtant, certains ne reçoivent pas le message, car ces éléments continuent à  figurer parmi les méthodes les plus courantes d'accès non autorisé aux serveurs. Pour plus de détails, voir l'article de The SysAdmin, Audit, Network, Security (SANS) Institute « The Twenty Most Critical Internet Security Vulnerabilities (Updated) - The Experts' Consensus » (http://www.sans.org/top20).
Après avoir acquis une bonne compréhension de la sécurité IIS de base, vous pouvez passer à  des sujets plus pointus : contrôle de l'identité des processus, filtrage des ports, désactivation de WebDAV (Web Distributed Authoring and Versioning) et utilisation de l'outil de sécurité URLScan. Commençons par clarifier quelques mythes tenaces à  propos de la sécurité IIS et examinons certains des outils et techniques Microsoft aptes à  renforcer vos serveurs Web.

Première vérité à  propos de la sécurité
IIS : tout ce qu’on lit n’est pas vrai. En
fait, l’une des raisons pour lesquelles
j’ai commencé à  partager mon expertise
IIS a été la masse de désinformation
provenant de diverses sources,
dont Microsoft. Voyons quelques
exemples de cette désinformation.

L’utilisateur anonyme a besoin
d’un privilège log-on-locally.

Peut-être avez-vous lu que le compte
IU SR_ que IIS utilise
pour l’authentification anonyme, demande
le droit de se connecter localement.
Cette information se trouve
dans les fichiers IIS Help et sur le site
Web Microsoft, y compris l’article
Microsoft « HOW TO: Set Basic NTFS
Permissions for IIS 5.0 » (http://support.
microsoft.com//?kbid=271071).
Les utilisateurs informent souvent
leurs collègues de cette exigence dans
les groupes de support et sur les services
télématiques. En réalité, cette exigence
ne vaut que si le serveur IIS réside
sur un DC (domain controller). Le
type d’authentification qui se produit
par défaut avec un utilisateur anonyme
résulte en un logon réseau qui ne nécessite
pas le privilège log-on-locally.
Du point de vue de la sécurité, il est légitime de refuser à  un utilisateur
anonyme le droit de se connecter localement,
parce qu’on empêche ainsi
quelqu’un d’utiliser le compte utilisateur
anonyme pour obtenir un logon
local, qui permettrait à  l’utilisateur
d’avoir plus de privilèges sur le réseau
qu’un logon réseau. Par exemple, un
pirate qui utilise le compte IUSR pour
se connecter par l’intermédiaire de
Windows 2000 Server Terminal
Services serait dans une session de logon
interactive et, par conséquent, capable
d’accéder aux autres ressources
du réseau. Il faut un certain temps
pour comprendre les différences entre
un logon local et un logon réseau. Mais
cette étude vaut la peine pour les administrateurs
d’IIS et est essentielle
pour une bonne maîtrise de la sécurité
des serveurs. Pour un rapide aperçu de
l’authentification, voir http://www.microsoft.
com/technet/prodtechnol/win
xppro/reskit/prdp_log_csky.asp et
Designing Secure Web-Based Applications
for Microsoft Windows 2000
(Microsoft Press) de Michael Howard.

Les utilisateurs ont besoin de
permissions Change sur les fichiers
log.

La Secure Internet Information
Services 5 Checklist à 
http://www.microsoft. com/technet/security/
tools/chklist/iis5chk.asp contient
quelques excellentes suggestions
et une idée vraiment mauvaise : accorder
au groupe Everyone des permissions
Read, Write et Change sur les
fichiers log générés par IIS (\%systemroot%system32\logfiles). J’ai étudié
cette suggestion pendant un certain
temps pour être certain de bien la
comprendre, mais l’octroi de ces permissions
au groupe Everyone n’empêchera
pas des utilisateurs malveillants
de supprimer des fichiers log
pour effacer leurs traces, comme la
liste de contrôle l’implique. Le bon
conseil est de n’accorder des permissions
Full Control sur les fichiers log
qu’aux groupes Administrators et
System. La seule exception à  cette
règle s’applique si l’on utilise un objet
de logging personnalisé qui écrit des fichiers
log IIS. Dans cette circonstance
plutôt rare, vous pourriez avoir besoin
d’accorder des permissions Change.

ASP (Active Server Pages) a
besoin de la permission NTFS
Execute.

De nombreux documents
Microsoft et non Microsoft incluent
des permissions NTFS suggérées pour
le contenu IIS. La plupart de ces documents
indiquent que les scripts ont besoin
de la permission NTFS Execute.
Cette affirmation viole l’importante
meilleure pratique de sécurité dite
« principe du moindre privilège ». En
général, tout script associé à  un moteur
de script n’a besoin que de la permission
NTFS Read.
Les administrateurs IIS ont du mal
à  faire le tri entre les vérités et les demivérités.
Et le fait que Microsoft ait sa
part dans cette désinformation n’arrange
pas les choses. Cependant, le fait
de connaître les étapes nécessaires
pour sécuriser vos serveurs Web vous
aidera. Examinons donc quelques vérités.

Téléchargez gratuitement cette ressource

IBMi et Cloud : Table ronde Digitale

IBMi et Cloud : Table ronde Digitale

Comment faire évoluer son patrimoine IBMi en le rendant Cloud compatible ? Comment capitaliser sur des bases saines pour un avenir serein ? Faites le point et partagez l'expertise Hardis Group et IBM aux côtés de Florence Devambez, DSI d'Albingia.

Tech - Par iTPro.fr - Publié le 24 juin 2010