Les scanner de ports TCP et UDP

Les scanner de ports TCP et UDP

1 – Introduction au scanner de ports TCP et UDP

La première phase pour un pirate avant de pénétrer un réseau est la découverte d’information sur la cible choisie. Il est donc fortement utile d’auditer soi-même son réseau à l’aide de scanner afin d’y déceler rapidement les failles.

Chaque application qui communique avec l’extérieur ouvre un ou plusieurs ports. Ainsi, pour auditer un réseau, on va balayer (scanner) ces ports TCP et UDP ouverts. Pour cela, nous allons vérifier l’existence ou non de cette « porte ouverte » sur le système.

Le but de cet article est de présenter les différentes méthodes de Scan, qui permettent de tester la sécurité de votre réseau. Ils vous révéleront les trous de sécurité et vous avertiront des problèmes potentiels, avant qu’un pirate ne le fasse à votre place…

2 – Rappel des terminologies

Nous aurons besoin de connaître, particulièrement pour le 4ème chapitre, comment est constitué l’entête TCP qui permet un transport en mode connecté.

scanner-port-tcp-udp rappel terminologie entete tcp

Idem pour le chapitre 5 où nous ferons référence à l’entête UDP basé sur 8 octets. Elle permet de définir principalement, un transport en mode non connecté.

scanner-port-tcp-udp rappel terminologie entete udp

Dans les schémas d’exemple qui vont suivre, il y a souvent deux protagonistes : je nomme le premier « Le Pirate » en référence à sa tentative d’en savoir davantage sur la machine cible, qui est le second protagoniste. Un tiers pourra parfois intervenir, la plupart des cas dans le but de brouiller les pistes, on le nomme « La machine zombie » en référence à la soumission de cette machine pour envoyer les requêtes.

Les outils utilisés NMAP et autres sont pour la plupart des outils en ligne de commande, disponibles sous Windows et Unix. Ils permettent de forger « à la main » des paquets TCP et UDP spécifiques au but recherché.

3 – Définition d’un scanner de ports

Un scanner est un programme qui balaye une plage de ports TCP ou UDP sur un ensemble de machines, afin d’établir la liste des couples machine/services ouverts. Dans le cas de TCP, il ouvre une session en émettant un SYN et attend la réponse SYN/ACK de la machine distante. Dans le cas de UDP, le scanner n’ouvre pas de session mais émet un datagramme et attend une  réponse. Le scan horizontal consiste à scanner un port sur un ensemble de machines, alors que le scan vertical consiste à scanner une plage de ports sur une même machine.

Il existe différent type de scanners : les primitifs qui balayent simplement les ports pour prévenir si un port est ouvert ou fermé. Et les plus évolués vont jusqu’à tester les applications, afin de nous informer sur le numéro de version, utilisant des techniques plus poussée (contournement de firewalls etc.)

Les scans de Internet sont permanents, il y a toujours quelqu’un, quelque part qui est en train d’analyser vos machines. Il ne faut pas considérer ces scans de façons anodines, en effet, une compromission est très souvent précédée d’un scan.

4 – Scan de ports TCP

Il existe les neuf types de scan de port TCP que nous vous détaillons :

4.1 – Vanilla connect()

TCP connect() est la méthode de connexion la plus basique et la plus fiable. L’appel système connect() essai d’ouvre une connexion entre ports sur un host distant. Si le port est ouvert, connect() réussira à s’y connecter, sinon le port est dit fermé ou sans réponse.

On considère qu’un port est ouvert sur la cible, lorsqu’on obtient ce schéma :

scanner-port-tcp-udp scan port tcp vanilla connect 1

On considère qu’un port est fermé sur la cible, lorsqu’on obtient ce schéma :

scanner-port-tcp-udp scan port tcp vanilla connect 2

On peut aussi ne rien recevoir si la cible l’a décidé où si un Firewall placé en avant l’interdit. Un port fermé peux alors aussi se représenter par un non réponse.

En lançant un scan par ping ICMP, vous pouvez effectuer une détection du système d’exploitation à distance en étudiant les paquets réponses obtenues (plus communément appelé « OS fingerprinting »)

Voici des outils fonctionnant sur la méthode Vanilla connect() :

  • Nmap utilise cette méthode si on lui indique l’option -sT.
  • Sous Windows, le SuperScan de Foundstone est un très bon outil de scanning.

4.2 – Half-open SYN flag

En tant normal, comme vu juste au dessus, la connexion TCP s’effectue en 3 datagrammes. Ici, nous allons envoyer un SYN, recevoir un SYN/ACK, mais au lieu de renvoyer un ACK, avec la méthode demi connexion SYN, nous allons envoyer un RST, ce qui va brutalement fermer la connexion. Si la machine cible n’a pas d’IDS (Système de Détection d’Intrusions) ou de firewall, cette « demi-connexion » ne sera pas enregistré (dans les logs) par la machine cible. Dans le cas contraire il y aura une trace comme quoi la connexion a été fermée brutalement et ce n’est donc pas normal. Il est peux être mieux d’être loggué comme session réussite que session échouée. L’administrateur distant sera attiré par les logs d’échec alors que la réussite sera noyé parmi les autres logs.

