Inbraakdetectie & Monitoring 15 min leestijd

eBPF voor Linux Security: Runtime Dreigingsdetectie met Tetragon en Falco

Leer hoe je eBPF inzet voor runtime beveiligingsmonitoring op Linux. Praktische gids met installatie van Tetragon en Falco, custom beveiligingsregels, en eBPF hardening — met werkende codevoorbeelden voor directe toepassing.

Editorial Team

Waarom Runtime Security in 2026 Onmisbaar Is

Laten we eerlijk zijn: statische beveiligingsscans en firewallregels zijn jarenlang de ruggengraat van Linux-beveiliging geweest. En ze doen nog steeds goed werk. Maar de realiteit van 2026 dwingt ons om verder te kijken. Met gemiddeld 8 tot 9 nieuwe kernel-kwetsbaarheden per dag en exploitatiecycli die dankzij AI-gestuurde reconnaissance in uren verlopen in plaats van weken, is wachten op de volgende patchcyclus simpelweg niet meer voldoende.

Hier komt eBPF (extended Berkeley Packet Filter) in beeld.

Deze technologie stelt je in staat om beveiligingsprogramma's direct in de Linux-kernel te draaien — zonder kernelmodules te laden of broncode aan te passen. Wat je daarmee krijgt is realtime zichtbaarheid in systeemaanroepen, procesuitvoering, bestandstoegang en netwerkverkeer, met verrassend weinig overhead. Tools als Tetragon en Falco bouwen hierop voort en bieden kant-en-klare runtime beveiligingsmonitoring die zero-day exploits, privilege-escalaties en container-escapes detecteert op het moment dat ze plaatsvinden.

In deze gids neem ik je stap voor stap mee door de praktische inzet van eBPF voor Linux-beveiliging. Van installatie en configuratie tot het schrijven van je eigen beveiligingsregels — met werkende codevoorbeelden die je direct kunt toepassen op je eigen servers.

Wat Is eBPF en Hoe Werkt Het?

Oké, even de basis. eBPF is een technologie waarmee je sandboxed programma's in de Linux-kernel kunt draaien, zonder de kernel zelf aan te passen. Het was oorspronkelijk ontworpen voor netwerkpakketfiltering (als opvolger van het klassieke Berkeley Packet Filter), maar is inmiddels uitgegroeid tot een veelzijdig platform voor observability, networking en security.

Architectuur op hoofdlijnen

De werking van eBPF draait om drie kerncomponenten:

  • eBPF-programma's: Kleine programma's geschreven in een beperkte instructieset, die worden gecompileerd naar eBPF-bytecode. Ze kunnen worden gekoppeld aan honderden hookpunten in de kernel — van systeemaanroepen en tracepoints tot LSM-hooks en netwerkstacks.
  • De verifier: Voordat een eBPF-programma wordt geladen, voert de kernel een grondige statische analyse uit. De verifier controleert op oneindige lussen, onveilige geheugentoegang en mogelijke crashes. Alleen programma's die deze analyse doorstaan worden geaccepteerd.
  • eBPF-maps: Gedeelde datastructuren (hash tables, arrays, ring buffers) waarmee eBPF-programma's data kunnen uitwisselen met userspace-applicaties en met elkaar.

Waarom eBPF voor security?

De voordelen ten opzichte van traditionele beveiligingstools zijn eerlijk gezegd behoorlijk overtuigend:

  • Kernel-level zichtbaarheid: Je ziet letterlijk alles wat het besturingssysteem doet, zonder afhankelijk te zijn van logbestanden die een aanvaller kan manipuleren.
  • Minimale overhead: eBPF-programma's draaien in de kernel en filteren events voordat ze naar userspace worden gestuurd. Typisch minder dan 1% CPU-overhead — dat merk je nauwelijks.
  • Tamper-proof: Anders dan userspace-agents kan een aanvaller eBPF-programma's niet zomaar uitschakelen of manipuleren.
  • Dynamisch: Programma's kunnen at runtime worden geladen en verwijderd, zonder herstart of kernelwijzigingen.
  • Proactief: Naast detectie kan eBPF ook handhaving bieden — verdachte acties blokkeren op het moment dat ze plaatsvinden.

