Auteur Sujet: Paquets UDP APIPA dans la boucle locale Covage 14 (Lu 4879 fois)

bolemo · « **le:** 29 octobre 2020 à 14:11:56 »

Bonjour,

J’ai abordé ce sujet sur le forum caps de K-Net ( https://forum.caps.services/index.php/topic,8122.0.html ), mais comme cela concerne tous abonnés de Covage 14 (tous FAI confondus sauf peut-être les offres passives), je poste ici.

Je reçois depuis le WAN des paquets UDP provenant d’une adresse APIPA, toutes les 15 secondes en moyenne. Actuellement, c’est 169.254.64.208, mais hier, c’était 169.254.234.247. Le port d’origine est 49150.
Ces paquets sont destinés au broadcast 255.255.255.255 port 49152.

L’analyse de ces paquets me donne ceci (scan sur 10 secondes) :

Code: [Sélectionner]

 root@HERMES:~$ tcpdump -i brwan udp port 49150 -vv -X
tcpdump: listening on brwan, link-type EN10MB (Ethernet), capture size 96 bytes
11:25:05.417880 IP (tos 0x0, ttl 64, id 63302, offset 0, flags [DF], proto UDP (17), length 48) 169.254.64.208.49150 > 255.255.255.255.49152: [udp sum ok] UDP, length 20
        0x0000:  4500 0030 f746 4000 4011 58a8 a9fe 40d0  E..0.F@.@.X...@.
        0x0010:  ffff ffff bffe c000 001c 9952 5245 4e53  ...........RRENS
        0x0020:  4f4e 5f44 4556 4943 452f 4a53 4f4e 3f00  ON_DEVICE/JSON?.
11:25:15.421035 IP (tos 0x0, ttl 64, id 63939, offset 0, flags [DF], proto UDP (17), length 48) 169.254.64.208.49150 > 255.255.255.255.49152: [udp sum ok] UDP, length 20
        0x0000:  4500 0030 f9c3 4000 4011 562b a9fe 40d0  E..0..@.@.V+..@.
        0x0010:  ffff ffff bffe c000 001c 9952 5245 4e53  ...........RRENS
        0x0020:  4f4e 5f44 4556 4943 452f 4a53 4f4e 3f00  ON_DEVICE/JSON?.
^C
2 packets captured
2 packets received by filter
0 packets dropped by kernel

Les pings ICMP, UDP et TCP ne retournent rien, mais ARP oui :

Code: [Sélectionner]

 root@HERMES:~$ arping -I brwan 169.254.64.208
ARPING 169.254.64.208 from 2.59.XX.XX brwan
Unicast reply from 169.254.64.208 [00:11:2a:22:48:e7] 5.905ms
Unicast reply from 169.254.64.208 [00:11:2a:22:48:e7] 5.342ms
Unicast reply from 169.254.64.208 [00:11:2a:22:48:e7] 5.373ms
Unicast reply from 169.254.64.208 [00:11:2a:22:48:e7] 5.373ms
Unicast reply from 169.254.64.208 [00:11:2a:22:48:e7] 5.374ms
Unicast reply from 169.254.64.208 [00:11:2a:22:48:e7] 5.530ms
Unicast reply from 169.254.64.208 [00:11:2a:22:48:e7] 5.530ms
Unicast reply from 169.254.64.208 [00:11:2a:22:48:e7] 5.467ms
^CSent 8 probe(s) (1 broadcast(s))
Received 8 response(s) (0 request(s), 0 broadcast(s))

Cela me donne trois informations :
1) La MAC de cet appareil qui est 00:11:2a:22:48:e7
Cette MAC indique que c’est un appareil de chez Niko NV - Industriepark West 40 - Sint-Niklaas O/V 9100 - BE
https://www.niko.eu/fr-fr
Donc sauf MAC spoofing, c’est un appareil de domotique de chez Niko.

2) Le temps de latence d’environ 5.5 ms, et
3) Le fait que l’appareil soit visible avec arp :
Le routeur de collecte Covage 14 (10.2.0.211), ainsi que la passerelle WAN sont à 2.5 ms de mon routeur.
Les routeurs d’échange Covage/FAI sont à 7 ms de mon routeur.

