Vadims Podans's blog - Security | AppLocker

Очередной баг в AppLocker (обновление)

Camelot — Mon, 23 Aug 2010 18:09:10 GMT

Некоторое время я описал баг в AppLocker'е, который заключается в некорректной обработке правил пути, если путь содержит неанглийские буквы (подробнее см. Очередной баг в AppLocker). Как я уже говорил, я открыл кейс в саппорте и обещал отписаться, если будут какие-то новости. И я выполняю своё обещание публикацией официального ответа Microsoft:

We've investigated the issue and it appears to be a problem in the implementation of case-insensitive path comparison for characters outside the ASCII range. Fortunately it seems there is a workaround for the time being. If, in Local Security Policy, one specifies paths in all-uppercase characters, including uppercasing any non-ASCII characters as appropriate, then the rule will match properly. Concretely, for your example 'Mapīte', putting that string with lowercase ī in a rule's path in Local Security Policy will not work; however putting the string 'MAPĪTE' with uppercase Ī does seem to work.

Т.е. если путь содержит буквы верхней таблицы ASCII (символы 128 и выше), путь следует прописывать заглавными буквами. Я уже собрался наваять костыль на пошике, который будет делать это за меня (за счёт использования метода String.ToUpper()), но очень быстро обломался, поскольку консоль пошика не способна отображать диактрические знаки и скопировать правильный путь из консоли не удастся и всю работу по озаглавливанию букв придётся делать вручную.

PowerShell Powered - http://www.sysadmins.lv

Будущее AppLocker'a

Camelot — Sun, 25 Jul 2010 12:03:52 GMT

Уже прошёл почти год моего опыта использования AppLocker'а в домашних, тестовых и производстенных условиях и я хотел бы поделиться своими впечатлениями об этом со стороны перспективы использования этой технологии. К сожалению (а может и к счастью?) эту технологию постиг эпик фейл. И это даже при весьма удачной технической реализацией, которая более удобная в управлении, чем SRP и более надёжная. Хотя и с известными багами.

Microsoft создала потребительскую технологию, актуальную для всех секторов рынка, но давать её решила только VIP'ам, а остальным только пускать слюнки. Я говорю о том, что AppLocker доступен только в редакциях Ultimate и Enterprise десктопной Windows 7. Этим самым из целевой аудитории отваливается домашний сектор. В реальной жизни кроме пиратов мало кто приобретает компьютер с Windows 7 Ultimate. Чаще это ноутбуки с редакциями Home Basic/Premium, то же касается и обычных десктопов. Так же отваливается как минимум весь сектор Small Business и Medium тоже. SMB и средний бизнес тоже не будет приобретать Windows 7 Enterprise, а скорее будет покупать Professional, поскольку у Enterprise против Professional реальных преимуществ для этих секторов почти нет. А SMB — это основной рынок любой страны и по большому счёту он делает погоду на рынке. Да и крупные компании тоже особо тратиться на Enterprise не будут (хотя, Software Assurance им покрывает эти расходы). Иными словами, целевая аудитория этой технологии — средний (в меньшей степени) и крупный бизнес. Это маркетоЕдная составляющая проблемы.

Другая проблема кроется в технической составляющей. При всех достоинствах, AppLocker имеет определённые недостатки, которые заключаются в ограниченном применении правил издателей (подробнее см.тут: Встречаем – AppLocker!). Уж очень неоднозначно описываются правила издателей (а кто-нибудь пробовал строгие правила издатедей? Нет, а попробуйте и узнаете что это такое ), из-за чего они могут обхватывать нежелательные сертификаты доверенного поставщика. И с этим бороться сложно. Хотя, кому как. Из-за этого более целесообразным является использование правила хеша, что в свою очередь доставляет головняка при обновлении исполняемых файлов, для которых создано правило хеша. Их каждый раз придётся пересчитывать и обновлять сами правила. Это не смертельно, но уже не так весело, как в вайтпеперах и уютненьких бложеках MVP-маркетоидов.

Но наиболее глобальная проблема даже не в недостатках правил издателей или бага в правилах пути. Наиболее глобальная проблема кроется в интеграции AppLocker'а в существующую среду и крупный бизнес здесь страдает от этого сильнее, чем смалл бизнес. Это связано с тем, что в крупном бизнесе практически никогда не бывает сетей с установленной единственной версией ОС. Там обязательно присустствует парк ОС из разных поколений (начиная от Windows 2000/XP до Windows 7). AppLocker покрывает только малую часть из всего парка (только Windows 7 Enterprise). Для остальных приходится же использовать что-то другое. Обычно это Software Restriction Policies. И администраторам придётся создавать 2 набора политик: отдельно SRP для XP/Vista и отдельно AppLocker для Windows 7. То же самое относится и к редактированию политик. Если обновился какой-то файл, придётся обновлять политику SRP и AppLocker соответственно. Администраторам будет проще поддерживать одну политику, вместо двух. Плюс, правила сертификатов в SRP могут вносить негативный эффект в правила AppLocker'а. Хоть и заявляется, что если AppLocker включен, SRP будет игнорироваться системой, но запреты по правилам сертификатам будут перекрывать соответствующие разрешения в AppLocker'е. Это вызовет в свою очередь проблему планирования правил, чтобы грамотно создать правило в SRP и AppLocker'е и чтобы не наткнуться на подводный камень.

Вывод: так какое же место в этой жизни уготовано для AppLocker? Я считаю, что это только терминальные сервера или фермы терминальных серверов, где AppLocker показывает явное преимущество. А так же тот небольшой кусочек домашнего сектора, где возможно использование AppLocker'а. В остальных случаях практического использования, AppLocker является нецелесообразным и неэффективным. Возможно в следующем поколении Windows (или через поколение) что-то изменится, но сейчас дела обстоят примерно таким образом.

