Monday, December 11th, 2017

Методы публикации DNS (Часть вторая): Топология

Published on Февраль 17, 2009 by   ·   Комментариев нет

Если вы хотите ознакомиться с остальными частями этой статьи, пожалуйста, прочитайте:

На этой недели мы рассмотрим несколько из наиболее распространенных методов публикации DNS, а также топологические схемы для них. Сегодня мы обсудим такие ситуации, как:

  • Публикующий сервер на брандмауэре ISA Firewall
  • Публикующие серверы в сегменте зоны DMZ с анонимным доступом
  • Публикующие серверы в зоне DMZ с анонимным доступом и использованием «back to back» для двух брандмауэров
  • Публикующие серверы во внутренней сети
  • Публикующий сервер как контроллер домена

Метод 1: публикующий сервер на брандмауэре ISA Firewall

В этом случае публикующий сервер устанавливается на сам брандмауэр ISA Firewall. Внешний клиент делает DNS запрос на IP адрес, расположенный на внешнем интерфейсе ISA Firewall. DNS сервер, установленный на ISA Firewall, настроен для прослушивания лишь внутреннего интерфейса брандмауэра. Для интерфейса сервера также создается правило публикации DNS Server Publishing Rule.

Мы используем правило DNS Server Publishing Rule вместо правила Access Rule (которое мы могли бы использовать, если бы настроили DNS сервер на прослушивание внешнего интерфейса) по той причине, что при использовании Server Publishing Rule мы можем эффективно использовать DNS фильтр приложений для защиты нашего сервера.

Очевидно, что этот метод не является оптимальным, так как при установке на ISA Firewall внешних сервисов, позволяющих анонимные соединения, мы значительно увеличиваем «площадь атаки». Несмотря на то, что у DNS сервера Windows Server 2003 SP2 нет известных уязвимостей, это вполне обоснованная теория. По этой причине я бы рекомендовал подобную конфигурацию лишь для тех компаний, у которых нет возможности использовать отдельные выделенные системы как публичные серверы.

Еще один недостаток данного решения в том, что у вас есть лишь один DNS сервер, так что о сохранении работоспособности системы говорить не приходится – хотя это ограничение скорее мнимое, так как если ISA Firewall прекратит работу, то же самое произойдет с любым публикующим сервером, расположенным за брандмауэром. Однако есть возможность, что DNS сервис на ISA Firewall может отключиться без выключения всех систем брандмауэра.

На рисунке, приведенном ниже, показана топология данного метода публикации.

Dns сервер

Рисунок 1

Для этого метода необходимо:

  • Установить службу DNS сервер на ISA Firewall
  • Настроить DNS сервер на прослушивание только внутреннего интерфейса
  • Создать правило DNS Server Publishing Rule, публикующее внутренний IP адрес, который прослушивает DNS сервер
  • С помощью регистратора доменов создать записи, указывающие, что IP адрес, упомянутый в правиле DNS Server Publishing Rule, является адресом авторитетного DNS сервера для публикуемого домена (публикуемых доменов)

Это довольно простое решение для домашнего офиса или малого предприятия, но оно нежелательно для компаний, которые могут позволить себе отделить обязанности DNS сервера от ISA Firewall.

Метод 2: публикующие серверы в сегменте зоны DMZ с анонимным доступом.

При использовании второго метода, публикующий сервер расположен в сегменте зоны DMZ с анонимным доступом. Многие администраторы, имеющие дело с брандмауэрами, традиционно считают DMZ однотипной сетью, но в действительности это не так. Зона DMZ – это место, где компьютеры с выходом в Интернет принимают входящие соединения из Интернета. Ее назначение в том, чтобы отделить эти устройства от внутренней сети и от защищенных служебных участков во внутренней сети. По этой причине внешние серверы Exchange Servers Exchange Client Access никогда не должны размещаться во внутренней сети или в защищенном сегменте служб сети.

Однако не все зоны DMZ одинаковы. Есть два главных типа DMZ, включаемые с помощью особых возможностей брандмауэра, предоставляемых ISA Firewall. Это:

  • Зона DMZ с анонимным доступом
  • Зона DMZ с аутентификацией

