rkhunter alerta para alteração de inode, mas nenhuma data de modificação de arquivo é alterada

Eu tenho vários sistemas executando o Centos 6 com o rkhunter instalado. Eu tenho um cron diário executando o rkhunter e relatando por e-mail.

Muitas vezes 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 normalmente reportará um hash e / ou data de modificação alterados nos arquivos verificados, o que me leva a pensar que não há mudanças reais.

Minha pergunta: existe alguma outra atividade na máquina que possa fazer a alteração do inode (executando ext4) ou isso realmente está yumfazendo alterações regulares (~ uma vez por semana) nesses arquivos como parte das atualizações de segurança normais?

A atualização de arquivos geralmente é feita escrevendo um novo arquivo no mesmo diretório e depois renomeando o arquivo sobre o arquivo antigo. Esse método geralmente é aplicado a tudo instalado por meio de um gerenciador de pacotes, mas também a qualquer atualização executada em executáveis ​​e bibliotecas, mesmo que atualizada por outros motivos.

Essa maneira de atualizar arquivos garante que qualquer processo de abertura do arquivo fique com o antigo ou o novo e não veja nada mudando no arquivo que eles abriram. Isso significa que, sempre que for atualizado, você realmente terá um novo arquivo com o mesmo nome; portanto, o número do inode foi alterado.

Acho que esse é o motivo desses arquivos terem um novo número de inode.

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

Executáveis ​​e bibliotecas estão sendo pré-vinculados para que possam iniciar mais rapidamente e usar menos memória. Durante esse processo, o endereço de carregamento é randomizado para tornar a exploração das vulnerabilidades de segurança um pouco mais difícil. Um trabalho cron repetiria periodicamente o processo com novos endereços aleatórios, fazendo com que todos os executáveis ​​e bibliotecas pré-vinculados fossem atualizados.

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

DISABLE_TESTS="suspscan hidden_procs deleted_files packet_cap_apps apps properties"

O propertiesteste é o que verifica e retorna falsos positivos nos hashes do arquivo.

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 que o md5sums desses arquivos corresponde 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 nos relatórios do rkhunter que mudam nas propriedades do arquivo, mas não vejo que eles tenham sido atualizados pelo yum para saber como verificar 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 alguns binários em que o conteúdo foi alterado?

Eu clonei uma unidade em uma unidade maior e recebi os avisos de arquivos com diferentes números de inodes. Eu removi o rkhunter do sistema e reinseri e executei o scann novamente sem nenhum aviso sobre o número de inodes sendo alterado