AIDE: reparar que um ficheiro foi substituído

O controlo de integridade responde a uma pergunta a que nem um antivírus nem uma firewall respondem: o que mudou neste servidor desde a semana passada? Um analisador por assinaturas procura o malicioso conhecido; o AIDE nada sabe de malícia, sabe que este ficheiro ontem era diferente. Para detetar uma porta traseira acrescentada a um ficheiro existente, é a única abordagem que funciona.

O AIDE instala-se com dois comandos. Configurá-lo para que os seus relatórios sejam lidos é a parte difícil, e é precisamente isso que costuma matá-lo: o primeiro relatório chega com dez mil linhas, ninguém abre o segundo, e um mês depois a tarefa é apagada.

Instalação e primeira base

sudo apt install aide aide-common
sudo aideinit

A inicialização leva de poucos minutos a meia hora: calculam-se as impressões de todos os ficheiros. O resultado fica ao lado da base de trabalho com o sufixo .new e tem de ser posto em serviço:

sudo mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db

A partir daí, uma verificação lança-se assim:

sudo aide --check

O que excluir para o relatório continuar legível

As definições estão em /etc/aide/aide.conf e na pasta /etc/aide/aide.conf.d/. A configuração Debian que vem de origem verifica demasiado, e a primeira coisa a fazer é retirar o que muda sozinho constantemente:

• /var/log: muda a cada segundo;
• /var/lib por inteiro: bases de dados, estado dos pacotes, estado dos serviços;
• /var/cache, /tmp, /proc, /sys, /run;
• as pastas de carregamentos e de cache do sítio: o seu conteúdo é alterado pelos visitantes.

O que vale a pena verificar com as definições mais estritas é uma lista curta:

• /bin, /sbin, /usr/bin, /usr/sbin: os executáveis do sistema;
• /lib, /usr/lib: as bibliotecas;
• /etc: a configuração;
• /root/.ssh e as pastas .ssh dos seus utilizadores;
• o código do sítio, mas sem as pastas de carregamentos e de cache.

A referência: um relatório diário vulgar deve caber num ecrã. Se for mais longo, as exclusões são insuficientes e deixará de ser lido.

Onde guardar a base

Um ponto essencial que muitas vezes escapa. Se um estranho tiver root, substituir um ficheiro e atualizar logo a base do AIDE não lhe custa nada, e a verificação seguinte comunicará que está tudo bem. Uma base que fica na mesma máquina e com permissão de escrita só protege de acidentes.

Um mínimo razoável para um servidor único:

• copiar a base para outra máquina depois de cada atualização e correr a verificação repondo essa cópia;
• ou pelo menos guardar à parte a soma de verificação da base e compará-la antes da verificação:

sha256sum /var/lib/aide/aide.db

Mesmo uma medida tão simples transforma uma substituição silenciosa num acontecimento visível.

Atualizar a base é um ato deliberado

Depois de alterações legítimas — uma atualização do sistema, uma versão nova do sítio — a base reconstrói-se:

sudo aide --update
sudo mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db

O momento importa. Correto: ler o relatório, garantir que cada alteração se explica, e só então atualizar. Incorreto e muito comum: correr o aide --update de forma agendada para que os relatórios saiam limpos. No segundo caso o sistema funciona, os relatórios chegam, e as alterações ficam registadas como normais precisamente no momento em que ocorrem: o sentido perde-se por completo.

Agendamento e carga

O pacote aide-common instala por si uma tarefa diária. A verificação carrega o disco e o processador durante alguns minutos, pelo que convém correr a uma hora tranquila e com prioridade baixa:

0 4 * * * ionice -c3 nice -n19 /usr/bin/aide --check

Como ler o relatório

Três secções: ficheiros acrescentados, removidos e alterados. Para cada alteração indica o que difere exatamente: conteúdo, permissões, proprietário, data.

A que reagir primeiro:

• uma alteração em qualquer ficheiro de /bin, /sbin, /usr/bin fora de uma janela de atualização;
• ficheiros novos em pastas do sistema;
• alterações em authorized_keys, /etc/passwd, /etc/sudoers, /etc/crontab e /etc/cron.d;
• o aparecimento de um ficheiro /etc/ld.so.preload: nunca aparece sozinho.

Cem ficheiros alterados logo depois de apt upgrade é normal, e a hora do relatório confirma-o. Três ficheiros alterados em /usr/bin numa quarta-feira sem atualizações é motivo para parar e ver.

AIDE e debsums

As ferramentas resolvem problemas vizinhos, mas a sua referência difere. O AIDE compara com um instantâneo próprio, pelo que vê alterações em quaisquer ficheiros, código do sítio incluído. O debsums compara com as somas de verificação dos pacotes da distribuição, pelo que vê ficheiros de sistema substituídos sem preparação nenhuma, mas nada sabe do que instalou fora dos pacotes. Ter ambos é razoável; na prática o debsums costuma vir primeiro, porque não exige configuração nem base.

Partilham também uma fraqueza: o relatório chega por correio, e o correio perde-se. O que importa, portanto, não é que a verificação tenha corrido, mas que exista um sítio onde o seu último resultado esteja à vista. Como fica mostra-o a página de demonstração abaixo.