Gérer les données de sortie de Nmap

I. Présentation

Dans ce chapitre, nous allons nous intéresser à la sortie produite par Nmap et notamment les différentes options de formatage de cette sortie. Nous verrons que Nmap peut produire plusieurs formats de sortie afin de répondre à des besoins différents, et qu’il s’agit là aussi d’une des grandes forces de cet outil.

Nmap offre par défaut une vue détaillée des résultats des scans et tests qu'il effectue. Cela inclut les hôtes et services scannés, ceux qui sont détectés comme accessibles, les spécificités des ports ouverts, leur état et leur version. De plus, les détails des scripts NSE sont également disponibles dans la sortie du terminal. Cependant, cette sortie peut devenir rapidement volumineuse, même avec un formatage clair des informations, ce qui peut rendre difficile la recherche d’informations précises dans les résultats.

II. Maîtriser les formats de sortie de Nmap

A. Enregistrer le résultat d’un scan dans un fichier texte

Pour nous faciliter la tâche, Nmap nous permet très facilement d’enregistrer sa sortie dans un fichier texte. Cela peut être utile pour de l’archivage, une comparaison avec d’autres tests, mais aussi pour parcourir cette sortie avec des outils de traitement de texte spécialisés ou des langages de scripting, je pense notamment à Sublime text, PowerShell, Python, grep, sed, etc. Pour stocker la sortie standard de Nmap dans un fichier texte, nous pouvons utiliser l’option “-oN <nom du fichier>” (le “N” de “normal”) :

# Enregistrer la sortie Nmap dans un fichier
nmap 10.10.10.0/24 -sV -oN nmap_scan_10.10.10.0_24.txt

Dès lors, pas de surprise, Nmap affichera une sortie standard comme à son habitude dans notre terminal, mais également dans le fichier indiqué.

B. Générer une sortie Nmap dans un format condensé

Il existe également un second format de sortie dans le style “texte” et interprétable facilement par un humain : le format “greppable”.

Ce format a été créé afin de fournir une vue “condensée” de la sortie Nmap, notamment structurée de manière à faciliter son traitement par des outils comme “grep”. Voyons un exemple de ce type de résultat :

Ici, j’ai réalisé une découverte réseau ainsi qu’un scan de port et une analyse des technologies et versions sur un réseau en /24, puis j’ai stocké la sortie dans un fichier au format “greppable”. Je me retrouve avec un fichier contenant 2 lignes par hôte actif :

• Une première ligne pour m’indiquer que tel hôte est Up;
• Une seconde ligne pour m’indiquer les ports scannés, leur statut et les informations de technologies et versions récupérées dans un format bien particulier : “<port>/<status/<protocol>//<service>//<version>/,”

Ce formatage à l’aide d’un délimiteur fixe permet un traitement rapide par des outils de traitement de texte tels que “grep”, ou des langages de scripting et programmation. La commande suivante me permet par exemple de retrouver facilement les informations de l’hôte “10.10.10.5” dans le cas d’un énorme scan réalisé par Nmap et dont la sortie serait difficile à parcourir :

# Filtre sur une adresse IP au sein du fichier "greppable" de Nmap
$ grep '10.10.10.5' nmap_10.10.10.0.gnmap
Host: 10.10.10.5 () Status: Up
Host: 10.10.10.5 () Ports: 21/open/tcp//ftp//Microsoft ftpd/, 80/open/tcp//http//Microsoft IIS httpd 7.5/ Ignored State: filtered (998)

À l’inverse, je peux aussi facilement lister tous les hôtes qui ont un port 21 d’ouvert, car ports et IP sont sur la même ligne :

# Filtre sur un port ouvert au sein du fichier "greppable" de Nmap
$ grep '21/open' nmap_10.10.10.0.gnmap
Host: 10.10.10.5 () Ports: 21/open/tcp//ftp//Microsoft ftpd/, 80/open/tcp//http//Microsoft IIS httpd 7.5/ Ignored State: filtered (998)

Host: 10.10.10.152 () Ports: 21/open/tcp//ftp//Microsoft ftpd/, 80/open/tcp//http//Indy httpd 18.1.37.13946 (Paessler PRTG bandwidth monitor)/, 135/open/tcp//msrpc//Microsoft Windows RPC/, 139/open/tcp//netbios-ssn//Microsoft Windows netbios-ssn/, 445/open/tcp//microsoft-ds//Microsoft Windows Server 2008 R2 - 2012 microsoft-ds/ Ignored State: closed (995)

Pour générer une telle sortie, nous devons utiliser l’option “-oG <nom du fichier>.gnmap” (le “G” de “grep”). Par habitude, j’utilise ici l’extension “.gnmap” pour un tel fichier, mais libre à vous d’utiliser celle que vous souhaitez :

# Enregistrer la sortie Nmap dans un fichier au format “greppable”
nmap 10.10.10.0/24 -sV -oG nmap_scan_10.10.10.0_24.gnmap

Ce format peut répondre à plusieurs besoins et est plutôt pratique pour du scripting/tri rapide. Néanmoins, il tend à être délaissé au profit du format que nous allons voir juste après.

