Auteur Sujet: [SUIVI] K-Net/Covage 14 - Problèmes APIPA, mDNS et spam DHCPv6  (Lu 40100 fois)

0 Membres et 1 Invité sur ce sujet

Steph

  • Abonné K-Net
  • *
  • Messages: 7 679
  • La Balme de Sillingy 74
    • Uptime K-net
[Résolu] spam élevé de trames IPv6 dans le GPON K-Net Covage 14 (et 91)
« Réponse #24 le: 21 avril 2022 à 08:13:54 »
1. en prérequis, activer SNMP sur la box (onglet avancé)
2. récupérer la chaîne "communauté publique" (variable community ci-après)
3. connaître son adresse IP publique (variable ip ci-après)
L'Icotera a son SNMP qui la fait assez régulièrement planter pour cause d'attaque extérieure.
VincentO2 avait mis une ACL sur la mienne et plus de plantage le temps que cela durait.

pju91

  • Abonné Free fibre
  • *
  • Messages: 861
  • 91
[Résolu] spam élevé de trames IPv6 dans le GPON K-Net Covage 14 (et 91)
« Réponse #25 le: 21 avril 2022 à 08:29:00 »
L'Icotera a son SNMP qui la fait assez régulièrement planter pour cause d'attaque extérieure.
VincentO2 avait mis une ACL sur la mienne et plus de plantage le temps que cela durait.
De mon côté, je n'ai jamais eu ce souci. J'ai un "polling SNMP" avec Cacti en place pour évaluer le trafic WAN depuis longtemps.

bolemo

  • AS2027 MilkyWan
  • Professionnel des télécoms
  • *
  • Messages: 1 623
  • Grandcamp Maisy (14)
[Résolu] spam élevé de trames IPv6 dans le GPON K-Net Covage 14 (et 91)
« Réponse #26 le: 21 avril 2022 à 12:59:38 »
Est-ce que ton monitoring te permet d'identifier l'adresse MAC de l'équipement qui inonde le GPON?
Est-ce toujours la même K-Box ?
Le monitoring passif non, mais quand un incident est en cours, je peux trouver la MAC en très peu de temps.
Les deux fois où j'ai regardé les paquets (deux incidents différents), la MAC de la K-Box était différente.

Je pourrais faire un script qui fait automatiquement un dump quand il y a une alarme… Et avoir une solution 100% passive de monitoring des incidents DHCPv6.

Citer
On a vu que plutôt que de coupure, il faudrait parler de "pollution du LAN" qui provoque des effets de bord, tels que duplication d'adresse IP.
A ce sujet, sais-tu si le firmware des K-Box v2 est le même pour tout le monde ?

Oui, je parlais du symptôme perçu par le client victime qui se présente sous la forme de coupures (soit de sa connexion, soit de certains appareils sur le LAN, dépendant…)
Pour le firmware, je n'en ai absolument aucune idée… Je n'ai eu de K-Box.

Pour la fuite GPON/LAN, ce qu'explique VincentO a beaucoup de sens, car les règles ebtables peuvent filtrer ou laisser passer du traffic entre WAN et LAN. Du coup, cela n'est pas forcément un problème de firmware si ce sont des règles appliquées ou modifiées par les solutions maison K-Net (ce n'est à priori pas un problème low-level).

Pour la boucle DHCPv6 SOLLICIT, c'est bien plus curieux… puisqu'à priori un client DHCPv6 même mal configuré, ne va pas envoyer 4 000 requêtes par secondes…
C'est soit une mauvaise conception dans le code du client qui dans certaines conditions revient à une boucle sans fin qui s'est emballée (corruption dans la gestion de la mémoire du processus…). Donc possiblement un problème de firmware, sauf si K-Net a altéré le client ou développé son propre client ou encore modifie un fichier dont dépend le processus (dans /var ou /tmp par exemple)…

On ne peut que spéculer de toute façon, sans avoir le code source, ou un accès root à une K-Box.

On a vu que d'autres opérateurs BYTEL (comme tu l'avais mentionné) on apparemment rencontré des situations similaires, probablement dans des circonstances totalement différentes (les box sont-elles des Icotera ou totalement différentes…), mais qui sait ?

