EBPF pour observer et bloquer dans le noyau Linux

Extended Berkeley Packet Filter (eBPF) permet de charger des programmes contrôlés dans le noyau Linux afin d’observer des événements ou de décider du sort d’un paquet, d’un processus ou d’une opération sensible. Le gain est une visibilité et une capacité de blocage très proches de l’exécution réelle, le prix est une extension de la surface d’attaque du noyau et une dépendance forte à sa version.

→ Lire l’explication complète de la marmotte

Le compromis eBPF : visibilité profonde contre privilèges noyau

eBPF n’est pas un outil d’observabilité parmi d’autres. C’est un mécanisme d’exécution dans le noyau, encadré par un vérificateur qui analyse le programme avant chargement. Ce vérificateur impose des accès mémoire bornés, interdit les boucles non prouvées terminantes sur les noyaux anciens et contrôle les appels aux fonctions auxiliaires autorisées. Il réduit le risque, il ne transforme pas le noyau en zone sans danger. Une vulnérabilité dans le vérificateur ou le compilateur juste-à-temps reste une vulnérabilité noyau.

Le compromis central est net : rapprocher la collecte et la décision de l’événement réduit les angles morts, mais donner le droit de charger des programmes eBPF revient à donner une capacité d’influence sur le noyau. Pour l’observabilité de production, eBPF est recommandé lorsque les journaux applicatifs ne permettent pas d’expliquer une latence, un refus réseau ou une ouverture de fichier. Pour l’enforcement, le recours doit rester limité à des règles stables, déterministes et testées hors production. Une politique de sécurité mouvante chargée à chaud dans le noyau est une très mauvaise idée, même si le tableau de bord a des dégradés de violet.

Le noyau Linux 5.15 LTS constitue un minimum raisonnable pour une base durable. Linux 6.1 LTS ou plus récent est préférable pour bénéficier d’améliorations de vérification, d’attache et de portabilité. La présence de BTF (BPF Type Format), métadonnées de types exposées par le noyau, est requise pour exploiter correctement CO-RE (Compile Once, Run Everywhere). CO-RE réduit la dépendance aux décalages de structures internes entre versions de noyau, mais ne garantit pas qu’un point d’attache, un champ ou une fonction existent partout.

Un hôte doit aussi disposer du système de fichiers BPF monté sur /sys/fs/bpf, des en-têtes correspondant au noyau cible pour certains modes de compilation, de clang et de libbpf pour construire et charger les programmes. Le chargement doit être réservé à un service dédié, avec des droits minimaux. Accorder indistinctement les capacités CAP_BPF, CAP_PERFMON ou CAP_SYS_ADMIN à un agent d’observabilité annule une partie du bénéfice. CAP_SYS_ADMIN est le couteau suisse des permissions Linux : quand il apparaît dans une procédure, il faut supposer que le tiroir contient aussi une tronçonneuse.

Points d’attache eBPF : trace, réseau et contrôle d’accès

Les tracepoints sont le choix par défaut pour l’observabilité. Ils exposent des événements stables, tels qu’une création de processus, une ouverture de fichier ou une transition réseau. Leur contrat est plus robuste que les sondes sur fonctions internes, souvent appelées kprobes. Une kprobe dépend d’un symbole noyau, de son existence et parfois de son comportement interne. Elle convient au diagnostic ciblé, pas à une instrumentation d’architecture censée survivre aux mises à jour.

Les fentry et fexit s’attachent à l’entrée ou à la sortie de fonctions noyau grâce à BTF. Elles imposent moins de surcoût que certaines kprobes et donnent accès aux arguments typés. Elles restent liées à des fonctions internes. Pour une métrique durable, préférer un tracepoint. Pour comprendre un comportement du noyau pendant un incident, fentry et fexit sont souvent le meilleur scalpel.

Sur le chemin réseau, XDP (eXpress Data Path) s’exécute très tôt à la réception des paquets, avant une grande partie de la pile réseau. Il convient au filtrage volumique, à la limitation de trafic et à la redirection. Il ne convient pas à une politique qui exige une vision complète de la connexion, des réassemblages ou du contexte applicatif. Bloquer sur XDP une requête qui nécessite l’état HTTP revient à lire un roman à partir de la première lettre. Pour cela, utiliser plutôt TC (Traffic Control), les cgroups, ou une passerelle applicative selon le niveau de décision.

