Nessus - un scanner de vulnérabilité

Nessus - scan

Néanmoins, Tenable Network Security maintient le moteur d'analyse de la version 2 de Nessus (ainsi qu'une infime quantité de failles de sécurité) qui est utilisé par un fork open source de Nessus : OpenVAS.

Nessus 3 est disponible pour les plateformes Windows et Unix et permet de réaliser des audits de réseaux sans utiliser d'agent. Nessus 3 est 2 à 5 fois plus rapide que Nessus 2 (ou OpenVAS).

En avril 2009, Tenable Network Security sort la version 4 de Nessus.

Nessus est le scanner de vulnérabilité réseaux de Tenable Network Security. Par rapport aux autres scanners de vulnérabilité, Nessus a la particularité d'être basé sur une architecture client/serveur et d'être compatible avec Windows et Linux. En plus, Nessus stocke et gère toutes ses failles de sécurité grâce à un système de plugins.

Nessus est un logiciel qui effectue de réelles attaques et présente le résultat de ces attaques sous forme de rapport. Son utilisation peut donc être à double tranchant. D'un côté, une équipe sécurité peut l'utiliser pour scanner son réseau dans le but de prévenir les intrusions et les dénis de service. D'un autre côté, un hacker peut l'utiliser à des fins malhonnêtes et en profiter pour exploiter les vulnérabilités déclarées.

D'après l'étude comparative menée par le site Hamza, le moteur d'analyse de risques de Nessus se situe en tête de liste :

Indicateur	MaxPatrol	Internet Scanner	Retina	Nessus	Shadow Security Scanner	Net Clarity Auditor
Identification des services et des applications, des dizaines	108	66	80	98	79	54
nombre trouvé de vulnérabilités	163	51	38	81	69	57
faux positifs	8	3	4	7	36	14
Vulnérabilité trouvée correctement (sur 225 possibles)	155	48	34	74	33	43
Nombre de sauts (faux négatifs)	70	177	191	151	192	182
en raison de l’absence d’une base de données	63	170	165	59	150	179
De ceux causés par la nécessité d’authentifier	0	6	16	36	0	0
Pour d’autres raisons	7	1	10	56	42	3

Pour la suite de la présentation, on considérera que le serveur et le client Nessus sont installés sur une machine Linux sans interface graphique. Le fait d'utiliser la ligne de commande pour utiliser Nessus permet sous Windows comme sous Linux, de planifier des scans par le planificateur de tâches ou cron (ou un quelconque ordonnanceur) et ainsi de conserver l'historique des rapports. Libre à la personne responsable de la sécurité d'utiliser ces rapports comme log ou encore de les expoités pour créer un logiciel dédié à la sécurité de son réseau.

Configuration

La gestion de la configuration du service Nessus s'est adaptée à cette architecture client/serveur.

L'utilisateur (côté client) possède un fichier de configuration par défaut ~/.nessusrc. Ce fichier de configuration va permettre de paramétrer les différentes options pour effectuer le scan.

Côté serveur, il existe également un fichier de configuration /etc/nessus/nessusd.conf. Ce fichier de configuration est plus complet que celui de la version client. Toutes les options de configuration spécifiées dans ce fichier vont écraser les options définies par l'utilisateur.

Serveur

Le serveur Nessus est un daemon. On peut l'installer à l'aide de la commande apt-get install nessusd. L'installation du serveur inclut des exécutables spécifiques à Nessus tels que :

• nessus-update-plugins : pour la mise à jour des plugins
• nessus-adduser : pour la création d'un utilisateur Nessus. Le client en a besoin pour s'authentifier auprès du serveur.
• nessus-mkcert : pour créer des certificats côté serveur. Cela permet de protéger les communications entre le client et le serveur en utilisant SSL.

Le serveur possède un fichier de configuration "/etc/nessus/nessusd.conf" pour le paramétrer. Les valeurs inscrites dans ce ficher viendront écraser les éventuelles configurations clientes. Grâce à cette gestion de fichiers de configurations, l'administrateur de Nessus peut centraliser le paramétrage de Nessus. De la même façon, le serveur possède un fichier pour centraliser les règles de scan "/etc/nessus/nessusd.rules".

Client

Le client Nessus peut s'installer en exécutant la commande apt-get install nessus. Concrètement, le client Nessus sert à se connecter au serveur Nessus et à lui transmettre une liste de machines à scanner. Il possède également quelques exécutables pour la génération de rapports sous différents formats et pour leurs conversions dans d'autres formats.

Séquence des opérations