scanner-port-tcp-udp scan port tcp half open syn flag

Si, après avoir envoyé un SYN, on reçoit un SYN/ACK, cela veut dire que le port est ouvert. On renvoie donc un RST pour couper la connexion, dans l’espoir de ne pas être logué. Si le port est fermé, on recevra un RST/ACK et on s’arrête là.

Voici un outil fonctionnant sur la méthode Half-open SYN flag :

  • Nmap utilise cette méthode si on lui indique l’option -sS.

4.3 – Inverse TCP flag

Les IDS et les firewalls sont désormais capables de loguer les scans SYN de toutes manières quelles qu’elles soient. La RFC 793 indique que si un port est fermé, alors il doit renvoyer un paquet RST/ACK pour fermer la connexion et s’il est ouvert, il ne renvoie pas de réponse.

Voici l’extrait :

  • « … TCP B tries to send to TCP A data on what it thinks is a synchronized connection. In this case, the data arriving at TCP A from TCP B is unacceptable because no such connection exists, so TCP A sends a RST. The RST is acceptable so TCP B processes it and aborts the connection. »

L’attaquant envoie donc des paquets TCP forgés avec des flags divers de type FIN, URG, PSH etc, mais pas de SYN bien évidement pour ne pas être logué par le firewall. Le principe de cette méthode est de ne pas envoyer de SYN, mais un autre paquet comme FIN, URG, PSH et d’attendre comme toujours la réponse.

Conformément à la RFC, le schéma suivant montre que le port de la cible est fermé :

scanner-port-tcp-udp scan port tcp inverse tcp flag 1

Le schéma suivant montre que le port de la cible est ouvert :

scanner-port-tcp-udp scan port tcp inverse tcp flag 2

Voici un outil fonctionnant sur la méthode Inverse TCP flag :

  • Nmap utilise cette méthode si on lui indique les options -sF (FIN flag) ou -sN (NULL = pas de flag TCP)
  • Sous Windows, il y a VScan qui requiert les drivers WinPcap

4.4 – ACK flag probe

Cette méthode exploite une vulnérabilité dans la pile TCP/IP. Elle a été découverte et publié dans le magazine Phrack #49. Pour cela, ll suffit d’envoyer un grand nombre d’ACK et d’analyser les réponses RST que nous recevrons :

scanner-port-tcp-udp scan port tcp ack flag probe

Deux analyses sont possibles :

Analyse du champ TTL

Analyse du champ TTL (Time To Live) des paquets reçus dont voici le log des premiers paquets RST reçus en utilisant l’outil hping2 :

  • 1 – host 192.168.0.12 port 20: F:RST -> ttl: 70 win: 0
  • 2 – host 192.168.0.12 port 21: F:RST -> ttl: 70 win: 0
  • 3 – host 192.168.0.12 port 22: F:RST -> ttl: 40 win: 0
  • 4 – host 192.168.0.12 port 23: F:RST -> ttl: 70 win: 0

En analysant les valeurs des champs TTL de chaque paquet, le pirate remarque que la valeur retourné par le port 22 est 40 alors que les autres ports ont retournées la valeur 70. On peut conclure que le port 22 est ouvert, car 40 est inférieure à la valeur frontière 64 et 70 est supérieur.

Analyse du champ WINDOW

Analyse du champ WINDOW dont voici le log des premiers paquets RST reçus en utilisant l’outil hping2 :

  • 1: host 192.168.0.20 port 20: F:RST -> ttl: 64 win: 0
  • 2: host 192.168.0.20 port 21: F:RST -> ttl: 64 win: 0
  • 3: host 192.168.0.20 port 22: F:RST -> ttl: 64 win: 512
  • 4: host 192.168.0.20 port 23: F:RST -> ttl: 64 win: 0

Remarquons que le TTL de chaque paquet est 64, nous ne pouvons donc pas utiliser la méthode précédente. Cependant, en prêtant attention au troisième paquet et à son champ WINDOW, le pirate voit que 512 est différent de 0, donc le port est ouvert.

L’avantage (ou l’inconvénient) de cette méthode est que sa détection par les IDS est difficile. Par contre, cette faiblesse de la pile TCP/IP a été fixée dans les équipements modernes. (Elle était effective dans les équipements à la BSD-like)

Voici un outil fonctionnant sur la méthode ACK flag probe :

  • Nmap utilise cette méthode si on lui indique les options -sA pour initialiser le TTL et -sW pour initialiser WINDOW.
  • hping2 le permet aussi. (cf plus loin)

4.5 – TCP fragmentation

La fragmentation TCP n’est pas une méthode de scan en tant que tel, c’est une technique qui rend très discret le scan. En effet, le but est de fragmenter l’entête TCP en petits fragments. Le réassemblage IP du côté serveur provoque souvent des résultats non prévisibles et anormaux.

Beaucoup d’hôtes sont incapables d’analyser et de rassembler les mini paquets et ainsi peut causer des crashs, des redémarrages. Ces mini paquets peuvent être potentiellement bloqués par la fragmentation IP, mis en attente dans le noyau ou pouvant être pris en compte par une règle de pare-feu.