Tetragon: Kernel-Level Security Observability

Tetragon is een open-source beveiligingstool van het Cilium-project (CNCF), ontworpen voor security observability en runtime enforcement via eBPF. Wat het onderscheidt van andere tools is dat het filtering en beleidshandhaving direct in de kernel uitvoert. Dat betekent dat alleen relevante events naar userspace worden gestuurd, wat een enorm verschil maakt qua performance.

Vereisten

  • Linux-kernel versie 4.19 of hoger (5.10+ aanbevolen voor volledige functionaliteit)
  • BTF-ondersteuning ingeschakeld (CONFIG_DEBUG_INFO_BTF=y)
  • Root-toegang voor het laden van eBPF-programma's

Controleer eerst of BTF beschikbaar is op je systeem:

# Controleer of BTF is ingeschakeld
ls -la /sys/kernel/btf/vmlinux

# Als het bestand bestaat, is BTF beschikbaar
# Verwachte output: -r--r--r-- 1 root root ... /sys/kernel/btf/vmlinux

Installatie op Linux

Tetragon kan als standalone daemon op elke Linux-server worden geïnstalleerd. Dit is vrij rechttoe rechtaan:

# Download de nieuwste release (v1.6.0, maart 2026)
curl -LO https://github.com/cilium/tetragon/releases/download/v1.6.0/tetragon-v1.6.0-amd64.tar.gz

# Verifieer de checksum
sha256sum tetragon-v1.6.0-amd64.tar.gz

# Pak het archief uit en installeer
tar -xvf tetragon-v1.6.0-amd64.tar.gz
cd tetragon-v1.6.0-amd64/
sudo ./install.sh

# Start en controleer de service
sudo systemctl enable --now tetragon
sudo systemctl status tetragon

Eerste events bekijken

Zodra Tetragon draait, begint het automatisch procesuitvoering en basale beveiligingsevents vast te leggen. Met de tetra CLI kun je events realtime streamen — en dat is eigenlijk waar het leuk wordt:

# Stream events in compact formaat
sudo tetra getevents -o compact

# Voorbeeld output:
# 🚀 process  /usr/bin/curl https://example.com
# 🚀 process  /usr/bin/bash -c "whoami"
# 💥 exit     /usr/bin/curl https://example.com 0

# JSON-output voor gedetailleerde analyse
sudo tetra getevents | jq '.process_exec.process | {binary, arguments, uid}'

Custom TracingPolicy: bestandstoegang monitoren

De echte kracht van Tetragon zit in TracingPolicies — YAML-bestanden waarmee je exact definieert welke kernel-events je wilt monitoren en hoe je erop wilt reageren. Hier een voorbeeld dat schrijfacties naar kritieke systeembestanden detecteert:

# /etc/tetragon/tetragon.tp.d/sensitive-file-access.yaml
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: sensitive-file-access
spec:
  kprobes:
    - call: "security_file_permission"
      syscall: false
      args:
        - index: 0
          type: "file"
        - index: 1
          type: "int"
      selectors:
        - matchArgs:
            - index: 0
              operator: "Prefix"
              values:
                - "/etc/shadow"
                - "/etc/passwd"
                - "/etc/sudoers"
            - index: 1
              operator: "Equal"
              values:
                - "2"  # MAY_WRITE

Laad de policy en test 'm:

# Laad de TracingPolicy
sudo tetra tracingpolicy add /etc/tetragon/tetragon.tp.d/sensitive-file-access.yaml

# Controleer of de policy actief is
sudo tetra tracingpolicy list

# Test door een schrijfactie naar /etc/shadow te simuleren
sudo touch /etc/shadow.test

# Bekijk de gegenereerde events
sudo tetra getevents -o compact | grep shadow

Netwerkverbindingen monitoren

Een andere veelgebruikte use case is het monitoren van uitgaande netwerkverbindingen. Denk aan het detecteren van ongeautoriseerde communicatie, zoals command-and-control (C2) verkeer:

# /etc/tetragon/tetragon.tp.d/network-monitor.yaml
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: network-connections
spec:
  kprobes:
    - call: "tcp_connect"
      syscall: false
      args:
        - index: 0
          type: "sock"
