eBPF para Segurança: Falco, Tetragon e Runtime Security Moderno

O que é eBPF e por que importa em segurança

eBPF começou a vida como Extended Berkeley Packet Filter — uma extensão do mecanismo clássico de filtragem de pacotes BSD para o kernel Linux. Hoje, o "BPF" virou marca: a tecnologia transcendeu redes e se tornou uma infraestrutura geral de programação de kernel. Programas eBPF rodam dentro de uma máquina virtual no espaço do kernel, em pontos de attachment bem definidos, sob a tutela de um verificador estático.

O verificador é a peça que separa eBPF de um kernel module tradicional: ele rejeita programas que possam fazer loop infinito, acessar memória inválida, vazar ponteiros para userspace ou executar instruções perigosas. Se o programa passa, o kernel o carrega e o executa em velocidade próxima de nativa via JIT. Se não passa, o programa simplesmente não é aceito — não há a possibilidade clássica de um módulo mal escrito travar o host.

Para segurança, três propriedades fazem do eBPF a tecnologia de base do stack moderno de runtime detection:

• Visibilidade sem módulo de kernel. Você instrumenta syscalls, eventos de rede, operações de arquivo, hooks de cgroups e LSM sem compilar um .ko e sem expor a superfície de risco que um módulo carrega.
• Overhead tipicamente baixo. A lógica de filtragem roda no kernel, perto dos eventos, evitando o custo de syscalls em userspace, cópia de buffers e context switches. Filtros bem escritos descartam eventos irrelevantes antes que cheguem ao espaço do usuário.
• Portabilidade via CO-RE. O modelo Compile Once — Run Everywhere, suportado por BTF (BPF Type Format) presente em kernels modernos, permite que um único binário rode em distribuições e versões variadas — algo impensável com módulos de kernel tradicionais.

O resultado é uma combinação inédita: telemetria profunda, integrada ao kernel, portátil e com baixo risco operacional. Antes de eBPF, escolher entre essas propriedades era um trilema. Hoje, ferramentas como Falco entregam as três simultaneamente.

Capabilities relevantes: kprobes, tracepoints, XDP, BPF-LSM

eBPF não é um único hook — é um catálogo de pontos de attachment. Para segurança, os mais relevantes são:

• kprobes / kretprobes. Permitem anexar um programa eBPF a praticamente qualquer função do kernel, na entrada (kprobe) ou no retorno (kretprobe). Flexibilidade máxima, mas frágil entre versões — a função pode mudar de nome, assinatura ou ser inlineada.
• uprobes / uretprobes. Equivalentes em userspace — instrumentam funções de binários ou bibliotecas (libssl, libc) sem modificá-los. Úteis para detectar uso anômalo de criptografia, chamadas a funções perigosas em runtime, etc.
• tracepoints. Pontos de instrumentação estáveis declarados pelo próprio kernel (ex.: sched:sched_process_exec, syscalls:sys_enter_execve). São a interface preferida quando existe — não quebram entre versões.
• XDP (eXpress Data Path). Hook ultra-precoce no pipeline de rede, antes mesmo da pilha TCP/IP do kernel processar o pacote. Base de mitigação de DDoS e firewalls programáveis de alta performance.
• cgroup hooks. Permitem aplicar políticas (de rede, de sockets) por cgroup — perfeito para o modelo de container, onde cada Pod tem seu próprio cgroup.
• BPF-LSM (kernel 5.7+). Plugar programas eBPF nos hooks oficiais do Linux Security Module, ao lado de SELinux e AppArmor. Permite decisões de autorização (allow/deny) em pontos canônicos, com a robustez do framework LSM.

Essa diversidade explica por que diferentes ferramentas fazem escolhas distintas: Falco apoia-se predominantemente em tracepoints de syscalls; Tetragon mistura tracepoints, kprobes e BPF-LSM para detecção e enforcement; Tracee tem foco em eventos de syscall com pipeline de análise mais voltado a forensics.

