Пример каскадного включения брандмауэров

Как надежно защитить приложения и службы Microsoft, обращенные в Internet? Это можно сделать с помощью Microsoft Internet and Security Acceleration (ISA) Server 2004, который значительно превосходит своего предшественника, ISA Server 2000. ISA Server 2004 располагает сетевым брандмауэром, выполняющим как проверку пакетов на соответствие заданным условиям (на 4-м транспортном уровне модели OSI — Open System Interconnection — и ниже), так и фильтрацию на прикладном 7-м уровне для всех имеющихся интерфейсов.

Многие организации располагают инфраструктурой на основе брандмауэров, но тем не менее не прочь воспользоваться преимуществами ISA Server 2004. Брандмауэр ISA Server 2004 отличается чрезвычайной гибкостью и обеспечивает ряд практичных вариантов развертывания. Один из самых распространенных и наиболее безопасных вариантов — каскадное (back-to-back) подключение брандмауэров. В этом случае традиционный аппаратный брандмауэр с фильтрацией пакетов располагается на внешней стороне (front end) и обеспечивает базовую фильтрацию с проверкой пакетов на соответствие заданным условиям, защищая демилитаризованную зону (DMZ) между брандмауэром и интерфейсом в локальную сеть, а брандмауэр ISA Server 2004 на внутренней стороне выполняет как фильтрацию пакетов, так и проверку приложений, защищая основные ресурсы предприятия.

ISA Server часто применяется для проверки дистанционного доступа к службам Microsoft Exchange Server, и некоторые технологии брандмауэра обеспечивают уникальный уровень защиты связанных с Internet служб Exchange, особенно Microsoft Outlook Web Access (OWA). Такой сценарий — хороший пример процедур, необходимых для того, чтобы разместить брандмауэр ISA Server за аппаратным брандмауэром с фильтрацией пакетов. На рисунке показано высокоуровневое представление каскадного включения брандмауэров. Перечислим основные характеристики топологии сети и брандмауэров.

  • Аппаратный брандмауэр с фильтрацией пакетов в соответствии с заданными условиями (на базе специализированной микросхемы), который в данной статье называется «аппаратным брандмауэром», размещается на внешней стороне. Этот брандмауэр обеспечивает защиту на уровне 4 и ниже для узлов в периметре сети между аппаратным брандмауэром и брандмауэром ISA Server 2004, который в статье именуется брандмауэром ISA. Сегмент DMZ — неаутентифицированный: общедоступные серверы в DMZ могут потребовать локальной аутентификации на сервере, но для входа в сегмент аутентификация не нужна.
  • ISA-брандмауэр для фильтрации с проверкой пакетов на соответствие заданным условиям и на прикладном уровне (уровне 7) размещается на внутренней стороне. Данный брандмауэр находится ближе к основным ресурсам предприятия и должен обеспечить более надежную защиту, чем аппаратный брандмауэр. ISA-брандмауэр достигает этой цели, выполняя ту же проверку на соответствие заданным условиям, что и аппаратный брандмауэр, но его возможности шире, чем у аппаратного брандмауэра, благодаря дополнительной проверке состояния на прикладном уровне. Кроме того, для всех входящих и исходящих соединений через брандмауэр ISA требуется надежная аутентификация группы или пользователя.
  • Брандмауэр ISA располагает тремя сетевыми интерфейсами: внешним интерфейсом для связи с сегментом DMZ, внутренним интерфейсом для подключения к сетевому сегменту инфраструктуры служб, содержащему базовые серверы инфраструктуры (например, контроллер домена (DC) и сервер глобального каталога (GC), внешний сервер Exchange, внутренний сервер Exchange), и другим внутренним интерфейсом для соединения с сетевым сегментом, в котором находятся клиентские машины. Не допускаются неаутентифицированные соединения внешнего интерфейса с сегментом инфраструктуры служб и запрещены все соединения из клиентского сегмента, за исключением необходимых для работы сетевых служб. Такая структура защищает серверы сетевой инфраструктуры не только от внешних нападений, но и от атак с машин клиентского сегмента.
  • Система ISA Server — член внутреннего сетевого домена. Некоторые специалисты считают, что членство в домене может нарушить безопасность внутренней сети в случае, если поражена машина ISA Server. Однако если это произойдет, членство сервера в домене мало повлияет на размер ущерба, нанесенного взломщиком. Польза от членства системы ISA Server в домене значительно перевешивает любые теоретические недостатки такого подхода.
  • Мост SSL-SSL (Secure Sockets Layer) брандмауэра ISA не позволяет скрыть вредные программы в туннелях SSL. Удаленный Web-клиент прокладывает туннель через аппаратный брандмауэр и завершает сеанс SSL с внешним интерфейсом брандмауэра ISA. Брандмауэр ISA расшифровывает пакеты, выполняет фильтрацию на прикладном уровне и заново шифрует пакеты для пересылки по второму каналу SSL, проложенному между внутренним интерфейсом брандмауэра ISA и внешним сервером Exchange.
  • Брандмауэр ISA настроен на предъявление клиентского сертификата на Web-узле OWA внешнего сервера Exchange. В результате внешний сервер Exchange защищен от попыток взломщика использовать другую машину (например, через фальшивый IP-адрес) для действия от имени ISA-брандмауэра и перенаправления соединений на внешний сервер Exchange. У взломщика нет действительного клиентского сертификата, и соединение не будет установлено даже при наличии действительных учетных данных пользователя OWA. Web-клиент не предъявляет клиентский сертификат в сервере Exchange или брандмауэре ISA; только брандмауэр ISA предъявляет клиентский сертификат при организации SSL-линии с внешним сервером Exchange.
  • DC в секторе инфраструктуры служб работает со службой Microsoft Certificate Services и настроен как центр сертификации предприятия (Certification Authority — CA). Корпоративный CA имеет много преимуществ перед автономным CA, в основном благодаря возможности использовать мастер, чтобы запросить и установить сертификат Web-узла на внешнем сервере Exchange, и автоматическому размещению корневого сертификата корпоративного CA в хранилищах сертификатов корневого центра сертификации всех членов домена.

