CHAPITRE 5

Les scanners de ports TCP et UDP.

 

 

1.  Introduction.

2.  Définition.

     2.1  Rappel des terminologies.

3.  Synthèse des différentes méthodes de Scan.

     3.1   Vanilla connect().

     3.2   Half-open SYN flag.

     3.3   Inverse TCP flag.

     3.4   ACK flag probe.

     3.5   TCP fragmentation.

     3.6   FTP Bounce.

     3.7   Proxy Bounce.

     3.8   Sniffer-based spoofed.

     3.9   IP ID header.

     3.10   Scan UDP.

4.  Analyse des réponses TCP.

     4.1   Comment se protéger.

     4.2   Conclusion.

 

1.    Introduction.

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 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.   Définition.

Un scanneur 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 pare-feux 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.

 

2.1    Rappel des terminologies.

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

Fig1. Schéma d’entête TCP.

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é.

Fig2. Schéma d’entête 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é.

Pour toute documentation à propos des différents protocoles cités dans l'article (TCP/UDP), se référer au site .

 

3.   Synthèse des différentes méthodes de Scan.

3.1   Vanilla connect()

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

3.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 pare-feu ou IDS est mis en place.

3.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 pare-feu.

3.4  ACK flag probe.

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

3.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'en-tête TCP qui ne correspond plus à un paquet TCP classique, donc le comportement reste imprévisible.

 

 

3.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 pare-feu  et ses règles d'anti-spoofing.

3.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.

 

3.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.

3.9  IP ID header.

Cette méthode est efficace pour cartographier les réseaux et machines de confiance qui communiquent entre elles (pare-feu ou passerelle VPN). En effet, en analysant l'en-tê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.

3.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)

 

4.   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 pare-feu 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).

 

4.1  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 pare-feux. 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 pare-feux pour empêcher le balayage UDP et le firewalking d'être efficace.

§  Configurer correctement vos pare-feux de sorte qu'ils puissent identifier les balayages. Vous pouvez configurer les pare-feux 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 pare-feu gère les paquets fragmentés IP en utilisant par exemple fragtest et fragroute.

§  S'assurer que vos routeurs et pare-feux 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 pare-feux ne sont pas vulnérables aux attaques des commandes mal formées de "PORT" et de "PASV".

§  Dans tous les cas, le pare-feu 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.

 

4.2  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)

 

©2007 reseau-securite Mail@ elmahrifa@gmail.com