L'option -f force le scan demandé (y compris les scans de type ping) à utiliser des paquets IP fragmentés en petits paquets. L'idée est de partager l'en-tête TCP en plusieurs paquets pour rendre plus difficile la détection de ce que vous faites par les dispositifs de filtrage de paquets, les systèmes de détection et d'intrusion et autres systèmes ennuyeux. Il faudra cependant faire attention ! Certains programmes ont du mal à gérer ces petits paquets. Les anciens sniffers comme Sniffit souffraient d'erreurs de segmentation immédiatement après avoir reçu le premier fragment. Spécifiez cette option une fois, et Nmap partage les paquets en 8 bytes ou moins après l'en-tête IP. Par exemple, un en-tête de 20 bytes sera fragmenté en 3 paquets. Deux avec 8 bytes d'en-tête TCP et un avec les 4 derniers. Bien entendu, chaque paquet a son en-tête IP. Spécifiez encore -f pour utiliser 16 bytes par fragment (ceci réduit le nombre de fragments). Vous pouvez aussi spécifier votre propre taille d'offset avec l'option --mtu. Par contre, ne spécifiez pas -f si vous utilisez --mtu. L'offset doit être un multiple de 8. Bien que les paquets fragmentés ne tromperont pas les filtrages de paquets et les pare-feux, tenant compte de tous les fragments IP, comme l'option CONFIG_IP_ALWAYS_DEFRAG dans le noyau Linux, certains réseaux ne peuvent supporter la perte de performance que cela entraîne et de ce fait laisse ceci désactivé. D'autres ne peuvent pas l'activer parce que les fragments peuvent prendre différentes routes au sein de leur réseau. Certains systèmes source défragmentent les paquets sortant dans le noyau. Linux, avec le module de connection « tracking iptables » est un très bon exemple. Faites donc ce genre de scan avec un sniffer comme Ethereal tournant en même temps afin de vous assurer que les paquets envoyés sont bien fragmentés. Si votre système d'exploitation causait des problèmes, essayez l'option --send-eth pour contourner la couche IP et envoyer des trames en raw Ethernet.

Engendrez un scan avec des leurres, ce qui fait croire à l'hôte distant que les hôtes que vous avez spécifié exécutent eux aussi un scan contre lui. Un IDS fera état d'un scan de 5 à 10 ports depuis des adresses IP différentes, dont la vôtre, sans pouvoir faire la différence entre les leurres et la véritable origine. Bien que ceci puisse être repéré par la tracabilité des routeurs, le renvoi de réponses (response-dropping), et d'autres mécanismes actifs, ceci reste une technique généralement efficace pour cacher votre adresse IP.

Séparez chaque leure par une virgule et vous pourrez utiliser de façon facultative ME en tant que l'un des leurres pour représenter la position de votre véritable adresse IP. Si vous mettez ME en sixième position ou après, certains systèmes de détection de scans de ports (comme l'excellent scanlogd de Solar Designer) sont incapables de voir votre adresse IP. Si vous n'utilisez pas ME, Nmap vous placera à une position aléatoire.

Notez que les hôtes que vous utilisez comme leurres devraient être réellement actifs; sinon, vous risquez d'inonder votre cible par des SYN. Sans compter qu'il serait très facile de déterminer quel hôte est en train de scanner si en fait un seul est actif sur le réseau. Vous pourriez utiliser des adresses IP plutôt que des noms afin de ne pas apparaître dans les logs des serveurs de nom du réseau.

Les leurres sont utilisés autant dans la phase initiale de scan ping (utilisant les ICMP, SYN, ACK, ou quoi que ce soit) que dans la phase proprement dite de scan de ports. Les leurres sont aussi utilisés pendant la détection d'OS distant (-O). Les leurres ne fonctionnent pas avec la détection de version ou un scan de type TCP connect().

Il est inutile d'utiliser trop de leurres car cela pourrait ralentir votre scan et potentiellement le rendre moins précis. Enfin, certains FAI peuvent filtrer vos paquets usurpés (spoofés) toutefois beaucoup ne le font pas du tout.

