Protocoles et scanning

Par 4n9e le 25-09-2004

Présentation des protocoles TCP/ IP, et des grandes familles de scans

Rappel sur les protocoles TCP/IP


TCP/IP est la famille de protocoles utilisés pour le transport logique des données sur Internet, et maintenant sur la plupart des réseaux locaux. Ses mécanismes, conçus il y a plus d.une vingtaine d.années, ont été étudiés pour permettre une facilité d.implémentation et d.utilisation, et souffrent de nombreux problèmes de sécurités inhérents.


1 IP


Rappelons les formats des paquets IP. IP est le protocole correspondant à la couche « Réseau » du modèle OSI (bien qu.IP soit antérieur à ce modèle). C.est donc IP qui s.occupe de la notion d.adressage, ici sous forme d.adresse IP sous 4 octets, souvent représentées par la notation a.b.c.d . IP est responsable du routage des paquets de leur source à la destination ; un routage adaptable au vol est d.ailleurs une des problématiques à l.origine d.Arpa, le précurseur d.Internet. IP s.occupe aussi de la fragmentation des paquets, c.est-à-dire
leur découpage en plus petits paquets afin de s.adapter aux contraintes des couches inférieures (physiques). La taille maximum des données que peut véhiculer un support physique donné est exprimée par son MTU (Maximum Transmit Unit) . IP découpe donc les données (fragmentation) pour les adapter au MTU du lien dans le cas d.une transmission, et les regroupe (défragmentation) avant de les remonter aux couches supérieures dans le cas d.une réception de paquet. Finalement, IP veille à ce qu.il n.y ait pas de bouclages de paquets, ou de paquets éternels en attribuant à chacun un Time-to-Live (durée de vie), qui donne le nombre d.interfaces (ou de systèmes, suivant les implémentations) que le paquet peut traverser avant d.être détruit.
Une telle destruction de paquet, lorsque son TTL arrive à 0, génère un message ICMP « Time Exceeded in Transit » qui est renvoyé à l.émetteur du paquet.

Les paquets IP sont constitués de la façon suivante :
(bits)
0 4 8 12 16 18 20 24 28 31
Version IHL Type de service Longueur totale
Identification Flags Offset
TTL Protocole Checksum en-tête
Adresse source
Adresse destination
Options (si présentes) Padding
Données ?
(par exemple, paquet TCP ou UDP)
En-tête IP
(IP header)

Flags :
IP_RF 0x8000 reserved fragment flag
IP_DF 0x4000 dont fragment flag
IP_MF 0x2000 more fragments flag
IP_OFFMASK 0x1fff mask for fragmenting bits

Les données véhiculées par un paquet IP ne sont pas des données brutes de communication d.applications, mais des données d.autres protocoles comme TCP ou UDP, dit de transport, dans le paquet IP. C.est le principe fondamental de l.encapsulation/décapsulation du modèle en couches. Chaque couche rajoute ses données de contrôle dans une en-tête qui lui est propre, les données véhiculées (qui contiennent elles-mêmes des en-têtes) lui sont complètement opaques.


2 TCP


TCP est le protocole IP correspondant au protocole connecté du modèle OSI. TCP s.occupe donc d.assurer un transport fiable d.un service source à un service destination, identifiés tous deux par un numéro dit numéro de port (entre 0 et 65535), en établissant une connexion logique et une vérification de transmission des données, avec retransmission en cas d.erreur (PAR,Positive Acknowledgment with Retransmission).

L.établissement d.une connexion TCP s.effectue par un mécanisme dit de 3-way handshake.
La machine source A désirant établir une connexion envoie un paquet TCP contenant le flag SYN et un numéro de séquence SN=x. La machine recevant la connexion B l.accepte ou non, suivant qu.il y ait ou non un processus prêt à répondre à la demande sur le port destination de la connexion. Dans le cas positif, B répond par SYN ACK, SN=y, et AN=x 1 (numéro d.acquittement). Sinon, A répond par un paquet contenant le flag d.interruption brutale RST.
Lorsque A reçoit le paquet SYN ACK, A émet un paquet contenant le flag ACK et un
acquittement AN=y 1. La connexion est alors établie, le transfert des données peut alors commencer. Les acquittements suivants doivent être effectués pour tous les octets transférés.
 

