Внедрение в сеть 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-запроса (п. 4.3.2 и 4.3.3).
Для реализации атаки путем перехвата DNS-запроса атакующему необходимо перехватить DNS-запрос, извлечь из него номер UDP-порта отправителя запроса, двухбайтовое значение ID идентификатора DNS-запроса и искомое имя и затем послать ложный DNS-ответ на извлеченный из DNS-запроса UDP-порт, в котором указать в качестве искомого IP-адреса настоящий IP-адрес ложного DNS-сервера. Это позволит в дальнейшем полностью перехватить трафик между атакуемым хостом и сервером и активно воздействовать на него по схеме "Ложный объект РВС" (п. 3.2.3.3).
Рассмотрим обобщенную схему работы ложного DNS-сервера (рис. 4.4):
Рис. 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 (транспортный).