Но учитывая, что процент использования SRP по отношению к общему количеству инсталляций Windows XP/Vista/7/Server 2003/Server 2008/Server2008 R2 (видали, какой список ОС поддерживает SRP? ) очень ничтожный, то процент использования AppLocker'а — вообще круглый ноль и можно сказать, что МС просто выкинул деньги на ветер, вложив их в разработку AppLocker'а.

PowerShell Powered - http://www.sysadmins.lv

Очередной баг в AppLocker

Camelot — Sat, 24 Jul 2010 16:53:50 GMT

Update 23.08.2010: добавлен воркэраунд для обхода проблемы.

Оговорюсь сразу, баг был обнаружен не мною, а кем-то с технетов. Но тем не менее я заинтересовался им. Баг состоит в том, что если в правиле пути сам путь содержит буквы неанглийского алфавита, правило просто напросто не применяется! И некоторые вводные данные:

Подверженные ОС:

Windows 7 Ultimate/Enterprise (x86/x64)
Windows Server 2008 R2 (все редакции)

И вот как его можно проверить:

Войдите в систему с правами локального администратора.
На рабочем столе создайте папку с именем Папка.
Скопируйте в эту папку любой .EXE файл.
Нажмите Start и в поле Search for programs or files введите Local Security Policy. Вы должны увидеть значок редактора локальных политик и нажмите на него. Если появится запрос подтверждения User Account Control, подтвердите операцию или введите пароль своей учётной записи.
В раскрывшемся окне разверните секцию Application Control Policies.
Выделите и разверните секцию AppLocker.
Выберите секцию Executable rules.
Нажмите правой кнопкой мыши на эту секцию и выберите Create Default Rules. Этой операцией вы создадите правила по умолчанию, которые позволят запускать любые исполняемые файлы в %systemroot%, %programfiles% и разрешит запускать абсолютно всё встроенной учётной записи администратора.
Найдите это правило для встроенных администраторов и удалите его. Вот как выглядит правило, которое следует удалить:
Теперь вы сможете запускать исполняемые файлы только из папок %systemroot% и %programfiles%, а остальные папки будут запрещены для запуска исполняемых файлов. Нажмите правой кнопкой мыши на Executable rules и нажмите Create New Rule.
На странице Before You Begin вы можете узнать основные сведения о мастере. Нажмите Next.
На странице Permissions убедитесь, что Action выставлен в Allow и User or group выставлено в Everyone (значения по умолчанию). Нажмите Next.
На странице Conditions выставьте переключатель в Path и нажмите Next.
На странице Path нажмите Browse Folders. Укажите созданную на рабочем столе папку (по умолчанию это C:\Users\<YourAccountName>\Desktop\Папка) и нажмите Ok. На этой же странице мастера нажмите Create.
Сверните окно консоли MMC.
Переключитесь на рабочий стол, откройте созданную папку и попробуйте запустить файл. И вы получите сообщение об ошибке, что приложение было блокировано групповой политикой.

Примечание: перед выполнением всех операций убедитесь, что у вас запущена служба Application Identity. Для этого вы можете запустить командную строку в elevated mode и выполнить следующую команду:

net start AppIDSvc

Воркэраунд для обхода проблемы опубликован здесь: Очередной баг в AppLocker (обновление)

PowerShell Powered - http://www.sysadmins.lv

AppLocker — порядок работы правил

Camelot — Wed, 17 Mar 2010 20:22:57 GMT

Примечание: для успешного освоения данного материала, необходимо прочитать мою предыдущую запись по теме: Встречаем – AppLocker!

Я в своё время написал пост о порядке сортировки правил в Software Restriction Policies (Секреты Software Restriction Policies (часть 4)). Некоторые вопросы в интернетах говорят мне о том, что с AppLocker'ом люди не особо разобрались и сильно путаются. Виной тому — полное отсутствие вменяемой документации по вопросам практической реализации и отсутствие серого вещества у некоторых администраторов. Сегодня я покажу как AppLocker выявляет результирующий статус для запускаемого приложения/скрипта.

В Software Restriction Policies правила достаточно простые, хотя и со своими тараканами. Например, у нас есть возможность использовать один из двух уровней по умолчанию — Disallowed и Unrestricted. Правила в SRP так же могут быть определены одним из двух уровней (на самом деле в SRP ещё есть Basic User, но я его опускаю, как незначительный момент). Т.е. правило либо однозначно запрещает, либо однозначно разрешает вне зависимости от уровня по умолчанию. А результирующий уровень определялся нехитрым методом сортировок правил.

С AppLocker'ом ситуация немного иная. Теперь уровень по умолчанию только Disallowed. Т.е. запрещено всё, что не разрешено. Вроде бы и просто, но сами правила стали немного сложнее — появились исключения. В результате этих исключений значительно усложнилась и изменилась методика определения результирующего уровня для запускаемого файла.

Примечание: под «файлом» я здесь подразумеваю файл с расширением, контролируемым в AppLocker'е.

Итак, AppLocker позволяет создавать правила с уровнем Deny или Allow. Каждое правило пути или издателя (Publisher), кроме правила хешей, могут содержать исключения. Поскольку правило издателя не может уникально идентифицировать конкретный файл, т.к. поле Subject сертификата достаточно абстрактное понятие и под одно такое правило может подпадать сотни различных файлов. Причём, ситуация усугубляется тем, что в Software Restriction Policies в правило сертификата указывался конкретный сертификат подписи, AppLocker их просто перестаёт различать! Т.е. область действия правила издателя становится ещё шире, чем с классическими правилами сертификатов в SRP. То же самое и с правилами пути, поскольку по указанному пути сегодня может быть один файл, а завтра уже другой. Но для AppLocker'а это будет всё один файл. А ещё могут быть ситуации, когда по некоторому пути нужно разрешить всё, кроме какого-то набора файлов. Недостатки (и достоинства одновременно) компенсируются наличием в правилах исключений. Исключения позволяют значительно сократить количество правил в AppLocker'е.

Примечание: Единственный способ уникальной идентификации файла в AppLocker'е (равно как и в SRP) может быть только правило хеша, поскольку хеш условно говоря уникально идентифицирует файл (в пределах коллизий хеша). Именно по этой причине правило хеша не поддерживает возможность использования исключений.

Основной сценарий, который многих сбивает с толку: создаём запрещающее правило по правилу издателя или правилу пути. Однако определённые файлы, подпадающие под этот запрет должны быть разрешены для запуска. Для этих целей мы можем смело воспользоваться исключениями. Поэтому мы вносим такие файлы в исключения по пути, хешу или издателю. И, казалось бы, исключение из запрета означает явное разрешение. На первый взгляд это так и есть. Однако, следует помнить, что AppLocker использует неотключаемое действие по умолчанию — Disallowed. И когда файл выпадает из явного запрета, он не разрешается автоматически, поскольку подпадает под действие по умолчанию, если нет явного разрешения. Вот такие пирожки. Следовательно, можно вывести общий постулат AppLocker'а: разрешённый файл не должен быть явно запрещён и должен быть явно разрешён. Этот постулат будет доказан и продемонстрирован чуть ниже.

Если SRP использовал сортировку правил по их типу, устанавливая заданный приоритет для каждого вида, AppLocker более не использует такой метод. Запрет по правилу пути не может быть перекрыт даже разрешением по хешу или правилу издателя, как это работает в SRP. AppLocker сортирует правила по их действию — Deny и Allow. Запреты отрабатываются в первую очередь и затем разрешения. Опираясь на мои исследования я составил примерно такой алгоритм работы правил аплокера:

Сначала проверяются все явные запреты (в произвольном порядке).
- Если файл подпал под явный запрет, то для этого запрета отрабатываются все исключения. Если файл всё ещё подпадает под явный запрет, то файл помещается в список «Denied» и блокируется для запуска. Остальные шаги проверки не производятся.
- Если после обработки исключений больше не подпадает под явный запрет, то берётся следующее запрещающее правило и так продолжается, пока не будут проверены все явные запреты.
- Если после отработки всех запретов, файл больше не подпадает под явный запрет, он помещается в список «Processing».
Если файл находится в списке «Processing», файл проходит через второй этап проверки. Если список «Processing» пуст, файл не проходит через второй этап и хмуро блокируется для запуска.

Если файл подпал под явное разрешение, то для этого разрешения отрабатываются все исключения. Если файл всё ещё подпадает под разрешение, файл помещается в список «Allowed» и разрешается для запуска. Остальные шаги проверки не производятся.
Если после обработки исключений файл больше не подпадает под явное разрешение, то берётся следующее разрешающее правило, и процесс повторяется для каждого разрешающего правила.
Если после отработки всех разрешений, файл всё ещё находится в списке «Processing», к файлу применяется действие по умолчанию. Т.е. файл блокируется для запуска.

Примечание: на самом деле никаких таких списков не существует, это я всё соврал. Я их придумал только для улучшения понимания.

Для наглядной демонстрации алгоритма я нарисовал следующую картинку:

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

Задача:

На компьютере в каталог по умолчанию установлен пакет Microsoft Office, которым можно пользоваться всем. Но группе «Accountants» необходимо разрешить запускать только программы Word и Excel. Запуск остальных файлов из «Program Files» разрешён без ограничений.

Решение:

Для решения этой задачи мы должны разрешить весь каталог «Program Files» по правилу пути для группы «Everyone». Поскольку доступ к программам Microsoft Office будет ограничен только для группы «Accountants», мы создаём новое запрещающее правило (с действием «Deny»), которое применяется только к группе «Accountants». Теперь программы из пакета Microsoft Office будут разрешены для запуска всем, кроме группы «Accountants». Чтобы обеспечить запуск только необходимых приложений из этой папки, мы редактируем запрещающее правило и добавляем два исключения (по правилу пути, хеша или издателя) для файлов «Excel.exe» и «Winword.exe».

Проверка:

Исходя из диаграммы, посмотрим, что будет происходить, когда член группы Accountants запустит PowerPNT.exe (PowerPoint).

При запуске мы попадаем на первый условный переход: подпадает ли файл под какой-нибудь запрет? Да, у нас есть запрет на папку %programfiles%\Microsoft Office. Следовательно выходим на следующий условный переход: указан ли PowerPNT.exe в исключениях? Правило запрета не предусматривает исключения для этого файла, следовательно мы выходим на действие «File is blocked to run». При этом алгоритм заканчивается.

А теперь член группы Accountants запускает Excel.exe (Excel). При запуске мы снова попадаем на первый условный переход: подпадает ли файл под запрет? Да, у нас есть запрет на папку %programfiles%\Microsoft Office. Следовательно переходим на следующий условный переход: указан ли Excel.exe в исключениях данного правила? Да, указан в исключениях, поэтому переходим на третий условный переход: есть ли ещё запрещающие правила? Если нет, мы сразу попадаем на четвёртый условный переход, который уже отрабатывает разрешения. Если есть ещё запрещающие правила, в них Excel.exe никак не запрещается (по условию задачи это не подразумевается), мы прямиком с первого условного перехода попадаем на четвёртый условный переход: подпадает ли файл хоть под одно разрешающее правило? Да, файл подпадает под разрешающее правило всего каталога Program Files для группы Everyone, в которую входит и группа Accountants. В результате попадаем на пятый условный переход: есть ли исключение для Excel.exe в этом разрешающем правиле? Нет, исключений для правила не предусмотрено и мы выходим на действие «File is allowed to run».

Как видите, используя эту диаграмму, можно разбирать правила любой сложности в пошаговом режиме и теперь вы знаете, как сортируются и проверяются правила AppLocker'а.

