Olhando para corridas de tripwire recentes, uma noite cerca de uma semana atrás, o tripwire detectou 11042 arquivos alterados que mudaram somente na contagem de blocos, não em tamanho, CRC32, MD5, inode ou qualquer outra coisa . Todos os arquivos que mudaram dessa forma que eu verifiquei no log do tripwire são oito blocos maiores. Se eu ignorar os arquivos que mudaram apenas na contagem de blocos, todas as outras mudanças são mudanças esperadas que eu sei que fiz, ou mudanças esperadas como arquivos de log mudando.
Para o contexto, este servidor falhou abruptamente em 19 de junho, então substituí a placa-mãe, mas mantive os discos. (Os discos são muito mais novos do que a placa-mãe.) Este sistema está no Fedora 23. O tripwire rodado às 3 da manhã de 20 de junho não encontrou nenhuma diferença. Em 20 de junho, abri o computador novamente para substituir uma placa de rede que não estava funcionando depois da troca da placa-mãe. O tripwire executado às 3 da manhã de 21 de junho é o primeiro a detectar todos os arquivos com uma contagem de blocos alterada.
rkhunter não se queixou de nada, pelo que vale a pena.
Dado que, para os arquivos em questão, absolutamente nada mudou exceto a contagem de blocos, e que todos os tipos de objetos obtiveram 8 blocos maiores (arquivos, diretórios, até mesmo links simbólicos), estou razoavelmente certo de que isso não é hacking. Mas não estou confiante de que seja benigno. Como um link simbólico pode ir de 0 a 8 blocos? Mas tudo parece estar funcionando bem.
O que poderia causar isso? Eu deveria me preocupar? Meu backup completo mais recente (rsync para unidade externa) foi feito na noite do dia 20, então provavelmente depois do que mudou aqui. Nenhum dos arquivos alterados estão em / boot ou / home ou / var (todos os quais são sistemas de arquivos separados para o que vale a pena). Na verdade, apenas arquivos foram alterados dessa maneira. O / filesystem é um espelho de ataque, se isso importa.