Cet appareil étant à 5.5 ms et dans mon voisinage arp, il est situé avant la livraison Covage aux FAI, quelque part dans la boucle de collecte 14.

Quelqu’un a donc connecté un appareil domotique au mauvais endroit ou sur un switch connecté à leur ONT.

Apparemment, les routeurs Covage laissent passer les paquets provenant d’adresses privées (ici APIPA) et les distribuent partout (car destination 255.255.255.255 qui signifie tous les appareils).

Ce n’est pas dramatique ici, mais Covage devrait bloquer ces paquets qui polluent la boucle, car tous les clients de ma boucle locale (possiblement tous les clients Covage 14 actif) reçoivent ces paquets.

Peut-être que l’abonné fibre qui possède cet appareil Niko lit ce forum, et devrait vérifier son installation, car 1) l’appareil ne fonctionne probablement pas (pas d’IP attribuée car APIPA...) et 2) la configuration de son réseau local n’est pas correcte.

bolemo · « **Réponse #1 le:** 31 octobre 2020 à 17:09:52 »

Les paquets en provenance de l’adresse 255.255.255.255 sont transmis par les switches, mais en principe pas par les routeurs. Ce n’est donc adressé qu’à tous les voisins d’un même réseau.

Ça semble cohérent puisqu’arp ne peut voir que le voisinage réseau.

Donc ça serait un appareil sur la boucle locale, avant le premier routeur de Covage, donc sur le même switch que moi dans le NRO, et ça pourrait donc venir d’un client en offre passive.

A moins qu’un routeur Covage laisse passer cette adresse...

Personne de chez Covage ici qui pourrait vérifier d’où ça provient ?

Steph · « **Réponse #2 le:** 31 octobre 2020 à 17:34:03 »

En principe, les adresse APIPA sont locales au subnet.

Ce serait sympa d'avoir des gens de chez Covage sur ce forum. Je n'en ai malheureusement jamais vu... ou du moins, ils ne l'ont pas dit...

bolemo · « **Réponse #3 le:** 31 octobre 2020 à 18:00:53 »

C’est cohérent.

Un appareil domotique ne reçoit aucune configuration DHCP, donc il se donne une adresse APIPA.
Ensuite, il cherche à communiquer avec tous ses voisins sur son voisinage avec une requête UDP de type JSON, probablement un esclave qui cherche son maître, ou un maître qui cherches les esclaves de ce système domotique.

Maintenant pourquoi ces paquets se retrouvent-ils dans une boucle de collecte Covage ?

Comment une adresse non attribuée par Covage (et derrière les FAI) peut elle envoyer des paquets à tous le voisinage, et qu’elle est la taille du voisinage ?

Apparemment, cela laisse entendre que n’importe quel appareil connecté à un ONT ou sur un switch sur l’ONT peut s’attribuer une adresse et envoyer des paquets à tout le voisinage (département ?).

Tant que l’on rencontre des switches, à priori, on reste local.
Donc, où se trouve le tout premier routeur ? Au NRO, à la collecte départementale ?

Le premier que je peux pinguer ou qui répond à traceroute est le fameux 10.2.0.211, la collecte départementale du 14, donc est-ce que cet appareil envoie des paquets dans tout le 14 ou seulement mon NRO ?

Ici, c’est clairement quelqu’un qui a très mal configuré son réseau (et son appareil ne fonctionne probablement pas ainsi), et sans danger, mais cela soulève des questions de sécurité...

Steph · « **Réponse #4 le:** 31 octobre 2020 à 18:51:45 »

Pour le voisinage, dificile à dire : cela dépend de qui voit qui. Après l'OLT, je ne sais pas trop ce qu'il y a...

Le premier routeur de collecte est en 10.2.0.x et en gros, il y en a un par département (sauf dans le 77 où il y en a plein...)
https://forum.caps.services/index.php/topic,7534.msg95039.html

