Эта статья является частью серии «Отключение PowerShell и другие способы борьбы с Malware».
Смотрите также:
• Часть I
• Часть II
• Часть III
Список разрешенных приложений – это вам не шутки. Сперва, придется начать с чистого листа, а затем осторожно добавлять туда безопасные приложения, которые вы знаете и доверяете. Это то, с чего мы начали развивать идею политик ограниченного использования программ (SRP) в прошлой раз.
Как вы помните, сперва мы расчистили «поляну», по умолчанию отключив выполнение приложений. В разделе дополнительные правила, затем я начал добавлять правила для приложений, которые были для меня важны.
Только те приложения, которые вам когда-нибудь понадобятся!
Очевидно, что это может стать немного утомительным занятием, так что 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-а, а также мои итоговые умозаключения на тему белых списков до следующего поста.
Смотрите также:
• Часть I
• Часть II
• Часть III
Список разрешенных приложений – это вам не шутки. Сперва, придется начать с чистого листа, а затем осторожно добавлять туда безопасные приложения, которые вы знаете и доверяете. Это то, с чего мы начали развивать идею политик ограниченного использования программ (SRP) в прошлой раз.
Как вы помните, сперва мы расчистили «поляну», по умолчанию отключив выполнение приложений. В разделе дополнительные правила, затем я начал добавлять правила для приложений, которые были для меня важны.
Только те приложения, которые вам когда-нибудь понадобятся!
Очевидно, что это может стать немного утомительным занятием, так что 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-а, а также мои итоговые умозаключения на тему белых списков до следующего поста.