Depuis que la plupart des systèmes de détection d’intrusion (IDS) utilisent des mécanismes basés sur des signatures pour identifier les scans, la fragmentation est très souvent capable de gagner sur ce type de filtrage, et le scan ne sera donc pas découvert.

4.6 – FTP Bounce

Le FTP Bounce signifie Rebond FTP. Il fonctionne sur des machines ayant de l’âge (FreeBSD < 2.1.x, Red Hat Linux < 4.2….). La figure ci-dessous explique le principe :

scanner-port-tcp-udp scan port tcp ftp bounce

1 – Ouverture d’une connexion TCP 21. Envoi de la commande PORT
2 – Le serveur FTP tente d’envoyer les données à la cible et retournera une réponse positive au pirate si le port est ouvert

Pour plus d’informations, consultez la RFC 959 sur l’utilisation de la commande PORT

C’est un cas de spoofing d’adresse IP. Elle est basée sur une utilisation de la commande PORT du protocole FTP lorsque le serveur FTP est en mode actif. PORT permet de se connecter à n’importe quel autre serveur distant. L’adresse IP que le serveur cible verra sera l’adresse IP du serveur FTP (de confiance, en théorie), et non de l’adresse IP de l’attaquant.

Les conséquences peuvent être un vol d’identité, et l’accès à des données confidentielles.

Voici un outil fonctionnant sur la méthode FTP Bounce :

Nmap utilise cette méthode si on lui indique les options -P0 et -b. Voici un exemple :

# nmap -P0 -b user:pass@ftp-server:port <cible>

Il faut bien être conscient de l’âge de cette technique qui fait qu’elle n’est plus réaliste de nos jours. Cette technique n’est plus d’actualité, mais reste intéressante car conforme à la RFC, ce qui lui avait fait sa force car elle était utilisable sur tous les serveurs FTP autorisant la commande PORT.

4.7 – Proxy Bounce

Les pirates qui utilisent cette méthode opèrent à travers des serveurs proxys ouverts (c’est à dire des proxys dans des entreprises ou des facultés que les administrateurs n’ont pas sécurisés. N’importe qui peut donc s’en servir). Il est donc possible, outre le fait de surfer presque anonymement en se servant du proxy comme relais, de lancer des scans de type TCP vers une cible. Ce n’est donc pas une méthode de scan à proprement parler, mais l’adresse IP qui sera logué sera celle du proxy et non du pirate. Un DOS ou n’importe quelle autre attaque peut alors être lancé. D’où l’importance de sécuriser et filtrer l’accès à ses serveurs proxys.

4.8 – Sniffer-based spoofed

Spoofer puis sniffer pour tromper la confiance, pour cette méthode, il faut être présent physiquement dans le réseau où se trouve notre cible.

Nommé spoofscan, cet outil innovant va mettre la carte réseau sur le mode promiscuous (c’est-à-dire que tous les paquets envoyés à la machine seront gérés par le noyau (donc par notre outil), et non par la carte réseau qui risquerait de rejeter ceux qui ne lui pas destiné !).

Cet outil va donc spoofer (changer d’identité) nos paquets pour prendre l’identité d’une machine de confiance sur le réseau, dans le but de tromper le firewall. Nous aurons ensuite accès au réseau interne, et nous capturerons tous les paquets qui passent pour les analyser ensuite. Nous pourrons obtenir beaucoup d’informations, cartographier les machines, capturer les informations qui transitent, connaître les OS, les ports, les services….

Voici un outil fonctionnant sur la méthode Sniffer-based spoofed :

4.9 – IP ID header

Utilisation de l’entête IP ID, cette méthode s’appuie encore sur une faiblesse de la pile TCP/IP. Il y a trois protagonistes : le pirate, la cible, et une machine zombie. L’IP ID header scanning est surtout utilisé pour cartographier les réseaux et machines de confiance, qui communiquent entre elles (firewalls ou passerelle VPN).

Voici un outil fonctionnant sur la méthode IP ID header :

Nmap utilise cette méthode si on lui indique l’option -sI <zombie host[:probe port]>. Voici un exemple :

# nmap -P0 -sI 192.168.0.155 192.168.0.50
 
Starting nmap 4.20 ( www.insecure.org/nmap/ )
Idlescan using zombie 192.168.0.155;
Interesting ports on (192.168.0.50):
(The 1582 ports scanned but not shown below are in state: closed)
Port State Service
25/tcp open smtp
53/tcp open domain
80/tcp open http
88/tcp open kerberos-sec
135/tcp open loc-srv
139/tcp open netbios-ssn
389/tcp open ldap
443/tcp open https

Nous avons donc scanner les ports de la machine cible 192.168.0.50 par le biais de notre machine zombie 192.168.0.155.

  • Sous Windows, Vscan permet aussi l’IP ID scanning.

    scanner-port-tcp-udp scan port tcp ip id header windows

5 – Scan de ports UDP

Le protocole UDP est ne requiert pas de connexions. Il y 2 manières d’énumérer les services UDP sur notre cible :

  • Envoyer des paquets UDP sur les 65535 ports et attendre un « ICMP destination port unreachable » qui signifie que le port est fermé, inaccessible ou que la machine est hors service.
  • Utiliser un client UDP tel que Smpwalk, Dig ou Tftp pour envoyer un datagramme à la cible et d’attendre une réponse positive.

