УЯЗВИМЫЕ МЕСТА ЗАЩИТЫ 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 более защищенными, читай врезку .)
