Bien que je dispose maintenant d’une théorie « rationnelle » pour expliquer les événements dont mon réseau à été victime, j’avoue sincèrement m’être senti bien démuni pendant quelques temps… Auriez vous trouvé plus vite que moi la véritable cause de ces soucis techniques ?
Perte de l’accès Internet
Tout commence donc le 25/04/2012 vers 10h30. Mon réseau interne, constitué d’une freebox et d’une chaine de 5 switch gigabit (le switch 1 est connecté à la freebox et au switch 2, le switch 2 est connecté au switch 3 etc) perd l’accès au net. Vérifications faites, la freebox n’y est pour rien. A coup de pings, je déduit que le problème se situe sur un switch précis, le numéro 4.
Arrêt/relance du switch : Oui… mais non
Je le débranche, le rebranche. Aussitôt, tout semble repartir sans soucis. les pings qui ne passaient plus passent de nouveau, l’accès au net est rétabli. Mais moins de deux minutes plus tard, le même problème se reproduit. Nouvel arrêt/relance, même résultat.
Changement du switch
Coup de chance, j’avais un veux switch 100 Mb/s qui trainait dans un coin. Je remplace le numéro 4 par ce « nouveau » switch. A peine est il branché que les pings vers la freebox cessent de fonctioner. Par contre, les machines qui se trouvent connectés à ce nouveau (mais vieux vous suivez ?) switch se pinguent entre elles. Nouveaux tests dans tous les sens, pour conclure que c’est maintenant le switch numéro 3 qui est HS ! Je le débranche, le rebranche. Tout repart quelques minutes, avant que celui en 100 Mb/s se mette à faire exactement la même chose que les précédents (tout semble normal, tout clignote, mais les pings ne passent plus).
Calme et sérénité
C’est à ce moment la que je me suis assis sur une chaise en essayant de trouver une explication logique sans y parvenir. Mon esprit troublé par ce manque de rationalité apparent sera tout de même parvenu à me convaincre de repartir sur de nouvelles bases, et de procéder par élimination.
- Arrêt électrique complet de tous les éléments actifs, puis redémarrage progressif : Pas mieux
- Changement des câbles réseaux : Pas mieux
C’est alors que j’étudiai la possibilité de changer les cartes réseaux que je remarquai un message d’erreur dans une console. Un message qui, les fois précédentes, avait disparu trop vite pour que je le remarque. Entre le moment ou les pings fonctionnaient, et celui ou ils ne fonctionnaient plus (ping timeout), j’avais un message de ce style : « sendto: No buffer space available ».
Merci Google
A partir de la, il n’y avait plus qu’a demander à notre meilleur ami (ou ennemi ?). D’après lui, l’explication de ce genre de message était qu’un nombre trop important de trames UDP parcouraient le réseau, saturant les buffers des cartes et des switch et bloquant finalement toute communication. Explication qui me convenait parfaitement, dans la mesure ou elle expliquait effectivement le coté aléatoire des switchs qui perdaient les pédales. Il n’y avait plus qu’a trouver qui pouvait bien inonder le réseau de paquets UDP.
Je connais maintenant l’élément coupable, mais pas LE coupable
Il ne faudra pas longtemps pour déterminer que c’était un point d’accès wifi qui devait être la source du problème. En effet, une fois cette AP débranché, plus le moindre soucis. Oui mais pourquoi donc cet AP inondait mon réseau ? Pour le savoir, je met rapidement en place un mini réseau autonome constitué de cet AP et d’un netbook, sur lequel je lance un wireshark en promiscuous. Cet AP avait il fortement bugué ? Ou ne faisait t-il que relayer des paquets venant de l’extérieur ? Une « attaque » Wifi ou quelque chose de ce genre ?
J’ai laissé tourné ce mini lab pendant plusieurs heures sans obtenir le moindre résultat, et pour cause. J’ai compris après coup que, sans serveur dhcp à contacter, l’AP ne parvenait pas à s’initialiser totalement. Le wifi restait donc désactivé, et je je ne risquai donc pas de voir quoi que ce soit venir de l’extérieur…
J’ai depuis rebranché cet AP à sa place sur le véritable réseau, et je n’ai pas eu de nouveaux problèmes. Soit il s’agissait d’un bug, soit le petit rigolo qui m’a fait perdre mon après midi à compris en voyant disparaitre le SSID de l’AP qu’il avait peut être fait une boulette. Si certains ont des avis ou des hypothèses, je suis tout ouïe 🙂
Je tente une explication :
Ta fille essaye de pirater ton réseau pour accéder au site mylittlepony que vilainement tu lui bloqué
Certes, cette explication souffre d’un postulat irréalisable, à savoir le blocage, puisque je le sais tu as tendance à débloquer les adresses réseau plutôt qu’à les bloquer j’en viens donc à une seconde hypothèse plus rationnelle : ton réseau débloque :p
J’ai oublié : Excellent jeu de mots … j’ai du mal à m’en remettre
Sinon, quelqu’un a renversé un café sur un switch, et a nettoyé vite fait bien fait pour pas que tu t’en aperçoive…
Jojo :
Pour le jeu de mot, sincèrement, j’étais pas totalement certain que beaucoup allaient le voir mais… Comme l’une des personnes interrogées l’a très bien indiqué dans « La revanche des geek » (Arté), les allusions et références plus ou moins cachées sont une bonne façon de nous reconnaitre 😉
Et pour ma fille, tu as raison. Pour le moment le seul filtre c’est que le câble réseau est pas branché par défaut… Forcément, un jour, je devrai surement augmenter un poil le niveau de sécurité…
H3 : Tu as mal lu le billet :p
Après avoir cogité avec quelques copains, on a eu une idée un peu fumeuse :
– On a 5 switchs cascadés. Un paramètre dans un des switchs (ou plusieurs) fait qu’il est en mode Switching loop.
– Maintenant on active le wifi. Ça crée une boucle entre les switchs.
– Le switching loop entretient une discussion entre les switch qui occupe approximativement 20% de la bande passante (comportement à peu près normal).
– Et là malchance, un bug dans le protocole de switching loop de l’un des switchs, la BP consommée explose.
– Lorsqu’on coupe le WiFi, on pert toute boucle et le comportement redevient normal.
Pourquoi l’idée est fumeuse ? Deux raisons :
1. Les paquets qui saturent sont des paquets UDP (l3) alors que le switching loop cause en l2.
2. Pourquoi est ce que le wifi pourrait activer le switching loop mode puisqu’il ne sert à priori pas à relier plusieurs switchs entre eux (ou alors ils peuvent communiquer entre eux via WiFi).
PS : La culture c’est comme la confiture, me suis-je dit avant de poster :/
mébon, tant pis
De quel jeu de mots s’agit-il ?
Vous avez éveillé ma curiosité !
olrind => admettons que tu as un ami coloré et de six lettres, un bon mot clé pourrait être : « poyépolomi »
hoper => arte/revanche des nerds … pas de foo bar pas de 42 … on sent bien que les journaleux ne connaissent que la surface du sujet, kodab 😉
Lister dans ce reportage toutes les références clefs, les incontournables absolu du « geek qui se respecte » (comme 42 effectivement) n’aurai certainement pas apporté grand chose au reportage. (A part perdre encore plus ceux qui ne font pas parti de ce monde la).
Je trouvai plus intéressant de simplement évoquer quelques sujets bien vagues (jeu de rôles, cosplay, informatique, littérature fantastique…) et de laisser s’exprimer ceux qui savent de quoi ils parlent. J’ai par exemple adoré le témoignage de cette fille qui se demandait « pourquoi les autres rigolent-ils en voyant Big bang theory ? Comprennent ils les blagues sur les elfes ? » Avant de comprendre que les différents spectateurs ne rigolaient pas pour les mêmes raisons.
Le coup des références cachées pour « détecter » le coté geek de son interlocuteur est aussi extrêmement vrai, et j’en ai fait l’expérience pas plus tard que le week end dernier. Rencontre avec 4 inconnus pour une partie d’ADD4. Et bien les références ont vites fusées de tous les cotés. Je pense avoir « passé le test » sans trop de difficulté :o) Qui d’autre qu’un geek aurait immédiatement reconnu la musique d’ambiance : Pegasus fantasy ? Tout comme il est vrai qu’un gars qui se se « prétend geek » parce qu’il à un iphone dans la poche ne pourra jamais faire illusion bien longtemps…
C’est quand même fou qu’une AP wifi réussissent à saturer les buffers d’un routeur gigabytes.
Autre étonnement, les buffers ne servent normalement pas qu’à stocker une trame en cours d’émission ou de reception après/avant de passer en mémoire vive. Un buffer passe sa vie à être plein puis vide (c’est d »ailleurs son rôle de buffer). Tu connais surement toi aussi le problème de collision et que du coup les trames ont une longueur minimale. Cette longueur de trame augmente avec la distance et le débit mais elle a une limite. Au doigt mouillé (pour moi, non-expert réseau), je dirai que la limite communément admise en gigabit est 9K (jumbo frame). Du coup à quoi sert-il d’avoir des buffers plus gros que 9K si les trames ne dépasseront jamais cette taille? Donc, je récapitule :
– les buffers servent à stocker les trames en cours de reception ou juste avant émission.
– comme les trames ont des tailles limitées, alors les buffers ont aussi une taille limitée et ne devraient pas profiter d’un mécanisme de remplissage (9K! on va pas se fouler! on fout toute la trame en cache et osef le code qui remplit/vide le buffer progressivement)
– si une trame avec une longueur supérieure à la taille de ton buffer se pointe alors ton buffer est plein et ne peut plus accueillir une trame pour envoi (de toute façon il y aurai collision)
L’hypothèse est donc qu’il y a des trames géante qui se baladent sur le réseau. C’est possible d’envoyer de forger de très grosse trame sans exploser son propre buffer de sortie ; il suffit de le désactiver (mais alors bonjour le blocage de ressource système qui va se traduire par une sur-conso de CPU/accès mémoire).
Protocole de vérification de l’hypothèse:
1. reviens en situation initiale (où rien ne marche)
2. attends que ça ne fonctionne de nouveau plus
3. wireshare that 😀
Je n’avais pas tilté, mais effectivement c’est assez étrange qu’un AP en 100 Mb/s (et oui, j’avais oublié ce détail) parvienne à saturer les buffers de switchs en Gb. Cela dit, je pense que ce n’est pas le débit qui compte mais le nombre de trames (et je n’utilise pas les jumbo frames sur mon réseau, aucun OS n’est en tout cas configuré pour, et je ne crois pas que linux utilise ça automatiquement).
Quand à ta proposition, c’est ce que j’ai indiqué il me semble à la fin du billet. Je suis revenu en configuration initial mais le problème n’apparait plus. J’ignore toujours si l’AP à violemment buggué, ou si quelqu’un faisait je ne sais trop quoi depuis l’extérieur.
Mmmh, je crois que même en WPA on peut injecter des trames sur un réseau filaire (à vérifier). L’hypothèse de l’attaquant est possible mais à moins d’avoir de déjà avoir des doutes sur une entité en particulier ça me parait vraiment fantaisiste.
Tu penses vraiment être la cible d’une attaque? Ton AP est au milieu de la silicon valley? Ton SSID est « hackmeifyoucan »? C’est franchement lassant de maintenir une attaque, il faut donc une motivation sérieuse pour le faire.
Je ne parle pas forcément « d’attaque » dans le sens : « Lui je l’aime pas et je vais lui faire péter son réseau ». J’imaginai plus l’utilisation d’outils pour cracker la clef Wifi, et qui généralement commencent par provoquer un trafic très important. Après, comme je ne connais pas précisément les outils en questions, et que je ne sais pas non plus si il serait alors normal que l’AP (en mode bridge) relaye tout ce qu’il reçoit sur le lan… Bref, c’est une simple supposition hein. Mais, en l’état, elle ne me semble pas moins crédible qu’un bug dans le firmware de la borne wifi qui provoquerait tout d’un coup un flood udp sur le lan.
Quand au coté lassant de ce genre de chose, je ne vois pas vraiment de quoi tu parle. Personne ne t’oblige à rester devant le PC sur lequel tu as juste lancé une commande 🙂
Pour ce qui de l’attaque contre le WEP, l’idée consiste à capture un paquet ARP chiffré.
Pourquoi?
1. parce qu’on les repère très facilement car ils sont tout petits.
2. parce que l’on connait une grande partie du contenue : les addresses MAC de l’expéditeur et du destinataire
3. parce que si on le rejoue, ben le hotspot re-répond 🙂
Avec un grand nombre de réponse chiffré mais dont on connait le contenu alors on peut trouver le vecteur d’initialisation et la clef. CQFD
L’ARP ne se ballade pas très loin, sa taille est très petite (pas moyen de casser du buffer avec), etc : on ne voit quasi pas ce type d’attaque.
Pendant une attaque c’est très courant de la voir se stopper nette et de devoir tout relancer. Pis X heures de backtrack qui tourne c’est X heures de Need For Speed sous Windows de pas joué. Dans mes souvenir, maintenir une attaquant c’est très chiant ^^’
« Pis X heures de backtrack qui tourne c’est X heures de Need For Speed sous Windows de pas joué. Dans mes souvenir, maintenir une attaquant c’est très chiant ^^' »
Il y a des gens qui sont riches et qui ont plusieurs machines chez eux :p
Merci pour l’explication concernant les paquets arp. Je sais que les attaques contre les clefs WEP sont vieilles comme le monde (ou presque…) mais je n’avais jamais pris le temps de me pencher sur les détails techniques. Plus qu’a trouver une explication similaire sur les attaques contre les clefs WPA en fonction du mode utilisé etc…