Les fichiers du répertoire Webroot peuvent être les plus sensibles sur un serveur Web. Ces fichiers sont exposés au public et contiennent souvent du code sensible que des intrus peuvent utiliser pour recueillir des informations et compromettre le serveur Web. Ainsi, votre code côté serveur peut contenir des informations de
Protéger le Webroot
connexion à la base de données, comprenant
des mots de passe, fort intéressants
pour un intrus. Le code pourrait
aussi contenir des références à des
fichiers et à des répertoires tout aussi
intéressants le même individu. Si quelqu’un
parvient à accéder à ce code
source par une brèche du système de
visualisation des fichiers, votre serveur
est menacé.
Vous pouvez utiliser l’ISM (Internet
Services Manager) pour définir les permissions
de lecture, d’écriture, et de
consultation de répertoire pour les
applications Web, mais ces permissions
ne sont pas les mêmes que les
permissions NTFS. Les permissions
d’application Web contrôlent la manière
dont IIS traite les requêtes des
utilisateurs du Web ; les permissions
NTFS offrent un niveau de contrôle supérieur
et régulent quel IIS peut accéder.
Si ISM découvre une vulnérabilité
susceptible de faire révéler par IIS le
code côté serveur, les permissions
NTFS ont priorité et bloquent l’accès
au fichier. Bien que cet article ne traite
que des permissions NTFS, vous devez
aussi choisir soigneusement les permissions
attribuées dans l’ISM.
Pour sécuriser la racine Web, commencez
par enlever les permissions
héritées. Faites un clic droit sur le
répertoire Webroot, sélectionnez
Properties puis l’onglet Security.
Enlevez l’option Allow inheritable permissions
from parent to propagate to
this object. Quand le système vous demande
des instructions pour traiter les
permissions existantes, cliquez sur
Remove. On garantit ainsi que les répertoires
Web n’héritent pas par inadvertance
de permissions indésirables
provenant de répertoires parents.
Ensuite, imitez les permissions du
groupe Web Anonymous Users. Ne laissez
ce groupe Write dans aucun des répertoires
Web. Il ne faut pas que la plus
grande partie des Web Anonymous
Users écrivent dans le système de fichiers.
S’il existe une application qui
requiert des permissions Write, ajoutez
cette permission aux seuls répertoires
qui en ont besoin. Cette règle vaut
aussi pour des permissions Execute ;
enlevez les permissions Execute de
tous les répertoires Web sauf si elles
sont absolument nécessaires pour une
application Web. S’il y a des répertoires
qui contiennent des fichiers DLL ou
exécutables, les applications ne fonctionneront
correctement que si les utilisateurs
anonymes ont des permissions
Execute. Les fichiers script,
comme le code ASP, n’ont pas besoin
de permissions NTFS Execute.
Téléchargez cette ressource

État des lieux de la réponse à incident de cybersécurité
Les experts de Palo Alto Networks, Unit 42 et Forrester Research livrent dans ce webinaire exclusif leurs éclairages et stratégies en matière de réponses aux incidents. Bénéficiez d'un panorama complet du paysage actuel de la réponse aux incidents et de sa relation avec la continuité de l'activité, des défis auxquels font face les entreprises et des tendances majeures qui modèlent ce domaine. Un état des lieux précieux pour les décideurs et professionnels IT.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- DSI en assurance : gardien du temple ou moteur de la transformation ?
- Ransomware : persistance des cyberattaques à l’échelle mondiale
- Cybersécurité : l’IA générative rebat les cartes du cybercrime
- Le World Cyber Ranking, 1er classement mondial de la cybersécurité des entreprises
- Comment le Quarter Plan permet d’aligner IT et Métiers pour délivrer
