eBPF-baserad runtime-säkerhet på Linux: Guide till Falco och Tetragon

Varför traditionell övervakning inte räcker längre

Hotbilden mot Linux-system har förändrats rejält under 2026. Angripare jobbar allt oftare på kärnnivå — rootkits som gömmer processer, fillös skadlig kod som exekveras helt i minnet, och living-off-the-land-tekniker som missbrukar helt vanliga systemverktyg. Traditionella övervakningsverktyg i användarrymden är ofta helt blinda för den här typen av aktivitet. Och tunga kärnmoduler? De riskerar systemstabiliteten.

Så, vad gör man?

eBPF (Extended Berkeley Packet Filter) erbjuder en tredje väg: sandlådebaserade program som körs direkt i Linux-kärnan med minimal overhead och full insyn. Det här är inte längre någon framtidsteknologi — 2025 meddelade AWS att EKS använder Cilium (byggt på eBPF) som standard-CNI. eBPF har helt enkelt lämnat forskningslabbet och blivit en del av produktionsinfrastrukturen.

I den här guiden går vi igenom hur du praktiskt implementerar eBPF-baserad runtime-säkerhet med de två ledande verktygen: Falco för regelbaserad detektion och Tetragon för kärnbaserad tillämpning. Du får konkreta konfigurationer, fungerande kodexempel och en tydlig strategi för att kombinera båda verktygen i din egen miljö.

Så fungerar eBPF för säkerhetsövervakning

Innan vi dyker in i verktygen behöver vi förstå vad eBPF faktiskt gör under huven. I korthet: eBPF låter dig köra anpassade program isolerat i en exekveringsmiljö inuti kärnan — den så kallade eBPF-virtualmaskinen. Processen ser ut ungefär så här:

1. Utvecklaren skriver programmet — vanligtvis i en begränsad delmängd av C.
2. Koden kompileras till bytekod med hjälp av LLVM/Clang.
3. En systemhändelse (hook) identifieras — till exempel en tracepoint, kprobe eller uprobe.
4. Programmet laddas in i kärnan via ett eBPF-bibliotek.
5. Verifieraren kontrollerar programmet — den simulerar flödet och säkerställer att programmet alltid terminerar, inte läser godtyckligt minne, och inte skapar dödlägen.
6. JIT-kompilatorn översätter bytekoden till maskinspecifika instruktioner för maximal prestanda.

Exekveringsmodellen är helt händelsedriven. eBPF-program kopplas till hookpunkter i kärnan och körs automatiskt vid en händelse — det kan vara ett systemanrop, en nätverkshändelse eller en filåtkomst.

Vad kan eBPF fånga?

• Systemanrop (syscalls): Övervakning av execve, open, connect, setuid och andra känsliga anrop.
• Nätverksaktivitet: Realtidsanalys av paket, anslutningar och DNS-förfrågningar.
• Filåtkomst: Detektering av läsning och skrivning till känsliga filer som /etc/shadow eller /etc/passwd.
• Privilegieeskalering: Övervakning av UID-övergångar och kapabilitetsförändringar.
• Beteendekorrelering: Kombination av signaler över hela processträdet för att identifiera komplexa attackmönster.

Jämfört med traditionella verktyg som Tripwire — som arbetar schemabaserat och helt missar filer som skapas och raderas mellan skanningar — låter eBPF dig övervaka filöppningar i realtid. Det är en ganska dramatisk skillnad, ärligt talat.

Falco: Regelbaserad detektion i realtid

Falco är ett CNCF-inkubationsprojekt skapat av Sysdig, och det fungerar i princip som en säkerhetskamera för dina Linux-system och Kubernetes-kluster. Falco använder eBPF-prober (eller en kärnmodul på äldre kärnor) för att fånga upp och analysera varje systemanrop. Det ger djup insyn i container- och värdaktivitet utan att du behöver modifiera applikationskod eller containerimages.

Installation på Kubernetes med Helm

Den rekommenderade installationsmetoden för Kubernetes-miljöer är via Helm:

# Lägg till Falco Helm-repository
helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update

# Produktionsklar installation med modern eBPF-drivrutin
helm install falco falcosecurity/falco \
  --namespace falco \
  --create-namespace \
  --set driver.kind=modern_ebpf \
  --set collectors.containerd.enabled=true \
  --set collectors.docker.enabled=false \
  --set falco.json_output=true \
  --set falco.json_include_output_property=true \
  --set falco.log_stderr=true \
  --set falco.log_syslog=false

# Vänta tills alla poddar är redo
kubectl wait pods --for=condition=Ready --all -n falco