C. Le format XML des sorties Nmap

Le dernier format qui mérite d’être mentionné dans ce cours est le format XML. Au contraire des deux formats précédents, celui-ci n’est pas fait pour être lu par des humains, mais par d’autres outils ou des scripts.

Le format XML (eXtensible Markup Language) est un langage de balisage utilisé pour stocker et transporter des données, offrant une structure hiérarchique via des balises personnalisées.

Dans le cadre de Nmap, le format XML est utilisé pour générer des rapports détaillés sur les analyses et scans effectués, incluant des informations sur les hôtes, les ports et les vulnérabilités détectées, mais aussi des informations additionnelles qui ne sont pas affichées dans la sortie standard de Nmap.

Pour générer un fichier de sortie au format XML, nous devons utiliser l’option “-oX” (“O” de “XML”) :

# Enregistrer la sortie Nmap dans un fichier au format XML
nmap 10.10.10.0/24 -sV -oX nmap_scan_10.10.10.0_24.xml

Vous trouverez alors en résultat la sortie standard de Nmap dans votre terminal, ainsi qu’un fichier au format XML dans votre répertoire courant.

Le format XML n’est bien sûr pas fait pour être lu et interprété par un humain. Néanmoins, si vous souhaitez faire du scripting ou de l’analyse automatisée sur ce format de la sortie Nmap, il faut quand même avoir une idée des balises et de la structure utilisée. Par exemple, voici une partie du contenu du fichier XML créé par Nmap, il expose les résultats du scan pour 1 hôte :

Nous voyons ici beaucoup d’informations, nous pouvons notamment nous intéresser aux deux ports ouverts :

<port protocol="tcp" portid="21"><state state="open" reason="syn-ack" reason_ttl="0"/><service name="ftp" product="Microsoft ftpd" ostype="Windows" method="probed" conf="10"><cpe>cpe:/a:microsoft:ftp_service</cpe><cpe>cpe:/o:microsoft:windows</cpe></service></port>
<port protocol="tcp" portid="80"><state state="open" reason="syn-ack" reason_ttl="0"/><service name="http" product="Microsoft IIS httpd" version="7.5" ostype="Windows" method="probed" conf="10"><cpe>cpe:/a:microsoft:internet_information_services:7.5</cpe><cpe>cpe:/o:microsoft:windows</cpe></service></port>

Nous comprenons bien que ce format va nous faciliter le parsing automatisé des résultats, chaque information est bien rangée dans une balise ou un attribut dédié et nommé. Nous retrouvons notamment une information que nous n’avons pas croisée jusqu’ici : le CPE.

cpe>cpe:/a:microsoft:internet_information_services:7.5</cpe><cpe>cpe:/o:microsoft:windows</cpe></service></port>
<cpe>cpe:/a:microsoft:internet_information_services:7.5</cpe><cpe>cpe:/o:microsoft:windows</cpe></service></port>

Nous avons rapidement mentionné le CPE dans le chapitre 2 du module 2, cette information est notamment déterminée dans les matches lors de la détection de version. Nmap se sert de ses mécanismes de détection de services, de technologies et de versions afin de retrouver le CPE associé.

Cela nous permet par la suite de réutiliser cette information avec les bases de données et applications qui l’utilisent. Je pense notamment à la base NVD qui référence les CVE. Elle contient, pour chaque CVE, les CPE concernés par la vulnérabilité. Voici un exemple de CVE concernant le “a:microsoft:internet_information_services:7.5” venant de la base NVD :

Nous comprenons à présent mieux l’intérêt de ce format, il propose une structure très claire des informations et contient toutes les données récoltées ou traitées par Nmap.

Par réflexe, j’effectue systématiquement un enregistrement de mes scans Nmap dans les trois formats d’un seul coup. Cela est possible grâce à l’option “-oA <nom>” (“A” pour “All”), qui créera un fichier “<nom>.nmap”, un fichier “<nom>.xml” et un fichier “<nom>.gnmap”. Ainsi je suis sûr de ne manquer de rien quand il faudra revenir sur les résultats.

Avec ces trois formats, vous devriez avoir tout ce qu’il faut pour enregistrer, puis éventuellement traiter de façon automatisée les résultats de Nmap. Nous réutiliserons notamment le format XML dans le chapitre suivant, quand nous aborderons l’utilisation de Nmap avec d’autres outils de sécurité.

III. Générer un rapport HTML d’un scan Nmap

Le format XML offre de nombreuses possibilités, notamment celle de servir de base à la génération d’un rapport au format HTML, qui sera visuellement plus agréable à parcourir.

Pour transformer un fichier Nmap au format XML en page web, nous allons utiliser l’outil “xsltproc”, qu’il nous faudra au préalable installer :

# Installation de l’outil xsltproc
sudo apt install xsltproc

Une fois cet outil installé, il suffit de lui fournir en entrée le fichier XML à convertir, ainsi que le nom du rapport HTML à générer :

