rkhunter avisa sobre alteração de inode, mas nenhuma alteração de data de modificação de arquivo

Question

Eu tenho vários sistemas rodando o Centos 6 com o rkhunter instalado. Eu tenho um cron diário rodando o rkhunter e me reportando via e-mail.

Frequentemente recebo relatórios como:

---------------------- Start Rootkit Hunter Scan ----------------------
Warning: The file properties have changed:
        File: /sbin/fsck
        Current inode: 6029384    Stored inode: 6029326
Warning: The file properties have changed:
        File: /sbin/ip
        Current inode: 6029506    Stored inode: 6029343
Warning: The file properties have changed:
        File: /sbin/nologin
        Current inode: 6029443    Stored inode: 6029531
Warning: The file properties have changed:
        File: /bin/dmesg
        Current inode: 13369362    Stored inode: 13369366

Pelo que entendi, o rkhunter geralmente relata um hash alterado e / ou data de modificação nos arquivos digitalizados, então isso me leva a pensar que não há nenhuma mudança real.

Minha pergunta: existe alguma outra atividade na máquina que poderia fazer a mudança de inode (executando o ext4) ou isso é realmente yum fazendo alterações regulares (uma vez por semana) para esses arquivos como parte das atualizações normais de segurança?

    

Answer 1

A atualização de arquivos geralmente é feita por meio da gravação de um novo arquivo no mesmo diretório, seguido pela renomeação do arquivo na parte superior do arquivo antigo. Esse método é geralmente aplicado a tudo que é instalado através de um gerenciador de pacotes, mas também a qualquer atualização executada em executáveis e bibliotecas, mesmo que seja atualizada por outros motivos.

Esta forma de atualizar arquivos garante que qualquer processo que abra o arquivo receba o antigo ou o novo e não veja nada que esteja mudando no arquivo que eles abriram. Isso significa que, cada vez que for atualizado, você terá um novo arquivo com o mesmo nome, portanto, o número do inode foi alterado.

Eu acho que essa é a razão para esses arquivos terem um novo número de inode.

Uma atualização de segurança pode ser um dos motivos. Mas há outra possibilidade, que eu observei primeiro no Fedora Core 1, e que poderia muito bem ter chegado ao Centos em algum momento.

Os executáveis e as bibliotecas estão sendo pré-vinculados, de modo que possam começar mais rapidamente e usar menos memória. Durante esse processo, o endereço de carregamento é randomizado para dificultar um pouco a exploração de vulnerabilidades de segurança. Um cron job periodicamente repetia o processo com novos endereços aleatórios, fazendo com que todos os executáveis e bibliotecas pré-configurados fossem atualizados.

    

Answer 2

A outra opção que encontrei foi desativar completamente esses testes de propriedades. Se você editar /etc/rkhunter.conf e procurar a linha DISABLE_TESTS e alterá-la para:

DISABLE_TESTS="suspscan hidden_procs deleted_files packet_cap_apps apps properties"

O teste properties é aquele que verifica e retorna falsos positivos nos hashes do arquivo.

    

Answer 3

Um número de inode alterado geralmente significa que o arquivo foi substituído. Pode, como você diz, ser devido a uma atualização esperada. Eu verificaria se os md5sums desses arquivos correspondem aos das versões distribuídas. Se você tiver outro sistema comparável, pode ser mais fácil comparar com isso.

Dê uma olhada na resposta aceita em o rkhunter reporta mudanças nas propriedades dos arquivos, mas não vejo que eles tenham sido atualizados pelo yum para saber de que pacote esses binários são.

Não seria muito surpreendente se esses binários fossem de uma distribuição que foi atualizada devido a um problema com outro binário que foi alterado, mas os binários que você listou foram incluídos na nova versão do pacote inalterada. Seu relatório também mostrou algum binário em que o conteúdo foi alterado?