Detectar um invasor só depois que ele executa comandos dentro de um contêiner custa caro: escala de privilégios, mineração de criptomoedas e roubo de credenciais acontecem em segundos, não em horas. Equipes que operam Linux e Kubernetes precisam de telemetria no momento da execução, e a ação prioritária é levar a detecção para dentro do kernel com eBPF, em vez de depender apenas de logs de aplicação e varreduras periódicas. Duas ferramentas abertas dominam esse espaço: Falco, para alertas baseados em regras, e Cilium Tetragon, para observabilidade e bloqueio no próprio kernel. Este guia compara as duas e define uma rota de adoção com prioridades claras.

O problema da detecção tardia

Agentes tradicionais de segurança de host avaliam artefatos: arquivos, processos em execução e configurações. Em ambientes de contêiner isso chega atrasado demais. Um pod efêmero pode nascer, abrir um reverse shell e morrer antes de qualquer ciclo de varredura; um ataque fileless nunca deposita binário para análise offline; e um atacante com acesso ao nó consegue adulterar logs de userspace antes que eles cheguem ao SIEM. O resultado é um buraco estrutural de visibilidade entre o comprometimento inicial e a descoberta.

A resposta da engenharia defensiva é instrumentar o kernel. O eBPF permite executar código verificado dentro do kernel Linux, observando cada chamada de sistema, abertura de arquivo e conexão de rede sem pagar um context switch por evento. Essa telemetria só vira alerta acionável quando carrega contexto: qual pod, qual contêiner, qual imagem e qual identidade disparou o comportamento. É a mesma lógica que já move a identidade de serviço entre clusters e nuvens — saber quem agiu, e não apenas onde agiu.

Falco: alertas com regras de syscall

O Falco nasceu no Sysdig e hoje é um projeto graduado da Cloud Native Computing Foundation. A ferramenta funciona analisando chamadas de sistema do kernel Linux em tempo real: um driver baseado em eBPF captura os syscalls, um motor de regras avalia o fluxo e qualquer violação vira um alerta enriquecido com metadados do contêiner e do workload. O binário moderno já embute o driver de eBPF, o que elimina a compilação de módulo de kernel na maioria das distribuições atuais.

As regras padrão cobrem os sinais mais explorados em invasões reais: execução de shell dentro de contêiner, uso de contêiner privilegiado, escrita em diretórios sensíveis como /etc e /usr/bin, mudanças de namespace com setns, conexões de rede inesperadas e mutação de binários de autenticação como passwd e shadowconfig. Cada regra é um YAML declarativo, o que permite escrever detectores próprios para o comportamento específico de cada carga — por exemplo, alertar quando o binário da aplicação abre um shell que nunca deveria existir no seu perfil de execução.

A telemetria também não se limita ao kernel: o Falco estende a ingestão por plugins, o que abre a porta para correlacionar eventos de syscall com logs de auditoria de API de nuvem no mesmo motor de regras. Do ponto de vista operacional, porém, o Falco é uma escolha de detecção: ele avisa, mas não mata o processo. O alerta segue para SIEM, data lake ou webhook, e a decisão de resposta permanece com a plataforma de automação — um desenho seguro para quem está começando, porque falso positivo não derruba produção.

Tetragon: enforcement direto no kernel

O Cilium Tetragon parte do mesmo substrato de eBPF, mas muda a promessa: em vez de apenas reportar, ele aplica filtragem e política diretamente no kernel, evitando o custo de encaminhar cada evento para um agente em userspace e permitindo decisões em microssegundos. O motor não tem lista fixa de funções monitoradas: as tracing policies definem os pontos de gancho, os filtros e as ações, inclusive sobre argumentos e valores de retorno de funções internas do kernel.

A diferença prática aparece no enforcement. As tracing policies do Tetragon suportam ação imediata, enviando SIGKILL ao processo que viola a política antes mesmo de o syscall retornar para a aplicação. O guia oficial demonstra o bloqueio de conexões TCP de saída para fora do cluster e a interdição de leitura de arquivos sensíveis, tudo definido em recursos Kubernetes com escopo por namespace e por rótulo. Como as políticas Kubernetes são carregadas e descarregadas em runtime, dá para começar com observação pura e promover para bloqueio de forma gradual e reversível.

Esse poder exige disciplina. Uma política de bloqueio mal calibrada mata processos legítimos e vira incidente próprio. A rota recomendada é medir primeiro, alertar depois e bloquear por último, sempre com escopo reduzido a namespaces específicos e a pools de canário antes de alcançar cargas críticas.

Comparação e decisão de adoção

Dimensão Falco Tetragon
Origem Sysdig, graduado na CNCF Projeto do ecossistema Cilium
Modelo Alertas com regras de syscall Observabilidade e enforcement em eBPF
Ação sobre o evento Notifica (SIEM, webhook) Bloqueia no kernel (SIGKILL, override)
Ponto forte Base ampla de regras prontas Políticas próprias por workload
Risco operacional Baixo; erro não derruba carga Alto sem calibração; mata processos
Papel recomendado Detecção e forense Contenção automática

Uma leitura honesta da tabela: as ferramentas não são excludentes. Muitas equipes rodam Falco como camada de detecção madura, com regras da comunidade, e adotam Tetragon nos casos em que o tempo de resposta humano é grande demais — escape de contêiner, mineração em andamento e exfiltração em massa. A decisão de engenharia não é escolher um vencedor, e sim definir qual camada responde primeiro em cada classe de evento.

Checklist de implantação em produção

  • P1 — Habilitar o driver eBPF moderno: no Falco, prefira o modern eBPF probe embutido ao módulo de kernel; menos dependência de headers e sem reinicialização do nó.
  • P1 — Implantar com escopo por namespace: comece por namespaces de menor risco, meça volume de eventos e falsos positivos por duas semanas antes de expandir.
  • P1 — Definir cinco detectores mínimos: shell em contêiner, contêiner privilegiado, escrita em /etc, conexão reversa e execução de binário fora da imagem.
  • P2 — Promover para enforcement seletivo: no Tetragon, converta em bloqueio apenas as políticas estáveis, aplicadas a cargas com perfil de comportamento conhecido.
  • P2 — Endurecer o próprio agente: o agente de kernel exige capacidades como CAP_BPF e CAP_PERFMON; restrinja-as, rode com root filesystem somente leitura e trate o agente como ativo crítico.
  • P2 — Integrar ao hardening existente: segurança de runtime complementa, não substitui, os benchmarks CIS aplicados a nós, clusters e serviços de dados.

O sinal de que o investimento pagou não é o número de alertas, e sim o tempo entre o primeiro comportamento suspeito e a contenção. Quando um minerador é morto pelo kernel antes de completar o download, ou quando um shell em contêiner dispara alerta com pod, imagem e namespace no mesmo evento, a operação deixou de reagir a artefatos e passou a reagir a execução — que é o único momento em que um ataque pode ser interrompido sem dano.

Fontes