Format d?un paquet TCP
bits
0 4 8 12 16 20 24 28 31
Port source Port destination
Numéro de séquence
Numéro d?acknowledgment
Offset Reservé Flags Window
Checksum Pointeur urgent
Options Padding
Données
Flags :
TH_SYN 0x02 Bit de Synchronisation
TH_RST 0x04 Réinitialisation (Reset), interruption brutale de connexion
TH_PUSH 0x08 Force le ?push? (délivre les données à l?application)
TH_ACK 0x10 Acknowledgment
TH_URG 0x20 Données urgentes

3 UDP

UDP est le protocole sans connexion de la famille IP. Comme dans TCP, une notion de port source et de port destination est utilisée pour multiplexer/démultiplexer les transferts de données

il est à noter qu.un port UDP n.a aucune relation avec un port TCP, même si les deux couvrent la même notion.

entre les applications d.émission et de réception. Dans le cas d.UDP, aucun établissement de connexion préliminaire n.est effectué, et aucun contrôle du transfert n.est directement assuré.
Dans le cas de l.envoi d.un paquet vers un port non bindé, c.est-à-dire un port sur lequel aucune application n.écoute, un message ICMP « Port Unreachable » est renvoyé à l.expéditeur.


Recherche des machines actives : scan ICMP et TCP

Il s? agit de balayer les adresses IP trouvées dans la phase d.identification et, par adresse, envoier un packet ICMP « Echo Request ». Les machines actives (up) répondent par un paquet ICMP « Echo Reply ».
Le protocole de messages et diagnostics ICMP est cependant souvent filtré, en raison des nombreuses fonctionnalités risquées qu.il présente (par exemple, ICMP « Redirect » permettant de reconfigurer une route). L.agresseur peut donc utiliser en alternative une méthode dite de ACK-scan. Il envoie un paquet TCP vers un service quelconque, contenant le bit ACK positionné dans les flags. Ce paquet ne correspondant à aucune connexion établie, la machine distante, si elle est active, répond par un paquet TCP contenant le flag RST de reset de connexion.
Etant donné que certains filtres IP (firewalls) annoncent le refus des paquets par un message ICMP, le scan ICMP permet donc aussi de faire une découverte rudimentaire des règles de filtrage IP.


Port scanning TCP et UDP

L.idée de ce type de scan, le plus important et le plus répandu, est d.obtenir la liste des services en écoute sur les machines distantes. Ces services sont susceptibles d.être fournis par des applicatifs contenant des bugs de sécurité, tels que les bugs d.implémentation que nous décrirons dans la phase suivante.
L.agresseur envoie donc, par IP (active) et par port intéressant, des paquets qui, suivant la réponse qu.ils génèrent, permettront de dire si le port est ouvert (en écoute) ou non.
L.envoi d.un paquet vers un port donné est appelé probe vers ce port.

La découverte et la publication d.un bug sur telle ou telle application serveur publique, comme en janvier 2001 le serveur de noms DNS bind d.ISC entraîne très souvent des milliers de scans de pirates pour les ports correspondants aux applicatifs incriminés, le port 53 (TCP et UDP) dans le cas de bind. Les ports scannés sont donc principalement les ports associés à des services contenant des vulnérabilités connues, et non des ports libres. En particulier, les scans visent la plupart du temps les ports inférieurs à 1024, historiquement
réservés aux services publics tels que DNS (53, en TCP et UDP), http (80 en TCP), portmap (111 en TCP), POP3 (110 en TCP).

