iGu'T.fr

Aller au contenu | Aller au menu | Aller à la recherche

mardi 27 avril 2010

Amélioration du dissector ISAKMP (IKEv1 & IKEv2)

Il y a quelques mois lors d'un troubleshooting sur du VPN IPsec, je me suis rendu compte que le dissector ISAKMP actuelle de Wireshark était assez limité.

Par exemple, les attributs du Mode Config étaient affichés en hexa

wireshark_xauth1.png

Après une recherche sur le bugtracker de Wireshark, je suis tombé sur ce bug #2905 ou il a été constaté le même probleme !
Ce bug datait de 2008 et n'avais pas bouger..
Après quelques heures de boulot, j'ai proposé un patch qui integre l'ensemble des attributs mode Config, Xauth et quelques attributs proprios.. (Cisco Unity)

Capture d'exemple avec les Xauth decodés

C'est quand même beaucoup plus simple pour le troubleshooting...

Lors du developement de ce patch, je me suis rendu compte que le code n'était pas le plus optimisé et dans le style de Wireshark et qu'il manquait beaucoup d'attribut qui n'avait pas était mise à jour

Par exemple, il y avait beaucoup de proto_tree_add_text qui sont de simples textes qui ne permettent pas de filtrer sur leur contenu.

J'ai donc proposé un second patch (bug #4546) qui ameliore grandement le code et met à jour les attributs.
J'ai aussi proposé quelques petits patch

  • Ajout complet du DPD (Dead Peer Detection) RFC3706 (bug #4542)
  • Ajout de IKEv2 Session Resumption RFC 5723 / Redirect Mechanism for IKEv2 RFC5685 (bug #4619)
  • Amélioration des Attribut Vendor ID (bug #4689 )



Toutes mes modifications (sauf la partie Attribut Vendor ID) sont disponibles dans la version de developement 1.3.4 à télécharger à l'adresse suivante : http://www.wireshark.org/download.html

vendredi 16 avril 2010

Implémentation de la RFC5841 pour Scapy & Wireshark

Comme tous les ans, IETF (l'organisme qui "gère" les RFC) sors une RFC spécial 1er Avril.

Cette année, la RFC s'appelle TCP Option to Denote Packet Mood (RFC 5841 par Google).

Cette RFC défini une nouvelle option TCP (25) pour indiquer l'humeur d'un paquet TCP (Joyeux, Triste...) ...

Apres quelques recherches sur Internet, je n'ai trouvé aucune implémentation de cette nouvelle norme !

J'ai donc utilisé Scapy afin de générer des paquets compatibles avec cette nouvelle norme.

Ca a été l'occasion de découvrir la puissance de Scapy et le langage Python (en effet, il m'a fallu patcher scapy afin de pouvoir supporter l'option 25)

J'ai aussi développé un patch pour Wireshark afin qu'il puisse décoder cette nouvelle option.

Voila quelques screenshots de Wireshark

wireshark_rfc5841_1.png
wireshark_rfc5841_2.png
wireshark_rfc5841_expert_1.png
wireshark_rfc5841_expert_2.png
La capture est disponible sur pcapr.net

Le patch pour Scapy

Le patch pour Wireshark

et un morceau de code en python (qui s'appuie sur Scapy) qui génère l'ensemble des humeurs de la norme

lundi 25 janvier 2010

Remote Monitoring d'un client ou d'une AP Aruba via Wireshark

Il est possible sur les controleurs WiFi Aruba (ou Alcatel) de mettre en place du remote Monitoring pour un point d'accès ou un client WiFi.

Voila la procédure pour la mise en place du Remote Monitoring d'un Point d'Accès.

Dans l'interface d'administration du controleur, Aller dans Monitoring => Access Points

Aruba-Remote_1.png

Selectionner votre point d'accès et cliquer sur Packet Capture

Aruba-Remote_2.png
Dans Target IP, Specifier l'adresse IP de votre machine puis Start

Les trames arrivent directement sur votre machine. Aruba_ERM_nodecoded.png Mais les trames ne sont pas décodés

Aruba fournit une version "speciale " de l'outil Wireshark pour la mise en place du Remote Monitoring, le probleme est que cette version est très vieille (basée sur la release 0.99.7) alors qu'on est en 1.2 pour la version stable !

Aruba-Wireshark-ext-0.99.7.png

J'ai donc crée un dissector (Aruba_ERM) qui permet de decoder directements les trames en provenance du controleur.

Pour cela, il faut au moins la build 1.3.3-SVN 31615 qui est disponible à l'adresse suivante http://www.wireshark.org/download/automated/win32/ (il suffit de prendre une version superieur à la build 1.3.3-SVN31615).

Aller dans les Preferences de Wireshark (Edit => Preferences )
Aruba_ERM_Port.png

Selectionner le Protocole ARUBA_ERM puis rentrer le port utilisé (par défaut 5555) puis Appliquer

Aruba_ERM_decoded.png

Vous pouvez maintenant utiliser toutes les derniers fonctionnalités de Wireshark (comme le déchiffrement WEP ou WPA)

samedi 31 octobre 2009

CAPWAP News 2 !!

Encore quelques nouvelles concernant le protocole CAPWAP...

Dans mon dernier billet, je disais que Cisco utilisait le protocole CAPWAP pour la gestion des points d'accès. Depuis j'ai appris que c'était une version brouillon (draft 8) de la norme

Aussi Zyxel vient d'annoncer un nouveau point d'accès/controleur (Hybrid AP NWA-3166) qui utilise CAPWAP comme protocole de gestion !

J'ai aussi continué à bosser sur mon dissector CAPWAP, le premier patch a été accepté et vous pouvez le tester de developement de wireshark (1.3.1).

Mais depuis on m'a fournit des traces du protocole CAPWAP avec du materiel Cisco, j'ai donc déveloper un second patch qui corrige quelques bugs et rajouter le support de la fragmentation (au niveau CAPWAP) et de nouveau Message Element Type analysé

J'ai rajouté en piece jointe, la derniere version stable de Wireshark avec mes derniers modifications de mon dissector CAPWAP.

Sinon je recherche un projet Open Source qui permettrait la gestion centralisée des points d'accès ( en se basant bien sur CAPWAP).

dimanche 26 juillet 2009

CAPWAP News !!

Quelques nouvelles concernant le protocole CAPWAP...

  • Cisco utilise depuis la version 5.2 de ces contrôleurs WiFi le protocole CAPWAP en natif
  • Aruba a annoncé qu'il n'ajouterait pas le support de CAPWAP pour le moment dans leur contrôleur à cause de doute sur la licence et que le protocole demande obligatoirement l'utilisation d'extension proprietaire pour fonctionner !
  • Il y existe un projet Open Source pour l'implémentation du protocole CAPWAP mais pour le moment le projet est au point mort et se base sur une vieille version de la norme (Draft 09)
  • J'ai réalisé un dissector pour Wireshark du protocole CAPWAP en me basant sur l'implémentation (bugé) Open Source de CAPWAP.


PS : Mon dissector étant encore dans la branche developement de Wireshark, je vous met en piece jointe la derniere version de Wireshark (1.2.1) avec le support du protocole CAPWAP.

vendredi 6 février 2009

Decodage des trames PAPI Aruba dans Wireshark

Suite à mon billet sur le decodage des trames GRE dans Wireshark.

J'ai crée un nouveau patch qui permet de decoder les attributs RADIUS.

Ces modifications ne sont pas encore disponibles dans la derniere version stable de Wireshark, mais elles sont disponibles dans la version de développement (lien vers le dev).

J'ai aussi travaillé sur le decodage du protocole Aruba PAPI, c'est le protocole utilisé pour le controle et la gestion des points d'accès depuis les controleurs WiFi (en attendant CAPWAP ...)

Ce protocole est un protocole proprietaire à Aruba, il y a donc aucune documentation disponible.
Pour la réalisation de "dissector" (Décodeur de trames), j'ai réalisé une analyse des trames capturés entre le controleur WiFi et une borne.
Le protocole se base sur de l'UDP en port 8211 en source et destination. (surement pour passer plus facilement les firewalls...)
Il encapsule un protocole maison de gestion de connexion (type TCP) avec des numeros de sequences, des ports src & dst, un checksum...
et en fonction des ports src & dst une couche "data" (données) differences (Pour la configuration, le Monitoring, le debug...)

Voila quelques screenshots
Wireshark_Aruba_PAPI_1.png Wireshark_Aruba_PAPI_2.png Je joins aussi mon patch sur le protocole PAPI et une version portable pour Windows (basé sur la version 1.1.2) qui integre ce patch.

lundi 20 octobre 2008

Decodage des trames GRE Aruba dans Wireshark.

J'utilise depuis plusieurs mois les produits WiFi Aruba / Alcatel OAW. C'est du WiFi à base de point d'accès leger et d'appliance/controlleur WiFi .

Le flux entre le point d'accès et l'appliance WiFi est encapsulé dans des trames GRE. Et actuellement Wireshark/Ethereal ne sais pas le decoder (les trames sont vu comme GRE Encapsulated 0x8200 (unknown))

Ce flux est simplement des trames 802.11 (avec quelques informations specifiques Aruba) encapuslé dans du GRE.

J'ai donc crée un patch pour Wireshark pour ajouter le "decodage" de ces trames (en fonction des ID GRE) , ce patch a été accepté dans la version officielle.

Donc, la prochaine version stable de Wireshark intégrera directement le decodage des trames GRE. (je signalerais quand ca sera disponible)