Осмотр исходящего SSL трафика в брандмауэрах TMG (часть 2)

В первой части данного цикла мы убедились в важности осмотра исходящего SSL трафика, увидели его основополагающую роль в информационной безопасности сети. После этого мы воспользовались мастером Web Access Policy Wizard для создания политики Web-доступа, которая разрешала бы исходящие соединения с сайтами по протоколам HTTP и HTTPS. Во второй (и последней) части данного цикла статей мы более детально рассмотрим настройку осмотра исходящего SSL трафика и протестируем ее, чтобы убедиться в корректности ее работы.

Изучение конфигурации осмотра исходящего SSL трафика

Теперь, когда создана политика, давайте разберемся с тем, что произошло. Если вы посмотрите на центральную панель консоли брандмауэра TMG, вы увидите, что было создано новое правило для брандмауэра под названием Blocked Web Destinations. Оказывается, что это одно из правил в группе Web Access Policy Group. Вы, может быть, удивитесь: что это за группа. Раньше мы всегда хотели сгруппировать наши правила, но брандмауэры ISA не позволяли этого. А теперь? А теперь брандмауэр TMG позволяет группировать правила. И это хорошо. Что касается нашего правила, вы видите, что оно применяется ко всем пользователям из внутренней сети по умолчанию, а адреса назначения прописаны в колонке ‘To’, где указываются группы фильтрации URL, к которым вы хотите блокировать доступ.

Обратите внимание на секцию над политикой брандмауэра - Web Access Settings. Здесь вы найдете данные для:

• Web Proxy(Web-прокси)
• Authentication(Аутентификация)
• HTTP Compression(HTTP-сжатие)
• Malware Inspection(Проверка на наличие вредоносных программ)
• Web Caching(Web-кэширование)
• HTTPS Inspection(Осмотр HTTPS-трафика)

Таким образом вы получаете доступ сразу ко всем опциям вашего соединения через Web-прокси. Так как в настоящее время нас больше всего интересует настройка HTTPS Inspection, щелкните на ссылку Enabled рядом с HTTPS Inspection.

Появится диалоговое окно HTTPS Outbound Inspection(Осмотр исходящего HTTPS-трафика). На вкладке General(Общие) вам предлагается несколько опций.

Опция Enable inspection of outbound HTTPS traffic(Включение осмотра исходящего HTTPS-трафика) включена в соответствии с настройками, сделанными нами в мастере Web Access Policy Wizard. Также есть секция Validate the certificate and inspect outbound traffic(Проверка сертификата и осмотр исходящего трафика).

В рамке Certificate Inspection Settings(Настройки осмотра сертификата) вы видите опции Use a self-signed certificate generated by Forefront TMG(Использовать самоподписанный сертификат, сгенерированный брандмауэром TMG) и Import an existing trusted CA(Импортировать существующий от доверенного центра сертификации), аналогичные тем, что мы видели в мастере Web Access Policy Wizard.

Щелкните на кнопку Trusted Root Certificate Options (Опции доверенных корневых сертификатов).

Появится диалоговое окно Certificate Deployment Options(Опции установки сертификата), где вы можете:

• Просмотреть подробности сертификата (View Certificate Details). Вы увидите сертификат, используемый брандмауэром TMG
• Осуществить автоматическую установку (Automatic Deployment). Настраивается автоматическая установка в непонятном хранилище сертификатов ‘DS" (подробности позже)
• Экспортировать в файл (Export to File). Вы можете экспортировать сертификат, созданный TMG, в файл, чтобы вы могли настраивать компьютеры, не являющиеся членами домена, доверять подписанному сертификату, чтобы эти машины могли работать с осмотром исходящего SSL-трафика. При выборе этой опции вам нужно вручную импортировать сертификат в хранилище сертификатов машины Trusted Root Certification Authorities, не являющейся членом домена, а не в хранилище сертификатов пользователя или службы. Эту опцию вы также можете использовать в случае, если хотите установить сертификат с помощью стандартной процедуры авторегистрации на основании групповой политики, вместо того, чтобы засовывать его в непонятное «DS».

Диалоговое окно Certificate появляется в тот момент, когда вы нажимаете на кнопку View Certificate Details(Обзор подробностей сертификата). Обратите внимание на информацию Issued To and Issued by(Выданный кому и выданный кем) и даты проверки сертификатов.

