Protéger le Webroot (2)

répertoire les
possède, tous les programmes que
vous lui ajouterez seront aussi exécutables.
Donc, au lieu de donner au répertoire
des permissions Execute, il
vaut mieux ne donner ces dernières
qu’aux fichiers particuliers dont l’application
Web a besoin. Ce faisant, les
éventuels nouveaux fichiers que vous
mettrez dans le répertoire n’hériteront
pas automatiquement de permissions
Execute.

De nombreuses attaques véhiculées
par le Web passent par le chargement
sur le Web d’un programme
grâce auquel l’attaquant va faciliter son
accès au système. Ainsi, le virus
CodeRed chargeait le fichier root.exe
dans le répertoire Scripts du site Web
d’une victime. En n’accordant des permissions
d’exécution qu’au niveau du
fichier, vous empêchez les nouveaux fichiers
de devenir exécutables par leur
seule présence dans le bon répertoire.
Cette seule technique aurait pu atténuer
les conséquences du virus
CodeRed et de ses variantes.

Il faut aussi restreindre l’accès du
compte System aux répertoires Web.
IIS a été vulnérable à  plusieurs types
d’attaques par débordement du buffer,
qui permettaient aux intrus de gagner
l’accès au niveau System, et des vulnérabilités
du même genre risquent fort
d’apparaître à  l’avenir. On peut aussi
réduire l’exposition à  de telles attaques
en limitant ce que le compte System
peut faire au Webroot. Bien que le
compte System puisse changer le jeu
de permissions NTFS sur n’importe
quel fichier, cette façon de faire nécessite
une approche plus complexe, limitant
du même coup l’exposition aux attaques
les plus sophistiquées.
Toutefois, sachez que si vous utilisez l’Indexing Service, le compte System
doit être en mesure de lire le Webroot
pour créer un index.