Вспомним DNS-алгоритм удаленного поиска IP-адреса по имени в Сети:

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

· удаленные атаки на DNS-сервер, а именно:

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

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

Рис. 6. 'Шторм' ложных ответов

Первый вариант проведения удаленной атаки, направленной на службу DNS, основан на разновидности типовой удаленной атаки "Ложный объект РВС" [2]. В этом случае атакующий осуществляет постоянную передачу на атакуемый хост заранее подготовленного ложного DNS-ответа от имени настоящего DNS-сервера без приема DNS-запроса. (Рис 6). Другими словами, атакующий создает в сети Internet направленный "шторм" ложных DNS-ответов. Это возможно, так как обычно для передачи DNS-запроса используется протокол UDP, в котором отсутствуют средства идентификации пакетов. Критерии, предъявляемые сетевой ОС хоста к полученному от DNS-сервера ответу, - это, во-первых, совпадение IP-адреса отправителя ответа с IP-адресом DNS-сервера; во-вторых, необходимо, чтобы в DNS-ответе было указано то же имя, что и в DNS-запросе; в-третьих, DNS-ответ должен быть направлен на тот же UDP-порт, с которого был послан DNS-запрос, и, в-четвертых, в DNS-ответе поле идентификатор запроса в заголовке DNS (ID) должно содержать то же значение, что и в переданном DNS-запросе.

Из рассмотренной ранее схемы удаленного DNS-поиска следует, что в том случае, если указанное в запросе имя DNS-сервер не обнаружил в своей базе имен, то запрос отсылается сервером на один из корневых DNS-серверов, адреса которых содержатся в файле настроек сервера root.cache. Т. е. в том случае, если DNS-сервер не имеет сведений о запрашиваемом хосте, он пересылает запрос далее - это значит, что теперь сам DNS-сервер является инициатором удаленного DNS-поиска. Поэтому ничто не мешает атакующему, действуя описанными выше методами, перенести свой удар непосредственно на DNS-сервер [2]. Иначе говоря, в качестве цели атаки теперь будет выступать не хост, а DNS-сервер и ложные DNS-ответы будут направляться атакующим от имени корневого DNS-сервера на атакуемый DNS-сервер. При этом важно учитывать следующую особенность работы DNS-сервера. Для ускорения работы каждый DNS-сервер кэширует в области памяти свою таблицу соответствия имен и IP-адресов хостов. В том числе в кэш заносится динамически изменяемая информация об именах и IP-адресах хостов, найденных в процессе функционирования DNS-сервера. Т. е. если DNS-сервер, получив запрос, не находит у себя в кэш-таблице соответствующей записи, он пересылает ответ на следующий сервер и, получив ответ, заносит найденные сведения в кэш-таблицу. Таким образом, при получении следующего запроса DNS-серверу уже не требуется вести удаленный поиск, так как необходимая информация уже находится у него в памяти.

Из анализа описанной схемы удаленного DNS-поиска становится очевидно, что в том случае если в ответ на запрос от DNS-сервера атакующий направит ложный DNS-ответ (или в случае "шторма" ложных ответов будет вести их постоянную передачу), то в кэш-таблице сервера появится соответствующая запись с ложными сведениями, и в дальнейшем все хосты, обратившиеся к данному DNS-серверу, будут дезинформированы, и при обращении к хосту, маршрут к которому атакующий решил изменить, связь с ним будет осуществляться через хост атакующего по схеме "Ложный объект РВС". И с течением времени эта ложная информация, попавшая в кэш DNS-сервера, будет распространяться на соседние DNS-серверы высших уровней.

Значительно более общим случаем является межсегментная атака, не требующая для своей реализации столь жестких условий, когда атакующий и целевой DNS-сервер разделяют общую физическую среду передачи [3].

Рис. 7. Межсегментная удаленная атака

Межсегментная атака на DNS-сервер выглядит следующим образом. Предположим для определенности, что целью атаки является "подмена" IP-адреса web-сервера www.coolsite.com на IP-адрес сервера www.badsite.com для пользователей некоторой подсети, которую обслуживает DNS-сервер ns.victim.com. В первой фазе атаки ns.victim.com провоцируется на поиск информации о IP-адресе www.coolsite.com путем посылки ему соответствующего рекурсивного запроса. Во второй фазе атакующий посылает серверу ns.victim.com ложный ответ от имени ns.coolsite.com, который является ответственным за домен coolsite.com. В ложном ответе вместо реального IP-адреса www.coolsite.com указывается IP-адрес www.badsite.com . Сервер ns.victim.com кэширует полученную информацию, в результате чего в течении определенного промежутка времени (величина этого промежутка указывается в поле TTL ложного ответа и может произвольно выбираться атакующим) ничего не подозревающие пользователи вместо сервера www.coolsite.com попадают на www.badsite.com (рис. 7).

Для того, чтобы ложный ответ был воспринят сервером ns.victim.com как истинный, достаточно выполнения четырех условий:

• IP адрес отправителя ответа должен соответствовать IP-адресу запрашиваемого сервера (в данном случае ns.coolsite.com);
• UDP-порт, на который направляется ответ, должен совпадать с портом, с которого был послан запрос;
• идентификатор ответа должен совпадать с идентификатором запроса;
• ответ должен содержать запрашиваемую информацию (в данном случае IP-адрес web-сервера www.coolsite.com).

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

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

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

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

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

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

Так же можно предложить использовать комплект приложений BIND (Berkley Internet Name Daemon) - берклевский демон имен Internet. Начиная с версии 4.9.3 в спецификацию BIND было внесено несколько директив и типов записей DNS, которые призваны несколько улучшить защиту серверов имен. Директива xfrnets файла начальной загрузки (/etc/named.boot) позволяет указать список IP-адресов сетей и серверов имен, на которые данный сервер имеет право пересылать информацию по зоне (операция зонной пересылки). Второе важное новшество - введение особого типа записи ресурсов TXT под названием SECURE_ZONE. Такая запись управляет перечнем машин и сетей (по IP-адресам), которым разрешено запрашивать данный сервер имен. Но несмотря на эти нововведения для отражения атак с подменой DNS требуется принять еще ряд мер. Среди них наиболее распространенной является установка двух серверов DNS: внешнего и внутреннего (см. Рис. 8).

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

Последняя версия BIND 8.2.2. включает в себя поддержку (RFC 2065) криптографической цифровой подписи, т.е. это уже не стандартный DNS -протокол, а расширенный, в котором в тело DNS-запроса будет включаться цифровая подпись. Это решение практически полностью обезопасит работу с DNS-службой. К сожалению, желаемый результат может дать только широкомасштабное внедрение новых протоколов, которое сопряжено со значительными организационными трудностями и не может быть проведено за короткое время.