Bombini et Oburix : deux petits outils eBPF qui méritent une évaluation en laboratoire

Deux petits projets open source offrent aux MSP un moyen économique d'ajouter une visibilité au niveau du noyau sur les parcs Linux : Bombini, un agent de surveillance basé sur eBPF écrit en Rust avec la bibliothèque Aya, et Oburix, un outil de détection de terminaux eBPF plus léger avec des règles définies en YAML. Ni l'un ni l'autre ne remplace directement un EDR commercial, mais tous deux méritent une évaluation en laboratoire.

Ce que chacun fait

Bombini s'attache aux points d'ancrage du Linux Security Module (LSM) et transforme les événements du noyau — exécution de processus, opérations sur les fichiers, connexions réseau, tentatives d'élévation de privilèges — en sortie JSON structurée qu'un SIEM ou un pipeline de journaux peut consommer. Il est entièrement écrit en Rust, sans dépendance à libbpf ni à bcc, et utilise BTF/CO-RE pour la portabilité entre les versions du noyau, même si certains points d'ancrage LSM doivent être explicitement activés au démarrage. Oburix adopte une approche plus légère : il surveille l'exécution des processus, les connexions réseau et l'activité du système de fichiers, puis compare cette télémétrie à des règles de détection écrites en YAML, avec pour objectif une empreinte à faible surcharge adaptée à une intégration SIEM ou XDR.

Comment les évaluer en toute sécurité

• Épinglez et testez la compatibilité du noyau avant tout déploiement plus large — l'outillage eBPF est sensible à la version et à la configuration du noyau.
• Exécutez d'abord dans un environnement de laboratoire, pas sur des hôtes de production.
• Reliez les détections de chaque outil à votre pipeline SIEM ou d'alerte existant plutôt que de l'utiliser comme console autonome.
• Documentez un chemin de retour en arrière au cas où l'agent lui-même causerait des problèmes de performance ou de stabilité.

Les deux projets sont modestes selon les standards de GitHub — un nombre d'étoiles et de contributeurs réduit par rapport à des outils établis comme Falco ou Tracee — ce qu'il convient de prendre en compte dans toute décision de déploiement : des projets plus petits signifient une itération plus rapide, mais aussi moins de tests éprouvés à grande échelle. La conclusion pratique est de traiter l'un ou l'autre comme une source de télémétrie défensive à expérimenter aux côtés de l'outillage existant, et non comme un produit de sécurité certifié à activer sur l'ensemble d'un parc.

Sources : GitHub — bombinisecurity/bombini, GitHub — Oburix.