Зона DMZ с анонимным доступом – это просто участок DMZ, где позволяются анонимные входящие соединения на хосты, расположенные на этом участке. В подобной зоне могут быть расположены DNS серверы, почтовые станции SMTP, FTP и веб-серверы общего доступа. Всех их объединяет то, что серверы, расположенные в зоне DMZ с анонимным доступом, не требуют аутентификации для доступа к информации.

Как вы можете видеть, зона такого типа является наиболее незащищенной из различных сетевых зон, поскольку хосты, находящиеся в DMZ с анонимным доступом принимают входящие соединения со всех подключенных к Интернет компьютеров по протоколам, допустимым для этих хостов.

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

Для того чтобы зона DMZ с аутентификацией была действительно более защищена, чем DMZ с анонимным доступом, необходимо, чтобы ISA Firewall осуществлял первичную аутентификацию соединений, прежде чем передавать их хостам, расположенным в зоне DMZ. Если ISA Firewall не будет выполнять данную операцию, тогда DMZ с аутентификацией по защищенности не будет отличаться от DMZ с анонимным доступом, так как все соединения с хостами, подключенными к Интернет, будут допустимы для серверов в данном сегменте, несмотря на то, что сами серверы могут требовать аутентификации.

В этом случае DNS сервер расположен в зоне DMZ с анонимным доступом, подключенной к третьему сетевому интерфейсу (NIC) брандмауэра ISA Firewall. Соединения будут анонимными, поскольку нет способа авторизировать DNS подключения с анонимных хостов, расположенных в Интернете, которым нужно разрешить имя вашего домена, расположенного в открытом доступе.

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

Isa публикация dns

Рисунок 2

Для этого метода необходимо:

  • Создать два правила Server Publishing Rule, чтобы опубликовать каждую службу в зоне DMZ с анонимным доступом.
  • Минимум три сетевых интерфейса (NIC) для брандмауэра ISA Firewall: внешний, внутренний и DMZ
  • Создать правило Network Rule, соединяющее зону DMZ с Интернет. Это будет правило NAT (хотя, если вам нужно, вы можете взять и правило Route Network Rule, если вы хотите использовать публичные адреса в вашей зоне DMZ, однако, если вы примените Route Network Rule, вам все равно будет необходимо использовать Server Publishing Rule вместо Access Rule для большей эффективности DNS фильтра приложений)
  • С помощью регистратора доменов создать записи, указывающие, что IP адрес, упомянутый в правиле DNS Server Publishing Rule, является адресом авторитетного DNS сервера для публикуемого домена (публикуемых доменов)

Это хорошее решение для предприятий любого размера, которые могут позволить выделить системы для роли публикующего сервера, при использовании лишь одного ISA Firewall.

Метод 3: публикующие серверы в зоне DMZ с анонимным доступом и использованием «back to back» для двух брандмауэров

Есть множество преимуществ в использовании конфигурации «back to back» брандмауэров ISA Firewall:

  • Меньше риск нарушения работы брандмауэра, поскольку вероятность ошибки в конфигурации уменьшена до минимума тем, что не нужно изучать, как использовать разные брандмауэры. Помните, события в системе безопасности, относящиеся к брандмауэру, очень редко появляются из-за проблем самого брандмауэра. Проблема, как правило, в ошибке в конфигурации брандмауэра, поэтому значительно безопасней использовать два ISA Firewall, чем смешивать брандмауэры для защиты от окружения.
  • Внешний ISA Firewall не должен быть членом домена, поскольку аутентификация будет происходить на внутреннем ISA Firewall
  • Внутренний ISA Firewall может быть членом домена, для того чтобы осуществлять быструю аутентификацию без применения менее функциональных и менее производительных методов аутентификации как RADIUS или LDAP
  • Отдельная зона DMZ с анонимным доступом и режимом работы DMZ с авторизацией. Внешний ISA Firewall контролирует анонимный доступ в DMZ, а внутренний несет ответственность за доступ в зону с аутентификацией (для этого потребуется третий сетевой интерфейс (NIC) для внутреннего ISA Firewall, что не показано на рисунке, приведенном ниже).

