-sS(TCP SYN scan)

L’analyse SYN est l’option d’analyse par défaut et la plus populaire pour de bonnes raisons. Il peut être exécuté rapidement, en balayant des milliers de ports par seconde sur un réseau rapide non entravé par des pare-feu restrictifs. Il est également relativement discret et furtif puisqu’il ne termine jamais les connexions TCP. Le SYN scan fonctionne contre n’importe quelle pile TCP compatible plutôt que de dépendre des idiosyncrasies de plateformes spécifiques comme le font les scans FIN/NULL/Xmas, Maimon et idle de Nmap. Il permet également une différenciation claire et fiable entre les états open,closed, et filtered.

Cette technique est souvent appelée scan semi-ouvert, car vous n’ouvrez pas une connexion TCP complète. Vous envoyez un paquet SYN, comme si vous alliez ouvrir une vraie connexion, puis vous attendez une réponse. Un SYN/ACK indique que le port est à l’écoute (ouvert), tandis qu’un RST (réinitialisation) indique que le port n’est pas à l’écoute. Si aucune réponse n’est reçue après plusieurs retransmissions, le port est marqué comme étant filtré. Le port est également marqué comme filtré si une erreur ICMP unreachable (type 3, code 0, 1, 2, 3, 9, 10 ou 13) est reçue. Le port est également considéré comme ouvert si un paquet SYN (sans le drapeau ACK) est reçu en réponse. Cela peut être dû à une caractéristique TCP extrêmement rare connue sous le nom de connexion ouverte simultanée ou split handshake (voir https://nmap.org/misc/split-handshake.pdf).

-sT(TCP connect scan)

TCP connect scan est le type de scan TCP par défaut lorsque SYN scan n’est pas une option. C’est le cas lorsqu’un utilisateur n’a pas de privilèges sur les paquets bruts. Au lieu d’écrire des paquets bruts comme le font la plupart des autres types de scan, Nmap demande au système d’exploitation sous-jacent d’établir une connexion avec la machine et le port cibles en émettant l’appel système connect. C’est le même appel système de haut niveau que les navigateurs web, les clients P2P et la plupart des autres applications réseau utilisent pour établir une connexion, et il fait partie d’une interface de programmation connue sous le nom de Berkeley SocketsAPI. Plutôt que de lire les réponses brutes des paquets sur le fil, Nmap utilise cette API pour obtenir des informations sur le statut de chaque tentative de connexion.

Lorsque le scan SYN est disponible, c’est généralement un meilleur choix. Nmap a moins de contrôle sur l’appel de haut niveau connectqu’avec les paquets bruts, ce qui le rend moins efficace. L’appel système complète les connexions aux ports cibles ouverts plutôt que d’effectuer la réinitialisation des demi-ouvertures que fait le SYN scan. Non seulement cela prend plus de temps et nécessite plus de paquets pour obtenir les mêmes informations, mais les machines cibles sont plus susceptibles d’enregistrer la connexion. Un système de détection d’intrusion décent détectera l’une ou l’autre de ces méthodes, mais la plupart des machines ne disposent pas d’un tel système d’alarme. De nombreux services sur votre système Unix moyen ajouteront une note au syslog, et parfois un message d’erreur cryptique, lorsque Nmap se connecte et ferme ensuite la connexion sans envoyer de données. Des services vraiment pathétiques se plantent quand cela arrive, mais c’est rare. Un administrateur qui voit un tas de tentatives de connexion dans ses journaux à partir d’un seul système devrait savoir qu’il a été scanné par connexion.

-sU(scans UDP)

Alors que la plupart des services populaires sur Internet fonctionnent sur le protocole TCP, les services UDP sont largement déployés. DNS, SNMP et DHCP (ports enregistrés 53, 161/162 et 67/68) sont trois des services les plus courants. L’analyse de l’UDP étant généralement plus lente et plus difficile que celle du TCP, certains auditeurs de sécurité ignorent ces ports. C’est une erreur, car les services UDP exploitables sont assez courants et les attaquants n’ignorent certainement pas l’ensemble du protocole. Heureusement, Nmap peut aider à inventorier les ports UDP.

Le scan UDP est activé avec l’option -sU. Il peut être combiné avec un type de scan TCP tel que le SYN scan(-sS) pour vérifier les deux protocoles au cours du samerun.

Le scan UDP fonctionne en envoyant un paquet UDP à chaque port ciblé. Pour certains ports communs tels que 53 et 161, une charge utile spécifique au protocole est envoyée pour augmenter le taux de réponse, mais pour la plupart des ports, le paquet est vide à moins que les options --data,--data-string ou --data-length ne soient spécifiées.Si une erreur ICMP de port inaccessible (type 3, code 3) est retournée, le port est closed. Les autres erreurs ICMP inaccessibles (type 3, codes 0, 1, 2, 9, 10, ou 13) marquent le port comme filtered. Occasionnellement, aservice répondra avec un paquet UDP, prouvant qu’il est open. Si aucune réponse n’est reçue après des retransmissions, le port est classé comme open|filtered. Cela signifie que le port pourrait être ouvert, ou peut-être que des filtres de paquets bloquent la communication. La détection de version (-sV) peut être utilisée pour aider à différencier les ports réellement ouverts de ceux qui sont filtrés.

Un grand défi avec le scan UDP est de le faire rapidement.Les ports ouverts et filtrés envoient rarement une réponse, laissant Nmap dans l’obligation d’attendre et d’effectuer des retransmissions juste au cas où la sonde ou la réponse seraient perdues. Les ports fermés sont souvent un problème encore plus important : ils renvoient généralement une erreur ICMP port unreachable. Mais contrairement aux paquets RST envoyés par les ports TCP fermés en réponse à un SYN ou à un connectscan, de nombreux hôtes limitent par défaut le taux de messages ICMP port unreachable.Linux et Solaris sont particulièrement stricts à ce sujet. Par exemple, le noyau Linux 2.4.20 limite les messages de destination inaccessible à une par seconde (en net/ipv4/icmp.c).

Nmap détecte la limitation de débit et ralentit en conséquence pour éviter d’inonder le réseau de paquets inutiles que la machine cible laissera tomber. Malheureusement, une limite de style Linux d’un paquet par seconde fait qu’une analyse de 65 536 ports prend plus de 18 heures. Les idées pour accélérer vos analyses UDP incluent l’analyse de plus d’hôtes en parallèle, l’analyse rapide des ports les plus populaires en premier, l’analyse derrière le pare-feu et l’utilisation de --host-timeout pour sauter les hôtes lents.

-sY(SCTP INIT scan)

SCTP est une alternative relativement nouvelle aux protocoles TCP et UDP, combinant la plupart des caractéristiques de TCP et UDP, et ajoutant également de nouvelles fonctionnalités comme le multi-homing et le multi-streaming. Il est principalement utilisé pour les services liés à SS7/SIGTRAN, mais il a également le potentiel d’être utilisé pour d’autres applications.Le scan INIT SCTP est l’équivalent SCTP d’un scan TCP SYN.Il peut être exécuté rapidement, en balayant des milliers de ports par seconde sur un réseau rapide non entravé par des pare-feu restrictifs.Comme le scan SYN, le scan INIT est relativement discret et furtif, puisqu’il ne complète jamais les associations SCTP. Il permet également une différenciation claire et fiable entre les états open,closed et filtered.

Cette technique est souvent appelée scan semi-ouvert, car vous n’ouvrez pas une association SCTP complète. Vous envoyez un chunk INIT, comme si vous alliez ouvrir une véritable association, puis vous attendez une réponse. Un chunk INIT-ACK indique que le port est à l’écoute (ouvert), tandis qu’un chunk ABORT indique que le port n’est pas à l’écoute. Si aucune réponse n’est reçue après plusieurs retransmissions, le port est marqué comme étant filtré. Le port est également marqué comme étant filtré si une erreur ICMPunreachable (type 3, code 0, 1, 2, 3, 9, 10, ou 13) est reçue.

-sN;-sF;-sX(scans TCP NULL, FIN, et Xmas)

Ces trois types de scans (encore plus sont possibles avec l’option--scanflags décrite dans la section suivante)exploitent une faille subtile dans la RFC TCP pour différencier les ports open etclosed. La page 65 de la RFC 793 dit que « si l’état du port est CLOSED …. un segment entrant ne contenant pas de RST provoque l’envoi d’un RST en réponse ». Ensuite, la page suivante discute des paquets envoyés aux ports ouverts sans les bits SYN, RST ou ACK définis, en déclarant que : « il est peu probable que vous arriviez ici, mais si c’est le cas, laissez tomber ce segment et revenez. »

Lorsque l’on scanne des systèmes conformes à ce texte de la RFC, tout paquet ne contenant pas de bits SYN, RST ou ACK entraînera un retour de RST si le port est fermé et aucune réponse du tout si le port est ouvert. Tant qu’aucun de ces trois bits n’est inclus, toute combinaison des trois autres (FIN, PSH, et URG) est OK. Nmap exploite cela avec trois types de scan:

Null scan (-sN)

N’active aucun bit (l’en-tête TCP flag est 0)

FIN scan (-sF)

Active uniquement le bit TCP FIN.

Xmas scan (-sX)

Met les drapeaux FIN, PSH, et URG, allumant le paquet comme un arbre de Noël.

Ces trois types de scan ont exactement le même comportement à l’exception des drapeaux TCP mis en place dans les paquets de sonde. Si un paquet RST est reçu, le port est considéré comme closed, tandis que l’absence de réponse signifie qu’il est open|filtered. Le port est marquéfiltered si une erreur ICMP unreachable (type 3, code0, 1, 2, 3, 9, 10, ou 13) est reçue.

Le principal avantage de ces types de scan est qu’ils peuvent se faufiler à travers certains firewalls non-stateful et packet filteringrouters. Un autre avantage est que ces types de scan sont un peu plus furtifs que même un scan SYN. Mais ne comptez pas là-dessus : la plupart des produits IDS modernes peuvent être configurés pour les détecter. Le gros inconvénient est que tous les systèmes ne suivent pas la RFC 793 à la lettre. Un certain nombre de systèmes envoient des réponses RST aux sondes, que le port soit ouvert ou non. Cela fait que tous les ports sont étiquetés closed. Les principaux systèmes d’exploitation qui font cela sont Microsoft Windows, de nombreux appareils Cisco, BSDI et IBM OS/400. Ce scan fonctionne cependant contre la plupart des systèmes basés sur Unix. Un autre inconvénient de ces scans est qu’ils ne peuvent pas distinguer les ports open de certains filtered, vous laissant avec la réponseopen|filtered.

-sA(TCP ACK scan)

Ce scan est différent des autres discutés jusqu’à présent car il ne détermine jamais les ports open (ou mêmeopen|filtered). Il est utilisé pour cartographier les jeux de règles de pare-feu, en déterminant s’ils sont stateful ou non et quels ports sont filtrés.

Le paquet de sonde du scan ACK a seulement le drapeau ACK activé (sauf si vous utilisez --scanflags). Lors du scan de systèmes non filtrés, les ports open et closed renverront tous deux un paquet RST. Nmap les étiquette alors commeunfiltered, ce qui signifie qu’ils sont joignables par le paquetACK, mais qu’il est impossible de déterminer s’ils sont open ouclosed. Les ports qui ne répondent pas, ou qui renvoient certains messages d’erreur ICMP (type 3, code 0, 1, 2, 3, 9, 10, ou 13), sont étiquetés filtered.

-sW(TCP Window scan)

Window scan est exactement le même que ACK scan sauf qu’il exploite un détail d’implémentation de certains systèmes pour différencier les ports ouverts des ports fermés, plutôt que de toujours imprimerunfiltered lorsqu’un RST est renvoyé. Il le fait en examinant le champ TCP Window des paquets RST retournés. Sur certains systèmes, les ports ouverts utilisent une taille de fenêtre positive (même pour les paquets RST) alors que les ports fermés ont une fenêtre nulle. Ainsi, au lieu de toujours lister un port comme unfiltered lorsqu’il reçoit un retour RST,Window scan liste le port comme open ouclosed si la valeur TCP Window dans cette réinitialisation est positive ou nulle, respectivement.

Ce scan repose sur un détail d’implémentation d’une minorité de systèmes sur Internet, vous ne pouvez donc pas toujours lui faire confiance. Les systèmes qui ne le supportent pas retourneront généralement tous les portsclosed. Bien sûr, il est possible que la machine n’ait réellement aucun port ouvert. Si la plupart des ports analysés sontclosed mais que quelques numéros de port courants (tels que 22,25, 53) sont filtered, le système est très probablementysusceptible. Parfois, les systèmes peuvent même présenter le comportement exactement inverse. Si votre scan montre 1000 ports ouverts et trois ports fermés ou filtrés, alors ces trois ports peuvent très bien être les ports réellement ouverts.

-sM(TCP Maimon scan)

Le scan Maimon est nommé d’après son découvreur, Uriel Maimon.Il a décrit la technique dans le numéro 49 de Phrack Magazine (novembre 1996).Nmap, qui inclut cette technique, a été publié deux numéros plus tard.Cette technique est exactement la même que les scans NULL, FIN et Xmas, sauf que la sonde est FIN/ACK. Selon la RFC 793 (TCP), un paquet RST devrait être généré en réponse à une telle sonde, que le port soit ouvert ou fermé. Cependant, Uriel a remarqué que de nombreux systèmes dérivés de BSD abandonnent simplement le paquet si le port est ouvert.

--scanflags(Custom TCP scan)

Les utilisateurs vraiment avancés de Nmap n’ont pas besoin de se limiter aux types de scan proposés. L’option --scanflags vous permet de concevoir votre propre scan en spécifiant des drapeaux TCP arbitraires.Laissez libre cours à votre créativité, tout en échappant aux systèmes de détection d’intrusion dont les vendeurs ont simplement parcouru la page de manuel de Nmap en ajoutant des règles spécifiques!

L’argument --scanflags peut être une valeur numérique de drapeau telle que 9 (PSH et FIN), mais utiliser des noms symboliques est plus facile. Il suffit de mélanger n’importe quelle combinaison de URG,ACK, PSH,RST, SYN, etFIN. Par exemple, --scanflagsURGACKPSHRSTSYNFIN définit tout, bien que ce ne soit pas très utile pour l’analyse. L’ordre dans lequel ils sont spécifiés n’a pas d’importance.

En plus de spécifier les drapeaux désirés, vous pouvez spécifier un type de scanTCP (tel que -sA ou -sF).Ce type de base indique à Nmap comment interpréter les réponses. Par exemple, un scan SYN considère qu’une absence de réponse indique un portfiltered, alors qu’un scan FIN le traite commeopen|filtered. Nmap se comportera de la même manière que pour le type de scan de base, sauf qu’il utilisera les drapeaux TCP que vous spécifiez à la place. Si vous ne spécifiez pas de type de base, le scan SYN est utilisé.

-sZ(SCTP COOKIE ECHO scan)

Le scan SCTP COOKIE ECHO est un scan SCTP plus avancé. Il tire avantage du fait que les implémentations SCTP devraient silencieusement abandonner les paquets contenant des chunks COOKIE ECHO sur les ports ouverts, mais envoyer un ABORT si le port est fermé.L’avantage de ce type de scan est qu’il ne s’agit pas d’un scan de port aussi évident qu’un scan INIT. De plus, il peut y avoir des jeux de règles de pare-feu non-stateful qui bloquent les chunks INIT, mais pas les ECHOchunks COOKIE. L’inconvénient est que les scans SCTP COOKIE ECHO ne peuvent pas différencier les ports open et filtered, vous laissant avec l’état open|filtered dans les deux cas.

-sI <zombie host>(idle scan)

Cette méthode de scan avancée permet un scan de port TCP vraiment aveugle de la cible (ce qui signifie qu’aucun paquet n’est envoyé à la cible depuis votre adresse IP réelle). Au lieu de cela, une attaque à canal latéral unique exploite la génération prévisible de séquences d’ID de fragmentation IP sur l’hôte zombie pour glaner des informations sur les ports ouverts sur la cible. Les systèmes IDS affichent le scan comme provenant de la machine zombie que vous avez spécifiée (qui doit être opérationnelle et répondre à certains critères). Tous les détails de ce type de scan fascinant se trouvent dans la section intitulée « TCP Idle Scan (-sI) ».

En plus d’être extraordinairement furtif (en raison de sa nature aveugle), ce type de scan permet de cartographier les relations de confiance basées sur l’IP entre les machines. La liste des ports montre les ports ouverts du point de vue de l’hôte zombie. Vous pouvez donc essayer de scanner une cible en utilisant divers zombies dont vous pensez qu’ils pourraient être de confiance (via des règles de routeur/filtre à paquets).

Vous pouvez ajouter un deux-points suivi d’un numéro de port à l’hôte zombie si vous souhaitez sonder un port particulier sur le zombie pour les changements d’ID IP. Sinon, Nmap utilisera le port qu’il utilise par défaut pour les pings TCP (80).

-sO(Scan du protocole IP)

Le scan du protocole IP vous permet de déterminer quels protocoles IP(TCP, ICMP, IGMP, etc.) sont supportés par les machines cibles. Il ne s’agit pas techniquement d’un balayage de port, puisqu’il parcourt les numéros de protocole IP plutôt que les numéros de port TCP ou UDP. Pourtant, il utilise toujours l’option-p pour sélectionner les numéros de protocole analysés, rapporte ses résultats dans le format normal de la table des ports, et utilise même le même moteur d’analyse sous-jacent que les véritables méthodes d’analyse de port. Il est donc suffisamment proche d’un scan de port pour être classé ici.

En plus d’être utile en soi, le scandale de protocole démontre la puissance des logiciels libres. Bien que l’idée fondamentale soit assez simple, je n’avais pas pensé à l’ajouter ni reçu de demandes pour une telle fonctionnalité. Puis, au cours de l’été 2000, Gerhard Rieger a eu l’idée, a écrit un excellent patch l’implémentant et l’a envoyé à la liste de diffusion Announce (alors appelée nmap-hackers). J’ai incorporé ce patch dans l’arbre de Nmap et publié une nouvelle version le jour suivant. Peu de logiciels commerciaux ont des utilisateurs assez enthousiastes pour concevoir et contribuer à leurs propres améliorations!

Le scan de protocole fonctionne de manière similaire au scan UDP. Au lieu d’itérer à travers le champ du numéro de port d’un paquet UDP, il envoie des en-têtes de paquets IP et itère à travers le champ de protocole IP de huit bits.Les en-têtes sont généralement vides, ne contenant aucune donnée et même pas l’en-tête approprié pour le protocole revendiqué. Les exceptions sont TCP, UDP, ICMP, SCTP et IGMP. Un en-tête de protocole correct pour ces protocoles est inclus car certains systèmes ne les enverront pas autrement et parce que Nmap a déjà des fonctions pour les créer. Au lieu de rechercher les messages ICMP portunreachable, le scan de protocole recherche les messages ICMPprotocol unreachable. Si Nmap reçoit une réponse dans n’importe quel protocole de l’hôte cible, Nmap marque ce protocole comme open. Une erreur ICMP protocol unreachableerror (type 3, code 2) fait que le protocole est marqué commeclosed tandis que port unreachable (type 3, code 3)marque le protocole open. D’autres erreurs ICMP unreachable (type 3, code0, 1, 9, 10, ou 13) font que le protocole est marquéfiltered (bien qu’elles prouvent en même temps que ICMP estopen). Si aucune réponse n’est reçue après des retransmissions, le protocole est marquéopen|filtered

-b <FTP relay host>(FTP bounce scan)

Une caractéristique intéressante du protocole FTP (RFC 959) émet le support pour des connexions FTP dites proxy. Cela permet à un utilisateur de se connecter à un serveur FTP, puis de demander que les fichiers soient envoyés à un serveur tiers. Une telle fonction est susceptible d’être utilisée de manière abusive à de nombreux niveaux, de sorte que la plupart des serveurs ont cessé de la prendre en charge. Il suffit de demander au serveur FTP d’envoyer un fichier à chaque port intéressant de l’hôte ciblé à tour de rôle. Le message d’erreur indiquera si le port est ouvert ou non. C’est un bon moyen de contourner les pare-feux car les serveurs FTP des entreprises sont souvent placés là où ils ont plus d’accès aux autres hôtes internes que n’importe quel hôte Internet. Nmap supporte le scan FTPbounce avec l’option -b. Elle prend un argument de la forme<username>:<password>@<server>:<port>.<Server> est le nom ou l’adresse IP d’un serveur FTP vulnérable. Comme pour une URL normale, vous pouvez omettre<username>:<password>,auquel cas les identifiants de connexion anonymes (user:anonymous password:-wwwuser@)sont utilisés. Le numéro de port (et les deux points précédents) peut également être omis, auquel cas le port FTP par défaut (21) sur<server> est utilisé.

Cette vulnérabilité était répandue en 1997 lorsque Nmap a été publié, mais elle a été largement corrigée. Les serveurs vulnérables existent toujours, il vaut donc la peine d’essayer quand tout le reste a échoué. Si votre objectif est de contourner un pare-feu, scannez le réseau cible pour le port 21 (ou même pour tout service FTP si vous scannez tous les ports avec la détection de version) et utilisez le scriptftp-bounceNSE. Nmap vous dira si l’hôte est vulnérable ou non. Si vous essayez simplement de couvrir vos traces, vous n’avez pas besoin (et, en fait, ne devriez pas) de vous limiter aux hôtes du réseau cible. Avant d’aller scanner des adresses Internet aléatoires à la recherche de serveurs FTP vulnérables, pensez que les administrateurs système n’apprécieront peut-être pas que vous abusiez de leurs serveurs de cette manière.

admin

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.

lg