Конечно, конфигурацию брандмауэра и сетевую инфраструктуру можно настроить различными способами. Например, многие администраторы брандмауэров требуют, чтобы в сети, содержащей DC и другие ключевые серверы инфраструктуры, не было серверов, обращенных в Internet. В этом случае можно дополнить ISA-брандмауэр четвертым сетевым интерфейсом; разместить внешний сервер Exchange в специализированном, проверяемом, ограниченном сетевом сегменте, предназначенном только для доступа; использовать правила доступа ISA-брандмауэра, чтобы разрешить применение только определенных протоколов для связи внешнего сервера Exchange с внутренним сервером Exchange и сервером DC/GC в сегменте инфраструктуры служб.

Рассмотрим пример конфигурации. Предположим, что CA предприятия расположен в одном домене с серверами Exchange. Для публикации OWA-сайта внешнего сервера Exchange для удаленных пользователей в Internet требуется выполнить следующие процедуры.

  1. Настроить общедоступный сервер DNS для перенаправления входящих соединений OWA на нужный адрес.
  2. Настроить аппаратный брандмауэр на перенаправление входящих TCP-соединений с портом 443 в брандмауэр ISA.
  3. Запросить и привязать сертификат Web-узла к Web-узлу OWA на внешнем сервере Exchange.
  4. Экспортировать сертификат Web-узла в файл.
  5. Настроить каталоги OWA на аутентификацию в режиме Basic, задействовать соединения SSL и потребовать от брандмауэра ISA клиентский сертификат.
  6. Создать учетную запись пользователя для брандмауэра ISA.
  7. Запросить клиентский сертификат для службы Web-proxy брандмауэра ISA.
  8. Импортировать сертификат Web-узла в хранилище сертификатов брандмауэра ISA.
  9. Импортировать клиентский сертификат брандмауэра ISA в хранилище персональных сертификатов службы ISA-брандмауэра.
  10. Создать правило Web-публикации OWA на брандмауэре ISA.
  11. Подкрепить правило Web-публикации OWA фильтром HTTP.
  12. Создать файл HOSTS в ISA-брандмауэре, который связывает полное доменное имя (fully qualified domain name — FQDN) сайта OWA с внутренним IP-адресом OWA-сайта.
  13. Запросить и установить корневой сертификат CA в клиентском браузере.

Рассмотрим первые пять этапов. Об остальных этапах речь пойдет в следующей статье.

1. Настройка общедоступного DNS.

Первый шаг проекта публикации OWA — привести в порядок DNS. Идеальная конфигурация — распределенная инфраструктура DNS, в которой одно имя соответствует различным IP-адресам, в зависимости от местонахождения пользователя. Например, если пользователь находится в корпоративной сети, то имя owa.domain.com преобразуется в IP-адрес внешнего сервера Exchange корпоративной сети. Если пользователь находится в удаленном филиале, то имя owa.domain.com преобразуется в IP-адрес, доступный из Internet.

