Brûlé par le CodeRed Worm

Généralement, nous utilisons dans
le Lab des pratiques de sécurité standard.
Dans une grande mesure, nous comptons
sur une méthode simple mais efficace:
isoler physiquement nos réseaux
de test. Quand un produit soumis aux
tests nécessite l’accès à  Internet ou des
liaisons WAN, nous simulons ces
connexions en utilisant des routeurs ou un logiciel d’émulation spécial comme
The Cloud de SHUNRA Software, qui
émule des liaisons WAN. Dans de tels cas,
nous nous efforçons de construire des
réseaux de test jamais exposés physiquement
à  des menaces extérieures. Et,
même sur ces réseaux, nous tenons scrupuleusement
à  jour les service packs et
les hotfixes.

Si les produits testés ont besoin d’un
accès Internet, nous utilisons un réseau
avec un circuit RNIS et le protégeons
avec un pare-feu que nous verrouillons
sauf pour les ports ouverts temporairement
pour le test. Quand nous ouvrons
un port, nous utilisons NAT (Network
Address Translation) et des filtres pour
réduire notre exposition. Sur le réseau interne, nous mettons à  jour manuellement
les service packs, les patches et les
hotfixes pour chaque hôte. Ces mesures
semblaient adéquates – nous n’avons jamais
constaté une attaque réussie contre
notre réseau. Pourtant, une erreur humaine
combinée à  l’extraordinaire sophistication
du CodeRed Worm a ouvert
la porte à  une attaque.

J’étais responsable de l’erreur : en
oubliant d’annuler un mappage
d’adresse IP externe-interne NAT que
j’avais créé pour un test. Aucun hôte interne
n’avait l’adresse IP mappée, donc
cet oubli n’a pas posé de problème immédiat.
Mais nous avons par la suite
attribué cette adresse IP à  un nouveau
serveur Windows 2000 qui était encore vulnérable à  une attaque par débordement
de buffer Microsoft IIS. Vous devinez
la suite : un serveur IIS infecté par
CodeRed sur Internet essayait de se
connecter à  tout serveur IIS répondant
sur une liste d’adresses IP générées aléatoirement,
et il a trouvé et infecté notre
serveur exposé. (Si vous ne connaissez
pas bien les détails sordides de CodeRed,
consultez http://www.eeye.com/html/
reasearch/advisories/al20010717.html.)
Comme un zombie dans un mauvais film
d’horreur, notre serveur Win2K a alors
commencé à  trouver des victimes
dans sa propre liste d’adresses IP
aléatoires. Rapidement, le trafic Web a embouteillé notre circuit RNIS.

Outre la morale évidente de cette
histoire : « Ne laisse pas un grand trou
dans ton pare-feu, idiot ! », deux
autres points méritent attention. Premièrement,
les erreurs humaines sont
inévitables, particulièrement quand les
administrateurs débordés jouent à 
l’homme-orchestre (administrateur de
réseau, administrateur de la sécurité,
Webmaster, par exemple). Un outil tel
qu’un scanner de vulnérabilité peut
compenser le facteur humain en balayant
automatiquement le réseau et
en vous signalant les changements
de configuration et les menaces de sécurité
recensées. Deuxièmement, il ne faut
pas compter entièrement sur la sécurité
du périmètre pour protéger le réseau.
CodeRed n’aurait pas infecté notre serveur
si nous avions appliqué le tout dernier
patch. Il faut renforcer le réseau
interne en maintenant les service packs,
les patches et les hotfixes. Et ce n’est pas
une mince affaire. Là  encore, des fournisseurs
proposent des outils qui facilitent
cette tâche – PoliVec Scanner d’e-business
technologie n’est qu’un exemple
d’un produit qui peut aider à  garder vos
hôtes Windows à  jour et configurés en
toute sécurité.