Cartographie et contrôle de la congestion du réseau

Par 4N9e

Sommaire :

• I. Introduction ;
• II. Explicit Congestion Notification ;
• III. Stratégie Nmap ;
• IV. Synthèse ;

I. Introduction

Dans sa dernière version, Nmap introduit la possibilité pour l'utilisateur de préciser les drapeaux qu'il souhaite fixer dans ses en-têtes TCP. Jusqu'à présent cela était possible avec les drapeaux classiques SYN, ACK, RST, FIN, URG, etc... Il est à present possible d'utiliser les derniers drapeaux de contrôle de congestion (ECN), ECE et CWR pour forger ses propres paquets de test (probes).

Le contrôle de congestion du réseau est défini depuis 2001, mais pas encore universellement utilisé par les divers équipements d'extrémité. De ce fait, Nmap considérant encore ceci comme suffisament discriminant au niveau de ces équipements (entre ceux qui en sont capables et les autres), il employait déjà cette technique au sein de son moteur de détection d'OS depuis la version 4.20 (stable).

En réalite, outre la détection des OS ces drapeaux peuvent se révéler utiles dans d'autres stratégies de scan qui n'ont pas forcément besoin d'une détection complète du système (dans un premier temps du moins). Celle-ci peut être même pénalisante à la fois dans le cas de scans de grands réseaux, augmentant de facon dramatique le temps du travail, mais aussi du fait du caractère très bruyant des nombreux probes envoyés sur une cible lors du processus de détection. Il était donc nécessaire d'offrir à l'utilisateur la possibilité d'exploiter ces drapeaux un peu particuliers à sa guise.

II. Explicit Congestion Notification

Le traffic que doit supporter un équipement de filtrage/routage du réseau peut être énorme en terme de paquets à traiter, et devenir même ingérable quand la charge du réseau devient critique pour sa capacité de traitement.

Pour surveiller et réagir à cette augmentation du traffic divers mécanismes existent ou sont expérimentés, l'un d'eux étant donc l'ECN : le contrôle de congestion.

Basiquement le principe est simple : il consiste pour l'équipement à prévenir son interlocuteur que sa capacité maximum risque d'etre atteinte. En réponse, pour faire simple celui ci réduit la taille de ses paquets.

Ainsi non seulement la congestion est évitée, mais en plus la rapidité du réseau est plus ou moins améliorée selon les cas (parfois grandement dans le cas des LAN, moins dans le WAN mais nous y reviendrons)

Toutefois comme on l'a dit, tous les équipements ne sont pas capables de gérer cette technologie. Il est donc nécessaire de mettre en place un protocole de reconnaissance entre les hôtes capables de la gérer.

Pour ceci, on utilise deux drapeaux : ECE pour ECN-Echo et CWR pour Congestion Window Reduced.

Le mécanisme est semblable au classique three way handshake, puisqu'il s'intègre à celui ci :

Un premier contact avec SYN et ECE, CWR actives. Ainsi, l'émetteur indique au destinataire qu'il sera capable de participer à la gestion ECN dans la suite de la communication. Dans le même temps, il demande à son correspondant si lui aussi en est capable.

La réponse doit être alors un SYN-ACK, ECE si l'équipement approuve et indique qu'il est lui aussi capable de gérer l'ECN.

Le troisième temps interviendra dans le cours de la communication en cas de congestion du réseau, avec l'utilisation du drapeau CWR. Au moment de la congestion, la source n'a pas encore conscience de celle ci. C'est le destinataire qui constate le début de congestion, et doit en avertir la source afin qu'elle puisse prendre les mesures de réduction nécessaires comme elle s'y est engagée au début de la transaction en se signalant comme étant ECN-capable.

A ce niveau la, le destinataire ne rejette donc pas simplement les paquets, mais considère l'ECN comme un gage de confiance et répond donc en placant un drapeau ECE avec un ACK comme un signal d'alerte à destination de la source.

La source est alors sensée reduire la fenêtre de congestion (algorithme Van Jacobson Congestion Avoidance), et répondre par un CWR qui indique au destinataire que les mesures ont été prises, et qu'il n'est plus nécessaire d'envoyer des ACK-ECE.