# Laad en test de netwerk-policy
sudo tetra tracingpolicy add /etc/tetragon/tetragon.tp.d/network-monitor.yaml

# Genereer testverkeer
curl -s https://example.com > /dev/null

# Verwachte output in tetra getevents:
# 🚀 process  /usr/bin/curl https://example.com
# 🔌 connect  /usr/bin/curl tcp 10.0.0.5:43210 -> 93.184.216.34:443
# 💥 exit     /usr/bin/curl https://example.com 0

Process credentials monitoring

Voor het detecteren van privilege-escalaties is het essentieel om veranderingen in procesrechten te monitoren. Dit is makkelijker in te schakelen dan je misschien denkt:

# Schakel process credentials monitoring in
echo "true" | sudo tee /etc/tetragon/tetragon.conf.d/enable-process-cred

# Herstart Tetragon om de wijziging toe te passen
sudo systemctl restart tetragon

# Nu worden UID/GID-veranderingen zichtbaar in events
sudo tetra getevents | jq 'select(.process_exec.process.process_credentials)'

Falco: Runtime Security met eBPF

Falco is een CNCF-graduated project dat oorspronkelijk door Sysdig is ontwikkeld. Het biedt een regelgebaseerde engine voor het detecteren van afwijkend gedrag in hosts, containers en Kubernetes-omgevingen. Sinds versie 0.43+ gebruikt Falco de modern_ebpf driver als aanbevolen methode — en eerlijk gezegd maakt dat de installatie een stuk eenvoudiger dan vroeger.

Installatie op een Linux-host

# Voeg de Falco repository toe (Debian/Ubuntu)
curl -fsSL https://falco.org/repo/falcosecurity-packages.asc | \
  sudo gpg --dearmor -o /usr/share/keyrings/falco-archive-keyring.gpg

echo "deb [signed-by=/usr/share/keyrings/falco-archive-keyring.gpg] \
  https://download.falco.org/packages/deb stable main" | \
  sudo tee /etc/apt/sources.list.d/falcosecurity.list

sudo apt-get update
sudo apt-get install -y falco

# Voor RHEL/Rocky/AlmaLinux:
sudo rpm --import https://falco.org/repo/falcosecurity-packages.asc
sudo curl -fsSL -o /etc/yum.repos.d/falcosecurity.repo \
  https://falco.org/repo/falcosecurity-rpm.repo
sudo dnf install -y falco

Modern eBPF driver configureren

Het mooie van de modern_ebpf driver is dat hij ingebouwd zit in de Falco-binary en out-of-the-box werkt dankzij CO-RE (Compile Once — Run Everywhere). Geen header-bestanden of compilers nodig. Gewoon configureren en gaan:

# Configureer Falco om modern_ebpf te gebruiken
# Bewerk /etc/falco/falco.yaml
engine:
  kind: modern_ebpf
  modern_ebpf:
    buf_size_preset: 4  # Ring buffer grootte (1-8, hoger = meer geheugen)
# Start Falco met de modern eBPF driver
sudo systemctl enable --now falco

# Controleer of Falco correct draait
sudo systemctl status falco

# Bekijk realtime alerts
sudo journalctl -u falco -f

Ingebouwde beveiligingsregels

Falco wordt geleverd met een flinke set standaardregels die veelvoorkomende aanvalspatronen detecteren. Zo worden onder andere de volgende zaken direct opgepikt:

  • Shell-sessies gestart in containers
  • Schrijfacties naar /etc/passwd, /etc/shadow of /etc/sudoers
  • Uitvoering van netwerk-tools als curl, wget of nc in onverwachte contexten
  • Privilege-escalatie via setuid of setgid
  • Ongeautoriseerde uitgaande netwerkverbindingen

Best indrukwekkend voor een standaardconfiguratie, als je het mij vraagt.

Custom regels schrijven

Maar je wilt natuurlijk ook je eigen detectieregels schrijven voor specifieke dreigingen in jouw omgeving. Hier zijn een paar voorbeelden die ik in de praktijk erg nuttig heb gevonden:

# /etc/falco/rules.d/custom-rules.yaml

