Que le scanning commence

versions de
Microsoft IIS, incluent Internet Server
API (ISAPI) Extension Buffer Overflows
(par exemple, l’exploit CodeRed), les
exploits Remote Data Services (RDS),
Unicode Vulnerability (par exemple,
l’exploit Nimda) et les exemples de
script CGI (Common Gateway
Interface) existants. Sur mes DC (domain
controllers) et stations de travail
internes, j’ai recherché les shares non
protégés, les mots de passe vierges, les
services actifs non autorisés, et la possibilité
de se connecter par l’intermédiaire
de sessions nulles. J’ai également
contrôlé la capacité de chaque
produit à  trouver des clients « voyous »
potentiels à  partir d’un inventaire de
tous les hôtes du réseau.

Tester la capacité de chaque produit
à  identifier les menaces a été plus
difficile que prévu. Chaque produit a
une méthode unique pour détecter les
vulnérabilités de sécurité. Ces différentes
approches s’expliquent par le
fait qu’un langage standard permettant
d’identifier et de présenter les vulnérabilités,
émerge à  peine : MITRE a pris la
tête de ce développement, créant la
liste CVE (Common Vulnerabilities and
Exposures), qui utilise un numéro CVE
pour dresser le catalogue des vulnérabilités.
Le numéro CVE, qui correspond
à  une description détaillée de la
menace, donnera au monde de la sécurité
un modèle de référence commun.
Bien que les fournisseurs des
produits que j’ai testés préconisent
CVE, leurs scanners de vulnérabilité
n’utilisent pas encore les numéros CVE
comme principal moyen d’identification
des menaces. Chaque produit utilise
plutôt une méthode de catalogage
propriétaire tout en utilisant les numéros
CVE dans ses références. Bien que
ces approches différentes aient compliqué
mes tentatives de comparaison
des scannings, elles ne devraient pas
poser de problème majeur dans votre
activité quotidienne. Mais sachez qu’il
sera parfois difficile et fastidieux
d’identifier une menace.

Chaque produit a identifié admirablement
les principales menaces de sécurité
présentes dans ma liste, et chacun
a reconnu les exploits de Nimda et
CodeRed – et plusieurs menaces
moindres – comme étant à  haut risque.
Leurs interfaces me permettent de
trier facilement les résultats du scanning
sur différents critères : client, menace,
et gravité de la menace. Les trois
produits ont reconnu mes hôtes non-
Windows et le routeur Cisco 2514 de
Cisco Systems que j’ai utilisé pour segmenter
mes réseaux. Chaque produit
offrait un scan de vulnérabilité précisément
destiné au routeur et a reconnu
les vulnérabilités dans les noms de communauté SNMP que j’avais attribués.
Tous les produits ont scrupuleusement
identifié les vulnérabilités et
leurs emplacements.

J’ai été impressionné par la détection
de la part d’Internet Scanner d’un
AP (Access Point) Cisco Aironet
802.11b – ainsi que par sa constatation
que l’AP n’avait pas de cryptage WEP
(Wired Equivalent Privacy) activé. Si le
produit avait découvert la même vulnérabilité
sur les AP Dell, Intermec
Technologies, et Intel que j’utilisais,
j’aurais été encore plus impressionné.
Mais les réseaux sans fil prolifèrent
comme le chiendent et donc la présence
d’éventuelles unités 802.11 dans
la base de données de vulnérabilités
d’Internet Scanner vaut d’être mentionnée.

Il est important qu’un produit
identifie les menaces réelles, mais il est
tout aussi important qu’il évite de faux
doubles. Bien que j’aie trouvé
quelques éléments erronés dans les résultats
de scanning de chaque produit,
c’est NetRecon qui a le plus « gonflé »
les rapports. L’une des redondances
constatées est celle de multiples listings
montrant l’accès à  la même ressource
du réseau. Après quelques recherches,
j’ai découvert que la
fonction Smart Scan de NetRecon – qui
capture les mots de passe vulnérables
et les utilise pour s’ouvrir l’accès – indiquait
une vulnérabilité chaque fois
qu’un mot de passe ouvrait correctement
un share. Au fur et à  mesure que
la liste de mots de passe de Smart Scan
grandissait, la liste des doublons sur le
rapport de scanning faisait de même.
Symantec met au point un filtre qui réglera
ce problème.