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

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

СХЕМА СЕРВИСА DNS

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

Некоторые системы периодически обновляют информацию по протоколу динамических обновлений. Обычно это происходит, когда система получает IP-адрес по протоколу DHCP и ей требуется обновить соответствие своего имени своему цифровому IP-адресу.

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

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

ПОТЕНЦИАЛЬНЫЕ УГРОЗЫ

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

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

В дальнейшем первичный сервер может быть выведен из строя, например посредством атаки DDoS.

Самый популярный вид атак на DNS — «отравление» кэширующего сервера (Cache Poison Attack) — приводит к тому, что в кэше сервера провайдера или локальной сети компании сохраняется искаженная информация, которая и предоставляется пользователям в ответ на их запросы. Кроме того, искажение информации возможно при взаимодействии непосредственно с резолвером клиента.

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

Так ли реальна угроза? Да, вполне реальна, и число успешных атак растет как снежный ком. Что же именно делают злоумышленники? Рассмотрим наиболее распространенные атаки.

РЕАЛЬНЫЕ АТАКИ

Чаще всего встречается указание своего сайта вместо запрашиваемого с целью сбора конфиденциальной информации (пароли, номера кредитных карт, маркеры cookies и т. д.). Причем, в отличие, скажем, от фишинга, пользователь даже не подозревает, что его обманывают. Не спасает и защищенный Web-протокол HTTPS (за исключением все еще редко встречающихся случаев приобретения сертификата SSL, хотя и при его наличии пользователь, скорее всего, проигнорирует сообщение о несоответствии сертификатов).

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

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

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

В общем и целом, для атак на DNS уязвима любая коммуникация в сети Internet, где используются буквенные имена ресурсов.

ПРОТОКОЛ DNSSEC

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

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

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

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

Как система DNS позволяет иерархично делегировать домены, так и система DNSSEC обеспечивает иерархичное делегирование доверия. Иначе говоря, подписанный ключом домена .RU ключ домена DNSSEC.RU позволяет проверить, является ли верным ответ с адресом ресурса www.dnssec.ru.

ИСПОЛЬЗОВАНИЕ НА ПРАКТИКЕ

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

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

RIPE принимает непосредственное активное участие во внедрении протокола DNS, им написано множество программ и библиотек, значительно облегчающих системным администраторам переход на DNSSEC.

С помощью подключаемых модулей поддержку DNSSEC можно добавить и к IPSEC, и LDAP. Более подробно о протоколе, программном обеспечении и доменах, уже поддерживающих DNSSEC, можно прочитать на сайте портала, посвященного DNSSEC, http://www.dnssec.net/.

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

К сожалению, корневые серверы DNS все еще не подписаны DNSSEC — пока существуют только пилотные проекты, в рамках которых предусматривается подпись копии корневых доменов. Один из таких проектов — http://www.rs.net/.

Поэтому ключи каждого домена верхнего уровня придется указывать по отдельности. Сейчас DNSSEC поддерживают (и имеют свои ключи) домены .NL, .SE, .MX, ряд доменов второго уровня .UK, популярные в мире домены .COM, .NET, .ORG, а также те, которые отвечают за обратное преобразование IP-адресов (из IP в имя сервера) в регионе RIPE.

Ради справедливости отметим, что правильность ответа DNS можно проверить и при помощи механизма look-aside вне иерархии доменов: администратор любого домена может добавить информацию о проверке в соответствующую систему DLV. Данный механизм поддерживается и в BIND 9.

Поддержка протокола DNSSEC появилась и в домене .RU. Подписанную копию домена .RU обслуживает компания «Гарант-Парк-Те-леком» (регистратор R01). Она же осуществляет защищенное DNSSEC делегирование доменов второго уровня в .RU.

Подробную инструкцию для системных администраторов по настройке DNSSEC на русском и английском языках, а также открытый ключ цифровой подписи домена .RU можно получить на сайте http://www.dnssec.ru/.

В домене .RU регистрацию доменов с их последующим защищенным делегированием осуществляет исключительно регистратор R01. Если домен находится на обслуживании у другого регистратора, его следует перенести в R01. По регламенту домена .RU эта операция бесплатна.

Подпись домена — достаточно простая процедура. Необходимо лишь сгенерировать ключи подписи, добавить открытый ключ в файл описания домена и подписать домен. Все действия выполняются программами, которые входят в стандартную поставку BIND версии 9.

В момент подписи будет сгенерирована строка DS (dsset), ее надо указать наряду с серверами NS в интерфейсе R01 при делегировании домена. Теперь домен защищен DNSSEC, так что все, использующие этот протокол, могут быть уверены, что при запросе ресурса попадают на нужный им сервер.

Максим Тульев — руководитель проекта LIR компании «Гарант-Парк-Телеком».