Когда стратеги военно-морского флота императорской Японии в 1941 г. планировали атаку на Пирл-Харбор, они рассчитывали нанести удар по трем важнейшим американским целям. Пожалуй, ни для кого не секрет, что первой из них были боевые суда ВМС США, уничтоженные в ходе налета. Хорошо известна и вторая цель — американские авианосцы, которые в декабре были далеко от Гавайев и потому не пострадали. Но мало кто знает, что была и третья цель: свыше 4 млн баррелей жидкого топлива, завезенного на Гавайи. Японцы считали эту цель самой важной, но не сумели обнаружить хранилища. Атака на Пирл-Харбор нанесла Соединенным Штатам огромный ущерб, но агрессору так и не удалось поразить две из трех намеченных мишеней.

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

DNS: еще одна угроза?

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

DNS нуждается в защите, поскольку функции этой службы жизненно важны, а хранимые в ней данные представляют большую ценность. Если говорить о функциональности, то DNS привлекает хакеров хотя бы потому, что захват данной службы позволяет организовывать атаки Denial of Service — отказ в обслуживании (DoS). Любой администратор, которому приходилось сталкиваться с полным отказом службы DNS, понимает, что последствия могут быть самые печальные. А данные, хранящиеся в DNS, представляют огромную ценность, особенно для взломщиков сетей. Файлы зон DNS часто содержат имена и адреса сетевых маршрутизаторов, серверов и выполняющих функции главной машины мэйнфреймов; имена практически всех систем и даже альтернативные (например, Canonical Name — CNAME) записи ресурсов, используемые специально для приложений. Конечно, не зная имен систем или IP-адресов, хакеры все равно будут предпринимать попытки атаковать систему, но в этом случае действия злоумышленников все-таки можно вовремя обнаружить.

Похоже, что разработчики Microsoft начали осознавать важность защиты службы DNS — во всяком случае, после того как была выпущена система Windows 2000. Сейчас достаточно внести всего лишь шесть изменений в настройки сетевых средств защиты, и безопасность сервера Windows DNS будет обеспечена.

Шаг 1. Создайте отдельные зоны DNS для работы внутри корпоративной сети и в Internet

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

Но если строится новая сеть, нужно иметь в виду, что оптимальный подход состоит в том, чтобы никогда без особой нужды не разглашать служебную информацию, сколь бы незначительной она ни казалась. Многие организации как в Internet, так и в intranet используют одно и то же имя (скажем, mightymouse.com). Но в этом случае любой человек, на глаза которому попался адрес электронной почты сотрудника, уже знает часть имен всех внутренних серверов сети. Если же в Internet использовать имя mightymouse.com, а в intranet — имя mm.com, можно считать, что информационная система окружена еще одним защитным барьером. Назначить одно имя зоны для внешних связей (через Internet), а второе — для внутреннего использования, особенно в зоне, защищенной брандмауэром, совсем нетрудно, а затрат при этом — никаких.

Шаг 2. Модернизируйте службу DNS до уровня Windows 2000

Службой DNS оснащены и Windows Server 2003, и Windows 2000, и Windows NT Server. Но не все версии DNS обеспечивают одинаковый уровень защиты.

До выхода в свет Windows 2000 можно было объединять в сети системы Windows, как включающие, так и не включающие службу DNS (хотя для больших маршрутизируемых сетей наличие централизованной системы разрешения имен, такой, как DNS или WINS, было фактически обязательным). В операционную систему Windows NT 4.0 разработчики Microsoft включили простую версию DNS на базе BIND 4.9.8. Эта версия обеспечивает функциональное и стабильное разрешение имен, но не позволяет минимизировать риски, связанные с обменом данными средствами DNS.

Для развертывания входящей в комплект поставки Windows 2000 службы Active Directory (AD) необходима поддержка серверов DNS. Такие серверы могут функционировать и не под Windows 2000, но они должны быть совместимы с BIND 5.4 или более поздней версией. Собственная служба DNS системы Windows 2000 использует уже BIND 8.2.3. В том, что касается защиты данных, эта служба отличается от DNS, реализованной в Windows NT, несколькими усовершенствованиями, в том числе защищенными обменами зонами (secure zone transfers) и защищенными обновлениями записей (клиентов Microsoft). Если используется версия DNS, установленная на сервере Windows NT, необходимо по возможности модернизировать такой сервер до уровня Windows 2000.

Шаг 3. Структурируйте DNS для интеграции с AD

Служба DNS операционной системы Windows 2000 позволяет конфигурировать зоны как стандартные или как интегрированные со службой AD. Стандартные зоны аналогичны зонам, применяемым в DNS системы Windows NT: данные DNS в этих зонах хранятся в виде обычных текстовых файлов, совместное использование зональной информации серверами DNS осуществляется в форме обмена незашифрованными данными, а обновления записей клиентов передаются по всей сети без шифрования. В зонах, интегрированных со службой AD, данные DNS хранятся вместе с зашифрованной информацией службы каталога и передаются с сервера на сервер в рамках процесса тиражирования AD, который предусматривает шифрование данных в ходе передачи. Кроме того, встроенные в AD зоны позволяют защищать данные, направляемые клиентами серверу DNS в процессе обновления записей.