Il faudrait que d'autres utilisateur de Covage 14 nous disent s'ils voient ses fameux paquets.
C'est peut être parce que ces paquets peuvent se balader qu'ils y a des problèmes sporadiques sur le réseau Covage14 en ce momment?

Je n'ai jamais très bien compris comment marchent les sous-réseaus Covage en 10.2.0.x.
Nos routeurs ont bien une passerelle en IPpublique.254 chez K-net, adresse portée par le routeur Covage 10.2.0.x? Routeur qui forward tout à K-net.
Il ne forward certainement pas les paquets APIPA que tu reçois.

Concernant la sécurité du sous-réseau, j'ai l'impression que c'est fragile : N'importe quelle appareil avec n'importe quelle IP peut causer sur le sous réseau. Il ne passera pas le routeur si l'IP n'est pas reconnues. Et l'IP en question doit être distribuée par DHCP avec association MAC pour la sécurité.

bolemo · « **Réponse #5 le:** 31 octobre 2020 à 20:33:46 »

Oui, je crois qu’à partir du routeur départemental, les paquets sont bloqués.
Avant, ce ne sont probablement que des switches.

L’IP APIPA a de nouveau changée, maintenant, c’est 169.254.189.112

Ça ne m’étonnerait pas que ces paquets perturbent certaines boxes, oui...

Mimou1208 · « **Réponse #6 le:** 01 novembre 2020 à 11:39:55 »

Bonjour, voilà ce que j'ai chez moi sur mon routeur Netgear dans mes logs

[LAN access from remote] from 169.254.189.112:5353 to 192.168.1.5:5353, Sunday, November 01, 2020 11:32:44

Je joint aussi un screen de mon geofiltrage qui m'indique que l'équipement fait quand même pas mal de ping

bolemo · « **Réponse #7 le:** 01 novembre 2020 à 13:48:46 »

@Mimou1208 : C’est vraiment curieux ça ! Cet appareil envoie aussi des paquets chez vous, mais depuis un autre port 5353 vers 5353 qui est du multicast DNS.
Avez-vous moyen de faire un tcpdump des paquets que vous recevez pour voir si ce sont les mêmes que les miens ?

Si oui, il y aurait donc un routeur chez Covage qui ferait de la redirection de port pour cet appareil... Ça serait curieux.

Si non, cet appareil envoie plusieurs paquets sur différents ports, mais je ne reçois que ceux concernant le port 49150, et vous ceux concernant le port 5353 (et il y aurait donc un filtrage partiel de certains ports dans la boucle Covage).

Quoi qu’il e soit, c’est de plus en plus curieux... Vous êtes dans quel coin du Calvados ?

EDIT : un instant, l’appareil cible un appareil spécifique de votre LAN ! 192.168.1.5
Mon log Netgear ne me montre pas les paquets, c’est mon script perso Aegis qui les bloque (blocage par iptables depuis des listes ipset, du même genre que FireHOL). Peut-être que les paquets du port 49150 arrivent bien chez vous aussi (ils ne ciblent personne en particulier, broadcast), mais le paquet que votre routeur a détecté semble ciblé. Avez vous une règle NAT pour le port 5353 ?

bolemo · « **Réponse #8 le:** 02 novembre 2020 à 13:23:29 »

L’IP a de nouveau changé: 169.254.228.175

bolemo · « **Réponse #9 le:** 05 novembre 2020 à 17:24:24 »

Maintenant : 169.254.196.192

Steph · « **Réponse #10 le:** 05 novembre 2020 à 17:32:10 »

T'as essayé de contacter un expert Covage?

https://www.covage.com
pied de page "Vous avez des questions?"

On peut toujours rêver...

bolemo · « **Réponse #11 le:** 05 novembre 2020 à 18:13:45 »

Citation de: Steph le 05 novembre 2020 à 17:32:10

T'as essayé de contacter un expert Covage?
https://www.covage.com
pied de page "Vous avez des questions?"

On peut toujours rêver...

C’est fait.
J’ai été technique et spécifique. À suivre...