rkhunter сообщил об одном изменении файла на виртуальном сервере (двоичный файл netstat). Никаких других предупреждений не поступало. Изменение не было результатом обновления пакета (я переустановил его, и контрольная сумма вернулась к прежней).
Мне интересно, это повреждение файла или вторжение. Я предполагаю, что вторжение изменило бы многие другие файлы, за которыми следит rkhunter (или ни одного, если бы злоумышленник имел доступ к базе данных rkhunter).
Я разобрал оба двоичных файла с помощью objdump -d и сохранил разницу здесь: https://gist.github.com/3972886
Полный дамп diff, созданный с помощью objdump -s это здесь : https://gist.github.com/3972937
Я предполагаю, что повреждение файла изменило бы либо большие блоки, либо отдельные биты, а не такие маленькие блоки.
Эти изменения выглядят подозрительно? Как я могу исследовать больше?
В системе работает Debian Squeeze.
Я проверил несколько из них, и все они оказались однобитными ошибками. На этом этапе я бы подумал о замене жесткого диска, используя RAID / ZFS и т. Д.
Я согласен, это не вторжение, а какая-то аппаратная ошибка.
Я бы также подумал, есть ли у вас неисправная RAM-карта, и запустите memtest86 на хост-сервере - однобитовые ошибки также могут быть ошибками RAM без ECC. Если у вас есть ОЗУ с ECC, вы можете исключить это (каждый сервер, конечно, должен использовать ОЗУ с ECC, и предпочтительно ZFS для обнаружения повреждений ОЗУ и диска).
Также это может быть ошибка контроллера диска.
Как правило, стоит проверить свои журналы на наличие ошибок контроллера и диска и попытаться изолировать причину переворота битов - это только на одном диске, происходит ли это, если вы меняете местами RAM-карты и т. Д.
Если у вас есть инструмент резервного копирования, который выполняет контрольную сумму блоков данных или файлов, он будет действовать наподобие ZFS, обнаруживая более широкие повреждения в нескольких файлах.
Если это важный сервер, просто замена оперативной памяти и диска будет быстрым вариантом, позволяющим протестировать их в некритичной системе в автономном режиме.
Некоторая предыстория исследования ЦЕРН: http://storagemojo.com/2007/09/19/cerns-data-corruption-research/