Farik90
Junior Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Dimitr1s, Dacor
Цитата: А зачем они? При создании правила в HIPS, не контролируется целостность файла. Я вижу смысл создания правила в HIPS, в одном случае: не подписанное приложение, исполняемый файл которого постоянно обновляется, при компиляции например. Остальное проще и безопаснее реализовать с помощью мощной системы доверия к файлу. И HIPS будет работать в полном объёме (на новые/недоверенные приложения) и целостность файлов контролироваться.
Он хеш записывает, не?
При имеющемся правиле в HIPS - нет. Типо фича. |
Старые байки, где-то я это уже видел.
HIPS инструмент, с логикой работы которого разбираться нужно, чем прежде выводы делать.
Все вертится вокруг системы правил, причем явно прописанные правила, относящиеся к пути, имеют приоритет над неявными, относящимися к системе рейтинга файлов.
Что это означает. У нас есть два списка, с одной стороны список путей с правилами, с другой стороны список хешей и подписей файлов с присвоенным рейтингом (рейтинги = фиксированные неявные наборы правил, их всего три: доверенный, неопознанный и вредоносный), и конфликты между двумя списками решается с помощью приоритета одного над другим.
Уже исходя из такого понимания утверждение "При создании правила в HIPS, не контролируется целостность файла" не соответствует действительности. На попытку объяснить это XenoZ и предложение проверить самостоятельно, я получил ответ что "брызжу слюнами" и прочий троллинг.
Упрощенно HIPS работает так:
исполняемый файл пытается проявить некую активность, которая контролируется HIPS
->
если к пути файла есть правило HIPS, которое которое явно контролирует эту активность (разрешение или запрет),
то активность контролируется им.
если нет, то комод смотрит на рейтинг хеша/подписи файла, и
если файл в доверенных, то он может проявлять любую активность, кроме запуска недоверенных файлов.
Для запуска появляются следующие варианты:
1) доверенный файл запускает другой доверенный, алерта нет.
2) доверенный запускает недоверенный, вызывает алерт, на который вы можете создать разрешающее правило, это будет значить что программа по пути A может запустить программу по пути B. В формулировке правила никакого "контроля целостности" действительно нет, но его не было и прежде. Если вы делаете все запускаемые файлы доверенными вручную, о последствиях абзацем ниже.
3) случай когда недоверенный файл пытается запустить другой вызовет алерт в любом случае, кроме того запускающий недоверенный сам может быть запущен лишь с помощью правила или явного разрешения пользователя.
Таки откуда растут ноги у подобного беспокойства об оригинальности файлов? Раз предполагается, что некая другая программа может их изменить, рассмотрим возможные сценарии подробнее (допустим даже наш пользователь работает под админом, и полагаться можно только на HIPS).
Когда вы подменяете файл вручную, вы делаете это через explorer.exe - доверенную программу. В случае же некоего malware, ему потребуется:
1) запускающей программе разрешение на запуск malware.
2) malware разрешение на модификацию исполняемых файлов и файлов, лежащих в защищенных директориях.
Всем подряд вы ведь подобные разрешения не даете?
Либо же malware должно получить разрешения автоматически, став доверенным:
1) Вероятность того, что оно будет иметь легитимную подпись из базы Comodo, которая не протухнет к моменту достижения вашего компьютера, оцените самостоятельно.
2) Остается вариант, при котором вы сами, вручную делаете malware доверенным, дав ему полную свободу действий. Такой сценарий вероятен как раз таки, если вы вручную делаете запускаемые файлы доверенными, пытаясь сделать себе этот самый "контроль".
И кстати, совсем не факт, что malware станет трогать ваш "контроль целостности". Особого смысла дополнительно модифицировать уже присутствующие на компьютере программы нет, кроме небольшого усложнения лечения домашним пользователем изнутри ОС. И то многие АВ умеют запускаться до загрузки ОС, а уж образы загрузочных дисков/флешек есть почти у всех. Популярность подобных приемов в прошлом, поскольку ускоряет обнаружение malware в песочницах.
Вообще, безопасность в Windows начинается с Windows, а не со сторонних продуктов. Работа под ограниченным пользователем защищает установленные программы и системные файлы, а Software Restriction Policy не позволяет запустить ничего лишнего (и разрешить запуск портативных программ по хешу/подписи). Системы, которые с такими зафиксированными конфигурациями стоят годами без АВ. Это встроенные в Windows средства, и любой админ будет использовать их в первую очередь, если безопасность важна. Единственная причина по которой такая настройка не используется повсеместно, состоит в удобстве обновления и установки программ (тем более в ручном режиме), и кривой софт, требующий полные права (что обходится запуском программы под отдельным пользователем, что опять же, требует настройки).
Если же вы пренебрегаете встроенными средствами Windows и при этом вручную делаете запускаемые файлы доверенными в комоде, то, как говорится, "поздно пить боржоми". В случае malware с правами админа и полным доступом к файловой системе от комода, об неприкосновенности установленных программ я бы беспокоился в последнюю очередь.
Соответственно правила HIPS придуманы больше не для того, чтобы не дать возможности запуститься malware (заметьте, даже правила, разрешающее запуск, относятся к запускающей программе, а не к той, которую запускают), а для того, чтобы ограничить свободу действий легитимных программ (где как раз и возникают проблемы и уязвимости, которые не решаются встроенными средствами).
Для примера: имеем софт системы бухучета. Взломан сайт разработчика и заменен дистрибутив программы. Или допустим прога подписана и взломан сервер разработки — украден ключ подписи и выложено новое "обновление".
1) Доверяем:
Вы скачиваете/обновляете программу, делаете ее доверенной вручную или через подпись и даете полную свободу действий полезной нагрузке.
2) Ограничиваем:
Программа бухучета изначально особых разрешений не требует — доступ к диску, к межпроцессорной памяти, установке хуков, к защищенным файлам по-умолчанию не открыт. Когда после обновления появляется неожиданный запрос от HIPS, запрещаем и думаем. Если режим "без оповещений", то читаем журнал и узнаем об обломавшейся атаке.
Для домашнего использования тоже пара примеров:
• Условно-бесплатные программы, которые несут с собой нежелательные элементы. Слепое доверие вас не защитит, а если не доверять и ограничить активность необходимыми правилами, можно сохранив плюсы, избавиться от минусов.
• Патченая программа, можно ли ей доверять? Для несистемной программы, ограниченной правилами HIPS (если лень думать, можно собрать их при использовании оригинальной) вопрос доверия обычно не возникает.
От тех, кто собирается дальше топить за "целостность контроля", хотелось бы услышать комментарии по следующим пунктам:
1) Что вам мешает сделать как на скринах ниже, без всяких комодов:
 
2) Опишите сценарий, при котором malware (пусть даже запущенное от админа) может изменить файлы других программ без получения разрешения на это, и без присвоения рейтинга доверенной программы. |
Всего записей: 120 | Зарегистр. 23-05-2011 | Отправлено: 03:06 17-07-2019 | Исправлено: Farik90, 03:18 17-07-2019 |
|
