• Aucun résultat trouvé

Attaques permettant de prendre l’empreinte réseau du système

Dans le document sécurité réseau (Page 65-69)

Parmi les informations que doit récolter un pirate, celles concernant le système d’exploi-tation du serveur visé sont primordiales. Diverses techniques d’attaques d’une efficacité variable permettent d’y parvenir.

Pour l’utilisateur moyen, la seule méthode permettant de détecter le système d’exploita-tion consiste à examiner les bannières des services réseau, pour peu que celles-ci fournis-sent ce renseignement. Cependant, grâce aux spécificités des implémentations de la pile TCP/IP de chaque constructeur, il est possible de déterminer avec une bonne précision le système d’exploitation d’un système.

38 IDPR, Control Message Transport Protocol

39 TP++ Transport Protocol

40 IL Transport Protocol

41 IPv6 over IPv4

42 SDRP (Source Demand Routing Protocol)

43 IPv6 Routing header

44 IPv6 Fragment header

45 IDRP (Inter-Domain Routing Protocol)

46 RSVP (Reservation Protocol)

47 GRE (General Routing Encapsulation) 48 MHRP (Mobile Host Routing Protocol)

49 BNA

50 ESP (Encapsulating Security Payload)

51 AH (Authentication Header)

52 Integrated Net Layer Security TUBA

53 IP with Encryption

54 NARP (NBMA Address Resolution Protocol) 55 Minimal Encapsulation Protocol

56 TLSP (Transport Layer Security Protocol) using Kryptonet key management

57 SKIP

Tableau 2.1 Valeurs du champ protocole dans une trame IP (suite)

L’empreinte TCP

Lors de l’échange de paquets TCP pour l’ouverture d’une session entre deux ordinateurs, des attributs sont définis par la pile TCP/IP de chaque système d’exploitation. Sachant que chaque implémentation d’une pile IP/TCP est généralement spécifique du système d’exploitation considéré, il est possible de détecter ce dernier par un court échange de paquets TCP.

Pour fonctionner à partir du protocole TCP, cette méthode nécessite que le serveur visé offre un port en écoute et un port qui n’écoute pas et qui n’est bien sûr pas protégé par un équipement filtrant.

Voici quelques-unes des techniques qui permettent de déterminer le système d’exploita-tion cible :

• Sondage FIN. Contrairement à ce que définit la RFC 793, certaines versions de Windows, BSDi, Cisco IOS, HP/UX, MVS et Irix répondent par un paquet RST à des paquets FIN envoyés vers un port en écoute.

• Sondage de l’en-tête TCP boguée. Certains systèmes d’exploitation, tels que Linux dans des versions inférieures à la 2.0.35, répondent à l’envoi d’un paquet TCP avec un drapeau inconnu (valeur égale à 64 et 128) par un paquet avec ce même drapeau.

• Sondage avec des paquets IP contenant des valeurs invalides. À la réception d’un paquet IP avec des valeurs invalides dans les champs de l’en-tête, les systèmes d’exploitation tels que AIX, HP/UX ou Digital Unix ne répondent pas, alors qu’ils devraient renvoyer un paquet ICMP « destination inaccessible ».

• Sondage avec un numéro de séquence initial TCP. Lors d’une réponse à une rupture de session, le numéro de séquence initial d’un paquet TCP est déterminé de façon différente selon le système d’exploitation. Il en ressort cinq groupes principaux : Les statiques, dont la valeur du numéro de séquence ne change jamais. C’est le cas de certains répéteurs 3Com ou des imprimantes LaserWriter d’Apple.

Les traditionnels 64K (nombre de vieux systèmes Unix), dont le numéro de séquence est toujours égal a 65535.

Les Windows, qui utilisent un modèle s’appuyant sur le temps, en incrémentant le numéro par une valeur fixe à chaque nouvel intervalle de temps atteint.

Les aléatoires, pour lesquels les numéros de séquence sont incrémentés aléatoirement.