Le scanning de ports étant assez bruyant au niveau des enregistrements (logs) des firewalls ou des systèmes de détection d.intrusion, de nombreuses variations existent pour assurer la furtivité des scans. Nous distinguons en particulier :

TCP connect scan

Ce type de scan, le plus simple à implémenter car il ne nécessite aucune manipulation de paquet, tente d.établir une connexion légitime avec le port visé de la machine distante. C.est aussi le scan le plus visible.

UDP scan

L.unique technique de scanning UDP consiste à envoyer un paquet au port UDP visé et attendre un éventuel message de réponse ICMP « Port Unreachable ». Si ce message est reçu, le port est fermé ou filtré. Cependant, le scan UDP est peu fiable car il est nécessaire que l.ICMP soit autorisé en sortie. D.autre part, de nombreuses stacks IP empêchent l.envoi trop rapide de réponses ICMP (au maximum 80 messages toutes les 4 secondes sous Linux par exemple, technique dite de throttle).

TCP SYN Scan

Le SYN Scan consiste à réaliser seulement une partie du 3-way handshake de l.établissement d.une connexion TCP, d.où son autre nom de half-open scan. L.agresseur envoie un paquet contenant le flag SYN au port à tester de la machine cible. Si celle-ci répond par un paquet contenant les flags SYN ACK, alors le port est ouvert et un service y est disponible. Sinon (cas
où la cible répond par RST), le port est fermé. Une fois l.état du port déterminé par la réponse de la cible, l.agresseur ne finalise pas l.établissement de la connexion par un ACK mais détruit la connexion au moyen d.un RST. La connexion n.apparaît donc pas dans les logs des services de
surveillance orientés connexion, tels que les tcpwrappers. Un tel scan est par contre détectable assez facilement par un système de détection d.intrusion en surveillant les paquets SYN.

TCP FIN Scan, NULL Scan, XMAS Scan6

D.après le RFC 793, la couche TCP/IP d.un système d.exploitation doit répondre par RST à tout paquet adressé à un port fermé, tandis qu.elle doit ignorer et ne pas répondre aux paquets non SYN adressés aux ports ouverts. L.idée des scans FIN, NULL et XMAS est d.utiliser des paquets contenant respectivement le flag FIN, aucun flag, les flags FIN URG et PUSH pour vérifier cette condition. Cependant quelques systèmes ne suivent pas les spécifications posées dans le RFC, et ces scans s.avèrent inopérants sur les plate-formes Microsoft (Windows NT et 9x), Cisco IOS, BSDI, HP/UX, SGI Irix.
Ce type de scan est très difficile à détecter pour un IDS réseau, car il lui faudrait mémoriser toutes les connexions afin de déterminer si le FIN correspond à une connexion réellement établie ou non. Les IDS réseau reconnaissent les scans FIN en remarquant les rafales de paquets FIN vers différents ports en un laps de temps très courts. Insérer un délai suffisant entre les probes permet d.éviter la détection de ces scans.

FTP bounce scanning

Le protocole FTP pose une communication à deux canaux pour le transfert de fichiers: une communication vers le port TCP 21 du serveur est établie par le client et sert de canal pour les commandes, un autre canal est établi à partir du port source 20 vers un port libre aléatoire côté client pour le transfert des données (listing des fichiers, envoi ou réception de fichiers)
proprement dites.
Ce mécanisme, outre les autres failles inhérentes de FTP (à savoir, passage en clair des identifiants et mots de passe), présente un risque de sécurité important car l.IP et le port vers lesquels le serveur effectuera la connexion de retour pour l.envoi des données sont spécifiés par le client, au moyen d.une commande PORT x,x,x,x,y,y (où x,x,x,x est l.adresse IP, octets séparés par des virgules et y,y sont les deux octets du numéro de port). Le client est donc libre de spécifier n.importe quelle IP et n.importe quel port. Si aucune vérification n.est effectuée côté serveur, celui-ci ira établir une connexion vers une machine tiers. Un agresseur peut ainsi effectuer un scan de ports au moyen de la commande PORT, répétée autant de fois que nécessaire. Les messages d.erreurs renvoyés par le serveur FTP indiquent que le port spécifié
n.est pas ouvert ou est filtré. Un transfert effectué sans erreur indique au contraire que le port est ouvert.
Même si la plupart des implémentations actuelles de serveurs FTP interdisent de telles commandes PORT, de nombreuses machines sur Internet contiennent encore des serveurs FTP affectés qui peuvent servir de relais pour des scans, sans même que l.agresseur ait besoin d.en prendre le contrôle (en se connectant au serveur en ftp anonyme, par exemple). En effet, la machine source du scan sera vue par la cible comme étant le serveur FTP. D.autre part, dans le cas de réseaux protégés par un filtre, la présence d.un serveur FTP vulnérable à une telle
attaque peut être utilisée pour passer le filtre avec les règles relatives à la machine hébergeant le serveur FTP.


