Etat des lieux, pourquoi un nouvel outil ?
Fut un temps où je devais télécharger une à plusieurs fois par jour des sauvegardes de serveurs sur mon ordi perso.
Afin de ne pas monopoliser la bande passante familiale, il fallait prévoir dès le début de la sauvegarde de limiter la bande passante.
J'ai pris l'habitude d'utiliser Trickle et parfois directement les options adéquates de wget/curl.
Quelque soit l'option choisie, 2 situations pourtant communes n'étaient pas gérables:
- impossibilité de modifier les limites après le début de la sauvegarde
- impossibilité de mettre en place des limites sur une sauvegarde déjà en cours
J'ai donc décidé d'y remédier en développant un programme: Netbump.
Présentation
Netbump est outil de type client/serveur (restreint à l'hôte) permettant de limiter la bande passante d'un groupe de cibles (socket existante, processus existant ou à démarrer et cgroup version2).
L'utilisateur peut ajouter, supprimer, mettre à jour et lister ses règles de limitation.
netbump: le client permet de créer une requête valide à envoyer à netbumpd grâce à une socket UNIX.
netbumpd: le serveur en charge de répondre aux requêtes et de mettre en place les limitations.
Détails
Netbump est écrit en Rust (sans l'aide de l'IA).
netbumpd est un programme suid, il doit avoir les droits root.
Il comprend ses propres programmes EBPF utilisés pour traquer les changements d'état des cibles et pour marquer le trafic réseau.
C'est en majeur partie l'utilisation de EBPF qui contraint netbumpd à ne fonctionner que sous Linux.
La limitation du trafic est effectuée par le noyau Linux, netbumpd ne fait que mettre en place cette limitation tel que pourrait le faire un utilisateur à l'aide de "tc" et quelques autres commandes.
Plusieurs options de compilation sont disponibles afin de définir comment démarrer le serveur netbumpd (daemon classique, automatiquement grâce à systemd, manuellement ou à l'aide du client netbump), plusieurs façons de générer les logs.
A chaque arrêt de netbumpd, toutes les modifications apportées à l'hôte sont supprimées.
A chaque démarrage de netbumpd, il peut récupérer d'un précédent crash/kill afin de nettoyer l'hôte.
Sécurité
netbumpd a besoin des droits root durant toute sa durée d'exécution car il va attacher/détacher ses programmes EBPF en fonction du besoin.
Il a aussi besoin d'accéder à procfs et sysfs pour de la découverte de sockets/processus/membres de cgroups, et utilise plusieurs connexions netlink pour mettre en place des IFB et des règles tc.
Je suis en cours de création d'un profil apparmor bien que je ne trouve pas cette solution assez restrictive.
J'ai aussi testé Landlock, mais netbumpd a besoin de lister les inodes des processus à limiter (fichiers contenus dans /proc/{pid}/fd/) mais ce type de "fichier" n'est pas reconnu par Landlock et en restreint l'accès empêchant l'usage de Landlock.
Root peut utiliser netbump à titre perso mais surtout l'utiliser en ciblant un autre utilisateur, il n'aura donc pas besoin d'utiliser d'autres commandes que netbump afin de lister/modifier/ajouter/supprimer les règles mises en place ou de nettoyer les modifications/ajouts apportés à l'hôte par netbumpd.
Netbump: https://codeberg.org/gonbalf/netbump
# avec wget
Posté par Krunch (courriel, site web personnel) . Évalué à 3 (+2/-1).
Avec wget tu peux interrompre puis relancer avec
-cet toutes les autres options pertinentes.pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: avec wget
Posté par ChocolatineFlying . Évalué à 4 (+3/-0).
a la condition que coté serveur cela soit accepté, ne fonctionne pas toujours a 100%
[^] # Re: avec wget
Posté par Krunch (courriel, site web personnel) . Évalué à 2 (+1/-1).
Il y a quoi comme vrais exemples de services webs pour le transfert de fichiers qui ne supporte pas le service d'octet HTTP en 2026 ?
Puis même si ça ne le supporte pas, ça fonctionne. C'est juste que ça recommence de zéro.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# pf
Posté par Krunch (courriel, site web personnel) . Évalué à 3 (+1/-0).
Sous OpenBSD et tout autre OS supportant pf, on peut limiter la bande passante d'un utilisateur ou d'un hôte distant par exemple. J'imagine que cela doit aussi être possible sous Linux sans installer un nouveau truc qui pèse 30 000 lignes ?
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: pf
Posté par Fabien . Évalué à 2 (+1/-0).
On doit pouvoir aussi le faire sous Linux avec tc/nftables mais je ne me rappelle jamais la syntaxe des multiples commandes à saisir.
Je ne suis pas sûr que ce soit très user-friendly.
Netbump gère aussi l'upload, peut se restreindre à une ou plusieurs interfaces réseau, gère l'ajout et la suppression de carte réseau (telle une carte wifi qui devient active).
Le système pour grouper les cibles à limiter permet de choisir plus finement les membres.
Le fait de fonctionner en mode client/serveur permet à une application externe d'utiliser le protocole netbump pour construire des requêtes et utiliser netbumpd.
Cet outil n'a pas été conçu pour les admin-sys mais pour palier aux limitations de trickle et wondershapper.
D'ailleurs, netbump ne permet de limiter que ce qui existe sur l'hôte, tu ne peux pas limiter un hôte distant.
Je recommande d'utiliser trickle à la place de netbump si ses options ne sont pas utiles.
# questions
Posté par steph1978 . Évalué à 4 (+2/-0).
Sympa, merci pour le partage. Cet outil pourrait s'avérer utile.
Questions:
Pourquoi ? De ma compréhension, un programme suid est un programme qui peut être lancé par un utilisateur lambda avec des privilèges root. Charge à ce programme d'en faire bon usage.
Ici, on a un démon qui peut être lancé en user root par l'init.
Quant au client
netbump, il peut venir avec l'identité de l'utilisateur et le serveur déterminera s'il a le droit de passer tel ou tel ordre (= gestion des autorisations), par exemple en fonction du groupe dans lequel l'utilisateur est.J'ai l'impression que ça dit deux fois la même chose - "après le début" et "déjà en cours" ; limitation qui est par ailleurs réelle.
[^] # Re: questions
Posté par Fabien . Évalué à 3 (+2/-0).
Effectivement ce n'est pas clair.
L'option suid est liée à la façon dont on veut démarrer netbumpd.
Le choix de proposer plusieurs modes de démarrage découle d'un prérequis: netbumpd n'impose pas d'être démarré en permanence.
L'option de démarrage de netbumpd est choisie à la compilation parmi les options (exclusives) suivantes:
- systemd
- daemon
- nodaemon
option systemd
permet (à l'aide des fichiers de conf fournis dans le dépôt) de laisser systemd écouter sur la socket Unix et démarrer netbumpd lors de la première requête reçue. Il démarrera tel un daemon classique et pourra (si compilé avec l'option autoclose) s'éteindre après une période d'inactivité (plus précisément une période d'inutilité) et redonner la socket Unix à systemd afin de répéter cette boucle.
On n'a donc pas besoin de suid tant que systemd permet à netbumpd de démarrer avec les droits root.
option daemon
correspond à la méthode classique pour démarrer un serveur "autonome", on a donc besoin des droits root mais pas du suid.
option nodaemon
est celle qui peut avoir besoin du bit suid.
Dans ce mode, on peut démarrer netbumpd dans un terminal mais il faut disposer des droits root. Ce n'est pas pratique et ça va à l'encontre de se présenter comme un utilitaire pour l'utilisateur final. Je pense à une machine multi-users, à des terminaux X et certainement plein d'autres cas.
L'idée est donc de permettre (optionnellement) au client netbump, de pouvoir démarrer netbumpd, imposant le bit suid à netbumpd dans ce cas.
On pourra donc choisir de compiler netbumpd avec le suid: cargo xtask netbumpd --suid …
Ca m'a été très utile pendant le développement, me permettant de compiler et démarrer netbumpd en une seule commande tout en restant sur un compte non-root (cargo xtask netbumpd --features … --suid --run—-v)
impossibilité de modifier les limites après le début de la sauvegarde
en utilisant les outils existants, on peut démarrer la sauvegarde avec une limite en download et /ou upload, mais on ne va pas pouvoir modifier cette limite. C'est le cas courant auquel j'étais confronté:
A l'époque, je plafonnais à 1Mo/s en download, je devais donc limité à 100ko/s pour laisser de la place pour les possibles appels visio des autres utilisateurs de la ligne internet. Je voulais pouvoir modifier la limite à tout instant afin d'utiliser pleinement mon débit maximum.
Krunch a mentionné les options de wget, mais ça limite à quelques protocoles, au bon vouloir du peer et surtout il aurait fallu que je modifie un script shell …
impossibilité de mettre en place des limites sur une sauvegarde déjà en cours
c'est la situation où je lançais directement ma sauvegarde sans l'avoir limitée, j'étais en incapacité d'ajouter une limite.
On peut s'en sortir avec tc et ntfables/iptables mais ce n'est pas user-friendly.
# Avec plusieurs utilisatrices
Posté par cg . Évalué à 4 (+2/-0).
Hello,
dans la documentation, on peut lire :
Y-a-t-il un moyen de dire "Alice ne peut modifier que ses jeux de règles mais pas ceux de Bob" ?
[^] # Re: Avec plusieurs utilisatrices
Posté par Fabien . Évalué à 3 (+2/-0).
Seul root peut lister toutes les règles, il est le seul à pouvoir forcer la création (et suppression/modification) d'une rule pour un autre utilisateur.
Chaque utilisateur crée ses propres rules et ne peut limiter que ce qui lui appartient: socket, process, cgroup.
En aucun cas un autre user peut lister/modifier … les règles des autres utilisateurs.
Il existe une seule exception permettant à un utilisateur classique de limiter quelque chose qui ne lui appartient pas, due à la possibilité de limiter un processus tout en suivant ses enfants (en cours ou futur).
Voici un exemple courant sur mon setup:
- 1 konsole appartenant à mon compte normal
- 3 onglets, donc 3 shells avec les mêmes droits que konsole
pid_de_konsole et tous ses pids enfants appartiennent à la rule nouvellement créée.
Si j'avais utiliser
su -ou si je l'utilise à posteriori, l'un des shells a/aura les droits root. Il reste dans la rule et tout ce qui peut être exécuté dans ce shell sera aussi associé à la rule.La phrase citée avait juste pour intention de préciser que le client netbump ne fait que construire une requête valide à passer à netbumpd à partir des options passées en ligne de commande.
[^] # Re: Avec plusieurs utilisatrices
Posté par cg . Évalué à 2 (+0/-0).
Merci pour la clarification !
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.