Запретить все приложения по умолчанию (часть 1)

Введение

Политика ограниченного использования программ ( SRP ) была введена в октябре 2001 года с выпуском Microsoft Windows XP Professional. С тех пор он жил довольно тихой жизнью, можно сказать, слишком тихой. Цель этой серии статей — «вернуть к жизни» SRP в реальном мире, побудить администраторов по всему миру переосмыслить свои программные политики и, возможно, даже внедрить SRP в самом надежном варианте: с помощью белого списка..

Почему СРП?

Бизнес-пользователи сотрудничают с помощью электронной почты, обмена мгновенными сообщениями, одноранговых приложений и т. д., как никогда раньше. Они используют Интернет для поиска и обмена информацией, и по мере расширения этого типа связи растут и угрозы со стороны вредоносного кода. Пользователи также переносят «неконтролируемые» данные на картах памяти, MP3-плеерах и т. д. из дома в офис и обратно — данные, которые могут быть чем угодно, от документов Word или электронных таблиц Excel до игр, хакерских инструментов и любых вредоносных программ. Портативные компьютеры в настоящее время более распространены, чем настольные компьютеры, и они подключаются к «неконтролируемым» сетям с использованием как проводных, так и всех видов беспроводных технологий, что подвергает их серьезному риску взлома с помощью вредоносного кода или атак.

Вот почему я могу придумать множество причин для внедрения SRP сегодня:

Таблица 1

Большинство ИТ-администраторов и менеджеров хотят устранить риск компьютерных вирусов и другие риски, упомянутые в таблице 1. Этого можно добиться путем введения SRP для определения того, какие исполняемые файлы и какие элементы управления ActiveX могут выполняться, если только сценарии с цифровой подписью и одобренные возможность запуска и т. д. Мы действительно можем обеспечить, чтобы только одобренные приложения могли работать на корпоративных компьютерах с помощью встроенной технологии. Мы можем заблокировать клиентские компьютеры и даже серверы, чтобы они могли делать только то, что нам нужно — не больше и не меньше. Это бесплатно и прямо перед нами…

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

фигура 1

фигура 2

С помощью SRP вы даже можете запретить локальным администраторам выполнять код, отличный от того, что вы хотите. Многие компании предоставили обычным пользователям административные права из-за различных проблем с правами или приложениями, но с SRP поверх этой настройки «официальные» сетевые администраторы могут почти чувствовать себя в безопасности…

Вы можете сказать, что ваши пользователи не могут устанавливать неавторизованное программное обеспечение, потому что они не являются локальными администраторами на своих компьютерах (что очень хорошо), но дело в том, что всевозможные исполняемые файлы все еще могут запускаться и выполнять нежелательные задачи. В качестве примера могу привести небольшую утилиту ProduKey, которую удобно иметь, если вы забыли свои ключи продуктов Microsoft (для Exchange, Office, SQL или самой операционной системы Windows). С точки зрения администратора это оставляет нам одну проблему: даже пользователи с ограниченными правами могут читать ключи продукта на локальном компьютере. Это означает, что пользователи могут получить ваши корпоративные ключи многократной установки ( VLK ) и установить свои домашние компьютеры и т. д., используя ваши корпоративные лицензии VLK!

Один из способов предотвратить это — создать политику, которая блокирует любой файл с именем «produkey.exe», но пользователи, вероятно, просто переименуют файл, и тогда он станет исполняемым. Другой способ — заблокировать значение HASH, криптографический отпечаток ProduKey.exe (последняя версия — 1.6), но это значение отличается от более старых или будущих версий исполняемого файла — и даже хуже: значение HASH можно изменить с помощью утилиты слияния файлов, такие как SuperStorm и другие инструменты. Допустим, вам удалось заблокировать ProduKey, вам еще предстоит пройти долгий путь, так как многие другие приложения «там» предлагают точно такие же функции.

Так что на самом деле единственный безопасный способ заблокировать программное обеспечение — это использовать так называемый «белый список»… Давайте посмотрим на разницу между «черным» и «белым» списками.

Черный список против белого списка

Первая фильтрация портов на сетевых маршрутизаторах в начале 1990-х годов была настроена на блокировку определенных портов и разрешение всего остального извне, растущего Интернета. Сетевые администраторы постоянно были на шаг позади хакеров, которые меняли атаки, чтобы постоянно проникать в новые сервисы. Как только администраторы блокировали входящий TELNET, вместо него атаковали RLOGIN или FTP. Это была бесконечная гонка вооружений с хакерами, которая могла привести только к внедрению правила брандмауэра «Запрет по умолчанию». По умолчанию ничего не разрешено, если мы не определим некоторые исключения из правила по умолчанию.

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

Подход « Запретить все приложения по умолчанию » известен как «белый список» ( WL ). При настройке SRP в режиме WL Уровень безопасности по умолчанию устанавливается на « Запрещено » — тогда создаются дополнительные правила с исключениями из правила по умолчанию. Подумайте об этом, ни один файл не может быть выполнен на вашем компьютере, если вы не указали это в политике — вам не нравится эта идея!

Если мы хотим использовать WL, то нам нужен полный список разрешенного программного обеспечения, а если мы хотим использовать HASH в качестве метода идентификации, нам также нужен доступ к исполняемым файлам. Если вместо этого мы хотим использовать правило сертификата, нам нужен либо файл сертификата ( .CER или .CRT ), либо просто доступ к подписанному исполняемому файлу.

Черный список ( BL ) — это уровень безопасности по умолчанию после включения SRP, также известный как «неограниченный» режим. BL можно назвать сизифовой задачей — она никогда не заканчивается и, кроме того, не обеспечивает того же уровня безопасности, что и WL. Из-за большого числа и форм, которые может принимать враждебный код, становится сложной задачей заблокировать все это, взяв «отпечатки кода» или используя имена файлов, если на то пошло. Зачем поддерживать список из 1 000 000+ типов вредоносных программ — список, который постоянно быстро растет — вместо того, чтобы поддерживать список только из 50 или, может быть, 100 приложений, необходимых в организации?

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

Инструмент для проверки концепции Gpdisable, созданный Марком Руссиновичем несколько лет назад, является хорошим примером того, почему WL превосходит BL. С помощью Gpdisable или аналогичного инструмента даже пользователи с ограниченными правами могут блокировать выполнение групповых политик на клиенте Windows, включая SRP, за исключением случаев, когда SRP применяется с помощью белого списка!

Только правило « Запретить все приложения по умолчанию » выдержит испытание временем. К сожалению, нам все еще нужно антивирусное программное обеспечение, чтобы защитить нас от загрузки и выполнения плохого кода. Не будем забывать, что SRP «всего лишь» защищает локальную систему от запуска нежелательного программного обеспечения — он по-прежнему может «нести» исполняемые файлы на жестком диске или в виде вложений электронной почты, вообще не конфликтуя с политиками.

Будущее

Я надеюсь, что в ближайшие годы Microsoft продолжит упрощать процесс утверждения новых приложений. Было бы неплохо, если бы можно было «импортировать» SRP или заданное количество значений HASH, требуемых данным приложением. Для этого потребуется, чтобы сторонние поставщики программного обеспечения поставляли «шаблон» SRP со своими приложениями, чтобы сетевые администраторы могли легко их импортировать, вместо того чтобы создавать политики вручную. Эти «шаблоны» должны состоять из значений HASH всех включенных исполняемых файлов и, желательно, требуемых библиотек динамической компоновки ( DLL ).

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

Я хочу поделиться своей идеей о том, как упростить администрирование WL. При обдумывании правил HASH от администратора требуется открыть объект групповой политики ( GPO ) и перейти к файлам и т. д. Если бы этот процесс мог быть написан по сценарию и запланирован, то все, что администратору сети нужно было бы сделать, это поместить исполняемый файл в центральный каталог «утверждения» (с надлежащим набором разрешений NTFS), когда сценарий запускается, он автоматически создает значение HASH и добавляет значение в «неограниченную» политику в указанном объекте групповой политики. Это также можно сделать для сертификатов: просто поместите сертификат в центральную папку, дождитесь выполнения сценария или процесса, после чего программное обеспечение будет одобрено в сети. Что ж, это всего лишь мечта — надеюсь, кто-нибудь когда-нибудь воплотит ее в жизнь — может быть, даже Microsoft…

Вывод

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

В следующей части этой серии статей мы рассмотрим, как проектируются, внедряются и настраиваются SRP.

внешние ссылки

Брайен М. Поузи: Использование политик ограниченного использования программ, чтобы не допускать игр к вашей сети

Деб Шиндер: Как политики ограниченного использования программ Windows Server 2003 повышают безопасность

Technet: что такое политики ограниченного использования программ?