Citer
De mon côté, je parviens à interroger ma box en SNMP, ça m'interesserait de savoir ce que ça donne ailleurs.
commande ci-dessous avec :
1. en prérequis, activer SNMP sur la box (onglet avancé)
2. récupérer la chaîne "communauté publique" (variable community ci-après)
3. connaître son adresse IP publique (variable ip ci-après)
$ snmpwalk -Os -c $community -v 2c $ip system|grep  Descr
sysDescr.0 = STRING: ICOTERA i4850 4850-1.16.3
... en imaginant que 1.16.3 est une version de firmware, mais je n'en sais rien.

pju91

  • Abonné Free fibre
  • *
  • Messages: 861
  • 91
[Résolu] spam élevé de trames IPv6 dans le GPON K-Net Covage 14 (et 91)
« Réponse #27 le: 21 avril 2022 à 13:56:43 »
Le monitoring passif non, mais quand un incident est en cours, je peux trouver la MAC en très peu de temps.
Les deux fois où j'ai regardé les paquets (deux incidents différents), la MAC de la K-Box était différente.
Donc plus d'un client affecté sur la boucle à laquelle tu es connecté  :(
Je pourrais faire un script qui fait automatiquement un dump quand il y a une alarme… Et avoir une solution 100% passive de monitoring des incidents DHCPv6.
Puisque les incidents de ces derniers jours ont duré peu de temps, est-ce qu'une solution de détection et de correction est maintenant en place côté K-Net ?
Si ce n'est pas le cas, conserver les adresses MAC des box concernées peut être utile effectivement.
Pour la fuite GPON/LAN, ce qu'explique VincentO a beaucoup de sens, car les règles ebtables peuvent filtrer ou laisser passer du traffic entre WAN et LAN. Du coup, cela n'est pas forcément un problème de firmware si ce sont des règles appliquées ou modifiées par les solutions maison K-Net (ce n'est à priori pas un problème low-level).
Je n'ai toujours pas compris pourquoi des règles ebtables doivent être installées sur un routeur (à part peut-être pour le port mirroring). Quelle est la raison ?
Pour la boucle DHCPv6 SOLLICIT, c'est bien plus curieux… puisqu'à priori un client DHCPv6 même mal configuré, ne va pas envoyer 4 000 requêtes par secondes…
C'est soit une mauvaise conception dans le code du client qui dans certaines conditions revient à une boucle sans fin qui s'est emballée (corruption dans la gestion de la mémoire du processus…). Donc possiblement un problème de firmware, sauf si K-Net a altéré le client ou développé son propre client ou encore modifie un fichier dont dépend le processus (dans /var ou /tmp par exemple)…

On ne peut que spéculer de toute façon, sans avoir le code source, ou un accès root à une K-Box.
Oui, ça me rappelle l'époque ancienne où je montrais (avec un peu de connaissance sur l'architecture de la machine) comment faire un programme en C qui bouclait de manière infinie, sans boucle explicite dans le programme, mais simplement en écrasant la pile avec la bonne valeur ...
On a vu que d'autres opérateurs BYTEL (comme tu l'avais mentionné) on apparemment rencontré des situations similaires, probablement dans des circonstances totalement différentes (les box sont-elles des Icotera ou totalement différentes…), mais qui sait ?
J'ai retiré ce message, le diagnostic de l'utilisateur semblait erroné.

bolemo

  • AS2027 MilkyWan
  • Professionnel des télécoms
  • *
  • Messages: 1 623
  • Grandcamp Maisy (14)
[Résolu] spam élevé de trames IPv6 dans le GPON K-Net Covage 14 (et 91)
« Réponse #28 le: 21 avril 2022 à 14:35:35 »
Donc plus d'un client affecté sur la boucle à laquelle tu es connecté  :(
Ma boucle est assez large… C'est tout le 14 + une partie (ou la totalité) du 91 sur l'infra Covage/Altitude.

Citer
Puisque les incidents de ces derniers jours ont duré peu de temps, est-ce qu'une solution de détection et de correction est maintenant en place côté K-Net ?
Je suppose que oui… La premier incident que j'ai détecté à duré 15 jours malgré le Tweet à Covage, K-Net puis Département…
On peut supposer qu'ils ont tous découvert le problème sans trop comprendre. Il a été résolu, peut-être intentionnellement, ou pas erreur… On a pas eu de retour

Le second incident, j'ai ajouté Altitude dans le Tweet… Mais ça a bougé très vite une fois un lien donné vers le post de VincentO2… Je suppose (encore une fois) que K-Net a appris la solution et peut-être l'origine du problème à ce moment, et ils dès le lendemain matin à 8h, ça a été résolu. Ça a duré quelques jours, mais pas deux semaines.

Les deux incidents suivants ont été résolu spontanément dans la journée, sans besoin de Tweets ou autre… Donc je suppose (toujours) que K-Net fait du monitoring spécifique à cet incident. Le font-ils seuls, ou avec l'assistance des OI, où les OI font-ils le monitoring et informent K-Net qui alors reset la box en question ? Là je ne sais pas…
Citer
Si ce n'est pas le cas, conserver les adresses MAC des box concernées peut être utile effectivement.
Je verrai à l'occasion. Ce n'est pas très compliqué, mais il me faut un peu de temps… Mon alarme Grafana doit déclencher le script sur mon routeur (qui est le seul à pouvoir écouter le GPON) qui enregistrera un échantillon de tcpdump. J'imagine par un appel à une page HTTP sur le serveur natif du routeur (je le fais déjà pour mon script Aegis).

Citer
Je n'ai toujours pas compris pourquoi des règles ebtables doivent être installées sur un routeur (à part peut-être pour le port mirroring). Quelle est la raison ?
Elle sont utiles en mode bridge. Probablement pour le mort mirroring aussi.
En mode routeur, des règles ebtables permettent d'isoler un réseau wifi guest du LAN par exemple.
Enfin, ebtables me permet sur mon routeur de faire des règles spécifiques selon les adresses MAC, donc de bloquer ces fameux paquets broadcast/multicast (ainsi que tout ce qui ne vient pas directement de la passerelle Covage), ou sur le LAN de bloquer certains appareils comme des bidules Amazon Chinois (cast TV par exemple) que je ne permet pas d'aller sur le net pour transmettre je ne sais quoi.