# Detecteer cryptocurrency mining processen
- rule: Crypto Mining Detected
  desc: Detecteert bekende cryptocurrency mining processen
  condition: >
    spawned_process and
    (proc.name in (xmrig, minerd, cpuminer, cgminer, bfgminer) or
     proc.cmdline contains "stratum+tcp" or
     proc.cmdline contains "stratum+ssl")
  output: >
    Crypto mining proces gedetecteerd
    (user=%user.name command=%proc.cmdline container=%container.id
     image=%container.image.repository)
  priority: CRITICAL
  tags: [cryptomining, host, container]

# Detecteer ongeautoriseerde SSH-sleutel toevoegingen
- rule: SSH Authorized Keys Modified
  desc: Detecteert wijzigingen aan authorized_keys bestanden
  condition: >
    open_write and
    fd.name endswith "authorized_keys"
  output: >
    SSH authorized_keys bestand gewijzigd
    (user=%user.name file=%fd.name command=%proc.cmdline)
  priority: WARNING
  tags: [ssh, persistence, mitre_persistence]

# Detecteer reverse shells
- rule: Reverse Shell Detected
  desc: Detecteert pogingen tot het opzetten van een reverse shell
  condition: >
    spawned_process and
    ((proc.name = "bash" and proc.cmdline contains "/dev/tcp") or
     (proc.name = "nc" and proc.args contains "-e") or
     (proc.name = "python" and proc.cmdline contains "socket") or
     (proc.name = "perl" and proc.cmdline contains "socket"))
  output: >
    Mogelijke reverse shell gedetecteerd
    (user=%user.name command=%proc.cmdline connection=%fd.name)
  priority: CRITICAL
  tags: [reverse_shell, mitre_execution]
# Herlaad Falco om de nieuwe regels te activeren
sudo systemctl restart falco

# Test een regel door een gesimuleerde alert te triggeren
echo "test" | sudo tee -a /root/.ssh/authorized_keys.test

# Bekijk of de alert verschijnt
sudo journalctl -u falco --since "1 minute ago" | grep authorized

Alerts routeren met Falcosidekick

Alerts in je journallog zijn prima voor debugging, maar in productie wil je ze ergens heen sturen. Falcosidekick routeert alerts naar meer dan 50 bestemmingen — van Slack tot Elasticsearch en alles daartussenin:

# Installeer Falcosidekick
sudo apt-get install -y falcosidekick

# Configureer output naar Slack en Elasticsearch
# /etc/falcosidekick/config.yaml
slack:
  webhookurl: "https://hooks.slack.com/services/JOUW/WEBHOOK/URL"
  channel: "#security-alerts"
  minimumpriority: "warning"

elasticsearch:
  hostport: "https://elasticsearch.intern:9200"
  index: "falco-alerts"
  minimumpriority: "notice"

eBPF Zelf Beveiligen: Hardening Best Practices

Dit is een punt dat vaak over het hoofd wordt gezien: eBPF is een krachtig gereedschap, maar het is tegelijkertijd een potentiële aanvalsvector. Als een aanvaller eBPF-programma's kan laden, heeft hij directe toegang tot de kernel. Niet ideaal, om het zacht uit te drukken.

Daarom is het hardenen van eBPF zelf minstens zo belangrijk als de tools die je erop draait.

Onbevoegde toegang beperken

# Controleer de huidige instelling
sysctl kernel.unprivileged_bpf_disabled

# Schakel eBPF uit voor onbevoegde gebruikers (AANBEVOLEN)
sudo sysctl -w kernel.unprivileged_bpf_disabled=1

# Maak de instelling permanent
echo "kernel.unprivileged_bpf_disabled=1" | sudo tee /etc/sysctl.d/99-ebpf-hardening.conf

# Beperk ook de JIT-compiler
sudo sysctl -w net.core.bpf_jit_harden=2
echo "net.core.bpf_jit_harden=2" | sudo tee -a /etc/sysctl.d/99-ebpf-hardening.conf

# Pas alle wijzigingen toe
sudo sysctl --system

Capabilities beperken

Sinds Linux 5.8 kun je fijnmazigere capabilities gebruiken in plaats van het (nogal brede) CAP_SYS_ADMIN:

  • CAP_BPF: Basisrecht om eBPF-programma's en maps te laden
  • CAP_PERFMON: Nodig voor tracing-programma's
  • CAP_NET_ADMIN: Nodig voor netwerk-gerelateerde eBPF-programma's
