Запретить обход политики выполнения powershell

У нас установлен Powershell в нашей среде RDS. В настоящее время он используется для таких задач, как удаленное управление и публикация виртуальных приложений App-V. Насколько я понимаю, довольно легко обойти политику ограниченного исполнения.

Однако я не могу найти никакой полезной информации о том, как предотвратить обход политики выполнения (или сделать ее намного сложнее). Я думал об использовании проверки файлов (applocker) для блокировки файлов ps, но я думаю, что тогда злоумышленники могли просто использовать сценарий VBA, прикрепленный к офисному файлу, для выполнения сценария powershell.

На данный момент мы сосредоточены на мониторинге, но я хотел бы больше внимания на предотвращение.

Источник

3 ответа

Решение

На самом деле, есть способы предотвратить неправильное использование Powershell (и сделать обход политики выполнения совершенно бесполезным):

  1. Настроить Applocker: также скрипты блокировки
  2. Настройте Powershell на использование режима Constrained Mode, чтобы код.NET не мог быть выполнен
  3. Для ваших собственных сценариев, которые должны поддерживать код.NET, вы можете подписать сценарии с помощью сертификата лица, подписывающего код (их можно запускать с ограниченным режимом + applocker)

Кроме того, настройка ведения журнала всех команд Powershell и их отправка через центральное местоположение (чтобы IDS мог контролировать это) также является хорошей практикой.

См. https://adsecurity.org/?p=2604 для получения более подробной информации о том, как этого добиться.

Источник

То, что вы пытаетесь достичь, бессмысленно, существуют десятки способов обойти политику выполнения, фактически она НЕ предназначена для обеспечения безопасности.

  1. Установите PS 5+ везде и реализуйте ведение журнала сценариев, вы можете поместить все журналы в общий каталог где-нибудь, чтобы проанализировать \ принять их
  2. удалить PS2 везде
  3. Блокировать макросы из файлов из Интернета
  4. Используйте белый список приложений

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

Источник

Это можно сделать, установив область действия «MachinePolicy» (или «UserPolicy»). Это можно сделать через редактор групповой политики, и его нельзя переопределить с помощью команды обхода. По умолчанию, если вы запуститеGet-ExecutionPolicy -Listв PowerShell вы, скорее всего, увидите оба параметра вверху как «Неопределено».

Чтобы изменить его, откройте редактор групповой политики и перейдите к:Computer Configuration > Administrative Templates > Windows Components > Windows PowerShellи откройте опцию под названиемTurn on Script Execution.

По умолчанию оно не настроено. Если вы установите его наDisabled, для MachinePolicy будет установлено значение «Ограничено». Если вы установите его наEnabledвы увидите раскрывающийся список, в котором можно выбрать другие политики, например только подписанные сценарии (Политика AllSigned).

Допустим, вы установили для него значение AllSigned. Затем, если кто-то попытается запустить команду типа:

Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope Process

Он ответит так:

Windows PowerShell updated your execution policy successfully, but the setting is overridden by a policy defined at a more specific scope. Due to the override, your shell will retain its current effective execution policy of AllSigned.

Если вы снова перечислите текущие политики выполнения, будет показана область, которую человек только что установил как имеющую эту политику выполнения. Однако даже если это, например, Bypass, на самом деле он не будет применяться, и MachinePolicy выиграет. Даже если PowerShell работает от имени администратора, MachinePolicy все равно будет применяться.

И вы также не можете просто изменить MachinePolicy через PowerShell, даже работая от имени администратора. Если вы это сделаете, он скажет:

Cannot set execution policy. Execution policies at the MachinePolicy or UserPolicy scopes must be set through Group Policy.

Для PowerShell 7:

Если вы используете PowerShell 7, который загружается отдельно (не путать с «Windows Powershell»), он будет использовать совершенно отдельные политики выполнения. Чтобы настроить для этого MachinePolicy, вам также необходимо использовать редактор групповой политики, но по умолчанию он там не будет найден.

Чтобы настройки PowerShell 7 отображались в редакторе групповой политики, вам необходимо запустить сценарий, включенный в вашу установку PowerShell 7, под названиемInstallPSCorePolicyDefinitions.ps1. Вы должны запустить это с помощью PowerShell 7 и, возможно, от имени администратора.

Теперь вы сможете найти эти настройки в GPE по адресу:Computer Configuration > Administrative Templates > PowerShell Core

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

Дополнительные замечания:

  • Другие упоминали использование AppLocker, что является хорошей идеей для повышения безопасности, но имейте в виду, что AppLocker НЕ блокирует полностью выполнение сценариев PowerShell, даже если вы явно создаете правило для блокировки определенного сценария. Вместо этого «Блокировка» сценария PowerShell в AppLocker просто запускает его в режиме «Ограниченный язык».

  • Чтобы изменить область действия «UserPolicy», вы делаете то же самое, что и выше, но вместо поиска в «Конфигурации компьютера» в редакторе групповой политики найдите соответствующие параметры в «Конфигурации пользователя».

Источник
Другие вопросы по тегам