Напоследок ещё хочется отметить ситуацию применения множественных политик. Так же как и в случае с Software Restriction Policies, правила никак не замещаются, а суммируются. Т.е. собираются в один список, после чего AppLocker оперирует правилами, собранных со всех политик, применённых к конкретному компьютеру.

Что бы почитать?

PowerShell Powered - http://www.sysadmins.lv

AppLocker vs Software Restriction Policies

Camelot — Tue, 01 Dec 2009 16:55:02 GMT

В последнее время мне всё чаще стали задавать вопрос, что выбрать, AppLocker или старый добрый SRP?

Казалось бы, что тут думать — AppLocker и точка. Многие, наверное, помнят пиар-акцию под названием «Windows 7 + 1», которую проводили многие MVP для рекламы новых технологий Windows 7. И весьма досадно то, что некоторые MVP вместо раскрытия реальной объективности новых технологий распространяли просто маркетинговый булшит и даже подтасовывали факты. Например статья Владимира Безмалого про AppLocker:

Этот вариант статьи можно ещё прочитать и здесь: http://www.osp.ru/win2000/2009/09/10721226/. Моё внимание обратила на себя табличка сравнения SRP и AppLocker. Вот она с моими комментариями:

Я думаю, что ни для кого не секрет, что аудит в SRP был и не сильно хуже, чем в AppLocker. Разница лишь в том, что AppLocker пишет в свой собственный EventLog, а SRP писал аудит в текстовый файл.

На счёт мастера создания правил я немного не понял. В принципе, окно создания правила в SRP тоже своего рода мастер. Только одношаговый, в отличии от AppLocker.

А сообщения об ошибках в SRP были тоже. Как в виде диалогоых окон, так и в журнале Application в эвентлоге. Т.е. тут у меня 2 мнения — либо человек не работал с SRP, либо намеренно исказил факты, чтобы подкрутить популярность AppLocker'а, поскольку революции AppLocker не совершил. Ведь с появлением AppLocker мы приобрели не только удобный интерфейс, но и потеряли несколько полезных вещей, которые есть в SRP. Как я уже отмечал ранее, мы потеряли возможность самостоятельно регулировать список контролируемых расширений файлов и потеряли возможность фильтрования файлов по конкретным сертификатам. Новое правило издателя позволяет контролировать версию разрешённого приложения, но не отличает каким сертификатом подписано приложение. Да и применимость издателей такая же как и у классических правил сертификатов — т.е. низкая. К сожалению я не могу вспомнить ни одно бизнес-приложение (не стандартные приложения типа Microsoft Office), которое бы было подписано. Плюс невозможность использования системных переменных окружения так же усложняет создание правил в доменной среде. Эту табличку можно переделать в такой вид:

	SRP	AppLocker
Применение правил	Все пользователи	Определённые группы и пользователи
Уровень по умолчанию	Unrestricted	Deny
Разрешающее действие
Запрещающее действие
Особое действие
Правила сертификатов
Правила издателей
Правила хешей
Правила сетевой зоны
Правила пути
Системные переменные окружения
Собственные переменные окружения
Пути из реестра
Режим аудита
Группировка правил
Мастер создания правил
Импорт/экспорт политик
Поддержка PowerShell
Сообщения об ошибках
Настраиваемый список расширений

Мы видим, что преимущество AppLocker перед SRP резко переходит на нет. Я не хочу сказать, что AppLocker — отстой, а лишь хочу показать, что реализация этой технологии не на столько крутая, что её стоит пиарить как революцию.

Из блога Владимира Безмалого:

В Windows 7 SRP также могут применяться, однако все чаще будет использоваться AppLocker. Почему?

К сожалению этого не случится, во всяком случае в цикле Windows 7. Как уже отмечалось, наиболее значительное изменение в AppLocker — это новый простой, удобный и понятный интерфейс, чего в SRP не было. В значительной степени из-за этого SRP на домашних компьютерах применялся лишь в единичных случаях. Сейчас же применить AppLocker гораздо проще на домашних системах при получении одинаково эффективного результата. Но Microsoft слишком жадный и включил эту технологию только в Windows 7 Ultimate и Enterprise. Я верю, что от появления SRP в домашних редакциях Windows 7 количество применений SRP на них не увеличится совсем. Учитывая, что с ноутбуками будет чаще всего проинсталлирована какая-то домашняя редакция Windows 7, то профита от AppLocker они не получат тоже. Но если дома есть возможность использовать AppLocker и вы хотите получить адекватный уровень защиты от запуска случайных файлов — используйте AppLocker. Хотя, скажите, кто из вас, кроме меня, использует Windows 7 Ultimate/Enterprise дома и использует AppLocker?

Если вы будете иметь возможность перевести часть парка машин предприятия на Windows 7 Enterprise, то вопрос использования AppLocker может сложиться не в его пользу. Это обусловлено тем, что если у вас уже используется SRP, то вам AppLocker не будет нужен до тех пор, пока весь парк не будет переведён на Windows 7 Enterprise. Ведь с AppLocker вы ощутимых бенефитов не получите в плане безопасности, но сразу усложните себе жизнь тем, что вам придётся поддерживать гораздо больше политик — SRP и AppLocker. При необходимости поддерживать клиентов отличных от Windows 7 Enterprise лучше использовать то, что может охватить наиболее число машин — SRP.

Внимать моим рекомендациям — личное дело каждого, просто я отразил своё видение проблематики. Вобщем, я не верю в массовое светлое будущее AppLocker по крайней мере до выхода следующей версии Windows, даже не смотря на активный и нечестный пиар технологии со стороны Microsoft (что вполне нормально для самого создателя) и прочих пиарщиков. Но начинать его использование по мере возможности — очень даже можно и нужно, т.к. однажды SRP просто не окажется в релизе ОС.

