Отключение PowerShell и другие способы борьбы с Malware, Часть II

Автор оригинала: Andy Green
  • Перевод
Эта статья является частью серии «Отключение PowerShell и другие способы борьбы с Malware».

Смотрите также:

Часть I
• Часть II
• Часть III

Список разрешенных приложений – это вам не шутки. Сперва, придется начать с чистого листа, а затем осторожно добавлять туда безопасные приложения, которые вы знаете и доверяете. Это то, с чего мы начали развивать идею политик ограниченного использования программ (SRP) в прошлой раз.

image

Как вы помните, сперва мы расчистили «поляну», по умолчанию отключив выполнение приложений. В разделе дополнительные правила, затем я начал добавлять правила для приложений, которые были для меня важны.

Только те приложения, которые вам когда-нибудь понадобятся!

Очевидно, что это может стать немного утомительным занятием, так что Microsoft любезно предоставила два правила по умолчанию: одно, чтобы разрешить выполнение приложений в папке Program Files и второе – исполняемые файлы в системном каталоге Windows.

Но это тоже не совсем удобно, т.к. тогда уже вы будете должны вносить в черный список приложения, которые вам не нужны.

В любом случае, когда пользователь запускает неутвержденное приложение или хакер пытается загрузить некоторые вредоносные программы, которых нет в белом списке, SRP будет предотвращать это. Вот что произошло, когда я попытался запустить PowerShell, которого не было в моем белом списке, из старой доброй оболочки cmd, которая есть в списке:



Будьте вы прокляты политики ограничения программного обеспечения SRP!

100% Безопасности

Чтобы быть идеологически чистым, вам не стоит не использовать правила политик Windows по умолчанию. Вместо этого, вы должны начать с нуля и проделать всю тяжелую работу выясняя, какие приложения вами используются и действительно вам нужны.

Однако, чтобы помочь вам преодолеть это препятствие, компания Microsoft предлагает в статье TechNet включить ведение журнала SRP, куда делается запись, каждый раз когда SRP оценивает приложение. Нам потребуется включить следующую запись реестра и задать местоположение файла журнала:

1. «HKLM\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers»
2.
3. Строковое значение: LogFileName, <путь к файлу журнала>
Вот пример такого журнала из моей тестовой среды AWS.



Файл журнала операций SRP.

Затем вам надо будет просмотреть этот журнал, а также возможно опросить ваших пользователей или обсудить это с другими ИТ-администраторами. Предположим, в итоге у вас получился список разрешенных приложений (помимо самой оболочки PowerShell), которые, как вы считаете, нужны большей части ваших пользователей. Ну и в конце, вы можете используя консоль Управление Групповой политикой (GPMC) для публикации этих правил в домене.

В теории, у вас должно получиться перетащить правила через drag-and-drop из консоли Редактора Локальных Политик в консоль GPMC управления доменными политиками. Я не смог это провернуть в моей среде AWS.

Вместо этого мне пришлось воссоздать все правила непосредственно в Редакторе Групповых Политик (ниже) и затем позволил ему сделать всю остальную работу, «разливая» эти политики по всему домену — в моем случае, по домену Acme.
Настоящая Магия!





Вы можете прочитать об этом здесь.

Взглянем на AppLocker

Давайте теперь снова вернемся к вопросу с PowerShell. Мы же жить не сможем без него, но и «злобные» хакеры тоже любят его как отличный инструмент для скрытного исследования сети после своего внедрения внутрь.

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

Было бы неплохо, если бы правила SRP позволяли делать разрешенные списки выборочно на основе членства пользователей и групп в каталоге Active Directory. Другими словами, отключить в PowerShell, за исключением, если вы, скажем, ИТ-администратор, который состоит в специальной разрешенной PowerShell-группе AD.

Такого, однако, нет в SRP, так как он не поддерживает такой уровень детализации!
Тем не менее, начиная с Windows 7 (и Windows Server 2008), компания Майкрософт отказалась от SRP и представила более мощные функции AppLocker. Он очень похож, но при этом он имеет возможность фильтрации на уровне пользователя или группы.

Мы поговорим об AppLocker и некоторых его преимуществах в заключительном посте этой серии. В любом случае, вы сможете легко найти его рядом с политиками SRP в разделе Политик Управления Приложениями в Редакторе Групповой Политики GPMC.

Для моего окружения Acme, я создал правило, которое разрешает PowerShell только для пользователей группы Acme-VIPS, для небольшой группы опытных сотрудников. Смотрите ниже, где я начал это настраивать, используя диалоговое окно мастера настройки AppLocker:



PowerShell, несомненно, является важным и полезным инструментом, так что вам нужно взвесить все риски выборочного включения его через AppLocker — не побоюсь этого слова, выполнить оценку рисков.

При этом, у вас (конечно же) должны иметься вторичные элементы управления, такие как, хмм, Анализ Поведения Пользователей (UBA), что позволит вам защититься даже в случае полной компрометации учетных записей ваших администраторов, которым как правило разрешено все, например при взломе их логинов злоумышленниками или инсайдерами.

Пока же давайте оставим описание полезных функций AppLocker-а, а также мои итоговые умозаключения на тему белых списков до следующего поста.
Varonis Systems
51,01
Компания
Поделиться публикацией

Комментарии 0

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое