Nmap : l'art du port scan

De SeRoM - Wiki
Aller à : navigation, rechercher


Cet article à pour but d'expliquer ce qu'est le port scan, les differentes manieres de scanner, et l'utilisation de Nmap.

l'article est basée sur une traduction de : The Art of Port Scanning by Fyodor


Introduction

Qu'est ce que le portscan

le "balayage de port" est une technique pour rechercher les ports ouverts chez un hôte du réseau. Elle est souvent utilisée par les administrateurs pour contrôler la sécurité des hôtes de leurs réseaux.(et par les pirates informatique pour tenter de la compromettre ...)

Pourquoi les scanners de ports sont-ils si importants au sein d'un réseau ?

Fondamentalement parce que ce sont des outils indispensables à ceux qui souhaitent attaquer un système. Les différentes méthodes pour la préparation d'une attaque sont les suivantes :

  • scanner une machine ou un réseau, observer les services en cours et les systèmes qui les exécutent et s'appuyer sur les vulnérabilités connues de ces services ou de ces systèmes.
  • scanner une machine ou un réseau à la recherche d'un service ou d'un système particulier (incluant la vérification de la version) dont la vulnérabilité est connue.

Pour cette raison, un administrateur préoccupé par la sécurité, devra scanner son réseau et y chercher les points faibles avant que d'autres, aux intentions moins avouables, ne s'en chargent.

Qu'est ce qu' Nmap

Nmap est un scanner de ports open source créé par Fyodor et distribué par Insecure.Org. Il est conçu pour détecter les ports ouverts, les services hébergés et les informations sur le système d'exploitation d'un ordinateur distant. Ce logiciel est devenu une référence pour les administrateurs réseaux car l'audit des résultats de Nmap fournit des indications sur la sécurité d'un réseau.



Les Differentes technique de scan

TCP connect() scanning

c'est le scanning TCP le plus courant. L'appel système connect() fourni par votre os est utilisé pour ouvrir une connexion sur les ports. Si le port est en train d'écouter, connect() sera réussi, autrement le port n'est pas accessible. Un grand avantage de cette technique c'est que vous n'avez besoin d'auncun privilège spécial. N'importe quel utilisateur d'un ordinateur UNIX est libre d'utiliser cet appel. Un autre avantage est sa vitesse. Tandis que faire en série un appel connect() séparé pour chaque port cible prendrait beaucoup de temps avec une connexion lente, vous pouvez accélérer le scan en utilisant plusieurs sock ets en parallèle. Utiliser un système I/O non-blocking vous permet de définir un bas time-out et d'observer toutes les sockets immédiatement. Le grand désavantage est que ce genre de scan est facilement détectable et filtrable. Les logs de l'hôtes cibles montreront une masse de connexions et de messages d'erreur pour les services qui ont capturées les connexions et les ont ensuite immédiatement fermées.

TCP SYN scanning

Cette technique est souvent mentionnée comme scanning "demi-ouvert" parce que vous n'ouvrez pas une connexion TCP complète. Vous envoyez un paquet SYN comme si vous alliez ouvrir une vraie connexion et attendre une réponse. Un SYN|ACK indique que le port écoute. Un RST indique que le port n'écoute pas. Si vous recevez SYN|ACK, vous lui enverrez immédiatement un RST pour interrompre la connexion (en fait le kernel le fait pour nous). Le grand avantage de cette technique de scan est que moins de cibles la loggeront. Malheureusement il vous faut avoir les privilèges root pour construire ces paquets standarts SYN. Le scanning SYN se fait avec l'option -s de nmap.

TCP FIN scanning

il arrive des fois que même le scanning SYN n'est pas assez clandestin. Certains firewall et filteur de paquets écoutes les SYNs sur des ports critiques et des programmes comme synlogger et Courtney sont disponible pour détecter ces scans. Les paquets FIN d'autre part peuvent être capables de passer tranquillement. Cette technique de scan a été décrite en détail par Ureil Maimon dans le Phrack 49, article 15. L'idée est que les ports fermés tentent de répondre à votre paquet FIN avec un RST propre. Les ports ouverts d'autre part tentent d'ignorer le paquet en question. Comme Alan Cox l'avait précisé c'est un comportement exigé de TCP/IP. Toutefois quelques systèmes (notamment les systèmes Mirco$oft) sont intouchables dans ce sens. Ils envoyent des RST indépendamment de l'état du port et ils ne sont ainsi pas vulnérables à ce type de scan. Cela marche bien sur la plupart des autres systèmes que j'ai essayés. En fait, cela est souvent utile afin de distinguer un système *NIX d'un NT, et on peut l'utiliser pour ça. Le scannning FIN se fait avec l'option -U (Uriel) de nmap.