Щелкните вкладку Destination Exceptions(Исключения в адресах назначения). Здесь вы можете исключить сайты из осмотра SSL-трафика и указать, нужно ли проверять HTTPS-сертификаты для таких сайтов. Обратите внимание на то, что это различные опции, то есть вы можете исключить какой-нибудь сайт из осмотра SSL-трафика, включив при этом проверку сертификата, и наоборот.

Существует группа по умолчанию Sites Exempt from HTTPS Inspection(Сайты, освобожденные от осмотра HTTPS-трафика), в которую вы можете вносить добавления. Если вы щелкните Site, а затем кнопку Edit, вы увидите диалоговое окно Sites Exempts from HTTPS Inspection Properties. Фактически, это набор доменных имен, которые вы можете использовать в правилах брандмауэра.

Записи по умолчанию в наборе доменных имен:

• *.microsoft.com
• *.windows.com
• *.windowsupdate.com

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

Обратите внимание на кнопку Validation(Проверка) в диалоговом окне HTTPS Outbound Inspection. Когда вы щелкаете сайт, вы можете щелкнуть кнопку Validation, чтобы включить или отключить проверку этого сайта. На графике для сайта Sites Exempt from HTTPS Inspection вы видите, что в колонке Certificates указано No Validation.

На вкладке Source Exceptions(Исключения в адресах источников) вы можете установить исключения, чтобы определенные клиенты исключались из осмотра HTTPS-трафика. Хочу заметить, что исключения вы видите только для компьютеров и наборов компьютеров. Вы не сможете работать на уровне пользователей или групп пользователей, что было бы неплохо.

На вкладке Certificate Validation вы можете установить политику проверки сертификатов, применяемую ко всем клиентам, выполняющим SSL-запросы через брандмауэр TMG. На этой вкладке есть три опции, ни с одной из которых мы не сталкивались при работе с мастером Web Access Policy Wizard. Вот эти опции:

• Block expired certificate after (days)(Блокировать истекшие сертификаты после (дней)): Эта опция позволяет вам указать количество дней, на которое может быть просрочен сертификат, прежде чем он будет блокирован (то есть он не будет проходить проверку). По умолчанию это количество дней равно 15, но вы можете изменять это количество.
• Block server certificates that are not yet valid(Блокировать сертификаты серверов, еще не начавшие действовать): Если сертификат, полученный от Web-сервера, еще не действует, соединение будет сброшено.
• Check for server certificate revocation(Проверить, не отозван ли сертификат): При включенной опции, если серверный сертификат был отозван, соединение будет сброшено. Однако на данный момент в документации не указано, что произойдет в случае, если CRL не проходит проверку из-за недоступности CRL. Я сам еще не проверял эту ситуацию, поэтому, как только я протестирую ее, дам вам знать о результатах.

Последняя вкладка на странице HTTPS Outbound Inspection - Client Notification (Оповещение клиента). Здесь у вас всего одна опция - включение или отключение оповещения пользователя путем проставления отметки возле Notify users that HTTPS inspection is applied.

А теперь давайте вернемся к теме самоподписанных сертификатов, созданных брандмауэром TMG. Большинство из нас, не являясь экспертами в Active Directory или PKI, привыкли к мысли, что можно использовать групповую политику и авторегистрацию для установки сертификатов в Trusted Root Certification Authorities клиентских систем. Долгие годы мы так и делали. Здорово, что можно видеть сертификаты в консоли Group Policy Management, и можно видеть Certificates MMC на контроллере домена. Все просто и понятно.

Когда же мы работаем с TMG по установке сертификатов, все становится запутанным, сложным, непонятным и даже пугающим. Почему? Потому что, если вы посмотрите на Group Policy с целью увидеть сертификат, установленный с помощью авторегистрации, вы его тут не увидите. Если вы посмотрите на Certificates MMC на контроллере домена, вы тоже ничего не увидите.

Так где же искать этот сертификат? Я до сих пор не знаю точно! Джим Харрисон (Jim Harrison) и Дэвид Кросс (David Cross) из команды ISA указали мне направление поиска информации, дав ссылки на статьи, частично охватывающие эту тему, но ни в одной из этих статей не было ответа на мой вопрос: "Как управлять сертификатом, установленным брандмауэром TMG для осмотра исходящего SSL-трафика?’.

Методом проб и ошибок за несколько часов я обнаружил, что при использовании средства certutil можно отобразить сертификат. Вот нужная команда:

Certutil ‘enterprise ‘viewstore

