Blocage d'exécution au niveau du kernel : sécuriser les passerelles matérielles en edge avec eBPF et Tetragon

Au moment où un agent de sécurité en espace utilisateur détecte une escalade de privilèges sur un nœud en edge, l’attaquant contrôle déjà le matériel. Cet article sort de l’espace utilisateur et examine comment des outils basés sur eBPF comme Cilium Tetragon interceptent et tuent les appels système malveillants directement dans le kernel — avant qu’ils n’atteignent les E/S physiques.

Les passerelles matérielles occupent une position périlleuse dans l’architecture moderne. Placées à l’extrême périphérie du réseau — sur les chaînes de production, sous-stations régionales, hubs de livraison, et sites d’infrastructure distants — ces machines relient le cloud numérique aux actifs physiques. Elles ingèrent des données brutes provenant de contrôleurs logiques programmables (PLC), caméras, et capteurs environnementaux via des interfaces locales comme serial, CAN bus, GPIO, et composants USB spécialisés.

Contrairement aux serveurs cloud centraux isolés dans des centres de données sécurisés, les passerelles en edge sont physiquement accessibles et souvent connectées à des réseaux locaux non fiables. Si un attaquant obtient un accès physique ou réseau à une passerelle en edge, la compromettre donne un contrôle direct sur la machinerie physique.

Sécuriser ces nœuds nécessite une évolution stratégique. Les systèmes de sécurité traditionnels échouent sur l’infrastructure en edge car ils opèrent de manière asynchrone en espace utilisateur. Pour protéger le matériel physique, l’application des mesures doit devenir synchrone, préventive, et directement liée au kernel du système d’exploitation.

La faille de la détection post-facto : pourquoi la sécurité en espace utilisateur échoue en edge

Historiquement, les systèmes de détection d’intrusion hôte (HIDS) se basaient sur des agents en espace utilisateur pour surveiller la santé du système et détecter les comportements malveillants. Les paradigmes plus anciens s’appuyaient souvent sur la lecture des logs d’audit (auditd), la consultation du système de fichiers /proc, ou la réception d’événements asynchrones passés par un module kernel ou un socket de streaming.

Ce design architectural introduit une faiblesse critique en edge : l’écart sémantique et temporel.

Comprendre le problème TOCTOU (Time-Of-Check to Time-Of-Use)

Dans un modèle de sécurité traditionnel en espace utilisateur, lorsqu’un processus exécute un appel système — comme demander la permission d’écrire sur un périphérique de bloc brut ou ouvrir une socket réseau — la séquence d’événements se déroule ainsi :