Por que substitui auditd, kernel modules e LD_PRELOAD

Antes do eBPF amadurecer, runtime detection em Linux dependia de três caminhos imperfeitos:

O ganho mais subestimado é estabilidade. Em ambientes de produção sérios, um host derrubado por um kernel module mal comportado custa muito mais do que qualquer detecção avançada que ele entregue. eBPF, ao restringir o que um programa pode fazer via verificador, transforma a equação de risco.

Falco: o motor de regras CNCF

Falco nasceu na Sysdig em 2016, foi doado à CNCF e atingiu o status de graduated — sinal de maturidade comparável a Kubernetes e Prometheus. É hoje a referência open source de motor de regras para detecção runtime em Linux e containers.

Arquitetura e drivers

Falco lê uma stream de eventos do kernel e a confronta com um conjunto de regras declarativas. A stream é fornecida por um driver — e é aqui que a evolução do projeto fica visível:

• modern_bpf (atual padrão) — driver CO-RE, baseado em libbpf, sem necessidade de compilar nada no host. Funciona em kernels com suporte a BTF (kernels 5.8+ na prática). É a opção recomendada.
• ebpf (legacy) — driver eBPF baseado em bcc/llvm, requer toolchain no host. Mantido para compatibilidade com kernels mais antigos.
• kmod — módulo de kernel clássico. Ainda suportado para distros muito legadas (RHEL 7, alguns kernels sem BTF), porém deve ser última opção.

Regras YAML e contexto

A linguagem de regras do Falco é declarativa e legível por humanos. Uma regra clássica para detectar shell interativo dentro de container fica como:

- rule: Terminal shell in container
  desc: Shell interativo aberto dentro de container
  condition: spawned_process and container
             and shell_procs and proc.tty != 0
  output: Shell em container (user=%user.name container=%container.id
          command=%proc.cmdline)
  priority: WARNING
  tags: [container, shell, mitre_execution]

O conjunto base de regras cobre dezenas de casos de uso mapeados a táticas do MITRE ATT&CK — TA0002 Execution, TA0003 Persistence, TA0004 Privilege Escalation, TA0005 Defense Evasion. Detecções típicas:

• Shell interativo em container (exec inesperado em workload imutável);
• Escrita em diretórios sensíveis (/etc, /usr/bin) dentro de container;
• Mount de volume privilegiado ou de socket Docker;
• Modificação de arquivo binário pelo runtime;
• Conexão de rede para destino conhecido como malicioso (consumo de IoC);
• Carregamento de kernel module;
• Detecção de exec de cryptominer conhecido.

Outputs e ecossistema

Falco emite eventos via stdout, syslog, gRPC e HTTP. O componente falcosidekick faz fan-out: recebe os alertas e os encaminha para Slack, Microsoft Teams, PagerDuty, Splunk HEC, Microsoft Sentinel, Elastic, Loki, Kafka, AWS SQS, AlertManager, OpenSearch, S3 e dezenas de outros destinos. Para K8s, há ainda falcosidekick-ui (dashboard simples) e o operador falco-talon para resposta automática (kill pod, isolar network policy).

Falco brilha em detecção generalista de host e container. Ele não tem ambição nativa de enforcement — quando alerta, alerta. Enforcement, quando desejado, vem por integração externa (falco-talon, controladores próprios).

Cilium Tetragon: detecção e enforcement nativos em K8s

Tetragon é parte da família Cilium — projeto originário da Isovalent (adquirida pela Cisco) — e tem foco explícito em segurança runtime para Kubernetes, com awareness profundo de identidade e namespaces. Não é fork nem derivativo de Falco: é uma implementação independente de tracing eBPF, com filosofia distinta.

TracingPolicy: política como CRD

