Nmap Scripting Engine (NSE)

Le moteur de scripts de Nmap (Nmap Scripting Engine -NSE) allie l'efficacité avec laquelle Nmap traite le réseau avec la souplesse d'un langage léger comme Lua, fournissant ainsi une infinité d'opportunités. Une documentation plus complète du NSE (y compris ses API) peut être obtenue sur https://nmap.org/nse. Le but du NSE est de fournir à Nmap une infrastructure flexible afin d'étendre ses capacités et ainsi offrir à ses utilisateurs une facon simple de créer leurs propres tests personnalisés. Le cadre d'usage du NSE englobe (mais encore une fois n'est pas limité à) :

Détection de version évoluée (catégorie version) - Alors que Nmap propose déja son système de détection de Service et de Version qui est inégalé en termes d'efficacité et de couverture, cette puissance trouve sa limite lorsqu'il s'agit de services qui demandent des tests plus complexes. La version 2 du Protocole Skype par exemple peut être identifié en envoyant deux paquets de tests pour lesquels le système n'est pas prévu d'origine: un simple script NSE peut alors faire le travail et mettre ainsi à jour les informations sur le service tournant sur le port.

Détection de Malware (catégories malware et backdoor)- Que ce soit les attaquants ou les vers, ils laissent souvent des portes dérobées, par exemple sous la forme de serveurs SMTP écoutant sur des ports inhabituels, le plus souvent utilisés par les spammers pour le relais de leurs mails, ou sous forme de serveur FTP donnant des accès à des données critiques aux crackers. Quelques lignes de code Lua peut aider à identifier facilement ces pièges.

Détection de vulnérabilités (catégorie vulnerability)- Le NSE permet de détecter les risques allant par exemple des mots de passe par défaut sur Apache au test de capacité d'agir en tant que relais pour un serveur SMTP concernant les mails en provenance de domaines divers.

Découverte du Réseau et Collecte d'Informations (catégories safe, intrusive et discovery) - En vous fournissant un langage de scripts et une API réseau asynchrone vraiment efficace d'une part et la collecte d'informations durant les étapes ultérieures du scan d'autre part, le NSE est concu pour écrire des programmes clients adaptés aux services en écoute sur la machine cible. Ces clients peuvent collecter des informations comme : liste des partages NFS/SMB/RPC disponibles, le nombre de canaux d'un réseau IRC ou les utilisateurs actuellement connectés.

Afin de refléter ces différents usages et pour simplifier le choix des scripts à employer, chaque script contient un champ qui l'associe a une ou plusieurs de ces catégories. Pour maintenir le lien entre scripts et catégories un fichier appelé script.db est installé avec les scripts distribués. Ainsi si par exemple vous voulez voir si une machine est infectée par un ver Nmap vous donne un script que vous pouvez facilement utiliser par la commande nmap --script=malware ip-cible afin d'analyser les résultats après coup.Les scripts de version sont systématiquement lancés de facon implicite lorsqu'un scan de scripts est invoqué. Le fichier script.db est lui même un script Lua et peut être mis à jour via l'option --script-updatedb.

Un script NSE est simplement un code Lua qui a (parmis quelques champs d'information comme le nom, l'identifiant et la catégorie) 2 fonctions: un test dans le cas où le script en particulier doit être lancé contre une cible et un port spécifiques (appelés hostrule et portrule respectivement) et une action qui doit être menée si le test est positif. Les scripts ont acces à la plupart des informations collectées par Nmap durant les étapes précédentes. Pour chaque hôte ceci inclus l'adresse IP, le nom de l'hôte et (si disponible) le système d'exploitation. Si un script est destiné à un port en particulier, il a accès au numéro du port, son protocole (tcp, udp ou ssl), le service tournant derrière ce port et des informations optionnelles en provenance d'un scan de version. Par convention les scripts NSE ont une extension .nse. Toutefois vous n'avez pas besoin de suivre cette recommandation pour le moment, ceci pouvant changer dans l'avenir. Nmap donnera une mise en garde si un fichier a une autre extension. Une documentation plus exhaustive sur le NSE comprenant une description de son API peut être obtenue sur https://nmap.org/nse/.

-sC

effectue un scan de scripts en utilisant la catégorie de scripts par défaut. Cette option est équivalente à --script=safe,intrusive

--script <catégories|répertoire|nom|all>

Lance un scan de scripts (comme -sC) avec les scripts que vous avez choisi plutôt que ceux par défaut. Les arguments peuvent être des catégories de scripts, des scripts uniques ou des répertoires contenant des scripts qui doivent être lancés contre les hôtes cibles à la place des scripts par défaut. Nmap va essayer d'interpréter les arguments d'abord comme des catégories puis comme des noms de fichiers ou des répertoires. Les chemins absolus sont interpretés tels quels, les chemins relatifs sont recherchés dans les endroits suivants : --datadir/; $(NMAPDIR)/; ~user/nmap/ (non cherché sous Windows); NMAPDATADIR/ ou ./. A scripts/ les sous répertoires sont aussi essayés dans chacun d'eux. Donnez l'argument all pour exécuter tous les scripts de la base de données de Nmap.

Si un répertoire est précisé et trouvé, Nmap charge tous les scripts NSE (chaque fichier se terminant par .nse) dans ce répertoire. L'extension nse est obligatoire. Nmap ne fait pas de recherche récursive dans les sous répertoires éventuels pour trouver les scripts. Lorsque des noms de scripts individuels sont spécifiés, l'extension est facultative.

Les scripts de Nmap sont stockés dans un répertoire scripts du répertoire de données par défaut de Nmap. Les scripts sont indexés dans une base de données dans scripts/script.db. La base de données liste tous les scripts dans chaque catégorie. Un seul script peut être dans plusieurs catégories.

--script-args=<name1=value1,name2={name3=value3},name4=value4>

vous permet de passer des arguments aux scripts NSE. Les arguments sont passés sous la forme de paires name=value . L'arguments fourni est interprété et stocké dans une table Lua à laquelle tous les scripts ont accès. Les noms sont pris comme des chaînes (qui doivent être des valeurs alphanumériques) et utilisés comme des clés dans la table argument-table. Les valeurs sont soit des chaînes soit des tables elles mêmes (encadrées par'{' et '}'). Les sous tables permettent de supplanter les arguments pour des scripts spécifiques (c'est à dire lorsque vous souhaitez fournir différents couples login/password pour des scripts différents). Par exemple vous pouvez passer les arguments séparés par des virgules : user=bar,password=foo, and anonFTP={password=nobody@foobar.com}. Si vous souhaitez outrepasser une option d'un script, vous devriez indexer la sous table avec l'identifiant du script étant donné que c'est la seule facon qu'a le script de connaitre ses arguments particuliers.

--script-trace

Cette option fait ce que fait --packet-trace , juste une couche OSI au dessus. Si cette option est spécifiée toutes les communications entrantes et sortantes en provenance d'un script sont affichées. Les informations affichées incluent le protocole de communication, la source, la cible et les données transmises. Si plus de 5% du traffic n'est pas imprimable, alors la sortie se fait au format hexadécimal.

--script-updatedb

met à jour la base de données de scripts qui contient les correspondances des catégories avec les noms de fichiers. La base de données est un script Lua qui est interprété pour choisir les scripts en fonction des catégories passées en arguments à --script . Ceci devrait être lancé si vous avez changé le champ categories d'un script, si vous avez ajouté de nouveaux scripts ou si vous en avez retiré du répertoire scripts/ .