Renforcer IIS 6.0

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.