# Création d’un rapport Nmap HTML à partir du format XML
xsltproc nmap_10.10.10.0.xml -o “Nmap – rapport web 05-2024.html”

# Ouverture du fichier .html avec Firefox
firefox “Nmap – rapport web 05-2024.html”

En résultat, nous aurons l’intégralité de notre scan joliment structuré, avec même quelques couleurs et des liens cliquables dans le sommaire !

Dans les grandes lignes, il faut savoir que le fichier XML enregistré par Nmap contient une référence vers un autre fichier, au format XSL :

<?xml-stylesheet href="/usr/share/nmap/nmap.xsl" type="text/xsl"?>

La conversion en HTML est donc une fonction prévue et facilitée par Nmap, “xsltproc” étant un outil commun et reconnu pour effectuer cette tâche (qui ne provient pas de la suite d’outil Nmap).

Le langage XSLT (Extensible Stylesheet Language Transformations) est un sous-ensemble du langage XSL qui permet d’afficher des données XML sur une page web et de les « transformer », parallèlement aux styles XSL, en informations lisibles et mises en forme au format HTML.

Source : https://helpx.adobe.com/fr/dreamweaver/using/xml-xslt.html

Le niveau d’information du rapport est équivalent à celui du format XML de Nmap et supérieur à celui de la sortie standard dans le terminal (interactive output).

IV. Gérer le niveau de verbosité de Nmap

Nous allons à présent passer en revue quelques options qui vous permettront de debugger Nmap ou d’obtenir un suivi précis de son avancement.

La première option que l’on peut mentionner est l’option “-v”, qui permet d’augmenter la verbosité de Nmap, voici un exemple :

Sur un scan ciblant de nombreux hôtes et ports, la sortie terminal deviendra difficile à exploiter en raison du nombre d’informations affichées. C’est pourquoi il convient d’utiliser cette option en combinaison avec les options vues précédemment qui permettent de stocker la sortie standard de Nmap dans un fichier. Les informations liées à l’utilisation de la verbosité ne seront pas incluses dans ce fichier de sortie. Comme vous le voyez dans l’exemple ci-dessus, cette verbosité permet d’avoir un suivi assez clair et en direct des actions et découvertes de Nmap. Pour des scans assez longs où l’affichage des données peut tarder à venir, cela évite d’être à l’aveugle sur l’activité actuelle de Nmap et de savoir que les choses avancent et à quel rythme. Pour augmenter la verbosité d’un niveau supplémentaire, il est possible d’utiliser l’option “-vv”.

Pour aller plus loin sur le suivi de l’activité de Nmap pendant son scan, il est possible d’utiliser l’option “--packet-trace”. Avec l’option “-v”, nous obtenons en live les ports ouverts découverts par Nmap alors qu’avec cette option, nous aurons une ligne de log pour chaque paquet envoyé sur un port. Cela produit naturellement une sortie très verbeuse, mais permet un suivi détaillé de l’activité de Nmap, voici un exemple :

À nouveau, ces informations ne seront pas enregistrées dans le fichier de sortie produit par Nmap si l’on utilise les options “-oN”, “-oG”, “-oX” ou “-oA”.

Enfin, Nmap dispose également de deux options de debug qui sont “-d” et “-dd”. Ces options ont un comportement similaire à l’option de verbosité “-v”, mais ajoutent des informations techniques supplémentaires, comme une synthèse des paramètres techniques en début de scan :

Nous verrons notamment dans les prochains chapitres ce que sont les options de “Timing” et pourquoi il est intéressant de les connaître.

Enfin, pour avoir uniquement un suivi basique et synthétique de l’avancée du scan Nmap, nous pouvons utiliser l’option “--stats-every 5s”, le “5s” signifie ici 5 secondes et peut être modifié en fonction de vos besoins. Il s’agit de la fréquence à laquelle nous aurons un retour de Nmap sur son avancement :

Nous pouvons notamment avoir un pourcentage d’avancée, ainsi qu’une indication de la phase à laquelle il se trouve : phase de découverte d’hôte via ping, phase de découverte des ports TCP exposés, etc. Ces informations peuvent également être obtenues dans la sortie terminal en appuyant sur “Entrée” pendant un scan.

Cependant, il faut savoir que Nmap n’est pas très bon pour estimer le temps que va lui prendre une tâche, notamment parce qu’il ne sait pas à l’avance le nombre d’hôtes et de services qu’il va avoir à scanner.

V. Conclusion

Dans ce chapitre, nous avons vu plusieurs options qui nous permettent d’enregistrer les résultats d’un scan Nmap dans différents formats de fichier. Cela vous sera très utile, car dans des contextes réalistes, les résultats de scan peuvent occuper plusieurs centaines, voire milliers de lignes ! Nous avons également vu comment augmenter le niveau de verbosité des Nmap dans le cadre du debug ou pour obtenir un étant d’avancement du scan.

D’ailleurs, le format XML nous sera particulièrement utile pour le prochain chapitre dans lequel nous aborderons quelques outils capables de travailler sur les résultats de Nmap.