O controlo de integridade tem uma propriedade incómoda: precisa de uma referência tirada de um sistema seguramente limpo. Se o servidor corre há três anos e a pergunta sobre uma intrusão surge só hoje, para essa referência já é tarde: registaria como normal aquilo que lá está.

No Debian e no Ubuntu, porém, a referência já existe, e não é sua: cada pacote instalado traz as somas de verificação dos seus próprios ficheiros. A comparação não exige configuração nem instantâneo prévio e funciona em qualquer sistema a qualquer momento. A ferramenta chama-se debsums.

Utilização

sudo apt install debsums
sudo debsums -c

A opção -c imprime apenas os ficheiros que não correspondem à referência. Sem ela a saída é um relatório linha a linha de cada ficheiro do sistema, dezenas de milhares de linhas.

A verificação leva alguns minutos e carrega o disco, pelo que num servidor em produção convém corrê-la com prioridade baixa:

sudo ionice -c3 nice -n19 debsums -c

Como ler o resultado

Uma saída vazia significa que todos os ficheiros verificados correspondem ao que a distribuição instalou. Uma saída não vazia exige análise, e os achados dividem-se em duas classes muito diferentes.

Ficheiros de configuração em /etc. Alterá-los é trabalho normal: editou o sshd_config, configurou o nginx, acrescentou parâmetros do núcleo. Essas divergências são esperadas. Para não incomodarem existe um modo à parte:

sudo debsums -e -c

-e verifica apenas os ficheiros de configuração: por vezes útil para ver a lista de tudo o que alterou nesta máquina.

Executáveis e bibliotecas. Uma divergência em /usr/bin, /usr/sbin, /bin ou /usr/lib é exatamente aquilo para que a verificação foi lançada. Causas legítimas existem, mas poucas: o ficheiro foi alterado à mão durante uma depuração, foi aplicado um patch de terceiros, o pacote estava a ser atualizado durante a verificação. Se nada disso encaixa, é altura de investigar a sério.

Os alvos clássicos de uma substituição são ls, ps, netstat, ss, find, sshd. Uma versão substituída esconde na sua saída as linhas que interessam, e todas as suas verificações seguintes deixam de dizer a verdade.

A cobertura é incompleta, e isso deve saber-se

Um limite de que normalmente não se fala: nem todos os pacotes fornecem somas de verificação. Os ficheiros desses pacotes não são verificados de todo e não aparecerão no relatório em circunstância nenhuma. A lista consulta-se assim:

sudo debsums -l

Um relatório limpo do debsums significa, portanto, «na parte verificada está tudo bem» e não «o sistema não foi alterado». O mesmo vale para tudo o que foi instalado à margem do gestor de pacotes: compilado a partir das fontes, descarregado como binário, colocado por um script do sítio do programador; disso o debsums nada vigia por definição, e é precisamente aí que faz falta o AIDE.

Execução periódica

O pacote traz uma tarefa pronta, ativada em /etc/default/debsums:

CRON_CHECK=weekly

Uma vez por semana é uma frequência razoável: a verificação carrega sensivelmente o disco e os ficheiros de sistema mudam pouco entre atualizações. Corrê-la diariamente não acrescenta nada além de carga.

Se um ficheiro foi mesmo substituído

O primeiro impulso é reinstalar o pacote e recuperar o original:

sudo apt install --reinstall coreutils

O comando é correto, mas não como primeira ação. Um binário de sistema substituído significa que alguém teve root, e repor o ficheiro não resolve esse problema: apenas destrói os rastos. A ordem tem de ser a inversa: primeiro guardar uma cópia do ficheiro suspeito e a sua hora de modificação, ver o que mais mudou no mesmo período, verificar as tarefas de cron, as chaves SSH e a lista de utilizadores. Repor só depois.

Lembre-se também dos limites do método: se o sistema estiver profundamente comprometido, o próprio debsums e as bibliotecas que usa podem ter sido substituídos também. Uma verificação a partir de dentro não pode dar garantia absoluta: isso faz-se arrancando a partir de um suporte externo. Para o trabalho diário, porém, chega: a esmagadora maioria dos ataques é automatizada e não tem essa sofisticação.

O seu lugar no conjunto

O debsums é valioso porque não exige nada e funciona de imediato, o que faz dele um ponto de partida cómodo para um servidor cuja história desconhece. A sua fraqueza é a cobertura incompleta e o desconhecimento de tudo o que está instalado fora dos pacotes. O par «debsums mais AIDE» fecha os dois lados: a referência já pronta da distribuição para os ficheiros de sistema e o seu próprio instantâneo para o resto.

Como sempre, a questão não é corrê-lo, mas ter à vista o último resultado com a sua data. Como fica mostra-o a demonstração abaixo.