В первой части этой серии, посвященной конфигурации брандмауэра ISA на нескольких зонах сетевой безопасности, мы рассмотрели концептуальные и проектные решения, связанные с интеллектуальной периметризацией сети. Во второй части, я описал пример сети, используемой в этой серии статей, цели проекта и природу трафика, который необходим для прохождения через брандмауэр ISA в различные зоны сетевой безопасности.
В этой, третьей части нашей серии, мы рассмотрим часто непонятные разделы, касающиеся соглашений по наименованию и инфраструктуры DNS, необходимой для поддержки конфигурации. Очень многие запутываются в этой области, поэтому необходимо уделить очень пристальное внимание к понятиям, обсуждаемым в этой статье. После того, как вы поймете принципы и проблемы, связанные с правильной инфраструктурой наименования сертификатов, вы никогда не встанете перед вопросом, почему ваши безопасные правила публикации Web и сервера (Server Publishing Rules) работают неправильно.
Если вы пропустили другие статьи из этой серии, то можете найти их здесь:
Первая тема, которая всегда вызываем замешательство – это соглашения по наименованию сертификатов, которые используются для поддержки SSL соединений к и через брандмауэр ISA. Вы должны заблаговременно решить, какие названия в сертификатах Web site должны быть связаны со следующими сетевыми элементами:
Сперва немного отвлечемся. Мы должны создать два Web listener для поддержки OWA, опубликованного с помощью механизма аутентификации брандмауэра ISA на основе форм. OWA FBA значительно повышает уровень безопасности, который брандмауэр ISA может предоставить для доступа к удаленным OWA соединениям. Для этого также необходимо отключить функцию FBA на front-end сервере Exchange.
В добавок, вы не можете использовать тот же самый listener для правила OWA Web Publishing Rule и правила OMA/ActiveSync/RPC-HTTP Web Publishing Rule, потому что клиентское программное обеспечение OMA/ActiveSync/RPC-HTTP не умеет работать с предоставляемыми им формами, и прекращает соединение, не информируя вас, почему оно было прекращено.
Теперь, когда вы знаете, что у вас должно быть два Web listener, вы также должны знать, что вы не можете создать два Web listener, используя одни и тот же сокет. Сокет – это комбинация IP адреса, протокола и порта.
Например, если мы создаем Web Listener, который будет использоваться для правила OWA Web Publishing Rule, которое слушает по TCP порту 443 по IP адресу 192.168.1.70, то мы не можем создать второй Web listener, который будет использоваться для правила OMA/ActiveSync/RPC-HTTP Web Publishing Rules, используя тот же самый сокет, т.е. этот сокет не может быть определен на TCP потру 443 по IP адресу 192.168.1.70. В этом и заключается причина того, что мы должны связывать второй IP адрес с внешним интерфейсом брандмауэра ISA для поддержки создания второго Web listener.
Примечание:
Вы можете обойти проблему необходимости двух IP адресов во внешнем интерфейсе брандмауэра ISA для поддержки правил OWA FBA Web Publishing Rules и OMA/ActiveSync/RPC-HTTP с помощью использования очень хорошего средства от Collective Software (www.collective.com) под названием FlexAuth. FlexAuth позволяет вам использовать один IP адрес для всех ваших опубликованных служб Exchange Web. Подробное описание FlexAuth я приведу в другой статье на этом сайте.
Последняя проблема, касающаяся сертификатов, связанных с Web listener, с которой мы будем иметь дело, заключается в том, что мы не можем связать один и тот же сертификат с несколькими listener (слушателями). Если мы создаем сертификат с общим названием owa.msfirewall.org и связываем его с первым Web Listener (который мы используем для правила OWA FBA Web Publishing Rule), то мы не можем использовать то же самый сертификат для второго Web Listener, который мы будем использовать для правила OMA/ActiveSync/RPC-HTTP Web Publishing Rule. Мы должны создать второй сертификат с другим названием, таким как rpc.msfirewall.org и связать этот сертификат со вторым Web listener.
Однако, проблемы с сертификатами еще не закончились. Т.к. брандмауэр ISA выполняет связь SSL к SSL, то первое соединение от удаленного клиента завершается на внешнем интерфейсе брандмауэра ISA. Затем брандмауэр ISA расшифровывает соединение, выполняет полную проверку содержимого прикладного уровня, затем заново шифрует содержимое и направляет информацию по второму SSL каналу между ним самим и front-end сервером Exchange. Брандмауэр ISA должен быть настроен для использования названия сертификата, связанного с Web сайтом на front-end сервере Exchange для того, чтобы установить второе безопасное SSL соединение.
Т.к. вы можете связать один сертификат Web site, то вы связываете Web Listener на брандмауэре ISA с Web сайтом на front-end сервере Exchange, я предпочитаю создать третий сертификат Web site и связать этот сертификат с front-end сервером Exchange.
Например, вы можете создать сертификат Web site под названием feexchange.msfirewall.org и связать этот сертификат с Web сайтом front-end сервера Exchange. Если вы настраиваете правило Web Publishing Rules для передачи соединений на feexchange.msfirewall.org и используете запись в файле HOSTS на брандмауэре ISA, таким образом, чтобы название feexchange.msfirewall.org соответствовало IP адресу front-end сервера Exchange.
Примечание:
Причина, по которой мы используем запись в файле HOSTS, заключается в том, что название в сертификате будет таким же, что и название, которое front-end сервер Exchange зарегистрировал в интегрированном DNS Active Directory. Альтернативой использования записи в файле HOSTS является ручное создание записи Host (A) в DNS для поддержки названия в сертификате Web сайта front-end сервера Exchange.
Наконец, вы должны придумать название для сертификата, связанного с Web сайтом OWA на back-end сервере Exchange. В то время как внешние пользователи не затрагиваются конфигурацией на back-end сервер Exchange, то внутренних пользователей это касается напрямую. Вам необходимо связать сертификат с back-end сервером Exchange, который имеет такое же название, как и название, которое вы хотите использовать для доступа к сайту.
Например, вы хотите создать сертификат под названием be.msfirewall.org и связать этот сертификат с back-end сервером Exchange. Тогда пользователи, которые соединяются с OWA сайтом back-end сервера Exchange, должны использовать URI https://be.msfirewall.org/exchange для доступа к сайту. Мы еще подробно обсудим соглашения об инфраструктуре DNS, и то, как работать со схемами наименования, которые требуют различные названия для использования внешними и внутренними пользователями.
Соглашения по наименованию сертификатов для SMTP, POP3 и IMAP4 сайтов немного проще, чем соглашения по наименованию Exchange Web сайтов. Причина этого заключается в том, что мы должны использовать правила Server Publishing Rules для публикации этих безопасных сайтов на front-end сервере Exchange. Правила Server Publishing Rules в основном противоположны правилам NAT, на основе которых соединения к брандмауэру ISA проходят проверку на прикладном уровне. Безопасные соединения не прекращаются на брандмауэре ISA, конечная остановка – это сам front-end сервер Exchange.
Существуют два основных требования, касающиеся связи сертификатов для SMTP, POP3 и IMAP4 сайтов с front-end сервером Exchange:
Вы можете создать три сертификата с различными названиями и связать их с каждым из сайтов. Например, сертификаты imap.msifrewall.org, pop.msfirewall.org и smtp.msfirewall.org могут быть связаны соответственно со службами IMAP4, POP3 и SMTP. Однако, я обычно советую использовать одинаковые названия для всех сайтов. Однако, помните, что если вы используете одинаковые сертификаты для всех сайтов, и по каким-то причинам вам надо аннулировать этот сертификат, то будет аннулированы сертификаты для всех трех сайтов. Напротив, если вы создаете различные сертификаты для каждого сайта, то вы можете удалить один сертификат не трогая сертификаты для других сайтов.
В тестовой сети мы будем использовать следующие соглашения по наименованию сертификатов для Web сайтов:
На рисунке ниже показано участие серверов в этих соединениях и названия сертификатов, связанные с соответствующими Web Listener/Web сайтами.
Рисунок 1
Примечания по установке сертификатов
Далее я думаю рассказать о деталях по установке сертификатов и о том, как запрашивать и устанавливать сертификаты на брандмауэра ISA, front-end сервере Exchange и back-end сервере Exchange. Проблема с установкой сертификатов заключается в том, что методы, используемые для установки сертификатов, отличаются в зависимости от инфраструктуры PKI, на которую производится установка.
Если вы решите использовать службы Microsoft Certificate Services, то у вас есть выбор установки либо корпоративной CA, либо отдельно стоящей CA. Практически во всех ситуациях, когда установлен брандмауэр ISA, лучше использовать корпоративный CA. Я установил корпоративный CA на контролере домена в корпоративной сети в тестовой сети, используемой в этой статье.
Брандмауэр ISA, back-end сервер Exchange и front-end сервер Exchange Server являются членами одного домена, что и компьютеры корпоративной CA. Это позволяет сертификатам корпоративной CA автоматически устанавливаться для всех членов домена. Следствием этого является то, что все члены домена будут доверят сертификатам, выпускаемым этой корпоративной CA. Единственный недостаток такого сценария заключается в том, что front-end сервер Exchange автоматически не получит сертификат CA, не смотря на то, что он является членом домена. Причина этого заключается в том, что существует ошибка в фильтре RPC (или может быть это специальная возможность?), которая запрещает автоматическую регистрацию, когда включена опция strict RPC compliance.
Но это не основная проблема, потому что вы можете включить сертификат Ca в файл сертификатов, который также содержит сертификат Web сайта. Вы можете затем поместить CA сертификат в хранилище Trusted Root Certification Authorities machine certificate store на front-end сервере Exchange Server.
Обратите внимание, что существует много способов, с помощью которых вы можете решить проблему установки сертификатов как для корпоративной, так и для отдельно стоящей CA.
Для этой статьи я установил сертификаты с помощью мастера IIS Certificate Request Wizard на back-end сервер Exchange Server с помощью следующей процедуры:
Может показаться, что это очень длительный процесс, но вы можете завершить всю процедура менее чем за десять минут. Конечно, существуют другие способы получить машинные сертификаты, например, использование регистрации Web сайта на CA. Однако, эти сайты различаются в зависимости от того, устанавливаете вы корпоративный CA или отдельно стоящий CA. Более подробно вы можете узнать об этом в VPN Deployment Kit или в Exchange Deployment kit.
Хорошо спроектированная инфраструктура DNS очень важна, если соединения на удаленный доступ образуют пару с PKI. Причина для этого теперь может быть очевидной: названия сертификатов должны соответствовать названиям, включенным в запросы, посланные клиентами. В добавок, названия, используемые внешними корпоративными клиентами при подключении к SSL/TLS ресурсам, должны также соответствовать названиям сертификатов Web сайтов, связанными с сетевыми службами, к которым эти клиенты подключаются.
Ключ к успеху – это раздельная DNS инфраструктура. Теперь, перед тем как вы убежите в ужасе, я должен объяснить это:
Раздельная DNS инфраструктура никак не связана с использованием одного и того же названия для внешнего и внутреннего сетевых доменов. Для поддержки раздельной DNS инфраструктуры вам не надо изменять название вашего домена Active Directory или любого другого внутреннего DNS домена.
Раздельная DNS инфрастуктура – это ни что иное, чем две зональных DNS базы данных, обслуживающие доменные названия, одна для пользователей корпоративной сети, а другая для пользователей, располагающихся вне корпоративной сети, например, пользователи, которые используют удаленных доступ с помощью интернет.
Например, предположим, что название вашего внутреннего домена сети isafirewall.local. Вы знаете, что не можете использовать название домена верхнего уровня .local в интернет, поэтому вы регистрируете доменное название isafirewall.org, чтобы разрешить удаленный доступ к сервисам вашего сервера Exchange.
Вы настраиваете ваш внешний DNS сервер, который авторизован для домена isafirewall.org так, чтобы owa.isafirewall.org соответствовал ISA адресу внешнего интерфейса брандмауэра ISA, который будет использоваться Web Listener на основе правила OWA Web Publishing Rule, чтобы разрешить входящие Web запросы. Сертификат, связанный с Web listener имеет название owa.isafirewall.org. Внешние пользователи могут успешно устанавливать соединения с сайтом OWA, т.к. их клиентские системы расположены на удаленных сайтах в интернет и используют интернет DNS сервера, которые сопоставляют доменное имя isafirewall.org IP адресам, связанными с внешним интерфейсом брандмауэра ISA (или по крайней мере адресам устройства, которое маршрутизирует входящие соединения на внешний интерфейс брандмауэра ISA.)
Но что происходит, когда те же самые пользователи возвращаются назад в корпоративную сеть, после того как их путешествие завершилось? Пользователи попытаются получить доступ к серверу OWA с помощью того же названия http://owa.isafirewall.org и у них это не получиться. Почему? Потому что название owa.isafirewall.org соответствует внешнему IP адресу, а не действительному IP адресу сервера Exchange в корпоративной сети.
Как решить эту проблему? С помощью использования раздельной DNS инфраструктуры. Вам не надо изменять название вашего внутреннего домена DNS Active Directory. Все что вам необходимо, это настроить DNS на ваших внутренних сетевых DNS серверах на такое же доменное название isafirewall.org. Единственное различие между внутренними и внешними зонами в том, что названия DNS зон соответствуют адресам доступным из вне, а внутренние зоны соответствуют внутренним адресам, например действительный IP адрес сервера или сетевое устройство, которое обеспечивает доступ к сетевым службам.
DNS инфраструктура в тестовой сети использует, то что я считаю наилучшим решением для DNS инфраструктуры, поддержку сценариев удаленного доступа. Эта DNS инфраструктура использует одно и то же название домена для внутренних сетевых ресурсов и для внешних сетевых ресурсов. Существует странное и необъяснимое заблуждение по поводу того, что использование одного и того же имени домена и для внутренних и для внешних ресурсов каким-то образом не является безопасным, однако, это в высшей степени ошибочное мнение, и вы должны игнорировать тех людей, которые заявляют, что это верно.
Наша тестовая сеть, используемая в этой статье использует одно и то же название домена msfirewall.org как для внутренних, так и для внешних ресурсов. Преимущество такого подхода заключается в том, что пользователям не нужно знать о своем местоположении, для того чтобы подключиться к ресурсам, которые доступны как для внешних, так и для внутренних пользователей. Пользователям не нужно перенастраивать клиентские приложения для поддержки перемещений между корпоративной сетью и внешним размещением.
Тестовая сеть имеет внешние и внутренние зоны, авторизованные для домена msfirewall.org. Внешние зоны поддерживаются сервером DNS, размещенном где-то извне, по отношению к корпоративной сети, а внутренняя зона поддерживается интегрированным сервером DNS в Active Directory в корпоративной сети.
На рисунке ниже показан пример того, что случится, если пользователь из внешней сети попытается подключиться к сайту OWA через периметр брандмауэра ISA.
Рисунок 2
Рисунок ниже описывает процесс, упомянутый в шаге 3. После того, как брандмауэр ISA подтвердит, что запрос, который был запущен внешним клиентом, соответствует параметрам в правиле Web Publishing Rule, затем он сопоставляет название в закладке To в правиле Web Publishing Rule. Файл HOSTS на брандмауэре ISA содержит запись, которая ставит в соответствие название front-end сервера Exchange в сертификате Web сайта действительному IP адресу front-end сервера Exchange Server в авторизованном для доступа DMZ сегменте. Затем, запрос передается этому IP адресу брандмауэром ISA.
Рисунок 3
На рисунке ниже показана последовательность соответствия названий для внешнего клиента, которые подключается к опубликованному сайту с помощью правила Server Publishing Rule вместо правила Web Publishing Rule. Внешний клиент выполняет запрос к основному серверу DNS за названием mail.msfirewall.org, а затем соединяется с IP адресом, который вернул DNS сервер, и который является IP адресом внешнего интерфейса брандмауэра ISA, используемый слушателем Server Publishing Rules listener.
Различие заключается в том, что соединение совершается не брандмауэром ISA, брандмауэр ISA совершает реверсивный NAT и передает соединение front-end серверу Exchange Server. Только после того, как соединение достигает front-end сервера Exchange, все содержимое расшифровывается. В этом случае, вам не надо беспокоиться о связи сертификатов со слушателями на брандмауэре ISA.
Рисунок 4
В этой статье мы обсудили насущные проблемы в инфраструктуре наименований сертификатов, необходимых для поддержки безопасного удаленного доступа с помощью брандмауэра ISA. Мы рассмотрели связь сертификатов с Web Listener брандмауэра ISA, front-end сервером Exchange Server и back-end сервером Exchange. Затем мы рассмотрели проблемы DNS инфраструктуры, связанные с безопасной публикацией. В следующей статье из этого цикла, мы рассмотрим подробности конфигурации брандмауэра ISA и правил Web Publishing Rules, Server Publishing Rules и Access Rules, необходимых для поддержки соединений с front-end сервером Exchange.
www.isaserver.org
Tags: dns, Exchange, imap, mac, nat, proxy, vpn