PowerShell Powered - http://www.sysadmins.lv

Applocker, PowerShell и Промпт

Camelot — Sun, 30 Aug 2009 17:47:39 GMT

Вася Гусев прислал мне одну замечательную ссылку на пост (а в посте ссылка на документ) Дмитрия Буланова по управлению AppLocker'ом с использованием Windows PowerShell: http://dimanb.spaces.live.com/blog/cns!7D6C59DEE1DA79E5!323.entry

В принципе, это хорошо, т.к. мне уже, возможно, не понадобится об этом писать. Однако, я не разделяю такого оптимизма автора документа (кстати говоря, авторство принадлежит не Дмитрию, а только перевод. Причём, бездарный перевод) и считаю, что такая поддержка со стороны PowerShell ещё ниже опускает уровень защиты AppLocker. Но и сам документ выглядит как типичный маркетинговый булшит, поскольку содержит несколько ложных утверждений и достаточно много подтасованных фактов. Давайте посмотрим документ внимательней:

Уже несколько лет администраторам в организациях приходилось устанавливать стороннее программное обеспечение, за что организациям приходилось тратить немалые средства. Теперь с появлением AppLocker у администраторов нет необходимости в поиске стороннего программного обеспечения, т.к. с появлением Windows 7 и Windows Server 2008 R2 AppLocker добавлен в групповые политики.

При этом автор очень сильно недоговаривает, поскольку SRP существует ещё с 2001 года (когда вышел RTM Windows XP). Т.е. раньше тоже были средства контроля используемых приложений.

Часто со временем, после развертывания операционных систем, конфигурация программного обеспечения типичного рабочего места оказывается далека от желаемого результата. Несогласованности приходят чаще, не столько от установки, сколько от работы несоответствующего стандартам программного обеспечения в пределах настольного окружения. Пользователи инсталлируют программное обеспечение из разнообразных источников: компакт-дисков и дисковых накопителей, загрузки файлов из сети Интернет, совместного использования файлов через совместные пиринговые сети, и через электронную почту. Результат – возможность заражения компьютера вредоносным программным кодом

Наверное, единственное утверждение, с которым я согласен.

Software Restriction Policies (SRP), в Windows XP и Windows Vista, было одним из первых решений прикладного контроля. SRP дал IT-администраторам грубый механизм, для определения и написания политик контроля за приложениями. Однако SRP мог ограничить управление в динамической настольной среде, где приложения устанавливались и обновлялись на постоянной основе, т.к. они в основном использовали правила хэширования. С правилами хэширования, каждый раз при обновлении программного обеспечения необходимо было создавать новые правила хэширования.

Враньё! Особенно выделенное. В ряде моментов SRP более гибок, чем AppLocker. Если говорить про правила хешей, то AppLocker вносит только одно удобство – позволяет за раз добавить несколько файлов в правило хеша из одной папки. Но дальше в этом плане ничем не отличается от SRP. А с правилами путей профитов в AppLocker по сравнению с SRP почти и нету, поскольку в правилах путей как правила используются wildcards, вместо полных путей до конечного файла. Про паблишеров я отмечусь чуть ниже.

С появлением AppLocker в операционной системе Windows 7 растет необходимость введения решений прикладного контроля на предприятии: простой и гибкий механизм, который позволяет администраторам конкретизировать разрешения для запуска программного обеспечения в своей программной среде. В результате, AppLocker обеспечивает не только защиту безопасности, но и оперативность и удобство по развертыванию политик

Этим автор ещё раз доказывает своё мнение, что до AppLocker'а у нас был ад и Израиль и у нас не было SRP. И прочитайте выделенное. Мне это говорит, что наоборот, AppLocker – источник всех проблем. Не будь его, не росла эта необходимость. В чём оперативность здесь – мне пока непонятно. Да, и что есть прикладной контроль? Есть мнение, что это от английского Application Control (жертва пиратского промпта? © Artem Pronichkin).

Ограничение в запуске нелицензионного программного обеспечения на рабочем месте;
Понижение уязвимости, средствами запрещения запуска несанкционированных приложений на вашем рабочем месте, в том числе запуск вредоносного кода;
Запрещать пользователям запуск приложений, которые бесполезно потребляют сетевую пропускную способность;
Ограничение пользователей от запуска приложений, которые дестабилизируют их рабочую среду;
Эффективность конфигурации управления;
Позволять пользователям устанавливать и запускать одобренное администратором программное обеспечение основанное на деловых потребностях;
Гарантировать, согласованность установки программного обеспечения с корпоративными политиками и правилами, например PCI DSS, Sarbanes-Oxley, HIPAA, Basel II, и другое.

пункт 3 - покажите!!! Как? Я тоже хочу использовать такую функциональность! Т.е. создавать правила на основе критериев: только приложения, которые полезно потребляют пропускную способность сети. В последнем пункте заметил несколько новых слов, значения которых я не знаю. Подозреваю, что основная целевая аудитория документа тоже не сильно владеет такими терминами.

Но вообще все эти пункты укладываются в более короткий список:

Контроль запуска только разрешённых администратором приложений. Что исключает возможность несанкционированного запуска потенциально опасного, вредного или лишнего ПО.

Размазывать единственное предназначение AppLocker'а (равно как и SRP) на 7 пунктов незачем. Разве что – задавить читателя массой возможностей нового продукта.

разрешения, запрещения и исключения

в русском языке вряд ли есть такое слово, как “запрещения”. Правильнее будет “запрет”. Промпт переводит как умеет…

Администратору предоставляется возможность разрешения на запуск приложений, которые входят в «белый список приложений» и блокировать все остальное.

в этом предложении я ничего не понял, кроме “белый список приложений”.

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

