eBPF (Extended Berkeley Packet Filter)

eBPF (Extended Berkeley Packet Filter) est une technologie du noyau Linux qui permet d'exécuter des programmes sandboxés directement dans l'espace kernel, sans écrire de module noyau ni recompiler le système. Initialement conçu pour filtrer les paquets réseau (le BPF « classique » de tcpdump), eBPF est devenu depuis le noyau 4.x une machine virtuelle généraliste qui alimente aujourd'hui l'observabilité, le routage réseau et la sécurité runtime des infrastructures cloud et conteneurisées.

Définition et principe

Un programme eBPF est un bytecode compilé (généralement depuis du C via LLVM/Clang, ou du Rust avec Aya) qui est chargé dans le noyau et attaché à un point d'accroche (hook) : appel système, fonction kernel, interface réseau, point de trace, socket. À chaque déclenchement du hook, le programme s'exécute et peut lire le contexte de l'événement, agréger des métriques ou prendre une décision (laisser passer, rejeter, rediriger, tuer un processus).

La spécificité d'eBPF tient à son vérificateur (verifier). Avant tout chargement, le noyau analyse statiquement le bytecode : absence de boucles non bornées, accès mémoire strictement dans les limites autorisées, terminaison garantie, nombre d'instructions plafonné. Un programme qui ne passe pas cette validation est rejeté. C'est ce qui rend eBPF acceptable en production là où un module noyau classique risquerait un kernel panic. Le bytecode validé est ensuite traduit en instructions natives par un compilateur JIT, ce qui offre des performances proches du code kernel compilé.

Fonctionnement technique

• Types de hooks : kprobe/kretprobe (fonctions internes du noyau), uprobe (fonctions en espace utilisateur, utile pour intercepter TLS avant chiffrement), tracepoint (points d'instrumentation stables), XDP (traitement du paquet au plus près de la carte réseau), TC (traffic control), LSM BPF (Linux Security Module programmable).
• Maps : structures de données partagées (tables de hachage, tableaux, ring buffers) qui permettent au programme kernel de communiquer avec un agent en espace utilisateur. C'est par ce canal que remontent les événements de sécurité.
• Helpers : un ensemble restreint de fonctions exposées par le noyau. Un programme eBPF ne peut pas appeler n'importe quelle fonction kernel, ce qui limite sa surface d'action.
• CO-RE (Compile Once, Run Everywhere) : grâce aux métadonnées BTF, un même binaire eBPF fonctionne sur différentes versions de noyau sans recompilation, ce qui a levé le principal frein au déploiement à grande échelle.

Cas d'usage en cybersécurité

Détection runtime. Falco, projet CNCF, s'appuie sur eBPF pour observer les appels système des conteneurs et déclencher des alertes sur des comportements anormaux : ouverture d'un shell dans un conteneur, lecture de /etc/shadow, écriture dans un répertoire système, connexion sortante vers une IP non autorisée. Tetragon (Isovalent) va plus loin en autorisant l'enforcement : le programme eBPF peut tuer le processus fautif avant que l'action n'aboutisse.

Réseau et micro-segmentation. Cilium remplace iptables par des programmes eBPF pour appliquer les NetworkPolicy Kubernetes à l'échelle L3/L4 et même L7 (HTTP, gRPC, Kafka). Le gain est double : performances (pas de parcours linéaire de chaînes iptables) et granularité (politiques basées sur l'identité du pod plutôt que sur l'IP, volatile en environnement conteneurisé). Hubble, son module d'observabilité, fournit une cartographie des flux est-ouest précieuse en réponse à incident.

Protection DDoS. Via XDP, un filtre eBPF traite les paquets avant même l'allocation d'un sk_buff, ce qui permet d'absorber des volumétries de plusieurs millions de paquets par seconde sur du matériel standard — l'approche retenue par Cloudflare et Meta.

Le revers : eBPF comme vecteur offensif

La même puissance sert les attaquants. Des rootkits eBPF (Boopkit, TripleCross, ou les usages documentés du groupe Symbiote) exploitent des programmes chargés en kernel pour masquer des processus, filtrer la sortie de ps, exfiltrer des identifiants interceptés en uprobe sur OpenSSL, ou établir un canal de commande activé par paquet magique. La détection est difficile : le code ne réside pas sur disque et échappe aux EDR qui n'inspectent pas les programmes BPF chargés.

Bonnes pratiques

• Restreindre CAP_BPF et CAP_SYS_ADMIN : seuls les agents de sécurité légitimes doivent pouvoir charger des programmes eBPF.
• Activer kernel.unprivileged_bpf_disabled=1 pour interdire le chargement par des utilisateurs non privilégiés.
• Inventorier périodiquement les programmes chargés avec bpftool prog list et bpftool map list, et alerter sur toute apparition non prévue.
• Maintenir un noyau à jour : plusieurs CVE ont visé le vérificateur lui-même, permettant des évasions de sandbox et des élévations de privilèges.
• Signer et versionner les programmes eBPF déployés, et les intégrer au périmètre de la revue de code.

Concepts liés

eBPF s'inscrit dans la continuité du durcissement système Linux (SELinux, AppArmor, seccomp) tout en offrant une programmabilité supérieure. Il constitue la brique technique de la plupart des solutions CWPP (Cloud Workload Protection Platform) et alimente les EDR orientés conteneurs. Sa télémétrie s'intègre naturellement à un SIEM et sert de socle à une démarche Zero Trust appliquée aux flux internes d'un cluster Kubernetes.