Linux et eBPF : durcir sans casser ses outils de sécurité

eBPF permet d’exécuter des programmes contrôlés dans certains points du noyau Linux. Il sert à l’observabilité, au réseau et à la sécurité. Comme d’autres capacités puissantes, il peut être détourné par un attaquant ayant obtenu les permissions nécessaires. L’objectif du durcissement est de limiter cet usage malveillant tout en préservant les outils légitimes.

1. Comprendre le risque

Un rootkit cherche à dissimuler une présence ou une activité. Un programme eBPF peut observer ou influencer certains événements selon son type et ses points d’attachement. Cela n’implique ni qu’un utilisateur quelconque puisse le charger, ni qu’il persiste automatiquement après un redémarrage. La persistance suppose notamment un mécanisme de rechargement ou un autre composant à examiner.

Le vérificateur eBPF examine des propriétés du programme avant son chargement. Le JIT transforme le programme en code machine pour son exécution. Durcir le JIT n’active pas le JIT et ne rend pas tous les programmes inoffensifs. Les autorisations et le maintien à jour du noyau restent essentiels.

2. Faire l’inventaire avant de bloquer

Identifiez la distribution, la version du noyau, les outils réseau, les agents de sécurité et les composants de conteneurisation. Un CNI, c’est-à-dire un composant réseau pour conteneurs, ou un outil d’observabilité peut dépendre d’eBPF. Relevez les capacités accordées aux services et aux conteneurs ; une capacité privilégiée dans un conteneur n’est pas anodine.

Les besoins ne se résument pas à CAP_BPF. Selon les opérations et versions, d’autres capacités comme CAP_PERFMON, CAP_NET_ADMIN ou des privilèges plus larges interviennent. Consultez la documentation du noyau et du produit réellement installé. Réduisez les permissions selon l’usage nécessaire, pas par une règle copiée sans contexte.

3. Lire les paramètres sans les modifier

Sur une machine Linux autorisée, les commandes suivantes consultent l’état. Elles nécessitent les outils correspondants ; certaines informations bpftool peuvent demander des privilèges. Une erreur de permission ou un paramètre absent doit être conservé comme résultat à interpréter.

uname -r
sysctl kernel.unprivileged_bpf_disabled
sysctl net.core.bpf_jit_harden
bpftool version
bpftool prog show
bpftool map show

Références : paramètres kernel et paramètres réseau du noyau Linux. Ces valeurs ne constituent pas une recommandation de les appliquer toutes. Commencez par un hôte pilote et vérifiez la documentation correspondant à votre noyau.

4. Définir une détection interprétable

Établissez une référence : quels programmes sont habituellement chargés, par quels services et à quels moments ? Après une mise à jour légitime, des identifiants et des noms peuvent changer. Un nom inhabituel seul est donc un signal faible. Croisez le processus chargeur, ses privilèges, le service associé et les modifications de configuration.

Falco, auditd ou un agent de sécurité peuvent contribuer à la collecte selon leur version et leur configuration. Une règle doit correspondre à un événement réellement disponible, avec des champs valides et un volume soutenable. Ce guide ne fournit pas une règle générique prétendument prête à détecter tous les rootkits. Rejouez d’abord un chargement légitime de test et vérifiez ce qui remonte.

Si le noyau est compromis, ses propres réponses peuvent être trompeuses. Une liste bpftool vide n’est pas un certificat d’intégrité. Un incident confirmé peut nécessiter une investigation depuis un environnement de confiance et une reconstruction, selon le contexte.

5. Recette du durcissement

• Consigner distribution, noyau, configuration et versions des outils de collecte.
• Relever les valeurs initiales et l’inventaire eBPF sur une machine pilote.
• Tester une modification à la fois selon la procédure de changement retenue.
• Vérifier réseau, conteneurs, supervision et agent de sécurité après chaque modification.
• Vérifier le refus d’un chargement non autorisé et la remontée d’un événement de test autorisé.
• Comparer consommation, erreurs et journaux avant et après ; documenter les exceptions.

Le résultat attendu est une limitation démontrée d’un usage non nécessaire, avec maintien des services légitimes. Le protocole doit inclure un redémarrage si les valeurs ou politiques choisies le nécessitent. Les résultats dépendent du noyau, des outils et du périmètre testés.

6. Retour arrière et suite de l’audit

Conservez une console de secours et les fichiers de configuration initiaux. Le retour arrière doit restaurer les paramètres persistants et, si nécessaire, redémarrer dans une fenêtre prévue. La valeur 1 de désactivation de l’eBPF non privilégié exige une attention particulière : un simple changement à chaud peut être impossible.

Après un soupçon de rootkit, ne supprimez pas au hasard les programmes observés : vous pourriez couper le réseau ou détruire des éléments utiles. Préservez les traces, déterminez le périmètre et décidez de la reprise avec l’équipe de réponse à incident. Le durcissement préventif et le traitement d’une compromission sont deux activités liées, avec des critères différents.

Sources et références

Références consultées le 10 octobre 2026. Les schémas sont des représentations pédagogiques ; les exemples et recettes proposés doivent être adaptés au périmètre réel.

• Linux - Paramètres kernel, dont unprivileged_bpf_disabled
• Linux - Paramètres réseau, dont bpf_jit_harden