O auditd responde às perguntas que só surgem depois do sucedido: quem alterou este ficheiro, quando foi criado este utilizador, de onde foi iniciado este processo. Nenhuma outra ferramenta lhes responde: nos registos das aplicações essa informação não existe, e o histórico de comandos é alterado por quem o deixou.

A dificuldade é que instalar o pacote, por si só, não traz nada. Regras por omissão praticamente não há, o diário é escrito mas está vazio no essencial, e isso descobre-se no pior momento: quando os dados fazem falta e não estão lá.

Instalação

sudo apt install auditd audispd-plugins
sudo systemctl status auditd

Uma particularidade: em algumas versões o auditd não reinicia com systemctl restart, o serviço governa-se por um comando próprio. As regras relêem-se assim:

sudo augenrules --load
sudo auditctl -l

O segundo comando mostra o que está realmente carregado. Acredite nele, não no conteúdo dos ficheiros.

O conjunto de regras

As regras colocam-se em /etc/audit/rules.d/ como ficheiro à parte. Segue-se um conjunto mínimo que compensa: responde à maioria das perguntas de um incidente sem entupir o disco.

sudo tee /etc/audit/rules.d/50-baseline.rules <<'EOF'
## Utilizadores e privilégios
-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 privileges
-w /etc/sudoers.d/ -p wa -k privileges

## Acesso SSH
-w /etc/ssh/sshd_config -p wa -k sshd_config
-w /root/.ssh/ -p wa -k ssh_keys

## Tarefas agendadas
-w /etc/crontab -p wa -k cron
-w /etc/cron.d/ -p wa -k cron
-w /var/spool/cron/ -p wa -k cron

## Módulos do núcleo
-w /sbin/insmod -p x -k modules
-w /sbin/modprobe -p x -k modules
-a always,exit -F arch=b64 -S init_module -S delete_module -k modules

## Utilização de sudo e su
-w /usr/bin/sudo -p x -k privileged
-w /bin/su -p x -k privileged
EOF
sudo augenrules --load

A sintaxe é curta: -w é um caminho a vigiar, -p wa significa reagir a escritas e alterações de atributos, -p x à execução, -k é a chave por que se procurará depois. Essas chaves são a comodidade principal: sem elas, procurar no diário passa a ser percorrer um gigabyte de texto.

O que não consta dessa lista e porquê

Os guias propõem muitas vezes registar todas as chamadas execve, ou seja, cada arranque de cada programa. A tentação percebe-se: um retrato completo das ações. Na prática, num servidor em produção isso produz centenas de megabytes por dia, consome uma parte apreciável do processador e leva a truncar o diário antes de ele fazer falta. Se esse nível de detalhe for necessário, ative-o de forma pontual: para um utilizador, ou durante uma investigação.

O mesmo vale para vigiar a pasta do sítio: ali escreve-se sem parar, e a regra transforma o diário numa torrente de eventos sem sentido.

A leitura

Procura por chave, com os identificadores numéricos resolvidos em nomes:

sudo ausearch -k identity -i
sudo ausearch -k privileges -i -ts today

A opção -i é indispensável para a legibilidade: sem ela obterá números em vez de nomes de utilizadores e de chamadas de sistema. -ts limita o período (today, recent ou uma data concreta).

Um resumo por período:

sudo aureport --summary -i
sudo aureport --auth -i --failed

Num registo de evento interessam três campos: auid, o identificador do utilizador que iniciou a sessão, uid, a identidade com que a ação decorreu, e exe, o programa que a executou. A diferença entre auid e uid é a resposta a «quem exatamente se tornou root»: uid=0 com o auid de uma pessoa concreta aponta o responsável sem ambiguidade, seja qual for a identidade que assumiu dentro da sessão.

O disco

As definições de volume estão em /etc/audit/auditd.conf:

max_log_file = 50
num_logs = 5
max_log_file_action = ROTATE
space_left = 500
space_left_action = SYSLOG

Veja à parte o disk_full_action. Algumas configurações trazem por omissão a paragem do sistema quando o disco enche: comportamento justificado em máquinas com obrigações de auditoria e completamente deslocado num servidor web. Verifique esse valor antes de o disco encher.

O modo de regras imutáveis

A linha -e 2 no fim do ficheiro de regras proíbe alterá-las até ao reinício, mesmo a quem obteve root. Isso aumenta nitidamente o valor do diário: um intruso não pode desligar a vigilância sem reiniciar a máquina, e um reinício nota-se por si.

O reverso é evidente: também você não poderá mudar as suas regras sem reiniciar. Ative-o quando o conjunto tiver assentado e tiver convivido um mês com ele.

Para quê num servidor vulgar

O auditd não impede nada. O seu valor manifesta-se exatamente uma vez: quando é preciso reconstruir a sequência dos acontecimentos, e os dados ou existem ou não. Não se recolhem a posteriori, por isso o conjunto de regras prepara-se de antemão e depois deixa-se em paz.

Um sinal prático de que a configuração está certa: a lista de regras não está vazia, o diário não cresce sem controlo, e os eventos com as chaves identity e privileges aparecem raramente e cada um pode ser explicado. Como fica numa página mostra-o a demonstração abaixo.