Хотелось бы мне знать, чем в данном случае явный запрет будет отличаться от отдельного запрета? Технически это одно и то же. Т.е. если мы одним правилом накрываем достаточно большую область, в которой нужно создать исключения, то создание исключения или отдельного запрета будет равноценным, поскольку тут так же работает правило приоритета более точного правила. А SRP этим не обделён ни разу.

AppLocker вводит правила издателя, которые основаны на прикладных цифровых подписях. Правила издателя дают возможность создания правил, которые включают возможность обновления программного обеспечения. Например, организация может создать правило, чтобы “разрешить все версии, большие, чем 9.0 для запуска Acrobat Reader, если у программного обеспечения Adobe есть цифровая подпись”. После чего, когда у Adobe появится новая версия Acrobat, вы можете безопасно запустить обновление программы без необходимости создания нового правила для последующей версии приложения.

Вот здесь снова появляется ложь. Правила издателя были в SRP, только немного в ином виде (Certificate Rule). Опять же, следует учитывать, что вы можете использовать эту возможность только при условии, что у файла есть цифровая подпись. Нету подписи – вот вам пачка хешей, работайте. Плюс, как я уже упоминал, AppLocker не закрывает одну опасную брешь в концепции цифровых подписей – не проверяется доверие конкретной цифровой подписи. Кто угодно может прочитать правило паблишера (да-да, именно средствами родного PowerShell, поскольку других вменяемых средств нету) и подписать свой файл своей же подписью, которую AppLocker скушает и разрешит для запуска. Вобщем, разработчики AppLocker'а допустили 2 фатальные ошибки, из-за которых эти профиты могут просто потерять реальный практический смысл:

совершенно испоганили правило издателя (publisher), отменив проверку доверия конкретной цифровой подписи;
разрешили пользователям со стандартыми правами (standard user) читать все настройки этой политики.

Поэтому эти 2 пункта следует рассматривать не как бенефиты AppLocker'а, а как его недостатки в контексте безопасности. Это было сделано в пользу удобства и в ущерб безопасности. И это не говоря о том, что не все редакции Windows 7 могут использовать эту политику.

Правила AppLocker могут быть ассоциированы с конкретным пользователем или группой в пределах организации. Это обеспечивает гранулирование контроля, что позволяет вам поддерживать требования компании и предписания благодаря которым пользователи могут управлять специфическими приложениями. Например, вы можете создать правило, чтобы “разрешить сотрудникам Отдела Финансов управлять линией приложений, которые относятся к их деятельности”. Эти приложения блокируются от запуска для всех пользователей, которые не находятся в Отделе Финансов (в том числе администраторы), но все еще обеспечивают доступ для тех, у кого есть надобность управлять данными приложениями.

На самом деле это тоже не прорыв. Подобная реализация на уровне групп пользователей была и в SRP, поскольку SRP можно было конфигурировать в секции User Configuration и фильтровать политику с помощью Security Filtering. Т.е. данный функционал был чуть причёсан и сделан более user-friendly.

Благодаря AppLocker в Windows 7, у администраторов появляется возможность контроля за приложениями пользователей.

Ещё раз отмечаю, что AppLocker в этом отношении не единственный бесплатный инструмент.

Вобщем, мой совет читателям – избегать подобных переводов, как ересь и ЛПП, поскольку промпт никогда (во всяком случае – в обозримом будущем) не сможет переводить тексты со смыслом и именно тем смыслом, который заложен в оригинале. Поэтому предлагаю ссылки на оригинальные статьи, которые были переведены в этом документе:

Спасибо за внимание

PowerShell Powered - http://www.sysadmins.lv

Встречаем – AppLocker!

Camelot — Thu, 06 Aug 2009 20:36:11 GMT

Хорошие новости – я наконец-то добрался до него! Что такое AppLocker? По сути это следующая стадия эволюции хорошо знакомой нам политики Software Restriction Policies, который доступен в операционных системах начиная с Windows 7 (Ultimate и Enterprise) и Windows Server 2008 R2. Безусловно, политики SRP остались в этих ОС (и SRP единственный инструмент подобного рода, который будет доступен в домашних редакциях Windows 7) в качестве совместимости. Я ещё не имею большого опыта (всего неделю использую его) с AppLocker и хочу поделиться первыми впечатлениями с замашками на общий обзор. Ну и обязательно проведу сравнительные моменты с политикой Software Restriction Policies. Я буду стараться рассмотреть только технические и организационные моменты политики AppLocker, поэтому данная статья может быть полезна только тем, кто имел опыт работы с SRP в качестве материала подготовки перехода с SRP к AppLocker. Для новичков тут вряд ли будет что-то интересное.

Введение

Прежде всего, чтобы как-то начать с ним работать следует включить и запустить службу Application Identity. Чтобы добраться до самой политики AppLocker нужно запустить редактор групповой политики и развернуть его в секции Computer Configuration. Если это изолированная рабочая станция, то просто Start –> Run… –> secpol.msc. И мы увидим примерно такое окно:

Здесь мы видим деление на 3 категории:

Executable Rules – содержит правила для файлов с расширениями COM, SCR и EXE;
Windows Installer Rules – содержит правила для файлов с расширениями MSI и MSP;
Script Rules – содержит правила для файлов с расширениями BAT, CMD, JS, PS1 и VBS.

Update 16.08.2009: в категорию Executable Rules включено ещё одно PE расширение – SCR (скринсейвер). Однако, в документации я не смог найти ни одного упоминания, что это расширение где-то проверяется в AppLocker. Но имейте ввиду, что де-факто это так.

Вот такого разделения весьма не хватало в политиках SRP, где всё было в кучу, теперь всё сгруппировано по категориям. Однако, в AppLocker нету возможности управлять расширениями, в отличии от SRP (где можно было редактировать окно Designated File Types), что является первой точкой возможнного ослабления защиты. И (ололо?) тут мы не видим HTA файлов! Следовательно, при использовании апплокера мы можем невозбранно запускать произвольный VBS код (разумеется, в контексте пользователя, который его запустил). Хотя, может, я слишком маниакальный и только вижу пользователей, которые пачками проносят HTA файлы .