Не спрашивайте меня, что значат ключи ‘enterprise и ‘viewstore, так как документация по certutil невероятно запутана. Однако если вы запустите эту команду, вы увидите то, что показано на рисунке ниже. Фактически вы увидите диалоговое окно View Certificate Store(Обзор хранилища сертификатов), которое я никогда раньше не видел. Я посчитал заголовок этого диалогового окна достаточно интересным. Да, я действительно вижу тут хранилище сертификатов. Но что это за хранилище сертификатов? И что особенного в этом хранилище сертификатов, что в нем содержится только тот сертификат, который был установлен брандмауэром TMG?

Возможно, если вы эксперт по PKI или Active Directory, вам мои вопросы покажутся глупыми, а ответы на них - простыми. Но я всего лишь человек, знающий о PKI и Active Directory только то, что нужно для повседневной работы. И я работал с ними на протяжении 10 лет, ни разу не увидев это самое диалоговое окно View Certificate Store, так что оно не должно быть необходимым для повседневных операций с Active Directory или PKI. Тем не менее, было бы здорово, если бы кто-нибудь объяснил бы, где хранятся такие сертификаты, как работает авторегистрация для этого сертификата, если групповые политики не используются, и каким образом можно удалить сертификат, если он становится ненужным.

На рисунке ниже показана консоль Certificates MMC на клиентском компьютере с Vista. Обратите внимание на то, что сертификат появляется в хранилище сертификатов Trusted Root Certification Authorities, так что мы знаем, какой механизм распределения работает. Вам понадобится сертификат TMG в каждом хранилище сертификатов Trusted Root Certification Authorities компьютеров, чтобы они могли доверять сертификатам, а брандмауэр TMG представлялся бы в качестве SSL-сайтов, к которым подключаются клиенты. Это нужно помнить для случая разрешения проблем с проверкой исходящего SSL-трафика - если она не работает, проверьте сначала клиентские консоли MMC.

Установка клиента брандмауэра на клиентском компьютере

Клиент брандмауэра TMG требуется для оповещения клиента. Я не собираюсь подробно расписывать процесс установки клиента брандмауэра, поскольку вам доступны многочисленные руководства и средства автоматизации этого процесса. Вместо этого я хочу показать вам, где вы можете достать клиентское приложение TMG. Как вы видите на рисунке ниже, клиентское приложение находится либо на установочном DVD (если кто-то еще устанавливает с DVD) или в дереве установочного каталога. Это каталог client, а файл называется MS_FWS.msi.

Доступ к SSL-сайтам и обзор проверки SSL-трафика

Теперь давайте посмотрим, что происходит, когда клиент пытается соединиться с SSL-сайтом. На клиенте Vista SP1 я попробую установить соединение со своим аккаунтом на hotmail. После входа всплывает сообщение, аналогичное показанному на рисунке ниже. Вот текст сообщения:

‘iexplore.exe initiated a secure connection to login.live.com. The connection is being inspected for malware detection. Click this balloon to manage how Outbound Inspection notifications are shown’(iexplore.exe инициировал безопасное соединение с login.live.com. Соединение проверяется на наличие вредоносного кода. Щелкните на этом сообщении для управления способом отображения всплывающих сообщений).

Вот это интересно! Несомненно, такое привлечет внимание пользователей.

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

• Notify me when content sendto secure Web sites are inspected(Оповещать при отправке содержимого исследуемым Web-сайтам). Обратите внимание на небольшую оплошность в тексте. Уверен, ее исправят в окончательной версии. Эта опция по умолчанию включена. Если пользователь не хочет получать уведомления, он может отключить эту опцию. Однако, учитывая, что политика брандмауэра TMG заключается в оповещении пользователей, я не уверен в том, что конфигурация клиента брандмауэра обновится и что опция не будет снова включена автоматически. Надеюсь, что дела обстоят именно так, ведь политика должна контролироваться администратором, а не пользователями.
• Notification Exceptions(Исключения в оповещениях). По умолчанию пользователи получают напоминание о проверке конкретного сайта один раз в час. Но каждый раз, когда они переходят на новый SSL-сайт, они получат напоминание о том, что этот новый SSL-сайт проверяется. Об одном и том же сайте им напомнят только через час. При этом пользователи имеют возможность не получать оповещения для выбранных ими сайтов. Я не знаю, хорошо это или нет, ведь это такая свобода пользователей в контроле над политикой, которая может навредить вашему бизнесу, а пользователь вполне может потом сказать: «Я забыл, что отключил напоминания. Не нужно было давать мне такую возможность!’

