Redes e Segurança

Auditoria e monitoramento com auditd e Falco

• 8 min de leitura

Auditoria e monitoramento com auditd e Falco
A segurança de sistemas Linux modernos exige visibilidade granular sobre o que acontece no kernel e nos processos em execução. Dois conceitos fundamentais sustentam essa visibilidade: logs de auditoria e monitoramento de runtime. Logs de auditoria registram eventos discretos como chamadas de sistema (syscalls), acessos a arquivos e alterações de configuração. Já o monitoramento de runtime analisa esses eventos em tempo real, aplicando regras contextuais para detectar comportamentos anômalos.

Auditoria e monitoramento com auditd e Falco

1. Introdução à auditoria e monitoramento em sistemas Linux

A segurança de sistemas Linux modernos exige visibilidade granular sobre o que acontece no kernel e nos processos em execução. Dois conceitos fundamentais sustentam essa visibilidade: logs de auditoria e monitoramento de runtime. Logs de auditoria registram eventos discretos como chamadas de sistema (syscalls), acessos a arquivos e alterações de configuração. Já o monitoramento de runtime analisa esses eventos em tempo real, aplicando regras contextuais para detectar comportamentos anômalos.

A diferença prática entre auditd e Falco reside em seus propósitos. O auditd é uma ferramenta nativa do Linux que captura syscalls e eventos do sistema de arquivos, ideal para compliance (PCI DSS, SOC 2) e auditoria forense. O Falco, mantido pela CNCF, é um motor de detecção de runtime que consome eventos do kernel (via eBPF ou driver) e aplica regras YAML para identificar ameaças como shells reversos, leitura de senhas ou execução de binários suspeitos.

Cenários típicos incluem:
- Compliance: demonstrar que arquivos críticos não foram alterados sem autorização
- Detecção de intrusão: alertar sobre spawn de shell em contêineres
- Troubleshooting: rastrear qual processo modificou um arquivo de configuração

2. Instalação e configuração básica do auditd

A instalação do auditd varia conforme a distribuição. No Debian/Ubuntu:

sudo apt update
sudo apt install auditd audispd-plugins
sudo systemctl enable auditd
sudo systemctl start auditd

No CentOS/RHEL:

sudo yum install audit
sudo systemctl enable auditd
sudo systemctl start auditd

O arquivo principal de configuração é /etc/audit/auditd.conf. Parâmetros essenciais:

log_format = ENRICHED     # Inclui metadados como UID e comando
max_log_file = 50         # Tamanho máximo de cada log em MB
max_log_file_action = ROTATE  # Rotaciona quando atinge o limite
space_left = 75           # Percentual de disco antes de alertar
space_left_action = SYSLOG   # Envia alerta para syslog

As regras de auditoria são definidas em /etc/audit/rules.d/. Exemplo inicial:

# /etc/audit/rules.d/audit.rules
-w /etc/passwd -p wa -k passwd_changes
-w /etc/shadow -p wa -k shadow_changes
-w /etc/ssh/sshd_config -p wa -k sshd_config
-a always,exit -F arch=b64 -S execve -k exec_audit

As regras carregam automaticamente na inicialização. Para aplicar manualmente:

sudo auditctl -R /etc/audit/rules.d/audit.rules

3. Criação de regras avançadas no auditd

O monitoramento de binários suspeitos é uma aplicação crítica. Exemplo: detectar execuções de wget e curl em servidores de produção:

# /etc/audit/rules.d/advanced.rules
-a always,exit -F arch=b64 -S execve -F path=/usr/bin/wget -k download_tool
-a always,exit -F arch=b64 -S execve -F path=/usr/bin/curl -k download_tool
-a always,exit -F arch=b64 -S execve -F path=/usr/bin/nc -k netcat

Para arquivos de configuração sensíveis, a regra deve capturar escritas (-p wa) e também leituras, se necessário:

-w /etc/sudoers -p wa -k sudoers_changes
-w /etc/group -p wa -k group_changes
-w /var/log/auth.log -p wa -k auth_log

O uso de chaves (-k) permite categorizar eventos. Exemplo com chaves para servidor web:

-w /var/www/html -p wa -k webserver_files
-w /etc/nginx/nginx.conf -p wa -k webserver_config
-a always,exit -F arch=b64 -S execve -F path=/usr/bin/php -k webserver_exec

4. Análise de logs com ausearch e aureport

O comando ausearch permite consultar eventos específicos. Exemplos práticos:

# Buscar eventos da chave 'passwd_changes' nas últimas 24 horas
sudo ausearch -k passwd_changes -ts today -te now

# Buscar execuções de comando pelo usuário 'root'
sudo ausearch -ua root -sc execve -i

# Buscar alterações no arquivo /etc/shadow
sudo ausearch -f /etc/shadow -i

O aureport gera relatórios resumidos:

# Relatório de eventos por hora
sudo aureport -t

# Relatório de eventos por usuário
sudo aureport -u

# Relatório de eventos de execução
sudo aureport -x

Exemplo prático: detectar tentativas de escalonamento de privilégio via sudo ou su:

sudo ausearch -sc execve -k exec_audit | grep -E 'sudo|su|pkexec'

