Renforcer IIS 6.0

Certes, il a fallu à Microsoft quelques années pour mettre IIS d’aplomb, mais IIS 6.0 peut être un serveur Web solide et sûr. Plus de la moitié des entreprises recensées dans la liste Fortune 1000 2005 utilisent IIS 6.0 pour héberger leurs sites Web principaux, selon une étude menée par Port80 Software. Et depuis son lancement en mars 2003, IIS 6.0 n’a fait l’objet que de trois avis de vulnérabilité par rapport aux 24 avis d’Apache 2.0, si l’on en croit Secunia IT, firme des services de sécurité. On peut en déduire que Microsoft a tenu sa promesse d’une meilleure sécurité des serveurs Web.Cela dit, quand on a pour mission de renforcer un serveur Microsoft IIS qui sera relié à Internet, il y a de quoi se sentir intimidé. Autant démarrer avec Windows Server 2003 et IIS 6.0 – ils sont parfaitement sûrs dès leur déballage. Mais, dans le monde réel, il faut installer et configurer des sites et des applications Web. Le fait de rattacher un serveur Web à Internet incite aussi une armée de pirates ou de scanners malveillants à ratisser votre site dans l’espoir de se glisser dans une faille de configuration. Sachant tout cela, j’ai installé Windows Server 2003, l’ai renforcé contre d’éventuelles attaques puis j’ai téléchargé et suivi les guides de sécurité pour l’installation et le déploiement de Microsoft IIS 6.0. Voici un résumé des étapes suivies.

La première étape a été d’installer Windows 2003 et de lui appliquer tous les correctifs avant de le connecter à Internet. Je voulais m’assurer de la sécurité du système de base Windows 2003 avant d’installer IIS. En premier lieu, il fallait être certain que tout le matériel et le BIOS étaient dotés du tout dernier firmware. Pas question d’être piraté à cause d’un driver SCSI périmé.

J’ai imposé l’initialisation à partir du seul lecteur C, pour prévenir les attaques locales qui utilisent des OS de contournement d’initialisation comme Knoppix ou NTFSDOS. Empêcher l’initialisation non autorisée à partir du lecteur de CD-ROM ou de disquettes contribue à stopper de nombreux programmes de réinitialisation ou de percement de mot de passe et rend plus difficile la copie du SAM local sur un support amovible. J’ai également désactivé les ports COM, LPT1, IDE et USB inutilisés dans le BIOS, puis protégé celui-ci au moyen d’un mot de passe complexe. J’ai installé un routeur et un pare-feu devant l’ordinateur serveur et j’ai bloqué les ports TCP de tous les routeurs, à l’exception d’un port RDP destiné à l’installation et à la configuration à distance. Dès que le site est devenu actif, j’ai également ouvert le port TCP 80.

Après quoi, j’ai installé Windows 2003, Standard Edition, et utilisé les paramètres par défaut pour un serveur en mode groupe de travail autonome (un domaine n’est pas nécessaire pour un serveur Internet face au public autonome). J’ai créé deux lecteurs locaux, C et D, sur le disque dur du serveur, lui-même protégé par RAID. Microsoft recommande d’installer l’OS sur un volume et le site Web IIS sur un autre pour empêcher des attaques transversales sur les répertoires.

J’ai rebaptisé les comptes Administrator et Guest avec des noms d’utilisateurs passe-partout et j’ai donné aux deux comptes des mots de passe complexes de plus de 10 caractères, pour réduire les risques d’une attaque par force brutale cherchant à deviner les mots de passe. Bien qu’un assaillant puisse découvrir le compte Administrator par l’énumération SID, l’énumération SID anonyme est désactivée par défaut sur les systèmes qui ne sont pas des DC dans Windows 2003 et Windows XP.

J’ai validé Remote Desktop comme le seul moyen d’administrer à distance le serveur. J’ai choisi Remote Desktop parce qu’il est installé (mais pas validé) par défaut, qu’il fonctionne bien, qu’il permet l’association de périphériques à distance afin que je puisse installer du logiciel, et qu’il possède le cryptage RC4 par défaut. J’ai changé le port RDP associé en autre chose que le port TCP 3389, suivant ainsi les instructions de l’article Microsoft « How to Change Terminal Server’s Listening Port » (http://support.microsoft.com/?k bid= 187623). Le port a été changé dans le but de ralentir des tentatives de pirates de découvrir le service Remote Desktop et les attaques visant à deviner le logon par force brutale auxquelles un port RDP découvert pourrait inviter.

J’ai caressé l’idée d’obliger IPSec à accéder à la connexion Remote Desktop mais j’ai renoncé à cette précaution supplémentaire dès que j’ai su que le serveur était stable. IPSec peut empêcher des attaques d’intermédiaires contre Remote Desktop mais je ne voulais pas dépanner Remote Desktop et IPSec en même temps pendant la configuration initiale. Grâce aux comptes Administrator et Guest renommés et à leurs mots de passe complexes, il serait difficile de deviner à distance le mot de passe pour pénétrer le serveur.