Il est évident que les règles d'applications de ce procédé sont un peu plus compliquées, ceci afin d'éviter les attaques de déni de service depuis de vrais hôtes zombies ou de paquets à l'ip spoofée : dans le cas où un hôte ECN-capable recevrait une masse d'alertes de congestion, étant alors sensé réduire son traffic en réponse il pourrait être globalement grandement ralenti, voire rendu muet. Par exemple l'une des limitations est le fait que le mécanisme ECN ne soit pas pris en compte dans le cas de paquets retransmis.

III. Stratégie Nmap

Comme on l'a dit, le mécanisme ECN n'est pas universellement deployé. En réalite, on le trouve sur les équipements Cisco par defaut si l'IOS est >=1.2.2, tout spécialement sur les Cisco Localdirector 430 (OS 2.1), AIX v4.2, SunOS 4.0.3, Solaris >=2.5 et Cisco X.25/TCP/LAT Protocol Translator. Linux ( >= 2.4) et BSD sont plus aléatoires parceque ce support est un paramètre choisi de l'administrateur (option CONFIG_INET_ECN dans le kernel, puis /proc/sys/net/ipv4/tcp_ECN par exemple sous linux).

Toutefois on peut s'attendre à rencontrer dans ce cas les linux versions précitées, et FreeBSD >=2.2.1

Avant d'aller plus loin, revenons tout de suite sur un problème évoqué au début de cet article :

Les performances WAN/Internet

Comme on l'a dit, ECN est impliqué dans une des nombreuses techniques disponibles à un attaquant dans le cadre de dénis de service. De ce fait, outre les règles d'auto protection de ce mécanisme, l'infrastructure elle même peut souvent filtrer le genre de paquet affichant les flags ECE et/ou CWR.

Il faut aussi avoir conscience du caractère éventuellement asymétrique de la connexion : le routage d'un paquet peut ne pas être le même que celui de sa réponse.

En conséquence, trouver une seule voie qui laisse passer l'ECN peut ne pas suffir, les réponses pouvant être bloquées sur le trajet de retour. Ce genre de technique employée sur un réseau de type WAN peut donc ne pas fonctionner faute de reponse.

Voici pourquoi :

Sur Nmap, on définit les drapeaux devant être actifs dans les paquets envoyés grâce à l'option --scanflags suivie de la liste des drapeaux URG, ACK, PSH, RST, SYN, FIN, ECE et CWR.

Cette option est prévue pour être accompagnée d'un type de scan que l'utilisateur choisit parmi les types connus : -sS, -sA, -sM etc...

Quels que soient les drapeaux choisis par --scanflags, Nmap interprètera le résultat selon les règles définies par le type de scan choisi.

C'est à dire que par exemple un SYN stealth scan -sS envoie un paquet (normalement SYN, mais la cela dépend de ce qui a été mis en argument de --scanflags), et déclare le port ouvert si il reçoit un SYN-ACK en réponse. Il sera filtré si Nmap ne reçois pas de réponse.

Quand on modifie les paquets envoyés, il faut donc bien connaitre le comportement du type de scan qu'on aura choisi afin de pouvoir interpreter correctement la réponse de Nmap.

En pratique, si on utilise la définition des drapeaux c'est qu'on a une assez bonne idée de ce que l'on attend en retour. Le plus simple sera donc d'associer un -sS, dont l'interpretation est la plus aisée et dont le comportement du réseau vis a vis de lui est le plus prévisible (c'est juste un half -connect après tout).

Pour revenir au sujet qui nous préoccuppe, c'est un mécanisme ECN qu'on va devoir simuler afin de découvrir les hôtes ECN-capables.

Comme on l'a vu, le principe est d'envoyer un SYN avec tous les drapeaux ECN actifs pour se signaler au destinataire comme ECN-capable, et lui demander par la même occasion ce qu'il en est de son côté.

Il est important aussi afin d'avoir une réponse d'être sûr de faire cette discussion sur un port ouvert, afin de pouvoir interpréter par la suite le résultat sans erreur.

Dans un premier temps, il faut donc déterminer les ports ouverts sur un hôte du réseau qu'on suspecte d'avoir un rôle de filtrage/routage au sein du réseau (filtrage est à prendre au sens large, pas au sens de firewall) :

nmap -sS -p22,23,80,443

