Фреймворк конфигурации и управления политиками Software Restriction Policies — III

ЧАСТЬ ТРЕТЬЯ. КОНФИГУРАЦИЯ БЛОКИРУЮЩИХ ПОЛИТИК.

Какое количество политик (объектов GPO) создать, в каких ситуациях следует создавать дополнительные политики? На это влияют следующие факторы:

  • Раздельные реализации AWL: AppLocker или SRP;
  • Возможность раздельного отключения политик для определённых контейнеров АД. Например, когда требуется временно выключить AWL для одного-двух департаментов, но не выключать для всех остальных;
  • Делегирование управления. Если компания имеет представительства в различных странах (например, Латвия и Россия), и в каждой стране имеется своя IT-поддержка, то для базовой политики SRP я предпочту создать два дополнения: SRP Workstations LV и SRP Workstations RU. Затем можно делегировать управление этими дополнениями IT-отделам соответствующих стран, разрешив конфигурацию базовой политики только доменным администраторам;
  • Разбиение большого количества дополнительных правил на несколько GPO. Количество правил может зависеть в том числе и от политических установок руководства компании. Например, IT-директор может заявить «да, наши пользователи устанавливают программы дезорганизованно, но сделайте AWL так, чтобы им ничего не пришлось переделывать». Такая позиция потребует применить сотни путей и хэшей, которые будет лучше разнести по нескольким GPO согласно структуре департаментов или другому признаку;
  • Существенные различия в конфигурации AWL: например, для департамента продаж, где все сотрудники работают с ограниченными привилегиями, можно включить AWL, нацеленный только на стандартных пользователей, в то время как для компьютеров химического анализа, где все сотрудники обладают привилегиями администратора, следует задействовать фильтрацию всех пользователей, в том числе администраторов.

Для типичной компании я применяю следующий набор политик:

  • SRP Audit Only, которая уже была описана ранее, подключается к корневой папке домена. Её же можно будет задействовать для создания исключений из общих правил. Например, подключить к специальному контейнеру, чтобы помещаемые в него компьютеры могли работать без ограничений AWL;
  • SRP Template, шаблон с первичной конфигурацией для создания всех новых блокирующих политик;
  • SRP Servers Baseline, задействующая основные, общие для большинства серверов «белые списки». Политика нацеливается на контейнер Servers, содержащего учётные записи всех серверов домена (кроме контроллеров), а также контейнер Domain Controllers;
  • SRP Workstations Baseline, содержащая базовую, общую для большинства рабочих станций конфигурацию «белых списков». Политика нацеливается на контейнер Computers, содержащую учётные записи всех рабочих станций. Действие политики распространяется и на стандартных пользователей, и на администраторов;
  • SRP Workstations Baseline NoAdmins. Отличие этой политики от предыдущей в том, что её действие распространяется только на стандартных пользователей, но не на членов локальной группы Администраторов.

 

Для компаний достаточно большого размера могут потребоваться несколько дополнительных политик:

  • SRP Servers %ServerRole%, являющиеся расширениями основной политики для группы серверов, играющих особые роли — например, терминальных серверов. Потребность в таких расширениях может возникнуть в компании с достаточно большим количеством серверов и делегированным управлением;
  • SRP Workstations %Attribute%, являющиеся расширениями основной политики для отдельной группы рабочих станций. Признаком группы может быть страна, департамент, делегирование управления отдельному IT-персоналу или особый функционал (например, компьютеры SCADA).

 