Citer
Oui, ça me rappelle l'époque ancienne où je montrais (avec un peu de connaissance sur l'architecture de la machine) comment faire un programme en C qui bouclait de manière infinie, sans boucle explicite dans le programme, mais simplement en écrasant la pile avec la bonne valeur ...
Ça peut être un problème de ce genre… Ou un mauvais design (une boucle explicite qui attend la réponse DHCPv6 du serveur avec le contrôle d'une variable de pause qui foire, ou un timer corrompu…) ; sans accès à la machine défaillante et/ou son code, on restera dans le noir. Ce qui compte, c'est que K-Net semble bien y travailler.

pju91

  • Abonné Free fibre
  • *
  • Messages: 861
  • 91
[Résolu] spam élevé de trames IPv6 dans le GPON K-Net Covage 14 (et 91)
« Réponse #29 le: 21 avril 2022 à 14:50:51 »
Concernant ebtables:
Elle sont utiles en mode bridge. Probablement pour le mort mirroring aussi.
En mode routeur, des règles ebtables permettent d'isoler un réseau wifi guest du LAN par exemple.
La K-Box étant basée apparemment sur un Icotera 4850, les fonctionnalités "bridge" existent dans le produit "usine" mais  les clients K-Net peuvent configurer assez peu de choses par le panel, comme le port mirroring, ou le filtrage MAC sur WiFi.
La fonctionnalité "WIFI guest" n'est pas proposée dans l'interface, et on ne peut évidemment pas saisir de règles ebtables.

bolemo

  • AS2027 MilkyWan
  • Professionnel des télécoms
  • *
  • Messages: 1 623
  • Grandcamp Maisy (14)
[Résolu] spam élevé de trames IPv6 dans le GPON K-Net Covage 14 (et 91)
« Réponse #30 le: 21 avril 2022 à 15:15:53 »
Concernant ebtables:La K-Box étant basée apparemment sur un Icotera 4850, les fonctionnalités "bridge" existent dans le produit "usine" mais  les clients K-Net peuvent configurer assez peu de choses par le panel, comme le port mirroring, ou le filtrage MAC sur WiFi.
La fonctionnalité "WIFI guest" n'est pas proposée dans l'interface, et on ne peut évidemment pas saisir de règles ebtables.

ebtables sur les K-Box est donc très probablement utilisé pour le port mirroring et le filtrage MAC.
Dans tous les cas, les règles ebtables sont configurées par les scripts K-Net sur la box, ou à distance depuis le serveur de configuration de K-Net, mais en effet en aucun cas directement par les clients (ni lecture seule d’ailleurs) ; c’est assez normal d’ailleurs, car par design, les box internet (tout opérateur) sont fermées pour éviter que les clients les bidouillent, et avoir des environnements standardisés pour faciliter le soutien technique.
La bonne nouvelle est que quand l’origine du problème aura été trouvée, une seule et même procédure devra être appliquée à toutes les box pour le résoudre.

Maintenant, ce qui est inquiétant, c’est que VincentO2 mentionne un passage physique des K-Box au centre de maintenance pour cela et d’autres procédures qu’il ne précise pas. Ça laisse penser qu’il existe d’autres soucis avec les Icotera, ou que l’origine est peut-être matérielle après tout… Peut-être des problèmes de nvram avec des secteurs défectueux qui apparaissent avec le temps…

pju91

  • Abonné Free fibre
  • *
  • Messages: 861
  • 91
[Résolu] spam élevé de trames IPv6 dans le GPON K-Net Covage 14 (et 91)
« Réponse #31 le: 21 avril 2022 à 15:30:02 »
Maintenant, ce qui est inquiétant, c’est que VincentO2 mentionne un passage physique des K-Box au centre de maintenance pour cela et d’autres procédures qu’il ne précise pas. Ça laisse penser qu’il existe d’autres soucis avec les Icotera, ou que l’origine est peut-être matérielle après tout… Peut-être des problèmes de nvram avec des secteurs défectueux qui apparaissent avec le temps…
En regardant dans l'interface de la K-Box, il y a une notion de version. Voir par exemple le screenshot correspondant à l'affichage des modifications de la version 5.5.
Ca fait référence à une version de firmware > 1.16. (j'évoquais ce matin 1.16.3 pour la version que me retourne snmpwalk).
On peut supposer qu'il y a des correctifs "panel" mis au point par K-Net, mais qui s'appuient sur des versions de firmware Icotera.
Ce que VincentO2 a peut-être en tête est la mise à jour du firmware, que K-Net ne sait peut-être pas pousser via le réseau et qui nécessite un retour atelier ? Ca serait bien compliqué, surtout par rapport à ce que font d'autres ISP !

Au fait, la dernière version est la 5.6. Elle date d'Avril 2019 ! rien depuis  :-[

bolemo

  • AS2027 MilkyWan
  • Professionnel des télécoms
  • *
  • Messages: 1 623
  • Grandcamp Maisy (14)
[Résolu] spam élevé de trames IPv6 dans le GPON K-Net Covage 14 (et 91)
« Réponse #32 le: 22 avril 2022 à 16:57:09 »
En préparant mon script, je partage ici des commandes tcpdump utiles :

Celle-ci écoute tout ce qui est lié à une Icotera sur le GPON :
tcpdump -i interface WAN -e "(ether[6:2] == 0x001e and ether[8:1] == 0x80) or (ether[6:2] == 0x000f and ether[8:1] == 0x15)"

probablement la partie or (ether[6:2] == 0x000f and ether[8:1] == 0x15) n'est pas nécessaire (je ne sais pas s'il existe des K-Box avec des MAC en 00:0F:15…)

Celle-ci est plus spécifique, elle fait comme la précédente, mais ne recueille que les packets DHCPv6, donc utile pour détecter la fameuse boucle spam :
tcpdump -i interface WAN -e "(ether[6:2] == 0x001e and ether[8:1] == 0x80) or (ether[6:2] == 0x000f and ether[8:1] == 0x15) and udp port 547 and multicast

pju91

  • Abonné Free fibre
  • *
  • Messages: 861
  • 91
[Résolu] spam élevé de trames IPv6 dans le GPON K-Net Covage 14 (et 91)
« Réponse #33 le: 22 avril 2022 à 17:44:29 »
probablement la partie or (ether[6:2] == 0x000f and ether[8:1] == 0x15) n'est pas nécessaire (je ne sais pas s'il existe des K-Box avec des MAC en 00:0F:15…)
Je pense que tu as raison.
Mais si tu veux être perfectionniste, https://hwaddress.com/company/icotera-as/ liste un 3e OUI pour ICOTERA: 4C-C4-49 (voir aussi dans https://standards-oui.ieee.org/oui/oui.txt).