Dans certaines circonstances, Nmap n'est pas capable de déterminer votre adresse source ( Nmap vous avisera le cas échéant). Dans cette situation, utilisez -S avec l'adresse IP de l'interface avec laquelle vous souhaitez envoyer les paquets.

Un autre usage possible de ce drapeau est d'usurper (spoofer) le scan afin de faire croire à la cible que quelqu'un d'autre est en train de les scanner. Imaginez une compagnie constamment scannée pas un concurrent ! L'option -e est généralement requise pour ce genre d'usage et -P0 est à conseiller quoi qu'il en soit.

Avise Nmap sur quelle interface envoyer et recevoir les paquets. Nmap devrait pouvoir la détecter automatiquement mais il vous le dira si ce n'est pas le cas.

L'une des erreurs de configuration les plus surprenantes est de faire confiance au trafic sur la base du port d'où il provient. Il est facile de comprendre pourquoi une telle situation se produit. Un administrateur va régler un tout nouveau pare-feu et être noyé sous les plaintes des utilisateurs dont les applications ne fonctionnent plus. En particulier, les DNS peuvent être cassés parce que les réponses UDP DNS depuis les serveurs externes ne peuvent plus entrer sur le réseau. Le FTP est un autre exemple. Dans les transferts actifs en FTP, le serveur distant essaie d'établir une connexion en retour vers le client afin de transférer le fichier demandé.

La solution sécurisée pour ce problème existe, souvent sous la forme de proxies applicatifs ou de modules de filtrage de protocoles au niveau du pare-feu. Malheureusement, il existe aussi des solutions faciles non sécurisées. En remarquant que les réponses DNS viennent du port 53 et le FTP actif du port 20, beaucoup d'administrateurs sont tombés dans le piège de seulement permettre le trafic entrant depuis ces ports. Ils imaginent souvent qu'aucun attaquant n'aura noté et pensé exploiter de telles failles de pare-feux. Dans d'autres cas, l'administrateur va considérer que c'est une solution à court terme jusqu'à ce qu'il implémente une solution plus sécurisée. Ils oublient par la suite d'effectuer la mise à jour de sécurité.

Les administrateurs de réseau surchargés de travail ne sont pas les seuls à tomber dans ce piège. Beaucoup de produits sont pensés avec ce genre de règle mal sécurisée. Même Microsoft en a été coupable. Les filtres IPsec, fournis avec Windows 2000 et Windows XP, contiennent une règle implicite qui autorise tout trafic depuis le port 88 (Kerberos) en TCP ou UDP. Dans un autre cas bien connu, les versions du pare-feu Zone Alarm personal firewall jusqu'à 2.1.25 permettaient tout paquet UDP provenant du port 53 (DNS) ou 67 (DHCP).

Nmap propose les options -g et --source-port qui sont équivalentes pour exploiter ces faiblesses. Fournissez simplement un numéro de port et Nmap enverra les paquets depuis ce port si possible. Nmap doit utiliser certains numéros de port afin que certains tests de détection d'OS fonctionnent correctement. De plus, les requêtes DNS ignorent le drapeau --source-port parce que Nmap se fonde sur un système de bibliothèques pour les traiter. La plupart des scans TCP, y compris le SYN scan, supportent entièrement l'option comme le fait aussi le scan UDP.

Normalement, Nmap envoie des paquets minimalistes contenant seulement un en-tête. Donc ces paquets TCP ne font généralement que 40 bytes et les ICMP echo request seulement 28 bytes. Cette option indique à Nmap d'ajouter le nombre donné de bytes aléatoires à la plupart des paquets qu'il envoie. Les paquets de la détection d'OS (-O) ne sont pas affectés, contrairement à la plupart des paquets de ping et de scan de port. Cette procédure ralentit bien entendu les choses mais permet toutefois de faire passer un scan pour un peu moins suspect.

