C'était un de ces soirs durant lesquels je geeke jusqu'à tomber de sommeil, sauf que là j'étais en vacances. C'est ennuyeux, les vacances. Alors j'ai pris la (sage) décision de mettre à profit mon temps disponible pour avancer mes nombreux projets. Et comme à mon habitude, je n'ai pas pu m'empêcher de diverger et d'aller titiller d'autres sujets. Je ne sais plus trop pourquoi, mais je me suis intéressé à un moyen d'évaluer de manière fiable ou presque le trafic d'un serveur distant, et la première chose qui m'est venue à l'esprit est l'analyse du champ Identification des datagrammes IP.
Premiers tests, et premières déceptions
J'ai donc entamé la recherche d'une méthode efficace permettant d'évaluer le trafic d'un serveur distant, en me basant sur l'évolution du champ Identification du protocole IP. Ce champ est en réalité un compteur sur 16 bits (entier non-signé), incrémenté de 1 à chaque émission de paquet. Au vu des quantités de paquets émis par un serveur, ce compteur boucle assez régulièrement, et il est donc très difficile de déduire quoi que ce soit. Ce champ est aussi souvent appelé IP/ID.
J'ai donc commencé mes tests par le développement d'un outil en Python, utilisant Scapy, et émettant à intervalle très court deux requêtes ICMP Echo Request, calculant le temps de parcours depuis l'envoi, et essayant de déterminer la vitesse d'évolution des IP/ID. L'implémentation n'a pas été un problème en soit, par contre les résultats n'étaient pas au rendez-vous, et pour cause: la mesure de temps n'est pas fiable. En réalité, nous ne disposons que d'une référence pour cette mesure de temps: la machine émettrice. Le réseau Internet étant ce qu'il est nous ne sommes pas sûrs de plusieurs choses: * les paquets peuvent avoir été routés via des chemins différents entre les deux requêtes * des latences réseau ont pu se produire, et faire varier le temps d'émission./réception des paquets Autant de facteurs qui rendent la mesure imprécise, et au vu du laps de temps très court séparant l'envoi des deux paquets, l'erreur introduite est élevée. Il n'est donc pas fiable d'employer cette méthode pour déterminer la quantité de trafic qu'émet un serveur distant.
Les timestamps à la rescousse
Heureusement, le protocole ICMP met à notre disposition d'autres types de messages, comme celui permet de demander à une machine distante de nous envoyer des indications sur son horloge interne (Timestamp), ce qui a pour intérêt de pouvoir nous renseigner sur l'heure d'émission du paquet. En effet, le protocole ICMP étant un protocole de couche 4 (Transport), ses datagrammes sont encapsulés dans des datagrammes IP (protocole couche 3). Autrement dit, en envoyant un message ICMP Timestamp Request (Code:0, Type:13), le serveur distant peut y répondre avec un paquet ICMP contenant notamment un Timestamp paramétré par la machine ayant effectué la requête, et un Timestamp correspondant à l'heure d'émission de la réponse.
Il ne me fallait pas plus de choses pour que j'implémente une variante de l'outil précédent, prenant en compte cette fois-ci une mesure de temps beaucoup plus précise. Bien sûr, il faut que le serveur distant testé réponde à ce type de requête ICMP, ce qui n'est pas monnaie courante. Mais j'ai pu identifier certains sites connus qui y répondent favorablement: www.hsc.fr, www.lemonde.fr, www.lefigaro.fr, etc ... L'exemple ci-dessous, réalisé avec l'utilitaire hping2, démontre bien les réponses reçues:
virtubox:/home/virtualabs# hping2 -1 -K 0 -C 13 -r www.hsc.fr HPING www.hsc.fr (wlan0 217.174.211.25): icmp mode set, 28 headers + 0 data bytes len=40 ip=217.174.211.25 ttl=53 id=21302 icmp_seq=0 rtt=23.3 ms ICMP timestamp: Originate=2647898 Receive=2647955 Transmit=2647955 ICMP timestamp RTT tsrtt=24 len=40 ip=217.174.211.25 ttl=53 id=+15 icmp_seq=1 rtt=24.0 ms ICMP timestamp: Originate=2648899 Receive=2648955 Transmit=2648955 ICMP timestamp RTT tsrtt=24 len=40 ip=217.174.211.25 ttl=53 id=+6 icmp_seq=2 rtt=23.5 ms ICMP timestamp: Originate=2649899 Receive=2649955 Transmit=2649955 ICMP timestamp RTT tsrtt=23
Le timestamp qui m'intéressa fut celui dénommé Transmit, correspondant à l'heure de transmission. Ce timestamp est en réalité le nombre de millisecondes écoulées depuis 00h00, et est donc suffisamment précis pour être utilisé. De là, j'ai développé un premier outil affichant un aperçu visuel du trafic, toujours en Python avec la bibliothèque curses. Le résultat n'est pas super joli, mais fait l'affaire:
J'étais assez satisfait du résultat, bien que cet outil ne casse pas trois pattes à un canard. Néanmoins, après différents tests sur des serveurs publics, j'ai pu noter les inconvénients suivants:
Et cela a commencé à m'ennuyer, je suis donc reparti à la recherche de la méthode ultime permettant de déterminer dans tous les cas de figures la quantité de trafic supporté par une machine distante. Et c'est devenu un poil plus complexe ...
Approche probabiliste
Je me suis rapidement rendu à l'évidence, après plusieurs tentatives infructueuses: réaliser une étude analytique pure de la variation du champ IP/ID est une pure perte de temps, à cause de la faible entropie de ce compteur. Il me fallait partir dans une autre direction, et trouver une approche différente, mais toutefois fiable. Et c'est là que m'est venu l'idée de prendre le problème dans l'autre sens. Si une machine subit un trafic conséquent, alors il devrait être très difficile de prédire la valeur du prochain IP/ID retourné. Il s'agit ici d'une simple constatation probabiliste. Plus il y a de trafic, plus le champ IP/ID varie, et plus il est difficile de prédire sa prochaine valeur. Il existe toutefois un cas de figure, mais qui reste très peu probable: celui où le trafic est conséquent et constant.
Il m'a donc semblé intéressant de tenter cette approche. J'ai donc entamé le développement d'une preuve de concept, toujours en Python, qui visait à réussir une prédiction pour un serveur donné. Malheureusement, ceci est très difficile à obtenir, surtout lorsque l'on cherche à prédire exactement la valeur du prochain IP/ID. J'ai donc introduit une variable représentant une marge d'erreur augmentant progressivement (suite aux tests infructueux), et en faisant varier cette marge d'erreur de manière exponentielle, j'ai pu obtenir des résultants probant.
La recherche de prédiction exacte et/ou approximative permet, lorsqu'elle est réalisée sur une durée suffisamment longue, de pouvoir associer un score (heuristique) à la quantité de trafic émis par la machine distante. Il y a dans le cas présent une relation qui lie cette quantité de trafic (et de manière indirecte, la variation de cette quantité de trafic) à la difficulté de prédiction du champ IP/ID. En évaluant la difficulté de prédiction, on peut tenter de déduire la quantité de trafic. Il sagit d'une méthode probabiliste, aboutissant à un résultat fiable (qualitatif) mais non-quantitatif, permettant d'apprécier la quantité de trafic par rapport à un trafic de référence. Il semblerait toutefois qu'en cas de présence de répartiteurs de charge ou lorsque l'intervalle de temps entre deux mesures est trop grand, la mesure ne soit pas fiable.
To be continued ...
Je suis actuellement en train d'approfondir cette méthode d'évaluation probabiliste, en tentant notamment de lier la difficulté de prédiction d'IP/ID à la quantité de paquets émis par le serveur, bien que cela ne me semble pas évident du tout. De même, je continue mes tests afin de vérifier la validité de mes résultats, bien que pour le moment ils soient positifs.
Je publierai mon analyse dans les détails par la suite, ainsi que le code source de ma preuve de concept.
Samedi se déroulait la neuvième édition de la Nuit du Hack, organisée par Sysdream et la communauté Hackerzvoice. Ce fut une nuit très enrichissante, pleine de rencontres et de pur fun, avec entre 700 et 800 visiteurs (je n'ai pas eu les chiffres officiels à ce jour).
Rude préparation
Cela fait plusieurs mois que l'on travaillait à l'organisation de cette Nuit du Hack 2011: organisation des talks, des workshops, du CTF (sic) et du wargame public. Toute la team hackerzvoice s'est mobilisée, chacun apportant sa brique à l'édifice qui s'agrandit chaque année. Nous avons opté pour un changement d'endroit, les péniches n'étant pas du tout adaptées à ce type d'évènement le choix du New York Hotel de Disneyland fut fait. Le New York Hotel de Disney possède une salle de 2000 mètres carrés, avec une régie, une scène, une sonorisation sur mesure ... Alors oui, quand on a annoncé que ça se passait à Disneyland, les critiques et commentaires ironiques ont fusés sur Twitter.
Du côté technique, le Capture The Flag de cette année a vu son architecture évoluer, peut-être un peu trop quand on voit comment on a missionné à le lancer. Franchement, pour y avoir passé des nuits dessus et avec pas mal de personnes impliquées, je suis sincèrement déçu que cela n'ait pas pu se dérouler dans les conditions voulues. On avait monté deux baies serveur et une palette de machines à la mode NdH2010, tout cablé et testé auparavant.
Rencontre avec les speakers, puis pseudo-dodo
Nous sommes arrivés au New York Hotel le vendredi soir, pour tout installer pour le lendemain. J'ai retrouvé Bruno Kerouanton au pub du NYH, accompagné de Nicolas Grégoire, Gary S. Miliefsky et Mario Heiderich. Ils sont venus nous donner du courage pour la préparation de la Nuit du Hack, et puis on en a profité pour boire un coup avec eux. J'ai retrouvé aussi Winn Schwartau, que j'ai rencontré l'année dernière à Las Vegas lors de la Defcon 18; ça faisait tout drôle de le revoir, avec sa moustache inchangée ;). J'ai passé un vendredi soir magique, j'ai même trouvé le temps de troller sur Hadopi avec Mario Heiderich o/ ! Petite retouche de mes slides pour la forme, avec Sorcier_FXK.
L'installation du matériel et le câblage se sont terminés tard dans la nuit (aux alentours de 3h du matin, le samedi). J'en ai profité pour rejoindre une chambre dans laquelle on a squatté avec Sorcier_FXK (kalkulators.org), Ezano et Franklin (le guru des conférences). Je n'ai dormi que 4h environ, mais ca m'a permis de récupérer un petit peu avant le grand jour.
Jour J, stress au max
Douche, petit-dej sur le pouce, et je débarque dans la salle où va se dérouler la Nuit du Hack 2011. Les régisseurs sont en place, on fait les derniers checks au niveau des écrans et du son, toujours les derniers détails qui posent problème. Je fais un test sur la scène, c'est vraiment impressionnant ... C'est vide mais j'essaie de m'imaginer ça rempli. Les gens commencent à arriver, et là problème: les applications de lecture des QRCodes des badges ne fonctionnent pas (à 30min de mon talk). Je règle le problème en urgence, et je saute sur scène. C'était plus dur que ce que je pensais en fait, de parler devant six ou sept cent personnes, avec un spot dans la tronche. J'ai chaud, je bafouille légèrement, mais j'arrive à gérer le temps et la démo en évitant de la louper. Plutôt cool donc :). Pour ceux que cela intéresse, les slides de mon talk sont disponibles ici.
Le reste de ma journée, je l'ai passée à discuter de temps en temps avec quelques intéressés d'Android, et puis avec le staff du CTF pour tout fignoler. On a essuyé pas mal de problèmes, enchaîné les pépins, et les esprits ont commencé à s'échauffer. Le retard s'accumulait, les problèmes aussi: à chaque problème que l'on pensait résolu s'en ajoutait un second... Aux alentours de 2h du matin, j'ai laissé les autres membres du staff gérer le truc, j'étais trop fatigué et énervé contre des personnes qui faisaient tout leur possible pour mettre ce CTF en route. Je me suis calmé de mon côté, en essayant de faire le vide, de trouver une solution "viable". De leur côté, le staff CTF a tenté de modifier le principe du challenge, mais cela a pris du temps et n'a pas été concluant. La dure décision d'arrêter les frais a été prise par le boss, et on a vu des équipes dégoutées, qui pour certaines étaient plus désolées pour nous et pour le temps que l'on avait passé dessus. Une grosse déception en somme, que j'ai essayé d'atténuer à grand renfort de bière.
En parallèle, le challenge public tournait plutôt bien, et les épreuves se faisaient valider au fur et à mesure que la soirée avançait. Au moins, tout n'aura pas été raté.
Impressions diverses et retours
Les retours que l'on m'a fait de l'évènement sont assez variés, mais dans l'ensemble plutôt bons. Tout le monde y va de son commentaire, de quelques idées qu'il a eu pour améliorer l'évènement, des regrets que cette édition soit plus "corporate" que celles des années précédentes ... Je peux tout à fait comprendre ces remarques et ces réactions. Disney a tout de même permis à l'équipe des organisateurs de se concentrer sur l'essentiel, sans avoir à gérer la logistique de la nourriture et de la boisson, en mettant à disposition de l'évènement une vraie régie son et vidéo, avec des systèmes qui fonctionnaient nickel et que l'on avait pas à gérer de notre côté. Du côté des visiteurs, l'endroit était tout de même hors-normes, avec une salle immense, un grand nombre de place (ah, ça fait toujours plus que sur la péniche) ainsi qu'un certain confort. Le fait de pouvoir louer une chambre pas loin, avec des tarifs préférentiels (mais chers, faut avouer), pouvait être un plus.
Ce que je retiens de cette édition, c'est que d'une part elle m'a franchement étonnée: un endroit de rêve pour des conférences, qui se prête tout à fait à la venue de speakers internationaux, et qui s'adapte aussi aux usages habituels de la Nuit du Hack (workshop, CTF, prises de courant, etc ...). Et d'autre part le nombre de personnes ayant répondu présent, les animateurs de workshop qui ont fait un boulot formidable, mais aussi les speakers qui ont été terribles (et qui, on le souhaite, reviendront nous voir l'année prochaine), etc... Si la Nuit du Hack devait se dérouler dans un seul endroit l'année prochaine, ce serait bien à nouveau dans l'hotel New York.
<center><embed type="application/x-shockwave-flash" src="https://picasaweb.google.com/s/c/bin/slideshow.swf" width="400" height="267" flashvars="host=picasaweb.google.com&hl=fr&feat=flashalbum&RGB=0x000000&feed=https%3A%2F%2Fpicasaweb.google.com%2Fdata%2Ffeed%2Fapi%2Fuser%2Fvirtualabs%2Falbumid%2F5620811613695329713%3Falt%3Drss%26kind%3Dphoto%26authkey%3DGv1sRgCIni3IHQoNvynwE%26hl%3Dfr" pluginspage="http://www.macromedia.com/go/getflashplayer"></embed></center>