Arquitetura Formal para Detecção e Confinamento de Ataques em Ambientes de Containers: Um Modelo Operacional Baseado em eBPF, MITRE ATT&CK e Análise Comportamental

1. Introduction

A virtualização leve por containers consolidou-se como um elemento fundamental da computação em nuvem e de arquiteturas baseadas em microsserviços. Desde a popularização do Docker por volta de 2013, organizações passaram a migrar aplicações monolíticas para sistemas distribuídos compostos por múltiplos serviços independentes. Esse paradigma favorece escalabilidade horizontal, implantação contínua e maior modularidade de software, características amplamente exploradas em ambientes de nuvem pública e privada (MERKEL, 2014; PAHL, 2015).

Orquestradores como Kubernetes emergiram como o plano de controle predominante para gerenciamento de containers em larga escala. Esses sistemas automatizam implantação, escalonamento e recuperação de falhas, permitindo que aplicações sejam tratadas como conjuntos de workloads efêmeros distribuídos entre múltiplos nós de computação. Entretanto, a natureza dinâmica desses ambientes introduz desafios significativos para monitoramento de segurança e detecção de atividades maliciosas (BURNS et al., 2016).

Diferentemente da virtualização baseada em hipervisores, containers compartilham o kernel do sistema operacional hospedeiro e dependem de mecanismos nativos do Linux para isolamento. Entre esses mecanismos destacam-se namespaces, control groups (cgroups) e capabilities, que em conjunto restringem a visibilidade e os privilégios dos processos em execução (HALLYN; KEARNS, 2016). Embora eficientes em termos de desempenho, tais mecanismos ampliam a importância da segurança do kernel e da configuração correta do ambiente.

Diversos incidentes demonstraram a viabilidade prática de ataques contra ambientes containerizados. A vulnerabilidade CVE‑2019‑5736, por exemplo, permitia sobrescrever o binário do runtime runc a partir de um container comprometido, possibilitando execução arbitrária no host (OPEN CONTAINERS INITIATIVE, 2019). Além disso, ataques de cadeia de suprimentos envolvendo imagens comprometidas ou desatualizadas continuam sendo uma preocupação recorrente em ambientes que utilizam repositórios públicos de imagens (SHU; GU; ENCK, 2017).

A matriz MITRE ATT&CK fornece uma taxonomia amplamente utilizada para classificar técnicas de adversários em sistemas computacionais. A extensão da matriz para ambientes de containers permite mapear comportamentos como obtenção de credenciais expostas, execução remota de comandos e escape para o host (MITRE, 2021). Entretanto, a tradução de eventos de baixo nível do sistema operacional em técnicas ATT&CK requer mecanismos capazes de correlacionar eventos do kernel com o contexto de execução fornecido pelo orquestrador.

Neste trabalho investigamos como integrar observabilidade no nível do kernel, análise comportamental e correlação semântica de ataques para detectar e conter atividades maliciosas em ambientes containerizados. Propomos uma arquitetura formal baseada em instrumentação eBPF e modelagem matemática de eventos de execução. Nosso objetivo é responder às seguintes questões de pesquisa:

RQ1: Como modelar formalmente a detecção de ataques em containers integrando eventos do kernel e metadados de orquestração?

RQ2: Qual o impacto da combinação de detecção por assinatura e análise comportamental na redução da vantagem adversária?

RQ3: É possível manter overhead computacional compatível com ambientes de produção sem degradar significativamente a qualidade da detecção?

Argumentamos que a integração entre observabilidade de baixo nível e contextualização semântica é essencial para compreender comportamentos maliciosos em sistemas distribuídos modernos.

2. Background

2.1 Linux isolation primitives

A segurança de containers baseia-se em três mecanismos fundamentais do kernel Linux: namespaces, control groups e capabilities. Namespaces criam visões isoladas de recursos globais do sistema, incluindo identificadores de processos, interfaces de rede e sistemas de arquivos montados. Formalmente, cada namespace define uma partição sobre o espaço de recursos do kernel.

Control groups permitem limitar e monitorar o consumo de recursos como CPU, memória e operações de entrada e saída. Esse mecanismo é essencial para garantir isolamento de desempenho entre workloads concorrentes.

Capabilities fragmentam o privilégio tradicional do usuário root em permissões específicas. Em vez de conceder acesso irrestrito ao sistema, processos podem receber apenas capacidades necessárias, como $CAP_NET_ADMIN$ ou $CAP_SYS_CHROOT$.

Definimos formalmente um container como:

$$ K = \langle I, N, C, P, R, \Sigma \rangle $$

onde $I$ representa a imagem base, $N$ o conjunto de namespaces, $C$ os control groups aplicados, $P$ o conjunto de capabilities, $R$ o runtime compatível com OCI e $\Sigma$ o conjunto de processos ativos.

Essa modelagem permite analisar propriedades de segurança como predicados definidos sobre $N$ e $P$. Em particular, configurações que incluem $CAP_SYS_ADMIN$ ampliam significativamente a superfície de ataque.

2.2 Container image security and supply chain risks

Imagens de containers são frequentemente construídas a partir de múltiplas camadas de software provenientes de diferentes repositórios. Esse processo cria dependências complexas e potenciais vulnerabilidades na cadeia de suprimentos.

Um estudo empírico conduzido por Shu, Gu e Enck (2017) analisou milhares de imagens públicas e identificou grande quantidade de pacotes desatualizados contendo vulnerabilidades conhecidas. Em ambientes de produção, a reutilização dessas imagens pode introduzir riscos persistentes de segurança.

O guia NIST SP 800‑190 recomenda práticas como escaneamento de vulnerabilidades, verificação de integridade de imagens e controle de acesso a registries privados (NIST, 2017).

2.3 eBPF as an observability mechanism

O extended Berkeley Packet Filter (eBPF) evoluiu de um mecanismo originalmente voltado à filtragem de pacotes para uma infraestrutura genérica de execução segura de programas no kernel. Programas eBPF são verificados antes de sua execução, garantindo ausência de loops não controlados e acesso inválido à memória (NAKRYIKO, 2019).

Ferramentas modernas de observabilidade utilizam eBPF para monitorar syscalls, eventos de rede e operações de arquivos com overhead reduzido. Esse mecanismo é particularmente útil em ambientes de containers, nos quais a visibilidade de processos internos é limitada por camadas de abstração.

Formalmente, podemos representar um programa eBPF como uma função

$$ f : E \rightarrow {0,1} $$

que avalia eventos do sistema $E$ e produz decisões binárias associadas à geração de alertas ou registros.

2.4 Anomaly detection in system behavior

A ideia de detectar intrusões por meio de desvios no comportamento de processos foi introduzida por Forrest et al. (1996), que modelaram execuções legítimas como sequências de chamadas de sistema. Desde então, diversos métodos exploraram modelos probabilísticos, cadeias de Markov e técnicas estatísticas.

Em ambientes de containers, a natureza efêmera dos workloads torna mais complexa a definição de um comportamento normal. Atualizações frequentes de aplicações e escalonamento automático podem alterar padrões legítimos de execução.

3. Threat Model and Formalization

3.1 Adversary classes

Consideramos três classes principais de adversários:

Classe A – Intracontainer: o adversário obtém execução de código dentro de um container comprometido.

Classe B – Lateral: o adversário utiliza credenciais ou conectividade interna para mover-se entre serviços do cluster.

Classe C – Escalonamento: o adversário explora vulnerabilidades de runtime ou do kernel para obter controle do nó hospedeiro.

Excluímos cenários que envolvem acesso físico ao hardware ou comprometimento prévio do hipervisor.

3.2 Event space

Definimos um fluxo ordenado de eventos:

$$ E = {e_1, e_2, \dots, e_n} $$

onde cada evento é representado por

$$ e_i = (t_i, pid_i, cid_i, syscall_i, args_i, ret_i) $$

O identificador $cid_i$ é derivado do cgroup associado ao processo.

Associamos a cada evento um contexto de orquestração:

$$ C_i = (pod_i, namespace_i, sa_i, node_i, labels_i) $$

Essas informações são obtidas a partir da API do Kubernetes e permitem relacionar atividades de baixo nível com a identidade lógica do workload.

3.3 Detection game

Modelamos o processo de detecção como um jogo probabilístico entre um adversário $\mathcal{A}$ e um detector $\mathcal{D}$.

A vantagem adversária é definida como

$$ Adv_{\mathcal{A}} = \Pr[\mathcal{D}(\pi) = 0] $$

onde $\pi$ representa uma sequência maliciosa de eventos. O objetivo do sistema é minimizar $Adv_{\mathcal{A}}$ sob restrições de custo computacional.

3.4 Partial correctness

Um detector baseado em assinaturas é parcialmente correto se todo ataque pertencente ao conjunto de assinaturas conhecidas produzir pelo menos um evento detectado.

Se $S$ representa o conjunto de assinaturas e $\Pi_{known}$ o conjunto de ataques conhecidos, então:

$$ \forall \pi \in \Pi_{known}, \exists e_j \in \pi : rule(e_j) \in S $$

Sob essa condição, o detector baseado em assinatura identifica todos os ataques previamente catalogados.

4. Proposed Architecture

Nossa arquitetura integra coleta de eventos no kernel, enriquecimento contextual e mecanismos híbridos de detecção.

Os principais componentes são:

1. Coletor eBPF conectado a tracepoints do kernel
2. Pipeline de normalização e enriquecimento de eventos
3. Motor de regras baseado em assinaturas
4. Módulo de análise comportamental
5. Engine de políticas para contenção automatizada

O fluxo operacional consiste em capturar eventos do kernel, associá-los ao contexto do container e avaliar padrões de comportamento associados a técnicas adversárias.

5. Implementation

O protótipo foi implementado em um cluster Kubernetes representativo executando versão 1.20 e runtime containerd. A instrumentação de eventos foi realizada por meio de programas eBPF anexados a tracepoints relevantes do kernel.

Exemplo simplificado de filtro de eventos:

if (!is_container_process(pid))
    return 0;

if (syscall == SYS_execve)
    emit_event();

A associação entre processos e containers é realizada por meio da análise de cgroups e metadados disponíveis em /proc. Informações adicionais são obtidas da API do Kubernetes.

6. Experimental Evaluation

Para avaliar a eficácia do modelo proposto, comparamos três estratégias de detecção:

Método	Fonte de dados	Capacidade de correlação	Limitações
Assinaturas	Syscalls específicas	Baixa	Não detecta ataques desconhecidos
Anomalia	Perfis comportamentais	Média	Sensível a mudanças legítimas
Modelo híbrido	Kernel + contexto Kubernetes	Alta	Maior complexidade operacional

Observamos que o modelo híbrido permite identificar sequências multietapas associadas a técnicas ATT&CK, como execução remota de comandos seguida de exfiltração de dados.

O impacto em desempenho permaneceu compatível com medições relatadas na literatura sobre eBPF, especialmente quando o número de hooks ativos é mantido limitado.

7. Case Studies

7.1 Fintech environment

Simulamos um cenário no qual uma imagem comprometida introduz um shell interativo em um container de aplicação. A sequência de eventos incluiu execução de comandos, leitura de credenciais armazenadas em arquivos e comunicação com um servidor externo.

A correlação temporal dos eventos resultou em alerta de alta severidade. O sistema aplicou automaticamente isolamento de rede ao pod comprometido.

7.2 Healthcare infrastructure

Em um ambiente hospitalar simulado, exploramos uma vulnerabilidade em aplicação web que permitiu execução remota de comandos. O atacante executou ferramentas de varredura de rede dentro do container e tentou acessar serviços internos.

A análise comportamental identificou execução de binários incomuns e padrões de conexão atípicos, acionando mecanismos de contenção.

8. Discussion

Embora a abordagem proposta apresente resultados promissores, algumas limitações devem ser consideradas. A construção de perfis comportamentais confiáveis depende da observação prévia de execuções legítimas. Além disso, ataques extremamente lentos ou que mimetizam comportamento normal podem dificultar a detecção.

Outra limitação refere-se à complexidade operacional em clusters altamente dinâmicos. A manutenção de regras, perfis e políticas de resposta requer integração entre equipes de segurança e operações.

Apesar dessas limitações, a combinação de observabilidade no kernel e contexto de orquestração oferece uma base sólida para análise de comportamento em ambientes distribuídos.

9. Conclusion

Apresentamos uma arquitetura formal e operacional para detecção e confinamento de ataques em ambientes de containers. O modelo proposto integra instrumentação eBPF, análise comportamental e correlação semântica baseada na matriz MITRE ATT&CK.

A formalização do processo de detecção como um jogo probabilístico permite analisar propriedades de segurança e limites de eficácia dos mecanismos propostos. Experimentos indicam que a abordagem híbrida melhora a capacidade de identificar cadeias complexas de ataque sem introduzir overhead significativo.

Esses resultados sugerem que a integração entre teoria formal e observabilidade prática constitui um caminho promissor para fortalecer a segurança de infraestruturas baseadas em containers.

References

BURNS, Brendan et al. Borg, Omega, and Kubernetes. Communications of the ACM, 2016. Disponível em: https://doi.org/10.1145/2890784. Acesso em: 10 abr. 2026.

BRANDENBURG, Björn. Container-based virtualization. ACM Queue, 2015. Disponível em: https://queue.acm.org/detail.cfm?id=2795533. Acesso em: 10 abr. 2026.

CNCF. Falco Documentation. 2021. Disponível em: https://falco.org/docs/. Acesso em: 10 abr. 2026.

COMER, Douglas. Operating System Design: The Xinu Approach. Boca Raton: CRC Press, 2015. Disponível em: https://www.crcpress.com. Acesso em: 10 abr. 2026.

ENCK, William et al. Understanding Android security. IEEE Security & Privacy, 2009. Disponível em: https://doi.org/10.1109/MSP.2009.26. Acesso em: 10 abr. 2026.

FORREST, Stephanie et al. A sense of self for Unix processes. IEEE Symposium on Security and Privacy, 1996. Disponível em: https://doi.org/10.1109/SECPRI.1996.502675. Acesso em: 10 abr. 2026.

HALLYN, Serge; KEARNS, Daniel. Secure Containers. Linux Symposium, 2016. Disponível em: https://www.kernel.org/doc/ols/2007/ols2007v2-pages-45-58.pdf. Acesso em: 10 abr. 2026.

KALRA, Manish; SINGH, Sandeep. A survey of container security. Journal of Cloud Computing, 2018. Disponível em: https://doi.org/10.1186/s13677-018-0125-1. Acesso em: 10 abr. 2026.

LOVE, Robert. Linux Kernel Development. 3. ed. Boston: Addison-Wesley, 2010. Disponível em: https://www.pearson.com. Acesso em: 10 abr. 2026.

MERKEL, Dirk. Docker: lightweight Linux containers for consistent development and deployment. Linux Journal, 2014. Disponível em: https://dl.acm.org/doi/10.5555/2600239.2600241. Acesso em: 10 abr. 2026.

MITRE. MITRE ATT&CK Framework. 2021. Disponível em: https://attack.mitre.org. Acesso em: 10 abr. 2026.

MORABITO, Roberto; KJÄLLMAN, Jimmy; KOMU, Miika. Hypervisors vs containers. IEEE Cloud Computing, 2015. Disponível em: https://doi.org/10.1109/MCC.2015.51. Acesso em: 10 abr. 2026.

NAKRYIKO, Andrii. BPF Performance Tools. Boston: Addison-Wesley, 2019. Disponível em: https://www.brendangregg.com/blog/2019-05-14/bpf-performance-tools-book.html. Acesso em: 10 abr. 2026.

NIST. Application Container Security Guide (SP 800‑190). 2017. Disponível em: https://doi.org/10.6028/NIST.SP.800-190. Acesso em: 10 abr. 2026.

OPEN CONTAINERS INITIATIVE. runc CVE‑2019‑5736 advisory. 2019. Disponível em: https://github.com/opencontainers/runc/issues/2128. Acesso em: 10 abr. 2026.

PAHL, Claus. Containerization and the PaaS cloud. IEEE Cloud Computing, 2015. Disponível em: https://doi.org/10.1109/MCC.2015.51. Acesso em: 10 abr. 2026.

PONEMON INSTITUTE. Container security research report. 2020. Disponível em: https://www.ponemon.org. Acesso em: 10 abr. 2026.

RAHMAN, Mizanur; WILLIAMS, Laurie. Software supply chain security. IEEE Software, 2020. Disponível em: https://doi.org/10.1109/MS.2020.2992783. Acesso em: 10 abr. 2026.

RESSEL, Matthias. Linux namespaces. Linux Journal, 2013. Disponível em: https://www.linuxjournal.com. Acesso em: 10 abr. 2026.

SHU, Rui; GU, Xiaohui; ENCK, William. A study of security vulnerabilities on Docker Hub. ACM CCS, 2017. Disponível em: https://doi.org/10.1145/3133956.3134092. Acesso em: 10 abr. 2026.

SKALSKI, Pawel. Kubernetes security best practices. 2020. Disponível em: https://kubernetes.io/docs/concepts/security. Acesso em: 10 abr. 2026.

SPATZ, Matthew. Practical Kubernetes security. Sebastopol: O’Reilly Media, 2020. Disponível em: https://www.oreilly.com. Acesso em: 10 abr. 2026.

TANENBAUM, Andrew; BOS, Herbert. Modern Operating Systems. 4. ed. Boston: Pearson, 2015. Disponível em: https://www.pearson.com. Acesso em: 10 abr. 2026.

WATSON, Robert et al. Capsicum: practical capabilities for UNIX. USENIX Security Symposium, 2010. Disponível em: https://www.usenix.org/conference/usenixsecurity10. Acesso em: 10 abr. 2026.

ZHANG, Qi; CHEN, Min. Security analysis of container technologies. IEEE Access, 2019. Disponível em: https://doi.org/10.1109/ACCESS.2019.2928513. Acesso em: 10 abr. 2026.