Создаём самые первые правила

По умолчанию в консоли никаких правил нету (в отличии от SRP, где основные правила исключений уже были). Чтобы создать правила по умолчанию нужно выбрать нужную категорию и правой кнопкой мышки выбрать Create Default Rules. И тогда появится 3 правила по умолчанию (и так будет в каждой категории):

Allow Everyone all files in Windows directory;
Allow Everyone all files in ProgramFiles directory;
Allow BUILTIN\Administrator all files.

Тут всё понятно – это аналог дефолтных правил в SRP с добавлением того, что администратор может запускать что угодно. Но я буду рекомендовать удалять последнее правило из каждой категории, которое позволяет администраторам запускать всё что угодно (а случай работы с полностью отключенным UAC я даже обсуждать не хочу). Мы ведь помним, что в 99% случаев всех заражений виноват именно локальный администратор.

Примечание: понятие BUILTIN\Administrators здесь трактуется как использование приложений в привелигированном режиме (elevated mode). При обычном запуске приложений на администратора распространяются только первые 2 правила.

На этом этапе мы видим кардинальное перерождение уровня Basic User в новый формат. Basic User в SRP позволял запускать файлы в обычном режиме и запрещал запускать приложения в elevated mode. Здесь же этот функционал работает с точностью до наоборот. Задание исключений для группы BUILTIN\Administrators не позволяет нам запускать приложения в обычном режиме, но разрешает их запуск в elevated mode. И ярковыраженного Basic User больше нету.

Уже из скриншота видно, что мы можем как-то разделять правила по группам пользователей. Этого, кстати, тоже не хватало в SRP. Теперь мы имеем возможность разделять правила для различных пользователей даже на уровне одной изолированной от домена рабочей станции. Это решает сразу 2 проблемы, которые были в SRP:

нету необходимости в неудобном переключателе между режимом применения политики (для всех пользователей, кроме администраторов или для всех пользователей без исключения) в окне Enforcement.
нету необходимости редактировать политики в нескольких местах. Т.е. в отличии от SRP, AppLocker уже не имеет настроек в секции User Configuration. Это упрощает процесс создания и внедрения политик на уровне домена, не требуя от администратора досконального знания, как политики из разных разделов GPO будут вести себя в случае конфликтов. Хотя, это знать полезно.

Как только мы создали правила, AppLocker уже начинает работать. Это довольно-таки спорный момент. В SRP у нас было отдельная секция, где мы задавали уровень по умолчанию, а в AppLocker этого уже нету. Каждая категория начинает работать в момент, когда создано хоть одно правило. Тогда работа идёт в строгом соответствии с этими правилами (даже если оно одно). Если удалить все правила из конкретной категории, то политика для данной категории отключается и конкретные типы файлов можно запускать без ограничений. Если сравнить с SRP, то мы так же помним, что политики SRP не экспортируются никак! Т.е. мы не можем их переносить между компьютерами, бэкапить на уровне локальной рабочей станции. Поэтому для предотвращения потери конфигурации и правил в SRP был введён переключатель режима. AppLocker в этом плане немного изменился – мы имеем возможность экспорта настроек и правил политики. Для этого нужно выставить курсор на секцию AppLocker и правой кнопкой мышки выбрать Export Policy. К счастью, политики экспортируются в читабельный XML файл, а не в бинарный мусор (как в случае с экспортом правил IPSec). Для полного отключения политики, там же после экспорта выбрать Clear Policy. Т.е. для временного отключения AppLocker мы сначала эксортируем настройки и правила, очищаем политику и работаем. Когда работу закончили – импортируем политику и мы снова под колпаком. SRP поддерживал возможность временного отключения политики на конкретной рабочей станции через реестр. Теперь мы такого функционала лишены, хотя с возможностью экспорта это не сильно и нужно нам. Ну и, повторюсь, AppLocker работает только в режиме белого списка.

Основные изменения в правилах

А теперь уже конкретно по правилам. В SRP у нас была возможность создавать 4 типа правила: Certificate, Hash, Network Zone, Path. Как и ожидалось, Network Zone не смог найти себе места в этих политиках, поэтому в AppLocker этот тип удалён и остаётся только 3: Publisher (бывший Certificate rule), Hash, Path с такой же приоритезацией. Правила издателя (Publisher) и пути (Path) несколько изменились в своей сути. Начнём с правила пути.

Изменения в правилах пути

Если вспомнить SRP, то там мы могли использовать абсолютные пути, переменные окружения (но на самом деле оказалось, что это очень опасно), подстановочные знаки и чтение путей из реестра. В AppLocker мы можем использовать только абсолютные пути и специальные переменные окружения. Вот таблица (взята из встроенной в Windows справки):

Windows directory or drive	AppLocker path variable	Windows environment variable
Windows	%WINDIR%	%SystemRoot%
System32	%SYSTEM32%	%SystemDirectory%
Windows Installation directory	%OSDRIVE%	%SystemDrive%
Program Files	%PROGRAMFILES%	%ProgramFiles% and %ProgramFiles(x86)%
Removable media (for example, CD or DVD)	%REMOVABLE%
Removable storage device (for example, USB flash drive)	%HOT%

Мы в правилах можем использовать только переменные, которые указаны во второй колонке. Мы лишены возможности использовать другие переменные как %temp%, %logonserver% и др. Но, в то же время, мы можем использовать в правилах переменные для обозначения CD/DVD приводов и съёмных накопителей (просто флешки). Здесь следует учесть, что эти переменные не являются переменными окружения Windows, а внутренние для AppLocker, даже не смотря на совпадение в синтаксисе. Это ещё сильнее утвердило во мне мысль, что Microsoft знал про баг с переменными окружения в Windows и сейчас уже подмена переменных ничего не даёт совсем для обхода запретов политики. Вобщем, тут мы немного потеряли (переменные окружения и чтение путей из реестра), но, в то же время, приобрели защиту от подмены переменных окружения и получили перменные для съёмных дисков и CD/DVD приводов.