Хост-запись DNS зависит от схемы IP-адресации, используемой в DMZ и сегменте инфраструктуры служб. Если между Internet и DMZ выполняется трансляция сетевых адресов (Network Address Translation — NAT), то следует зарегистрировать IP-адрес интерфейса WAN аппаратного брандмауэра в качестве FQDN, с помощью которого удаленные пользователи могут обращаться к сайту OWA. Если в DMZ и маршрутах аппаратного брандмауэра между Internet и DMZ используются общедоступные адреса, следует задействовать IP-адрес внешнего интерфейса ISA-брандмауэра.

2. Настройка аппаратного брандмауэра.

Этот брандмауэр не выполняет фильтрацию с проверкой на соответствие заданным условиям на прикладном уровне, поэтому он не может определить URL назначения входящего запроса, проанализировав заголовки HTTP. Поэтому данный брандмауэр должен перенаправлять все входящие соединения для сайта OWA на IP-адрес внешнего интерфейса брандмауэра ISA. Эта процедура для разных брандмауэров различна, но все простые брандмауэры с проверкой пакетов на соответствие заданным условиям обеспечивают маршрутизацию или обратную трансляцию сетевых адресов (reverse NAT) на конкретный сокет (то есть IP-адрес, протокол и порт).

3. Запрос и привязка сертификата Web-узла к Web-узлу OWA.

В процессе настройки моста SSL-SSL брандмауэр ISA представляет Web-узел OWA таким образом, что клиентские браузеры устанавливают соединение с внешним интерфейсом брандмауэра ISA. Брандмауэр ISA представляет Web-узел OWA, предъявляя сертификат Web-узла, содержащий такое же имя, как Web-узел OWA. Например, если адрес Web-узла OWA при организации SSL-сеанса с пользователем — https://owa.domain.com/exchange/, то брандмауэр ISA предъявляет сертификат с общим именем owa.domain.com. CA предприятия расположен в одном домене с серверами Exchange, поэтому с помощью интегрированного с Microsoft IIS мастера Web Site Certificate Request Wizard можно запросить и привязать сертификат к Web-узлу OWA.

На внешнем сервере Exchange следует открыть консоль Microsoft Management Console (MMC) с Internet Information Services (IIS) Manager, щелкнуть правой кнопкой мыши на Default Web Site и выбрать пункт Properties из контекстного меню. Затем нужно перейти к вкладке Directory Security и щелкнуть на Server Certificate, чтобы запустить мастер Web Site Certificate Request Wizard.

Если сертификат Web-узла для сайта OWA отсутствует, то на странице Server Certificate необходимо выбрать пункт Create a new certificate. Если сертификат имеется (возможно, был получен из коммерческого источника сертификатов), требуется щелкнуть на кнопке Assign an existing certificate. В данном примере предполагается, что требуется создать новый сертификат.

Поскольку имеется функционирующий корпоративный CA, следует выбрать режим Send the request immediately to an online certification authority. Если используется автономный CA, то единственный выход — подготовить автономный запрос и вручную предъявить его с помощью Web-узла регистрации CA. Мастер приводит к странице Your Site?s Common Name (экран 1).

Эта страница — ключевая в мастере. Введенные в ней данные определяют стандартное имя (common name — CN) сертификата Web-узла. CN должно соответствовать как имени, используемому удаленными пользователями для доступа к Web-узлу OWA, так и имени, которое применяется при перенаправлении, когда создается правило Web-публикации в брандмауэре ISA. В данном примере используется имя owa.domain.com. В производственной среде применяется имя, с помощью которого удаленные пользователи обращаются к Web-узлу OWA.

Работу с мастером следует продолжить до последней страницы и завершить нажатием кнопки Finish. После этого во вкладке Directory Security появится кнопка View Certificate.

4. Экспорт сертификата Web-узла в файл.

Теперь сертификат Web-узла можно экспортировать в файл. Позднее этот файл будет использован для импорта сертификата Web-узла и частного ключа в хранилище сертификатов брандмауэра ISA.

Щелкните на кнопке View Certificate во вкладке Directory Security. Затем следует перейти к вкладке Certification Path окна Certificate. В иерархию входят корневые сертификаты CA и Web-узла. Если имя Root CA отмечено красным символом x, то корневой сертификат CA не содержится в хранилище сертификатов корневого центра сертификации внешнего сервера Exchange. Однако если используется CA предприятия, то его корневой сертификат автоматически помещается в хранилище сертификатов корневого центра сертификации.

Чтобы запустить мастер Certificate Export Wizard, нужно перейти к вкладке Details и щелкнуть на кнопке Copy to File. На странице Export Private Key следует выбрать пункт Yes, export the private key. Администраторы часто забывают о необходимости активизировать данный режим — это одна из самых распространенных причин неработоспособности мостов SSL-SSL.

