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.
Scripting en mode crise
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:
- 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. - 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. - 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). - 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 cette ressource
Sécuriser votre système d’impression
Longtemps sous-estimée, la sécurisation d’un système d’impression d’entreprise doit être pleinement prise en compte afin de limiter le risque de fuite d’informations sensibles. Voici les 3 principales précautions à prendre.
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Un leadership décisif en matière d’IA propulse l’innovation
- En route vers l’inconnu : comment préparer les équipes à l’ère de l’IA
- L’Europe, un leader mondial de l’IA
- L’Intelligence Artificielle, le nouveau copilote du CRM : une révolution incontournable
- Optimiser la gestion de la relation client dans le secteur des sciences de la vie
