Защита DNS

В старые времена - около полутора десятка лет назад - ученые-исследователи, университетские профессора и чиновники Министерства обороны открыто использовали Internet для обмена информацией. Такая система работала, потому что она состояла из небольшого сетевого сообщества, члены которого доверяли друг другу.

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

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

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

Например, когда пользователь обращается из браузера к http://www.examiner.com (узел Web сан-францисской газеты), он, естественно, ожидает, что полученная страница Web принадлежит этой газете. Однако протокол DNS не содержит никаких механизмов для потверждения факта аутентичности страницы Web.

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

В каждой отрасли есть свой злой гений - просто представьте себе, что ваш заклятый конкурент мог бы сделать с вашей репутацией, если бы он получил контроль над базой подписчиков вашего сервера Web всего на один день. Неточные или намеренно недостоверные данные могут привести к тому, что пользователи столкнутся с отказом в обслуживании или будут перенаправлены на серверы сомнительного содержания. Для решения этой проблемы IETF работает над расширениями защиты для протокола DNS - так называемой Domain Name System Security (DNSSEC).

ОТ SRI-NIC ДО DNS

До появления DNS данные о каждом новом хосте приходилось добавлять в центральное хранилище Информационного центра сети в Стенфордском исследовательском институте (Stanford Research Institute`s Network Information Center, SRI-NIC), отвечавшем за предоставление такой информации до начала 90-х. SRI-NIC затем публиковал этот файл, и он посредством массового копирования поступал на все хосты сети агентства по перспективным исследованиям (Advanced Research Projects Agency Network, ARPANET).

Другая проблема такого метода управления именами хостов состояла в его плоской структуре. Каждое зарегистрированное в SRI-NIC имя должно было быть уникальным. Например, никакие два хоста нигде в Internet не могли одновременно называться www. Как результат, SRI-NIC уступила место DNS.

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

В DNS эта информация хранится в записях ресурсов (Resource Records, RR). Каждому типу содержащейся в DNS информации соответствует свой тип RR. Примерами типов записей о ресурсах могут служить запись A об IP-адресе для данного имени хоста, запись NS о сервере имен для данного имени домена и запись MX о почтовом сервере для данного имени DNS.

Иерархическая упорядоченность DNS обеспечивает уникальность имен хостов. Иерархическая структура DNS имеет вид перевернутого дерева. При перемещении по дереву от листа к корню мы получаем полное доменное имя (Fully Qualified Domain Name, FQDN). В DNS всякое имя FQDN является уникальным. Запрос с указанием имени хоста приводит к просмотру структуры дерева от корня до листа в целях нахождения соответствующего ему IP-адреса. Аналогичное дерево имеется и для обратного отображения, в случае которого запрос с IP-адресом приводит к просмотру структуры этого дерева для нахождения имени хоста или FQDN, для указанного IP-адреса.

Верхнему уровню перевернутого дерева соответствует корень DNS. Этот корень обычно обозначается как "." (т. е. "точка") и является последним символом в FQDN. Первый уровень ниже корня делится на крупные классы, такие, как некоммерческие организации (org), коммерческие структуры (com), образовательные учреждения (edu) и т. д. Следующий уровень обычно представляет конкретную организацию или компанию в домене org, edu или com. Например, isc.org или vix.com. И isc, и vix называются также именами доменов.

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

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

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

УЯЗВИМЫЕ МЕСТА ЗАЩИТЫ DNS

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

Рисунок 1. В данном примере DNS атакующего ответственна за сеть 172.16.0 (0.16.172.in-addr.arpa). Атакующий присваивает обратный адрес 172.16.0.8 хосту с именем trustme.plain.org. Злоумышленник подключается к victim.example.com для исследования его доверительных взаимоотношений с trustme.plain.org. Атака оказывается успешной, потому что протокол DNS не предусматривает какого-либо механизма предотвращения назначения владельцем обратного адресного пространства доменных имен за пределами его области полномочий.

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

Некоторые из наиболее распространенных приложений, где когда-то использовалась такая процедура, были переделаны в целях проведения еще одной проверки - что имя хоста DNS соответствует данному IP-адресу. Однако многие приложения не предусматривают этой дополнительной процедуры. Старые версии rlogin, RSH, Network File System (NFS), X Window и HTTP могут быть по-прежнему уязвимы для такого рода атак.

Кроме того, DNS уязвима с позиций взлома системы. Если злоумышленник сможет через одну из сетевых служб (telnet, ftp и т. д.) получить несанкционированный доступ к серверу DNS, после этого он получит возможность изменять базу данных DNS, как ему заблагорассудится. В такой ситуации протокол DNS опять оказывается беззащитен, потому что он не обеспечивает идентификации данных. (О том, как сделать серверы DNS более защищенными, читай врезку "Защита серверов DNS без помощи DNSSEC".)

КРИПТОГРАФИЧЕСКИЕ ПОДПИСИ

Для ликвидации названных ограничений протокола DNS IETF создала рабочую группу DNSSEC (DNSSEC Working Group, DNSSEC WG) для внесения расширений DNSSEC в существующий протокол. Berkeley Internet Name Daemon (BIND) 8.2 имеет некоторые из функциональных возможностей DNSSEC.

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

Рисунок 2. Два примера ответов и запросов DNS с DNSSEC и без оных. Обратите внимание, что в ответе с DNSSEC ответное сообщение содержит не только подписи и ключи, необходимые для проверки информации, но и сам исходный вопрос. Эта процедура называется "Аутентификацией транзакции и запроса". Благодаря ей запрашивающая сторона может быть уверена, что она получила ответ на тот вопрос, который задавала.

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

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

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

НОВЫЕ ЗАПИСИ РЕСУРСОВ

Криптографические подписи DNSSEC применяются к данным по зоне, динамическим обновлениям и транзакциям DNS. Кроме того, они используются для подтверждения отсутствия данных DNS. DNSSEC предусматривает три новые записи ресурсов - KEY RR, SIG RR и NXT RR.

KEY RR содержит открытый ключ, принадлежащий имени домена, указанному в KEY RR. Это не сертификат открытого ключа. Механизм обеспечения возможностей поиска сертификатов открытых ключей предусматривается DNSSEC WG, но не для целей защиты данных DNS. Он предоставляется в качестве дополнительного бонуса, благодаря которому DNS может применяться для запроса сертификатов открытых ключей на все, что может быть представлено с помощью имени домена. Эту возможность обеспечивает CERT RR.

SIG RR содержит преимущественно криптографическую подпись, дату окончания срока годности подписи и определение данных DNS, к которым эта подпись относится. NXT RR позволяет проверить (за счет использования криптографии), что RR для данного имени DNS не существует. Таким образом, отсутствие данной RR может быть подтверждено доказательно.

Другим аспектом DNSSEC является подпись транзакции (Transaction Signature, TSIG). TSIG отличается от других подписей DNS тем, что она создается с использованием шифрования с секретными ключами. Мы рассмотрим TSIG позже.

Протокол DNSSEC как таковой не обеспечивает конфиденциальности данных или контроля доступа. Однако конкретные его реализации могут предусматривать те или иные механизмы обеспечения конфиденциальности и контроля доступа. Причина отсутствия такого стандартного механизма в DNS в том, что исходный протокол DNS предназначался для работы с общедоступными данными. Озабоченность утечкой информации относительно имен и местонахождения систем и возможность атак по типу "отказ в обслуживании" порождает спрос на механизмы обеспечения конфиденциальности и контроля доступа. Этот спрос отражается в реализациях DNS.

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

Internet Software Consortium (ISG) - некоммерческая организация, занимающаяся реализацией базовых протоколов Internet в виде открытых кодов, - добавила два механизма защиты для наделения сервера DNS возможностями DNSSEC. Первый определяет аутентичность данных в системе на основании проверки факта их подписи администратором узла, от которого они якобы поступили.

Однако, как большинство подобных решений, этот метод просто смещает акценты в проблеме защиты, ставя вопрос: "Как мы можем знать, что данные были действительно подписаны тем, кем они должны были быть подписаны?" В случае шифрования с открытыми ключами подписи генерируются с помощью личного ключа и проверяются с помощью открытого ключа. DNSSEC использует для распространения открытых ключей узлов Internet саму DNS, т. е. необходимый для проверки ключ предоставляется с помощью того же самого совершенно незащищенного протокола, что и данные, которые вы пытаетесь проверить. Кажется, что мы попали в замкнутый круг, но это не так.

Один из способов проверить открытый ключ до использования его для проверки ответа - взглянуть на подпись самого открытого ключа. Родительский узел должен подписывать все свои открытые ключи, поэтому в нашем первом примере проверочный (открытый) ключ examiner.com должен был быть подписан администратором com. Однако, прежде чем проверять подпись com для examiner.com, нам необходимо знать открытый (проверочный) ключ для самого com, а он должен быть подписан родителем com (т. е. вышеупомянутым корнем DNS). Чтобы быть абсолютно уверенными в том, что открытые (проверочные) ключи корня действительно принадлежат ему, они должны находиться на вашем компьютере в файле, полученном защищенным образом (например, на CD-ROM) от надежного источника (например, от производителя компьютера). Так как корень является прародителем всех имен доменов, для всей DNS нужен только один открытый ключ.

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

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

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

ПОДПИСИ ТРАНЗАКЦИЙ

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

TSIG особенно полезен в случае транзакций DNS UPDATE. Большинство транзакций DNS представляет собой запросы относительно наличия данных. Транзакция DNS UPDATE вносит изменения в данные DNS на узле. Эта транзакция описана в RFC 2136, но для наших целей достаточно будет знать, что она не снабжена собственными механизмами защиты.

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

НЕДОСТАТКИ DNSSEC

Подписание и проверка данных DNS, очевидно, создают дополнительные накладные расходы, отрицательно сказывающиеся на производительности сети и серверов. Подписи занимают немало места, часто они намного превышают по объему данные, под которыми стоят. Это увеличивает нагрузку, которую DNS возлагает на магистраль Internet и многие немагистральные каналы. Генерация и проверка подписей отнимают значительное время ЦПУ. В некоторых случаях однопроцессорный сервер DNS придется даже заменить многопроцессорным сервером DNS. Подписи и ключи могут занимать на порядок больше места на диске и в оперативной памяти, чем собственно данные. Базы данных и системы управления придется наращивать, чтобы они могли справляться с возросшими объемами.

Кроме того, реализация DNSSEC сопровождается и другими, не столь очевидными затратами. Новое программное обеспечение больше по объему и сложнее, чем прежнее, а многие его компоненты являются совершенно новыми и нуждаются в обширном тестировании в реальных условиях. Пока широкомасштабных испытаний DNSSEC в Internet не проводилось, так что они могут принести множество сюрпризов (возможно, даже придется полностью менять).

Вывод отсюда следующий: развертывание DNSSEC чревато столькими же опасностями, как и отказ от него. Мы бы рекомендовали обождать год или два, пока DNSSEC RFC не получит статуса хотя бы проекта стандарта.

На декабрь 1999 года TSIG полностью и DNSSEC частично были реализованы только в BIND 8.2. Другие разработчики (включая Microsoft) собираются реализовать различные формы TSIG в следующих редакциях своих продуктов. Спецификация BIND 9.0, появление которой ожидается в первой четверти 2000 года, будет содержать полную реализацию DNSSEC.

РАБОТА ПРОДОЛЖАЕТСЯ

Работа над некоторыми функциональными сторонами DNSSEC еще продолжается, например над тем, как именно администрация com будет подписывать открытые ключи. Соответствующий новый протокол может вскоре появиться. Кроме того, во время смены ключей может потребоваться поддерживать одновременно более одной пары открытых/личных ключей, но, как это будет реализовано, пока неясно. Если личный ключ окажется украден и, как следствие, должен будет изъят из обращения, то в настоящее время никаким способом нельзя известить о компрометации ключа тех, кто будет проверять с его помощью подпись.

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

Должны ли Соединенные Штаты продолжать администрировать это всемирное средство обеспечения электронной коммерции? Если администрирование будет передано некоммерческой отраслевой ассоциации, например Internet Corporation for Assigned Name and Numbers (ICANN), то сможет ли такая организация учесть интересы и законодательство всех стран? Должно ли оно быть передано Объединенным Нациям? В состоянии ли Объединенные Нации справиться с подобной ответственностью? В состоянии ли кто-нибудь вообще? Развертывание DNSSEC во всемирном масштабе невозможно, пока вопрос с администрацией корня не будет урегулирован.

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

Дайана Давидович работает в Национальном управлении океанических и атмосферных исследований. С ней можно связаться по адресу: compsec101@yahoo.com. Пол Викси - президент и основатель Internet Software Consortium (ISC) и архитектор BIND. С ним можно связаться по адресу: paul@isc.org.

Защита серверов DNS без помощи DNSSEC

Ресурсы Internet