Cartographie et controle de la congestion du reseau

Par 4n9e le 18-03-2007

Depuis la version 4.21-Aplha3, Nmap permet a l'utilisateur de controler les drapeaux de congestion ECN. Explication.

Sommaire :
I. Introduction
II. Explicit Congestion Notification
III. Strategie Nmap
IV. Synthese

I. Introduction

Dans sa derniere version, Nmap introduit la possibilite pour l'utilisateur de preciser les drapeaux qu'il souhaite fixer dans ses en tete TCP. Jusqu'a present cela etait possible avec les drapeaux classiques SYN, ACK, RST, FIN, URG, etc... Il est a present possible d'utiliser les derniers drapeaux de controle de congestion (ECN), ECE et CWR pour forger ses propres paquets de test (probes)

Le controle de congestion du reseau est definit depuis 2001, mais pas encore universellement utilise par les divers equipements d'extremite. De ce fait, Nmap considerant encore ceci comme suffisament discriminant au niveau de ces equipements (entre ceux qui en sont capables et les autres), il employait deja cette technique au sein de son moteur de detection d'OS depuis la version 4.20 (stable).

En realite, outre la detection des OS ces drapeaux peuvent se reveler utiles dans d'autres strategies de scan qui n'ont pas forcement besoin d'une detection complete du systeme ( dans un premier temps du moins ). Celle ci peut etre meme penalisante a la fois dans le cas de scans de grands reseaux, augmentant de facon dramatique le temps du travail, mais aussi du fait du caractere tres bruyant des nombreux probes envoyes sur une cible lors du processus de detection. Il etait donc necessaire d'offrir a l'utilisateur la possibilite d'exploiter ces drapeaux un peu particuliers a sa guise.

II. Explicit Congestion Notification

Le traffic que doit supporter un equipement de filtrage/routage du reseau peut etre enorme en terme de paquets a traiter, et devenir meme ingerable quand la charge du reseau devient critique pour sa capacite de traitement.
Pour surveiller et reagir a cette augmentation du traffic divers mecanismes existent ou sont experimentes, l'un d'eux etant donc l'ECN : le controle de congestion.

Basiquement le principe est simple : il consiste pour l'equipement a prevenir son interlocuteur que sa capacite maximum risque d'etre atteinte. En reponse, pour faire simple celui ci reduit la taille de ses paquets.
Ainsi non seulment la congestion est evitee, mais en plus la rapidite du reseau est plus ou moins amleiroree 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 equipements ne sont pas capables de gerer cette technologie. Il est donc necessaire de mettre en place un protocole de reconnaissance entre les hotes capables de la gerer.

Pour ceci, on utilise deux drapeaux : ECE pour ECN-Echo et CWR pour Congestion Window Reduced.
Le mecanisme est semblable au classique three way handshake, puisqu'il s'integre a celui ci :
Un premier contact avec SYN et ECE, CWR actives. Ainsi, l'emetteur indique au destinataire qu'il sera capable de participer a la gestion ECN dans la suite de la communication. Dans le meme temps, il demande a son correspondant si lui aussi en est capable.
La reponse doit etre alors un SYN-ACK, ECE si l'equipement approuve et indique qu'il est lui aussi capable de gerer l'ECN.
Le troisieme temps interviendra dans le cours de la communication en cas de congestion du reseau, 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 debut de congestion, et doit en avertir la source afin qu'elle puisse prendre les mesures de reduction necessaires comme elle s'y est engagee au debut de la transaction en se signalant comme etant ECN-capable.
A ce niveau la, le destinataire ne rejette donc pas simplement les paquets, mais considere l'ECN comme un gage de confiance et repond donc en placant un drapeau ECE avec un ACK comme un signal d'alerte a destination de la source.
La source est alors sensee reduire la fenetre de congestion (algorithme Van Jacobson Congestion Avoidance), et repondre par un CWR qui indique au destinataire que les mesures ont ete prises, et qu'il n'est plus necessaire d'envoyer des ACK-ECE.

Il est evident que les regles d'applications de ce procede sont un peu plus compliquees, ceci afin d'eviter les attaques de deni de service depuis de vrais hotes zombies ou de paquets a l'ip spoofee : dans le cas ou un hote ECN-capable recevrait une masse d'alertes de congestion, etant alors sense reduire son traffic en reponse il pourrait etre globalement grandement ralenti, voire rendu muet. Par exemple l'une des limitations est le fait que le mecanisme ECN ne soit pas pris en compte dans le cas de paquets retransmis.

III. Strategie Nmap

Comme on l'a dit, le mecanisme ECN n'est pas universellement deploye. En realite, on le trouve sur les equipements Cisco par defaut si l'IOS est >=1.2.2, tout specialement 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 aleatoires parceque ce support est un parametre choisis 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 a rencontrer dans ce cas les linux versions precitees, et FreeBSD >=2.2.1

Avant d'aller plus loin, revenons tout de suite sur un probleme evoque au debut de cet article : les performances WAN/Internet.
Comme on l'a dit, ECN est implique dans une des nombreuses techniques disponibles a un attaquant dans le cadre de denis de service. De ce fait, outre les regles d'auto protection de ce mecanisme, l'infrastructure elle meme peut souvent filtrer le genre de paquet affichant les flags ECE et/ou CWR.
Il faut aussi avoir conscience du caractere eventuellement asymetrique de la connexion : le routage d'un paquet peut ne pas etre le meme que celui de sa reponse.

En consequence, trouver une seule voie qui laisse passer l'ECN peut ne pas suffir, les reponses pouvant etre bloquees sur le trajet de retour. Ce genre de technique employee sur un reseau de type WAN peut donc ne pas fonctionner faute de reponse. Voici pourquoi :

