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

0 Membres et 1 Invité sur ce sujet

bolemo

  • AS2027 MilkyWan
  • Professionnel des télécoms
  • *
  • Messages: 1 606
  • Grandcamp Maisy (14)
[SUIVI] K-Net/Covage 14 - Problèmes APIPA, mDNS et spam DHCPv6
« Réponse #192 le: 27 mai 2022 à 21:30:02 »
Quel détective, bravo.
Si tu as le fin mot de cette histoire, raconte nous ça ici. Jusqu'à présent, on pensait que les routeurs perso étaient plus "civilisés" que les K-Box.

Routeur TP-Link… on a désactivé le proxy IGMP (le fait qu’il était activé aurait expliqué cela), mais c’est toujours là.
Pas d’accès SSH ou autre moyen de toucher manuellement aux iptables pour le routeur…

Rien trouvé sur le net à propos de fuites mDNS…

Plus le temps de réfléchir à ça ce soir, mais c’est curieux.

blarglibloup

  • Invité
[SUIVI] K-Net/Covage 14 - Problèmes APIPA, mDNS et spam DHCPv6
« Réponse #193 le: 28 mai 2022 à 11:45:38 »
Un peu hors-sujet mais j'ai vu un truc pas courant hier soir: je suis en attente d'activation sur un nouveau raccordement sur OI Axione (depuis bientôt 15j :P) avec le symptôme classique qu'aucun DHCP ne répond à mon routeur. J'ai un tcpdump qui tourne pour "surveiller" et cette nuit pendant environ 5h, j'ai vu arriver des paquets IP qui étaient manifestement destinés à un autre abonné (MAC cible différente de la mienne, et ce matin l'IP cible répond au ping, hier soir non). L'équivalent fibre des "fils qui se touchent" du RTC? ;P

Moi qui pensait qu'Axione c'était carré  ::)

Hugues

  • AS2027 MilkyWan
  • Modérateur
  • *
  • Messages: 12 425
  • Lyon (69) / St-Bernard (01)
    • Twitter
[SUIVI] K-Net/Covage 14 - Problèmes APIPA, mDNS et spam DHCPv6
« Réponse #194 le: 28 mai 2022 à 12:07:27 »
Rien de choquant, c'est simplement de l'unknown unicast, c'est le fonctionnement classique d'un réseau Ethernet quand une MAC n'est pas peuplée en FDB -> Flood sur tous les ports


blarglibloup

  • Invité
[SUIVI] K-Net/Covage 14 - Problèmes APIPA, mDNS et spam DHCPv6
« Réponse #195 le: 28 mai 2022 à 12:09:31 »
Rien de choquant, c'est simplement de l'unknown unicast, c'est le fonctionnement classique d'un réseau Ethernet quand une MAC n'est pas peuplée en FDB -> Flood sur tous les ports
Je ne crois pas qu'on soit dans ce cas de figure. La MAC cible et l'IP cible du traffic que j'ai reçu correspondent bien à un autre client (dixit le service technique que je viens d'appeler).

(et accessoirement, dans un réseau bien configuré on est pas censé désactiver l'UU forwarding, notamment pour éviter les storm? Je suis un peu rouillé en réseau mais il me semble que ça fait partie des "best practice" non?)

Hugues

  • AS2027 MilkyWan
  • Modérateur
  • *
  • Messages: 12 425
  • Lyon (69) / St-Bernard (01)
    • Twitter
[SUIVI] K-Net/Covage 14 - Problèmes APIPA, mDNS et spam DHCPv6
« Réponse #196 le: 28 mai 2022 à 12:20:01 »
Oui, genre un client qui aurait éteint sa box ? Du coup plus de résolution MAC et donc unknown unicast.

Et non, on ne désactive pas l'unknown unicast, a moins d'être en mac-db statique (ce qui est un enfer à gérer), le flooding des paquets pour learn c'est le principe de base de tous les réseaux ethernet depuis que ça existe (il faut bien que le switch sache où se trouve la MAC, il doit donc broadcaster), même si il existe des mécanismes pour ne plus avoir à le faire en partie (notamment en EVPN). Par contre, tu es censé les limiter à quelque chose comme 0,1% de la capa de ton interface pour éviter les storm

blarglibloup

  • Invité
[SUIVI] K-Net/Covage 14 - Problèmes APIPA, mDNS et spam DHCPv6
« Réponse #197 le: 28 mai 2022 à 12:28:38 »
Oui, genre un client qui aurait éteint sa box ? Du coup plus de résolution MAC et donc unknown unicast.
Euh what? Les MAC des boxs sont pas en static? Donc il suffit d'éteindre sa box pour que les voisins récupèrent le traffic? Et si un des voisins spoofe la MAC, il se passe quoi? c'est pas un peu problématique?

Petite précision: le traffic reçu entre 23h40 (plausible) et 4h55 (ça fait très matinal pour "rallumer" sa box quand même non? ;) )

Et non, on ne désactive pas l'unknown unicast, a moins d'être en ip statique, le flooding des paquets pour learn c'est le principe de base de tous les réseaux ethernet depuis que ça existe, même si il existe des mécanismes pour ne plus avoir à le faire en partie (notamment en EVPN)
Ah ouais je suis confusé, je raisonnais L2/L3 (ARP), mais évidemment ça ne concerne pas les switchs. Néanmoins, je pensais que côté infra les MAC étaient en dur, pour éviter le flood et pour "sécuriser"?

Hugues

  • AS2027 MilkyWan
  • Modérateur
  • *
  • Messages: 12 425
  • Lyon (69) / St-Bernard (01)
    • Twitter
[SUIVI] K-Net/Covage 14 - Problèmes APIPA, mDNS et spam DHCPv6
« Réponse #198 le: 28 mai 2022 à 12:39:54 »
Euh what? Les MAC des boxs sont pas en static? Donc il suffit d'éteindre sa box pour que les voisins récupèrent le traffic? Et si un des voisins spoofe la MAC, il se passe quoi? c'est pas un peu problématique?
Non, tu as des mécanismes qui permettent d'éviter ça (MFF peuplé par DHCP Snooping) mais ça ne filtre que le trafic sortant des ONT, pas le trafic entrant

Petite précision: le traffic reçu entre 23h40 (plausible) et 4h55 (ça fait très matinal pour "rallumer" sa box quand même non? ;) )
En tout cas elle était injoignable, pour quelle raison, ça c'est une autre histoire :)

Ah ouais je suis confusé, je raisonnais L2/L3 (ARP), mais évidemment ça ne concerne pas les switchs. Néanmoins, je pensais que côté infra les MAC étaient en dur, pour éviter le flood et pour "sécuriser"?

Non c'est impossible de maintenir une DB de plusieurs milliers de MAC sur chaque équipement traversant, on fait du DHCP Snooping pour n'autoriser dans le L2 que les MAC qui ont un lease DHCP valide, ça suffit pour faire le ménage

Optix

  • AS41114 - Expert OrneTHD
  • Abonné Orne THD
  • *
  • Messages: 4 644
  • WOOHOO !
    • OrneTHD
[SUIVI] K-Net/Covage 14 - Problèmes APIPA, mDNS et spam DHCPv6
« Réponse #199 le: 28 mai 2022 à 12:54:10 »
Pour compléter, si le mec :

- force une IP statique : sa MAC n'est pas apprise via le LAN avec ARP mais via le DHCP snooping qui peuple la table au moment du lease. Donc le mec n'aura aucun trafic dans la tronche. Niqué.

- se met en DHCP avec une MAC spoofé du voisin : il n'aura aucun lease, car le DHCP snooping communique aussi le "circuit-id", càd l'interface concernée (l'arbre pon concerné et l'id de l'ONU/ONT). Et forcément j'attends une MAC très précise pour TON port et pas une autre, donc niqué.

Perso, on whiteliste seulement la mac déclarée dans le dossier client, comme ça que je me protège des techs qui inversent des boxs et des LAN abonnés qui fuient :)

blarglibloup

  • Invité
[SUIVI] K-Net/Covage 14 - Problèmes APIPA, mDNS et spam DHCPv6
« Réponse #200 le: 28 mai 2022 à 13:00:19 »
Non, tu as des mécanismes qui permettent d'éviter ça (MFF peuplé par DHCP Snooping) mais ça ne filtre que le trafic sortant des ONT, pas le trafic entrant

Non c'est impossible de maintenir une DB de plusieurs milliers de MAC sur chaque équipement traversant, on fait du DHCP Snooping pour n'autoriser dans le L2 que les MAC qui ont un lease DHCP valide, ça suffit pour faire le ménage
OK donc pour prendre un exemple, si un abonné centralise chez lui des flux (e.g un monitoring, disons collectd par exemple qui passe tout en clair, mais ça pourrait être de la télésurveillance aussi) de plusieurs sites distants, et que pour une raison ou pour une autre, son routeur se déconnecte, tous ses voisins peuvent "écouter" les flux en question? Je suis surleculfié :) (et ça me renforce dans ma tendance paranoïaque à chiffrer au maximum mon trafic)

blarglibloup

  • Invité
[SUIVI] K-Net/Covage 14 - Problèmes APIPA, mDNS et spam DHCPv6
« Réponse #201 le: 28 mai 2022 à 13:02:03 »
Pour compléter, si le mec :

- force une IP statique : sa MAC n'est pas apprise via le LAN avec ARP mais via le DHCP snooping qui peuple la table au moment du lease. Donc le mec n'aura aucun trafic dans la tronche. Niqué.

- se met en DHCP avec une MAC spoofé du voisin : il n'aura aucun lease, car le DHCP snooping communique aussi le "circuit-id", càd l'interface concernée (l'arbre pon concerné et l'id de l'ONU/ONT). Et forcément j'attends une MAC très précise pour TON port et pas une autre, donc niqué.

Perso, on whiteliste seulement la mac déclarée dans le dossier client, comme ça que je me protège des techs qui inversent des boxs et des LAN abonnés qui fuient :)
C'est plus clair, merci pour les détails :)

Hugues

  • AS2027 MilkyWan
  • Modérateur
  • *
  • Messages: 12 425
  • Lyon (69) / St-Bernard (01)
    • Twitter
[SUIVI] K-Net/Covage 14 - Problèmes APIPA, mDNS et spam DHCPv6
« Réponse #202 le: 28 mai 2022 à 13:04:43 »
OK donc pour prendre un exemple, si un abonné centralise chez lui des flux (e.g un monitoring, disons collectd par exemple qui passe tout en clair, mais ça pourrait être de la télésurveillance aussi) de plusieurs sites distants, et que pour une raison ou pour une autre, son routeur se déconnecte, tous ses voisins peuvent "écouter" les flux en question? Je suis surleculfié :) (et ça me renforce dans ma tendance paranoïaque à chiffrer au maximum mon trafic)

Bah si tu envoies bêtement de l'UDP, oui (enfin je doute qu'Axione n'ait pas mis de limite a quelques dixièmes de % des interfaces pour l'UU.
Si c'est du TCP non, la session ne s'établira pas.

Sachant que normalement tu as un timeout sur ARP, typiquement chez nous c'est 5 minutes, mais je sais que K-Net avait déjà trafiqué ça par le passé

blarglibloup

  • Invité
[SUIVI] K-Net/Covage 14 - Problèmes APIPA, mDNS et spam DHCPv6
« Réponse #203 le: 28 mai 2022 à 13:09:07 »
Bah si tu envoies bêtement de l'UDP, oui (enfin je doute qu'Axione n'ait pas mis de limite a quelques dixièmes de % des interfaces pour l'UU.
Si c'est du TCP non, la session ne s'établira pas.

Sachant que normalement tu as un timeout sur ARP, typiquement chez nous c'est 5 minutes, mais je sais que K-Net avait déjà trafiqué ça par le passé
Thanks. Je me coucherai moins bête ce soir ;)
Du coup j'ai pris la tête à "Mikaël" pour rien  ;D
Enfin la morale de l'histoire c'est qu'au moins ma route optique est fonctionnelle!