id: Гость   вход   регистрация
текущее время 15:28 18/04/2024
Автор темы: Гость, тема открыта 01/05/2014 01:55 Печать
Категории: инфобезопасность, операционные системы
http://www.pgpru.com/Форум/UnixLike/КакПроверитьИПоправитьЗдоровьеСистемы
создать
просмотр
ссылки

Как проверить и поправить здоровье системы


Речь идет об обнаружении возможных повреждений системных и пользовательских файлов, и действиях, которые по ними предпринимаются.
Файлы могут повредиться например, в результате аппаратных сбоев и действиях хакеров и эксплоитов, модифицирующих родные файлы или подсовывающие свои.
Поскольку работаю с RPM-based системах, то сначала речь пойдет о них.
В менеджере пакете RPM есть такая команда:


rpm -Va


Она проверяет установленные пакеты на соответствие оригиналу если не ошибаюсь, путем сличения подписями с контрольными сумамми и в случае расхождения выдает сообщения.


Например, получилось нижеследующее. Кто подскажет, что теперь с этим добром нужно делать?


В итоге хотелось бы собрать в этой теме практические рекомендации и по другим апробированным методам тестирования и лечения системы, например, OSec, AIDE и т.д.



 
Комментарии
— Гость (01/05/2014 02:07)   <#>
На всякий случай уточню вопрос – именно что нужно с этим добром делать, чтобы устранить найденные ошибки?
Потому что что они означают, всем известно – достаточно заглянуть в man.
— unknown (01/05/2014 12:24)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Что делать — переустанвливать пакеты, пока суммы не сойдутся? Вот только если там качественный целенаправленный руткит, то такая проверка не поможет.


Не скажу насчёт OSec, но AIDE — просто проверка изменений контрольных сумм. Если таким путём пытаться находить злонамеренные изменения в бинарниках, то это надо выключить компьютер и физически примонтировать носитель с подозреваемой операционкой в режиме read-only на системе с доверяемой чистой операционкой и проверять из под неё. А поскольку проверка это обычно длительная и разбор изменений — утомителен, то это мало кто может себе позволить.

К тому же это надо делать регулярно, чтобы была какая-то информативность на фоне накопившихся изменений. И опять же, злонамеренный руткит может подождать естественого обновления пакетов и внедриться на этом этапе. Если у него есть права на то, тобы подменить бинарник, то у него есть и возможность поломать отображение электронных подписей сумм. А какие именно суммы должны быть после изменения — каждый раз вручную не отследишь.

И вообще — лечить систему бесполезно, только если интересно узнать способ, как её взломали, выудить эксплойт. В большинстве случаев нужно ставить с нуля, перенося со старой только некоторые данные и конфиги.
— Гость (01/05/2014 17:44)   <#>

Это рекомендация или вопрос?
И что делать, если токие ошибки сразу обнаруживаются в только что установленной системе? Т.е. видимо идут от нерадивого производителя.
— unknown (01/05/2014 22:04)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Это риторический вопрос. В смысле, замечание о (не)целесообразности таких проверок. Проверка в момент установки имеет смысл, чтобы понять, что пакет пришёл на систему целым и неизменённым. По какой причине его компоненты меняются на системе, сама по себе это проверка не выяснит, она может даже этого не показывать если система под контролем умного руткита.

С RPM-based давно не сталкивался. Так что, вы быстрее найдёте ответ на ресурсах поддержки вашего дистрибутива. Если это возникает после установки, может это вообще штатная ситуация — не знаю. Например, по зависимостям или по конфигам ставятся не все компоненты пакета, а затем проверка показывает, что часть компонентов отсуствует — как у вас, поскольку проверяется всё подряд, а, к примеру, не так, как должно быть при установке. Мне механизм этой проверки до конца неясен, могу только предполагать.
— Гость (30/05/2014 06:49)   <#>

При правильной инфраструктуре, когда идёт работа с виртуалками, а всё страшное запускается только в гостевых ОС, для которых есть чистый бекап, это сделать просто: сравниваем чистый бэкап с актуальной версией, рассматриваем diff'ы. Например, rdiff-backup умеет. А вот постфактум установить, что было, когда соответствующей инфраструктуры не заложено, уже не получится (unknown всё правильно сказал).
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3