La Fibre
Datacenter et équipements réseaux => Routeurs => 
Remplacer la LiveBox par un routeur => Discussion démarrée par: TheHecateII le 09 décembre 2025 à 15:33:51
-
Bonjour, premier post pour moi sur le forum.
Depuis quelques jours, @Raraph84 et moi-même testons cette idée un peu loufoque de remplacer notre Livebox par un conteneur Docker.
Forcément, ce projet s'adresse aux personnes qui ont/vont procéder à l'opération depuis un OS basé sur Linux (Debian 13 lors de nos tests).
Voici les liens du projet, n'hésitez pas à tester et nous faire des retours, une update est prévu pour la télé/téléphone quand le temps nous le permettra :
GitHub : https://github.com/Raraph84/docker-livebox (https://github.com/Raraph84/docker-livebox)
Docker Hub : https://hub.docker.com/r/raraph84/livebox (https://hub.docker.com/r/raraph84/livebox)
Bien évidemment, ce projet a été possible grâce aux ressources déjà présentes.
Merci à toutes les personnes qui ont partagé des infos ! ^^
-
Bonsoir,
outre le poc, quels seraient les futurs développements?
-
Bonjour,
Dans le futur nous comptons le rendre plus flexible (pouvoir activer/désactiver des fonctionnalités)
Et aussi implémenter d'autres fonctionnalités présentes dans la Livebox comme un serveur DHCP par exemple
N'hésitez pas aussi à proposer des idées et à faire des PR :p
-
Bonne initiative ! Par contre sourcez/listez les noms des personnes et repo git chez qui vous prenez des bouts de script/code. (je peux voir qu'une partie vient de chez moi :p)
Mais sinon top d'avoir une possibilité suplémentaire de choix de deploy/usage.
-
Oui j'ai justement pensé hier soir qu'on avait oublié de citer nos sources, je vais faire ca tout de suite !
-
Pour info j'ai essayer de passer mon wiki debian 13 en usage de networkd, ça a été une catastrohpe. Je ne recommande pas l'usage, en tout cas pour le moment.
-
Bonsoir,
Après avoir détaillé mes péripéties, je viens aux nouvelles pour l'édition Livebox.
Il semblerait que le bug CoS/VLAN que j'ai découvert côté Bouygues affecte également Orange. La différence, est que Orange répond au DHCP quelle que soit l'adresse IP source de la requête, alors que Bouygues ignore tout simplement les paquets malformés.
Le bug existe des deux côtés, mais il passe inaperçu chez Orange car leur serveur DHCP est plus permissif.
Si malgré tout vous souhaitez corriger le souci, un passage sur une carte E1000 sur Proxmox règle le problème (Pour les VM du moins). Je prendrai le temps de lister les cartes/chipsets touchés quand j'aurai le temps.
-
une IP source dans une requête DHCP ?
-
une IP source dans une requête DHCP ?
C'est un abus de langage de ma part. Dans un DHCP Discover, le client n'a pas encore d'IP donc l'en-tête IP contient 0.0.0.0 en source.
Le bug fait que ce champ passe de 0.0.0.0 à 0.0.255.255 (décalage de 2 octets dans le paquet).
Extrait sur mes tests bouygues (Valable chez Orange) :
00:28:34.470393 f8:ab:05:09:14:a8 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 346: vlan 100, p 6, ethertype IPv4 (0x0800), (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
0.0.255.255.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from f8:ab:05:09:14:a8, length 300
-
C'est un abus de langage de ma part. Dans un DHCP Discover, le client n'a pas encore d'IP donc l'en-tête IP contient 0.0.0.0 en source.
Le bug fait que ce champ passe de 0.0.0.0 à 0.0.255.255 (décalage de 2 octets dans le paquet).
Eh bé !
Il semblerait que le bug CoS/VLAN que j'ai découvert côté Bouygues affecte également Orange. La différence, est que Orange répond au DHCP quelle que soit l'adresse IP source de la requête, alors que Bouygues ignore tout simplement les paquets malformés.
Ce n'est pas un bogue à proprement dit. Si c'est le cas alors l'application est défectueuse (invalide en l'état).
Je ne comprends pas le motif. Présenter un produit comme étant fini « à fin éducatif ou usage personnel » mais qui est bancal.
On est sur une solution professionnelle (ayant pour vocation de remplacer une Livebox) mais partiellement achevée. Je trouve
que cela manque de rigueur.
-
Eh bé !
Ce n'est pas un bogue à proprement dit. Si c'est le cas alors l'application est défectueuse (invalide en l'état).
Je ne comprends pas le motif. Présenter un produit comme étant fini « à fin éducatif ou usage personnel » mais qui est bancal.
On est sur une solution professionnelle (ayant pour vocation de remplacer une Livebox) mais partiellement achevée. Je trouve
que cela manque de rigueur.
Je n'ai jamais prétendu que c'était une solution professionnelle. Le projet est open source et en phase de test, c'est écrit noir sur blanc. L'objectif est justement de partager et de permettre à la communauté de contribuer.
Tout ça est fait par passion et gratuitement.
Concernant le "bug", il s'agit d'un problème dans le fonctionnement même de nftables sur les interfaces VLAN avec certains drivers.
Ce n'est pas un défaut du projet en lui même. D'ailleurs, un rapport a été soumis aux développeurs de netfilter.
Si vous pensez pouvoir corriger ce bug, je vous invite à faire une PR ^^
-
@TheHecatell :
Mon jugement était hâtif. Le projet pourrait laisser supposer que c'est clé en main avec Docker. On est sur du déploiement automatisé.
J'étais parti sur de l'ingénierie système ou développement bas niveau sans chercher plus loin. Quoi qu'il en soit, le propos n'était pas
explicite (mis en lien avec nftables). Je n'ai rien compris non plus au rapport de bogue (https://bugzilla.netfilter.org/show_bug.cgi?id=1673). J'ai fait fausse route et je n'ai pas non plus
bien cerné le caractère expérimental du projet : pour une personne carré cela n'a rien de loufoque.
-
Pas de souci, je comprends que ça pouvait prêter à confusion ;D
Pour faire simple les paquets DHCP qui passent par une règle nftables du type :
nft insert "rule netdev filter egress udp dport 67 meta priority set 0:6 ip dscp set cs6"
Sur une machine bare metal ou avec une émulation hardware type Intel E1000 sous Proxmox, le paquet DHCP part avec un wildcard correct : 0.0.0.0.68 > 255.255.255.255.67
Cependant, si l'hôte est virtualisé avec des drivers VirtIO, le wildcard passe à 0.0.255.255.68 > 255.255.255.255.67
Chez Orange, ce souci ne pose pas de problème, le DHCP nous répondra quand même.
-
Selon une IA, ce problème proviendrait de Docker en mode pont et de la combinaison choisie. Elle recommande de se passer de Docker pour le DHCP ou de configurer
Docker avec Macvlan/Ipvlan. À vérifier, je ne suis pas compétent dans le domaine.
Tu cumules :
- virtualisation réseau (Proxmox)
- virtualisation OS (VM)
- virtualisation réseau Docker
👉 Donc :
chaque couche déforme un peu plus le paquet DHCP
Et à la fin :
- paquet mal formé
- ou réponse jamais reçue
On remarque que cette configuration est bien plus complexe que celle annoncée (figurant) dans le dépôt GitHub du projet.
Le responsable du projet nftables n'a pas non plus réussi à reproduire un bogue potentiel qui serait lié à la virtualisation (testé avec QEMU).
L'IA indique également que Docker gère du réseau, mais n’est pas conçu pour remplacer un routeur (mauvaise isolation).
-
L'IA indique également que Docker gère du réseau, mais n’est pas conçu pour remplacer un routeur (mauvaise isolation).
c'est pas tellement l'isolation Faut juste que ce soit pas ton accès internet "principal"
Parce que mettre un routeur et serveur DHCP profondément enfoui au sein d'un réseau local, dans une VM, pour jouer un rôle "top" sommet/centre de l'architecture tu te retrouves avec un problème d'oeuf et de poule et rendre plus compliquer l'administration de ton LAN avec des confs statiques de partout. Après tu peux faire des choses rigolote : 2 acces dans des VM et tu peux deplacer tes VM sur un autre site distant pour assurer l'internet de ta boite
Le corollaire c'est que si tu peux mettre une box dans un docker/VM l'opérateur aussi. Et toi t'as juste un convertisseur media fibre RJ45 pour ton switch ou la fibre dans un SFP+ de ton switch et une saleté qui fait du wifi. Donc plus de livebox qui crame à remplacer. Plus de millions de matos en compta ou de cartons sur un trottoir de saint genis de pouilly. Plus de produits différents au catalogue. Plus de trucs rigolos pour les pros et de pra/pca des acces internet via d'autres établissements de la boite etc.
-
Selon une IA, ce problème proviendrait de Docker en mode pont et de la combinaison choisie. Elle recommande de se passer de Docker pour le DHCP ou de configurer
Docker avec Macvlan/Ipvlan. À vérifier, je ne suis pas compétent dans le domaine.
On remarque que cette configuration est bien plus complexe que celle annoncée (figurant) dans le dépôt GitHub du projet.
Le responsable du projet nftables n'a pas non plus réussi à reproduire un bogue potentiel qui serait lié à la virtualisation (testé avec QEMU).
L'IA indique également que Docker gère du réseau, mais n’est pas conçu pour remplacer un routeur (mauvaise isolation).
Comme indiqué, ce souci intervient uniquement quand les drivers de la carte sont en VirtIO ou bcmgenet (Raspberry donc sans virtu ::)). Une fois les NIC passés en émulation E1000 ou Realtek, plus aucun souci.
La version Bouygues du projet embarque un correctif en phase de test qui semble corriger ce souci (VM comme Bare metal tant que Debian 13 boot ça juste marche).
Le patch sera sûrement porté sur cette version même si cela ne semble pas bloquant chez Orange ??? (Dans le doute... autant le faire)
c'est pas tellement l'isolation Faut juste que ce soit pas ton accès internet "principal"
Parce que mettre un routeur et serveur DHCP profondément enfoui au sein d'un réseau local, dans une VM, pour jouer un rôle "top" sommet/centre de l'architecture tu te retrouves avec un problème d'oeuf et de poule et rendre plus compliquer l'administration de ton LAN avec des confs statiques de partout. Après tu peux faire des choses rigolote : 2 acces dans des VM et tu peux deplacer tes VM sur un autre site distant pour assurer l'internet de ta boite
Dans des labs où la majorité de l'infra est virtualisée, cela reste à débattre ;D Mes deux fibres arrivent directement au cul du serveur pour finir dans leur VM respective, chacune isolée dans un bridge avec un port en slave pour leur WAN et le LAN dans le bridge de mon réseau local.
-
Dans des labs où la majorité de l'infra est virtualisée, cela reste à débattre ;D Mes deux fibres arrivent directement au cul du serveur pour finir dans leur VM respective, chacune isolée dans un bridge avec un port en slave pour leur WAN et le LAN dans le bridge de mon réseau local.
ouai mais les labs c'est pas de la prod :p t'as pas de SLA à racker quand ca se vautre, ni de mec d'astreinte...
apres sur un PC la fibre au popotin au moins tu partages le rien fouttage du CPU avec une autre VM
-
Dans des labs où la majorité de l'infra est virtualisée, cela reste à débattre ;D Mes deux fibres arrivent directement au cul du serveur pour finir dans leur VM respective, chacune isolée dans un bridge avec un port en slave pour leur WAN et le LAN dans le bridge de mon réseau local.
Si tu es le seul utilisateur, je suppose que c'est OK. Sinon, avoir les deux VM sur le même hyperviseur peut ou pas être problématique en cas de panne/redémarrage/mise à jour dudit hyperviseur.
Ca dépend de ce qu'il y a derrière. Dans mon dernier job d'employé, je gérais le réseau à mes heures perdues. 2 fibres, 2 routeurs OPNSense en failover sur deux alimentations redondées, pour être tranquille quand on a besoin de bosser sur l'infra et ne pas devoir rester à 11h le soir au bureau avant de tenter d'appliquer une mise à jour... sinon, tu peux être sur qu'en moins de 3 min, quelqu'un était sur ton dos parce "qu'il y a plus internet".
Depuis, je bosse seul, mes besoins sont bien plus souples. Un seul routeur openwrt derriere une fibre unique, et je m'arrange si jamais il y a un souci.
-
Si tu es le seul utilisateur, je suppose que c'est OK. Sinon, avoir les deux VM sur le même hyperviseur peut ou pas être problématique en cas de panne/redémarrage/mise à jour dudit hyperviseur.
Ca dépend de ce qu'il y a derrière. Dans mon dernier job d'employé, je gérais le réseau à mes heures perdues. 2 fibres, 2 routeurs OPNSense en failover sur deux alimentations redondées, pour être tranquille quand on a besoin de bosser sur l'infra et ne pas devoir rester à 11h le soir au bureau avant de tenter d'appliquer une mise à jour... sinon, tu peux être sur qu'en moins de 3 min, quelqu'un était sur ton dos parce "qu'il y a plus internet".
Depuis, je bosse seul, mes besoins sont bien plus souples. Un seul routeur openwrt derriere une fibre unique, et je m'arrange si jamais il y a un souci.
ouai mais les labs c'est pas de la prod :p t'as pas de SLA à racker quand ca se vautre, ni de mec d'astreinte...
L'hyperviseur est un Proxmox, et toute la maison profite de cette installation (parents, frère et même les chats 8)) sans réel souci. Je ne comprends pas cette pulsion maladive de transposer des besoins d'entreprise dans vos foyers, hahaha ;D.
À moins qu'un classico Paris-Marseille ne demande un SLA de 99,99 % :o ?
Le sujet de base du post, c’est le projet, pas de savoir si mon infrastructure répond à vos standards personnels :'(
-
@TheHecatell
Le projet est présenté avec beaucoup de zèle sans contours définis. Or, plusieurs aspects importants sont éludés.
De quel correctif s'agit-il ? De quel rapport de bogue s'agit-il ? Transformer un hôte en Livebox avec Docker ?
-
Je ne comprends pas cette pulsion maladive de transposer des besoins d'entreprise dans vos foyers, hahaha ;D.
... mon post conclut justement sur le fait que différentes solutions conviennent à différentes situations ? Je ne l'ai pas explicitement écrit, j'aurai peut être dû.
-
... mon post conclut justement sur le fait que différentes solutions conviennent à différentes situations ? Je ne l'ai pas explicitement écrit, j'aurai peut être dû.
Ce projet c'est de l'enfumage.
Ce que décrit ce projet est techniquement crédible… mais avec des limites importantes.
En gros : ce n’est pas “émuler une Livebox”, c’est reproduire juste assez du comportement pour passer l’accès Internet.
Ce que ce projet est vraiment
un client WAN Orange minimaliste + un peu de routage.
1. Docker n’est pas au bon niveau système
Créer une interface VLAN + gérer DHCP bas niveau implique :
accès direct aux interfaces réseau
privilèges élevés (--privileged, NET_ADMIN)
dépendance forte au noyau Linux
👉 En pratique, ton conteneur devient presque… une VM déguisée.
[...]
3. Pas de gestion complète du réseau
Même si ça marche :
- pas de Wi-Fi intégré
- pas de gestion TV Orange (multicast, VLAN spécifiques)
- VoIP très compliquée voire impossible
- debugging pénible en cas de coupure
4. Stabilité et maintenance
[...]
Ton conteneur :
- peut casser après une mise à jour Docker/Linux
- demande maintenance manuelle
- aucun support (et ajout de correctifs hétéroclites (https://github.com/TheHecateII/docker-bbox))
🎯 Verdict honnête
Techniquement possible → ✅ oui
Stable sur le long terme → ⚠️ incertain
Remplacement propre d’une Livebox → ❌ non
Solution de bidouille avancée / homelab → ✅ parfait
-
On fait confiance à ChatGPT de nos jours pour évaluer la qualité/fonctionnalité d'un projet?
Je demande, je suis un vieux schnock. Je sais que dans le domaine dans lequel je bosse, tous les modèles que j'ai pu tester ne servent qu'à me faire perdre du temps (comprendre: sont bien présentés et convaincants, mais entre beaucoup et entièrement faux).
-
@simon :
Non, pas entièrement. Je me fie à une intuition en me basant sur des constats. Je n'ai pas les compétences mais je perçois l'écart avec ce qui est avancé.
Et visiblement cela percute dans mon esprit (ou pas toujours dans celui des autres). Il ne suffit pas de dire mais de démontrer. Rien n'a été démontré.
-
C'est un peu agaçant de lire ce genre de commentaires dénigrants où l'argumentation (quand il y en a) n'est qu'une sortie d'une IA et en plus à côté de la plaque.
Il s'agit uniquement pour le moment d'une idée un peu loufoque de remplacer [une] Livebox par un conteneur Docker.
Si la page d'accueil mentionne effectivement transforms your host into an Orange Livebox, ce n'est évidemment pas de faire une émulation complète du firmware de Livebox dans un container Docker mais plutôt de retrouver au moins les fonctions basique qu'apporte
Les auteurs ont proposé ce projet (au stade évident d'ébauche pour le moment) réalisé de manière bénévole et présentant leurs expérimentations et pourquoi pas aller plus loin. Jamais ils n'ont présenté cela comme étant une solution professionelle pour remplacer une Livebox (sans doute une hallucination de l'IA ?).
Je trouve justement la démarche des auteurs positive et de bonne volonté, et permet d'ajouter une pierre à la communauté.
Aucune solution pour remplacer une Livebox/etc par un autre routeur sur une offre grand public n'est une solution pro et la méthode d'accès au réseau peut changer sans prévenir, typiquement la conformité protocolaire DHCP chez Orange depuis 2023, avec des adaptation à faire partout.
S'il y a des lacunes dans les compétences de certains, ce n'est certainement pas une IA qu'il faut consulter, il faut aller lire les docs et expérimenter.
Il ne suffit pas de dire mais de démontrer. Rien n'a été démontré.
Je ne pense pas que les auteurs vous doivent quoi que ce soit, par contre le projet est open source et ouvert donc si le sujet vous intéresse, n'hésitez pas à faire des contributions positives afin qu'il aille de l'avant.
-
@thibthib :
Certes, ce sont des commentaires critiques. Ils sont portés par un mélange d'ambition et d'exigence associé à de la curiosité.
Ils me servent à jauger le niveau de crédibilité, entrevoir des perspectives et éventuellement à me remettre en question
(découvrir de nouvelles approches). En général, je suis frappé par la rigueur et en même temps par un manque de clarté.
Des lacunes j'en ai énormément dans ce domaine (et en général), mais on retrouve aussi des dissonances.
Je trouve justement la démarche des auteurs positive et de bonne volonté, et permet d'ajouter une pierre à la communauté.
Aucune solution pour remplacer une Livebox/etc par un autre routeur sur une offre grand public n'est une solution pro et la méthode d'accès au réseau peut changer sans prévenir, typiquement la conformité protocolaire DHCP chez Orange depuis 2023, avec des adaptation à faire partout.
Toutes les solutions ne sont pas bonnes et ne se valent pas.
Il s'agit uniquement pour le moment d'une idée un peu loufoque de remplacer [une] Livebox par un conteneur Docker.
C'est une remarque impertinente. La page du projet (https://github.com/TheHecateII/docker-bbox) adopte un style injonctif, caractérisé par des énoncés déclaratifs et l’absence notable de conditionnel.
En bref, je ne crache pas dans la soupe. De loin cela ressemble à de la bouillie.
-
@thibthib :
Concernant l'IA, il faut être réaliste. Elle permet des avancées majeures dans des domaines de pointe.
-
Concernant l'IA, il faut être réaliste. Elle permet des avancées majeures dans des domaines de pointe.
Dans le cas présent, elle semble te conforter dans le jugement initial que tu portes sur le projet. Je ne suis pas sûr qu'elle te rende service ou qu'elle apporte la moindre avancée dans cette discussion, mais je n'ai personnellement pas de billes dans ce thread.
Rappelons que ce qu'on appelle des IA génératives, ce sont grosso modo des perroquets probabilistes glorifiés. Je ne dis pas que ca n'a pas sa place ou son utilité... mais selon moi, si on veut s'en servir, il faut savoir que la substance a tendance à pêcher (la proba que la sortie soit correcte est assez faible, surtout sur de sujets peu courants) et que la forme est excellente (ca fait des jolies phrases, tables et graphes, et c'est *très* convaincant).
-
@simon :
Je converge avec les réponses ayant été généré par l'IA, mais avec un côté sceptique. Cela me semble correct.
Ce projet crée seulement un accès Internet basique, moins avancé que d'autres. Il est imprécis. Certains choix
posent clairement questions : Docker + Proxmox (non mentionné sur GitHub), eBPF (pour corriger un bogue
hypothétique dans le noyau / nftables ?), nftables et iptables, ISC DHCP (https://www.isc.org/dhcp/)... Cela commence à faire beaucoup à
avaler. Il y a toute une partie que je ne maîtrise pas mais c'est troublant et décevant. Et pour finir, c'est une
substitution sauf que cela n'a strictement rien avoir avec une Livebox.
J'attends les réponses aux questions que j'ai posé pour tenter d'y voir plus clair (ci-dessous).
@TheHecatell
Le projet est présenté avec beaucoup de zèle sans contour défini. Or, plusieurs aspects importants sont éludés.
De quel correctif s'agit-il ? De quel rapport de bogue s'agit-il ? Transformer un hôte en Livebox avec Docker ?
Je ne suis pas persuadé que qualifier l'IA de perroquet probabiliste (https://www.france24.com/fr/info-en-continu/20260330-un-homme-sa-chienne-et-chatgpt-la-saga-du-vaccin-ia-en-australie) soit vraiment avisé notamment au regard
des enjeux. Même les experts ne comprennent pas le fonctionnement interne des IA.
-
@basilix Tes remarques relèvent purement et simplement d'un manque de respect.
J'ai consenti à garder mon calme en mettant la faute sur de potentielles tournures de phrases qui n'étaient pas précises.
Tu pollues ce sujet avec des torchons générés par IA sans même comprendre ce qu'elle te raconte. Je te demanderai donc de ne plus poster de messages sur ce thread, à défaut de demander à un membre du staff d'intervenir dans le cadre ou tu continurais.
Tu sembles ne pas avoir compris que cet applicatif peut s'exécuter sur tout... machine physique comme virtuelle (Même le respirateur de mon papy, fantastique non ?).
Nous balancer des pavés générés par un LLM dans le seul but de faire du "rage-bait" est inutile, et je vois que tu commences à agacer les personnes qui souhaitent simplement suivre l'évolution du projet...
-
Ah oui effectivement c'est affligeant, basilix va aller faire un tour dehors quelques jours pour réfléchir à ses contributions.
-
cool, ;)
Moi je trouve ce sujet fort intéressant, par contre juste une remarque comment gérez vous la sécurité?
pour ce que je comprend, vous êtes en frontale sur internet, sans le pare feu de la livebox, (même si je ne sais pas ce qu'il fait).
Car quand je vois le nombre de bots qui scannent tous les ports en permanence et qui lancent un brute force sur la moindre faille.
pour exemple, sur mon mikrotik, j'ai un wan-drop toutes les 3, 4s et 4 ou 5 ip au purgatoire en permanence pour 15 jours, en moyenne.
Après ça vaut pour toutes les solutions de remplacement de la livebox. Mais l'os d'un routeur est fait pour.
Bon courage ;)
-
@orefie, tu as des millions de serveurs accessibles avec une IP publique qui tournent sous debian de part le monde, comme ton routeur sait drop les paquets qui ne l'interesse pas, c'est pareil pour les serveurs sous debian ;)
Que ton serveur débian ait un site internet ou "remplace" une livebox c'est kif kif ;) Il se protège de la même maniere.
-
C'est pas trop Debian qui m'a fait poser cette question, c'est plus la boite noire Docker. :-X
-
Docker n'est plus qu'une surcouche de containerd qui est open source, donc un audit du code est possible.
-
je vais essayer de développer un peu ma question et mes interrogations.
Donc ok,
l’hôte peut être sécurisé.
Docker est open source donc auditable.
On met un docker en place par exemple sur un debian.
Debian est sécurisé, on installe le docker dessus avec des privilèges comme c'est le cas dans ce post.
Nous sommes d'accord que le docker partage de le même noyau que l’hôte.
Et on expose tout ça à internet direct par l'ont.
Je ne vois pas comment ça peut être sécure, la moindre faille et on prend la main sur l’hôte.
Je suis sur que les auteurs y ont déjà pensé d’où ma question. ;)
-
Bah comme tout routeur sous Linux en fait (donc 90% des routeurs GP et semipro). S'il y a une faille noyau exploitable en remote, docker ou pas la faille est là.
-
Non, quand je parle de faille, c'est au sens général, pas du noyau.
Un OS de routeur à une politique du "tout fermé", la c'est plutôt "tout ouvert"
La moindre erreur de configuration et c'est open bar.
Aussi bien sur l’hôte que sur le docker, vu qu'ils sont imbriqués, qu'il n'y a pas d'isolation et que docker à des privilèges .
Et niveau configuration cette option doit être plutôt complexe car il faut penser à toutes les éventualités.
-
On peut tout à fait faire faire un refus implicite à iptables et à nftables. À moins que ça n'ait changé et sur les distributions que je connais, la stratégie de base des chaînes INPUT et FORWARD est sur ACCEPT. Et en effet, je trouverais pertinent de la mettre sur DROP pour imiter une box opérateur, pour ne garder autorisées que les connexions établies ou liées. Ainsi, plus de problèmes de vulnérabilité de noyau en tapant directement sur le routeur. Il peut toujours y avoir une exploitation depuis une machine du LAN ou un moyen détourné mais ça réduit déjà la surface d'attaque.
nftables remplaçant iptables, ça pourrait être une amélioration de n'utiliser que le premier à l'avenir.
-
[...]
pour ce que je comprend, vous êtes en frontale sur internet, sans le pare feu de la livebox, (même si je ne sais pas ce qu'il fait).
[...]
En fait ça change rien. Une livebox a deux fonctions majeures :
1 - router les paquets de ta famille vers Internet et le trafic réciproque (le camionneur)
2 - filtrer et lessiver les paquets entrants et sortant (la concierge)
3 - des bricoles comme la téloche et le téléphone. On en parlera pas c'est juste des applications au dessus des 2 autres fonctions primaires.
Le docker proposé réalise les même fonctions principales.
Que ce soit une livebox ou un docker : y a un système d'exploitation pour lancer les applications de routage ou de lessivage. De base un Unix c'est une brique. Tu peux le mettre dans l'acideˆw sur Internet il ne se passe rien. Faut des drivers, ouvrir des choses, écouter sur une carte réseau, monter les paquets dans la pile IP, laver les paquets dans la lessiveuse, you put it in the water, you wash it you wash it, you rince, Hm it smells like a flower YOU PUT IT in the water si ça smell pas bon pour le noyer pour de bon.
Et corollaire : on peut parfaitement remplacer la livebox par n'importe quel bousin qui fait la même chose et parle de façon compréhensible à Orange et Internet.
Non, quand je parle de faille, c'est au sens général, pas du noyau.
Un OS de routeur à une politique du "tout fermé", la c'est plutôt "tout ouvert"
[...]
L'OS a zéro politique c'est la pile IP -augmentée- d'une application de lavage de paquet qui le permet (nftable, ipfw, pf...). Par defaut la pile IP y a rien qui écoute sur le port bah c'est une brique elle répond sauf contre ordre un ICMP port unreach.
Après pour aller dans le docker faut quand même traverser l'OS + les drivers et la pile IP de l'hôte et oui si y a une vulnérabilité bah bobo au popotin. Juste que ça sera un vlan ou une interface réseau dédiée qui rentrera dans le docker. Oui l'hôte a son propre firewall/filtrage aussi. Et c'est des portions de code tellement utilisée et déboqguée... qu 'on est plus à l'âge de faire tomber des ciscos avec un ping de la mort.
On sait deja que la livebox embarque des gros morceaux de Linux, comme d'autres box de FAI. On a vu au début du conflit en Ukraine une attaque qui a briqué des box satellites. Effectivement tout reste possible en terme de sécu.
-
Bonsoir ;D
Effectivement, comme l'indique @Fyr, par défaut un port sans écoute derrière est droppé, donc pas trop trop de souci à ce niveau.
Pour ce qui est de la sécurité, c'est à l'utilisateur de faire le nécessaire (De la même manière que l'on configure un VPS finalement ;D)
Par défaut, on voulait une version Linux pour pouvoir tout custom nous-mêmes et développer nos propres solutions, puis on a dérapé sur Docker.
Là où une solution type PfSense/OPNsense vient packagée avec un Web GUI, ici la philosophie c'est vraiment "Less is more".
En revanche, si vous avez des idées de solutions à intégrer, on est preneurs ^^ Perso j'essaye d'intégrer la TV out-of-box car ça fonctionne en réalité faut juste automatiser le setup d'IGMP Proxy (Pas comme certain l'ont avancer ::))
@Orefie
Je suis sur que les auteurs y ont déjà pensé d’où ma question. ;)
Effectivement on y a penser ;D On hésite à push automatiquement un fail2ban ect... quand tu lance le container
Retenez bien un truc, Docker sert juste à executer comme un bon esclave toutes les commande ip/nftables, Il n'y a que le DHCP qui est instancier dans le container le reste c'est propre à l'hôte.
(En gros, ça vous permet de ne pas avoir à compiler/install 1 par 1 les différents packages nécessaires, si vous voulez cloner les scripts et lancer le .sh maître ça marchera pareil hahaha)
-
Merci pour toutes vos réponses, en tout cas bravo pour le concept.
Affaire à suivre. ;)