# Voorbeeld: draai Tetragon met minimale capabilities
# In het systemd service-bestand:
[Service]
CapabilityBoundingSet=CAP_BPF CAP_PERFMON CAP_SYS_RESOURCE CAP_SYS_PTRACE
AmbientCapabilities=CAP_BPF CAP_PERFMON CAP_SYS_RESOURCE CAP_SYS_PTRACE
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true

eBPF-programma's auditen

Je wilt uiteraard ook weten welke eBPF-programma's er op je systeem draaien. Dat doe je zo:

# Bekijk alle momenteel geladen eBPF-programma's
sudo bpftool prog list

# Voorbeeld output:
# 42: tracing  name sensitive_file  tag abc123  gpl
#     loaded_at 2026-03-15T10:30:00+0000  uid 0
#     xlated 296B  jited 185B  memlock 4096B

# Bekijk details van een specifiek programma
sudo bpftool prog show id 42

# Inspecteer geladen eBPF-maps
sudo bpftool map list

# Monitor wie eBPF-programma's laadt via auditd
sudo auditctl -a always,exit -F arch=b64 -S bpf -k ebpf_activity

# Bekijk het auditlog
sudo ausearch -k ebpf_activity

Integratie met Je Bestaande Beveiligingsstack

eBPF-gebaseerde tools werken het beste als onderdeel van een bredere beveiligingsarchitectuur. Geen enkele tool lost alles op (ondanks wat de marketing soms belooft). Hier is hoe je Tetragon en Falco kunt integreren met veelgebruikte Linux-beveiligingstools.

Tetragon + Wazuh

Als je al Wazuh gebruikt voor SIEM en inbraakdetectie, kun je Tetragon-events naar Wazuh doorsturen voor correlatie en alerting. De setup is verrassend eenvoudig:

# Schrijf Tetragon-events naar een logbestand dat Wazuh monitort
sudo tetra getevents -o json >> /var/log/tetragon/events.json &

# Configureer Wazuh om het logbestand te monitoren
# /var/ossec/etc/ossec.conf
<localfile>
  <log_format>json</log_format>
  <location>/var/log/tetragon/events.json</location>
</localfile>

Falco + nftables

Dit is een combinatie waar ik persoonlijk erg enthousiast over ben: Falco-detectie koppelen aan automatische nftables-blokkering voor actieve respons. Dus als Falco iets verdachts ziet, wordt het IP meteen geblokkeerd:

#!/bin/bash
# /usr/local/bin/falco-response.sh
# Automatisch IP-adressen blokkeren bij kritieke Falco-alerts

ALERT_IP=$(echo "$1" | jq -r '.output_fields["fd.sip"]')
PRIORITY=$(echo "$1" | jq -r '.priority')

if [ "$PRIORITY" = "Critical" ] && [ -n "$ALERT_IP" ]; then
    logger "Falco response: blokkeer IP $ALERT_IP vanwege kritieke alert"
    nft add element inet filter blocklist { "$ALERT_IP" }
fi

Gecombineerd overzicht

Een volledige beveiligingsstack met eBPF-tools ziet er in 2026 ongeveer als volgt uit:

  • Tetragon: Kernel-level procesmonitoring en beleidshandhaving
  • Falco: Regelgebaseerde runtime detectie met uitgebreide alerting
  • Wazuh: SIEM, logcorrelatie en compliance-rapportage
  • nftables: Netwerk-level firewalling en automatische blokkering
  • Lynis/OpenSCAP: Periodieke compliance-audits en hardening-checks

Samen vormen deze tools meerdere verdedigingslagen die elkaar aanvullen. Geen enkele laag is waterdicht, maar gestapeld krijg je een behoorlijk stevige opstelling.

Prestaties en Kernelvereisten