Le protocole IP offre plusieurs options pouvant être placées dans l'entête des paquets. Contrairement aux options TCP habituelles, les options IP sont rarement rencontrées pour des raisons pratiques et de sécurité. En fait, beaucoup de routeurs Internet bloquent les options les plus dangereuses comme le routage de source. CEpendant les options peuvent s'avérer utiles dans certains cases for determining and manipulating the network route to cas de machines cibles. Par exemple vous pouvez être en mesure d'utiliser l'enregistrement de routage pour déterminer un chemin vers une cible quand bien même une approche plus traditionnelle de Traceroute échouerait. Ou si vos paquets sont rejettés par un pare-feu, vous pouvez spécifier une autre route avec des options plus ou moins vagues de routage.

La facon la plus puissante de spécifier ces options IP est simplement de passer ces valeurs en argument à --ip-options. Faites précéder chaque nombre héxadécimal par \x puis les deux chiffres. Vous pouvez répèter certains charactères en les séparant par un asterisk suivit du nombre de répétions. Par exemple, \x01\x07\x04\x00*36\x01 est une chaine héxa contenant 36 NUL bytes.

Nmap propose aussi un mechanisme de raccourcis pour spécifier ces options. Donnez simplement la lettre R, T, ou U pour demander l'enregistrement de routage, de timestamp, ou les deux simultanement, respectivement. Un routage strict ou plus vague peut être spécifié avec un L ou un S suivit d'un espace et d'une liste séparée d'espaces d'adresses IP.

Si vous souhaitez voir les options dans les paquets envoyés et recus, spécifiez --packet-trace. Pour plus d'information et d'exemples de l'utilisation des options IP avec Nmap, voir http://seclists.org/nmap-dev/2006/q3/0052.html.

Demande a Nmap d'utiliser une somme de contrôle TCP ou UDP erronnée pour les paquets envoyés aux hôtes cibles. Comme virtuellement toutes les piles IP des hôtes rejettent ces paquets, toute réponse recue doivent venir d'un pare-feu ou d'un IDS qui ne se préoccuppe pas de vérifier les sommes de contrôle. Pour plus de détails sur cette technique, voir http://www.phrack.org/phrack/60/p60-0x0c.txt

Règle le champ IPv4 du time-to-live dans les paquets envoyés à la valeur donnée.

Indique à Nmap de mélanger tous les groupes contenant jusqu'à 8 096 hôtes avant de les scanner. Ceci peut rendre les scans moins évidents pour de nombreux systèmes de surveillance réseau, spécialement si vous le combinez à des options de délai lentes. Si vous souhaitez mélanger des groupes de taille plus importante, augmentez la valeur PING_GROUP_SZ dans nmap.h et recompilez. Une autre solution serait de générer la liste des IP cibles avec un scan de listage (list scan, -sL -n -oN <filename> ), le mélanger à l'aide d'un script Perl, puis fournir la liste complète à Nmap avec -iL.

Demande à Nmap d'utiliser l'adresse MAC spécifiée pour l'ensemble des trames en raw Ethernet qu'il envoie. Cette option implique --send-eth pour s'assurer que Nmap envoie vraiment des paquets au niveau Ethernet. Le MAC donné peut prendre plusieurs formes. S'il s'agit seulement de la chaîne “0”, Nmap choisit une adresse MAC totalement aléatoire pour la session. Si la chaîne est un nombre hexadécimal (avec les paires de nombres éventuellement séparées par les deux points), Nmap utilisera ceci comme adresse MAC. Si moins de 12 chiffres sont spécifiés, Nmap remplit le reste avec des valeurs aléatoires. Si l'argument n'est ni 0 ni une chaîne hexadécimale, Nmap recherche dans sa base de données nmap-mac-prefixes un nom de fournisseur contenant la chaîne en question (non sensible à la casse). Si une correspondance est trouvée, Nmap utilise le numéro OUI du distributeur (un préfixe de 3 bytes) et utilise les 3 bytes restants de façon aléatoire. Des exemples de valeurs --spoof-mac valides sont Apple, 0, 01:02:03:04:05:06, deadbeefcafe, 0020F2 et Cisco.