Para gerar um relatório de autenticações falhas:

sudo aureport -au

5. Introdução ao Falco: monitoramento de runtime baseado em regras

O Falco pode ser instalado via script oficial ou pacotes. Método recomendado:

# Debian/Ubuntu
curl -s https://falco.org/repo/falcosecurity-3672BA8F.asc | sudo apt-key add -
echo "deb https://download.falco.org/packages/deb stable main" | sudo tee /etc/apt/sources.list.d/falcosecurity.list
sudo apt update && sudo apt install falco

A arquitetura do Falco é simples: um driver de kernel (ou eBPF) captura syscalls, que são enviadas para o processo falco, que aplica regras YAML. A saída padrão é stdout, mas pode ser redirecionada para syslog, arquivo ou webhook.

Primeira regra: detectar shell interativo em contêiner. Arquivo /etc/falco/rules.d/custom_rules.yaml:

- rule: Detect Shell in Container
  desc: Alerta quando um shell interativo é aberto em um contêiner
  condition: container.id != host and proc.name in (bash, zsh, sh, dash) and evt.type=execve
  output: Shell detectado em contêiner (user=%user.name container=%container.id process=%proc.name)
  priority: WARNING
  tags: [container, shell]

6. Criação de regras personalizadas no Falco

A sintaxe de regras Falco é declarativa. Exemplo de regra para detectar spawn de shell em diretórios não autorizados:

- rule: Shell in Unauthorized Directory
  desc: Shell executado em /tmp ou /dev/shm
  condition: evt.type=execve and proc.name in (bash, sh, zsh) and (proc.cwd startswith /tmp or proc.cwd startswith /dev/shm)
  output: Shell em diretório suspeito (user=%user.name cwd=%proc.cwd process=%proc.name)
  priority: CRITICAL
  tags: [shell, privilege_escalation]

Alerta para leitura de arquivos de senhas:

- rule: Read Sensitive File
  desc: Tentativa de leitura de /etc/shadow
  condition: evt.type=open and fd.name=/etc/shadow and evt.dir=<
  output: Leitura de shadow detectada (user=%user.name process=%proc.name)
  priority: EMERGENCY
  tags: [credential_access]

Monitoramento de montagem de dispositivos não esperados:

- rule: Unexpected Mount
  desc: Dispositivo montado em diretório não padrão
  condition: evt.type=mount and not fd.name startswith /mnt and not fd.name startswith /media
  output: Montagem inesperada (user=%user.name device=%fd.name)
  priority: WARNING
  tags: [mount, persistence]

Uso de macros para reutilização:

- macro: sensitive_files
  condition: fd.name startswith /etc/shadow or fd.name startswith /etc/gshadow or fd.name startswith /etc/ssh

- rule: Access Sensitive Files
  condition: evt.type=open and sensitive_files and evt.dir=<
  output: Acesso a arquivo sensível (file=%fd.name)
  priority: CRITICAL

7. Integração e alertas: auditd + Falco em produção

Para enviar logs do auditd para syslog, configure o audispd:

# /etc/audit/plugins.d/syslog.conf
active = yes
direction = out
path = /sbin/audisp-syslog
type = always
format = string

No rsyslog, crie um template para encaminhar ao ELK:

# /etc/rsyslog.d/auditd.conf
template(name="AuditdTemplate" type="string" string="auditd: %msg%\n")
if $programname == "auditd" then /var/log/audit_forward.log;AuditdTemplate
if $programname == "auditd" then @@elasticsearch-server:514

Para alertas do Falco via webhook, edite /etc/falco/falco.yaml:

json_output: true
json_include_message_property: true

program_output:
  enabled: true
  keep_alive: false
  program: "curl -X POST -H 'Content-Type: application/json' -d @- https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX"

Pipeline completo Falco → syslog → SIEM (Wazuh):

# /etc/falco/falco.yaml
syslog_output:
  enabled: true
  severity: warning

8. Boas práticas e otimização de performance

Para evitar sobrecarga no auditd, evite regras muito abrangentes como -a always,exit -S all. Em vez disso, seja específico:

# Ruim: captura todas as syscalls
-a always,exit -S all

# Bom: captura apenas syscalls relevantes
-a always,exit -F arch=b64 -S execve,open,openat,connect

No Falco, use filtros de prioridade para reduzir ruído:

# /etc/falco/falco.yaml
priority: warning

A rotação de logs no auditd deve considerar o espaço em disco:

# /etc/audit/auditd.conf
max_log_file = 100
max_log_file_action = ROTATE
num_logs = 5
space_left = 20
space_left_action = SYSLOG
admin_space_left = 10
admin_space_left_action = SUSPEND

Teste regras antes de aplicar em produção:

# auditd
sudo auditctl -l

# Falco
sudo falco --dry-run -r /etc/falco/rules.d/custom_rules.yaml

A combinação de auditd e Falco oferece uma camada dupla de defesa: o auditd fornece logs forenses detalhados para compliance, enquanto o Falco detecta ameaças em tempo real com regras contextuais. Juntos, eles formam a espinha dorsal de uma estratégia de segurança em sistemas Linux.

Referências

💬 Comentários
Mais em Redes e Segurança