Sur Nmap, on definit les drapeaux devant etre actives dans les paquets envoyes grace a l'option --scanflags suivie de la liste des drapeaux URG, ACK, PSH, RST, SYN, FIN, ECE et CWR.
Cette option est prevue pour etre accompagnee d'un type de scan que l'utilisateur choisis parmis les types connus : -sS, -sA, -sM etc...
Quels que soient les drapeaux choisis par --scanflags, Nmap interpretera le resultat selon les regles definies par le type de scan choisis.

C'est a dire que par exemple un SYN stealth scan -sS envoie un paquet (normalement SYN, mais la cela depend de ce qui a ete mis en argument de --scanflags), et declare le port ouvert si il recoit un SYN-ACK en reponse. Il sera filtre si Nmap ne recois pas de reponse.
Quand on modifie les paquets envoyes, il faut donc bien connaitre le comportement du type de scan qu'on aura choisis afin de pouvoir interpreter correctement la reponse de Nmap.

En pratique, si on utilise la definition des drapeaux c'est qu'on a une assez bonne idee de ce que l'on attend en retour. Le plus simple sera donc d'associer un -sS, dont l'interpretation est la plus aisee et dont le comportement du reseau vis a vis de lui est le plus previsible (c'est juste un half -connect apres tout).

Pour revenir au sujet qui nous preoccuppe, c'est un mechanisme ECN qu'on va devoir simuler afin de decouvrir les hotes ECN-capables.
Comme on l'a vu, le principe est d'envoyer un SYN avec tous les drapeaux ECN actives pour se signaler au destinataire comme ECN-capable, et lui demander par la meme occasion ce qu'il en est de son cote.
Il est important aussi afin d'avoir une reponse d'etre sur de faire cette discussion sur un port ouvert, afin de pouvoir interpreter par la suite le resultat sans erreur.

Dans un premier temps, il faut donc determiner les ports ouverts sur un hote du reseau qu'on suspecte d'avoir un role de filtrage/routage au sein du reseau (filtrage est a 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 etape. Pour cela on utilise l'option --defeat-rst-ratelimit. Explication :
Toujours pour lutter contre le scan et les attaques de deni de service, de nombreux dispositifs de filtrage limitent la frequence a laquelle ils repondent aux paquets par un RST lorsque ces paquets arrivent trop nombreux et trop vite.
En temps normal, Nmap mesure cette vitesse de reaction de la cible, et calle son timing d'envoi en consequence. Et ca peut monter tres haut, jusqu'a plusieurs secondes !
L'option --defeat-rst-ratelimit va inhiber simplement ce mechanisme de Nmap, qui n'attendra pas les reponses 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 ferme et un port filtre (RST ou pas de reponse recue). Par contre, il ne se trompera pas sur un port ouvert, et c'est tout ce qui nous interresse.

Ayant a present definit notre port cible parmis les ports ouverts sur la cible, il faudra avoir recours a un outil d'ecoute du trafic en parallele a Nmap afin de s'assurer du contenu exact de la reponse de notre cible. Nous allons voir pourquoi :

Imaginons que le port distant 22 soit ouvert sur la cible. On sait que la negociation doit commencer par un SYN accompagne de tous les drapeaux ECN ( ECE et CWR ). On va envoyer la requete ECN comme suit ( -n demande juste a Nmap de ne pas resoudre 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 verifie qu'on avait un 22/tcp open ssh, c'est perdu : l'hote n'a pas repondu a la requete ECN et le scan TCP SYN (-sS) considere une absence de reponse comme venant d'un port filtre.

Si par contre on recoit un 22/tcp open ssh, c'est presque gagne ! presque, car en realite un hote peut se comporter de plusieurs facons face a ce genre de paquet :
- Soit il renvoie un ACK-ECE, et la, c'est vraiment gagne : notre hote est bien ECN-capable. Vous pourrez lui faire faire tout ce qu'on peut...imaginer de ce mechanisme...
- Soit il renvoie un ACK-ECE-CWR, et la...c'est rate ! -sS a bien recu une reponse, mais en fait l'hote n'est pas ECN-capable : il a juste pris nos drapeaux ECN pour des bits reserves et a decide d'en faire un echo.

Dans les deux cas la reponse de Nmap sera un grand OPEN, il nous faut donc regarder le contenu des reponses pour en etre sur. Voici une capture Ethereal qui montre deux cas : un hote qui repond a notre scan, et un autre qui n'est pas ECN-capable



IV. Synthese

La cartographie du reseau passe par la determination des noeuds importants, qui sont les points d'acces et de gestion de celui ci. Ceci passe donc, outre les divers serveurs DNS et autres proxies necessairement par la decouverte des passerelles et autres routeurs de celui ci. Souvent un simple scan de version suffit lorsque les bannieres sont suffisament explicites mais ce n'est pas toujours le cas.
Pourtant comme on vient de le voir, meme dans les conditions de depart les plus difficiles (reseau inconnu, aucune information, bannieres dissimulees etc...) il est toujours possible de reflechir a une strategie adaptee aux caracteristiques des cibles recherchees.

Dans les reseaux de moyenne et grande importance, l'etape suivante sera d'etablir les interconnections sous-jacentes, les sous reseaux desquels dependent les cibles strategiques qu'on a reussi a lister. Nmap propose a ce titre dans ses dernieres options des possibilites qui sont autant de petites fioles dans une boite de petit chimiste. Bien melangees, elles donnent souvent des resultats surprenants. Mais c'est une autre histoire...