C’est le cas avec des versions récentes de Solaris, IRIX, FreeBSD, Digital Unix, Cray, etc.

Les vrais aléatoires (Linux 2.0.x, OpenVMS, les AIX récents, etc.), dont le numéro de séquence est généré aléatoirement sans logique.

Des sous-groupes peuvent en outre être créés au sein d’un groupe. Par exemple, dans le groupe des aléatoires, différents algorithmes de génération sont communs à plusieurs systèmes d’exploitation et permettent ainsi d’améliorer la précision de l’empreinte TCP :

• Sondage avec le bit de non-fragmentation. Certains systèmes d’exploitation initiali-sent le bit de non-fragmentation afin que les paquets qu’ils envoient ne soient pas frag-mentés. La lecture de cet attribut permet de réaliser une discrimination des systèmes d’exploitation. Un système d’exploitation tel que Sun Solaris active ce bit, par exemple, alors que HP-UX 10.30 et 11.0x et AIX 4.3.x ne l’activent pas.

• Sondage par la taille de la fenêtre initiale TCP. Il s’agit ici de récupérer la valeur de la taille de la fenêtre TCP utilisée dans les paquets en retour. Cette valeur, qui est géné-ralement constante, est parfois fixée à d’autres valeurs par certains systèmes d’exploi-tation.

• Sondage par la valeur du ACK. Lors de l’envoi d’un paquet avec les drapeaux FIN, PSH et URG activés vers un port qui n’écoute pas, la plupart des systèmes d’exploita-tion répondent en initialisant la valeur du ACK à celle du numéro de séquence, alors que Windows l’initialise à la valeur du numéro de séquence incrémenté de 1.

• Sondage par les drapeaux TCP. Parce que chaque système d’exploitation a une implémentation unique de la pile TCP/IP, l’échange de messages en faisant varier les drapeaux TCP permet de constituer une source d’information solide sur le système d’exploitation du système visé.

• Résistance à l’inondation SYN. L’inondation SYN est une technique de déni de service d’une pile IP/TCP corrigés depuis par les systèmes d’exploitation. Cependant, le comportement peut être différent d’un système d’exploitation à un autre si on envoie un certain nombre de paquets (avec le drapeau SYN) usurpés sans réponse suivis par une connexion normale. Les champs du paquet de retour peuvent être alors différents pour chaque système d’exploitation.

L’empreinte ICMP

TCP n’est pas le seul protocole permettant de réaliser une empreinte d’un système. ICMP (Internet Control Message Protocol) permet de gérer les informations relatives aux erreurs des systèmes connectés par des sessions IP mais aussi de sonder un réseau afin de déterminer les caractéristiques générales des systèmes qui le composent.

Les messages de contrôle ICMP sont transportés sur le réseau sous la forme de paquets IP. Ofir Arkin a illustré dans ICMP Usage In Scanning v3.0 un grand nombre de techni-ques s’appuyant sur le protocole ICMP, notamment les suivantes :

• Sondage par le champ TTL dans les paquets ICMP. Selon la pile TCP/IP qui émet un paquet ICMP (en réponse à un paquet echo-request, par exemple), la valeur choisie pour le champ TTL (Time To Live) varie. Ces valeurs sont généralement 255, 128, 64 ou 32. L’analyse de cette valeur permet d’affiner l’hypothèse sur le système d’exploi-tation.

• Sondage par le contrôle du débit des messages d’erreur ICMP. Certaines piles TCP/IP des systèmes d’exploitation limitent le débit des différents messages d’erreur qu’elles renvoient. Il est dès lors possible d’envoyer des paquets UDP vers un port qui

n’est pas en écoute et de compter le nombre de messages reçus en retour dans un laps de temps donné.

• Sondage par les réponses ICMP. Il existe de telles différences d’implémentation des messages ICMP, qu’il est possible de déterminer le système d’exploitation en analy-sant des échanges à base de message ICMP.

Le tableau 2.2 récapitule tous les types de codes véhiculés par le protocole ICMP.

