Scripting en mode crise

par Bob Wells - Mis en ligne le 24/11/2004 - Publié en Novembre 2003

Utilisez des scripts pour évaluer et endiguer la crise

Vous vous souvenez probablement que le 25 janvier 2003, les serveurs du monde entier utilisant Microsoft SQL Server 2000 furent frappés par un virus insidieux baptisé Slammer. SQL Slammer est un ver propagateur qui exploite une condition de dépassement de buffer, sur des machines SQL Server. Un serveur compromis peut alors exécuter du code arbitraire pour le compte de l'assaillant ...Malheureusement, l'attaque ne visait pas que les serveurs sous SQL Server 2000. Les ordinateurs sous MSDE (Microsoft SQL Server Desktop Engine) - une version allégée et distribuable du moteur de base de données SQL Server 2000 - étaient également visés par l'attaque. Ce qui semblait être une attaque raisonnablement isolée et facilement identifiable est devenu une catastrophe tous azimuths, parce que MSDE est un composant facultatif présent dans divers produits Microsoft et tierce partie, comme Microsoft Offixe XP Professional et Microsoft Visio 2002 Professional.
MSDE n'est pas installé par défaut sur ces produits desktop, mais comment savoir s'il l'était ou non ? Le scripting apporte une réponse. Dans l'esprit des administrateurs, le scripting est souvent vu sous l'angle proactif. Par exemple, ils voient le scripting comme un outil permettant d'automatiser des tâches d'administration système courantes, comme le suivi des comptes utilisateur, le suivi des ressources et la gestion de la configuration. En réalité, le scripting peut jouer un rôle tout aussi important quand il faut réagir à  une crise imprévue du genre SQL Slammer. Pour illustrer cette affirmation, je vais utiliser l'incident SQL Slammer pour vous montrer comment le scripting permet d'évaluer et d'atténuer les dommages.

Pour pouvoir écrire un script chargé de traiter le ver SQL Slammer ou tout autre sinistre, vous devez avoir une certaine connaissance du problème. En effet, sans une certaine connaissance de la catastrophe à  affronter, vous ne pouvez pas
écrire un script chargé de fermer des ports, de tuer des processus, de désactiver des services, de remplacer des fichiers, ou d'effectuer toute autre tâche. Toute information collectée auprès du CERT Coordination Center (CERT/CC - http://www.cert.org), du fournisseur, des traces de réseau et d'autres sources vous aidera à  concentrer judicieusement votre travail d'identification et d'endiguement du problème. A titre d'exemple, voyons ce que les administrateurs ont appris à  propos de SQL Slammer:

1. Le ver peut potentiellement infecter toutes les versions non patchées de SQL Server 2000 Service Pack 2 (SP2) et antérieures, y compris toutes les versions de MSDE SP2 et antérieures.
2. Le ver exploite une condition de dépassement de buffer connue qui a été découverte et signalée au CERT en juillet 2002. Bien que Microsoft ait diffusé un patch qui traitait le problème en juillet 2002, de nombreux systèmes (principalement des ordinateurs sous MSDE) sont restés non patchés pour deux raisons principales. Premièrement, les opérations d'application du patch étaient bien trop difficiles dans certains cas (ainsi, l'ancien patch exigeait trop d'étapes manuelles). Deuxièmement, de nombreux administrateurs ignoraient l'étendue du problème quant au nombre d'ordinateurs utilisant MSDE dans leurs environnements.
3. Le ver cible le SQL Server Resolution Service, qui est à  l'écoute sur le port UDP 1434 (c'est-à -dire, le port mssql- m dans la sortie de netstat.exe).
4. Dès qu'un ordinateur a été infecté par le virus SQL Slammer, le ver résident en mémoire essaie de se propager en envoyant des charges de 376 octets au port UDP 1434 à  des adresses IP aléatoires.

Identifier la portée, ou l'étendue du problème a été l'un des aspects les plus ardus du virus SQL Slammer. Cela explique pourquoi Microsoft a rapidement offert des outils aidant à  identifier les ordinateurs sous SQL Server 2000 et MSDE. Auriez-vous pu utiliser un script à  la place ? Et comment ! Vous pouvez utiliser un script tel que IdentifySQLComputers.vbs pour déceler les ordinateurs exposés au risque puis contenir la crise avec un script tel que DisableSQLService.vbs.