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

bolemo · « **Réponse #348 le:** 04 juillet 2022 à 20:38:53 »

Je remarque aussi que l'adresse MAC de la passerelle infra a changé…

pju91 · « **Réponse #349 le:** 05 juillet 2022 à 09:59:24 »

Citation de: bolemo le 04 juillet 2022 à 20:38:53

Je remarque aussi que l'adresse MAC de la passerelle infra a changé…

Difficile de dire ce qui a changé sur l'infra AI. Tu vois qu'ils ont mis une autre passerelle, ça n'est donc pas qu'une question de reconfiguration des équipements pré-existants.
Il faudrait, pour satisfaire notre curiosité intellectuelle et comprendre pourquoi ça a amélioré la situation sur ton réseau de collecte, que tu leur demandes en quoi a consisté cette intervention du 4 juillet au matin.

bolemo · « **Réponse #350 le:** 05 juillet 2022 à 13:55:24 »

Citation de: pju91 le 05 juillet 2022 à 09:59:24

Difficile de dire ce qui a changé sur l'infra AI. Tu vois qu'ils ont mis une autre passerelle, ça n'est donc pas qu'une question de reconfiguration des équipements pré-existants.
Il faudrait, pour satisfaire notre curiosité intellectuelle et comprendre pourquoi ça a amélioré la situation sur ton réseau de collecte, que tu leur demandes en quoi a consisté cette intervention du 4 juillet au matin.

Je vais faire un courriel de remerciement à la DC d'AI 14, et je vais aller à la pêche (je ne crois pas qu'ils nous diront grand chose…)

À mon avis, ils ont du changer des switches qui ne devaient pas permettre la gestion avancée des règles de routage L2 nécessaires, et ils en ont peut-être profité pour refondre un peu l'infra.
Ou encore ils ont refait une infra en parallèle avec les nouveaux réglages et ont basculé d'un coup.

Ma longue coupure était du au fait que je n'autorise que la connexion vers le switch OI, et comme ils l'ont changé, j'interdisait le nouveau switch. J'ai du redémarrer hier mon routeur pour que mon script détecte la nouvelle adresse MAC.

blarglibloup · « **Réponse #351 le:** 05 juillet 2022 à 14:27:17 »

Citation de: bolemo le 05 juillet 2022 à 13:55:24

Ma longue coupure était du au fait que je n'autorise que la connexion vers le switch OI, et comme ils l'ont changé, j'interdisait le nouveau switch. J'ai du redémarrer hier mon routeur pour que mon script détecte la nouvelle adresse MAC.

Aucun intérêt. Par définition il n'y a que ce switch qui te parle. Tu fatigues ton routeur avec des checks inutiles et tu te retrouveras à nouveau coupé au prochain changement de l'OI.

Hugues · « **Réponse #352 le:** 05 juillet 2022 à 14:32:44 »

Vu le bazar qu'il y'avait sur la collecte je ne lui jetterai pas la pierre ^^

bolemo · « **Réponse #353 le:** 05 juillet 2022 à 14:34:32 »

Citation de: blarglibloup le 05 juillet 2022 à 14:27:17

Aucun intérêt. Par définition il n'y a que ce switch qui te parle. Tu fatigues ton routeur avec des checks inutiles et tu te retrouveras à nouveau coupé au prochain changement de l'OI.

J'avais mis cela en place, car ça me bloquait bien des trucs justement (les fuites dont la MAC source n'était pas celle de la passerelle). Peut-être inutile maintenant mais ça ne ralentit en rien mon routeur (simple règle ebtables) et sa charge CPU avec toutes mes règles (ebtables, iptables…), supervision… reste en dessous de 4%, et c'est aussi une sécurité de plus en cas de MitM (très peu probable on est d'accord).

blarglibloup · « **Réponse #354 le:** 05 juillet 2022 à 15:20:35 »

Citation de: Hugues le 05 juillet 2022 à 14:32:44

Vu le bazar qu'il y'avait sur la collecte je ne lui jetterai pas la pierre ^^

Certes

Citation de: bolemo le 05 juillet 2022 à 14:34:32

