Attaque par IIS dans la DMZ

J’ai ouvert le snap-in Microsoft Management Console (MMC) Active Directory Users and Computers et examiné tous les comptes utilisateur. J’ai constaté que quelqu’un avait créé un compte utilisateur malveillant, membre du groupe Administrators. J’ai su qu’un intrus avait piraté le réseau. J’ai donc fermé toutes les connexions externes et commencé la recherche d’un ordinateur compromis. Il n’a pas fallu longtemps. Mon client avait deux serveurs Web dans la zone démilitarisée (DMZ, demilitarized zone). Un serveur exécutait la page Web de la société tandis que l’autre exécutait le logiciel de contrôle de l’heure. J’ai examiné les sous-clés Run du registre et analysé les fichiers batch suspects sur les lecteurs C des deux serveurs. Le serveur chargé du contrôle de l’heure était gravement compromis. Il contenait des programmes FTP et SMTP malveillants, avec de multiples root kits. Ce serveur était connecté à un système Microsoft SQL Server sur le côté LAN et n’autorisait que le trafic SQL Server à passer de la DMZ au LAN. Le serveur utilisait Win2K avec SP2 (Service Pack 2) et il lui manquait beaucoup de mises à jour Win2K critiques.

Réparer le dommage. J’ai reconstruit le serveur à partir de zéro, l’ai déplacé vers le côté LAN du pare-feu et éliminé tout accès public y conduisant. Après quoi, j’ai reconnecté les lignes externes et les ai surveillées de près pour traquer toute activité suspecte.

Leçons apprises. Avant de placer dans la DMZ un serveur accessible publiquement, vérifiez avec les fournisseurs de logiciels que les programmes que vous exécuterez sur le serveur seront suffisamment protégés conte l’accès public. Gardez tous les serveurs, et pas simplement ceux de la DMZ, actualisés avec les tous derniers packs de service et mises à jour critiques. Assurez-vous que les applications utilisent la sécurité intégrée à SQL Server et qu’elles n’utilisent pas une chaîne de connexion dans leur code pour se connecter à un serveur SQL. En effet, le fait d’insérer une chaîne de connexion dans le code serveur Web donne instantanément à un intrus un nom d’utilisateur et un mot de passe valides. Pour plus d’informations sur l’établissement d’une connexion SQL Server à partir d’un serveur Web, reportez- vous à l’article Microsoft « Recommendations for Connecting to Databases Through Internet Information Services » (http://support.microsoft.com/?kbid=258939).

Assurez-vous que Microsoft IIS utilise les procédures stockées pour accéder aux données de SQL Server, et ne laissez pas le serveur IIS exécuter des instructions SQL. Comme ces étapes vous permettent d’accorder à un utilisateur authentifié des permissions Execute pour des procédures stockées bien précises, vous pouvez interdire à l’utilisateur d’exécuter des instructions SELECT sur SQL Server.