Parametern driver.kind=modern_ebpf är viktig här — den använder den moderna eBPF-drivrutinen istället för kärnmodulen, vilket ger bättre prestanda och säkerhet. Det är helt klart den väg man vill gå i 2026.

Så fungerar Falco-regler

Falco identifierar misstänkt beteende baserat på YAML-regler som definierar villkor, utdata och prioritetsnivåer. Reglerna bygger på tre huvudkomponenter: lists (listor med värden), macros (återanvändbara villkor) och rules (själva detektionslogiken).

Detektera skalexekvering i containrar

En av de vanligaste attackindikatorerna (och något jag själv har sett i produktionsmiljöer) är när ett skal öppnas inuti en container som normalt inte borde ha interaktiv åtkomst:

# /etc/falco/rules.d/custom_rules.yaml

# Definiera kända skal
- list: shell_binaries
  items: [bash, sh, zsh, ksh, csh, tcsh, dash]

# Macro för containermiljö
- macro: container
  condition: container.id != host

# Macro för skalexekvering
- macro: spawned_shell
  condition: evt.type = execve and proc.name in (shell_binaries)

# Detektionsregel
- rule: Skal startat i container
  desc: Detekterar skalexekvering inuti en container (potentiell kompromittering)
  condition: spawned_shell and container and proc.tty != 0
  output: >
    Skal startat i container
    (anvandare=%user.name container=%container.name
    image=%container.image.repository
    skal=%proc.name foralder=%proc.pname
    kommando=%proc.cmdline)
  priority: WARNING
  tags: [container, shell, mitre_execution]

Detektera web shells och kryptomining

Nu blir det lite mer intressant. Mer avancerade regler kan identifiera specifika attackmönster som web shells och kryptovalutamining:

# Detektera web shell-exekvering
- rule: Web Shell detekterad
  desc: Detekterar web shell-exekveringsmoenster i webbservrar
  condition: >
    spawned_process and container.image.repository contains nginx
    and (proc.name in (sh, bash, zsh, dash)
    and (proc.aname in (nginx, httpd, apache2)
    or proc.cmdline contains "wget"
    or proc.cmdline contains "curl"))
  output: >
    Mojlig web shell detekterad
    (foralder=%proc.aname kommando=%proc.cmdline
    container=%container.name)
  priority: CRITICAL
  tags: [webshell, attack, mitre_persistence]

# Detektera kryptovalutamining
- rule: Kryptovalutamining detekterad
  desc: Detekterar kryptovaluta-mining i containrar
  condition: >
    spawned_process and container
    and (proc.name in (xmrig, ethminer, minerd, cpuminer)
    or proc.cmdline contains "stratum+tcp"
    or proc.cmdline contains "cryptonight")
  output: >
    Kryptovalutamining detekterad
    (kommando=%proc.cmdline container=%container.name
    image=%container.image.repository)
  priority: CRITICAL
  tags: [cryptomining, malware]

Detektera kubectl exec via auditloggar

Falco kan även övervaka Kubernetes-auditloggar för att fånga misstänkt klusteradministration. Det här är väldigt användbart för att se vem som gör vad i klustret:

# Detektera kubectl exec via Kubernetes audit-loggar
- rule: Kubectl Exec detekterad
  desc: Detekterar kubectl exec-kommandon via auditloggar
  condition: >
    kevt and ka.verb = create
    and ka.target.resource = pods
    and ka.target.subresource = exec
  output: >
    Kubectl exec (anvandare=%ka.user.name
    pod=%ka.target.name
    namnrymd=%ka.target.namespace)
  priority: NOTICE
  source: k8s_audit
  tags: [kubernetes, exec, mitre_execution]

Falcosidekick: Från detektion till åtgärd

Att köra Falco med bara loggning till stdout är i princip värdelöst i produktion — det kan vi nog vara ärliga om. Falcosidekick kopplar ihop Falcos detektioner med dina befintliga verktyg: Slack, PagerDuty, SIEM-system, eller till och med automatiserade Kubernetes-åtgärder som att terminera komprometterade poddar.

# Aktivera Falcosidekick med webbgränssnitt
helm upgrade --namespace falco falco falcosecurity/falco \
  --set falcosidekick.enabled=true \
  --set falcosidekick.webui.enabled=true

# Verifiera att Falcosidekick körs
kubectl get pods -n falco

# Åtkomst till webbgränssnittet (port-forward)
kubectl port-forward svc/falco-falcosidekick-ui -n falco 2802:2802

Tetragon: Kärnbaserad tillämpning i realtid