Изменения в правилах издателя (Publisher rule)

Это по сути ребрендинг правил сертификатов (Certificate Rule). Тут изменения более глобальные. И так же, частично в лучшую сторону и частично в обратную. Когда вы делаете правило издателя сертификата, то вы указываете на файл, который содержит цифровую подпись и всё. Политика сама извлечёт из файла цифровую подпись и прикрутит издателя к правилу. Вот как это выглядит вживую:

я ему просто подсунул подписанный файл и мы видим несколько разных полей. Поле Publisher извлекается из поля Subject сертификата цифровой подписи. Остальные поля извлекаются уже непосредственно из внутреннего кода файла (он обычно зашивается в EXE файлы при компиляции исходников). В случае со скриптами я не уверен, что они поддерживают распознаваемые версии и другие данные, которые мы видим пустыми на нашем скриншоте. И тогда все файлы данной категории, которые подписаны этим сертификатом будут запускаться без проблем. Двигая указанный ползунок мы можем указывать строгость соответствия подписи от полного соответствия, включая версию файла, до конкретного издателя.

Если говорить про версии файлов, то мы видим (правда, затенённое) поле с раскрывающимся списком, где мы можем задавать как точное совпадение версии (Exact match), так и сравнительную версию – только текущая и более новые версии (And above) или только текущая и более старые версии (And below).

Здесь, в отличии от SRP уже не используется внутренний в Windows механизм Trusted Publishers, который использовался в SRP, поэтому подсовывание сертификатов в этот контейнер ничем нам не поможет, как я уже демонстрировал в случае с SRP.

Внимание – Publisher!

Но тут ВНЕЗАПНО я понял одну вещь. SRP в правилах сертификатов проверял не только соответствие цифровой подписи, но и полное соответствие сертификата в правиле Certificate Rule и сертификата в самой подписи. AppLocker этого не делает. В отношении сертификатов, AppLocker проверяет только 2 вещи:

целостность подписи (вне зависимости кем эта подпись сделана).
соответствие поля Subject в сертификате подписи.

Что даёт нам некоторые преимущества. Например, утилиты Sysinternals подписаны разными сертификатами в разное время. Из-за чего для каждого сертификата в SRP надо было указывать каждый уникальный сертификат, что доставляло неудобства. Здесь же мы можем создавать более гибкие правила, которые позволяют запускать, например, любую версию ворда не ниже 10.0. Если у вас в сети используется несколько версий офиса (2002, 2003 и 2007), то мы можем одним правилом разрешить все 3 версии, указав в правиле версию самого древнего ворда и сказать, что можно эту версию и более новые. То же самое и касается утилит Sysinternals.

Что касается скриптов, если в SRP для них правила сертификатов были весьма удобным и безопасным решением. Но, как я говорил, соответствие самих сертификатов AppLocker не проверяет, поэтому мы можем невозбранно подделывать цифровые подписи:

makecert.exe -n "cn=Administrator, cn=Users, dc=contoso, dc=com" -ss my -eku 1.3.6.1.5.5.7.3.3

эта команда сгенерирует нам свой сертификат с таким же полем Subject, что и подписаны скрипты на предприятии (а там скрипты подписаны сертификатом администратора и к нему доступа у нас нету). Далее, мы этим сертификатом подписываем наши вредоносные скрипты, проносим на рабочие компьютеры и они будут запускаться! И только потому, что в наших сертификатах совпал Subject с сертификатом администратора. Технет пишет:

Use a publisher condition when possible. Publisher conditions can be created to allow applications to continue to function even if the location of the application changes or if the application is updated

но мы им не поверим, а от себя скажу, что правила издателей нельзя использовать для скриптов ни в коем случае, а в остальных случаях использовать с особой осторожностью. Пользователи не дураки и смогут прочитать сертификат цифровой подписи в своих логонных скриптах.

Исключения из правил

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

На скрине видно, что у нас есть основное разрешающее правило издателя. Но мы хотим что-то из этого издателя запретить, например, запуск тестовых скриптов из определённой папки. Мы в ходе создания правила указываем нужное исключение (причём, исключение может быть любого типа, а не только того типа, что и основное правило). Достаточно гуманно.

Примечание: не забывайте, что в Windows 7 и Windows Server 2008 R2 системный темп всё так же разрешён на запись пользователям и подпадает под дефолтные ращрешающие правила. Поэтому, если вы ещё их не перенесли в другое место, вы должны в правилах папки Windows должны включить исключения на папку Temp и папку спулера печати.

Много правил в одном правиле

В ходе создания правил вы увидите, что вы в процессе создания правила можете внутри создавать коллекцию подправил, которая будет составлять ваше правило. Скриншот показывать не буду, т.к. это видно по предыдущему скрину. Там есть кнопка Add, с помощью которой можете добавлять несколько различных исключений для своих правил. Это тоже весьма удобно, при условии, что администратор осмысленно структуирует свои правила.

Баги-баги

Я ещё не уверен, что это баг (нашёл такое поведение пока писал этот пост), но мне такой расклад не понравился. Что я сделал:

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

Мне думается, что если где-то есть запрет, то он должен быть приоритетней разрешения. Хотя, я ещё далеко не всё знаю про AppLocker, поэтому могу просто чего-то не знать. Либо же явное разрешение без исключений перекрывает запрет в исключениях. Как по аналогии с правами NTFS, когда явно назначенное разрешение перекрывает унаследованный запрет.

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

Удачи! © One

PowerShell Powered - http://www.sysadmins.lv