Очевидно, что лучше иметь зоны, интегрированные с AD, но такой выбор требует более тщательного планирования на этапе развертывания серверов, на которых установлена DNS. Два главных требования состоят в следующем: служба DNS должна выполняться на контроллерах доменов (domain controller, DC), и все они должны располагаться в одном и том же домене. Вполне возможно, что выполнить эти требования будет непросто. Предположим, организация использует одно и то же доменное имя как в Internet, так и внутри сети, но ее серверы разделяются на множество доменов. В этом случае для того, чтобы разместить серверы DNS по всем физическим адресам организации (дабы повысить эффективность разрешения имен), возможно, потребуется развернуть дополнительные контроллеры доменов даже для таких доменов, которые могут в отдельных местах и не использоваться. Затраты могут возрасти еще и из-за того, что для организации бесполезного по большому счету репликационного трафика в таких доменах потребуется дополнительный запас полосы пропускания.

Разумеется, совсем не обязательно создавать полностью интегрированную с AD службу DNS. Несколько контроллеров доменов могут обслуживать зону (и выполнять функции целевых устройств для защищенных обновлений клиентов) в режиме AD-интеграции. Администратор может сконфигурировать в качестве вторичных DNS-серверов другие серверы, не являющиеся контроллерами доменов или не входящие в главный домен, и эти серверы могут осуществлять разрешение имен для клиентов. Однако следует иметь в виду, что перенос интегрированной с AD зоны на стандартный вторичный сервер DNS осуществляется в незащищенном режиме.

Чтобы создать новую интегрированную с AD зону, нужно выполнить следующие действия.

  • Установить DNS на всех контроллерах доменов, которые должны выполнять функции серверов DNS.
  • На одном из этих серверов запустить оснастку DNS консоли Microsoft Management Console (MMC).
  • В окне с древовидной структурой щелкнуть на значке сервера DNS.
  • В окне с древовидной структурой щелкнуть правой кнопкой мыши на элементе Forward Lookup Zones. Чтобы запустить New Zone Wizard, нужно выбрать пункт New Zone.
  • Щелкнуть на кнопке Next.
  • В окне мастера, показанном на Экране 1, выбрать элемент Active Directory-integrated.
  • Продолжить формирование зоны.
  • Для преобразования стандартной зоны DNS в зону, интегрированную с AD, требуется выполнить следующие действия.
  • Установить DNS на всех контроллерах доменов, которые будут выполнять функции серверов DNS.
  • Перенести первичную стандартную зону (Primary standard zone) на контроллер домена, где выполняется DNS.
  • Запустить оснастку DNS на DNS-сервере, обслуживающем первичную зону.
  • Щелкнуть на значке сервера DNS.
  • В окне с древовидной структурой выполнить двойной щелчок на элементе Forward Lookup Zones.
  • Правой кнопкой мыши щелкнуть на имени зоны и выбрать элемент Properties.
  • Щелкнуть на параметре Change, который расположен на закладке General окна Properties.
  • На экране Change Zone Type выбрать пункт Active Directory-integrated.
Экран 1. Выбор типа зоны DNS.

Шаг 4. Для файлов стандартной зоны установите защиту средствами NTFS

Независимо от того, используется ли DNS системы Windows 2000 или Windows NT, следует позаботиться о том, чтобы файлы были защищены средствами безопасности стандарта NTFS. Поскольку служба DNS предусматривает хранение интегрированных с AD зон не в файле, а в базе данных AD, разрешения NTFS на эти зоны не влияют.

Понятно, что интегрированные с AD зоны нельзя применять при использовании Windows NT. Кроме того, без стандартных зон не обойтись и в некоторых сетях Windows 2000 — для сохранения совместимости с DNS-серверами более ранних версий. Стандартные зоны хранятся в виде обычных текстовых файлов с расширением .dns в каталоге \%systemroot%system32dns, обычно на диске C. Таким образом, стандартная зона joe.com, как правило, хранится по адресу: C:winntsystem32dnsjoe.com.dns. Эти файлы следует хранить на разделе NTFS и предоставлять применительно к ним разрешения уровня Full Control только администраторам домена, как показано на Экране 2.

Экран 2. Предоставление разрешений на открытие стандартных зональных файлов.

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

Шаг 5. Защитите передачу зон DNS

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

В ходе синхронизации содержимого серверов DNS серверы DNS Windows NT пересылают весь файл зоны (в виде открытого текста, как я отмечал ранее) даже в том случае, если изменилась всего одна запись. Единственный способ защитить передачу зон между DNS-серверами Windows NT — использовать VPN-туннели или программы шифрования независимых поставщиков. Модернизацию серверов DNS до уровня Windows 2000 обычно выполнять проще.

Служба DNS системы Windows 2000 позволяет осуществлять инкрементную передачу (incremental zone transfer, IXFR) для стандартных зон, поэтому DNS-серверы Windows 2000 передают только те записи, содержимое которых было изменено. При таком подходе вероятность перехвата всей зоны резко уменьшается: DNS-серверы Windows 2000 передают содержимое всей зоны лишь тогда, когда администратор добавляет вторичный сервер DNS. Безопасность передачи зон — важнейший аргумент в пользу реализации зон, интегрированных с AD. В этих зонах информация DNS передается в рамках процесса репликации AD между контроллерами доменов, поэтому, с одной стороны, обмены являются инкрементными, а с другой — передаваемые данные шифруются.

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

Возможность защитить содержимое стандартных зон от перехвата существует, но для такой защиты требуется изменить стандартную конфигурацию, которая позволяет выполнять перенос зон с любым сервером. При использовании Windows 2000 или Windows NT следует ограничить число партнеров по передаче зоны и разрешать такую передачу лишь санкционированным партнерам DNS. Чтобы настроить стандартные зоны для выполнения ограниченных переносов зон, нужно выполнить следующие действия.

  • На первичном сервере зоны запустить оснастку DNS.
  • Выполнить двойной щелчок на имени сервера DNS.
  • Дважды щелкнуть на элементе Forward Lookup Zones.
  • Правой клавишей мыши щелкнуть на имени зоны и выбрать элемент Properties.
  • На закладке Zone Transfers в разделе Allow zone transfers установить флажок Only to the following servers, как показано на Экране 3.
  • Ввести IP-адрес вторичного сервера DNS для данной зоны, затем щелкнуть на кнопке Add.
  • Повторить пункт 6 для всех остальных вторичных серверов DNS (передачу зоны для каждой зоны нужно конфигурировать индивидуально).
  • Щелкнуть OK.
Экран 3. Настройка для осуществления ограниченных зональных обменов.

Шаг 6. Защитите обновления DNS

Я настоятельно рекомендую использовать не DNS Windows NT, а DNS Windows 2000. Но должен признаться: в том, что касается обеспечения безопасности, последняя из названных версий имеет свои недостатки. Один из них состоит в том, что клиентский компьютер может вносить изменения в базу данных DNS. В Windows 2000 реализована возможность динамического обновления DNS. Это означает, что клиенты и серверы DHCP могут автоматически — и дистанционно — выполнять утомительную процедуру обслуживания базы данных DNS. В среде Windows NT изменение базы данных DNS осуществляется вручную; им должны заниматься администраторы, имеющие соединение с сервером DNS, так что в этом отношении DNS-системы Windows NT защищены лучше, чем DNS Windows 2000. Однако изменение записей DNS хотя бы для одной системы за сеанс предоставляет хакеру возможность захватить данные, а затем с их помощью выдать себя за другую систему.

К примеру, организаторы атак в Internet прибегают к спуфингу (подмене адресов), подменяют серверы DNS и перенаправляют пользователей на фальшивые торговые или на порнографические сайты. Примером таких действий может служить предпринятая в 1997 г. массовая спуфинг-акция AlterNIC. В конце концов, DNS контролирует основные адреса всего трафика сети TCP/IP. Злоумышленники могут задействовать функцию динамического обновления для перенаправления пользователей с легитимной системы на «самозваную».

Специалисты Microsoft, разрабатывавшие DNS системы Windows 2000, уделяли особое внимание проблемам безопасности и предусмотрели возможность того, что хакеры могут попытаться использовать в своих целях процесс динамического обновления. После того как клиент регистрируется в интегрированной с AD зоне, настроенной таким образом, чтобы принимать только защищенные обновления, клиент может изменять host-запись DNS лишь в том случае, если его полномочия были проверены службой AD. DNS Windows 2000 обеспечивает динамические обновления и для стандартных зон, однако возможность защиты таких обновлений не предусмотрена.

Для настройки интегрированной с AD зоны таким образом, чтобы разрешались только защищенные динамические обновления, нужно выполнить следующие действия.

  • Запустить оснастку DNS.
  • Дважды щелкнуть на имени сервера DNS.
  • Выполнить двойной щелчок на элементе Forward Lookup Zones.
  • Правой клавишей мыши щелкнуть на имени зоны и выбрать пункт Properties.
  • Как показано на Экране 4, на закладке General из списка Allow dynamic updates выбрать пункт Only secure updates (если список Allow dynamic updates не отображается, значит, данная зона не является интегрированной с AD).
  • Щелкнуть на кнопке OK.
Экран 4. Обеспечение защиты динамических обновлений.

Непробиваемая DNS

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

Джо Рудич — сетевой администратор St. Paul Companies в г. Сент-Пол, шт. Миннесота. С ним можно связаться по адресу: joe@rudich.com.