Tetragon är Cilium-projektets eBPF-baserade säkerhetsverktyg för observerbarhet och runtime-tillämpning. Och här kommer den stora skillnaden mot Falco: Tetragon kan inte bara detektera attacker — den kan blockera dem i realtid, direkt i kärnan, innan skadan är skedd.

Tänk på det så här: Falco fungerar som en övervakningskamera som larmar efter att något har hänt. Tetragon fungerar som en vakt som faktiskt stoppar den skadliga handlingen mitt i utförandet. Ganska stor skillnad.

Installation på Kubernetes

# Lägg till Cilium Helm-repository
helm repo add cilium https://helm.cilium.io
helm repo update

# Installera Tetragon
helm install tetragon cilium/tetragon -n kube-system

# Vänta tills DaemonSet är redo
kubectl rollout status -n kube-system ds/tetragon -w

# Verifiera installation
kubectl get pods -n kube-system -l app.kubernetes.io/name=tetragon

Den senaste versionen i skrivande stund är v1.6.0 (februari 2026).

TracingPolicy: Tetragons policymotor

Tetragon använder TracingPolicy-CRD:er (Custom Resource Definitions) för att definiera exakt vilka kärnhändelser som ska övervakas och vilka åtgärder som ska vidtas. En TracingPolicy består av fyra delar:

• Hooks: Definierar vilka kärnfunktioner eller systemanrop som ska övervakas (kprobes, tracepoints).
• Arguments: Anger typer och detaljer om funktionsargument att fånga.
• Selectors: Filtrerar vilka händelser som utlöser policyn — specifika filsökvägar, processnamn eller argumentvärden.
• Actions: Definierar svar på matchade händelser, från loggning till verkställighetsåtgärder som Sigkill.

Övervaka åtkomst till känsliga filer

Följande policy övervakar all åtkomst till känsliga systemfiler och Kubernetes-hemligheter:

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: monitor-kansliga-filer
spec:
  kprobes:
  - call: "security_file_open"
    syscall: false
    args:
    - index: 0
      type: "file"
    selectors:
    - matchArgs:
      - index: 0
        operator: "Prefix"
        values:
        - "/etc/shadow"
        - "/etc/passwd"
        - "/etc/kubernetes/pki"
        - "/var/run/secrets/kubernetes.io"
      matchActions:
      - action: Post

# Applicera policyn
kubectl apply -f monitor-kansliga-filer.yaml

# Strömma händelser med tetra CLI
kubectl logs -n kube-system -l app.kubernetes.io/name=tetragon \
  -c export-stdout -f | tetra getevents -o compact

Blockera privilegieeskalering

Och här blir det riktigt kraftfullt. Den här policyn detekterar och blockerar försök till privilegieeskalering via setuid och setgid — processen dödas omedelbart med SIGKILL:

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: blockera-privilegieeskalering
spec:
  kprobes:
  - call: "sys_setuid"
    syscall: true
    args:
    - index: 0
      type: "int"
    selectors:
    - matchArgs:
      - index: 0
        operator: "Equal"
        values:
        - "0"
      matchActions:
      - action: Sigkill
        message: "Privilegieeskalering till root blockerad"
  - call: "sys_setgid"
    syscall: true
    args:
    - index: 0
      type: "int"
    selectors:
    - matchArgs:
      - index: 0
        operator: "Equal"
        values:
        - "0"
      matchActions:
      - action: Sigkill
        message: "Privilegieeskalering till root-grupp blockerad"

Förhindra containerutbrytning

Containerutbrytning via namnrymdmanipulering (setns) är en allvarlig attackvektor — och tyvärr inte så ovanlig som man kanske hoppas. Tetragon kan blockera sådana försök direkt:

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: forhindra-containerutbrytning
spec:
  kprobes:
  - call: "__x64_sys_setns"
    syscall: true
    args:
    - index: 0
      type: "int"
    - index: 1
      type: "int"
    selectors:
    - matchNamespaces:
      - namespace: Pid
        operator: NotIn
        values:
        - "host_ns"
      matchActions:
      - action: Sigkill

Detektera misstänkta binärer

Följande policy använder security_bprm_check-hooken för att övervaka exekvering av binärer som ofta används vid privilegieeskalering inuti containrar:

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: detektera-misstankta-binarers-exekvering
spec:
  kprobes:
  - call: "security_bprm_check"
    syscall: false
    args:
    - index: 0
      type: "linux_binprm"
    selectors:
    - matchBinaries:
      - operator: "In"
        values:
        - "/bin/su"
        - "/usr/bin/sudo"
        - "/usr/bin/passwd"
      matchNamespaces:
      - namespace: Pid
        operator: NotIn
        values:
        - "host_ns"
      matchActions:
      - action: Post