Ca, c'est la version simple pour le cas d'une seule cible. Si on effectue la recherche sur une grande plage d'adresses, on va devoir optimiser la vitesse de cette étape. Pour cela on utilise l'option --defeat-rst-ratelimit.

Explication :

Toujours pour lutter contre le scan et les attaques de déni de service, de nombreux dispositifs de filtrage limitent la fréquence à laquelle ils répondent aux paquets par un RST lorsque ces paquets arrivent trop nombreux et trop vite.

En temps normal, Nmap mesure cette vitesse de réaction de la cible, et cale son timing d'envoi en conséquence. Et ca peut monter très haut, jusqu'à plusieurs secondes !

L'option --defeat-rst-ratelimit va inhiber simplement ce méchanisme de Nmap, qui n'attendra pas les réponses qui n'arrivent pas pour donner son avis sur le port.

La contrepartie est que face a un tel dispositif de protection, comme Nmap risque de rater des RST, il peut ne plus faire la difference entre un port fermé et un port filtré (RST ou pas de réponse reçue). Par contre, il ne se trompera pas sur un port ouvert, et c'est tout ce qui nous intéresse.

Ayant à présent défini notre port cible parmi les ports ouverts sur la cible, il faudra avoir recours à un outil d'écoute du trafic en parallèle à Nmap afin de s'assurer du contenu exact de la réponse de notre cible.

Nous allons voir pourquoi :

Imaginons que le port distant 22 soit ouvert sur la cible. On sait que la négociation doit commencer par un SYN accompagné de tous les drapeaux ECN (ECE et CWR). On va envoyer la requête ECN comme suit ( -n demande juste à Nmap de ne pas résoudre le nom de domaine, pour gagner du temps) :

nmap -sS -n --scanflags SYNECECWR -p22

Si on obtient un 22/tcp filtered ssh, alors qu'au premier scan on avait bien vérifié qu'on avait un 22/tcp open ssh, c'est perdu : l'hôte n'a pas répondu à la requête ECN et le scan TCP SYN (-sS) considère une absence de réponse comme venant d'un port filtré.

Si par contre on reçoit un 22/tcp open ssh, c'est presque gagné ! presque, car en réalite un hôte peut se comporter de plusieurs façons face à ce genre de paquet :

• - Soit il renvoie un ACK-ECE, et la, c'est vraiment gagné : notre hôte est bien ECN-capable. Vous pourrez lui faire faire tout ce qu'on peut... imaginer de ce mecanisme.
• - Soit il renvoie un ACK-ECE-CWR, et la...c'est raté ! -sS a bien reçu une réponse, mais en fait l'hôte n'est pas ECN-capable : il a juste pris nos drapeaux ECN pour des bits réservés et a decidé d'en faire un echo.

Dans les deux cas la réponse de Nmap sera un grand OPEN, il nous faut donc regarder le contenu des réponses pour en être sûr. Voici une capture Ethereal qui montre deux cas : un hôte qui répond à notre scan, et un autre qui n'est pas ECN-capable

IV. Synthèse

La cartographie du réseau passe par la détermination des noeuds importants, qui sont les points d'accès et de gestion de celui ci. Ceci passe donc, outre les divers serveurs DNS et autres proxies nécessairement par la découverte des passerelles et autres routeurs de celui ci. Souvent un simple scan de version suffit lorsque les bannières sont suffisament explicites mais ce n'est pas toujours le cas.

Pourtant comme on vient de le voir, même dans les conditions de depart les plus difficiles (réseau inconnu, aucune information, bannières dissimulées etc...) il est toujours possible de réflêchir à une stratégie adaptée aux caractéristiques des cibles recherchées.

Dans les réseaux de moyenne et grande importance, l'étape suivante sera d'établir les interconnections sous-jacentes, les sous réseaux desquels dépendent les cibles stratégiques qu'on a reussi à lister. Nmap propose à ce titre, dans ses dernières options, des possibilités qui sont autant de petites fioles dans une boite de petit chimiste. Bien mélangées, elles donnent souvent des résultats surprenants. Mais c'est une autre histoire...

Article paru sur FutureZone ;

Lire ou télécharger le document au format pdf, poids 268 ko : Congestion réseau ;

4N9e

Contacter l'auteur ;