А как насчет определения вредоносного кода по SSL-ссылке? Я поставил Web-сервер в тестовой сети и разместил на нем SSL-сайт с вирусной строкой EICAR в текстовом файле. После соединения с этим сайтом при попытке загрузить текстовый файл я получил следующее:

Приятно видеть, что защита от вредоносных программ действительно работает для SSL-ссылки! Это поможет против авторов вирусов, пытающихся воспользоваться SSL-соединениями для отправки своих созданий вашим машинам. Хотя такая тактика будет работать там, где еще нет брандмауэра TMG(или брандмауэра ISA с установленным ClearTunnel).

Что происходит после того, как произведено соединение с SSL-сайтом и заблокирован вредоносный код? Давайте проверим вкладку Alerts(Сигналы тревоги) в консоли брандмауэра TMG. Тут можно настроить определение сигналов тревоги, чтобы информировать вас при обнаружении вредоносного кода, но эта опция по умолчанию не включена. Я заранее включил эти сигналы, чтобы они появлялись после блокирования вредоносного кода.

На рисунке ниже показано предупреждение Malware Inspection Filter Detected Malware (Фильтр проверки на наличие вредоносного кода обнаружил вредоносный код). В панели details говорится, что The Malware Inspection Filter detected malware and either removed it or blocked the message. See the Web Proxy log for details (Фильтр обнаружил вредоносный код и либо удалил его, либо блокировал сообщение. Подробности смотрите в журнале Web-прокси). Хм, хотелось бы побольше информации о вредоносном коде в этом сообщении, но, похоже, за деталями придется обращаться в журнал Web-прокси.

Перейдите к узлу Logging & Reports (Ведение журнала и отчеты) в консоли брандмауэра TMG и щелкните вкладку Logging. Я установил Log Time(Журнальное время) на Last Hour(Последний час) и настроил поле Malware Inspection на Blocked. На рисунке ниже показана запись в файле журнала Web-прокси для заблокированного соединения. В панели detail показан URL, вызвавший блокировку, и имя файла по URL. Обратите внимание, что вредоносный код действительно обнаружен в течении SSL-сессии, поскольку URL - https://www.clickme.com/badfile.txt.

Однако здесь нет никакой информации о наименовании вредоносного кода. Давайте пройдем по полям и посмотрим, сможем ли что-нибудь такое узнать. И вот мы находим поле Threat Name(Наименование угрозы). Обратите также внимание на поле Threat Level(Уровень угрозы), в котором оценивается степень угрозы, исходящая от данного вредоносного кода.

И, наконец, давайте закончим рассмотрением взаимодействий, происходящих между брандмауэром TMG и клиентом. Чтобы клиент брандмауэра мог оповещать пользователя о том, что SSL-сессия осматривается, брандмауэр TMG должен взаимодействовать с клиентским приложением брандмауэра. Это что-то новое, ведь в предыдущих версиях брандмауэра, взаимодействия между клиентом и брандмауэром всегда инициировались клиентом. Однако в случае с TMG взаимодействие двунаправленное. Как клиент брандмауэра может инициировать взаимодействие с брандмауэром TMG, так и брандмауэр TMG может инициировать взаимодействие с клиентом.

Различие заключается в используемых протоколах. Когда клиент брандмауэра соединяется с брандмауэром TMG, используется TCP-порт 1745. В обратном случае соединение идет через UDP-порт 1745.

На рисунке ниже показаны соединения брандмауэра TMG с клиентом брандмауэра на клиентской системе Vista SP1. Обратите внимание: используемый протокол - Microsoft Firewall Client (Notifications), а также на то, что при включении оповещений включается системное правило политики, разрешающее исходящий доступ от брандмауэра к клиентам.

Заключение

В этом двухчастном цикле статей об осмотре исходящего SSL-трафика для брандмауэра TMG мы узнали, почему так важен такой осмотр для любой сети, в которой вы хотите обеспечить базовый уровень сетевой безопасности. Мы познакомились с настройкой политики Web-доступа, позволяющей исходящий доступ для соединений по протоколам HTTP и HTTPS. Осмотр исходящего SSL-трафика включается в процессе работы мастера Web Access Policy Wizard. После включения осмотра исходящего SSL-трафика мы рассмотрели подробности конфигурации, а также громко повозмущались загадками сертификатов, установленных брандмауэром TMG. Наконец мы установили исходящее SSL-соединение, чтобы увидеть всплывающее предупреждающее сообщение, и увидели, как блокируется вредоносный код. Блокирование вредоносного кода очень важно, так как речь идет об SSL-туннеле.