Falco kontra Tetragon: Vilken ska du välja?

Det här är den fråga alla ställer sig. Och svaret är kanske inte vad du förväntar dig — det är inte ett antingen-eller. Men låt oss jämföra verktygen ordentligt innan vi kommer dit.

Grundläggande filosofi

• Falco arbetar utanför systemanropets exekveringsväg. Det observerar händelser efter att de inträffat. Om någon kör chmod 777 /etc/shadow kan Falco detektera det — men bara efter att det redan har hänt.
• Tetragon fångar upp händelser under exekveringen. Hela processen med synkron övervakning, filtrering och tillämpning sker inom kärnan. Det eliminerar TOCTOU-attackvektorer (Time-of-Check-Time-of-Use), vilket är en rätt stor fördel.

Prestanda

• Falco lägger till ungefär 5–10 % overhead genom att parsa systemanrop i användarrymden.
• Tetragon körs med under 1 % overhead via eBPF-krokar direkt i kärnan — säkert nog för produktionsarbetsbelastningar.
• I benchmarks tillför Falco cirka 10 ms till svarstider medan Tetragon tillför 5–26 ms beroende på konfiguration.
• Tetragon är mest CPU-effektivt, medan Falco är mest minneseffektivt.

Kubernetes-integration

• Falco kräver manuellt arbete för att filtrera larm efter namnrymd och pod-etiketter.
• Tetragon förstår Kubernetes-etiketter och namnrymder inbyggt. Policyer kan riktas mot poddar baserat på etiketter som app: nginx utan extra kod — det bara fungerar.

Ekosystem och integrationer

• Falco har ett bredare ekosystem tack vare längre tid på marknaden — SIEM, Slack, webhooks, PagerDuty och ett stort bibliotek av färdiga regler.
• Tetragon erbjuder JSON-loggar och gRPC-endpoints men har (ännu) färre färdiga integrationer.

Sammanfattande jämförelse

Egenskap	Falco	Tetragon
Primär funktion	Detektion och larm	Detektion och tillämpning
Policyformat	YAML-regler	TracingPolicy CRD:er
Realtidsblockering	Nej	Ja (kärnnivå)
Kubernetes-medvetenhet	Ja	Djupt inbyggd
CPU-overhead	5–10 %	Under 1 %
Minne	Effektivt	Något högre
Ekosystem	Stort och moget	Växande
Kärnkrav	4.14+ (stöd för äldre via modul)	4.19+ med BTF

Kombinera Falco och Tetragon: Bästa praxis

Den bästa strategin just nu är faktiskt att använda båda verktygen tillsammans. De kompletterar varandra väldigt bra:

• Falco ger bred detektion med ett stort regelbibliotek och mogna integrationer mot SIEM och larmsystem.
• Tetragon ger Kubernetes-nativ tillämpning med realtidsblockering av de mest kritiska hoten.

Rekommenderad arkitektur

# 1. Installera Tetragon för enforcement
helm install tetragon cilium/tetragon -n kube-system

# 2. Installera Falco för bred detektion
helm install falco falcosecurity/falco \
  --namespace falco \
  --create-namespace \
  --set driver.kind=modern_ebpf \
  --set falcosidekick.enabled=true \
  --set falcosidekick.webui.enabled=true

# 3. Applicera Tetragon-policyer for kritiska hot
kubectl apply -f blockera-privilegieeskalering.yaml
kubectl apply -f forhindra-containerutbrytning.yaml
kubectl apply -f monitor-kansliga-filer.yaml

Strategisk uppdelning

En praktisk uppdelning som fungerat bra ser ut så här:

1. Tetragon hanterar kritiska blockeringar — privilegieeskalering, containerutbrytningar, åtkomst till känsliga filer. De här hoten kräver omedelbar åtgärd och får aldrig bara loggas.
2. Falco hanterar bred detektion — skalexekvering i containrar, ovanliga nätverksanslutningar, kryptomining, kubectl exec. Dessa händelser larmas via Falcosidekick till SIEM och larmkanaler.
3. Falcosidekick orkestrar allt — kopplar ihop utdata från båda verktygen till Slack, PagerDuty, Elasticsearch eller andra SIEM-system.

Begränsningar och säkerhetsöverväganden

eBPF-baserade verktyg är kraftfulla, men det vore oärligt att inte nämna deras begränsningar. Här är vad du behöver vara medveten om:

Kärnberoenden

