Уязвимые места защиты 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 (транспортный).