 |
|
|
|
Как спасти пирожки? AppLocker: укрепляем безопасность сети
Как спасти пирожки? Ваши пользователи запускают сомнительное ПО? Вы не в состоянии проконтролировать каждого из них? Научитесь предотвращать потенциальные угрозы атак опасного ПО штатными инструментами. Вопросы безопасности компьютерных сетей были, есть и будут актуальны во все времена, поскольку именно от них зависит успех вашего бизнеса. Одной из самых больших и трудноразрешимых проблем безопасности является злонамеренное ПО. Компьютерные вирусы существуют уже не один десяток лет, и столько же времени идёт неустанная борьба с ними. Этот вопрос может стать актуальным, когда сотрудник вашей фирмы по выпечке пирожков получает письмо от конкурентов с приложенным файлом. После запуска этого файла (ведь пока его не запустишь, не узнаешь, что там внутри) новый секретный рецепт фирменных пирожков вашей компании уходит к конкурентам. Другая опасность связана с тем, что зловредное ПО нарушает нормальную работу ПК, из-за чего сотрудники не могут полноценно выполнять свои задачи, им приходится бороться с симптомами заражения. Поверьте, клиенты не станут ждать, пока вы решите свои проблемы, а просто уйдут к другим поставщикам. Сегодня существуют десятки специализированных программ и решений, которые предназначены для защиты от компьютерных вирусов, троянских модулей и другого опасного ПО. Однако в действительности эффективность подобного подхода остаётся крайне низкой, поскольку чаще всего борьба ведётся лишь с уже известными производителю антивирусной программы версиями зловредного ПО. Когда антивирус обнаруживает угрозу, система зачастую уже скомпрометирована и бороться с последствиями уже бесполезно. Учитывая эту проблему, некоторые поставщики предлагают продукты, которые подходят к решению с другой стороны – пытаются устранить даже потенциальную возможность заражения. В 2001 году Microsoft выпустила первый вариант своей технологии, которая называлась Software Restrition Policies, или просто SRP (о ней вы можете прочитать в статье [1]). За восемь лет существования этой технологии она по различным причинам так и не смогла завоевать широкую популярность. Практика показала, что управление SRP было далеко не простым, а сама реализация имела известные критические недостатки. С выходом Windows 7 и Windows Server 2008 R2 Micosoft предлагает другое, более гибкое, удобное и ещё более надёжное средство защиты – AppLocker. Фактически AppLocker является новой архитектурной реализацией того же принципа, который был представлен в SRP. Наиболее заметным изменением стало то, что политика теперь работает не в пользовательском окружении, а в системном. Это практически лишает пользователей возможностей по обходу запретов AppLocker. Начало работы Для того чтобы начать работу с AppLocker, вы должны открыть оснастку редактора групповой политики в секции Computer Configuration -> Policy -> Windows Settings -> Security Settings -> Application control Policies -> AppLocker (см. рис. 1).
Рисунок 1. Внешний вид консоли AppLocker В дереве консоли вы увидите несколько дочерних элементов, в которых вы сможете создавать и редактировать правила. Они сгруппированы по типам: Executable Rules – могут содержать правила для файлов типов Application (с расширением exe) и MS-DOS Application (с расширением com). В действительности к данной категории относятся и файлы типа Screen saver (с расширением scr), так что правила будут применяться и к ним. Однако создавать отдельные правила для этих файлов вы не можете. Windows Installer Rules – могут содержать правила для файлов типов Windows Installer Package (с расширением msi) и Windows Installer Patch (с расширением msp). Script Rules – могут содержать правила для файлов типов Windows Batch File (с расширением bat), Windows Command Script (с расширением cmd), Jscript Script File (с расширением js), PS1 File (сценарий Windows PowerShell с расширением ps1) и VBScript Script File (с расширением vbs). В основном окне вы можете управлять применением правил, а также видеть сводную информацию по их количеству. Чтобы изменить режим применения политики, щёлкните по ссылке Configure rule enforcement. Для каждого типа правил можно выбрать один из двух режимов работы. Enforced – правила принудительно применяются к пользователям. И любой файл, для которого нет подходящего правила, будет заблокирован для запуска. Audit Only – режим аудита. Он полезен для определения списка ПО, которое используется пользователями. Когда включен этот режим, политики AppLocker не ограничивают запуск приложений. Но если для запускаемого файла (сценария или приложения) задано правило в политике, в журнал событий AppLocker будет добавлена соответствующая запись. Этот журнал можно просмотреть через оснастку Event Viewer по адресу Applications and Service logs -> Microsoft -> Windows -> AppLocker (см. рис. 2).
Рисунок 2. Окно управления режимом работы политики для каждой категории правил На вкладке Advanced того же окна вы можете отдельно настроить применение политик AppLocker к файлам типа Application extension – динамически загружаемым библиотекам с расширением dll. Однако используйте эту функцию с осторожностью, так как после её включения вам придётся создавать отдельные правила для файлов библиотек. А в результате проверки всех библиотек на соответствие правилам скорость работы системы может существенно снизиться (см. рис. 3).
Рисунок 3. Окно управления проверкой файлов библиотек на соответствие правилам Обратите внимание, что для применения правил в системе должна быть запущена служба Application Identity. Для создания и редактирования правил это не требуется. Создание правил После краткого обзора консоли управления политикой мы можем приступать к созданию правил (см. рис. 4).
Рисунок 4. Создание новых правил из контекстного меню каждого типа К этой задаче существуют три подхода:
В большинстве случаев я рекомендую комбинировать ручное создание правил с автоматической генерацией правил по умолчанию. Это позволит сразу создать относительно безопасную среду. Для этого нажмите правой кнопкой на каждой категории и выберите элемент Create Default Rules, после чего система создаст несколько правил по умолчанию. Пример результата для типа Executable Files показан на рис. 5.
Рисунок 5. Правила, созданные по умолчанию Правила по умолчанию позволяют всем пользователям запускать любые исполняемые файлы из каталогов Windows и Program Files. А локальным администраторам разрешают запускать вообще всё. Это достаточно щадящие правила, которые впоследствии могут быть отредактированы под ваши нужды. Так же здесь хочу отметить один достаточно важный момент – пока в конкретной категории правил политики нет ни одного правила, вы можете запускать любые файлы, которые подпадают под эту категорию. Создав хоть одно правило, вы сможете запускать только те файлы, которые подпадают под разрешения в созданных правилах. В результате если мы работаем под учётной записью обычного пользователя, нам будет разрешено запускать файлы только из системных каталогов. Это относится только к тем расширениям, которые проверяются политикой. Но очень часто этого будет недостаточно, именно поэтому придётся создавать и свои правила. Для этого в контекстном меню нужной категории выберите пункт Create New Rule..., после чего вы увидите окно создания нового правила. Правила создаются пошаговым мастером, поэтому разобраться в них будет достаточно просто (см. рис. 6).
Рисунок 6. Окно мастера создания правил В секции Before You Begin вы можете прочитать вступление к мастеру и основные инструкции. В секции Permissions вы можете задать действие для правила – разрешить или запретить запуск подходящих файлов, а также выбрать группу безопасности, на которую это правило будет распространяться. Это намного удобнее, чем механизм применения политик в SRP. Теперь мы можем создать всего одну политику на уровне домена вместо того, чтобы иметь несколько отдельных политик и управлять их применением с помощью Security Filtering. Важно знать, что политики AppLocker не действуют на служебные учётные записи, например, LocalSystem. Дальше в секции Conditions вы выбираете тип правила. Прежде чем выбрать что-то из этого списка, следует рассмотреть каждый тип правил. Правила пути Правила пути достаточно простые, но их нужно использовать осторожно. Правила этого типа следует использовать только для тех путей, по которым пользователи не имеют права на запись. Ни в коем случае не допускается создание правил путей для каталогов, в которые пользователи могут записывать свои файлы. Ведь в результате им ничего не будет стоить подменить легитимные файлы своими и запускать их. Правила пути обычно используются для приложений, которые установлены не в стандартный каталог (Program Files), а находятся по другому адресу – например, в сетевой папке или на другом томе. Вы можете использовать подстановочные знаки – такие, как «?» и «*», а также специальные переменные окружения (см. таблицу). Таблица. Правила пути
Но это неудобство было немного компенсировано другой полезной особенностью – теперь мы можем использовать отдельные переменные для съёмных и оптических носителей. Правила хешей Это один из наиболее популярных типов правил как в SRP, так и в AppLocker. Правило хеша просто создаёт хеш для файла (с использованием алгоритма SHA256) и записывает его в правило. Данный тип правил следует использовать для файлов, которые расположены в разрешённых для записи пользователям каталогах. Действительно, некоторые программы для корректной работы требуют прав на создание файлов в той же папке, в которой находится сам исполняемый модуль. Для таких сценариев целесообразно использовать правило хеша. В этом случае при повреждении файла, подмене, заражении вирусом его хеш будет также изменён, и файл окажется заблокирован для запуска. Однако при частом обновлении программ вам с такой же периодичностью придётся обновлять и соответствующие правила хеша. Правила издателей Правила издателей – это следующая ступень эволюции классических правил сертификатов в SRP, которая привнесла несколько удобных нововведений. Правило издателей вы можете создавать, просто указав файл с цифровой подписью. Следует учесть, что для этого файл должен иметь целостную подпись, а корневой сертификат подписи должен быть помещён в контейнер «Trusted Root Certification Authorites». Если хоть одно из этих условий не выполняется, то создать правило издателя не получится (см. рис. 7).
Рисунок 7. Окно со свойствами правила издателя Если посмотреть на примере Microsoft Office, то мы видим достаточно информации, чтобы достоверно идентифицировать приложение. Такое правило включает поле Subject сертификата цифровой подписи, сведения о продукте, внутреннее имя файла и внутреннюю версию файла. Используя ползунок, мы можем задать и более общее правило, которое, например, будет разрешать запускать любой подписанный файл с указанным полем Subject (в правиле это поле называется Publisher) и внутренним именем без ограничения по версии. Или даже любой файл, который подписан таким сертификатом. Также вы можете использовать и вовсе произвольные настройки правил издателей. Для этого установите флажок Use custom Values – и все поля станут доступны для редактирования вручную. В том числе вы можете указывать степень соответствия версии файла как Exact match, And above и And below. Это можно использовать, когда вы хотите запретить использовать любые версии Excel младше, чем Excel 2003. Тогда вы указываете версию 11.0.0.0 и степень соответствия выставляете в And above. В таком случае запустятся только версии Excel 2003 и более новые. Правила издателей удобны для часто обновляемых программных файлов (например, бизнес-приложения или ваши собственные подписанные сценарии). Если после обновления файлы проходят повторный процесс подписывания, они подпадут под уже существующее правило и будут запускаться. Много правил в одном правиле Следующим удобством является то, что при использовании правил путей или правил хеша вы можете добавлять не только по одному файлу, но и группу файлов в одном каталоге. Технологически вы не имеете возможности добавить группу файлов на основе правила издателя, поскольку правило издателя не опирается на физическое местоположение файлов, а их целостность проверяется только при запуске. Когда вы выбрали правило пути или правило хеша, в следующем окне мастера вы можете нажать Browse Folders, и тогда для правила пути мастер разрешит запускать всё из указанного каталога (это будет заметно по символу подстановки – «*» в конце пути). А для правила хеша мастер найдёт все подходящие файлы в указанной папке и подсчитает для них хеш. При этом важно отметить, что поиск не будет рекурсивным (т.е. не станет включать файлы во вложенных каталогах). Если вы хотите исключить какие-то файлы из полученного списка, достаточно выделить нужные файлы и нажать кнопку Remove. Вы не можете использовать отдельные исключения для правила хеша, поскольку любой хеш уникально идентифицирует конкретный файл. Иными словами, под одно правило хеша может подпадать только один файл. А добавляя несколько файлов (например, все файлы в каталоге), вы создаёте целый набор отдельных правил хеша. Это следующий положительный момент в организации правил в AppLoker, поскольку эти составляющие правила вы можете группировать по какому-либо принципу. Например, создать одно общее правило хеша, которое будет называться Microsoft Office, и внутри этого правила добавить по хешу несколько исполняемых файлов из программного пакета. Зачастую бизнес-приложения так же состоят из нескольких исполняемых модулей. Таким образом, значительно повышается читабельность политик, удобство управления правилами и снижается вероятность ошибки. Я рекомендую именно такой сценарий группировки правил – по типу приложений. Для каждого приложения вы создаёте свою коллекцию правил, в которую включаете все необходимые исполняемые модули. Таким образом, при изменении определённого приложения вам будет очень просто найти нужное правило и отредактировать его. Исключения из правил В отличие от правила хеша правила пути и издателя не позволяют уникально идентифицировать файл и обладают достаточно большой областью действия. Поэтому возможны ситуации, когда вы хотите запретить запуск некоторых файлов, которые подпадают под разрешающее правило. Для этого в секции Exceptions мастера создания правила вы можете указать исключения. Как вы видите на рис. 8, исключения можно создавать, используя все возможности AppLocker. В порядке исключения вы можете добавлять исключаемые пути, хеши файлов и даже цифровые подписи. Например, вы разрешили все файлы по маске %PROGRAMFILES%\Microsoft Office\*, используя правило пути. Однако вы хотите запретить запуск программы PowerPoint. Для этого вы можете создать исключение по правилу пути вида %PROGRAMFILES%\Microsoft Office\Office12\POWERPNT.EXE или по правилу хеша, указав конкретный файл PowerPnt.exe.
Рисунок 8. Окно Exceptions мастера создания правил Другой сценарий может подразумевать, что у вас есть приложение, исполняемые модули которого подписаны различными сертификатами. В таком случае правило издателя будет не очень эффективным решением, и вы хотите создать правило пути или правило хеша для всего каталога. Но вы хотите запретить запуск файлов, которые подписаны определённым сертификатом. В данном случае в секции Exceptions вы указываете тип исключения Publisher и в диалоговом окне поиска выбираете файл с необходимой цифровой подписью. Таким образом вы сможете запускать все файлы из каталога – кроме тех, которые подписаны указанным сертификатом. Исключения или запреты? Внимательные читатели могут задать вопрос: а зачем делать исключения, если их можно вынести в отдельные правила запрета? Действительно, на первый взгляд может показаться, что это более простое решение. Однако запреты всегда являются краеугольным камнем в настройке прав. Применительно к AppLocker здесь есть несколько нюансов, которые следует учитывать при создании запретов. Самый главный из них – порядок применения правил. Для определения возможности запуска файла AppLocker при сортировке правил использует принцип первого попадания (First Match). Это означает, что правила к файлу применяются в строго определённом порядке, и действующим окажется то, которое сработало (т.е. под которое подпал файл) первым. Поэтому знание принципа сортировки правил в AppLocker может сэкономить вам время. Все правила сортируются отдельно по запретам и разрешениям и проверяются в следующем порядке:
Чтобы понять, как это работает, рассмотрим один пример. На компьютере в каталог по умолчанию установлен пакет Microsoft Office, которым можно пользоваться всем. Но группе Accountants необходимо разрешить запускать только программы Word и Excel. Запуск остальных файлов из Program Files разрешён без ограничений. Для решения этой задачи мы должны разрешить весь каталог Program Files по правилу пути для группы Everyone. Поскольку доступ к программам Microsoft Office будет ограничен только для группы Accountants, мы создаём новое запрещающее правило (с действием Deny), которое применяется только к группе Accountants. Теперь программы из пакета Microsoft Office будут разрешены для запуска всем, кроме группы Accountants. Чтобы обеспечить запуск только необходимых приложений из этой папки, мы редактируем запрещающее правило и добавляем два исключения (по правилу пути, хеша или издателя) для файлов Excel.exe и Word.exe. Исходя из порядка сортировки правил, в первую очередь файлы будут проверены на соответствие запрещающему правилу (запрет на каталог Microsoft Office) с учётом исключений. После этого под запретом остаётся весь каталог Mictosoft Office, но без Word.exe и Excel.exe. Если у нас запретов больше нет, то применяется разрешение на каталог Program Files для группы Everyone. Поскольку указанные файлы подходят под это разрешающее правило, они и будут разрешены для запуска. (Разумеется, при условии, что в этом разрешающем правиле нет исключений, действующих на эти файлы). А вот если члены группы Accountants попытаются запустить PowerPoint, то ситуация окажется совершенно другой. Мы снова начинаем с первого шага. Из запрещающего правила отрабатываются исключения, т.е. Word и Excel, а затем файл снова проверяется на соответствие правилу. И даже после удаления исключений PowerPoint всё ещё подпадает под запрет. В таком случае остальные правила не проверяются, а запуск блокируется. Импорт и экспорт правил AppLocker В процессе эксплуатации AppLocker вы можете захотеть зафиксировать конфигурацию политик на отдельной рабочей станции перед изменением существующих правил. Одной из причин такого шага может служить необходимость отката к заведомо работоспособной конфигурации на случай, если изменения приведут к непредвиденным последствиям, а также для использования шаблонов правил. При использовании SRP это зачастую было неразрешимым вопросом, поскольку стандартные шаблоны безопасности (Security Templates) не позволяют заранее настроить правила для SRP и сохранить их в каком-то состоянии. В AppLocker этот недостаток также решён (см. рис. 9).
Рисунок 9. Контекстное меню импорта и экспорта политики AppLocker В контекстном меню AppLocker вы можете выбрать команду Export Policy для экспорта и Import Policy для импорта политик. AppLocker сохраняет все правила и настройки в файле XML, который вы можете редактировать даже без доступа к редактору групповой политики. Если в доменной среде вы можете делать резервные копии политик с помощью GPMC, то в условиях рабочей группы (например, домашнего использования) эта возможность будет очень удобным и простым средством сохранения ваших правил AppLocker. *** В данной статье мы рассмотрели ключевые возможности нового инструмента защиты ПК от выполнения нежелательного (и потенциально злонамеренного) ПО – AppLocker. Также мы рассмотрели методику создания правил на нескольких практических примерах. Изложенный материал является достаточным для начала эффективной работы с AppLocker с целью обеспечения безопасности ваших систем. Если вы заинтересовались данной технологией и хотели бы испытать её в действии, то вы можете загрузить ознакомительную версию Windows 7 Enterprise с сайта Microsoft. Также более глубокое изучение особенностей работы политики AppLocker вы можете прочитать в блоге автора статьи – http://www.sysadmins.lv.
|
ВАДИМ ПОДАНС, эксперт в области автоматизации административных задач при помощи PowerShell, также занимается вопросами компьютерной безопасности и
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
