Проблемы с DNS нередко упоминаются на форумах и в почтовой рассылке ISAserver.org. Недавно там появилась целая куча вопросов относительно публикации DNS. Поток вопросов на данную тему заинтересовал меня, поскольку публикация DNS – это довольно простой процесс, и сложно представить, что он может вызвать такие затруднения. Как оказалось, основной причиной сложностей является не сама публикация DNS, а непонимание того, что люди пытаются выполнить, что и приводит к проблемам.
В этой статье говорится о публикации DNS. В следующих я переключусь на проблемы с исходящими запросами DNS. Это две совершенно разные темы, и поэтому подробное обсуждение разницы между входящими и исходящими DNS поможет объяснить некоторые сложности, прежде чем мы перейдем к методам публикации.
DNS Advertisers(Публикующие сервера).
При публикации DNS сервера, он располагается в защищенной сети ISA Firewall. Цель публикации DNS сервера в том, чтобы позволить внешним пользователям получить доступ к серверу при использовании DNS протокола для разрешения имен серверов Интернет. (Я не говорю про те варианты, где ISA Firewall - это внутренний брандмауэр, используемый для защиты того сегмента сети, который содержит DNS сервера). Когда вы публикуете DNS сервер, вы предоставляете информацию, которую Интернет-клиенты могут использовать для того, чтобы разрешать имена ваших доменов.
Например, предположим, что ваши Веб-серверы расположены в зоне DMZ за брандмауэром ISA Firewall. Когда внешние пользователи хотят соединиться с вашей Веб-страницей, им нужно сперва перевести имя страницы в IP-адрес с помощью того внешнего интерфейса ISA Firewall, что используется сервисом веб-прослушивания по правилу публикации Web Publishing Rule для данной страницы. Так, если они хотят зайти на ваш Интернет-сайт www.company.com, им необходимо послать DNS запрос на ваш опубликованный DNS сервер, чтобы перевести имя www.company.com в IP адрес с помощью внешнего интерфейса ISA Firewall, который используется веб-прослушивателем.
Это лишь один пример, как вы можете использовать DNS для внешних пользователей. Еще один случай – если вы хотите использовать свой собственный DNS, но ваш Интернет и почтовые серверы расположены где-то на другом хосте. В таком случае, вы настраиваете свой опубликованный DNS сервер на возврат IP-адресов хостера ваших серверов. То, что у вас размещаются ваши собственные сервисы DNS, не означает, что вы должны быть хостом для всех своих сервисов. В некоторых случаях вы будете размещать у себя ваши собственные службы (такие как Exchange), но передадите хостинг веб-сайта третьему лицу. В таком случае, ваш DNS сервер будет возвращать IP-адреса вашего хостера веб-сайта и IP-адреса внешнего интерфейса ISA Firewall, используемого для E-mail публикации.
Опубликованные DNS сервера не должны содержать частную информацию. Когда вы публикуете DNS сервер, вы делаете это для предоставления публичного доступа к ресурсам, находящимся под вашим контролем. Цель не в том, чтобы предоставлять информацию о ваших личных ресурсах. Никогда не публикуйте DNS сервер, содержащий ваши личные сетевые записи. DNS сервера такого типа также называются публикующими (DNS Advertisers), так как они предоставляют информацию о ваших ресурсах, находящихся в открытом доступе.
DNS Resolvers(Сервера разрешения имен)
Если публикация DNS используется для предоставления открытого доступа к доменным именам, находящимся под вашим контролем, то исходящий DNS доступ предназначен для разрешения имен для внутренних клиентов. Когда вы позволяете исходящий доступ к DNS, вы даете внутренним клиентам и серверам возможность разрешать имена серверов в Интернет. Например, если внутренний клиент хочет посетить сайт http://www.microsoft.com/, DNS сервер должен быть настроен так, чтобы он мог разрешить это имя для клиента. Такие DNS сервера могут быть предназначены для разрешения лишь Интернет-имен, или они могут отвечать за разрешение и имен и внешних и внутренних хостов. В обоих случаях, эти системы называются серверами разрешения имен (DNS resolvers), так как их главной задачей считается разрешение тех имен, что являются внешними для вашей организации.
Ключевой идеей для понимания здесь является то, что внутренние пользователи никогда не должны использовать публикующие сервера для разрешения имен, а внешние пользователи никогда не должны использовать ваши внутренние сервера разрешения имен (исключением будут клиенты VPN, в том случае, если вы хотите, чтобы они использовали ваши внутренние DNS сервера для разрешения имен хостов во внутренней сети).
Причина, почему мы ни в коем случае не хотим, чтобы внутренние пользователи использовали наши публикующие сервера для разрешения имен, в том, что они могут публиковать имена лишь ваших ресурсов, находящихся в открытом доступе. Они не могут разрешать имена любого другого домена. Так что, даже если вы хотели использовать публикующие сервера для разрешения лишь ваших открытых ресурсов, вам бы пришлось позволить внутренним клиентам наталкиваться на брандмауэр ISA Firewall при попытке достичь внутренних ресурсов или тех, что находятся в зоне DMZ. Решение этой проблемы в использовании разделенной инфраструктуры DNS с тем, чтобы внутренние клиенты не натыкались на внешний интерфейс ISA Firewall, пытаясь добраться до хоста, находящегося в том же или другом сегменте сети под защитой ISA Firewall.
Причина, по которой мы ни в коем случае не хотим, чтобы внешние пользователи имели доступ к нашим внутренним DNS серверам, в том, что внешние пользователи анонимны, и мы не имеем представления о том, каковы их цели. Злонамеренные пользователи могут добыть полезную информацию о нашей внутренней сети, если они смогут получить доступ к нашим внутренним DNS серверам, и по этой причине никогда нельзя предоставлять им доступ к ним (исключая клиентов VPN, о чем я уже упоминал ранее).
Мы поговорим подробней о серверах разрешения имен в следующей статье. Эта статья о публикующих серверах.
Защита системных настроек сервера DNS для публикующего сервера
На этом этапе вы уже знаете, что при публикации DNS сервера, вы получаете публикующий сервер (DNS advertiser). Пользователи из Интернета, скорее всего, получат анонимный доступ к подобным серверам, поскольку аутентификация не предусмотрена в мерах безопасности для разрешения имен DNS. Поэтому ваши DNS сервера вполне могут быть атакованы анонимным Интернет-пользователем, и вследствие этого вам стоит предпринять некоторые действия для того, чтобы заблокировать системные настройки вашего DNS сервера. Стоит отметить, что атаки будут идти только с 53-их портов UDP и TCP, потому что ваше правило публикации DNS Server Publishing Rule не позволит никаких других подключений к DNS серверу.
На рисунке, приведенном ниже, показано диалоговое окно Properties одного из моих публикующих серверов. Советуют иметь по меньшей мере два авторитетных DNS сервера для двух разных подсетей для большей отказоустойчивости. Однако, при публикации DNS серверов это не имеет особого смысла, так как если ваше соединение с Интернетом оборвется, не будет иметь значения, есть ли где-то еще один DNS сервер, способный разрешать имена, поскольку даже если внешний пользователь сможет разрешить имя, он в любом случае не сможет получить доступа к ресурсам, ведь соединения с Интернетом нет.
Тем не менее, полезно иметь как минимум два DNS сервера на тот случай, если один из них выйдет из строя. Обычно я устанавливаю два выделенных сервера разрешения имен в зону DMZ с анонимным доступом. Это не единственный способ сделать это, как вы увидите позже, когда мы будем говорить о различных методах публикации DNS.
Находясь в диалоговом окне Properties для сервера DNS, на вкладке Interfaces, убедитесь, что вы отметили условие Only the following IP addresses и затем выберите определенный IP адрес, который DNS server будет прослушивать в поисках входящих запросов DNS. Это мелочь, но я обнаружил, что она может предотвратить некоторые потенциальные сложности в устранении неполадок в тех случаях, когда к DNS серверу прикреплено несколько IP адресов (как в случае, когда DNS сервер также поддерживает множество веб-страниц, прослушивающих разные IP адреса).
Рисунок 1
На вкладке Forwarders, вам нужно убрать галочку рядом с опцией Enable forwarders. Причиной для этого служит то, что мы не хотим сделать наши публикующие серверы серверами разрешения имен. Если позволить серверу стать сервером разрешения имен, он откроется для потенциальных атак, которые были бы невозможны, будь он только публикующим сервером. Таким образом, это предотвращает использование DNS сервера для разрешения имен – почему вы должны предоставлять эти сервисы каждому встречному и позволять ему использовать вашу сеть? Он вполне может воспользоваться собственными серверами или подобным сервером своего провайдера.
Рисунок 2
На закладке Advanced нам нужно отметить опции Disable recursion и Secure cache against pollution. Опция Disable recursion запрещает DNS серверу разрешать те имена, для которых он не является авторитетным. Иначе говоря, если сервер не может разрешить имя, используя записи ресурса (Resource Records), настроенные на сервере, то DNS запрос не будет выполнен. Опция Secure cache against pollution не позволяет атакующим засорить кэш DNS сервера, хоть это и так технически невозможно, когда рекурсия отключена. Однако я все равно использую эту опцию, с ней мне как-то спокойнее (теперь я заговорил как настоящий админ-железячник!)
Рисунок 3
На закладке Root Hints показан список корневых серверов DNS в Интернете. Они используются, когда DNS серверу нужно выполнить рекурсию. Раз уж мы не хотим, чтобы наши публикующие серверы выполняли рекурсию, почему бы нам не убрать все корневые серверы из списка, и тем самым не избавиться от искушения ее включить? Это неплохая идея, и все, что вам надо сделать, это всего лишь выделить все корневые серверы в списке и нажать кнопку Remove. Когда это будет сделано, ваша закладка Root Hints должна будет выглядеть как моя на рисунке, приведенном ниже.
Рисунок 4
Теперь нажмите кнопку Apply, чтобы убедиться в том, что изменения приняты, и переключайтесь на вкладку Monitoring. Отметьте опцию A simple query against this DNS server и затем нажмите на кнопку Test Now. Для этого теста должно появиться значение PASS. Это означает, что ваш DNS сервер может разрешать имена, для которых он является авторитетным, что мы и хотели добиться. Отключите опцию A simple query against this DNS server и поставьте галочку рядом с A recursive query to other DNS servers. Нажмите кнопку Test Now. Для этого теста должно быть значение FAIL. Это то, что там нужно, раз мы не хотим, чтобы наш публикующий сервер выполнял рекурсию и разрешал те имена, для которых он не является авторитетным.
Рисунок 5
На данном этапе наши системные настройки DNS сервера защищены так, как только мы можем это сделать. Заметьте, для этого примера я использовал серверWindows DNS, который работает превосходно и стабилен настолько, насколько это возможно (Он был запущен у меня около года и я перезагружал его лишь один раз, когда я устанавливал обновление, связанное со службами DNS). Однако вам необязательно использовать сервер Windows DNS. Любой сервер подходит, и если вы хотите сэкономить, вы легко можете использовать общедоступный DNS сервер. Просто убедитесь в том, что вы настроили его так, что он не будет выполнять рекурсии любого типа и будет отвечать на запросы лишь для тех доменов и ресурсов, для которых он является авторитетным.
Прежде чем закончить сегодняшнее обсуждение, я хочу осветить одну проблему, которая никогда передо мной не стояла, но, на мой взгляд, это то, о чем необходимо рассказать, чтобы никто не был в замешательстве. Это проблема с передачами зон. Я встречал нескольких людей, которые считали, что когда они опубликовали свой публикующий сервер, им нужно включить передачу зон с DNS сервера внутренней сети к публикующему серверу, который чаще всего расположен в зоне DMZ. Меня никогда не касалась эта проблема потому что, что записи на вашем внутреннем DNS сервере никогда не должны быть те же, что и на публикующем.
Если вы позволите передачу зон с внутреннего сервера на публикующий, вы передадите частные записи о вашей внутренней сети на открытый DNS сервер, а это как раз то, чего делать не стоит! В общем, вам не нужно включать передачу зон с внутреннего DNS сервера на публикующий сервер.
На этой недели мы рассмотрим несколько из наиболее распространенных методов публикации 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 может отключиться без выключения всех систем брандмауэра.
На рисунке, приведенном ниже, показана топология данного метода публикации.
Рисунок 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 серверов.
Рисунок 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 соединения к публикующим серверам в этом сегменте.
На рисунке, приведенном ниже, показана топология данного метода публикации.
Рисунок 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 с анонимным доступом и разместить публикующие серверы в ней.
Рисунок 4
Метод 5: публикующий сервер на контроллере домена
Это мой излюбленный метод, но не потому, что я советую использовать его, а потому, что он дал мне несколько важных уроков относительно того, как работает инфраструктура DNS и разделенной DNS. Это наихудшая из возможных конфигураций, она никогда не должна использоваться, но тут есть чему поучиться, и я собираюсь это обсудить.
Много лет назад, когда я только начинал понимать, как работает Интернет, я в первый раз попытался сделать ресурсы в моей внутренней сети доступными из Интернет. В то время я ничего не знал о брандмауэрах и уж точно не понимал важность разделения на зоны безопасности. Все, чего я хотел – это разместить в моей внутренней сети веб-страницу и сделать ее доступной из Интернет.
Нашим внутренним доменов в то время был tacteam.net, и я хотел иметь возможность использовать это имя и в Интернет. Я обнаружил, что не могу сделать всего, чего желал, потому что я использовал контроллер домена, свой единственный DNS сервер, как для разрешения имен хостов в Интернет, так и для разрешения внутренних имен.
Например, если я хотел использовать mail.tacteam.net для своего почтового сервера, мне приходилось выбирать либо внешний адрес, используемый для обратного NAT для этой DNS записи, либо внутренний адрес сервера. Ничего хорошего не выйдет, если позволить внутренним клиентам использовать обратный NAT адрес для доступа к ресурсам внутренней сети! Из-за этого я начал изучать разделенную службу DNS и узнал о ее ценности для любой организации.
У этой конфигурации имеются следующие проблемы:
- Она не поддерживает разделенную службу DNS
- Она оставляет Active Directory вместе с внутренними именами без защиты перед Интернет
- Она не защищает контроллер домена от анонимных входящих соединений из Интернет
- Она не может размещать хосты, подключенные к Интернет (такие, как внешние серверы Exchange, Exchange Client Access и DNS) отдельно от сетевых клиентов и серверов
На рисунке, приведенном ниже, показана топология данного метода публикации
Рисунок 5
Заключение
Мы исследовали несколько различных сценариев и рассмотрели преимущества и недостатки каждого из них. Общим для всех сценариев является то, что публикующие серверы должны иметь возможность принимать анонимные входящие соединения от всех Интернет хостов, если вы хотите, чтобы они могли получить доступ к ресурсам вашего домена. Поскольку публикующие серверы – это хосты, подключенные к Интернет и требующие анонимные входящие соединения, они должна быть расположены отдельно от внутренних клиентов и серверов. Способ этого достичь – расположить публикующие серверы в зоне DMZ с анонимным доступом.