Een vraag die ik regelmatig krijg: wat kost eBPF-gebaseerde security eigenlijk aan systeemprestaties? Het korte antwoord: minder dan je denkt.

  • CPU-overhead: Typisch minder dan 1% op matig actieve systemen. eBPF-programma's draaien in de kernel en filteren events voordat ze naar userspace worden gestuurd, dus er is geen dure context-switching.
  • Geheugengebruik: Tetragon gebruikt standaard zo'n 50-100 MB RAM. Falco met modern_ebpf zit in dezelfde range, afhankelijk van de geconfigureerde ring buffer grootte.
  • Kernel-compatibiliteit: Voor volledige functionaliteit wordt kernel 5.10+ aanbevolen. De meeste moderne distributies (Ubuntu 22.04+, RHEL 9+, Debian 12+) voldoen hier gewoon aan.

Controleer de kernelondersteuning op je eigen systeem:

# Controleer je kernelversie
uname -r

# Controleer BTF-ondersteuning
ls /sys/kernel/btf/vmlinux 2>/dev/null && echo "BTF: OK" || echo "BTF: niet beschikbaar"

# Controleer BPF-ondersteuning in de kernelconfiguratie
grep -E "CONFIG_BPF|CONFIG_DEBUG_INFO_BTF" /boot/config-$(uname -r) 2>/dev/null

# Tetragon kernel feature probe
sudo tetra probe

Veelgestelde Vragen

Wat is het verschil tussen eBPF-gebaseerde security en traditionele IDS-systemen?

Traditionele IDS-systemen zoals Snort werken voornamelijk op netwerkniveau en analyseren verkeer dat al door de kernel is verwerkt. eBPF-gebaseerde tools als Tetragon en Falco opereren in de kernel zelf, waardoor ze systeemaanroepen, procesgedrag en bestandstoegang direct kunnen monitoren. Je ziet dus niet alleen wat er over het netwerk gaat, maar ook wat er op het systeem zelf gebeurt. En doordat events in de kernel worden gefilterd voordat ze naar userspace gaan, is de overhead ook aanzienlijk lager.

Kan eBPF SELinux of AppArmor vervangen?

Kort antwoord: nee. En dat zou je ook niet willen. eBPF en MAC-frameworks als SELinux en AppArmor zijn complementair. SELinux en AppArmor bieden preventieve toegangscontrole — ze blokkeren acties op basis van voorgedefinieerde beleidsregels. eBPF-tools bieden detectieve en responsieve beveiliging — ze detecteren afwijkend gedrag en kunnen daarop reageren. De ideale opstelling combineert beide: AppArmor of SELinux als preventieve laag, met Tetragon of Falco als detectielaag die verdacht gedrag oppikt dat door het beleid glipt.

Is eBPF veilig om in productie te draaien?

Ja, absoluut — mits correct geconfigureerd. De kernel-verifier garandeert dat eBPF-programma's niet kunnen crashen, in oneindige lussen terechtkomen, of willekeurig geheugen benaderen. Bedrijven als Meta, Google en Cloudflare draaien eBPF op grote schaal in productie. Het belangrijkste is om kernel.unprivileged_bpf_disabled=1 in te stellen zodat alleen root eBPF-programma's kan laden, en om net.core.bpf_jit_harden=2 te activeren voor bescherming tegen Spectre-achtige aanvallen.

Welke Linux-kernelversie heb ik minimaal nodig?

Voor basale eBPF-functionaliteit is kernel 4.19 voldoende. Maar voor volledige security-functionaliteit (inclusief BTF, CO-RE, en fijnmazige capabilities als CAP_BPF) wordt kernel 5.10 of hoger aanbevolen. Moderne distributies als Ubuntu 22.04 (kernel 5.15), RHEL 9 (kernel 5.14) en Debian 12 (kernel 6.1) voldoen hier ruim aan.

Kan ik Tetragon en Falco tegelijkertijd draaien?

Zeker. Beide tools kunnen prima naast elkaar draaien — ze gebruiken afzonderlijke eBPF-programma's en interfereren niet met elkaar. Een opstelling die ik vaak tegenkom (en zelf ook aanraad) is Tetragon voor gedetailleerde procestracing en beleidshandhaving, en Falco voor brede regelgebaseerde detectie met integratie naar alerting-platformen via Falcosidekick. De gecombineerde CPU-overhead blijft in de praktijk onder de 2%.

Over de Auteur Editorial Team

Our team of expert writers and editors.

Gerelateerde Artikelen