Tableau 2.2 Types et codes des messages ICMP

Type Code Message Signification du message

0 0 Réponse à ECHO Envoie un paquet suite à la réception d’un message ECHO.

3 0 Destinataire inaccessible Le réseau n’est pas accessible.

3 1 Destinataire inaccessible La machine n’est pas accessible.

3 2 Destinataire inaccessible Le protocole n’est pas accessible.

3 3 Destinataire inaccessible Le port n’est pas accessible.

3 4 Destinataire inaccessible Fragmentation nécessaire mais interdite 3 5 Destinataire inaccessible Échec d’acheminement

3 6 Destinataire inaccessible Réseau inconnu 3 7 Destinataire inaccessible Machine inconnue

3 8 Destinataire inaccessible Machine non connectée au réseau 3 9 Destinataire inaccessible Communication avec le réseau interdite 3 10 Destinataire inaccessible Communication avec la machine interdite 3 11 Destinataire inaccessible Réseau inaccessible pour ce service 3 12 Destinataire inaccessible Machine inaccessible pour ce service 3 13 Destinataire inaccessible Communication interdite (filtrage)

4 0 Contrôle de flux Un routeur peut être amené à détruire un paquet s’il manque de mémoire. Dans ce cas, il émet ce message à destination de la source du paquet détruit.

5 0 Redirection pour un réseau Lorsqu’un routeur remarque que la route d’un réseau entier n’est pas optimale, il envoie aux hôtes du réseau l’adresse du routeur, diminuant de ce fait le chemin d’acheminement.

5 1 Redirection pour un hôte Lorsqu’un routeur remarque que la route d’un hôte n’est pas optimale, il envoie à l’hôte l’adresse du routeur, diminuant de la sorte le chemin d’acheminement.

5 2 Redirection pour un réseau et un service donné

Lorsqu’un routeur remarque que la route d’un réseau entier n’est pas optimale pour un service donné, il envoie aux hôtes du réseau l’adresse du routeur, diminuant de ce fait le chemin d’acheminement.

5 3 Redirection pour un hôte et un service donné

Lorsqu’un routeur remarque que la route d’un hôte n’est pas optimale pour un service donné, il envoie à l’hôte l’adresse du routeur, diminuant de ce fait le chemin d’acheminement.

8 0 Demande d’ECHO Envoi d’un paquet avec demande de réponse afin de confirmer la pré-sence d’un hôte

Par exemple, HP-UX 10.20, AIX, Ultrix et OpenVMS répondent à des demandes d’information, avec la particularité pour Ultrix et OpenVMS de répondre à une demande de masque d’adresse, contrairement à HP-UX et AIX, qui rejettent le paquet.

• Sondage par les données de débogage associées à un message ICMP. Dans la défi-nition du protocole ICMP, il est indiqué que les messages d’erreur peuvent inclure des données associées au message original ayant causé l’erreur. Ainsi, lors d’un message de port inaccessible, la plupart des systèmes d’exploitation renvoient un en-tête IP et 8 octets supplémentaires. Cependant, Solaris ajoute encore un bit et Linux encore plus de données. Il est de la sorte possible de détecter ces systèmes d’exploitation, même s’ils n’écoutent sur aucun port.

• Sondage par l’intégrité du message d’erreur ICMP renvoyé. Sachant qu’un message ICMP de port inaccessible inclut une partie du message original, certaines machines utilisent l’en-tête du paquet reçu comme une zone de travail pour créer le paquet à renvoyer. Ainsi, certains AIX ou BSDI renvoient un paquet avec un champ

« longueur totale » d’une valeur trop grande de 20 octets, tandis que d’autres renvoient un paquet avec un checksum incorrect ou égal à 0.

• Sondage par type de service. Au sein d’un paquet ICMP d’erreur dû à un port inac-cessible, il existe un champ « type de service ». Dans la plupart des piles TCP/IP, la valeur de ce champ est égale à 0, mais Linux l’initialise à 0xC0.

Dans le document sécurité réseau (Page 65-69)