Если вы хотите ознакомиться с остальными частями этой статьи, пожалуйста, прочитайте:
На этой недели мы рассмотрим несколько из наиболее распространенных методов публикации DNS, а также топологические схемы для них. Сегодня мы обсудим такие ситуации, как:
В этом случае публикующий сервер устанавливается на сам брандмауэр 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 может отключиться без выключения всех систем брандмауэра.
На рисунке, приведенном ниже, показана топология данного метода публикации.
Рисунок 1
Для этого метода необходимо:
Это довольно простое решение для домашнего офиса или малого предприятия, но оно нежелательно для компаний, которые могут позволить себе отделить обязанности DNS сервера от ISA Firewall.
При использовании второго метода, публикующий сервер расположен в сегменте зоны DMZ с анонимным доступом. Многие администраторы, имеющие дело с брандмауэрами, традиционно считают DMZ однотипной сетью, но в действительности это не так. Зона DMZ – это место, где компьютеры с выходом в Интернет принимают входящие соединения из Интернета. Ее назначение в том, чтобы отделить эти устройства от внутренней сети и от защищенных служебных участков во внутренней сети. По этой причине внешние серверы Exchange Servers Exchange Client Access никогда не должны размещаться во внутренней сети или в защищенном сегменте служб сети.
Однако не все зоны DMZ одинаковы. Есть два главных типа DMZ, включаемые с помощью особых возможностей брандмауэра, предоставляемых ISA Firewall. Это:
Зона 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 серверов.
Рисунок 2
Для этого метода необходимо:
Это хорошее решение для предприятий любого размера, которые могут позволить выделить системы для роли публикующего сервера, при использовании лишь одного ISA Firewall.
Есть множество преимуществ в использовании конфигурации «back to back» брандмауэров ISA Firewall:
Если у нас конфигурация ISA Firewall с использованием «back to back», сегмент DMZ между внешним ISA Firewall и внутренним ISA Firewall представляет собой зону DMZ с анонимным доступом. Правила DNS Server Publishing Rules настраиваются на внешнем брандмауэре, позволяющем DNS соединения к публикующим серверам в этом сегменте.
На рисунке, приведенном ниже, показана топология данного метода публикации.
Рисунок 3
Для этого метода необходимо:
Заметьте, что вам не нужно создавать каких-либо правил на внутреннем ISA Firewall, чтобы предоставить открытый доступ для DNS серверов. По той причине, что внутренние пользователи никогда не будет нужно использовать DNS серверы, расположенные в DMZ с анонимным доступом. Им необходимо использовать внутренние DNS серверы с DNS зонами, настроенными чтобы соответствовать DNS доступу внутреннего пользователя.
Теперь вы можете спросить: «Что, если у меня есть публичные веб-серверы в том же сегменте зоны DMZ, где находятся и DNS серверы с открытым доступом?» Это хороший вопрос. Что вам нужно, так это настроить ваши внутренние DNS серверы так, чтобы зоны и записи ресурсов в этих зонах указывали на текущие IP адреса веб-серверов в зоне DMZ с анонимным доступом.
Причиной, почему мы не хотим, чтобы внутренние пользователи подключались к публикующим серверам, является то, что публикующие серверы содержат информацию, подходящую для внешних пользователей, которые получают доступ к ресурсам в зоне DMZ через внешний интерфейс внешнего ISA Firewall. Другими словами, не нужно, чтобы внутренние пользователи наталкивались внешний брандмауэр в попытке достичь ресурсов, расположенные в DMZ. Лучше, чтобы внутренние пользователи соединялись с веб-серверами через внутренний ISA Firewall, используя правило Access Rule внутреннего брандмауэра.
Основной момент здесь в том, что вам нужно создать разделенную инфраструктуру DNS, чтобы поддерживать данную конфигурацию, если в зоне DMZ с анонимным доступом есть какие-либо ресурсы, нужные пользователям. Запомните, что внутренние пользователи не должны иметь необходимость подключаться к вашим публикующим серверам!
В данном случае публикующие серверы расположены в используемой по умолчанию внутренней сети. Допущения в подобной сети таковы, что клиенты и сетевые серверы (контроллер домена Active Directory, серверы WINS, RADIUS, файловые серверы и т.п.) расположены в одной и той же сети. В производственных сетях, внутренняя сеть, используемая по умолчанию, разбивается на зоны безопасности, так что сетевые серверы и службы ядра расположены на выделенном и защищенном сегменте (сегментах) сети, с тем, чтобы корректно разделять зоны безопасности.
Я упоминаю этот метод только ради наглядного урока, насколько плохой может быть защищенность сети. Причиной небезопасности подобной конфигурации является то, что устройства, подключенные к Интернет, находятся в том же самой зоне безопасности, что и неподключенные. Это все равно что поставить внешний сервер Exchange или Exchange Client Access (CAS) в тот же самый сегмент, где расположены сетевые клиенты или, что еще хуже, в сегмент сетевых клиентов во внутренней сети.
Это очень распространенная ошибка среди новичков в сетевой безопасности, но она легко исправляется. Все, что вам нужно, это встроить еще один сетевой интерфейс (NIC) в брандмауэр ISA Firewall, создать зону DMZ с анонимным доступом и разместить публикующие серверы в ней.
Рисунок 4
Это мой излюбленный метод, но не потому, что я советую использовать его, а потому, что он дал мне несколько важных уроков относительно того, как работает инфраструктура DNS и разделенной DNS. Это наихудшая из возможных конфигураций, она никогда не должна использоваться, но тут есть чему поучиться, и я собираюсь это обсудить.
Много лет назад, когда я только начинал понимать, как работает Интернет, я в первый раз попытался сделать ресурсы в моей внутренней сети доступными из Интернет. В то время я ничего не знал о брандмауэрах и уж точно не понимал важность разделения на зоны безопасности. Все, чего я хотел – это разместить в моей внутренней сети веб-страницу и сделать ее доступной из Интернет.
Нашим внутренним доменов в то время был tacteam.net, и я хотел иметь возможность использовать это имя и в Интернет. Я обнаружил, что не могу сделать всего, чего желал, потому что я использовал контроллер домена, свой единственный DNS сервер, как для разрешения имен хостов в Интернет, так и для разрешения внутренних имен.
Например, если я хотел использовать mail.tacteam.net для своего почтового сервера, мне приходилось выбирать либо внешний адрес, используемый для обратного NAT для этой DNS записи, либо внутренний адрес сервера. Ничего хорошего не выйдет, если позволить внутренним клиентам использовать обратный NAT адрес для доступа к ресурсам внутренней сети! Из-за этого я начал изучать разделенную службу DNS и узнал о ее ценности для любой организации.
У этой конфигурации имеются следующие проблемы:
На рисунке, приведенном ниже, показана топология данного метода публикации
Рисунок 5
Этой статьей заканчивается серия из двух статей о методах публикации DNS. Мы исследовали несколько различных сценариев и рассмотрели преимущества и недостатки каждого из них. Общим для всех сценариев является то, что публикующие серверы должны иметь возможность принимать анонимные входящие соединения от всех Интернет хостов, если вы хотите, чтобы они могли получить доступ к ресурсам вашего домена. Поскольку публикующие серверы – это хосты, подключенные к Интернет и требующие анонимные входящие соединения, они должна быть расположены отдельно от внутренних клиентов и серверов. Способ этого достичь – расположить публикующие серверы в зоне DMZ с анонимным доступом.
www.isaserver.org
Tags: dns, Exchange, ftp, ldap, nat