O modelo de configuração de Tetragon são as TracingPolicy — Custom Resources do Kubernetes que descrevem quais eventos observar, quais filtros aplicar e quais ações tomar. Exemplo simplificado para detectar e bloquear escrita em /etc/shadow:

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: block-shadow-write
spec:
  kprobes:
  - call: "security_file_open"
    syscall: false
    args:
    - index: 0
      type: "file"
    selectors:
    - matchArgs:
      - index: 0
        operator: "Equal"
        values:
        - "/etc/shadow"
      matchActions:
      - action: Sigkill

A propriedade decisiva é matchActions. Tetragon pode detectar e agir: enviar um SIGKILL ao processo (via bpf_send_signal()), sobrescrever o retorno da syscall com erro (override action), ou apenas registrar o evento. Isso transforma a categoria — sai de "detection" e entra em "prevention". O preço é cuidado: regra mal calibrada em modo enforcement pode derrubar workloads legítimos.

Process tree e contexto K8s

Tetragon mantém uma árvore completa de processos do host, com pais, filhos e contexto. Quando emite um evento, anexa: pod name, namespace, container ID, labels, identidade Cilium (se houver), binário ancestral, hash. Para um investigador, é a diferença entre "alguém rodou wget" e "o pod frontend-7f9 no namespace shop, identidade app=frontend, executou wget a partir de sh -c invocado por nginx".

Integração com Cilium

Em clusters que já rodam Cilium como CNI, Tetragon reaproveita a identidade de workload, a observabilidade Hubble e o pipeline de policy. Em clusters com outro CNI, Tetragon funciona standalone — não exige Cilium. Mas a sinergia justifica a escolha do par em greenfield de plataforma.

Tracee: forensics e detecção orientada a eventos

Tracee, da Aqua Security, é uma ferramenta open source de runtime tracing e detection com personalidade própria: forte ênfase em forensics, captura rica de artefatos, e linguagem de assinaturas independente do motor (suporta regras em Go, Rego/OPA e tem histórico de suporte a Lua). Tracee instrumenta o kernel via eBPF (tracepoints e raw_tracepoints) e emite eventos estruturados.

O que distingue Tracee:

• Captura de artefatos. Além de logar o evento, Tracee pode capturar o binário executado, memória em execução, sockets abertos — útil para análise pós-incidente sem precisar voltar ao host.
• Assinaturas separadas do core. O motor emite eventos; um runtime de assinaturas (signature engine) avalia-os contra regras. Permite escrever detecções em código (Go) ou política declarativa (Rego).
• Foco em behaviors complexos. Detecções multi-step encadeadas — por exemplo, processo que faz memfd_create seguido de execve a partir de file descriptor (técnica fileless clássica).

Comunidade menor que Falco, sem o status CNCF, mas com tração crescente em times de detection engineering que querem expressividade além de YAML.

Comparativo prático: quando usar cada um

Os três projetos convergem na base tecnológica (eBPF) e divergem em filosofia, modelo de configuração e profundidade de integração com Kubernetes. Resumo decisório:

Recomendações pragmáticas:

Combinações fazem sentido. Uma arquitetura comum em organizações grandes: Falco como motor de detecção transversal (telemetria para SIEM, regras CNCF mantidas pela comunidade) + Tetragon em namespaces críticos (PCI, dados sensíveis) onde enforcement é desejado. Tracee entra quando o time de DFIR precisa de capacidade forense específica.

Limitações reais e armadilhas

eBPF não é mágica — e ferramentas baseadas nele herdam três classes de problemas que devem entrar no plano de capacity e gestão de risco:

Pipeline típico: do kernel ao SIEM

O fluxo end-to-end de uma detecção runtime em um stack maduro tem cinco estágios:

1. Coleta no kernel — Falco (driver modern_bpf) ou Tetragon (eBPF nativo) instrumentam pontos relevantes (tracepoints de syscall, LSM hooks, kprobes selecionadas).
2. Filtragem e correlação no agente — eventos irrelevantes são descartados ainda no kernel; eventos relevantes recebem enrichment com contexto de container/pod/namespace.
3. Fan-out (falcosidekick / Hubble exporters) — o evento é roteado a múltiplos destinos conforme severidade: SIEM corporativo, datalake, canal de chat, ticketing.
4. Normalização e enriquecimento — em pipelines maduros, Vector ou Logstash convertem para um schema padrão (ECS, OCSF), agregam tags de business, anexam owner do serviço, mapeiam a MITRE.
5. Detecção e resposta no SIEM/SOAR — Splunk, Sentinel, Elastic ou similar correlacionam com outras fontes (identidade, EDR, cloud audit logs) e disparam playbook de resposta — automatizada para casos baixa-severidade, com humano no loop para alta.

A escolha de cada peça depende do contexto: para times que já operam Splunk maduro, o caminho natural é Falco → falcosidekick (Splunk HEC) → ES com correlação de Enterprise Security. Em ambientes Microsoft-first, o destino é Sentinel via conector falcosidekick. Em arquiteturas observability-first, o pipeline alternativo é Falco → Loki → Grafana, com alerting em Grafana ou AlertManager.

Para a comparação ampla entre stacks de detecção e resposta — incluindo onde runtime security se encaixa frente a EDR e XDR — veja o comparador EDR vs XDR vs MDR. Para o contexto de segurança de containers e cluster, o artigo Kubernetes & Container Security traz o panorama de controles complementares, e o de DevSecOps aborda o lado de pipeline.

Perguntas frequentes

Conclusão

eBPF deixou de ser feature obscura de kernel e virou base do stack moderno de runtime security em Linux e Kubernetes. Para times de SecOps e plataforma, isso significa que finalmente é possível ter visibilidade profunda, portabilidade e estabilidade simultaneamente — algo que kernel modules, auditd e LD_PRELOAD nunca entregaram juntos.

O ecossistema oferece três projetos open source com personalidades complementares. Falco é a aposta segura para detecção generalista, com regras maduras, comunidade ampla e integração trivial com SIEM. Cilium Tetragon é a escolha quando enforcement Kubernetes-native está na mesa — bloqueio em kernel, identidade Cilium, TracingPolicy via GitOps. Tracee brilha em times de detection engineering avançado que querem expressar lógica complexa em código e capturar artefatos para forense.

O caminho prático de adoção é incremental: comece com Falco em modo detecção em todos os nós, calibre regras durante 4–8 semanas, integre ao SIEM, mapeie a MITRE ATT&CK, mensure ruído. Quando o motor de detecção estiver estável, avalie Tetragon para enforcement seletivo em workloads críticos. Tracee entra sob demanda específica de DFIR. Em paralelo, mantenha disciplina de versionamento de regras, testes em pré-prod e tuning contínuo — eBPF não substitui processo, apenas dá ao processo uma base técnica muito melhor.

Referências

• eBPF Foundation. What is eBPF? — Project hub e documentação. Disponível em: ebpf.io.
• The Linux Kernel Documentation. BPF and XDP Reference Guide. Disponível em: docs.kernel.org/bpf.
• The Falco Project (CNCF Graduated). Falco Documentation, drivers e regras. Disponível em: falco.org/docs.
• Cilium / Isovalent. Tetragon — Security Observability and Runtime Enforcement. Disponível em: tetragon.io; código em github.com/cilium/tetragon.
• Aqua Security. Tracee — Runtime Security and Forensics using eBPF. Disponível em: github.com/aquasecurity/tracee.
• MITRE Corporation. ATT&CK for Enterprise — Tactics and Techniques. Disponível em: attack.mitre.org.
• CNCF. Cloud Native Landscape — Runtime Security category. Disponível em: landscape.cncf.io.
• Brendan Gregg. BPF Performance Tools — Linux System and Application Observability. Addison-Wesley, 2019.