Techniques avancées de scanning

Voyons ici quelques techniques mettant en défaut certains filtres IP (firewalls) et IDS.


Ports sources spéciaux

Comme nous venons de voir, le protocole FTP s.attend à ce que toute communication de données soit faite avec comme port source au niveau serveur le port 20, et comme destination un port quelconque côté client. Ceci est souvent pris en compte dans les règles de firewall en incluant une règle, extrêmement dangereuse, acceptant toute connexion entrante sur le réseau dont le port source est 20. Ce type de règle est à proscrire; il est très facile de choisir le port
source d.une connexion et un firewall arborant une telle règle est équivalent à pas de firewall au niveau TCP. Des outils (nmap (http://www.insecure.org/) et ADMfzap (ftp://adm.freelsd.net/pub/ADM/) permettent même de positionner le port source de n.importe quelle connexion à une valeur donnée, sans besoin de modifier les logiciels eux-mêmes.
Un autre port source souvent accepté en entrée, cette fois-ci pour UDP, est le port 53, qui correspond à la source d.une requête DNS. De nombreuses configurations de firewalls incluent par facilité des règles telles que « accepter tout paquet vers notre serveur DNS ayant comme port source 53 », exposant ainsi le serveur entier à des attaques sur des services UDP autres
que DNS.

Rebonds au travers de proxies applicatifs

De nombreuses organisations disposent de proxies applicatifs dans des buts de sécurité (socks, firewalls applicatifs tels que NAI Gauntlet) ou d.optimisation du trafic Internet (proxy-cache http).
Ces proxies, lorsqu.ils sont mal configurés, peuvent servir de rebonds à un utilisateur extérieur pour attaquer le réseau interne ou un autre réseau de façon anonyme. Les proxies les plus recherchés par les pirates sont les proxies http (Les caches http tels que Microsoft Proxy Server, Squid, permettent aussi d.émettre des connexions non
http, notamment au moyen des méthodes POST et CONNECT. ) et Wingate, souvent utilisables sans authentification.

Fragmentation IP

Une des fonctionnalités rendues par IP est la fragmentation des paquets pour les adapter aux contraintes de taille du support physique, le lien. Ainsi, il est possible de découper les paquets de telle façon que les informations nécessaires au firewall pour décider de l.acceptation ou non du paquet soient distribuées sur plusieurs fragments, en coupant par exemple l.en-tête TCP en deux. Les alternatives possibles pour le firewall sont alors l.acceptation/le refus sans examen du paquet ou l.attente des autres fragments pour pouvoir défragmenter le paquet et ainsi disposer de l.en-tête complet pour faire la décision de passage. Dans de nombreux cas (en particulier dans les filtres IP simples des routeurs, sur les réseaux à grand débit), le coût de cette défragmentation est trop important et seuls les fragments d.offset 0 (censés contenir les informations de décision) sont inspectés, les autres sont par défaut acceptés.

Ouf !
 

        4N9e pour FutureZone, 2004