Les programmes attachés aux cgroups permettent de contrôler les connexions entrantes ou sortantes d’un groupe de processus. Cette granularité est adaptée aux charges conteneurisées, à condition que la hiérarchie des cgroups soit gouvernée et que les identités de charge soient fiables. Dans un orchestrateur, une politique fondée sur un chemin de cgroup éphémère doit être réconciliée à chaque recréation de charge. Le sujet rejoint directement la segmentation décrite dans les fondations réseau et les contraintes de cycle de vie des plateformes conteneurisées.

LSM (Linux Security Modules) eBPF permet d’attacher des décisions aux contrôles de sécurité du noyau, notamment sur les fichiers, processus et opérations réseau. C’est le mécanisme à retenir pour un enforcement local fin, mais seulement après avoir défini la relation avec SELinux ou AppArmor. Deux moteurs qui refusent des accès sans journal corrélé produisent un audit où chaque équipe accuse le gremlin du voisin. La règle doit préciser quel mécanisme est autoritaire, quel mécanisme journalise et comment un refus est attribué.

Exemple eBPF : tracer les exécutions de processus

Le programme suivant utilise bpftrace, un outil de traçage eBPF, pour afficher les exécutions de processus via le tracepoint sched_process_exec. Il nécessite un noyau avec eBPF activé, un utilisateur disposant des privilèges de traçage et l’installation du paquet bpftrace.

# Afficher le processus qui vient d'exécuter un nouveau binaire.
# Le tracepoint est préféré à une sonde sur une fonction interne du noyau.
sudo bpftrace -e '
tracepoint:sched:sched_process_exec
{
  printf("pid=%d parent=%d commande=%s\n", pid, curtask->real_parent->tgid, comm);
}'

Cette commande ne constitue pas une journalisation d’audit complète. Le champ comm est tronqué par le noyau et ne fournit ni les arguments complets ni l’identité métier de la charge. Pour une investigation, corréler le PID (Process Identifier), l’horodatage, l’espace de noms et les événements d’audit Linux. Pour un contrôle de sécurité, ne jamais déduire une autorisation depuis le seul nom du processus : un binaire peut modifier son nom, être remplacé ou être invoqué par un interpréteur.

Le chargement de programmes doit passer par une chaîne de construction reproductible. Compiler le code eBPF, produire l’objet, vérifier les sections attendues, signer l’artefact de distribution et conserver son empreinte. Le noyau vérifie la sûreté structurelle du programme, pas son intention. Un programme valide qui bloque les résolveurs DNS reste valide, puis très bruyant à trois heures du matin.

Surface d’attaque eBPF et contre-mesures

Le premier risque est le chargement non autorisé. Désactiver les programmes eBPF non privilégiés via kernel.unprivileged_bpf_disabled=1, sauf besoin démontré et isolé. Restreindre l’accès au système de fichiers BPF, car les objets épinglés peuvent être réutilisés par d’autres processus selon leurs permissions. Un répertoire global inscriptible dans /sys/fs/bpf devient un point de passage entre composants supposés séparés.

Le deuxième risque concerne le compilateur juste-à-temps, ou JIT (Just-In-Time). Le JIT transforme le bytecode eBPF en instructions machine pour réduire le coût d’exécution. Il améliore les performances, mais les défauts du vérificateur et du JIT ont déjà permis des élévations de privilèges. Garder le noyau à jour, suivre les avis de sécurité de la distribution et désactiver le JIT lorsque la politique de performance le permet sur des hôtes exposés réduisent le risque. Désactiver le JIT peut rendre certains usages coûteux, pas impossibles.

Le troisième risque est l’exfiltration par l’observabilité. Un programme eBPF peut lire des métadonnées de processus, des chemins, des adresses réseau et parfois des données applicatives selon son point d’attache. Les événements transmis vers l’espace utilisateur doivent être minimisés, filtrés et protégés comme des journaux sensibles. Capturer des en-têtes d’autorisation ou des requêtes complètes au nom du diagnostic ne crée pas de visibilité : cela crée une fuite de secrets avec une interface graphique.

eBPF ne garantit pas l’intégrité du noyau après compromission privilégiée, l’authenticité d’une identité applicative, la confidentialité des données collectées, ni la sécurité d’un service accessible publiquement. Ces propriétés doivent venir du démarrage vérifié, du contrôle d’accès, de la gestion des secrets et de la segmentation. Les mécanismes d’identité restent traités dans les architectures IAM, pas dans une carte eBPF posée sur une slide.

Exploitation eBPF : rotation, supervision et reprise