Если у нас конфигурация ISA Firewall с использованием «back to back», сегмент DMZ между внешним ISA Firewall и внутренним ISA Firewall представляет собой зону DMZ с анонимным доступом. Правила DNS Server Publishing Rules настраиваются на внешнем брандмауэре, позволяющем DNS соединения к публикующим серверам в этом сегменте.

На рисунке, приведенном ниже, показана топология данного метода публикации.

Dns сервер

Рисунок 3

Для этого метода необходимо:

  • Создать правила DNS Server Publishing Rules на внешнем ISA Firewall, которые публикуют DNS серверы в зоне DMZ с анонимным доступом
  • Создать правило Network Rule, соединяющее DMZ с Интернет. Это будет правило NAT (хотя, если вам нужно, вы можете взять и правило Route Network Rule, если вы хотите использовать публичные адреса в вашей зоне DMZ, однако, если вы примените Route Network Rule, вам все равно будет необходимо использовать Server Publishing Rule вместо Access Rule для большей эффективности DNS фильтра приложений)
  • С помощью регистратора доменов создать записи, указывающие, что IP адрес, упомянутый в правиле DNS Server Publishing Rule, является адресом авторитетного DNS сервера для публикуемого домена (публикуемых доменов)

Заметьте, что вам не нужно создавать каких-либо правил на внутреннем ISA Firewall, чтобы предоставить открытый доступ для DNS серверов. По той причине, что внутренние пользователи никогда не будет нужно использовать DNS серверы, расположенные в DMZ с анонимным доступом. Им необходимо использовать внутренние DNS серверы с DNS зонами, настроенными чтобы соответствовать DNS доступу внутреннего пользователя.

Теперь вы можете спросить: «Что, если у меня есть публичные веб-серверы в том же сегменте зоны DMZ, где находятся и DNS серверы с открытым доступом?» Это хороший вопрос. Что вам нужно, так это настроить ваши внутренние DNS серверы так, чтобы зоны и записи ресурсов в этих зонах указывали на текущие IP адреса веб-серверов в зоне DMZ с анонимным доступом.

Причиной, почему мы не хотим, чтобы внутренние пользователи подключались к публикующим серверам, является то, что публикующие серверы содержат информацию, подходящую для внешних пользователей, которые получают доступ к ресурсам в зоне DMZ через внешний интерфейс внешнего ISA Firewall. Другими словами, не нужно, чтобы внутренние пользователи наталкивались внешний брандмауэр в попытке достичь ресурсов, расположенные в DMZ. Лучше, чтобы внутренние пользователи соединялись с веб-серверами через внутренний ISA Firewall, используя правило Access Rule внутреннего брандмауэра.

Основной момент здесь в том, что вам нужно создать разделенную инфраструктуру DNS, чтобы поддерживать данную конфигурацию, если в зоне DMZ с анонимным доступом есть какие-либо ресурсы, нужные пользователям. Запомните, что внутренние пользователи не должны иметь необходимость подключаться к вашим публикующим серверам!

Метод 4: публикующий сервер во внутренней сети

В данном случае публикующие серверы расположены в используемой по умолчанию внутренней сети. Допущения в подобной сети таковы, что клиенты и сетевые серверы (контроллер домена Active Directory, серверы WINS, RADIUS, файловые серверы и т.п.) расположены в одной и той же сети. В производственных сетях, внутренняя сеть, используемая по умолчанию, разбивается на зоны безопасности, так что сетевые серверы и службы ядра расположены на выделенном и защищенном сегменте (сегментах) сети, с тем, чтобы корректно разделять зоны безопасности.

Я упоминаю этот метод только ради наглядного урока, насколько плохой может быть защищенность сети. Причиной небезопасности подобной конфигурации является то, что устройства, подключенные к Интернет, находятся в том же самой зоне безопасности, что и неподключенные. Это все равно что поставить внешний сервер Exchange или Exchange Client Access (CAS) в тот же самый сегмент, где расположены сетевые клиенты или, что еще хуже, в сегмент сетевых клиентов во внутренней сети.

Это очень распространенная ошибка среди новичков в сетевой безопасности, но она легко исправляется. Все, что вам нужно, это встроить еще один сетевой интерфейс (NIC) в брандмауэр ISA Firewall, создать зону DMZ с анонимным доступом и разместить публикующие серверы в ней.