В общем случае, количество политик следует свести к минимуму. Любая политика SRP состоит из двух частей: общая конфигурация и дополнительные правила (Additional Rules), в которых прописаны все пути, хэши, сертификаты. Когда к доменному компьютеру применяется одновременно несколько политик, их общая часть перезаписывается обычным методом LSDOU («кто ближе, тот и прав»), а вот дополнительные правила (пути, хэши) суммируются (подробнее о сложении политик: https://sysadmins.lv/blog-en/software-restriction-policies-rule-ordering.aspx). Как результат, для корректной обработки некоторых изменений вам может потребоваться вносить их во все ваши SRP GPO, либо для какой-то из политик верхнего уровня установить принудительный режим применения (Enforced), что может вызвать дополнительные сложности управления.

 

Какие конкретно параметры блокирующих политик задать?

Некоторые параметры будут общими для большинства блокирующих политик SRP. Их можно сразу отразить в шаблоне SRP Template:

  • В репозитории политик создайте новый объект SRP Template. Подключать его никуда не потребуется;
  • В разделе Computer Configuration > Policies > Windows Settings > Security Settings > Software Restriction Policies создайте новую конфигурацию SRP;
  • В подразделе Security Levels назначьте правило по умолчанию: Disallowed;
  • В объекте Designated File Types удалите LNK;
  • В объекте Enforcement укажите параметр Apply To: All Software Files;
  • В объекте Enforcement укажите параметр Apply To: All Users;
  • В подразделе Additional Rules удалите все встроенные правила и добавьте новые: C:\Windows\, C:\Program Files\, C:\Program Files (x86)\. Причиной такой переконфигурации является некорректная обработка переменных при вызовах исполняемых модулей со сменой архитектуры. Например, когда 64-разрядный Outlook вызывает на исполнение 32-разрядный Acrobat Reader при открытии PDF-приложения к письму, переменная %ProgramFilesDir% не обновляется, и встроенные правила необоснованно срабатывают на отказ (то есть, случается false positive);
  • Сразу же можно добавить пути, гарантированно требующиеся для всех компьютеров домена. Например, это могут быть пути вида \\WindowsNT.LV\NetLogon\ для исполнения сценариев входа и загрузки и \\DeploymentServer\Install\ для сервера распространения программ, \\FileServer\Applications\ для сервера приложений.

SRP Template

 

На базе SRP Template создайте объекты SRP Baseline:

  • В репозитории политик скопируйте объект политики SRP Template и вставьте три копии для Baseline-объектов;
  • В подразделе Additional Rules скорректируйте или добавьте пути, которые требуется всем компьютерам, подпадающим под действие конкретной Baseline-политики;
  • Для политики SRP Workstations Baseline NoAdmins параметр Enforcement переключите в Apply To: All Users except Local Administrators.

 

В какой последовательности и к каким контейнерам Active Directory подключать созданные объекты политик?

  • Одно из важнейших предварительных условий — структурирование учётных записей компьютеров по контейнерам Active Directory (Organizational Unit, OU). Ситуации, когда SRP можно задействовать сразу на всю компанию без структурирования, очень редки. Как правило, это или маленькие компании с числом рабочих станций до ста, или заведения с большим количеством унифицированных рабочих станций — например, университет;
  • В типичной компании для рабочих станций я задействую AWL последовательно, раз в неделю подключая политику к каждому следующему выбранному OU. Когда все подразделения будут задействованы, политика подключается к контейнеру более высокого уровня и отключается от всех дочерних контейнеров;
  • Перед включением политики для очередного подразделения следует провести аудит запускаемых программ и принять решение, что делать с файлами, загружаемыми из нестандартных мест. Если будет принято решение эти программы добавить в «белые списки», оцените, не следует ли создать отдельный SRP GPO для этой компании/страны/подразделения;
  • Возможно, для некоторых компьютеров «с наскоку» включить AWL не получится из-за большого количества нестандартных программ. В текущем OU создайте подконтейнер SRP Audit Only, туда же подключите политику SRP Audit Only и переместите эти компьютеры. Они могут оставаться в «подвешенном» состоянии некоторое время, чтобы не задерживать ход проекта;
  • Для серверов логика включения AWL может несколько отличаться. Сначала создайте подконтейнер SRP Audit Only и подключите к нему политику SRP Audit Only. Поместите все серверы в этот контейнер и по очереди вытаскивайте в родительский OU, к которому будет подключена политика SRP Servers Baseline. Учтите, что для полноценного первого включения SRP требуется делать рестарт системы!
  • Если метод «OU by OU» не подходит, вы можете создать группу вида WindowsNT Servers SRP-Enabled, куда добавлять учётные записи серверов по мере внедрения проекта. К контейнеру Servers подключите политику SRP Servers Baseline, но укажите право её применения только указанной группе. Недостаток этого метода в том, что он может требовать дополнительного рестарта для вступления членства в группе в силу;

SRP Audit Only

 

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

  • Какие-то программы придётся объявить неразрешёнными. Например, если пользователь скачал игру и запускает её из папки своего профиля;
  • Какие-то версии программ придётся запретить, но предоставить сотрудникам правильные версии альтернативным способом. Например, пользователь установил себе браузер Firefox Portable и обосновывает его наличие рабочей необходимостью. В этом случае версию Portable лучше заблокировать, но предоставить сотрудникам возможность установки поддерживающую массовое распространение и групповые политики версию FireFox Community Edition подсредством WSUS или SCCM;
  • Какие-то программы можно переместить на сервер распространения или сервер приложений. Например, если сотрудникам отдела техподдержки требуются утилиты SysInternals, вы можете опубликовать их в доступной только для чтения общей папке, путь до которой уже добавлен в политику;
  • Какие-то программы можно переместить во внесённую в AWL доступную для записи локальную папку вида C:\Applications. Сотрудники, занимающиеся тестированием или обновлением различных версий программ, смогут сохранять и запускать оттуда всё необходимое. Разумеется, они смогут сохранить туда также и неразрешённые программы, но риски случайного запуска вируса из приложенного к письму файла всё же будут снижены;
  • Какие-то необходимые для работы программы можно задекларировать в AWL. Вам нужно будет только решить, добавить ли их в GPO Baseline или создать новую политику, расширяющую AWL для нужд конкретного подразделения, что зависит в том числе от факторов, описанных в начале статьи.

 

В следующей части я расскажу, как поддерживать компьютеры, защищённые политиками AWL.

 

 

 

 

Реклама

14 Responses to Фреймворк конфигурации и управления политиками Software Restriction Policies — III

  1. Добрый вечер, Петр.
    У вас нет проблем с блокировкой файлов с расширением «URL»? Причём, такая лажа на разных компьютерах (XP, 7, 10). Такое впечатление, что где-то на уровне ОС нет сопоставления этого типа файлов с приложением и система игнорирует запуск таких файлов. А вот на уровне пользователя сопоставление есть и ярлык благополучно открывается в браузере. С расширением «WEBSITE» (к своему стыду, только сегодня узнал о нём) такой проблемы нет.

  2. И как это лечить? И потом, Вы пробовали пнуть по этому поводу Microsoft? Или им до лампочки, как и всем остальным?

    • Обычно с Microsoft общается Вадик, и обычно они ему отвечают, что им до лампочки .) Типа «SRP is not a security feature». В общем, именно про URL я не напрягался потому, что это всего лишь ссылка, почти то же самое, что пользователь щёлкнет на ссылке в письме.

      • Добрый день.

        С URL-ми какая-то мистика. Я пользуюсь Google Chrome и по умолчанию проблем с открытием им URL-файлов нет (видимо, потому, что он назначен основным браузером). Но зато, есть проблема с блокировкой в SRP этих файлов. Оказалось, что на уровне пользователя эта проблема решается ручным выставлением сопоставления типа файла браузеру. То есть ситуация странная, с одной стороны тип файлов без проблем открывается в браузере, а с другой стороны ОС делает вид, что этому типу нет сопоставленной программы. Но, после ручного сопоставления, с одной стороны начинает правильно срабатывать SRP, а с другой стороны, Google Chrome начинает отрывать URL-файлы как текстовые, напрочь забыв как правильно это делать. Эта смешная и бредовая проблема лечится установкой в Google Chrome дополнения под названием «.URL Handler». Вот такая странная и смешная ситуация.

        Петр, Вы уже пользуетесь Windows 10? Я перешёл на неё примерно год назад (пришлось, т.к. купил новый ноутбук, старый ещё нужен, а Win 7 купить уже нельзя). Так вот, с самого начала использования ОС, к своему удивлению, обнаружил, что SRP как-то странно блокирует файлы PS1. Если просто запустить файл PS1, то он блокируется, а вот если командой «PowerShell C:\Temp\Test.PS1», то скрипт отрабатывает. С CMD таких сюрпризов нет, а в Win7 подобных сюрпризов нет и с PS1.

      • Что-то припоминаю, что где-то я убирал расширение URL из списка SRP. Связано было с тем, что люди не могли щёлкать на ссылки в почте. Взвесив плюсы и минусы, решил, что пусть щёлкают. Поэтому вот.

        Что касается поведения PowerShell, это они сделали преднамеренно. При запуске PS генерирует ничего не значащие ps-файлы в пользовательском Temp именно для проверки, нет ли Application Whitelisting. Если есть, то PowerShell переходит в усечённый режим с ограничением списка доступных команд.
        https://windowsserver.uservoice.com/forums/301869-powershell/suggestions/13332018-software-restriction-policy-constrained-language

  3. Насчёт ссылок в почте и URL Вы немного напутали, т.к. ссылки будут работать вне зависимости от блокировки URL. Но, это так, к слову.

    О PowerShell и SRP. Если скрипт запускается с административными правами, то можно убрать распространение SRP на администраторов (тогда Language Mode будет FullLanguage) и проблем нет. А вот если нужно запускать скрипт в среде пользователя с ограниченными правами? Или, если права ограничены, то ограниченного языкового режима (Language Mode — ConstrainedLanguage) вполне хватает? И как защититься от попытки запустить вредоносный скрипт?
    Как Вы с этим боритесь? Или в Ваших «владениях» это проблем не создаёт? Что показывает Ваш опыт?

    • Constrained Mode распространяется только на интерактивный режим и скрипты, лежащие за пределами Whitelisting, вот тут они объясняют: https://blogs.msdn.microsoft.com/powershell/2015/06/09/powershell-the-blue-team/

      Свои скрипты я раскидываю в пути типа C:\Windows, оттуда всё работает. Интерактивный режим нужен только для отладки, в этом случае можно запустить консоль PS при политике, переключённой в Blacklisting. В общем, особых проблем пока не создаёт.

  4. Спасибо, понял.

    А как защититься от запуска вредоносных скриптов (например, пролезших через уязвимость в стороннем ПО или ОС), кроме выключения PowerShell? Я, например, SRP использую, в основном, для защиты от таких ситуаций. Хоть работа скрипта и ограничена в своих возможностях, но по здравой логике, если мы блокируем что-то в SRP, то это не должно запускаться и точка. А тут получается, что «всё» условно. Как бы работает, как бы защищено. По мне так, это примерно то же самое, что ключ под ковриком.

    • «Пролезших через уязвимость» означает, что код уже исполнился, это больше не ваш компьютер. Это уже случилось, блокировать дальше скрипты? Сомнительное занятие. Не путайте запуск дополнительных программ и уже исполнившийся код .)

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

  5. Да нет, Вы что-то напутали. Вот Вам реальный пример. Правда, давно было. WinXP (лицензия, регулярно обновлялась и на момент инцидента была полностью обновлена), с помощью IE зашли на сайт скачать книжки. Через уязвимость в папку с учетной записью пользователя (возможно, в Temp, уже не помню) записался исполняемый файл и запустился, ещё зачем-то туда же записались два заражённых PDF-файла (это не те файлы, которые качал пользователь). Я так и не понял, зачем зараженные PDF, если вместе с ними проникает EXE-файл, но этот исполняемый заблокировал учетную запись. УЗ была ограниченной, так что больших проблем не было. Я тут же установил Google Chrome и зашёл им на ту же страницу – тишина, это к вопросу о браузерах. Хотя, допускаю, что мог бы быть и обратный вариант. Антивирус был установлен (уже не помню какой), но он EXE-шник «прохлопал ушами». SRP на тот момент не использовал, что, естественно, было ошибкой. Возможно, такие уязвимости и редкость, но исключать их мы не можем. И потом, если что-то защищено, значит, попытка обойти защиту будет неудачной, иначе это не защита, а профанация. Конечно, могут быть такие уязвимости, против которых SRP бессильна, но как говорится «против лома нет приёма, если нет другого лома».

    • Для того, чтобы что-то записать в папку и что-то запустить, атакующему нужно исполнить свой код. В котором указать URL и имя файла, например. Такие упражнения легко выполняются в metasploit.

      SRP часто предотвращает запуск скачанного эксплоитом ехе-шника, но это лишь потому, что атакующий поленился интегрировать его напрямую в эксплоит или выполнить memory injection. На самом деле, следует понимать, что код атакующего таки исполнился.

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

%d такие блоггеры, как: