[NessusWX – Partie 1] Introduction, installation et configuration

Par Rédaction, secuobs.com
Le 12/05/2008

---

Résumé : Nessus WX est la version graphique pour les systèmes d'exploitation de type Microsoft Windows du logiciel homonyme sous les systèmes d'exploitation Linux. Nessus s'est imposé au fil des années comme un standard parmi les scanners de vulnérabilités. - Lire l'article



NDLR : ce document a été rédigé en 2006, certaines versions ainsi que certaines configurations des logiciels utilisés selon ces versions peuvent être différentes de celles qui sont mentionnées ; merci de vous reporter vers les sites officiels des projets en question en cas de problème.


Nessus est un outil d’audit réseau open source produit par la société Tenable Network.

A l’origine exclusivement réservé aux plateformes *nix, une version cliente est désormais disponible gratuitement pour les environnement Windows : NessusWX.

Les outils Nessus sont couramment utilisés dans les tests d’intrusion (pen-tests, penetration testing) ou simplement dans des audits internes réguliers.

Ils permettent, via des plugins devant être mis à jour régulièrement, de diagnostiquer le niveau de sécurité d’une ou plusieurs machines (plages d’adresses, réseaux, ou hôtes simples).

Les scans et recherches de vulnérabilités sont effectués directement depuis le serveur, les clients jouant le rôle de commanditaires : des contrôles d’accès plus fins peuvent donc être fixés sur les pare-feux en amont.

Le serveur nessusd devra lui, en revanche, toujours fonctionner dans un environnement *nix avec sa configuration préalablement fixée (utilisateur « nessus », authentification par mot de passe ou certificat, etc.)


Installation

L’installation de NessusWX est très simple : elle ne comporte pas d’installer, le paquet (fichier zip) est téléchargeable sur le site officiel ( lien )lien Une fois l’archive extraite, l’exécutable peut être directement lancé sans opération préalable.


Configuration

Les principales options de NessusWX seront détaillées ici, permettant de configurer l’environnement de travail ainsi que les paramètres propres aux audits (cibles, plugins, méthodes des scans, etc.).

La illustre l’interface principale de NessusWX. Les audits peuvent être groupés en sessions (cf. icônes vertes). L’organisation s’en voit alors simplifiée et il est possible de garder un suivi des audits précédemment effectués, et de comparer chronologiquement plusieurs tests.

La communication avec le serveur Nessus se configure dans le menu « Communications » (raccourci clavier F4). L’adresse IP (ou le FQDN) doit alors être renseigné, ainsi que le port distant en écoute (TCP/1241 par défaut).

Le login doit également être entré (login attribué par l’administrateur du serveur Nessus)

Deux types d’authentifications sont possibles :

- Une authentification par mot de passe ;

- Une authentification par certificat.


Dans tous les cas, l’administrateur du serveur Nessus devra fournir les éléments nécessaires (certificat ou mot de passe).

Une fois ces champs renseignés, le certificat du serveur s’affiche à l’écran. Si l’utilisateur est certain de l’intégrité du certificat proposé (par exemple si celui-ci est signé par d’autres tiers de confiance), la meilleure solution est d’accepter et de le sauvegarder.

En effet, en cas de changement de celui-ci, un message d’alerte sera affiché, évitant ainsi des attaques du type homme du milieu par exemple (MITM : Man in the middle).

La configuration de la session s’effectue dans le menu (clic droit sur l’icône), puis « Properties ».

Les onglets proposés sont :

- Targets permettant de régler les différentes cibles à auditer (cf. et ). Il est possible de spécifier des machines seules, des plages d’adresses discontinues, ou directement des réseaux (de la forme adresse + masque) ;

- Options (cf. ) permettant de définir les options générales (nombre de scans simultanés, safe checks permettant de limiter les dégâts collatéraux pouvant être occasionnés par ce type d’audits intrusifs, le chemin par défaut des scripts CGI, etc.) ;

- Port scan (cf. et ) permettant de régler de nombreuses options du scanner de port (qui précède toujours les batteries de tests).

Plusieurs types de scans sont disponibles (SYN, FIN, XMAS, NULL, connect…) et peuvent permettre, par exemple, de contourner des règles de pare-feux défaillantes comme le port source 53 (DNS) accepté en entrée depuis toutes les sources.

Les plages de ports à scanner peuvent également être spécifiées pour gagner en temps ;

- Connection pour éventuellement configurer un serveur nessusd spécifique à la session en cours ;

- Plugins pour activer, ou non, les différents tests.

Ce choix est très important pour la longueur de l’audit, les faux-positifs (il serait inutile d’activer les plugins Windows sur une infrastructure entièrement Linux par exemple), ou encore le degré d’intrusion du test.

Il est en effet possible de ne sélectionner uniquement les plugins ne pouvant entraîner de déni de service sur les cibles.

Il est possible de fixer des logins/passwords par défaut, des chemins (CGI, pages d’administration…), de fixer des timeouts, etc. 

Ces réglages permettent, une fois la configuration sauvegardée, d’automatiser les tests de façon régulière ;

- Comments, zone de commentaires.


L’ajout par subnet fait appel à un notation de type 192.168.0.0/24 (ou 192.168.0.0 est l’adresse et 24 le masque de sous réseau).

Dans l’ajout par intervalle d’adresse (address range), l’exemple précédent se formulera « From 192.168.0.1 To : 192.168.1.255 ».

L’augmentation du nombre d’hotes scannés en même temps (hosts scanned) et le nombre de test effectués par hote en même temps (security checks per host) permettent de diminuer la durée du scan.

Pour ne rien louper, il est possible de spécifier que tous les ports doivent être testés (1-65535) grace à l’option specific range.

Il est possible de choisir différentes technique de scan. Ici nous sélectionnons un scan basique de type connect(). Le scan SYN est aussi très utilisé.

Désactiver les plug-ins inutiles permet d’améliorer la rapidité du scan par nessus


Autres ressources dans ce dossier :

[NessusWX – Partie 2] Audits et conclusion – lien