Как проверить и поправить здоровье системы
Речь идет об обнаружении возможных повреждений системных и пользовательских файлов, и действиях, которые по ними предпринимаются.
Файлы могут повредиться например, в результате аппаратных сбоев и действиях хакеров и эксплоитов, модифицирующих родные файлы или подсовывающие свои.
Поскольку работаю с RPM-based системах, то сначала речь пойдет о них.
В менеджере пакете RPM есть такая команда:
rpm -Va
Она проверяет установленные пакеты на соответствие оригиналу если не ошибаюсь, путем сличения подписями с контрольными сумамми и в случае расхождения выдает сообщения.
Например, получилось нижеследующее. Кто подскажет, что теперь с этим добром нужно делать?
В итоге хотелось бы собрать в этой теме практические рекомендации и по другим апробированным методам тестирования и лечения системы, например, OSec, AIDE и т.д.
Потому что что они означают, всем известно – достаточно заглянуть в man.
комментариев: 9796 документов: 488 редакций: 5664
Не скажу насчёт OSec, но AIDE — просто проверка изменений контрольных сумм. Если таким путём пытаться находить злонамеренные изменения в бинарниках, то это надо выключить компьютер и физически примонтировать носитель с подозреваемой операционкой в режиме read-only на системе с доверяемой чистой операционкой и проверять из под неё. А поскольку проверка это обычно длительная и разбор изменений — утомителен, то это мало кто может себе позволить.
К тому же это надо делать регулярно, чтобы была какая-то информативность на фоне накопившихся изменений. И опять же, злонамеренный руткит может подождать естественого обновления пакетов и внедриться на этом этапе. Если у него есть права на то, тобы подменить бинарник, то у него есть и возможность поломать отображение электронных подписей сумм. А какие именно суммы должны быть после изменения — каждый раз вручную не отследишь.
И вообще — лечить систему бесполезно, только если интересно узнать способ, как её взломали, выудить эксплойт. В большинстве случаев нужно ставить с нуля, перенося со старой только некоторые данные и конфиги.
Это рекомендация или вопрос?
И что делать, если токие ошибки сразу обнаруживаются в только что установленной системе? Т.е. видимо идут от нерадивого производителя.
комментариев: 9796 документов: 488 редакций: 5664
С RPM-based давно не сталкивался. Так что, вы быстрее найдёте ответ на ресурсах поддержки вашего дистрибутива. Если это возникает после установки, может это вообще штатная ситуация — не знаю. Например, по зависимостям или по конфигам ставятся не все компоненты пакета, а затем проверка показывает, что часть компонентов отсуствует — как у вас, поскольку проверяется всё подряд, а, к примеру, не так, как должно быть при установке. Мне механизм этой проверки до конца неясен, могу только предполагать.
При правильной инфраструктуре, когда идёт работа с виртуалками, а всё страшное запускается только в гостевых ОС, для которых есть чистый бекап, это сделать просто: сравниваем чистый бэкап с актуальной версией, рассматриваем diff'ы. Например, rdiff-backup умеет. А вот постфактум установить, что было, когда соответствующей инфраструктуры не заложено, уже не получится (unknown всё правильно сказал).