Tracee : détection runtime et forensic avec eBPF

Tracee ne se contente pas de tracer ce qui se passe dans le noyau : il applique des signatures comportementales pour dire « ceci est suspect ». C'est la différence entre un traceur (comme bpftrace) et un outil de détection runtime : Tracee, construit sur eBPF par Aqua Security, observe les appels système et lève une alerte quand un enchaînement correspond à une technique d'attaque. Cette page le montre au travail sur un hôte, avec des sorties réelles capturées sur une VM Ubuntu 24.04 (noyau 6.8, Tracee v0.24.1) : d'abord une trace brute, puis une vraie détection. Pour le socle eBPF, voir le hub eBPF.

Ce que vous allez apprendre

Distinguer tracer un événement et détecter un comportement
Lancer Tracee sur un hôte avec son image conteneur
Tracer un appel système et lire la sortie
Déclencher et observer une signature de détection
Situer Tracee face à Falco et Tetragon, et en Kubernetes

Le problème : tracer ne suffit pas à détecter

Les outils de traçage eBPF montrent ce qui se passe : tel processus a lancé tel programme, ouvert tel fichier. C'est indispensable, mais brut : à vous d'y repérer l'anormal. Sur un serveur de production, personne ne lit en continu le flux des appels système.

Tracee ajoute la couche qui manque : des signatures, des règles qui reconnaissent des comportements de sécurité connus (un programme qui détecte qu'on l'analyse, un exécutable écrit puis lancé, un shell relié à une socket réseau). Tracee transforme un flux d'événements en alertes exploitables. C'est un outil de détection runtime et d'analyse forensic, pas un simple traceur.

Prérequis

Un hôte Linux avec un noyau récent et BTF (/sys/kernel/btf/vmlinux présent), voir CO-RE et BTF.
Un runtime de conteneurs (Docker ou containerd) pour lancer l'image officielle.
Les privilèges nécessaires : Tracee charge des programmes eBPF sur l'hôte.

Lancer Tracee