На странице Export File Format следует выбрать Personal Information Exchange-PKCS #12 (.PFX) и сбросить флажок Enable strong protection. Этот режим необходимо отменить, так как он требует вмешательства пользователя, а в нашей процедуре публикации нет соответствующего механизма взаимодействия. Также следует установить флажок Include all certificates in the certificate path if possible.

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

На странице File to Export следует ввести полный путь с именем файла. В данном примере используется C:owacert. Расширение имени файла указывать не обязательно; оно будет добавлено автоматически.

Для завершения работы мастера следует щелкнуть на кнопке Finish. Затем нужно щелкнуть на кнопке OK в диалоговом окне Default Web Site Properties.

Файл требуется скопировать на сменный носитель. Позднее он будет скопирован на машину, на которой размещен брандмауэр ISA.

5. Настройка конфигурации каталогов OWA.

OWA-каталоги — ExchWeb, Exchange и Public — необходимо настроить на организацию SSL-соединений, работу с клиентскими сертификатами и аутентификацию Basic. Использование только Basic-аутентификации обеспечивает максимальную совместимость и наиболее прозрачный доступ для удаленных пользователей OWA, но если планируется поддержка Exchange ActiveSync (как в нашем примере), то необходимо также активизировать аутентификацию Integrated в каталоге Exchange.

В левой панели оснастки Internet Information Services (IIS) Manager следует щелкнуть правой кнопкой мыши на каталоге ExchWeb и выбрать из контекстного меню пункт Properties. Затем нужно перейти на вкладку Directory Security и щелкнуть на кнопке Edit в разделе Authentication and access control, чтобы открыть диалоговое окно Authentication Methods. Обязательно должен быть сброшен флажок Enable anonymous access. Не следует предоставлять удаленному пользователю возможность установить неаутентифицированное соединение с любым каталогом сервера OWA. Следует установить флажок Basic authentication и ввести имя NetBIOS выбираемого по умолчанию домена в текстовом поле Default domain. В данном примере имя NetBIOS выбираемого по умолчанию домена — DOMAIN. Следует щелкнуть на кнопке OK.

Не покидая вкладку Directory Security диалогового окна ExchWeb Properties, нужно щелкнуть на кнопке Edit в разделе Secure Communications. В диалоговом окне Secure Communications (см. экран 2) необходимо установить флажки Require secure channel (SSL) и Require 128-bit encryption и активизировать режим Require client certificates. Щелкните на кнопке OK, чтобы сохранить параметры защищенных соединений, а затем на кнопке OK для сохранения конфигурации каталога ExchWeb. В диалоговом окне Inheritance Overrides требуется щелкнуть на кнопке Select All, а затем нажать OK.

Для подключения к Web-узлу OWA брандмауэр ISA должен предъявить клиентский сертификат, но этот сертификат обеспечивает только организацию SSL-соединения между внутренним интерфейсом брандмауэра ISA и внешним сервером Exchange. Учетные данные, предоставляемые удаленным пользователем, открывают доступ к почтовому ящику. Требование клиентского сертификата не оказывает никакого влияния на доступ к почтовому ящику пользователя; он лишь определяет, какие устройства могут установить прямое соединение с внешним сервером Exchange.

Впоследствии необходимо запросить клиентский сертификат для службы Firewall Service брандмауэра ISA и настроить брандмауэр ISA для передачи клиентского сертификата на Web-узел OWA.

В левой панели оснастки Internet Information Services (IIS) Manager нужно щелкнуть правой кнопкой мыши на каталоге Exchange и выбрать пункт Properties, а затем перейти прямо на вкладку Directory Security, открыть диалоговое окно Secure Communications, как объяснялось выше, и установить те же флажки и режимы, которые были выбраны для каталога ExchWeb. Нажмите OK.

Не покидая вкладки Directory Security, следует щелкнуть на кнопке Edit в разделе Authentication and access control. На этот раз нужно установить флажки Integrated Windows authentication и Basic authentication, а затем ввести имя NetBIOS в качестве стандартного имени домена в текстовом поле Default domain. Активизация режима Integrated authentication в каталоге Exchange обеспечивает свободу публикации доступа ActiveSync.

Щелкните на кнопке OK, чтобы сохранить параметры аутентификации, затем на кнопке OK для сохранения конфигурации каталога Exchange.

Процедуру следует повторить для каталога Public, активизировав только режим аутентификации Basic в диалоговом окне Authentication Methods.

В следующей статье будут рассмотрены этапы 6-13. Читатели смогут получить полное представление о том, как с помощью ISA Server 2004 повысить безопасность обращающихся в сеть приложений, например, OWA.

Главный автор материалов для http://www.isaserver.org. Совладелец фирмы TACteam и соавтор книги Configuring ISA Server 2000 (издательство Syngress). tshinder@isaserver.org