> Tech > Scripting en mode crise

Scripting en mode crise

Tech - Par iTPro.fr - Publié le 24 juin 2010
email

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.

Téléchargez gratuitement cette ressource

Guide de Services Cloud Managés

Guide de Services Cloud Managés

Accélérer votre transformation digitale, protéger et sécuriser vos environnements Cloud avec les offres de support, d'accompagnement et de services managés. Découvrez le TOP 3 des Services Managés pour accompagner la transformation de vos environnements Cloud, gagner en agilité et en sécurité dans un monde d'incertitudes.

Tech - Par iTPro.fr - Publié le 24 juin 2010