Dns firewall

Рисунок 4

Метод 5: публикующий сервер на контроллере домена

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

Много лет назад, когда я только начинал понимать, как работает Интернет, я в первый раз попытался сделать ресурсы в моей внутренней сети доступными из Интернет. В то время я ничего не знал о брандмауэрах и уж точно не понимал важность разделения на зоны безопасности. Все, чего я хотел – это разместить в моей внутренней сети веб-страницу и сделать ее доступной из Интернет.

Нашим внутренним доменов в то время был tacteam.net, и я хотел иметь возможность использовать это имя и в Интернет. Я обнаружил, что не могу сделать всего, чего желал, потому что я использовал контроллер домена, свой единственный DNS сервер, как для разрешения имен хостов в Интернет, так и для разрешения внутренних имен.

Например, если я хотел использовать mail.tacteam.net для своего почтового сервера, мне приходилось выбирать либо внешний адрес, используемый для обратного NAT для этой DNS записи, либо внутренний адрес сервера. Ничего хорошего не выйдет, если позволить внутренним клиентам использовать обратный NAT адрес для доступа к ресурсам внутренней сети! Из-за этого я начал изучать разделенную службу DNS и узнал о ее ценности для любой организации.

У этой конфигурации имеются следующие проблемы:

  • Она не поддерживает разделенную службу DNS
  • Она оставляет Active Directory вместе с внутренними именами без защиты перед Интернет
  • Она не защищает контроллер домена от анонимных входящих соединений из Интернет
  • Она не может размещать хосты, подключенные к Интернет (такие, как внешние серверы Exchange, Exchange Client Access и DNS) отдельно от сетевых клиентов и серверов

На рисунке, приведенном ниже, показана топология данного метода публикации

Dns сервер

Рисунок 5

Заключение

Этой статьей заканчивается серия из двух статей о методах публикации DNS. Мы исследовали несколько различных сценариев и рассмотрели преимущества и недостатки каждого из них. Общим для всех сценариев является то, что публикующие серверы должны иметь возможность принимать анонимные входящие соединения от всех Интернет хостов, если вы хотите, чтобы они могли получить доступ к ресурсам вашего домена. Поскольку публикующие серверы – это хосты, подключенные к Интернет и требующие анонимные входящие соединения, они должна быть расположены отдельно от внутренних клиентов и серверов. Способ этого достичь – расположить публикующие серверы в зоне DMZ с анонимным доступом.

www.isaserver.org


Смотрите также:

Tags: , , , ,

Readers Comments (Комментариев нет)




Да человек я, человек! =)

Exchange 2007

Проведение мониторинга Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 3)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Проведение мониторинга Exchange 2007 с помощью диспетчера System ... [+]

Практическое рассмотрение перехода с Exchange 2003 на Exchange 2007 (часть 1)

Введение В этой статье из нескольких частей я хочу показать вам процесс, который недавно использовал для перехода с существующей среды Exchange 2003 ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 2)

Если вы пропустили первую часть этой серии, пожалуйста, прочтите ее по ссылке Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (Часть ... [+]

Мониторинг Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 2)

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Мониторинг Exchange 2007 с помощью диспетчера System Center Operations ... [+]

Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 5)

Если вы пропустили предыдущие части этой серии статей, перейдите по ссылкам: Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 1) ... [+]

Установка и настройка Exchange 2007 из командной строки (Часть 3)

If you missed the previous parts in this article series please read: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 1)

Инструмент ExRCA Текущий выпуск инструмента предоставляется только в целях тестирования и оснащен 5 опциями: Тест подключения Outlook 2007 Autodiscover Тест подключения Outlook 2003 RPC ... [+]

Развертывание сервера Exchange 2007 Edge Transport (часть 5)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Развертывание сервера Exchange 2007 Edge Transport (часть 1) Развертывание ... [+]

Установка и настройка Exchange 2007 из командной строки (часть 2)

Если вы пропустили первую статью данного цикла, пожалуйста, перейдите по ссылке: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование интегрированных сценариев Using Exchange Server 2007 – часть 2: генерирование отчетов агента Transport AntiSpam Agent

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Использование интегрированных сценариев Using Exchange Server 2007 – часть ... [+]