Un programme eBPF chargé est un artefact exécutable. Il doit donc avoir un propriétaire, une version, une empreinte, une date d’expiration de compatibilité et une procédure de retrait. Épingler un programme ou une map eBPF dans le système de fichiers BPF permet sa persistance au-delà du processus chargeur, mais crée une dette d’exploitation : après un redémarrage incomplet, des objets épinglés peuvent survivre à l’agent qui les gérait.

Les maps eBPF stockent l’état partagé entre noyau et espace utilisateur : compteurs, tables de règles, identifiants autorisés ou statistiques. Une map n’est pas une base de données transactionnelle. Une mise à jour de politique doit être atomique quand le type de map le permet, sinon utiliser une map de remplacement et basculer la référence du programme. Modifier entrée par entrée une liste de blocage active produit des fenêtres de décision incohérentes.

Superviser au minimum le nombre de programmes chargés, les erreurs du vérificateur, les pertes d’événements, la saturation des ring buffers et la durée d’exécution. Un ring buffer est une zone mémoire utilisée pour transférer des événements vers un processus utilisateur. Une perte d’événement doit être une métrique d’alerte, pas une note de bas de page dans une console. Si la télémétrie perd des événements sous charge, elle doit annoncer son taux de perte et refuser toute prétention d’exhaustivité.

La reprise exige un inventaire déclaratif des programmes, maps et points d’attache. Après redémarrage, recharger depuis des artefacts signés et reconstruire l’état depuis une source de vérité externe. Ne pas sauvegarder aveuglément une map contenant des décisions temporaires ou des identifiants de connexion. Restaurer une autorisation périmée est une panne de sécurité, pas une restauration réussie.

🐝 Ce qui arrive si on s’en passe

Sans instrumentation dans le noyau, la visibilité se limite à ce que les applications acceptent de déclarer et à ce qu’un échantillonnage périodique capture : un processus vivant quelques centaines de millisecondes entre deux relevés ne laisse aucune trace exploitable. Les flux réseau observés en bordure restent alors non attribuables à un processus, un conteneur ou un espace de noms, ce qui interdit de distinguer une connexion sortante légitime d’une exfiltration lancée depuis la même machine. Les agents placés en espace utilisateur ou les interpositions de bibliothèques peuvent être contournés par un binaire statique ou arrêtés par un compte privilégié, sans que la collecte signale son propre silence. Faute de point de décision proche de l’événement, le blocage dépend de la coopération de l’application surveillée, et la reconstruction d’incident se réduit à des horodatages trop grossiers pour ordonner les causes.

🦫 Explication de la marmotte 🍫

eBPF est une fonction de Linux qui permet d’ajouter de petits programmes dans le noyau, la partie du système qui gère directement les processus, les fichiers et le réseau. Avant d’accepter un programme, Linux examine son code. Il vérifie notamment que le programme ne lit pas n’importe quelle zone mémoire et qu’il ne peut pas tourner sans fin. Si cette vérification échoue, le programme est refusé.

Une fois accepté, le programme est relié à un événement précis. Il peut recevoir une information lorsqu’un logiciel démarre, lorsqu’un fichier est ouvert ou lorsqu’un paquet réseau arrive. Selon l’endroit choisi, il peut seulement enregistrer ce qui se passe, ou autoriser, modifier ou refuser une action. Les informations récoltées sont ensuite envoyées à un logiciel normal, hors du noyau, pour être affichées ou conservées.

Cette puissance demande des droits élevés. Une personne ou un logiciel capable de charger ces programmes peut influencer le comportement du système. Il faut donc limiter cet accès, garder une liste des programmes chargés et vérifier leur provenance. Les données collectées peuvent aussi contenir des noms de fichiers, des adresses ou des secrets : elles doivent être protégées.

Si le programme est mal conçu, il peut ralentir la machine, perdre des événements ou bloquer une activité légitime. Si le noyau contient un défaut, eBPF ne le corrige pas. Il faut maintenir Linux à jour, surveiller les erreurs et pouvoir retirer rapidement une règle qui empêche le système de fonctionner.

Pages voisines

La citent

EBPF pour observer et bloquer dans le noyau Linux

Elle cite

EBPF pour observer et bloquer dans le noyau Linux

EBPF pour observer et bloquer dans le noyau Linux

Le compromis eBPF : visibilité profonde contre privilèges noyau

Points d’attache eBPF : trace, réseau et contrôle d’accès

Exemple eBPF : tracer les exécutions de processus

Surface d’attaque eBPF et contre-mesures

Exploitation eBPF : rotation, supervision et reprise

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines