Обеспечение безопасности DNS для Windows (Часть 2)

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

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

В последней статье я рассказал о некоторых основных аспектах безопасности DNS, включая также некоторые основы самого DNS. Некоторые их концепций безопасности требуют интеграции DNS с Active Directory, а также обеспечения более безопасной среды DNS со связью с DHCP. Это очень простая и мощная конфигурация для вашей среды DNS. Однако, не стоит на этом останавливаться! Вы лишь коснулись поверхности того, что относиться к обеспечению безопасности для вашей среды DNS. В этой статье, посвященной обеспечению безопасности DNS, мы пойдем глубже и узнаем о том, как обеспечить безопасность базы данных DNS database, особенно при взаимодействии с другими серверами DNS. DNS сервера должны взаимодействовать с другими серверами DNS, чтобы обновлять свою базу данных. Такое взаимодействие может быть идеальной ситуацией для злоумышленника, чтобы воспользоваться выявленной уязвимостью. Если вы предпримите правильные меры для обеспечения безопасной настройки DNS, то риск возникновения такой ситуации существенно снизится.

Передача зон (Zone transfers)

Когда дело касается зон DNS, то вы должны понимать, что существуют различные типы зон, которые вы должны выделить в своей среде DNS. Хотя мы сфокусируемся лишь на нескольких из возможных зон, существует список зон, которые вы можете выделить в своем DNS:

  • Зона, интегрированная в Active Directory
  • Основная зона (Primary Zone)
  • Дополнительная зона (Secondary Zone)
  • Зона заглушек (Stub Zone)

В последней статье мы обсуждали зону, интегрированную в Active Directory. При этом зона, интегрированная в Active Directory, работала как основная зона. Причина этого заключалась в том, в рамках статьи основная зона (primary zone, а также зона, интегрированная в Active Directory) – это зона, которая производит записи в базе данных DNS. Дополнительные зоны не производят записи в базу данных DNS database. Дополнительные зоны лишь осуществляют передачу обновлений из основных зон primary DNS zone. Передача обновлений из основной зоны в дополнительную называется передачей зоны (zone transfer).

Интерфейс передачи зон достаточно понятен из ваших настроек, как вы можете увидеть на рисунке 1. Вы можете либо разрешить “любому” серверу DNS получать содержимое основной зоны (primary zone), либо вы может сузить это множество до нескольких серверов DNS на ваше усмотрение. Конечно, в целях безопасности вы должны сузить рамки DNS сервером, которым разрешено получать IP адреса и доменное имя для всех компьютеров в вашей организации!

213

Рисунок 1: Интрефейс для зон передачи для Windows DNS

Обеспечение безопасности передачи зон

Вы также можете обеспечивать безопасность зон передачи DNS zone transfers на другом уровне. Обеспечение безопасности DNS – это не радикальная концепция, большинство компаний на сегодняшний день делают дополнительные настройки для обеспечения безопасности зон передачи DNS zone transfers. Есть несколько настроек для обеспечения безопасности DNS и зон передачи. Здесь все зависит от того, как настроена ваша среда DNS.

Во-первых, необходимо использовать IPSec или VPN туннель между серверами DNS, чтобы обеспечить зашифрованное взаимодействие с базой данных DNS, во время ее передачи по сети. IPSec очень распространен для соединений между серверами DNS, которые располагаются в одной сети. Если ваши сервера DNS должны проходить через незащищенную сеть (insecure network), то используется VPN. Если вы используете VPN для обеспечения безопасности данных, проходящих по незащищенной сети, то обычно используется L2TP. L2TP использует более безопасный алгоритм шифрования для защиты данных, передаваемых по сети.

Вторая настройка для защиты данных при их передачи от одного сервера DNS на другой сервер DNS – это использовать интеграцию с Active Directory. Это требует, чтобы сервера DNS работали на домене Active Directory. Это также требует, чтобы сервера DNS были запущены на контроллере домена (domain controller). Однако при этом достигаются значительные преимущества. Т.к. данные хранятся и копируются с использованием средств копирования Active Directory, то данные шифруются при передаче от одного сервера DNS к другому DNS. Другие преимущества интеграции DNS с Active Directory заключается в том, что все соединения изначально аутентифицированы. Это помогает защитить зоны передачи, обязуя сервер DNS пройти аутентификацию в базе данных Active Directory перед копированием информации.

Переадресация (все четыре типа)

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

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

Безопасность dns Windows 2003

Рисунок 2: Переадресация для сервера Windows DNS server

Еще одна настройка, которая есть у нас в распоряжении, это сделать переадресацию более направленной. Это сможет гарантировать, что все запросы попадут (будут переадресованы) на нужный сервер DNS, что сведет риск взлома информации к минимуму. Эта настройка называется условной переадресацией (conditional forwarding), и изображена в верхней части на рисунке 2. Ее можно использовать в среде, где у вас используются несколько внутренних пространств имен DNS namespaces, и вы не хотите полагаться на Интернет или некоторые другие инфраструктуры DNS для преобразования имен. В этом случае каждый сервер DNS передает запросы на другие пространства имен для клиентов.

Резюме

DNS может быть сложным, но после более подробного рассмотрения он уже кажется не таким сложным, и его можно правильно обезопасить. В этой статье вы увидели, что DNS может защитить базу данных, настроенную для правильных серверов DNS, которые должны передавать зоны передачи. В такой ситуации ваши основные зоны, или зоны, интегрированные в Active Directory, будут иметь специальные дополнительные сервера DNS, с которыми они будут взаимодействовать. Без такой конфигурации, хакерские сервера DNS могут получить очень важную информацию относительно вашей сети. Еще одна возможность для обеспечения безопасности DNS. Безопасность DNS серверов можно обеспечить за счет интеграции с Active Directory, или за счет более современных технологий, как IPSec или VPN туннель. Наконец, контроль над переадресацией DNS может гарантировать более точное преобразование имен, а также поможет лучше защитить ваши внутренние DNS сервера от взлома.

Источник www.windowsecurity.com


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

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 – часть ... [+]