J'avais mis cela en place, car ça me bloquait bien des trucs justement (les fuites dont la MAC source n'était pas celle de la passerelle). Peut-être inutile maintenant mais ça ne ralentit en rien mon routeur (simple règle ebtables) et sa charge CPU avec toutes mes règles (ebtables, iptables…), supervision… reste en dessous de 4%, et c'est aussi une sécurité de plus en cas de MitM (très peu probable on est d'accord).

4% à plein débit? C'est quoi ton routeur?

MitM: lol. Quand bien même ça arriverait (rêvons un peu), celui qui se donnera cette peine prendra aussi a minima celle de cloner la MAC.
Non vraiment ça ne sert à rien à part rajouter un point de casse possible dans ta config dès que l'OI change quelque chose (comme ce fut le cas).

Fyr · « **Réponse #355 le:** 05 juillet 2022 à 16:14:47 »

Citation de: pju91 le 05 juillet 2022 à 09:59:24

Difficile de dire ce qui a changé sur l'infra AI. Tu vois qu'ils ont mis une autre passerelle, ça n'est donc pas qu'une question de reconfiguration des équipements pré-existants.
Il faudrait, pour satisfaire notre curiosité intellectuelle et comprendre pourquoi ça a amélioré la situation sur ton réseau de collecte, que tu leur demandes en quoi a consisté cette intervention du 4 juillet au matin.

Bah apparemment certains ont parlé de changement de MAC A partir de là on peut connaitre le fabricant. Si ça a changé ça appuie la nouvelle passerelle différente. Mais ça peut être aussi la même mais via "un circuit" enfin sécurisé sans fuite. Les équipements ont quand même une MAC différente par interface.

Citation de: bolemo le 05 juillet 2022 à 14:34:32

J'avais mis cela en place, car ça me bloquait bien des trucs justement (les fuites dont la MAC source n'était pas celle de la passerelle). Peut-être inutile maintenant mais ça ne ralentit en rien mon routeur (simple règle ebtables) et sa charge CPU avec toutes mes règles (ebtables, iptables…), supervision… reste en dessous de 4%, et c'est aussi une sécurité de plus en cas de MitM (très peu probable on est d'accord).

C'est pas le MitM qui est gênant mais qu'on puisse écouter le trafic WAN de qqn d'autre. En plus de laisser la porte ouverte à l'émission de paquet vers tout le monde, y compris les paquets rigolos. C'est pas interdit d'aller sur le web de son voisin (et heureusement) mais d'avoir des trafics non maitrisés. (sur le câble y avait des crétins qui fouttaient du 220V sur le coax... je ne doute plus de rien sur la connerie dès qu'un truc est possible)

blarglibloup · « **Réponse #356 le:** 05 juillet 2022 à 16:34:54 »

Citation de: Fyr le 05 juillet 2022 à 16:14:47