Tracee se distribue sous forme d'image conteneur officielle, qui embarque tout le nécessaire. On la lance en mode privilégié avec accès à l'hôte (c'est un outil de sécurité qui doit voir tout le système) :

sudo docker run --rm --name tracee --pid=host --cgroupns=host --privileged \
  -v /etc/os-release:/etc/os-release-host:ro \
  -v /sys/kernel/security:/sys/kernel/security:ro \
  -v /boot:/boot:ro \
  aquasec/tracee:0.24.1

Sans option, Tracee charge son jeu de signatures et surveille. Pour commencer plus simplement, on peut lui demander de tracer un seul type d'événement.

Tracer un événement

Traçons les exécutions de programmes (execve), pour voir la forme des données :

sudo docker run ... aquasec/tracee:0.24.1 --events execve --output table

Sortie réelle :

TIME             UID   COMM    PID     TID    RET  EVENT    ARGS
12:58:24:958968  1000  bash    26574   26574  0    execve   pathname: /usr/bin/uname, argv: [/usr/bin/uname -r]
12:58:24:959590  1000  bash    26575   26575  0    execve   pathname: /usr/bin/id, argv: [/usr/bin/id]
12:58:24:960289  1000  bash    26577   26577  0    execve   pathname: /usr/bin/sleep, argv: [sleep 0.3]

Chaque ligne donne l'heure, l'utilisateur (UID), le processus (COMM), son PID, la valeur de retour (RET) et surtout les arguments détaillés : le chemin exact du programme et sa ligne de commande. C'est déjà plus riche qu'une trace classique, mais on reste au niveau de l'observation. La vraie force de Tracee est ailleurs.

Détecter un comportement : les signatures

Passons à la détection. Une signature intéressante est anti_debugging : elle repère un programme qui tente de détecter s'il est analysé, une technique courante des logiciels malveillants pour échapper aux outils d'inspection. Concrètement, elle se déclenche quand un processus appelle ptrace avec l'option PTRACE_TRACEME.

On lance Tracee sur cette signature, puis on exécute un petit programme qui déclenche ce comportement :

sudo docker run ... aquasec/tracee:0.24.1 --events anti_debugging

Sortie réelle, la détection se produit :

TIME             UID   COMM       PID     TID    RET  EVENT            ARGS
13:20:36:614888  1000  antidebug  27215   27215  0    anti_debugging   detectedFrom: ptrace
13:20:36:615310  1000  antidebug  27216   27216  0    anti_debugging   detectedFrom: ptrace
13:20:36:615653  1000  antidebug  27217   27217  0    anti_debugging   detectedFrom: ptrace

L'événement n'est plus execve mais anti_debugging : Tracee ne dit pas seulement « ce programme a fait un appel système », il dit « ce programme a un comportement de logiciel qui cherche à se cacher », avec la source de la détection (detectedFrom: ptrace). C'est une alerte de sécurité, pas une simple observation. Voilà ce qui distingue Tracee d'un traceur.

Les signatures disponibles

Tracee embarque un catalogue de signatures qui couvrent des techniques d'attaque documentées. Quelques exemples parlants :

Signature	Comportement détecté
`anti_debugging`	Un programme cherche à savoir s'il est analysé
`dropped_executable`	Un exécutable est écrit puis lancé (charge utile)
`fileless_execution`	Exécution sans fichier sur disque
`stdio_over_socket`	Entrées/sorties reliées à une socket réseau (reverse shell)
`illegitimate_shell`	Un serveur web lance un shell interactif

Chaque détection est enrichie de contexte (processus, conteneur, arguments), ce qui en fait un point de départ pour l'analyse forensic : reconstituer ce qui s'est passé après une alerte.

Tracee en Kubernetes

Sur un cluster, Tracee se déploie en DaemonSet : une instance par nœud, qui surveille tous les conteneurs. Les détections remontent avec le contexte Kubernetes (pod, espace de noms), et peuvent être envoyées vers un collecteur (webhook, sortie structurée) pour alimenter un SIEM ou déclencher une réponse.

kubectl create namespace tracee
helm install tracee aqua/tracee -n tracee

Le principe reste identique à ce qu'on a vu sur l'hôte : ce sont les mêmes signatures, appliquées à l'échelle du cluster.

Tracee, Falco ou Tetragon

Trois outils de sécurité runtime eBPF coexistent, avec des angles différents. Le choix mérite une page dédiée : voir Falco vs Tetragon pour la comparaison détaillée. En résumé :

Tracee met l'accent sur la détection par signatures et le forensic, avec un fort héritage de recherche en menaces.
Falco est la référence historique de la détection par règles, largement adopté et intégré (projet CNCF).
Tetragon va au-delà de la détection : il peut bloquer une action directement dans le noyau.

Les trois ne s'excluent pas ; ils traduisent des priorités différentes entre observation, détection et application.

Sécurité et points de vigilance

Privilèges élevés. Tracee tourne en mode privilégié avec accès à l'hôte : c'est un composant sensible, à déployer avec les mêmes précautions qu'un agent de sécurité (surface réduite, mises à jour suivies).
Volume d'événements. Sur un hôte chargé, activer trop d'événements ou de signatures génère du bruit et un surcoût. Cibler les signatures pertinentes pour votre modèle de menace.
Données sensibles. Les détections contiennent des chemins, des arguments, parfois des fragments de données. Traitez ces flux comme des journaux de sécurité, avec le contrôle d'accès correspondant.
Détection, pas prévention. Tracee alerte ; il ne bloque pas par lui-même. Pour empêcher une action, il faut un outil d'application comme Tetragon, ou brancher la réponse en aval.

Dépannage

Symptôme	Cause probable	Solution
Échec au démarrage, BTF manquant	Vieux noyau sans BTF	Vérifier `/sys/kernel/btf/vmlinux`, mettre à jour le noyau
Aucune détection	Signature non activée ou non déclenchée	Vérifier `--events`, provoquer le comportement ciblé
`permission denied`	Conteneur non privilégié	Ajouter `--privileged` et les montages hôte requis
Trop d'événements	Jeu d'événements trop large	Restreindre avec `--events` et des filtres

À retenir

Tracee est un outil de détection runtime et de forensic basé sur eBPF, pas un simple traceur.
Il trace des événements riches (chemin, arguments) et applique des signatures qui reconnaissent des comportements suspects.
Une détection réelle (anti_debugging, detectedFrom: ptrace) est une alerte de sécurité, pas une observation neutre.
Ses signatures couvrent des techniques documentées : exécutable déposé, exécution sans fichier, reverse shell.
En Kubernetes, il se déploie en DaemonSet avec le contexte pod / espace de noms.
Tracee détecte ; pour bloquer, il faut un outil d'application comme Tetragon.

Prochaines étapes

Falco vs Tetragon Choisir son outil de sécurité runtime eBPF selon le besoin.

Tetragon : observer et bloquer Passer de la détection à l'application de politiques dans le noyau.

Les rootkits eBPF et leur détection Ce que Tracee aide à repérer côté menace.

Le hub eBPF Comprendre la technologie qui rend cette détection possible.