Как быстро все меняется. Сегодня сообщество пользователей Internet достигло немыслимых размеров, и далеко не каждый его член заслуживает доверия. Наличие проказливых или злонамеренных пользователей породило потребность в защите. Однако при разработке DNS, одной из ключевых инфраструктур Internet, защита была отнюдь не главной целью. Как результат, DNS представляет собой незащищенный протокол.
DNS - это иерархическая база данных, содержащая записи с описанием имен, IP-адресов и другой информации о хостах. База данных находится на серверах DNS, связанных с Internet и частными сетями Intranet. Проще говоря, DNS предоставляет сетевым приложениям услуги каталога по преобразованию имен в адреса, когда им требуется определить местонахождение конкретных серверов. Например, имя DNS используется каждый раз при отправке сообщения электронной почты или доступе к странице Web.
Проблема в том, что нет никакого способа проверить, что ответ DNS поступил от аутентичного источника и содержит аутентичные данные. Немного потрудившись, даже ребенок сможет инфицировать сервер DNS неверными данными, которые клиенты Web будут не в состоянии отличить от верных данных. Этот факт вызывает особое беспокойство в связи с тем, что DNS часто используется в качестве системы неявной идентификации.
Например, когда пользователь обращается из браузера к (узел Web сан-францисской газеты), он, естественно, ожидает, что полученная страница Web принадлежит этой газете. Однако протокол DNS не содержит никаких механизмов для потверждения факта аутентичности страницы Web.
Хотя пользователь может увидеть страницу San Francisco Examiner вместо, как он надеялся, местной Examiner своего родного города, это не самое неприятное, что может случиться: пользователь может получить страницу Web, не принадлежащую вообще никакой газете, а неким злонамеренным третьим лицам, намеренно испортившим DNS, чтобы перенаправить ничего не подозревающих читателей на свой сервер Web, где публикуется сатира на реальную газету или где содержится заведомо искаженная информация.
В каждой отрасли есть свой злой гений - просто представьте себе, что ваш заклятый конкурент мог бы сделать с вашей репутацией, если бы он получил контроль над базой подписчиков вашего сервера Web всего на один день. Неточные или намеренно недостоверные данные могут привести к тому, что пользователи столкнутся с отказом в обслуживании или будут перенаправлены на серверы сомнительного содержания. Для решения этой проблемы IETF работает над расширениями защиты для протокола DNS - так называемой Domain Name System Security (DNSSEC).
Уязвимые места защиты DNS
Вместе с тем такая чрезвычайно эффективная организация оборачивается множеством слабостей с точки зрения защиты. Например, когда удаленная система связывается с приложением, приложение посылает запрос для определения имени DNS по ее IP-адресу. Если возвращаемое доменное имя соответствует ожидаемому, то удаленной системе разрешается доступ.
Рис 2. Схема атаки.
В данном примере 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 Security (DNSSEC) в BIND 8.2 или будете ждать полной стандартизации расширений защиты, в любом случае вы можете принять некоторые меры предосторожности для защиты информации DNS до появления полной реализации DNSSEC. Сервер, где выполняется программное обеспечение DNS, должен быть хорошо защищен. Все ПО, включая программное обеспечение DNS, должно быть представлено в последних редакциях, и к ним должны быть применены все выпущенные заплаты. При оценке возможности размещения DNS на сервере вы должны помнить, что всякое выполняющееся на сервере сетевое приложение увеличивает риск взлома. Для сокращения степени риска на сервере должны выполняться только самые необходимые для его работы приложения. Затем вы можете ограничить доступ к этим сервисам и предусмотреть жесткую идентификацию для тех приложений, для которых она необходима.
С появлением автоматизированного инструментария сканирования при выходе в Internet серверы DNS подвергаются постоянному зондированию и попыткам вторжения. Здесь практически ничего нельзя поделать, так как серверы DNS должны отвечать на запросы.
Однако их открытость можно ограничить за счет применения модели расщепленной DNS. При такой модели один сервер DNS с минимальной информацией помещается с внешней стороны сети, в то время как второй сервер - с внутренней стороны. Доступ к этому серверу возможен только из внутренней сети, и он содержит всю информацию DNS по внутренней сети.
Помните, что внутренние серверы могут подвергнуться атакам и изнутри сети, поэтому они должны быть защищены так же тщательно, как внешние серверы DNS. На случай, если злоумышленник получит доступ к серверу, администратор DNS может воспользоваться резюме сообщения (например, контрольной суммой MD5) для обнаружения факта незаконного изменения данных.
