IIS a été installé avec ses paramètres par défaut normaux, ce qui, entre autres choses, désactive toutes les extensions Web et les filtres ISAPI (Internet Server API). Voici les autres mesures que j’ai prises (la plupart sont recommandées dans les ressources de Microsoft IIS 6.0 figurant dans l’encadré Autres ressources)
Installer et configurer IIS 6.0

:
1. Changé l’adresse IP du site Web dans la console IIS Manager pour que ce soit une adresse privée statique au lieu de All Unassigned.
2. Renommé le site Default Web dans la console IIS Manager.
3. Sur le site Web renommé, j’ai fait en sorte que l’en-tête de l’hôte corresponde au nom d’URL approprié. Cela empêche l’action de nombreux outils de pirates et de vers automatisés qui n’utilisent généralement que des adresses IP. Quand les utilisateurs accèdent aux sites Web, ils utilisent presque toujours le nom du site Web plutôt que l’adresse IP (voir http://www.iisanswers.com/hinders_ rant.htm pour plus de détails.
4. Mis Execute Permissions of the Web Site sur None dans la console IIS Manager.
5. Désactivé le IWAM et les comptes anonymes IIS par défaut dans l’outil User Manager.
6. Créé un nouveau compte anonyme IIS. Cette mesure est facultative mais elle m’a permis de mieux contrôler le genre d’accès que l’utilisateur anonyme IIS a sur le serveur Web.
7. Créé un groupe Anonymous Web Users, ajouté le nouveau compte utilisateur anonyme IIS au groupe et ôté le compte anonyme IIS original de celui-ci.
8. A l’aide de Windows Explorer, j’ai mis Full Control permission sur Deny sur les dossiers Windows et System32 pour le groupe Anonymous Web Users.
9. Créé un nouveau répertoire de serveurs IIS Web sur le lecteur E.
10. Dans la console IIS Manager, changé le répertoire du serveur Web de C :\Inetpub en nouveau répertoire sur le lecteur E. Le fait d’enlever le site Web du volume d’initialisation rend inopérantes de nombreuses attaques transversales sur les répertoires.
11. Donné au nouveau groupe Anonymous Web Users la permission en lecture seule sur le nouveau dossier du site Web pour empêcher des utilisateurs anonymes d’écrire ou de créer des fichiers sur le site Web.
12. Installé URLScan 2.5. URLScan se charge comme un programme ISAPI.
• Mis UseAllowExtensions à 1.
• Mis MaxURL à 50.
• Mis MaxAllowContent Length à 1000.
• Mis MaxQueryString à 0.
• Mis AllowVerbs à GET et HEAD.
• Ajouté un point (.) à AllowExtension.
Les paramètres de URLScan – en particulier, la courte longueur URL et la longueur 0 pour les requêtes – protègent efficacement le site contre des attaques par débordement de buffer, connues et à venir, via l’URL. Même si ces valeurs ne sont pas réalistes pour tous les sites de commerce électronique, tous amélioreront nettement la sécurité en rejetant des requêtes et des URL exagérément longues.
Remarque: IIS 6.0 est installé avec une grande partie des fonctionnalités d’URLScan déjà en place, mais j’ai choisi d’installer la version autonome de URLScan. Elle ajoute encore davantage de fonctionnalités et permet un plus grand contrôle de la configuration qu’en acceptant les paramètres URLScan câblés de IIS 6.0. 13. Ajouté Everyone Deny permissions sur Windows\Temporary Compressed Files.
14. Supprimé tous les fichiers dans le dossier iisadmpwd.
15. Surpprimé le dossier \wutemp laissé par l’application des correctifs.
16. Désactivé Idle Timeout pour Default App Pool.
17. Dans la console IIS Manager, désactivé Session State sur le nouveau site Web. 18. Désactivé les extensions Cache ISAPI. 19. Changé Default App Pool identity de NetworkService en LocalService parce que le site Web n’a pas besoin d’accéder à des ressources réseau supplémentaires.
20. Changé memory recycling pressure à 700 Mo pour les deux paramètres.
21. Désactivé rapid fail protection.
22. Changé Shutdown Time Limit de 90 secondes à 10 secondes.
J’ai ensuite arrêté et redémarré IIS pour voir les nouveaux changements en action. J’ai réexécuté MBSA à la recherche d’éventuels correctifs manquants et aucun n’a été signalé.
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.