La plupart des réseaux filtrent les messages ICMP, il est donc souvent difficile d’évaluer quel service UDP est accessible par un simple scan de port. Le schéma ci-dessous montre que le port est ouvert :

scanner-port-tcp-udp scan port udp 1

Et le schéma ci-dessous montre que le port est fermé :

scanner-port-tcp-udp scan port udp 2

Voici un outil fonctionnant sur le scan de port UDP :

  • Nmap utilise cette méthode si on lui indique l’option -sU.
  • Sous Windows, SuperScan le permet aussi.
  • Il y a aussi Scanudp par Fryxar

Voici un exemple d’utilisation de scanudp :

# ./scanudp
scanudp v2.0 - by: Fryxar
 
usage: ./scanudp [options] <host>
Options:
 
-t <timeout> Set port scanning timeout
-b <bps> Set max bandwidth
-v Verbose
 
# ./scanudp 192.168.0.50
 
192.168.0.50 53
192.168.0.50 137
192.168.0.50 161

6 – Synthèse des différentes méthodes de Scan

6.1 – Vanilla connect()

Méthode de scan dites « normale », fiable, mais facilement détectable et donc repoussé par une système de sécurité.

6.2 – Half-open SYN flag

Un scan de port en utilisant des paquets SYN est sûrement le plus efficace contre une cible pour trouver les applications et versions associés. Le scan SYN est très rapide, c’est pour ces raisons qu’il est aussi rapidement détecté si un dispositif de sécurité tel qu’un Firewall ou IDS est mis en place.

6.3 – Inverse TCP flag

Cette technique est puissante, car elle utilise une imprécision de la RFC. Elle demeure néanmoins moins précise et moins fiable qu’une connexion SYN. L’autre inconvénient est que cette méthode reste tout de même facilement détectable et rejetable par quelques règles de firewall.

6.4 – ACK flag probe

Les deux méthodes sont complémentaires et efficaces. Il faut cependant que le firewall n’est pas modifiés les champs pour ces techniques fonctionnent. Très difficile de repérer cette méthode avec un firewall/IDS. Notons l’âge de cette technique, assez ancienne donc plus d’actualité.

6.5 – TCP fragmentation

N’étant pas une technique de scan, mais une technique de discrétion de scan, ses avantages sont d’éviter les IDS, et d’être furtif. L’inconvénient de cette méthode est qu’elle peut causer des problèmes réseau sur l’hôte distant à cause de la fragmentation de l’entête TCP qui ne correspond plus à un paquet TCP classique, donc le comportement reste imprévisible.

6.6 – FTP Bounce

La méthode n’est plus d’actualité, cependant elle était très puissante il y a quelques temps. C’est un cas de spoofing d’IP, il se peut donc que vous soyez rejeté par le firewall et ses règles d’anti-spoofing.

6.7 – Proxy Bounce

L’avantage de cette méthode est l’anonymat du scan effectué. Si le serveur proxy parvient à se connecter au port spécifié de la cible, alors le port sera considéré ouvert et le scan sera logué comme venant du serveur proxy et non du pirate initial.

6.8 – Sniffer-based spoofed

Scanner une cible en spoofant son adresse peut être très intéressant lorsque l’on désire tromper un réseau de confiance où le pirate n’aurait normalement pas les droits. Bien utilisé, ce type de scan peut être dangereux.

6.9 – IP ID header

Cette méthode est efficace pour cartographier les réseaux et machines de confiance qui communiquent entre elles (firewalls ou passerelle VPN). En effet, en analysant l’entête du paquet ID, on peut savoir si un port est ouvert, et en sniffant la connexion (à condition d’appartenir au réseau), on peut aussi savoir avec quelles machines notre cible communique. Cette technique reste marginale et difficile à mettre en oeuvre, elle est peut utilisé car pas assez fiable.

6.10 – Scan UDP

Ce type de scan peut être efficace si et seulement si le message ICMP de type 3 code 3 (destination port unreachable) est autorisé à sortir de l’infrastructure. Autrement dit, si un dispositif de sécurité empêche la sortie de ce message, le scan est inutile. Sinon, il peut être intéressant pour collecter des informations sensibles en se servant de machines déjà compromises (DNS, SNMP, TFTP en particulier)

7 – Présentation et utilisation avancée d’outils de scan

7.1 – Analyse des réponses TCP

Avant d’envoyer des paquets précis pour effectuer un scan, il est très utile de comprendre et d’analyser les paquets que nous recevrons en réponses.

  • TCP SYN/ACK : 
    Le port est considéré ouvert.
  • TCP RST/ACK :
    Le paquet envoyé a été rejeté par la cible ou par un IDS ou par un firewall avec une règle de rejet.
  • ICMP type 3 code 13 :
    La cible ou un organe de sécurité a interdit la connexion sur ce port par l’utilisation des règles de type « access control list : ACL »
  • Aucune réponse :
    Si aucun paquet n’a été reçu, c’est qu’un périphérique de sécurité entre la cible et le pirate a intercepté silencieusement le paquet et l’a supprimé (règle de drop).