Fragmentation scanning

Ce n'est pas une méthode nouvelle et indépendante de scanning mais une variation d'autres techniques. Au lien de seulement envoyer le paquet espion, vous le diviser en plusieurs petits fragments IP. Vous fractionnez l'en-tête TCP sur plusieurs paquets pour rendre la chose plus difficile aux filtreurs de paquets et ainsi détecter ce que vous en êtes en train de faire. Fais attention avec cela! Certains programmes ont de la peine à manipuler d'aussi petits paquets. Mon sniffer préféré me fait un segmentation fault directement après la réception du premier fragment de 36-bytes. Ensuite un de 24 bytes arrive! Alors que cette méthode ne marche pas avec les filtreurs de paquets et les firewalls qui mettent en file d'attente tous les fragments IP (comme l'option Linux CONFIG_IP_ALWAYS_DEFRAG), beaucoup de réseaux n'ont pas les capacités de résoudre ce problème. Cette possibilité est assez unique dans un scanner (en tout cas je n'en ai vu aucun le faire). Merci à daemon9 de m'en avoir donné l'idée. L'option -f dit au scan SYN ou FIN spécifié d'utiliser de petits paquets fragmentés.

TCP reverse ident scanning

Comme l'a remarqué Dave Goldsmith dans un envoi de 1996 à Bugtraq, le protocole ident (rfc 1413) permet de révéler le nom de l'utilisateur propriétaire de n'importe quel processus relié par TCP, même si ce processus n'as pas initié de connexion. Ainsi vous pouvez par exemple vous connecter au port http et ensuite utiliser identd pour savoir si le serveur est exécuté par root. Cela peut seulement être fait par une connexion complète au port cible (càd l'option -t). L'option -i de nmap demande à identd le propriétaire de chaque port écouté par listen().


FTP bounce attack

Une possibilité intéressante du protocole ftp (RFC 959) est qu'il supporte des connexions ftp par "proxy". En d'autres mots, je devrais pouvoir me connecter de evil.com au serveur PI (protocol interpreter) ftp de target.com pour établir une connexion. Ensuite je serais capable de demander que le serveur PI lance un serveur DTP (data transfer process) actif pour envoyer un fichier N'IMPORTE Où sur le net! Vraisemblablement à un User DTP, bien que la RFC dit spécifiquement que demander à un serveur d'envoyer un fichier à un autre est permis. Bon cela a pu bien marcher en 1985 quand la RFC venait d'être écrite. Mais de nos jours il ne peut y avoir des gens qui hijackent des serveurs ftp et demandent que les données soient renvoyer vers n'importe quels points du net. Comme *Hobbit* l'avait écrit en 1995, ce défaut du protocole "peut être utilisé pour poster des mails et des news pratiquement non retraçables, attaquer des serveurs depuis différents endroits, remplire des diques durs, traverser des firewalls et généralement être ennuyant et difficile à retrouver en même temps". Ce que nous ferons pour cela (surprise surprise) c'est de scaner des ports TCP d'un serveur ftp "proxy". Ainsi vous pourriez vous connecter à un serveur ftp derrière un firewall et puis scanner ceux qui sont le plus probablement bloqués (le port 139 est un bon exemple). Si le serveur ftp permet de lire et d'écrire sur un répertoire (comme /incoming), vous pouvez envoyer n'importe quelles données sur les ports que vous trouvez ouverts.

UDP ICMP port unreachable scanning

Cette méthode de scan diffère de ce qu'il y a au-desssus parce qu'ici nous utilisons le protocole UDP au lieu de TCP. Alors que ce protocole est plus simple, le scanning est réellement sensiblement plus difficile. Ceci parce ce que les ports ouverts ne sont pas obligés d'envoyer un acknowlegment en réponse à une demande et les ports fermés ne doivent même pas renvoyer de paquet d'erreur. Heureusement, la plupart des hôtes renvoyent une erreur ICMP_PORT_UNREACH quand vous envoyez un paquet à un port UDP fermé. Ainsi vous pouvez savoir si un port N'est PAS ouvert donc par exclusion déterminer quels ports sont ouverts. Comme il n'est garanti ni que les paquets UDP, ni que les erreurs ICMP arrivent, les scanners UDP de ce genre doivent aussi implémenter une retransmission des paquets qui pourraient être perdus (sinon vous obtiendrez un groupe faussement positif). En outre cette technique est lente en raison des machines qui appliquent la RFC 1812 section 4.3.2.8 pour découragez et limitez le taux d'erreurs ICMP. Par exemple, le kernel Linux (dans net/ipv4/icmp.h) limite la production de message de destination innaccessible à 80 chaque 4 secondes avec une pénalité de 1/4 de secondes en cas de dépassement. Dans quelque temps j'ajouterai un meilleur algorithme à nmap pour détecter cela. De plus vous devez être root pour accéder au raw ICMP socket nécessaire pour la lecture du port inaccessible. L'option -u (UDP) de nmap incorpore cette méthode de scannings pour les utilisateurs root.

Certaines personnes pensent que le scanning UPD est lame et inutile. Je leur rappelle généralement le récent bug rcpbind de Solaris. Rcpbind peut se cacher sur un port UDP non documenté quelque part au-dessus de 32770. Ainsi on s'en fout que le port 111 soit bloqué par un firewall. Mais pouvez-vous trouver sur lequel des 30'000 ports plus hauts il écoute? Avec un scanner UDP vous pouvez!

UDP recvfrom() and write()

scanning: Alors que les utilisateurs qui ne sont pas root ne peuvent pas lire les erreurs de ports innacessibles directement, Linux est assez sympa pour informer l'utilisateur indirectement quand elles ont été reçues. Par exemple un deuxième appel write() à un port fermé échouera normalement. Cela arrive à beaucoup de scanners comme netcat et pscan.c de Pluvius. J'ai aussi remarqué que recvfrom() sur des non-blocking sockets UDP retourne EAGAIN ("Try Again", errno 13) si l'erreur ICMP n'a pas été reçue et ECONNREFUSED ("Connection refused", errno 111) si elle a été reçue. C'est la technique utilisée pour déterminer les ports ouverts quand les utilisateurs qui ne sont pas root utilise l'option -u (UDP). Les utilisateurs root peuvent aussi utiliser l'option -l (lamer UDP scan) pour forcer à que cela se passe mais c'est une idée vraiment bête.

ICMP echo scanning

ce n'est pas vraiment du portscanning vu que ICMP n'a pas de port abstraction. Mais il est parfois utile de savoir quels hôtes dans un réseau sont up en les pingant tous. l'option -P le fait. Le scan ICMP se fait maintenant en parallèle il peut être ainsi assez rapide. Pour encore plus accélérer les choses vous pouvez augmenter le nombre de ping en parallèle avec l'option '-L'. Il peut être aussi utile de modifier la valeur du ping timeout avec l'option '-T'. nmap supporte une notation en hôte / masque de bits pour faciliter ce genre de chose. Par exemple 'nmap -P cert.org/24 152.148.0.0/16' scannera le réseau du CERT de classe C et toutes les entitée de class B représentées par 152.148.* . Hôte/26 est intéressant pour les sous-réseaux de 6-bits dans une organisation. Nmap permet maintenant aussi une syntaxe plus puissante. Vous pouvez maintenant manipulez des addresses comme '150.12,17,71-79.7.*' et nmap en fera ce que vous voulez. Pour chacune des quatre valeurs vous pouvez soit mettre un simple nombre, soit un intervalle (avec '-'), une liste d'intervalle et de nombre séparée par des virgules, ou un '*' qui est synonyme de 0-255. Par défaut, les adresse de broadcast d'un réseau comme .0 et .255 ne sont pas scannée mais l'option '-A' vous permet d'y remédier si vous le souhaiter.


Resumé

  • TCP connect scanning : Avantage : pas de privilège, rapide ; Desavantage : detectable et filtrable.
  • TCP SYN scanning : Avantage : furtif (mais quand meme detectable par exemple par des IDS (intrusion detection systems) ; Desavantage : il faut des privilege root pour construire les packets.
  • TCP FIN scanning : Avantage : très furtif Desavantage : ne marche pas sur les systems de type windows
  • Fragmentation scanning :Avantage : très furtif voir quasi indetectable Desavantage : plus lent
  • TCP reverse ident scanning : Avantage : permet de savoir a qui appartient le processus lancer sur le port Desavantage :idem que pour le TCP connect scanning