A ma connaissance, seuls 3 boites font des chipset ADSL:
Texas Instrument (AR7* pour les boitiers Dlink, Linksys, ...), Broadcom (box ADSL free, 9, alice) et Analog Digital, Inc (Livebox).
Sur les 3, pas un seul ne file les sources de l'outil de configuration du module ADSL, ni du module ADSL, ni du firmware de la puce ou unité qui gère l'ADSL.
Donc, pour arriver à faire des choses tordues comme écouter tous les VC en même temps et logger les trames, envoyer des données arbitraires, etc... c'est possible mais à mon avis il faut pas mal de boulot de reverse-engeeniering sur ces aspect-la des puces.
Mais bon, on peux imaginer que, avec n'importe quel modem adsl traffiqué (pas seulement une box), on peux envoyer ce que l'on veux sur tous les VC.
Ensuite, il faut voir si le DSLAM est bien protégé à ce niveau-là, et si des protections existent (genre, mise en connection restreinte et remonté d'alerte lors de la détection de trames louches, ex qui se balladent sur un VC non utilisé)
Notoirement, il y a quelques années les DSLAM étaient de vraie passoire (vxworks :-) ) mais maintenant j'imagine que ca à dû changer.
Il faut voir ensuite comment sont protégé les serveurs en amont, télé et téléphonie, en particulier face au fuzzing. C'est là ou, potentiellement, un DoS peux faire mal.
Mais c'est pas en mettant à jour les box qu'on pourra l'éviter...
Dans tous les cas, la QoS devrait faire que, à moins de tomber sur un bug d'un routeur ou du DSLAM qui le met en DoS, tripatouiller sa connection ne devrais léser que soit-même.
[^] # Re: c'est marqué dedans...
Posté par C. OB (site web personnel) . En réponse au journal Neuf confirme son ouverture vers le logiciel libre. Évalué à 1.
A ma connaissance, seuls 3 boites font des chipset ADSL:
Texas Instrument (AR7* pour les boitiers Dlink, Linksys, ...), Broadcom (box ADSL free, 9, alice) et Analog Digital, Inc (Livebox).
Sur les 3, pas un seul ne file les sources de l'outil de configuration du module ADSL, ni du module ADSL, ni du firmware de la puce ou unité qui gère l'ADSL.
Donc, pour arriver à faire des choses tordues comme écouter tous les VC en même temps et logger les trames, envoyer des données arbitraires, etc... c'est possible mais à mon avis il faut pas mal de boulot de reverse-engeeniering sur ces aspect-la des puces.
Mais bon, on peux imaginer que, avec n'importe quel modem adsl traffiqué (pas seulement une box), on peux envoyer ce que l'on veux sur tous les VC.
Ensuite, il faut voir si le DSLAM est bien protégé à ce niveau-là, et si des protections existent (genre, mise en connection restreinte et remonté d'alerte lors de la détection de trames louches, ex qui se balladent sur un VC non utilisé)
Notoirement, il y a quelques années les DSLAM étaient de vraie passoire (vxworks :-) ) mais maintenant j'imagine que ca à dû changer.
Il faut voir ensuite comment sont protégé les serveurs en amont, télé et téléphonie, en particulier face au fuzzing. C'est là ou, potentiellement, un DoS peux faire mal.
Mais c'est pas en mettant à jour les box qu'on pourra l'éviter...
Dans tous les cas, la QoS devrait faire que, à moins de tomber sur un bug d'un routeur ou du DSLAM qui le met en DoS, tripatouiller sa connection ne devrais léser que soit-même.
OB