Внедрение в сеть 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 (транспортный).