Уязвимые места защиты dns

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

ЛожныйDns-сервер в сети Internet

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

В самом начале зарождения Internet для удобства пользователей было принято решение присвоить всем компьютерам в сети имена. Использование имен позволяет пользователю лучше ориентироваться в киберпространстве сети Internet - куда проще, понятней и наглядней для пользователя запомнить, например, имяwww.ferrari.it, чем четырехразрядную цепочку IP-адреса. Использование в Internet мнемонически понятных для пользователей имен породило проблему преобразования имен в IP-адреса. Такое преобразование необходимо, так как на сетевом уровне адресация пакетов идет не по именам, а по IP-адресам, следовательно, для непосредственной адресации сообщений в Internet имена не годятся. На этапе раннего развития Internet, когда в сеть было объединено небольшое количество компьютеров, NIC (Network Information Center) для решения проблемы преобразования имен в адреса создал специальный файл (hosts file), в который вносились имена и соответствующие им IP-адреса всех хостов в сети. Данный файл регулярно обновлялся и распространялся по всей сети. Но, по мере развития Internet, число объединенных в сеть хостов увеличивалось, и данная схема становилась все менее и менее работоспособной, поэтому была создана новая система преобразования имен, позволяющая пользователю в случае отсутствия у него информации о соответствии имен и IP-адресов получить необходимые сведения от ближайшего информационно-поискового сервера (DNS-сервера). Эта система получила название доменной системы имен -DNS(Domain Name System).

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

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

• хост посылает на IP-адрес ближайшегоDNS-сервера (он устанавливается при настройке сетевой ОС)DNS-запрос, в котором указывает имя сервера, IP-адрес которого необходимо найти;

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

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

Внедрение в сеть Internet ложного  DNS-сервера путем перехватаDNS-запроса

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

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

Во-вторых, следующая тонкость, на которую требуется обратить внимание, состоит в том, что значение поля "порт отправителя" в UDP-пакете вначале принимает значение ? 1023 и увеличивается с каждым переданнымDNS-запросом.

В-третьих, значение идентификатора (ID)DNS-запроса ведет себя следующим образом. В случае передачиDNS-запроса с хоста это значение зависит от конкретного сетевого приложения, вырабатывающегоDNS-запрос. Эксперименты показали, что в случае передачи запроса из оболочки командного интерпретатора (SHELL) операционных систем Linux и Windows '95 (например, ftp nic.funet.fi) это значение всегда равняется единице. В том случае, еслиDNS-запрос передается из Netscape Navigator, то с каждым новым запросом сам броузер увеличивает это значение на единицу. В том случае, если запрос передается непосредственноDNS-сервером, то сервер увеличивает это значение идентификатора на единицу с каждым вновь передаваемым запросом. Все эти тонкости имеют значение в случае атаки без перехватаDNS-запроса.

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

Рассмотрим обобщенную схему работы ложногоDNS-сервера (рис. 4.4):

• ожиданиеDNS-запроса;

• извлечение из полученного запроса необходимых сведений и передача по сети на запросивший хост ложногоDNS-ответа, от имени (с IP-адреса) настоящегоDNS-сервера, в котором указывается IP-адрес ложногоDNS-сервера;

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

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

Рис. 4.4. Функциональная схема ложного  DNS-сервера.

Рис. 4.4.1. Фаза ожидания атакующимDNS-запроса (он находится на ХА1, либо на ХА2).

Рис. 4.4.2. Фаза передачи атакующим ложногоDNS-ответа.

Рис. 4.4.3. Фаза приема, анализа, воздействия и передачи перехваченной информации на ложном сервере.

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

Отметим, что практическая реализация данной удаленной атаки выявила ряд интересных особенностей в работе протокола FTP и в механизме идентификации TCP-пакетов (подробнее см. п. 4.5). В случае, когда FTP-клиент на хосте подключался к удаленному FTP-серверу через ложныйDNS-сервер, оказывалось, что каждый раз после выдачи пользователем прикладной команды FTP (например, ls, get, put и т. д.) FTP-клиент вырабатывал команду PORT, которая состояла в передаче на FTP-сервер в поле данных TCP-пакета номера порта иIP-адреса клиентского хоста(особый смысл в этих действиях трудно найти - зачем каждый раз передавать на FTP-сервер IP-адрес клиента)! Это приводило к тому, что, если на ложномDNS-сервере не изменить передаваемый IP-адрес в поле данных TCP-пакета и передать этот пакет на FTP-сервер по обыкновенной схеме, то следующий пакет будет передан FTP-сервером на хост FTP-клиента, минуя ложныйDNS-сервер и, что самое интересное, этот пакет будет воспринят как нормальный пакет (п. 4.5), и, в дальнейшем, ложныйDNS-сервер потеряет контроль над трафиком между FTP-сервером и FTP-клиентом! Это связано с тем, что обычный FTP-сервер не предусматривает никакой дополнительной идентификации FTP-клиента, а перекладывает все проблемы идентификации пакетов и соединения на более низкий уровень - уровень TCP (транспортный).