(sur le câble y avait des crétins qui fouttaient du 220V sur le coax... je ne doute plus de rien sur la connerie dès qu'un truc est possible)

Oui quand les voisins t'emmerdent avec la télé trop fort c'est une solution qui a fait ses preuves

bolemo · « **Réponse #357 le:** 05 juillet 2022 à 16:52:47 »

Mac passerelle, même fabriquant : Nokia
Après, matériel différent ou interface différente, peu importe, ce qui compte c’est que la collecte est plus sécurisée. Un hacker mal intentionné pouvait obtenir plein d’infos (et mettre le boxon aussi ).

Pour ma règles ebtables (et plein d’autres iptables), ça ne me pose pas de problème, dès que j’ai réalisé que j’avais perdu la connexion, je suis allé sur le routeur en ssh, et j’ai identifié le problème de suite. Un redémarrage du routeur et voilà (mon script trouve tout seul la MAC au lancement).
Je pourrais faire un check toutes les minutes par crontab et changer dynamiquement, mais le changement de la MAC de la passerelle,c’est rare quand même.

Et mon routeur, c’est un Netgear R7800, une bête en ce qui concerne le routage car j’utilise l’accélération matérielle. Je peux avoir plusieurs speedtest en parallèle depuis le LAN et le CPU ne bouge quasiment pas. En revanche, un speedtest depuis le routeur lui-même sature le CPU, car on ne passe plus par l’accélération CPU.

J’ai installé un IDS récemment, et le port mirroring natif de Netgear était médiocre (plafonnement des débits LAN/WAN). Du coup je passe par une règle TEE iptables, et mes débits sont plein pot, encore une fois merci l’accélération matérielle.

blarglibloup · « **Réponse #358 le:** 05 juillet 2022 à 18:45:42 »

Citation de: bolemo le 05 juillet 2022 à 16:52:47

Pour ma règles ebtables (et plein d’autres iptables), ça ne me pose pas de problème, dès que j’ai réalisé que j’avais perdu la connexion, je suis allé sur le routeur en ssh, et j’ai identifié le problème de suite. Un redémarrage du routeur et voilà (mon script trouve tout seul la MAC au lancement).
Je pourrais faire un check toutes les minutes par crontab et changer dynamiquement, mais le changement de la MAC de la passerelle,c’est rare quand même.

Reboot routeur à la mano possible uniquement quand tu es chez toi. Quant au script qui "trouve tout seul la MAC", il est encore plus inutile en cas de MitM

Citation de: bolemo le 05 juillet 2022 à 16:52:47

Et mon routeur, c’est un Netgear R7800, une bête en ce qui concerne le routage car j’utilise l’accélération matérielle. Je peux avoir plusieurs speedtest en parallèle depuis le LAN et le CPU ne bouge quasiment pas. En revanche, un speedtest depuis le routeur lui-même sature le CPU, car on ne passe plus par l’accélération CPU.

Je comprends mieux. Tu ne gères donc pas la latence ("bufferbloat") côté routeur. Perso une bonne gestion de la latence me paraît bien plus importante que d'assurer un débit collé au plafond. Chacun ses prios

bolemo · « **Réponse #359 le:** 06 juillet 2022 à 00:43:00 »

Citation de: blarglibloup le 05 juillet 2022 à 18:45:42

Reboot routeur à la mano possible uniquement quand tu es chez toi. Quant au script qui "trouve tout seul la MAC", il est encore plus inutile en cas de MitM
Je comprends mieux. Tu ne gères donc pas la latence ("bufferbloat") côté routeur. Perso une bonne gestion de la latence me paraît bien plus importante que d'assurer un débit collé au plafond. Chacun ses prios

Ah, bah on peut argumenter et avoir tous deux raison

Je ne rencontre pas de problème de latence ; j’ai choisi l’algorithme de congestion qui me va le mieux, et j’ai passé du temps à optimiser les règles, scripts du routeur, éléments sysctl, etc.
Ça marche pour moi et mon utilisation, probablement pas pour d’autres.

La règle ebtables, je l’avais mise en place car elle me protégeait (très bien) des fuites sur la boucle.
C’est probablement devenu inutile, mais bon, une protection de plus qui n’impacte pas les performances… C’est comme mes règles de port knocking pour un accès depuis l’extérieur sur certains services… Sont-elles vraiment utiles ? Probablement pas, car mes serveurs sont protégés en SSL, mais bon, j’ai monté mon truc à la main.
Ainsi j’apprends des choses ; c’est comme ça que j’ai découvert les fuites d’ailleurs…

Certes, le script capte tout seul la MAC de La passerelle ainsi :

Code: [Sélectionner]

 GW_IP="$(ip route show 0.0.0.0/0 dev brwan | cut -d\  -f3)"
GW_MAC="$(/usr/bin/arping -f -i brwan $GW_IP | /usr/bin/awk '$1=="Unicast"{print substr($5,2,length($5)-2);exit}')"

Le but à l’époque était d’éliminer le bruit venant des fuites.
Donc oui, je devrais peut-être hardcoder la MAC de la passerelle pour une meilleure protection d’un MitM, ou tout simplement me débarrasser de cette règle (en cas de MitM avec spoof de la MAC de la passerelle), ou la laisser pour me protéger d’éventuelles fuites.

De toute façon, je supervise mon routeur, mon ONT, les temps de latence entre mon routeur et la passerelle, puis les routeurs de collecte… Donc une activité MitM, à moins qu’elle soit très bien faite, changerait ces latences.
J’ai aussi un IDS avec Suricata et ELK.

J’isole les appareils IoT d’internet pour qu’ils n’appellent pas à la maison, etc.
Mais tout cela, c’est un hobby aussi, car j’en n’ai pas vraiment de données sensibles, et je ne suis pas une cible intéressante. Je m’entraîne et j’apprends