bolemo

  • AS2027 MilkyWan
  • Professionnel des télécoms
  • *
  • Messages: 1 623
  • Grandcamp Maisy (14)
[Résolu] spam élevé de trames IPv6 dans le GPON K-Net Covage 14 (et 91)
« Réponse #34 le: 22 avril 2022 à 19:18:53 »
Je pense que tu as raison.
Mais si tu veux être perfectionniste, https://hwaddress.com/company/icotera-as/ liste un 3e OUI pour ICOTERA: 4C-C4-49 (voir aussi dans https://standards-oui.ieee.org/oui/oui.txt).

Effectivement, la base de donnée que j'avais consulté est incomplète…
Mais je pense que les Icotera K-Box sont en 00:1e:80

Voilà comment je vais récupérer automatiquement la (ou les) MAC des K-Box qui s'emballeraient :
{ timeout 1 tcpdump -i interface WAN -te "ether[6:2] == 0x001e and ether[8:1] == 0x80 and udp port 547 and multicast"; } | awk 'length($1)==17{a[$1]++} END { for (i in a) { if (a[i]<50) continue; print i } }'Dans un crontab qui vérifiera toutes les minutes par exemple, et fera un log.

Ça signifie que la MAC de toutes les K-Box qui enverront plus de 50 requêtes DHCPv6 par seconde seront enregistrées dans le log.

Je pense pouvoir aussi modifier le script pour enregistrer automatiquement les K-Box qui fuient.

Il me restera à faire en sorte que ça publie automatiquement quelque part les incidents… Peut-être des tweets automatiques ?  ;D
« Modifié: 23 avril 2022 à 14:31:40 par bolemo »

pju91

  • Abonné Free fibre
  • *
  • Messages: 861
  • 91
[Résolu] spam élevé de trames IPv6 dans le GPON K-Net Covage 14 (et 91)
« Réponse #35 le: 22 avril 2022 à 20:44:30 »
Chez moi, ta commande s'affichait avec
if (a<50) au lieu de if (a[i]<50)  dans ta règle END et ça passe en italique
Du coup, le script me paraissait faux.
En tentant de te répondre en te "citant", ça fait bien apparaître le a[i]Il faut donc vraiment utiliser "code" plutôt que forcer la police en courrier.

Dire que je pensais être le dernier à utiliser awk ...

Bon, je pense qu'effectivement ce script peut être utile ... s'il ne charge pas trop ton matériel.
« Modifié: 22 avril 2022 à 21:09:46 par pju91 »