7.2 – Nmap

Commençons par le plus connu scanner : Nmap qui est un puissant outil open-source d’exploration réseau et d’audit de sécurité. Il fonctionne en utilisant des paquets IP bruts (raw packets) pour déterminer quels sont les hôtes actifs sur le réseau, quels services (y compris le nom de l’application et la version) ces hôtes offrent, quels systèmes d’exploitation (et leurs versions) ils utilisent, quels types de dispositifs de filtrage/pare-feux sont utilisés etc….

La syntaxe est classique :

$ Nmap [Types de scan] [Options] {cible(s)}

Les options principales du scanner Nmap sont :

-sT :
Scan des ports TCP ouverts. Ouverture d'une connexion sur tous les ports ouverts, toutes la connexion sont visibles sur la machine cible (dans les fichiers de log notamment)
-sV: Teste les ports ouverts pour déterminer le service en écoute et sa version
-sS :
Scan des ports TCP. Envoie d'un message SYN pour l'ouverture d'une connexion TCP, puis attente de la réponse. Après réponse on sait que le port est ouvert, l'avantage de cette option est que l'action n'est pas logué par la cible,
-sF,-sX,-sN Stealth FIN, Xmas, ou Null scan (fonctionne que sous UNIX) Scan des ports plus discrets (voir man nmap pour plus de détails)
-sP équivalent à ping, pour voir si la cible est « alive »
-sU scanning des ports UDP ouverts (assez lent)
L'option -P0 (« tiret P zéro ») évite l'envoi d'un paquet ICMP echo request (ping) pour une discrétion accrue. Il sera tout de même détecté par un NIDS (snort par exemple)

D’autres options intéressantes (liste non exhaustive) :