• eBPF kräver Linux-kärna 4.14+ för grundläggande funktionalitet. Tetragon behöver 4.19+ med BTF-stöd (BPF Type Format) för bästa prestanda.
• Att köra eBPF kräver CAP_BPF eller CAP_SYS_ADMIN-privilegier. I strikt reglerade miljöer kan detta kräva ytterligare godkännanden.
• Tetragons Override-action kräver CONFIG_BPF_KPROBE_OVERRIDE i kärnkonfigurationen.

Attackyta mot eBPF

Det är viktigt att förstå att eBPF-baserade säkerhetsverktyg inte är immuna mot manipulation. Om en angripare lyckas ladda en kärnmodul — via root-åtkomst och avaktiverad Secure Boot — kan de modifiera kärnans beteende och selektivt störa vad eBPF-program kan se. eBPF-baserad övervakning ger djup insyn, men den förlitar sig i slutändan på kärnans integritet.

Tetragon försöker stoppa redan framgångsrika exploits från att utnyttja sina vinster, men post-exploiteringsdetektering är i händerna på angriparen om denne verkligen lägger ner ansträngning på att undvika detektionsmekanismerna. Inget verktyg är perfekt.

Praktiska råd

• Börja alltid i loggläge innan du aktiverar tillämpning. En alltför restriktiv policy kan (och kommer sannolikt) krascha applikationer om du inte har profilerat ordentligt.
• Profilera i testmiljö — verifiera att policyer inte blockerar legitim trafik innan produktionsrullning. Det här steget är inte valfritt.
• Kombinera med Secure Boot och signerade kärnmoduler för att skydda kärnans integritet.
• Kontrollera unprivileged_bpf_disabled — om denna kärnparameter är satt till 0 kan oprivilegierade användare köra eBPF-program, vilket öppnar en attackvektor du inte vill ha.

Vanliga frågor

Vad är skillnaden mellan eBPF och traditionella Linux-säkerhetsmoduler som SELinux?

SELinux och AppArmor tillhandahåller obligatorisk åtkomstkontroll (MAC) baserat på statiskt definierade policyer. eBPF erbjuder dynamisk, programmerbar övervakning och tillämpning som kan laddas och avladdas utan omstart. eBPF kan dessutom fånga kontextuell information — som hela processträdet, nätverksmetadata och Kubernetes-etiketter — som traditionella LSM:er helt saknar. I praktiken kompletterar de varandra: SELinux/AppArmor för grundläggande åtkomstkontroll och eBPF-verktyg för avancerad beteendeövervakning.

Kan jag använda Falco och Tetragon utan Kubernetes?

Ja, båda verktygen fungerar på vanliga Linux-värdar utan Kubernetes. Falco kan installeras direkt via pakethanterare (apt/yum) och Tetragon kan köras som en fristående binär. I icke-Kubernetes-miljöer förlorar du dock vissa funktioner — främst Kubernetes-medvetenhet i Tetragon och audit-loggar i Falco. För fristående Linux-servrar är Falco ofta det enklare valet tack vare sitt breda regelbibliotek.

Vilken Linux-kärnversion krävs?

Grundläggande eBPF-funktionalitet finns från kärna 4.14. Falcos moderna eBPF-drivrutin kräver 5.8+. Tetragon kräver 4.19+ med BTF-stöd, men för full funktionalitet rekommenderas 5.3+. De flesta moderna distributioner — Ubuntu 22.04+, RHEL 9+, Debian 12+ — levereras med tillräckligt nya kärnor, så det bör inte vara ett problem.

Hur påverkar eBPF-övervakning systemets prestanda?

eBPF-program körs med minimal overhead tack vare JIT-kompilering och exekvering direkt i kärnan. Tetragon filtrerar händelser i kärnan innan de når användarrymden, vilket genererar mindre data och använder färre resurser. I praktiken adderar Tetragon under 1 % CPU-overhead medan Falco kan lägga till 5–10 % på grund av syscall-parsning i användarrymden. Den exakta påverkan beror på arbetsbelastning och antal aktiva regler.

Uppfyller eBPF-baserad övervakning regulatoriska krav?

eBPF kan fånga systemhändelser som filåtkomst, processexekvering och systemanrop i realtid. Den kapaciteten är kritisk för revisioner som involverar systemintegritet eller detektering av insiderhot. eBPF kan hjälpa till att uppfylla krav på systemnivåövervakning i standarder som ISO 27001, PCI DSS och NIST 800-53. I kombination med Falcosidekick och SIEM-integration skapar du en komplett revisionskedja med bevis på kontinuerlig övervakning.