Regras do auditd mal escritas são uma das causas mais comuns de trilhas de auditoria inúteis em servidores Linux: o volume de eventos explode, a CPU paga a conta e o sinal de um ataque real se dissolve em meio a registros sem significado. O problema atinge equipes que mantêm auditoria de chamadas de sistema por exigência de compliance ou para investigação forense, e se agrava justamente nos servidores com mais tráfego. A ação prioritária é revisar o conjunto de regras com três critérios que vêm da documentação oficial do projeto: exigir o campo arch em toda regra de syscall, marcar eventos com chaves (-k) e controlar a ordem de carregamento dos arquivos em /etc/audit/rules.d. Nenhum desses ajustes exige ferramenta nova; todos mudam a relação entre cobertura, ruído e custo.

Por que as regras viram ruído

O subsistema de auditoria do kernel intercepta cada chamada de sistema feita por todos os programas da máquina. A página de manual audit.rules(7) é direta sobre o custo: quanto mais regras de syscall, maior o impacto no desempenho, e combinar várias chamadas em uma única regra é a forma eficiente de escrevê-las. Uma regra que audita open, openat e openat2 em um só comando produz um evento por acesso relevante; dez regras separadas para o mesmo propósito multiplicam a avaliação no kernel sem acrescentar um byte de cobertura.

Ruído também nasce de regras que capturam sucesso e falha sem distinção. Falhas de permissão (EACCES e EPERM) têm valor investigativo alto, porque indicam tentativa de acesso negada, normalmente de processo mal configurado ou de alguém sondando o sistema. Já regras que registram toda abertura bem-sucedida de arquivo em um servidor de aplicação produzem milhões de eventos por hora e escondem exatamente o que a equipe queria ver. O desenho da regra decide se o log serve à detecção ou apenas ao armazenamento.

O campo arch muda tudo

Em máquinas bi-arquitetura, os números de syscall de 32 e 64 bits nem sempre coincidem. Segundo a documentação oficial, uma regra sem o campo arch faz o kernel avaliar todas as chamadas de sistema, o que afeta o desempenho — e, em sistemas de dupla arquitetura, você ainda corre o risco de auditar a syscall errada sem perceber, porque a consulta usa a tabela errada de números. A correção é mecânica: escrever duas regras, uma com -F arch=b32 e outra com -F arch=b64, cada uma consultando a tabela correta. O próprio auditctl avisa quando a regra é ambígua; ignorar esse aviso em produção é aceitar cegos na cobertura que você acredita ter.

Chaves organizam a investigação

A chave (-k) é texto livre inserido no evento para dar significado à regra. É o mecanismo que transforma uma pilha de logs em cobertura mensurável: com aureport --key --summary a equipe lista quais regras dispararam na semana e mede a proporção de sinal por chave. Regras que atendem a um mesmo requisito devem compartilhar a mesma chave, como -k acesso-negado em todas as regras de falha de permissão. Na prática de investigação, ausearch -k acesso-negado --raw | aureport --file --summary responde quais arquivos foram alvo de acesso negado, e a mesma busca com --user --summary mostra quem tentou. Sem chave, cada pergunta forense vira uma varredura manual em texto não estruturado, e o tempo de resposta cresce na hora em que ele mais importa. Esse registro estruturado é o que separa um log consultável de um depósito inútil no pós-incidente — o mesmo princípio de registrar o incidente para transformá-lo em lição aplicada.

Ordem, filtros e imutabilidade

No diretório /etc/audit/rules.d, os arquivos são processados em ordem numérica e o resultado importa: a ordem das regras importa porque o kernel aplica first match wins, ou seja, a primeira regra que corresponde encerra a avaliação. A convenção do projeto usa números para papéis: 10 para configuração do kernel e do auditctl, 20 para exceções que sobrepõem regras gerais, 30 para as regras principais, 40 para opcionais, 50 para específicas de servidor, 70 para regras locais e 90 para o arquivo de finalização que torna o conjunto imutável. Uma exclusão numerada depois da regra principal nunca dispara, e o erro é silencioso: o relatório continua saindo, apenas com o evento errado dentro.

Para cortar ruído sem perder eventos obrigatórios, o filtro exclude descarta tipos de mensagem inteiros — por exemplo, -a always,exclude -F msgtype=CRED_REFR — enquanto o kernel continua emitindo os eventos fixos de login, autenticação e anomalias exigidos por normas de segurança. O kernel oferece seis listas de filtragem, e saber onde cada regra mora evita both over-collection e buracos:

Filtro Papel
task Avaliado apenas em fork e clone; raro na prática.
exit Onde toda syscall e toda regra de arquivo é avaliada; é a lista das regras principais.
user Filtra eventos originados em userspace.
exclude Descarta eventos por tipo de mensagem; a ferramenta de corte de ruído.
filesystem Lista dedicada a eventos de sistema de arquivos.
io_uring Observa syscalls executadas sob operações io_uring.

Saúde do daemon e do disco

Trilha de auditoria que não cabe no disco não é trilha. O daemon monitora o espaço livre e emite avisos em níveis configuráveis antes de o disco de log encher, e o projeto recomenda reservar uma partição exclusiva em /var/log/audit, dimensionada pela política de retenção, para que nenhum outro processo consuma o espaço da auditoria. Para observar a saúde em produção, auditctl --signal state despeja métricas internas em /run/auditd.state, incluindo tamanho atual do log, espaço restante na partição e profundidade da fila de plugins — fila crescente indica que o consumo de eventos é mais lento do que a produção, outro sintoma de regras verbosas. O userspace oficial do projeto, que traz auditd, auditctl, ausearch e aureport, exige kernel 5.15 ou mais recente, o que deve ser verificado antes de qualquer plano de roll-out em frota antiga.

Checklist de revisão em produção

  • P1 — arch em toda regra de syscall: liste com auditctl -l e reescreva o que estiver sem arch como pares b32/b64.
  • P1 — chave em toda regra: regra sem -k não é mensurável; agrupe por requisito de cobertura.
  • P1 — ordem verificada: exceções (20) antes das principais (30); o arquivo de finalização (90) por último, só depois da revisão.
  • P2 — medir sinal por chave: rode aureport --key --summary semanalmente; a chave que domina o volume é candidata a exclusão ou reescrita.
  • P2 — disco e fila: partição exclusiva para /var/log/audit, teste de space_left e admin_space_left em ambiente próprio e monitoramento da fila de plugins.
  • P2 — critérios auditáveis no ambiente todo: quando a infraestrutura inclui Kubernetes, combine com kube-bench para auditar o cluster com critérios e mantenha uma única linguagem de cobertura.

A auditoria do kernel é a fonte mais rica de telemetria de host em Linux, mas só entrega valor quando cada regra tem propósito, arquitetura explícita, chave e posição deliberada. Revisar isso custa horas e devolve a capacidade de detectar; ignorar custa a investigação inteira no primeiro incidente.

Fontes