Conceito e funcionamento
Auditd registra eventos conforme regras carregadas, políticas do kernel, estado do serviço e recursos disponíveis. Sua presença não prova cobertura integral; regras devem responder a objetivos definidos. O evento pode conter múltiplos registros vinculados por serial, como syscall, caminho e contexto de usuário.
Como investigar e correlacionar
Verifique auditctl -s e -l, use ausearch por período e tipo e relacione eventos com host, serial e processo. Considere relógio, rotação e tamanho de buffer. Ao estabelecer regras novas, calcule volume e teste em ambiente autorizado antes de ativar em produção.
Consulta ou exemplo orientativo
Execute somente em ambiente autorizado, com privilégios e ferramentas adequados. A saída depende da configuração da fonte.
sudo auditctl -s
sudo auditctl -l
sudo ausearch -m USER_LOGIN -ts recent -iESTUDO DE CASO · CENÁRIO SINTÉTICO
Aplicação em uma investigação
Situação
O serviço auditd está ativo, mas mudanças em um arquivo sensível não aparecem nas consultas do SOC.
Procedimento orientado
Revise regras com auditctl -l, estado de backlog e tipo de evento; reproduza uma alteração autorizada apenas no laboratório.
Resultado esperado
A saída deve mostrar se a regra cobria o caminho e se houve perda ou rejeição, com evidências de coleta.
Cuidados adicionais
Ativar regras amplas sem medir volume pode encher logs e aumentar perda de eventos.
Limitações e interpretações incorretas
Regras extensivas podem degradar desempenho ou preencher armazenamento. Ausência de dados pode decorrer de falta de regra, perda de backlog ou retenção insuficiente. A ferramenta deve ser usada com controle de acesso.
Checklist de validação
- Confirmar serviço e regras
- Checar backlog e perda
- Filtrar por tipo e período
- Preservar serial e registros associados
Referências técnicas
Guias para aprofundar
- hardening linux oracle rhel9 — aguardando publicação editorial
- preservacao evidencias timeline — aguardando publicação editorial