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
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.