-O ou -A permet de connaître sur quel OS tourne la cible
--osscan-limit: Limite la détection aux cibles prométueuses. Attention : --osscan-guess: Détecte l'OS de façon plus agressive (log dans les logfile...)
-p <range> syntaxe pour avoir un ensemble de ports à scanner :
  -p 23 va scanner que le port 23
  -p 10-90,63000 va scanner les ports de 10 à 90 et supérieur à 63000 (jusqu'à 65535 en fait) par défaut, nmap scrute uniquement de 1 à 1024 plus les ports se trouvant dans/etc/services
-F scan rapide, scanne uniquement les ports contenus dans /etc/services
-o <logfile> log le résultat dans le fichier <logfile>
-v Verbose, mode bavard (recommandé)
-e <devicename>, spécifier une interface particulière pour envoyer les paquets (eth0, ppp0..).

Pour la cible, on peut spécifier l’hôte ou l’adresse IP et aussi un ensemble d’adresse ou des sous-masques telles : exemple.org/24 ou 192.88.209.5/24, 192.88.209.0-255 ou bien encore 128.88.209.*’

Pour plus d’informations sur les options, faits un « man nmap » ou bien cet url rendez-vous sur cette URL :http://insecure.org/nmap/man/fr/

Voici quelques exemples concrets

scanner-port-tcp-udp nessus 1.jpg

# nmap -sS -sV -T4 -P0 XXX.org
 
Starting Nmap 4.20 ( http://www.insecure.org/nmap )
PORT STATE SERVICE VERSION
21/tcp open ftp ProFTPD 1.2.10
22/tcp open ssh OpenSSH 3.9p1 (protocol 2.0)
80/tcp open http Apache httpd 1.3.31
199/tcp open smux Linux SNMP multiplexer
Device type: general purpose|firewall
Running: Linux 2.1.X|2.2.X|2.4.X, Symantec Solaris 8
OS details: Linux 2.1.19 - 2.2.25, Linux 2.4.19 - 2.4.20, Linux 2.4.21 (x86 SuSE), Symantec Enterprise Firewall v7.0.4 (on Solaris 8)
Network Distance: 13 hops
Service Info: OS: Linux

Commentons un peu les résultats. Nous avons :

  • Tout d’abord un problème avec OpenSSH version 3.9p1 : la version est obsolète et sujette a des attaques d’authentification à distance (bid : 14729, 11781 et 7482)
  • Le serveur web est un Apache httpd version 1.3, qui est obsolète et vulnérable.
  • Nous avons un serveur de ftp (proftpd) obsolète et exploitable via dépassement de mémoire à distance, entre autre.
  • Nous connaissons notre système d’exploitation : Linux, qui a visiblement un noyau inférieur à un 2.6 et un firewall Enterprise Firewall v7.0.4. La version du noyau peut nous permettre d’affiner les outils d’exploration et utiliser des outils en conséquence. La version du firewall permet de chercher des failles pour le passer.
  • Il est assez aisé pour un pirate de connaître beaucoup d’informations sur votre système et ensuite de chercher des potentielles failles et y exécuter des exploits.

Il existe aussi une version GUI (graphique) de nmap pour plus de commodité. Cependant, c’est pas la philosophie AuthSecu. Nmap est donc un outil très intéressant et puissant pour scanner rapidement une machine ou n réseaux. Avec son cortège d’options, il est redoutablement difficile à repérer lorsqu’il est bien utilisé. Notons que l’OS fingerprinting (détection du système d’exploitation) n’est pas à prendre à 100 % comme acquis. Il existe d’autres outils pour confirmer cela.

7.3 – Nessus

Nessus est un scanner de sécurité développé par un français! Il se base entre autres sur nmap, mais en plus de tester les ports, il va scruter les composants logiciels de la machine cible pour déterminer les trous de sécurité et vous avertir sur certaines faiblesses.

Le scanner Nessus est constitué d’une partie serveur et cliente, les deux peuvent très bien fonctionner sur la même machine. La partie serveur est à installer sur la cible pour que le client puisse s’y connecter.

Une fois le serveur nessusd lancé, on ouvre le client (nessus). Cette nouvelle fenêtre propose alors sept onglets. Le premier onglet se nomme « nessusd host ». Depuis ce panneau, vous pouvez vous connecter sur l’hôte nessusd en cliquant sur entrant le login/pass créé précédemment lors de l’installation. Après s’être connecté à l’hôte, allons sur le deuxième onglet qui concerne les plugins. Vous y sélectionnez (ou désélectionnez) les plugins à utiliser pendant le scan. Par exemple, vous pouvez désactiver les plugins dangereux (ceux susceptibles de « planter » une machine comme les dénis de service).

scanner-port-tcp-udp nessus 1

Dans l’onglet Prefs, vous pouvez saisir d’autres informations, notamment un nom d’utilisateur valide et son mot de passe si votre machine est aussi serveur POP ou SMB (samba). Sinon vous pouvez utiliser le ‘brute forcer’ multi-protocoles « Hydra » pour tenter de trouver un accès valide sur un service (samba, http, cisco, vnc…) Agissez de même avec l’onglet suivant « Scan options ». Il ne nous reste plus qu’à lancer le Scan et d’attendre les résultats. Le temps d’attente est parfois long, en fonction de l’OS, de la vitesse du réseau, du rôle des machines (plus ou moins de ports ouverts), du nombre de plugins actifs, etc. Une fois le scan terminé, une fenêtre « Report » apparaît avec les détails des trous de sécurité et des warnings trouvés.

Ces rapports sont plutôt détaillés et proposent souvent une solution à la vulnérabilité découverte. Encore mieux, ils sont très fiables.
Si une vulnérabilité trouvée est « douteuse », Nessus précise qu’il peut s’agir d’une fausse alerte.
Nessus vous fournit donc des tonnes d’informations permettant de corriger les vulnérabilités ou faiblesses des machines de votre réseau.

scanner-port-tcp-udp nessus 2

Nessus est donc un très outil de balayage de ports et découverte de failles. Son principal avantage par rapport a d’autres scanners est qu’il permet de trouver directement les failles et les exploits possibles en fonction de la bannière de version et les mises a jour à effectuer. Le revers de la médaille : il faut installer le serveur Nessus sur la « cible ». Ce n’est donc pas un bon outil pour un pirate qui voudrait impunément scanner un réseau avec Nessus, n’ayant pas la possibilité d’installer le serveur sur la cible.

7.4 – Hping2

hping2 est un outil scanner permettant d’envoyer des paquets TCP, UDP, ICMP arbitraires à des systèmes et d’afficher les réponses de la cible comme le programme ping le fait avec les réponses ICMP. hping2 traite la fragmentation, les contenus de paquets, les tailles arbitraires et peut être utilisé dans le but de transférer des fichiers encapsulés dans les protocoles supportés.

hping2 est couramment utilisé dans les cas suivants :

  • Tester les règles d’un firewall
  • Scanner des ports (en usurpant une adresse)
  • Tester les performances réseau en utilisant différents protocoles, tailles de paquets, TOS (type de service) et fragmentation.
  • Découverte de « Path MTU »
  • Transférer des fichiers même au travers de règles de firewall réellement fachistes.
  • Comme traceroute avec différents protocoles.
  • Utilisation comme Firewalk.
  • Détermination d’OS à distance.
  • Audit de pile TCP/IP.

Il assez compliqué à utiliser dû à son nombre impressionnant de combinaisons d’options. Voici un tableau récapitulatif des principales possibilités :

-c <number> : Nombre de paquets à envoyer
-s <port>   : Port TCP source (hasard par défaut)
-d <port>   : Port TCP destination
-S          : Fixe le flag TCP SYN
-F          : Fixe le flag TCP FIN
-A          : Fixe le flag TCP ACK

Voici un bon exemple d’utilisation :

# hping2 -c 3 -s 53 -p 139 -S 192.168.1.1
 
HPING 192.168.1.1 (eth0 192.168.0.1): S set, 40 headers + 0 data
ip=192.168.1.1 ttl=128 id=275 sport=139 flags=SAP seq=0 win=64240
ip=192.168.1.1 ttl=128 id=276 sport=139 flags=SAP seq=1 win=64240
ip=192.168.1.1 ttl=128 id=277 sport=139 flags=SAP seq=2 win=64240

Ici, 3 paquets (-c 3 ) TCP SYN ont été envoyé au port 139 (-p 139 ) à l’adresse 192.168.1.1 (192.168.1.1) en utilisant comme port source le port 53 (-s 53). Pourquoi le port 53 ? Parce que certain firewall sont configurer pour autoriser le traffic DNS qu’importe les règles.

Les prochains exemples vont générer des réponses qui correspondent à nos états précédents (port ouvert, fermé, bloqué…)

Le port TCP 80 est ouvert :

# hping2 -c 3 -s 53 -p 80 -S google.com
 
HPING google.com (eth0 216.239.39.99): S set, 40 headers + 0 data
ip=216.239.39.99 ttl=128 id=289 sport=80 flags=SAP seq=0 win=64240
ip=216.239.39.99 ttl=128 id=290 sport=80 flags=SAP seq=1 win=64240
ip=216.239.39.99 ttl=128 id=291 sport=80 flags=SAP seq=2 win=64240

Le port TCP 139 est fermé (ou l’accès a été rejeté par le firewall) :

# hping2 -c 3 -s 53 -p 139 -S 192.168.0.1
 
HPING 192.168.0.1 (eth0 192.168.0.1): S set, 40 headers + 0 data
ip=192.168.0.1 ttl=128 id=283 sport=139 flags=R seq=0 win=64240
ip=192.168.0.1 ttl=128 id=284 sport=139 flags=R seq=1 win=64240
ip=192.168.0.1 ttl=128 id=285 sport=139 flags=R seq=2 win=64240

Le port TCP 23 est bloqué par un routeur ACL :

# hping2 -c 3 -s 53 -p 23 -S 192.168.0.254
 
HPING 192.168.0.254 (eth0 192.168.0.254): S set, 40 headers + 0 data
ICMP unreachable type 13 from 192.168.0.254
ICMP unreachable type 13 from 192.168.0.254
ICMP unreachable type 13 from 192.168.0.254

Les paquets TCP ont été supprimés par un dispositif de sécurité pendant leur transit ! (règle drop d’un firewall)

# hping2 -c 3 -s 53 -p 80 -S 192.168.10.10
HPING 192.168.10.10 (eth0 192.168.10.10): S set, 40 headers + 0 data
(aucune réponse)

7.5 – FireWalk

L’outils firewalk n’est pas un outil de scan à proprement parler, mais mériterai un article entier . Firewalk a été développé par Dave Goldsmith et Mike Schiffman.

Sans s’étendre sur le sujet, cet outil fonctionne comme un balayeur systématique de ports et est capable de détecter des ports ouverts derrière un firewall. Firewalk fonctionne en construisant des paquets avec un IP TTL calculé de façon à expirer sur un segment situé après le firewall.

En fait, si le paquet est autorisé par le firewall, il pourra le passer et expirera comme prévu en envoyant un message « ICMP TTL expired in transit ». A l’inverse, si le paquet est bloqué par l’ACL du firewall, il sera abandonné et aucune réponse ne sera envoyée ou bien un paquet de filtre « communication administratively prohibited » ICMP de type 13 sera envoyé.

Exemple concret d’un test des ports TCP 135 à 140

# firewalk -pTCP -S135-140 10.22.3.1
192.168.1.1
Ramping up hopcounts to binding host ...
probe: 1 TTL: 1 port 33434: expired from [....]
probe: 2 TTL: 2 port 33434: expired from [....]
probe: 3 TTL: 3 port 33434: Bound scan at 3 hops [....]
port 135: open
port 136: open
port 137: open
port 138: open
port 139: *
port 140: open

L’exemple suivant teste les filtres mis en place en sélectionnant les ports TCP (21, 22, 23, 25, 53, et 80). On a besoin de 2 IPs : la passerelle (gw.test.org ici) et la cible (www.test.org ici) qui est DERRIERE la passerelle.

# firewalk -n -S21,22,23,25,53,80 -pTCP gw.test.org www.test.org
 
Firewalk 5.0 [gateway ACL scanner]
Firewalk state initialization completed successfully.
TCP-based scan.
Ramping phase source port: 53, destination port: 33434
Hotfoot through 217.41.132.201 using 217.41.132.161 as a metric.
Ramping Phase:
 
1 (TTL 1): expired [192.168.102.254]
2 (TTL 2): expired [212.38.177.41]
3 (TTL 3): expired [217.41.132.201]
 
Binding host reached.
Scan bound at 4 hops.
Scanning Phase:
 
port 21: A! open (port listen) [217.41.132.161]
port 22: A! open (port not listen) [217.41.132.161]
port 23: A! open (port listen) [217.41.132.161]
port 25: A! open (port not listen) [217.41.132.161]
port 53: A! open (port not listen) [217.41.132.161]
port 80: A! open (port not listen) [217.41.132.161]
 
Scan completed successfully.

Premièrement, l’outil effectue un traceroute vers la cible pour calculer le nombre de sauts. Ensuite, il envoie des paquets TCP avec des champs TTL spécifiques. Puis il analyse les réponses, en particulier les messages de type 11 ICMP code 0. En faisant ensuite un peu de « reverse-analyse » on peut trouver les règles de gw.test.org

Quelles sont les parades à firewalk? Il est possible de bloquer les paquets ICMP TTL EXPIRED au niveau de l’interface externe, mais le problème est que ses performances risquent d’en prendre un sérieux cou car des clients se connectant légitimement ne seront jamais ce qui est arrivé à leur connexion…

7.6 – Scanners en ligne

Un autre moyen de sonder une cible sans passer par notre propre machine, donc sans se faire loguer ou presque, est d’utiliser les outils de balayage « online ».

En effet, ce n’est plus la machine « pirate » qui envoie la requête vers la machine cible, mais c’est le site web proposant ce service qui va envoyer à notre place la requête de scan et qui nous remonte la la réponse via HTTP.

On est alors *presque* anonyme. Dans le sens où c’est l’outil en ligne qui peut nous logguer.

Voici des exemples de scanner en ligne :

  • Le sanner TCP online de FrameIp qui permet de scanner une rangée de ports TCP.
  • L’outil NQT (Network Query Tool) est aussi intéressant dans le mesure où il pratique plusieurs types de scan (Resolve/Reverse Lookup, enregistrement DNS, Whois, ping de port, traceroute,…).
  • Nmap version web, le petit dernier, mais très intéressant aussi. Le puissant scanner online couplé avec une chaîne de Proxy peut être doté d’un bon niveau d’anonymat pour scanner une cible.

8 – Comment se protéger

Voici quelques conseils pour filtrer voire contrer les scans.

  • Filtrer les messages ICMP auprès du réseau externe, par l’intermédiaire des routeurs et firewalls. Cela forcera le pirate à employer de véritables balayages de port de TCP pour tracer votre réseau correctement, ce qui a pour avantage d’être logué par les IDS. Il faut aussi avoir conscience des impacts que cela peux engendrer. La première chose étant que l’on ne respecte plus les différentes RFC.
  • Filtrer les messages ICMP de type 3 (destination port unreachable) auprès des routeurs et firewalls pour empêcher le balayage UDP et le firewalking d’être efficace.
  • Configurer correctement vos firewalls de sorte qu’ils puissent identifier les balayages. Vous pouvez configurer les firewalls commerciaux (de type CheckPoint, NetScreen, PIX, ou IPtable) pour empêcher les balayages rapides de ports et les inondations SYN (SYN flood). Il y a beaucoup d’outils tels que portsentry qui peut identifier les scans et peut ignorer les paquets provenant d’un IP donnée pendant une période donnée.
  • Evaluer comment votre firewall gère les paquets fragmentés IP en utilisant par exemple fragtest et fragroute.
  • S’assurer que vos routeurs et firewalls ne peuvent pas être outrepassés en utilisant des ports spécifiques ou des techniques de modifications d’adresse (spoofing).
  • Si vous hébergez des serveurs FTP publiques, assurez-vous que vos firewalls ne sont pas vulnérables aux attaques des commandes mal formées de « PORT » et de « PASV ».
  • Dans tous les cas, le firewall doit avoir le dernier patch installé, et avoir des règles d’anti-spoofing bien définis (pour empêcher les IP spoofés).
  • Utiliser dans la mesure du possible des servers proxys. Mais ça ne change pas que l’on peux scanner les Proxy: ils ne redirigeront pas les paquets fragmentés et mal formés, ce qui rend impossible l’attaque FIN/NULL… vu précédemment.

9 – Conclusion

Les outils présentés ici sont d’une simplicité étonnante et efficace. N’importe qui peut effectuer un balayage de ports sur vos machines et réseaux, analyser vos ports ouverts et détecter la version des services tournant dans le but de la comparer avec des bases de données d’exploits (SecurityFocus, Milworm, osvdb…)

Il est vrai qu’un Scan n’est pas une attaque en soit, mais il faut être réaliste et prendre conscience que cela représente une approche et donc un risque potentiel.

Dans un souci de sécurité, il faut mieux que vous soyez le premier à effectuer ces tests, avant que des pirates avec des objectifs différents le fassent pour vous. Ainsi, vous découvrirez vos propres faiblesses et éventuelles erreurs humaines d’administration. De plus, les tests, qu’ils soient réalisés par vous-même ou par un sous-traitant, devront être récurent car les techniques évolues et votre architecture vie.

Il existe bien sur d’autre outils open source ou non dédié à la recherche de vulnérabilités. Citons entre autres SARA ou SAINT (anciennement SATAN), Raccess, et CiscoTorch (dédié à l’analyse d’équipements Cisco).

En tant que responsable d’un SI, vous devez absolument logguer se qui ce passe pour les raisons suivantes :

  • Pour le pro activité et ne pas attendre le clash
  • Pour le respect de la loi et donc prise en compte de sa responsabilité en cas de problème
  • Pour que vos équipes comprennent se qu’il se passe sur votre architecture Sécurité en cas de soucis (fait office aussi de veille technologique)

10 – Suivi du document

Création et suivi de la documentation par Jérémy AMIOT et _SebF

11 – Discussion autour des scanner de ports TCP et UDP

Vous pouvez poser toutes vos questions, faire part de vos remarques et partager vos expériences à propos des scanner de ports TCP et UDP. Pour cela, n’hésitez pas à laisser un commentaire ci-dessous :

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *