Engenharia de Detecção em Linux e Nuvem - Primeiros passos com o Defend for Containers (D4C)

Introdução

Os sistemas Linux continuam sendo uma base fundamental para a infraestrutura moderna, especialmente em ambientes nativos da nuvem, onde contêineres e plataformas de orquestração são a norma. À medida que as cargas de trabalho migram de hosts de longa duração para contêineres efêmeros, as técnicas de ataque também mudam. Atividades que antes deixavam registros persistentes no disco estão cada vez mais confinadas a comportamentos de curta duração, em tempo de execução, que podem ser difíceis de capturar usando fontes de log tradicionais.

A engenharia de detecção nesses ambientes, portanto, depende muito da visibilidade em tempo de execução. Compreender como os processos são executados dentro dos contêineres, como os arquivos são acessados e como as cargas de trabalho interagem com o host torna-se mais importante do que depender de indicadores estáticos ou artefatos pós-incidente.

A Elastic fornece diversas fontes de telemetria focadas em Linux para dar suporte a esse tipo de trabalho de detecção. Em publicações anteriores desta série, focamos na visibilidade em nível de host usando o Auditd e o Auditd Manager, mostrando como eventos de sistema de baixo nível podem ser traduzidos em detecções de alta fidelidade. Neste post, o foco muda para o Defend for Containers da Elastic: uma integração de segurança em tempo de execução criada especificamente para cargas de trabalho Linux em contêineres.

O objetivo deste artigo não é documentar todos os recursos do Defend for Containers, mas sim fornecer um ponto de partida prático para engenheiros de detecção: quais dados a integração produz e como interpretá-los. Na próxima parte, analisaremos como isso pode ser aplicado a cenários realistas de ataques a contêineres.

Visibilidade otimizada com o Defend for Containers

Temos o prazer de anunciar a chegada do Defend for Containers na versão 9.3.0. liberar. Essa integração traz uma abordagem simplificada para a segurança de contêineres, oferecendo uma base sólida para a visibilidade em infraestruturas nativas da nuvem. Os usuários podem aproveitar um conjunto de regras de detecção personalizadas para se defenderem contra ameaças modernas do Kubernetes e vulnerabilidades específicas de contêineres. A chegada do Defend for Containers é acompanhada por um conjunto de regras de detecção específico para contêineres, projetado em torno de modelos de ameaças realistas para contêineres e Kubernetes.

No momento da redação deste documento, o conjunto de regras Defend for Containers oferece cobertura básica para técnicas comuns de ataque a contêineres, incluindo atividades de reconhecimento, tentativas de acesso a credenciais, ataques ao kubelet, abuso de tokens de contas de serviço, execução interativa de processos, criação e modificação de arquivos, abuso de interpretadores, execução de payloads codificados, instalação de ferramentas, comportamento de tunelamento e múltiplos vetores de escalonamento de privilégios. É importante destacar que todas as regras de detecção existentes específicas para contêineres e Kubernetes foram tornadas compatíveis com o Defend for Containers, permitindo que a lógica anteriormente centrada no host opere diretamente na telemetria de tempo de execução do contêiner.

Isso torna o Defend for Containers uma fonte de dados prática e imediatamente utilizável para engenheiros de detecção do Linux focados em detecção de tempo de execução orientada por comportamento. O restante deste artigo se concentra em como essa telemetria se apresenta na prática e como ela pode ser aplicada a cenários reais de ataques a contêineres.

Introdução à Defesa dos Contêineres

Defend for Containers é uma integração de segurança em tempo de execução que fornece visibilidade dos contêineres Linux durante sua execução. Em vez de depender da análise estática de imagens ou de registros pós-execução, o foco é observar o comportamento do contêiner em tempo real.

Em linhas gerais, o Defend for Containers captura eventos de tempo de execução relevantes para a segurança de contêineres em execução, como a execução de processos e o acesso a arquivos. Esses eventos são enriquecidos com o contexto do contêiner e da orquestração e enviados para o Elasticsearch, onde podem ser analisados e usados como entrada para regras de detecção.

Do ponto de vista da engenharia de detecção, o Defend for Containers situa-se na intersecção entre o comportamento tradicional do Linux e o contexto dos contêineres. Processos, chamadas de sistema e atividades de arquivos continuam sendo sinais essenciais, mas agora estão restritos a contêineres, namespaces e cargas de trabalho que podem existir apenas brevemente.

O Defend for Containers é implementado como parte do Elastic Agent e integra-se diretamente com o Elastic Security. Uma vez ativado, ele fornece um fluxo dedicado de eventos de tempo de execução do contêiner que podem ser consultados usando KQL ou ES|QL, ou consumidos diretamente pela análise de detecção. Isso permite que os engenheiros de detecção apliquem técnicas de análise familiares, levando em consideração as realidades operacionais das cargas de trabalho nativas da nuvem.

Nas seções seguintes, examinaremos os eventos do Defend for Containers com mais detalhes e analisaremos diversos cenários de ataque a contêineres para ilustrar como esses dados podem ser usados na prática.

Configuração de Defesa para Contêineres

Antes de poder aproveitar a visibilidade e a análise em tempo de execução do Defend for Containers, você precisa implantar a integração e configurar uma política que defina quais eventos observar e quais ações tomar quando uma atividade correspondente for encontrada. Mais informações sobre a integração e sua configuração podem ser encontradas aqui. Em linhas gerais, essa configuração consiste em:

1. Implantação da integração do Defend for Containers via Elastic Agent em seu ambiente Kubernetes.
2. Configurar ou personalizar a política Defend for Containers, que consiste em seletores que definem quais operações devem ser correspondidas e respostas que definem quais ações devem ser tomadas.
3. Validar e refinar a política com base no comportamento da carga de trabalho observada.

Métodos de implantação

O Defend for Containers é fornecido como uma integração do Elastic Agent e depende do Elastic Agent para coletar e encaminhar a telemetria de tempo de execução do contêiner para o seu Elastic Stack. Para cargas de trabalho do Kubernetes, você instala a integração por meio da interface do usuário do Elastic Security e, em seguida, inscreve os agentes nos nós do cluster.

O fluxo básico de implantação é:

Na interface do usuário do Elastic Security, navegue até Fleet e crie uma nova Política de Agente (ou adicione a integração a uma já existente). Após a criação da Política do Agente, podemos adicionar a integração “Defend for Containers” à política.

Dê um nome à integração e, opcionalmente, ajuste os seletores e respostas padrão (analisaremos as opções disponíveis mais adiante nesta publicação). Após selecionar “Adicionar integração”, uma nova Política de Agente com a integração correta deverá estar disponível.

Para esta demonstração, utilizaremos o método de implantação do Kubernetes. Para implementar essa política em uma carga de trabalho, podemos navegar até Ações → Adicionar agente → Kubernetes. Aqui, vemos instruções para copiar ou baixar o manifesto do Kubernetes.

Uma observação importante a ter em mente é: “Observe que o manifesto a seguir contém limites de recursos que podem não ser adequados para um ambiente de produção. Consulte nosso guia sobre como dimensionar o Elastic Agent no Kubernetes antes de implantar este manifesto.”

Você precisará incluir o seguinte capabilities sob securityContext no seu arquivo YAML do Kubernetes para que o serviço funcione:

securityContext:
    runAsUser: 0
    capabilities:
      add:
        - BPF ## Enables both BPF & eBPF
        - PERFMON
        - SYS_RESOURCE

Após copiar ou baixar o manifesto elastic-agent-managed-kubernetes.yml fornecido, você pode editá-lo conforme necessário e aplicá-lo com:

kubectl apply -f elastic-agent-managed-kubernetes.yml

Conforme mencionado no manifesto, consulte o guia "Executar o Elastic Agent no Kubernetes gerenciado pelo Fleet " para obter mais informações sobre a implantação.

Aguarde até que os pods do Elastic Agent sejam agendados e que os dados comecem a fluir para o Elasticsearch.

Após a implantação, o Elastic Agent estabelecerá uma conexão com o Fleet, se inscreverá na política selecionada e começará a emitir telemetria do Defend for Containers que o Elastic Security poderá consumir.

Na próxima seção, examinaremos as opções de configuração de integração e exploraremos quais recursos estão disponíveis para uso.

Políticas da Defend for Containers

No cerne da configuração do Defend for Containers está a política. As políticas determinam qual atividade observar e como responder quando eventos correspondentes ocorrem. As políticas são compostas por dois elementos fundamentais:

• Seletores: definem quais eventos são de interesse, especificando operações e condições;
• Respostas: definem quais ações tomar quando as condições de um seletor são atendidas.

As políticas do Defend for Containers podem ser editadas antes da implantação ou modificadas após a implantação por meio do editor de políticas da interface do usuário do Elastic Security.

Estrutura da política

Cada política deve conter pelo menos um seletor e pelo menos uma resposta. Um seletor típico especifica uma ou mais operações (como eventos de processo ou atividades de arquivo) e usa condições (como nome da imagem do contêiner, namespace ou rótulo do pod) para restringir o escopo. As respostas fazem referência a seletores e indicam qual ação tomar quando os eventos correspondem.

A política padrão do Defend for Containers inclui dois pares seletor-resposta: “Detecção de Ameaças” e “Detecção e Prevenção de Desvios”.

Detecção de ameaças: Um selector chamado allProcesses corresponde a todos os eventos fork e exec dos contêineres.

E o response associado tem a ação definida como Log, garantindo que os eventos sejam ingeridos e possam ser analisados.

Detecção e prevenção de desvios: Um seletor chamado executableChanges corresponde às operações createExecutable e modifyExecutable .

E a resposta está configurada para gerar alertas (e pode ser modificada para bloquear essas operações).

Essas configurações podem ser modificadas pela interface do usuário, mas, internamente, essas políticas são arquivos de configuração YAML simples que podem ser facilmente modificados e usados em qualquer fluxo de CI/CD:

process:
  selectors:
    - name: allProcesses
      operation:
        - fork
        - exec
  responses:
    - match:
        - allProcesses
      actions:
        - log
file:
  selectors:
    - name: executableChanges
      operation:
        - createExecutable
        - modifyExecutable
  responses:
    - match:
        - executableChanges
      actions:
        - alert

A seguir, analisaremos alguns exemplos de seletores e respostas e discutiremos as opções disponíveis para configurar a integração de acordo com suas preferências.

Exemplo de trecho de seletor

Os seletores permitem uma correspondência precisa usando condições em campos como:

• containerImageFullName: nomes de imagens completos como docker.io/nginx;
• containerImageName: nomes parciais de imagens;
• containerImageTag: tags específicas como "mais recente";
• kubernetesClusterId: IDs de clusters Kubernetes;
• kubernetesClusterName: Nomes de clusters Kubernetes;
• kubernetesNamespace: namespaces onde a carga de trabalho é executada;
• kubernetesPodName: nomes de pods, com suporte para curingas no final;
• kubernetesPodLabel: pares de chave/valor de rótulos, com suporte a caracteres curinga.

selectors:
  - name: nodeExports
    file:
      operations:
        - createExecutable
        - modifyExecutable
      containerImageName:
        - "nginx"
      kubernetesNamespace:
        - "prod-*"

Neste exemplo, o seletor denominado nodeExports corresponde a eventos de arquivo que criam ou modificam executáveis dentro de contêineres cujos nomes de imagem contêm “nginx” e cujo namespace Kubernetes começa com “prod-”.

Exemplo de trecho de resposta

As respostas determinam o que acontece quando as condições do seletor são atendidas. As ações comuns incluem:

• log: enviar o evento como telemetria para análise;
• alertCriar um alerta no Elastic Security;
• block: impedir a operação (para tipos suportados).

responses:
  - name: alertAndBlockNodeExports
    matchSelectors:
      - nodeExports
    actions:
      - alert
      - block

Aqui, a resposta denominada alertAndBlockNodeExports faz referência ao seletor nodeExports definido anteriormente e irá gerar um alerta e bloquear a operação.

Coringas e correspondência

Os seletores no Defend for Containers suportam curingas à direita em condições baseadas em strings (como nomes de pods ou tags de imagens). Isso permite uma correspondência ampla sem enumerar todos os valores possíveis. Por exemplo, um seletor de pod de backend-* corresponderá a todos os pods cujos nomes começam com backend-, enquanto uma condição de rótulo como role:api* corresponde a valores de rótulo que começam com api.

Essa utilização de curingas é essencial em ambientes dinâmicos onde as cargas de trabalho escalam e mudam rapidamente.

Além da simples correspondência de strings, os seletores do Defend for Containers também suportam semântica de curinga baseada em caminho ao corresponder a caminhos de arquivos. Considere o seguinte exemplo de seletor:

- name:
  targetFilePath:
    - /usr/bin/echo
    - /usr/sbin/*
    - /usr/local/**

Neste exemplo:

• /usr/bin/echo corresponde apenas ao binário echo nesse caminho exato.
• /usr/sbin/* corresponde a tudo que é filho direto de /usr/sbin.
• /usr/local/** corresponde a tudo recursivamente sob /usr/local, incluindo caminhos como /usr/local/bin/something.

Essas distinções permitem definir com precisão o escopo dos seletores baseados em arquivos, equilibrando cobertura e ruído. Na prática, elas permitem que os engenheiros de detecção visem binários específicos, diretórios inteiros ou árvores de diretórios complexas, dependendo do caso de uso, sem recorrer a regras excessivamente permissivas.

Unindo tudo

Até este ponto, analisamos os seletores do Defend for Containers, a semântica de curingas, os tipos de eventos e como eles revelam o comportamento do atacante em tempo de execução. O passo final é entender como essas peças se unem dentro de uma política para expressar a lógica de detecção real.

Considere o seguinte fragmento de política:

file:
  selectors:
    - name: binDirExeMods
      operation:
        - createExecutable
        - modifyExecutable
      targetFilePath:
        - /usr/bin/**
    - name: etcFileChanges
      operation:
        - createFile
        - modifyFile
        - deleteFile
      targetFilePath:
        - /etc/**
    - name: nginx
      containerImageName:
        - nginx

  responses:
    - match:
        - binDirExeMods
        - etcFileChanges
      exclude:
        - nginx
      actions:
        - alert
        - block

Esta política define três seletores. Dois seletores (binDirExeMods e etcFileChanges) descrevem a atividade do sistema de arquivos de interesse, enquanto o terceiro seletor (nginx) descreve um contexto de contêiner a ser excluído.

A seção de resposta interliga esses seletores. Os seletores listados em match são logicamente OR'd, o que significa que qualquer uma das condições é suficiente para acionar a resposta. O seletor listado em exclude atua como um NOT lógico, removendo eventos correspondentes quando a imagem do contêiner é nginx.

Em linguagem simples, a política expressa a seguinte lógica:

Se um executável for criado ou modificado em qualquer lugar sob /usr/bin, ou um arquivo for criado, modificado ou excluído sob /etc, e a atividade não se originar de um contêiner nginx , gere um alerta e bloqueie a ação.

Em formato booleano, isso pode ser expresso como:

IF (binDirExeMods OR etcFileChanges) AND NOT nginx
→ alert + block

É aqui que as políticas da Defend for Containers se tornam poderosas. Em vez de escrever uma lógica de detecção complexa em uma linguagem de consulta, os seletores permitem decompor o comportamento em pequenos blocos de construção reutilizáveis e, em seguida, combiná-los de forma declarativa. Ao combinar seletores baseados em caminho, tipos de operação, contexto de contêiner e exclusões, você pode expressar uma lógica de detecção refinada que permanece legível e de fácil manutenção.

Na prática, esse modelo permite que os engenheiros de detecção traduzam hipóteses de ameaças diretamente em lógica de política: qual comportamento importa, onde ele ocorre, em quais cargas de trabalho e o que deve acontecer quando ele ocorre.

Validação e aprimoramento de políticas

Após a implementação de uma política, é fundamental validá-la em relação ao comportamento real da carga de trabalho antes de habilitar respostas agressivas, como o bloqueio. Políticas muito restritivas podem interromper as operações normais dos contêineres; políticas muito permissivas podem deixar que atividades indesejadas passem despercebidas.

Um fluxo de trabalho recomendado é:

1. Implante a política padrão no modo de monitoramento (por exemplo, com seletores registrando eventos).
2. Observe os eventos que aparecem no Elasticsearch para entender os padrões normais de carga de trabalho.
3. Aperfeiçoe gradualmente os seletores e as respostas, passando de "somente registro" → "alerta" → "bloqueio", testando em cada etapa.
4. Utilize um cluster de teste ou de homologação para validar os comportamentos de bloqueio antes de aplicá-los em produção.

Defesa de Contêineres - Limitações da versão Beta

Até o momento da redação deste documento, o Defend for Containers está disponível como uma integração Beta, e seus recursos atuais e suporte à plataforma refletem esse status.

O Defend for Containers oferece suporte formal ao Amazon EKS e ao Google GKE. Embora a integração possa ser implementada no Azure AKS, essa configuração não é oficialmente suportada. Em particular, as implementações do AKS atualmente carecem de telemetria de eventos de arquivos, o que limita a cobertura de detecção para técnicas de ataque baseadas em arquivos nesses ambientes.

A versão Beta atual também não captura eventos de rede. Consequentemente, as detecções relacionadas a conexões de saída, movimentação lateral na rede ou exfiltração de dados devem depender de fontes de dados complementares, como a integração com o Network Packet Capture ou com o Packetbeat , em vez de dependerem apenas da telemetria do Defend for Containers.

Para atividades com arquivos, o Defend for Containers registra intencionalmente eventos de abertura de arquivos somente quando abertos com intenção de gravação. Essa escolha de projeto reduz o ruído e concentra-se no comportamento que modifica o estado do sistema. No entanto, isso também significa que o acesso somente leitura a arquivos sensíveis, como descoberta de segredos, extração de configurações ou tentativas de acesso malsucedidas, não é atualmente observável.

Essa limitação afeta casos de uso de detecção, tais como:

• Pesquisa e leitura de tokens de contas de serviço do Kubernetes,
• Verificando a presença de arquivos .env ou material de credencial.

Essas são áreas em que futuras versões do Defend for Containers poderão fornecer telemetria mais detalhada para dar suporte a casos de uso avançados de engenharia de detecção.

Habilitar as regras de detecção pré-configuradas do Defend for Containers

O Defend for Containers é fornecido com um conjunto de regras de detecção pré-configuradas que oferecem cobertura básica para técnicas comuns de ataque a contêineres. Uma vez que a integração esteja habilitada, essas regras podem ser ativadas diretamente do Elastic Security sem configuração adicional.

A ativação das regras predefinidas é recomendada como ponto de partida, pois elas foram projetadas para se alinharem à telemetria de tempo de execução do Defend for Containers e abrangem a execução, a modificação de arquivos, a persistência e o comportamento pós-comprometimento dentro dos contêineres. A partir daí, as regras podem ser ampliadas ou refinadas para se adequarem às cargas de trabalho e aos modelos de ameaça específicos do ambiente.

Ao filtrar por “Fonte de dados: Elastic Defend for Containers”, você encontrará todas as regras associadas a essa integração.

Observação: se você não vir nenhuma regra aparecer, verifique se sua pilha está executando a versão 9.3.0. pois essas regras são implementadas apenas na versão 9.3.0 ou superior.

Com todas as limitações importantes da versão Beta mapeadas, a integração implementada, as regras de detecção pré-configuradas instaladas e ativadas e uma política funcional em vigor, o próximo passo é explorar a semântica dos eventos produzidos pelo Defend for Containers, incluindo os campos comumente usados na lógica de detecção, as considerações de desempenho e como esses eventos diferem dos eventos do Elastic Defend.

Analisando eventos do Defend for Containers

Agora que o Defend for Containers está implantado e as políticas estão em vigor, o próximo passo é entender os eventos que ele gera. Assim como acontece com o Elastic Defend ou o Auditd Manager, a telemetria do Defend for Containers torna-se muito mais valiosa quando você desenvolve um modelo mental de como os eventos são estruturados e quais campos são mais relevantes para a engenharia de detecção.

O Defend for Containers gera vários tipos de eventos, principalmente eventos de processo e eventos de arquivo, cada um enriquecido com contexto de contêiner, host e orquestração. Embora os sinais subjacentes permaneçam enraizados no comportamento do Linux, os metadados adicionais do Kubernetes e do contêiner permitem que você analise a atividade de maneiras que não são possíveis com a telemetria somente do host.

As seções a seguir descrevem os grupos de campos e tipos de eventos mais importantes, usando eventos reais do Defend for Containers como pontos de referência.

Campos comuns

Antes de analisarmos categorias específicas de eventos, é útil entender os campos que aparecem consistentemente na telemetria do Defend for Containers. Esses campos fornecem a cola contextual que vincula as ações individuais em tempo de execução às políticas, aos seletores e aos pontos de execução subjacentes dentro do kernel.

Embora os eventos de processo e de arquivo difiram em seus detalhes, os campos descritos abaixo estão presentes em todos os fluxos de dados do Defend for Containers e geralmente são o primeiro lugar a ser verificado ao validar detecções ou solucionar problemas de comportamento da política.

Defender o contexto específico dos contêineres

O Defend for Containers adiciona diversos campos específicos sobre como os eventos são coletados e as políticas são aplicadas.

O campo cloud_defend.hook_point indica onde no kernel o evento foi capturado. No exemplo mostrado, valores como tracepoint__sched_process_fork e tracepoint__sched_process_exec revelam que o evento foi gerado a partir de pontos de rastreamento do kernel associados à criação e execução do processo.

O campo cloud_defend.matched_selectors mostra quais seletores na política ativa corresponderam ao evento. No exemplo, o valor allProcesses indica que este evento correspondeu a um seletor amplo que captura toda a atividade do processo. Ao ajustar políticas ou investigar alertas, este campo é essencial para entender por que um evento foi capturado.

Os campos cloud_defend.package_policy_id e cloud_defend.package_policy_revision vinculam o evento a uma política específica do Elastic Agent e à sua revisão. Isso possibilita correlacionar eventos com alterações de configuração ao longo do tempo e verificar qual versão de uma política estava ativa quando o evento ocorreu.

Metadados do evento

Os eventos do Defend for Containers seguem as convenções do Elastic Common Schema e incluem metadados de evento padrão que descrevem o tipo e o ciclo de vida da atividade.

O campo event.category identifica o tipo de atividade de alto nível, como process ou file, e normalmente é o primeiro campo usado ao filtrar dados do Defend for Containers. O campo event.action descreve o que ocorreu, por exemplo, fork ou exec para atividade de processo, ou open, creation, modification e deletion para eventos de arquivo.

O campo event.type adiciona contexto de ciclo de vida, como start para execução de processo, e é frequentemente usado junto com event.action para distinguir diferentes fases de atividade. O campo event.dataset indica o fluxo de dados de origem do Defend for Containers, como cloud_defend.process, o que é útil ao criar consultas ou detecções com escopo de conjunto de dados.

Campos de metadados adicionais como event.id, event.ingested e event.kind são usados principalmente para correlação, ordenação e resolução de problemas, em vez de lógica de detecção.

Informações do host

Os eventos do Defend for Containers incluem o contexto completo do host, semelhante ao Elastic Defend e ao Auditd Manager. Isso possibilita correlacionar a atividade de tempo de execução do contêiner com o nó Kubernetes subjacente.

O campo host.name identifica o nó no qual o contêiner está sendo executado, enquanto host.os.* fornece detalhes do sistema operacional, como distribuição e versão do kernel. O campo host.architecture indica a arquitetura da CPU, que pode ser relevante ao analisar a execução binária ou o comportamento específico do kernel.

Um campo particularmente útil é host.pid_ns_ino, que identifica o espaço de nomes PID. Este campo permite correlacionar a atividade do contêiner com a telemetria de processos e kernel do host, sendo especialmente valioso na investigação de tentativas de fuga do contêiner ou do impacto no nível do nó.

O contexto do host é crucial na análise de ataques nativos da nuvem, pois vários contêineres frequentemente compartilham o mesmo host e kernel, e o comportamento de tempo de execução de um contêiner pode ter implicações que vão além de seus limites.

Contexto de contêiner e orquestrador

O principal ponto forte da Defend for Containers reside em seu conhecimento sobre contêineres. Cada evento de tempo de execução é enriquecido com metadados de contêiner e orquestração, permitindo que a atividade seja analisada no contexto do que está sendo executado, onde está sendo executado e com quais privilégios.

No nível do contêiner, campos como container.id e container.name identificam exclusivamente o contêiner em execução, enquanto container.image.name, container.image.tag e o hash da imagem fornecem visibilidade da origem e versão da carga de trabalho. Isso é especialmente útil para distinguir entre imagens de utilitários esperadas e cargas de trabalho inesperadas ou ad hoc.

Um campo chave para avaliação de risco é container.security_context.privileged. Este campo indica explicitamente se um contêiner está sendo executado em modo privilegiado. Quando a execução privilegiada é combinada com outros sinais, como shells interativos ou amplas capacidades do Linux, o perfil de risco de qualquer atividade detectada aumenta significativamente.

O Defend for Containers também enriquece os eventos com contexto de orquestração. Campos como orchestrator.cluster.name, orchestrator.namespace e orchestrator.resource.name (normalmente o nome do Pod) vinculam o comportamento em tempo de execução às cargas de trabalho do Kubernetes. Os rótulos expostos por meio de orchestrator.resource.label permitem ainda que as detecções incorporem a intenção da carga de trabalho e a propriedade.

Para a engenharia de detecção, esse contexto permite o escopo preciso das detecções para:

• espaços de nomes específicos (por exemplo, kube-system),
• contêineres privilegiados ou de alto risco,
• cargas de trabalho com rótulos sensíveis,
• ou imagens de utilidade conhecidas, como netshoot, kubectl ou curl.

Essa camada de enriquecimento permite que a lógica de detecção com reconhecimento de contêiner seja expressa diretamente, sem a necessidade de inferir a intenção indiretamente a partir de caminhos do sistema de arquivos, cgroups ou identificadores de namespace.

Eventos de processo

A execução de processos é um dos tipos de sinal mais importantes fornecidos pelo Defend for Containers. Os eventos de processo capturam as atividades fork, exec e end dentro dos contêineres e expõem informações de linhagem detalhadas, essenciais para entender como a execução se desenrola em tempo de execução.

Diversos campos são particularmente importantes para a engenharia de detecção. A combinação de process.name e process.executable identifica o que foi executado e de onde, enquanto process.args fornece informações sobre como foi invocado. Campos como process.pid, process.start, process.end e process.exit_code descrevem o ciclo de vida do processo e são úteis para análise de tempo e reconstrução do fluxo de execução. O process.entity_id fornece um identificador estável que permite que os processos sejam rastreados em vários eventos relacionados.

O projeto Defend for Containers também coleta informações genealógicas valiosas. Os campos sob process.parent.* descrevem o processo pai imediato, possibilitando a detecção de relações pai-filho suspeitas, como shells gerados por binários inesperados. Além disso, process.entry_leader.* e process.session_leader.* fornecem âncoras de nível superior dentro da árvore de processos.

Assim como o Elastic Defend, o Defend for Containers modela os processos como um grafo, em vez de eventos isolados. O líder de entrada é especialmente útil em ambientes de contêiner, pois geralmente representa o processo inicial lançado pelo runtime do contêiner (por exemplo, containerd, runc ou um shell especificado como ponto de entrada do contêiner). Ancorar as detecções ao líder de entrada permite que as árvores de processos sejam interpretadas de forma consistente, mesmo quando os contêineres geram muitos processos filhos de curta duração.

Os campos do líder da sessão fornecem contexto adicional sobre a execução interativa e os limites da sessão, ajudando a distinguir serviços em segundo plano de atividades interativas ou iniciadas por atacantes.

Em conjunto, esses campos possibilitam expressar uma lógica de detecção que vai além de execuções individuais e, em vez disso, raciocina sobre cadeias de execução, linhagem e intenção, o que é essencial para detectar técnicas reais de ataque a contêineres.

Contexto de capacidades e privilégios

Um dos aspectos mais poderosos dos eventos de processo do Defend for Containers é a inclusão de informações sobre os recursos do Linux. Para cada processo, o Defend for Containers expõe os conjuntos de capacidades efetivas e permitidas por meio de:

• process.thread.capabilities.effective
• process.thread.capabilities.permitted

Esses campos descrevem o que um processo está realmente autorizado a fazer em tempo de execução, independentemente de seu ID de usuário ou limite de contêiner.

Em contêineres privilegiados, os processos frequentemente expõem um amplo conjunto de capacidades efetivas, incluindo altamente sensíveis, como CAP_SYS_ADMIN, CAP_SYS_MODULE, CAP_SYS_PTRACE, CAP_SYS_RAWIO e CAP_BPF. A presença dessas funcionalidades altera significativamente o perfil de risco de qualquer comando executado, pois permite ações que podem impactar diretamente o kernel do host ou outras cargas de trabalho.

Do ponto de vista da engenharia de detecção, esse contexto é crucial. Isso permite que as detecções vão além da simples correspondência de nomes de processos e, em vez disso, analisem o impacto. A mesma execução binária pode ter implicações muito diferentes dependendo se ela é executada com um conjunto mínimo de recursos ou com privilégios próximos aos do host.

Na prática, os dados de capacidade permitem que os engenheiros de detecção:

• Identificar operações suspeitas executadas em contêineres com permissões excessivas.
• Correlacione o comportamento em tempo de execução com combinações de capacidades perigosas.
• Priorize os alertas com base no potencial real de exploração, em vez de atividades superficiais.

Isso se torna especialmente relevante para pesquisas sobre quebra de segurança em contêineres, onde a presença ou ausência de capacidades específicas muitas vezes determina se uma exploração é viável.

Execução interativa

O campo process.interactive indica se um processo está associado a uma sessão interativa. Em ambientes de contêineres, a execução interativa é relativamente rara para cargas de trabalho de produção e geralmente está fortemente correlacionada com atividades pós-comprometimento ou com o uso direto do teclado.

O Defend for Containers expõe a interatividade não apenas no nível do processo, mas também em contextos de execução relacionados, incluindo process.parent.interactive, process.entry_leader.interactive e process.session_leader.interactive. Isso possibilita determinar se toda uma cadeia de execução é interativa, em vez de depender de um único indicador de processo isoladamente.

Exemplos comuns de execução interativa dentro de contêineres incluem a criação de um shell bash ou sh , a execução de utilitários interativos como curl, kubectl ou busybox, ou reconhecimento conduzido pelo operador dentro de um Pod comprometido. Embora essas ações possam ser legítimas durante a depuração, elas são incomuns em cargas de trabalho de produção em estado estável.

Quando combinada com a imagem do contêiner, o namespace e o contexto de privilégios, a execução interativa torna-se um forte sinal de anomalia. Isso permite que a lógica de detecção distinga entre o comportamento esperado de um contêiner automatizado e atividades mais consistentes com intervenção manual ou exploração conduzida por um invasor.

Eventos de arquivo

Os eventos de arquivo do Defend for Containers capturam a atividade do sistema de arquivos dentro dos contêineres e são emitidos para uma variedade de operações. Diferentemente do monitoramento tradicional de integridade de arquivos, esses eventos são sensíveis ao tempo de execução e restritos às cargas de trabalho do contêiner, fornecendo contexto sobre como e por que as alterações de arquivos ocorrem.

O Defend for Containers consegue detectar atividades de arquivos, como aberturas com intenção de gravação, modificações de conteúdo, criações de arquivos, renomeações, alterações de permissões e exclusões. Ao focar em operações orientadas à escrita, o Defend for Containers enfatiza comportamentos que alteram o estado do sistema, em vez do acesso passivo a arquivos.

Isso permite que os engenheiros de detecção analisem os padrões de uso de arquivos em tempo de execução, e não apenas o resultado de uma alteração.

Diversos campos são particularmente importantes na construção de detecções baseadas em arquivos. Os campos file.path e file.name identificam o arquivo afetado e sua localização, enquanto file.extension pode ajudar a distinguir binários, scripts e arquivos de configuração. Os campos event.action e event.type descrevem qual operação ocorreu e como ela deve ser interpretada no ciclo de vida do evento.

Em conjunto, esses campos permitem que o Defend for Containers distinga o acesso legítimo a arquivos de padrões de modificação suspeitos, como a gravação de binários ou a alteração de permissões em diretórios sensíveis.

Juntando tudo

Assim como acontece com qualquer outra fonte de dados, a telemetria do Defend for Containers torna-se verdadeiramente valiosa quando você entende como combinar campos em todos os domínios: processo, arquivo, contêiner e orquestração. Em vez de depender de indicadores estáticos, o Defend for Containers permite a engenharia de detecção com base no comportamento em tempo de execução, no contexto de privilégios e na identidade da carga de trabalho.

Conclusão

Defenda os contêineres no Elastic Stack 9.3.0 Inclui a detecção de tempo de execução de contêineres como um componente central da engenharia de detecção do Linux. Ele apresenta um escopo claro, um modelo de configuração orientado por políticas e telemetria de tempo de execução projetada especificamente para cargas de trabalho em contêineres.

Neste artigo, examinamos como implantar o Defend for Containers, como seu modelo de políticas é estruturado e como os eventos de tempo de execução são gerados e enriquecidos com o contexto do contêiner e da orquestração. Exploramos a estrutura de eventos de processo e arquivo, metadados de capacidade, sinais de execução interativos e campos específicos do contêiner que permitem que as detecções sejam expressas de maneira adaptada à carga de trabalho.

A principal conclusão é que a detecção eficaz de contêineres exige raciocínio sobre o comportamento em tempo de execução dentro do contexto: processos, modificações de arquivos, privilégios e identidade da carga de trabalho devem ser avaliados em conjunto. A Defend for Containers fornece a telemetria necessária para tornar isso possível.

No próximo artigo, partiremos dessa base, analisando um cenário realista de ataque a contêineres e demonstrando como a telemetria do Defend for Containers revela cada etapa da invasão na prática.