1. D'abord, Nessus va détecter si la machine visée est vivante ou non. Grâce au plugin ping_host.nasl, il va effectuer des pings graduels. D'abord, il va tenter de joindre la cible par des requêtes ARP. Puis, il va essayer avec des requêtes TCP (avec des échanges SYN<=>ACK ou SYN<=>RST) sur des ports aléatoires allant de 1024 à 65535. Il va ensuite tenter en effectuant un ping (ICMP). Et enfin, il va effectuer un ping UDP applicatif (de type requête DNS, RPC, ...).
2. Nessus va scanner les ports des machines vivantes avec un des quatre scanners de port interne, ou externe comme nmap. En sachant que Nessus est optimisé s'il utilise ses scanners de port maison. Il est donc déconseillé d'utiliser nmap pour des raisons de performances.
3. Selon la configuration de l'utilisateur, Nessus effectue un scan local ou distant.
4. Nessus envoie ses attaques de manière progressive. Il va utiliser sa base de connaissance pour appliquer les bonnes failles de sécurité aux bons services et aux bonnes versions. Grâce à ses plugins, le serveur Nessus va générer des attaques de plus en plus agressives contre les machines visées. Cela peut aller du simple test de version de logiciel jusqu’à des attaques de type DDoS comme par exemple « SYN flooding »

# Number of plugins that will run against each host,
# i.e. simultaneous tests
# Total number of processes will be max_checks x max_hosts
max_checks = 15

# Maximum number of hosts
max_hosts = 255

Inconvénients

Le scan distant a pour inconvénient de générer des faux positifs. C'est-à-dire que Nessus peut détecter une faille de sécurité par exemple, sur un service obsolète, alors qu'un patch de sécurité est appliqué sur la machine locale pour corriger les bugs de cette version. C'est le scan local qui vient corriger ce problème de faux positif.

Il y a un deuxième inconvénient sur ce genre de scan : la surcharge du réseau. Par exemple, dans le cas où l'on scanne un réseau entier et que le serveur Nessus ne se trouve pas dans ce réseau, les requêtes envoyées par Nessus peuvent saturer la table de translation de firewall intermédiaire.

En plus, toutes les adresses IP du réseau ne sont pas forcément utilisées. Nessus peut donc envoyer des requêtes à travers le réseau qui n'aboutiront jamais. La détection des machines vivantes est donc nécessaire mais ne rend pas le scan optimal dans ce cas là.

Ce type de scan permet de tester tout ce qui n'est pas testable par le scan distant sans avoir à se soucier des faux positif. Parmi ces tests, on retrouve :

• des mots de passe par défaut ou de faible complexités,
• des fautes de configurations de logiciels,
• des versions de dll ou de package obsolète,
• des services désactivés et vulnérables.

Un utilisateur Nessus qui souhaite uniquement déterminer si ses machines sont à jour, exécutera un scan local. Ce scan local est extrêmement rapide, (environ 6 secondes pour déterminer les mises à jour en local contre une minute environ avec le scan distant).

Inconvénients

Pour le moment, Nessus ne permet pas de vérifier les stratégies de sécurité locales des systèmes distants. Tenable Network Security prévoit néanmoins d'implémenter cette fonctionnalité dans un script NASL

Pour effectuer ses tests, Nessus lance de réelles attaques contre les machines cibles. En d'autres termes, avec ses scans locaux, Nessus peut facilement effectuer un déni de service. Il est donc prudent de prévenir cette attaque soit, en effectuant le scan sur une plage horaire où la machine cible ne craint pas de perte de données soit, en spécifiant dans les fichiers de configuration que l'on souhaite effectuer, un scan safecheck.

De plus, certains IDS (comme snort) peuvent détecter les scans de Nessus comme étant une attaque de hacker. Il faut donc également penser à configurer correctement son IDS.

Par exemple, la description du plugin php_split_mime.nasl permet au responsable sécurité, de déterminer la procédure pour corriger la vulnérabilité :

desc["english"] = "
Synopsis :

Arbitrary code may be run on the remote server.

Description :

The remote host is running a version of PHP earlier than 4.1.2.

There are several flaws in how PHP handles multipart/form-data POST 
requests, any one of which can allow an attacker to gain remote access
to the system.

Solution : 

Upgrade to PHP 4.1.2

Risk factor :