[Processus en espace utilisateur] --- 1. Déclenchement de Syscall --- [Linux Kernel] (Exécution de l'opération)
                                                        |
                                                        v
[Agent de sécurité en espace utilisateur] --- 3. Détection/Alerte --- 2. Enregistrement asynchrone de l'événement

1. L’application malveillante invoque un appel système (par ex., sys_write vers une interface industrielle).
2. Le kernel traite et exécute l’appel, modifiant l’état du matériel.
3. Le kernel enregistre l’événement de façon asynchrone via des sous-systèmes comme auditd.
4. L’agent de sécurité en espace utilisateur lit l’entrée du log, la parse, l’évalue selon un ensemble de règles, et déclenche une alerte.

Au moment où l’agent lit le log, l’appel système a déjà été exécuté. Si un processus malveillant réalise une escalade de privilèges locale (LPE) exploitant une vulnérabilité du kernel, il obtient les privilèges root avant que le moniteur en espace utilisateur ne puisse analyser l’événement initial.

Sur une VM cloud, un nœud compromis peut être isolé, détruit, et redéployé en quelques secondes par un orchestrateur. Sur une passerelle matérielle physique, un attaquant qui remporte cette course peut flasher un firmware malveillant sur un microcontrôleur attaché, écraser le bootloader de la passerelle, ou commander un actionneur industriel pour une sur-rotation. Une fois le matériel manipulé, la remédiation logicielle a ses limites.

L’alternative moderne : application de l’enforcement basé sur eBPF

Extended Berkeley Packet Filter (eBPF) transforme le kernel Linux en un bac à sable programmable. Au lieu de modifier le code source du kernel ou de charger des modules instables, les développeurs écrivent de petits programmes compilés en bytecode eBPF. Ce bytecode est vérifié pour la sécurité par un vérificateur intégré au kernel (pour éviter boucles infinies, accès mémoire invalide, ou panics) et compilé en instructions CPU natives via JIT pour une exécution à la vitesse matérielle.

+--------------------------------------------------------------+
|                         ESPACE UTILISATEUR                   |
|        +-------------------------------------------+          |
|        |           Tetragon Agent Daemon            |         |
|        +-------------------------------------------+          |
|                              ^                                |
|              gRPC / JSON     | Lecture des alertes            |
|              Événements      | & métriques                     |
|                              |                                |
+------------------------------|--------------------------------+
|                            KERNEL                             |
|                              |                                |
|                              | Maps eBPF (Configuration)        |
|                              v                                |
|        +-------------------------------------------+          |
|        |          Moteur d'exécution eBPF             |         |
|        +-------------------------------------------+          |
|             | Hook                     | Hook                 |
|             v                          v                      |
|      [Table Syscall]            [Hooks de sécurité LSM]       |
|             |                          |                      |
|             +------------+-------------+                      |
|                          |                                    |
|                          v                                    |
|          Blocage synchrone / Kill du processus                |
+--------------------------------------------------------------+

eBPF déplace la sécurité d’un simple logging passif à une vérification en ligne. Plutôt que d’attendre qu’un sous-système diffuse un message dans un log, les programmes eBPF s’attachent directement aux points de hook dans le kernel :

• Kprobes (Kernel Probes) : Hooks dynamiques attachés à presque toutes les fonctions internes du kernel.
• Tracepoints : Hooks statiques intégrés dans le code source du kernel par les développeurs pour un suivi d’événements prévisible.
• Hooks LSM (Linux Security Module) : Points d’interface le long des chemins d’accès internes du kernel, permettant des décisions de sécurité avant que la ressource ne soit allouée.

Cilium Tetragon, un sous-projet CNCF de Cilium, utilise eBPF pour surveiller l’exécution des processus, l’intégrité des fichiers et des namespaces, les sockets réseau, et interfaces matérielles, allant au-delà de la visibilité en effectuant une enforcement synchrone en temps réel.

Une nuance importante : le hooking d’un appel système brut (par ex., un kprobe sur sys_openat) peut encore laisser un petit fenêtre TOCTOU si l’argument correspondant est un pointeur vers la mémoire utilisateur, car un second thread pourrait réécrire cette mémoire entre le déclenchement du hook et la consommation par le kernel. Hooker une fonction kernel ultérieure — notamment un hook LSM security_* — évite cela, car ces hooks se déclenchent sur des données résidentes dans le kernel qui ont déjà été copiées depuis l’espace utilisateur. Pour les politiques d’enforcement en edge avec la plus haute assurance (blocage d’accès à /etc/shadow ou à un bus matériel), les hooks LSM sont généralement préférés ; les kprobes sur syscalls restent utiles et sont ceux que la majorité des politiques exemplaires utilisent, mais ils offrent une garantie légèrement plus faible contre un attaquant déterminé et rapide.

Interception structurée des syscalls

Lorsque Tetragon est configuré avec une politique d’enforcement, ses programmes eBPF attachent le point d’entrée des appels système sensibles (par ex., __x64_sys_kexec_load, __x64_sys_ioctl). Lorsqu’un processus déclenche un appel système non autorisé, le programme eBPF intercepte le thread avant que le kernel ne traite l’appel.

Si les arguments violent la politique, le code eBPF agit immédiatement dans le contexte du kernel. Il peut remplacer la valeur de retour par une erreur comme EPERM (Opération non permise), ou envoyer un signal fatal (SIGKILL) directement à la structure de tâche (task_struct) du processus concerné. Le processus est terminé avant que l’appel système ne puisse modifier le matériel physique.

Renforcer les passerelles en edge contre les vecteurs physiques et cyber

Les passerelles matérielles spécialisées exécutent des charges de travail spécifiques mais font face à des menaces uniques. Voici comment l’application au niveau du kernel bloque certains schémas d’attaque ciblant le hardware en edge.

1. Bloquer l’accès non autorisé aux interfaces matérielles (/dev/*)

Les systèmes en edge exposent les bus de communication physiques au système d’exploitation sous forme de périphériques caractères ou de blocs bruts sous /dev/ (par ex., /dev/ttyUSB0 pour un convertisseur série Modbus, /dev/can0 pour un réseau automobile, ou blocs GPIO bruts).

Une application web compromise ou un conteneur MQTT tournant sur la passerelle pourrait tenter de manipuler ces interfaces. Les permissions UNIX classiques sont insuffisantes si un attaquant exploite une vulnérabilité locale pour obtenir un accès root.

Avec Tetragon, vous pouvez appliquer des politiques qui surveillent des fonctions comme sys_openat ou fd_install au niveau du kernel. Même si un processus tourne en root dans un conteneur compromis, Tetragon peut vérifier ses métadonnées de namespace de conteneur. Si ce conteneur n’est pas explicitement autorisé à ouvrir /dev/ttyUSB0, l’appel est annulé, le descripteur de fichier est bloqué, et une alerte précise est enregistrée avec les métadonnées du conteneur.

2. Éliminer l’exfiltration de données via le réseau

Les passerelles industrielles communiquent généralement avec un ensemble spécifique d’endpoints : un broker local, un jumeau numérique cloud en amont, ou un serveur NTP. Toute autre connexion réseau est suspecte.

Les attaquants cherchant à compromettre une passerelle tentent souvent de télécharger des charges utiles secondaires, des outils de reverse-shell, ou d’exfiltrer des secrets de configuration. Tetragon intercepte la création de sockets réseau au niveau du kernel via des fonctions comme tcp_connect et __sys_connect.

En évaluant les appels réseau dans le kernel, Tetragon associe le contexte d’exécution (chemin binaire, processus parent, ID du conteneur) avec les données réseau (adresse IP cible et port). Si un binaire non autorisé comme curl ou wget tente d’atteindre un port non approuvé, Tetragon tue le processus avant qu’un seul paquet de handshake TCP ne traverse la carte réseau — c’est un schéma documenté et démontré (bloquer wget sur le port 443 tout en laissant curl fonctionner est un exemple publié dans les études de cas de Tetragon).

3. Empêcher l’évasion de conteneur et l’escalade de privilèges

De nombreux gateways en edge utilisent des runtimes légers comme K3s, Docker, ou Podman pour gérer des services modulaires. La containment des conteneurs repose sur des namespaces kernel et des cgroups. Si un attaquant exploite une vulnérabilité du kernel pour sortir d’un conteneur, il obtient un accès au système hôte.

Ce n’est pas une hypothèse : la vulnérabilité Dirty Pipe (CVE-2022-0847), révélée en 2022, permet à un processus non privilégié de réécrire des données dans des fichiers en lecture seule en exploitant une faille dans le buffer de pipe Linux — un bug qui fonctionnait indépendamment de la configuration du conteneur et pouvait être utilisé pour escalader les privilèges ou altérer des fichiers à travers les frontières de namespace. L’équipe de Tetragon cite cet exemple comme une illustration claire de l’intérêt d’une enforcement en kernel, consciente des namespaces, même lorsque l’isolation par conteneur semble solide sur le papier. Par ailleurs, la documentation de politique de Tetragon cite une analyse interne montrant qu’environ 44% des chaînes d’exploitation d’évasion de conteneur reposent sur la capacité d’un processus non privilégié à créer un namespace utilisateur, ce qui lui donne un ensemble complet de capacités dans ce namespace.

Tetragon surveille en temps réel les transitions de namespace et les changements de crédentiels en hookant des fonctions comme commit_creds et des syscalls comme setns/unshare. En surveillant les gains de capacités (CAP_SYS_ADMIN, CAP_SYS_RAWIO) ou les changements de namespace sur des processus pas dans le namespace hôte, Tetragon peut isoler ou tuer un processus dès qu’il tente une transition de privilège non autorisée — avant qu’il ne puisse exécuter des commandes supplémentaires sur le système de fichiers hôte.

Déploiement de Tetragon sur des passerelles en edge bare-metal

Bien que Tetragon soit souvent déployé dans des environnements Kubernetes, il fonctionne tout aussi bien en tant que démon autonome sur des nœuds en edge bare-metal.

Prérequis pour les nœuds en edge

Pour déployer une sécurité en runtime basée sur eBPF, le kernel Linux de votre passerelle doit supporter BTF (BPF Type Format), qui permet aux programmes eBPF d’utiliser CO-RE (Compile Once – Run Everywhere) afin qu’un programme construit sur une version de kernel puisse toujours lire les bons décalages de structures sur une autre.

La documentation de compatibilité de Tetragon liste les options de configuration du kernel suivantes comme prérequis :

CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
CONFIG_BPF=y
CONFIG_BPF_EVENTS=y
CONFIG_BPF_JIT=y
CONFIG_BPF_JIT_DEFAULT_ON=y
CONFIG_BPF_KPROBE_OVERRIDE=y
CONFIG_BPF_SYSCALL=y
CONFIG_CGROUPS=y
CONFIG_DEBUG_INFO_BTF=y
CONFIG_DEBUG_INFO_BTF_MODULES=y
CONFIG_FTRACE_SYSCALLS=y
CONFIG_SECURITY=y

CONFIG_BPF_KPROBE_OVERRIDE mérite une mention spécifique : c’est l’option qui contrôle l’action Override utilisée dans la politique de bus matériel ci-dessous. Sans elle, Tetragon peut toujours détecter et tuer (Sigkill), mais ne peut pas réécrire la valeur de retour d’un syscall.

Vérifiez la prise en charge de BTF sur un nœud en cours d’exécution en vérifiant son fichier d’abstraction système :

ls -l /sys/kernel/btf/vmlinux

Si vous prévoyez d’utiliser des politiques basées sur des hooks LSM (la méthode d’application la plus forte évoquée ci-dessus), le kernel doit également avoir bpf activé dans sa pile LSM, ce qui n’est pas activé par défaut sur beaucoup de distributions. Vérifiez avec :

cat /sys/kernel/security/lsm

Si bpf n’apparaît pas dans la sortie, il faut l’ajouter à la paramètre de boot lsm= du kernel (typiquement via /etc/default/grub et la reconstruction du fichier de configuration grub) — testez d’abord sur du matériel non critique, car ces changements peuvent affecter le comportement de démarrage.

La matrice de tests de Tetragon couvre les kernels LTS 4.19, 5.4, 5.10, et 5.15, et recommande le kernel stable le plus récent compatible avec votre matériel, car les capacités eBPF (comme kprobe_multi fast-attach, ou la visibilité complète des arguments d’exécution sur arm64) continuent d’être intégrées dans les versions plus récentes.

Workflow d’installation

Pour une passerelle en edge tournant sous une distribution Debian, Ubuntu ou Yocto, Tetragon peut être installé directement en tant que binaire et géré via systemd. La version actuelle, selon la documentation officielle, est v1.7.0 :

# 1. Récupérer le bundle de la dernière version
curl -LO https://github.com/cilium/tetragon/releases/download/v1.7.0/tetragon-v1.7.0-amd64.tar.gz

# 2. Extraire l’archive
tar -xvf tetragon-v1.7.0-amd64.tar.gz
cd tetragon-v1.7.0-amd64/

# 3. Exécuter le script d’installation natif
sudo ./install.sh

# 4. Vérifier le statut du service système
sudo systemctl status tetragon

Les versions évoluent rapidement, il est conseillé de consulter la page des releases de Tetragon avant de fixer une version dans les scripts de provisioning.

Deux autres méthodes supportées pour les flottes en edge :

• Déploiement en container, utile si votre passerelle utilise déjà un runtime de container pour ses charges de travail : bash docker run --name tetragon --rm -d \ --pid=host --cgroupns=host --privileged \ -v /sys/kernel/btf/vmlinux:/var/lib/tetragon/btf \ quay.io/cilium/tetragon:v1.7.0 - Installation via Helm, si la passerelle tourne avec une distribution Kubernetes légère comme K3s plutôt que systemd : bash helm repo add cilium https://helm.cilium.io helm repo update helm install tetragon cilium/tetragon -n kube-system kubectl rollout status -n kube-system ds/tetragon -w

Une fois en fonctionnement, le démon Tetragon s’attache au kernel et envoie des événements de télémétrie dans un fichier log structuré JSON situé à /var/log/tetragon/tetragon.log.

Rédiger des politiques de traçage Tetragon pour la protection en edge

Tetragon utilise des ressources personnalisées YAML TracingPolicy pour définir les points de hook et les actions d’enforcement. Ces CR fonctionnent de la même manière que vous utilisiez Kubernetes — en mode bare-metal, vous pointez le démon directement vers un fichier de politique avec --tracing-policy.

Politique 1 : Blocage préventif de l’exécution de binaries non autorisés

Cette politique surveille l’exécution de binaries et limite leur lancement dans des répertoires volatils ou en écriture (/tmp, /var/tmp, /dev/shm), souvent utilisés pour déposer et exécuter des payloads.

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: block-volatile-execution
spec:
  kprobes:
    - call: "sys_execve"
      syscall: true
      args:
        - index: 0
          type: "string" # Chemin du binary en cours d’exécution
      selectors:
        - matchArgs:
            - index: 0
              operator: "Prefix"
              values:
                - "/tmp/"
                - "/var/tmp/"
                - "/dev/shm/"
          matchActions:
            - action: Sigkill

Lorsqu’un binary tente de s’exécuter depuis /tmp/, le probe eBPF de Tetragon détecte la condition de préfixe sur la sys_execve. Le kernel déclenche l’action Sigkill, terminant le processus avant que le binary ne soit chargé en mémoire.

Politique 2 : Protection des interfaces matérielles brutes contre les logiciels containerisés

Cette politique empêche les processus containerisés d’accéder aux interfaces série ou USB brutes (/dev/ttyUSB*, /dev/bus/usb/*) sauf si le processus tourne dans l’espace de namespace du host — c’est-à-dire qu’elle limite l’application à des containers, sans affecter les outils de confiance du système hôte.

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: protect-hardware-buses
spec:
  kprobes:
    - call: "sys_openat"
      syscall: true
      args:
        - index: 1
          type: "string" # Chemin du fichier
      selectors:
        - matchArgs:
            - index: 1
              operator: "Prefix"
              values:
                - "/dev/ttyUSB"
                - "/dev/bus/usb/"
          matchNamespaces:
            - namespace: Pid
              operator: "NotIn"
              values:
                - "host_ns"
          matchActions:
            - action: Override
              argError: -1 # -EPERM : Opération non permise

matchNamespaces permet de limiter un sélecteur aux processus qui ne tournent pas dans le namespace PID du host — le mot-clé host_ns est résolu automatiquement vers l’inode du namespace. En renvoyant -1 (-EPERM) via l’action Override, le logiciel appelant reçoit une réponse d’accès refusé comme si les permissions étaient manquantes, sans que le kernel n’exécute l’appel sys_openat original.

 Note de correction : une version antérieure de cette politique utilisait un bloc matchNamespaces avec une description en texte brut (namespace: "those_outside_host_pid") au lieu de la syntaxe réelle de Tetragon — namespace: Pid, operator: NotIn, values: ["host_ns"]. Ce champ doit respecter le schéma officiel, avec un type de namespace (Uts, Ipc, Mnt, Pid, PidForChildren, Net, Cgroup, User, et, sur kernels ≥5.6, Time/TimeForChildren), un opérateur (In ou NotIn), et une valeur (inode ou host_ns). La YAML corrigée ci-dessus reflète cette syntaxe.

Fermer le gap de redémarrage de l’agent : enforcement persistant

Un risque opérationnel spécifique à l’edge est la connectivité intermittente et les redémarrages périodiques de l’agent — précisément les conditions où une défaillance de l’agent, même brève, crée une fenêtre d’exposition. Tetragon propose une solution : enforcement persistant.

En exécutant le démon avec --keep-sensors-on-exit, les programmes eBPF chargés restent fixés sous /sys/fs/bpf/tetragon dans le filesystem BPF du kernel, même si le processus Tetragon en espace utilisateur plante, est tué, ou en cours de redémarrage lors d’une mise à jour. Les actions d’enforcement (Sigkill, Override) continuent de fonctionner car elles résident dans le kernel, pas dans le processus Tetragon — seul le pipeline de rapport d’événements est interrompu jusqu’au retour du démon.

tetragon --bpf-lib bpf/objs/ --keep-sensors-on-exit --tracing-policy protect-hardware-buses.yaml

Pour une passerelle de production sur une liaison WAN instable, cela comble précisément la faille évoquée : l’enforcement ne disparaît pas silencieusement durant la fenêtre d’indisponibilité de l’agent.

Déploiement sécurisé : modes d’enforcement

Parce qu’une mauvaise politique peut dégrader la performance du nœud ou, pire, tuer un processus légitime sur un matériel inaccessible physiquement, Tetragon supporte deux modes : Monitoring (actions seulement loguées, pas appliquées) et Enforcement (actions effectives). La démarche recommandée pour une nouvelle politique en edge est : commencer en mode monitoring en production, vérifier qu’elle ne se déclenche que pour des comportements indésirables, puis la passer en mode enforcement — plutôt que de tester uniquement en laboratoire, ce qui peut ne pas refléter le trafic réel.

Considérations de performance pour l’edge à ressources limitées

L’infrastructure en edge fonctionne souvent sous des contraintes strictes : ordinateurs industriels, SBC ARM64, ou passerelles fanless avec processeurs faibles et RAM limitée. Les plateformes de télémétrie en espace utilisateur lourdes peuvent épuiser les ressources disponibles, entraînant pertes de paquets ou retards dans la lecture des capteurs.

Tetragon minimise la surcharge grâce à un filtrage agressif en kernel :

TRADITIONNEL HIDS (ex. Falco)
[Kernel] --- Écoute de TOUS les syscalls (haute surcharge) --- [Daemon en espace utilisateur] (Filtrage & décision)

ARCHITECTURE TETRAGON eBPF
[Kernel : moteur eBPF évalue les règles localement] --- Seules les correspondances/alertes vérifiées --- [Daemon en espace utilisateur]

Si un syscall est bénin et conforme aux paramètres, Tetragon ignore l’événement ou incrémente un compteur local en kernel. Les données ne traversent la frontière kernel-utilisateur que si une règle est violée ou qu’un événement de cycle de vie inconnu survient.

Concernant la surcharge CPU : il n’existe pas de chiffre officiel unique pour Cilium, et les chiffres publiés varient selon la charge. Des études de la communauté de 2025–2026 rapportent une surcharge allant de moins de 1% CPU sur des nœuds peu chargés, à environ 1–3% sur des nœuds avec un volume d’événements modéré et plusieurs politiques actives, jusqu’à 5–8% sur des nœuds à fort churn syscall et nombreuses politiques. La tendance générale est que le coût dépend du volume d’événements et du nombre de TracingPolicy actifs, pas de la taille du nœud. Sur une passerelle en edge avec peu de politiques ciblées, la surcharge reste faible. Considérez tout chiffre fixe comme dépendant de la charge et testez avec votre propre trafic.

Limitation connue : eBPF n’est pas invulnérable

Il est important de le préciser : une architecture de sécurité entièrement basée sur le kernel n’est pas une solution miracle. Un attaquant ayant déjà CAP_BPF ou CAP_SYS_ADMIN — par exemple via une vulnérabilité kernel ou un DaemonSet privilégié compromis — peut charger ses propres programmes eBPF qui hookent les mêmes fonctions kernel surveillées par Tetragon, filtrant les événements avant qu’ils n’atteignent la pipeline de rapport en espace utilisateur. C’est un domaine actif de recherche en sécurité en 2026, pas une curiosité théorique. Cela signifie que Tetragon (comme Falco et autres outils eBPF) doit être déployé dans une stratégie de défense en profondeur — en limitant l’obtention de CAP_BPF, en surveillant le chargement de programmes BPF non autorisés, et en ne considérant pas un agent résident dans le kernel comme totalement digne de confiance si le root hôte est compromis.

Tableau récapitulatif : HIDS legacy vs. enforcement eBPF Tetragon

Attribut de sécurité	HIDS en espace utilisateur (ex. auditd, Falco ancien)	Enforcement kernel moderne (Tetragon)
Couche d’exécution	Agent en espace utilisateur analysant logs ou queues	Sandbox natif dans le kernel
Timing d’enforcement	Asynchrone / réactif : alerte après l’exploitation ou la modification matérielle	Synchrone / préventif : interception et blocage avant la fin du syscall
Vulnérabilité au bypass	Élevée : compromis root permettant de désactiver agents ou logs	Plus faible, mais pas nul : un attaquant avec CAP_BPF peut charger des programmes concurrents
Empreinte système	Modérée à élevée, dépend du volume d’événements	Faible, dépend du volume d’événements et du nombre de politiques actives
Adapté au hardware en edge	Faible : vulnérable aux races TOCTOU ; risque de manipulation physique	Fort : durcit les interfaces I/O locales au niveau OS/driver, avec enforcement persistant après redémarrage

Conclusion : sécuriser le machine en edge

Avec l’évolution de l’edge computing, la protection du matériel physique doit suivre la rapidité du système d’exploitation. La détection réactive traditionnelle laisse une fenêtre dangereuse entre l’exploitation et l’alerte en espace utilisateur.

En utilisant eBPF et des outils comme Cilium Tetragon, les ingénieurs peuvent construire des garde-fous résilients et proactifs autour des passerelles physiques. Déplacer le filtrage d’exécution dans le kernel Linux permet d’intercepter les attaques au niveau des syscalls et des hooks LSM. Les tentatives de connexion non autorisées sont bloquées, les transitions de privilèges malveillantes empêchées, et les requêtes hardware modifiées neutralisées avant qu’elles n’atteignent le matériel — avec la réserve que, comme toute couche de contrôle, cela fonctionne mieux en tant que couche bien instrumentée plutôt que comme stratégie unique.

---

Changelog

Métadonnées supprimées : la section titre/lede fusionnée dans l’export source a été séparée en un titre H1 clair et un paragraphe introductif.

Corrections : - Correction du bloc matchNamespaces dans la Politique 2 (namespace: "those_outside_host_pid" n’est pas syntaxe valide Tetragon). Remplacement par le vrai schéma — namespace: Pid, operator: NotIn, values: ["host_ns"] — vérifié avec la documentation officielle des sélecteurs de Tetragon et plusieurs exemples de politiques. - La liste des options de configuration du kernel requises a été étendue pour couvrir toutes celles listées dans la FAQ officielle, en soulignant que CONFIG_BPF_KPROBE_OVERRIDE contrôle l’action Override utilisée dans la Politique 2. - La mention de surcharge CPU a été adoucie. La valeur « 1% à 2.5% » n’est pas issue d’un benchmark officiel unique ; des études de 2025–2026 rapportent une gamme allant de moins de 1% à 8% selon la charge. La présentation est désormais une fourchette sourcée plutôt qu’un chiffre fixe. - Correction de petites incohérences de rédaction (ex. « assets physiques physiques », « flashing firmware malveillant »). - Ajout d’une note sur la différence entre hooks syscalls (qui peuvent laisser une petite fenêtre TOCTOU sur arguments pointeurs) et hooks LSM (qui ne laissent pas cette fenêtre), pour clarifier la nuance.

Sources vérifiées : site officiel Tetragon, documentation, blog Cilium 2025, articles indépendants 2025–2026.