auditd: auditoria de eventos de segurança no Linux

auditd é o sistema de auditoria nativo do kernel Linux, registra em log todo sudo executado, acesso a arquivos sensíveis, mudanças em configurações críticas e tentativas de escalada de privilégio. Em caso de incidente de segurança, o auditd é a prova forense que mostra exatamente o que aconteceu e quando.

Instalar e configurar o auditd

Instalação e configuração básica do auditd no Ubuntu:

bash
# Instalar auditd:
sudo apt install -y auditd audispd-plugins

# Verificar status:
sudo systemctl status auditd
sudo auditctl -s          # status do subsistema de auditoria

# Verificar configuração atual de regras:
sudo auditctl -l

# Arquivo de configuração: /etc/audit/auditd.conf
# Configurações recomendadas:
sudo nano /etc/audit/auditd.conf

# Principais parâmetros:
# log_file = /var/log/audit/audit.log
# max_log_file = 100          # MB por arquivo de log
# max_log_file_action = ROTATE # rotacionar ao invés de parar
# num_logs = 10               # manter 10 arquivos rotacionados
# space_left = 500            # MB livres antes de alertar
# space_left_action = SYSLOG  # logar alerta quando espaço baixo

# Reiniciar após mudanças:
sudo systemctl restart auditd

Regras de auditoria para segurança

Regras para rastrear eventos críticos de segurança:

bash
# /etc/audit/rules.d/security.rules
# Carregar após criar: sudo service auditd restart

# Deletar todas as regras existentes:
-D

# Aumentar buffer de kernel para evitar perda de eventos:
-b 8192

# Tornar regras imutáveis (requer reboot para mudar):
# -e 2

# ── Mudanças de identidade e privilégio ──────────────────
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/sudoers -p wa -k sudoers
-w /etc/sudoers.d/ -p wa -k sudoers

# ── Uso de sudo e su ─────────────────────────────────────
-w /bin/su -p x -k privilege_escalation
-w /usr/bin/sudo -p x -k privilege_escalation

# ── Comandos de rede ─────────────────────────────────────
-w /sbin/iptables -p x -k network_modification
-w /sbin/ip -p x -k network_modification

# ── Acesso a chaves SSH ──────────────────────────────────
-w /root/.ssh -p rwa -k ssh_access
-w /home/ -p rwa -k ssh_home_access

# ── Arquivos de configuração do sistema ──────────────────
-w /etc/ssh/sshd_config -p wa -k sshd_config
-w /etc/nginx/ -p wa -k nginx_config
-w /etc/cron.d/ -p wa -k cron_modification
-w /etc/crontab -p wa -k cron_modification

# ── Execuções suspeitas ──────────────────────────────────
-w /tmp -p x -k tmp_execution
-w /var/tmp -p x -k tmp_execution

Consultar logs de auditoria

Pesquisar eventos de auditoria com ausearch e aureport:

bash
# Ver todos os eventos de hoje:
sudo ausearch --start today | head -50

# Buscar por chave (regra específica):
sudo ausearch -k sudoers -i | tail -30

# Buscar por usuário:
sudo ausearch -ua 1000 -i | tail -20

# Buscar por tipo de evento:
sudo ausearch -m USER_CMD -i | tail -20     # comandos executados com sudo
sudo ausearch -m EXECVE -i | tail -20       # qualquer execução

# Relatório resumido de logins:
sudo aureport --login

# Relatório de uso de sudo:
sudo aureport --comm | head -20

# Relatório de falhas de autenticação:
sudo aureport --auth --failed

# Relatório de execuções a partir de /tmp:
sudo ausearch -k tmp_execution -i

# Ver log bruto:
sudo tail -f /var/log/audit/audit.log

Detectar comandos suspeitos em tempo real

Monitorar auditoria em tempo real e configurar alertas:

bash
# Seguir log de auditoria em tempo real:
sudo ausearch --start recent -i | tail -f

# Script simples de alerta para Telegram quando sudo é usado:
#!/bin/bash
# /opt/scripts/audit-alert.sh (chamado pelo audisp/syslog)
EVENT=$(ausearch -k privilege_escalation --start recent -i 2>/dev/null | tail -5)
if [ -n "$EVENT" ]; then
    curl -s -X POST "https://api.telegram.org/botTOKEN/sendMessage" \
      -d "chat_id=CHAT_ID" \
      -d "text=🔐 Sudo usado na VPS:%0A${EVENT}"
fi

# Plugin audispd para encaminhar para syslog/SIEM:
sudo apt install audispd-plugins
sudo nano /etc/audisp/plugins.d/syslog.conf
# active = yes

# Encaminhar para servidor de logs centralizado (rsyslog):
# /etc/rsyslog.d/audit.conf:
# if $programname == 'audit' then @SIEM_SERVER:514
# & stop

Análise forense após incidente

Usar o auditd para investigar o que aconteceu após um incidente:

bash
# Investigar atividade de um usuário específico:
sudo ausearch -ua 1001 --start "01/01/2026 00:00:00" \
             --end "06/07/2026 23:59:59" -i | grep -E "EXECVE|USER_CMD"

# Ver todos os arquivos acessados por um processo:
sudo ausearch --pid 12345 -i

# Reconstruir linha do tempo de um incidente:
sudo ausearch --start "06/07/2026 10:00:00" \
             --end "06/07/2026 12:00:00" -i \
  | awk '/type=USER_CMD/ {print $0}' | head -50

# Verificar se houve modificação em arquivos críticos:
sudo ausearch -k identity -i \
  | grep "type=PATH" | grep "nametype=CREATE|nametype=DELETE"

# Exportar log completo de um período para análise offline:
sudo ausearch --start "06/07/2026 00:00:00" -i \
  > /tmp/audit_$(date +%Y%m%d).log

Não quer configurar manualmente?

Implante o VPS em menos de 5 minutos com a Runstack. Infraestrutura da OPEN Datacenter, com servidores em São Paulo.

Perguntas frequentes

journald captura logs de serviços systemd mas não tem granularidade de segurança. auditd opera no nível do kernel, captura chamadas de sistema, acesso a arquivos, mudanças de UID/GID e execuções, independente do serviço. Para auditoria de segurança séria: auditd é indispensável. journald pode ser usado como complemento para correlacionar eventos de serviços.

Com regras bem calibradas: overhead típico de 2-5% de CPU. Regras muito amplas (como auditar todos os EXECVE) podem gerar volume enorme de logs e impacto maior. Comece com regras específicas (sudoers, SSH, /etc) e expanda conforme necessário. Use -b 8192 para aumentar o buffer e evitar perda de eventos sob carga.

Encaminhar os logs imediatamente para servidor externo de logs (SIEM, Elastic, Graylog) via rsyslog. Com -e 2 (imutable mode): as regras do auditd não podem ser alteradas sem reboot. Considere enviar logs para bucket S3/MinIO imutável (object lock). Um atacante com root pode sempre apagar logs locais, a defesa real é a exfiltração em tempo real.

Configure max_log_file = 100 (MB por arquivo) e num_logs = 10 para manter rotação automática. Se space_left_action = SUSPEND, o servidor para de auditar quando o disco está cheio, altere para ROTATE ou SYSLOG. Para servidores com muito tráfego: refine as regras para só capturar o essencial ou aumente o disco/partition dedicado para /var/log/audit.

auditd no host monitora chamadas de sistema de todos os processos, incluindo os dentro de containers. Eventos de containers aparecem nos logs mas sem identificação clara do container. Para auditoria específica de containers: use Falco (cloud-native runtime security) que entende o contexto de containers e pods Kubernetes.