High / CVSS Base Score : 7.5
(CVSS2#AV:N/AC:L/Au:N/C:P/I:P/A:P)";

Nessus peut générer des rapports sous différents formats :

• HTML simple et HTML avec graphe,
• XML,
• LaTEX,
• NSR,
• NBE,
• TXT.

Par défaut, Nessus génère un rapport au format NBE(Nessus Back End report). Les fichiers NBE sont des fichiers dont les informations sont séparées par des '|'.

Voici un exemple de fichier NBE :

timestamps|||scan_start|Wed Oct 21 18:05:26 2009|
timestamps||192.168.0.2|host_start|Wed Oct 21 18:05:31 2009|
results|192.168.0|192.168.0.2|general/tcp|10180|Security Note|The remote host is up\n
results|192.168.0|192.168.0.2|general/icmp|10114|Security Warning|\nThe remote host answers to an ICMP timestamp request. This allows an attacker \nto know the date which is set on your machine. \n\nThis may help him to defeat all your time based authentication protocols.\n\nSolution : filter out the ICMP timestamp requests (13), and the outgoing ICMP \ntimestamp replies (14).\n\nRisk factor : Low\nCVE : CAN-1999-0524\n
results|192.168.0|192.168.0.2|general/udp|10287|Security Note|For your information, here is the traceroute to 192.168.0.2 : \n192.168.0.11\n192.168.0.2\n\n
results|192.168.0|192.168.0.2|general/tcp|19506|Security Note|Information about this scan : \n\nNessus version : 2.2.10\nPlugin feed version : 200704181215\nType of plugin feed : GPL only\nScanner IP : 192.168.0.11\nPort scanner(s) : synscan nessus_tcp_scanner \nPort range : 1-15000\nThorough tests : no\nExperimental tests : no\nParanoia level : 1\nReport Verbosity : 1\nSafe checks : yes\nMax hosts : 20\nMax checks : 4\nScan duration : unknown (ping_host.nasl not launched?)\n\n
results|192.168.0|192.168.0.2|general/tcp|9999|Security Hole|\nYou are running a version of Nessus which is not configured to receive\na full plugin feed. As a result, the security audit of the remote host produced\nincomplete results.\n\nTo obtain a complete plugin feed, you need to register your Nessus scanner\nat http://www.nessus.org/register/ then run nessus-update-plugins to get\nthe full list of Nessus plugins.\n\n
timestamps||192.168.0.2|host_end|Wed Oct 21 18:07:53 2009|
timestamps|||scan_end|Wed Oct 21 18:07:53 2009|

La première information représente un flag :

• Pour le flag timestamp; la ligne correspondante nous donne des indications temporelles sur le scan. Par exemple, ici on sait que le scan a commencé le 21 octobre 2009 à 18:05:26 et qu'il a fini le 21 octobre 2009 à 18:07:53. Pendant ce scan, on sait que la machine possédant l'adresse IP 192.168.0.2 a été scannée entre 18:05:31 et 18:07:53.
• Pour le flag result; la ligne correspondante nous décrit le résultat d'un test de sécurité. Entre autres, on peut connaître le sous réseau de la machine, son nom ou adresse IP, le protocole de communication utilisé et le type de vulnérabilité. Ce qui est surtout intéressant, c'est la description de chaque vulnérabilité. C'est cette description qui sera utilisée par le responsable sécurité d'une entreprise pour corriger la vulnérabilité.

On peut spécifier, au serveur Nessus, une liste d'adresse IP pour que les clients Nessus ne scannent pas les adresses ou les plugins contenus dans cette liste. Ce filtre est accessible dans le fichier /etc/nessus/nessusd.rules :

#
# Nessus rules
#

# Syntax : accept|reject address/netmask

reject 192.168.0.1
reject 192.168.0.2

# On peut aussi autoriser / refuser certains ports : 
# Refus de la connexion au port 80 pour la machine 10.0.0.1
reject 10.0.0.1:80
# Refus de la connexion aux ports entre 8000 et 10000 pour toutes les machines dans le réseau 192.168.0.254/24 : 
reject 192.168.0.0/24:8000-10000

# On peut également autoriser / refuser l'utilisation de certains plugins(ID) : 
plugin-reject 10335
plugin-accept 10000-40000
	 
# Accept to test anything :
default accept
				

Pour éviter que les scans locaux ne viennent effectuer des attaques DoS sur les machines cibles, Tenable Network Security a mis en place une configuration Safe checks(valeur booléenne) disponible à /etc/nessusd/nessusd.conf sur le serveur. Cette option va forcer le serveur Nessus à reconnaître les services uniquement sur les bannières de bienvenue signalées par les hôtes cibles au lieu d'essayer de reconnaître l'empreinte du service. De plus, cette option va désactiver tous les plugins qui peuvent effectuer des buffers overflow sur les hôtes cibles.

Configuration du serveur pour effectuer des scans locaux

Pour que le serveur puisse effectuer des tests locaux sur les machines cibles, il faut qu'il puisse s'y connecter localement. Dans Nessus, plusieurs types de connexion sont proposées (configurable dans la section PLUGINS_PREFS du fichier ~/.nessusrc sur le client) :

SNMP settings[entry]:SNMPv3 user name : = 
SNMP settings[password]:SNMPv3 authentication password : = 
SNMP settings[password]:SNMPv3 privacy password : = 
# Pour telnet, rsh, rexec : 
Cleartext protocols settings[entry]:User name : = 
Cleartext protocols settings[password]:Password (unsafe!) : = 
SSH settings[entry]:SSH user name : = root
SSH settings[radio]:Elevate privileges with : = Nothing;sudo;su
SSH settings[entry]:Preferred SSH port : = 22
SSH settings[password]:SSH password (unsafe!) : = 
SSH settings[file]:SSH public key to use : = 
SSH settings[file]:SSH private key to use : = 
SSH settings[password]:Passphrase for SSH key : = 
SSH settings[password]:su/sudo password : = 
SSH settings[file]:SSH known_hosts file : = 
SSH settings[entry]:Client version : = OpenSSH_5.0
Kerberos configuration[entry]:Kerberos Key Distribution Center (KDC) : = 
Kerberos configuration[entry]:Kerberos Realm (SSH only) : = 
Services[file]:SSL certificate : = 
Services[file]:SSL private key : = 
Services[password]:PEM password : = 
Services[file]:CA file : = 
Database settings[entry]:Login : = 
Database settings[password]:Password : = 
Database settings[entry]:Database SID : = 
Database settings[entry]:Database port to use : = 
Login configurations[entry]:HTTP account : = 
Login configurations[password]:HTTP password (sent in clear) : = 
Login configurations[entry]:NNTP account : = 
Login configurations[password]:NNTP password (sent in clear) : = 
Login configurations[entry]:POP2 account : = 
Login configurations[password]:POP2 password (sent in clear) : = 
Login configurations[entry]:POP3 account : = 
Login configurations[password]:POP3 password (sent in clear) : = 
Login configurations[entry]:IMAP account : = 
Login configurations[password]:IMAP password (sent in clear) : = 
Login configurations[entry]:SMB account : = admin
Login configurations[password]:SMB password : = password
Login configurations[entry]:SMB domain (optional) : = 
Login configurations[entry]:SNMP community (sent in clear) : = 
SLAD Init[file]:slad SSH public key: = 
SLAD Init[file]:slad SSH private key: = 
SLAD Init[password]:slad SSH key passphrase: = 
Global variable settings[checkbox]:Do not log in with user accounts not specified in the policy = no
Global variable settings[file]:SSL certificate to use : = 
Global variable settings[file]:SSL CA to trust : = 
Global variable settings[file]:SSL key to use : = 
Global variable settings[password]:SSL password for SSL key : = 

Certaines connexions comme l'accès aux bases de données ou encore aux serveurs web sont configurées pour tenter des attaques par injections de code. D'autres connexions sont établies (avec une authentification en claire : login + mot de passe) dans le but de rechercher les fautes de configuration (comme samba, snmp, nntp, pop2, pop3, imap). Enfin, pour se connecter aux systèmes d'exploitation, plusieurs méthodes d'authentification sont proposées par Nessus :

• telnet : à proscrire car l'authentification transite en clair sur le réseau,
• SSH avec login + mot de passe : à proscrire car sensible aux attaques par dictionnaire de type brute force et l'inscription du login et du mot de passe (d'un compte utilisateur aux droits root) sont en clair dans le fichier de configuration,
• SSH avec clé privée + publique : à conseiller, méthode d'authentification fortement sécurisée ayant déjà fait ses preuves,
• NTML et NTMLv2 pour l'authentification sous Windows,
• Kerberos : méthode permettant l'authentification d'utilisateurs sur des systèmes Windows et Linux dans un réseau (nécessite une architecture spécifique).

Pour sécuriser la connexion entre client/serveur, le serveur doit générer un certificat à l'aide de nessus-mkcert. Grâce à SSL la communication entre client/serveur est sécurisée (permet d'éviter une attaque de type Man In the Middle).

# End of /etc/nessus/nessusd.conf file.
#
# Added by nessus-mkcert
#
# If you decide to protect your private key with a password, 
# uncomment and change next line
 pem_password=password
# If you want to force the use of a client certificate, uncomment next line
 force_pubkey_auth = yes
#
# Added by nessus-mkcert
#
cert_file=/var/lib/nessus/CA/servercert.pem
key_file=/var/lib/nessus/private/CA/serverkey.pem
ca_file=/var/lib/nessus/CA/cacert.pem