Однажды мне этот вопрос задал администратор, который рассматривал возможность изменения правил публикации на межсетевом экране ISA 2006 для обеспечения безопасности доступа к почтовой инфраструктуре Exchange 2007. Задача заключалась в том, чтобы разгрузить сервер ISA, используя правила публикации серверов вместо правил Web-публикации для пользователей Outlook, обращающихся к внутренней серверной ферме Exchange 2007 Client Access Server (CAS) из доверенной корпоративной сети.
Пользователи подключались к инфраструктуре Exchange через корпоративный proxy-сервер, не подключенный напрямую к Internet. Идея заключалась в том, что с точки зрения безопасности имеет смысл не выполнять на сервере ISA просмотр трафика на уровне протокола HTTP, а просто осуществлять фильтрацию пакетов согласно заданным на сервере правилам публикации серверов. Просмотр HTTP-трафика настраивается через правило Web-публикации.
Все пользователи Outlook подключались к инфраструктуре через протокол HTTP с SSL-шифрованием (протокол HTTPS). Поэтому вопрос состоял в том, позволит ли совместное использование на серверах ISA протокола SSL и правила публикации серверов разрывать входящие SSL-соединения приложения Outlook?
Идея использования правил публикации серверов вместо правил Web-публикации для разгрузки сервера ISA имеет право на жизнь. При использовании правила публикации сервера служба ISA работает как фильтр пакетов. При использовании правила Web-публикации служба ISA выступает в качестве proxy-сервера для приложений. Proxy-серверы приложений работают на верхнем уровне стека протоколов TCP/IP и могут проверять протоколы прикладного уровня (например, HTTP), но обычно требуют больше ресурсов процессора, чем при обработке правила публикации серверов. Правило публикации серверов действует на транспортном уровне (протокол TCP) стека протоколов TCP/IP и выполняет лишь фильтрацию пакетов, на основе IP-адреса источника и номера порта.
Данными свойствами правил объясняется и то, почему правило публикации серверов не может быть использовано для разрыва SSL-соединений на сервере ISA. Протокол SSL действует между транспортным (TCP) и прикладным уровнями стека протоколов TCP/IP. Правило публикации серверов может переадресовывать пакет протоколов более высокого уровня, таких как SSL, но не имеет возможности разрывать сеансы данных протоколов или транслировать их, например, на соединение к внутренней инфраструктуре по открытому протоколу HTTP. Другими словами, правила публикации серверов поддерживают использование моста SSL, но не поддерживают туннелирование SSL. Поясню, чем отличаются использование моста SSL и туннелирование SSL.
Если вы хотите задействовать правило публикации серверов для публикации своей фермы Exchange CAS, вам необходимо переходить на более высокий уровень стека протоколов, чтобы иметь возможность разрывать сеансы SSL. Такой переход может быть выполнен либо на уровне серверов клиентского доступа CAS либо на каком-либо сетевом устройстве, размещенном между сервером ISA и фермой CAS. В качестве такого устройства могут выступать балансировщик нагрузки или специально разработанное средство снижения интенсивности SSL-запросов (обычно реализуемое аппаратно).
Режим туннелирования SSL предполагает, что защищенный SSL-трафик туннелируется через межсетевой экран. Данные в процессе туннелирования остаются зашифрованными, поэтому межсетевой экран не может их проверить. Туннелирование SSL в большинстве случаев представляет собой канал «точка-точка» — SSL-туннель между браузером (SSL-клиент) и Web-сервером (SSL-сервер). Для организации такого канала на Web-сервере должен быть установлен сертификат подлинности SSL, а на каждом клиенте, при необходимости, клиентский сертификат SSL.
Альтернативой туннелированию является использование моста SSL. При использовании моста SSL-туннель начинается или заканчивается межсетевым экраном. Помимо всего прочего, это означает, что межсетевой экран может проверять содержимое SSL-туннеля. Туннелируемые данные доступны для манипуляций межсетевого экрана в период между их дешифрацией на конце одного туннеля и шифрованием в начале другого.
При использовании моста SSL соединение уже не строится по схеме «точка-точка». Мосты SSL могут быть настроены различными способами.
Вариант 1. Используется единственный SSL-туннель, который начинается на стороне клиента и заканчивается на межсетевом экране. Данный метод требует наличия сертификата SSL на межсетевом экране и при необходимости, наличия сертификата на стороне клиента, если нужна строгая проверка подлинности на клиентском уровне.
Вариант 2. Используется единственный SSL-туннель, который начинается на межсетевом экране и заканчивается на Web-сервере. Этот метод требует наличия сертификата SSL на Web-сервере и при необходимости, наличия сертификата на межсетевом экране.
Вариант 3. Используются два SSL-туннеля, один из которых начинается на стороне клиента и заканчивается на межсетевом экране, а второй начинается на межсетевом экране и заканчивается на Web-сервере. Данный метод требует наличия сертификатов SSL на межсетевом экране, Web-сервере и при необходимости на стороне клиента.
Жан де Клерк (jan.declercq@hp.com) — сотрудник Security Office компании HP. Специализируется на управлении идентификационными параметрами и безопасностью в продуктах Microsoft