Отображение доменных имен на IP-адреса

ЛЕКЦИЯ1

I. Отображение доменных имен на IP-адреса

Организация доменов и доменных имен

Для идентификации компьютеров аппаратное и программное обеспечение в сетях TCP/IP полагается на IP-адреса, поэтому для доступа к сетевому ресурсу в пара- метрах программы вполне достаточно указать IP-адрес, чтобы программа правильно поняла, к какому хосту ей нужно обратиться. Например, команда ftp://192.45.66.17 будет устанавливать сеанс связи с нужным ftp-сервером, а команда http://203.23.106.33 откроет начальную страницу на корпоративном Web-сервере. Однако пользователи обычно предпочитают работать с символьными именами компьютеров, и операци­онные системы локальных сетей приучили их к этому удобному способу. Следова­тельно, в сетях TCP/IP должны существовать символьные имена хостов и механизм для установления соответствия между символьными именами и IP-адресами.

В операционных системах, которые первоначально разрабатывались для рабо­ты в локальных сетях, таких как Novell NetWare, Microsoft Windows или IBM OS/2, пользователи всегда работали с символьными именами компьютеров. Так как ло­кальные сети состояли из небольшого числа компьютеров, то использовались так называемые плоские имена, состоящие из последовательности символов, не разде­ленных на части; Примерами таких имен являются: NW1_1, mail2, MOSCOW_SALES_2. Для установления соответствия между символьными именами и МАС-адресами в этих операционных системах применялся механизм широковещательных запро­сов, подобный механизму запросов протокола ARP. Так, широковещательный спо­соб разрешения имен реализован в протоколе NetBIOS, на котором были построены многие локальные ОС. Так называемые NetBIOS-имена стали на долгие годы од­ним из основных типов плоских имен в локальных сетях.

Для стека TCP/IP, рассчитанного в общем случае на работу в больших террито­риально распределенных сетях, подобный подход оказывается неэффективным по нескольким причинам.

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

Широковещательный способ установления соответствия между символьными именами и локальными адресами хорошо работает только в небольшой локальной сети, не разделенной на подсети. В крупных сетях, где общая широковещательность не поддерживается, нужен другой способ разрешения символьных имен. Обычно хорошей альтернативой широковещательности является применение центра­лизованной службы, поддерживающей соответствие между различными типами адресов всех компьютеров сети". Компания Microsoft для своей корпоративной операционной системы Windows NT разработала централизованную службу WINS, которая поддерживает базу данных NetBIOS-имен и соответствующих им IP-адресов.

Для эффективной организации именования компьютеров в больших сетях есте­ственным является применение иерархических составных имен.

В стеке TCP/IP применяется доменная система имен, которая имеет иерархи­ческую древовидную структуру, допускающую использование в имени произвольного количества составных частей (рис. 5.11).

Иерархия доменных имен аналогична иерархии имен файлов, принятой во мно­гих популярных файловых системах. Дерево имен начинается с корня, обозначае­мого здесь точкой (.). Затем следует старшая символьная часть имени, вторая по старшинству символьная часть имени и т. д. Младшая часть имени соответствует конечному узлу сети. В отличие от имен файлов, при записи которых сначала указывается самая старшая составляющая, затем составляющая более низкого уровня и т. д., запись доменного имени начинается с самой младшей составляющей, а за­канчивается самой старшей. Составные части доменного имени отделяется друг от друга точкой. Например, в имени partnering.microsoft.com составляющая partnering является именем одного из компьютеров в домене microsoft.com.

Разделение имени на части позволяет разделить административную ответствен­ность за назначение уникальных имен между различными людьми или организа­циями в пределах своего уровня иерархии. Так, для примера, приведенного на рис. 5.11, один человек может нести ответственность за то, чтобы всё имена, кото­рые имеют окончание «щ>>, имели уникальную следующую вниз по иерархии часть. Если этот человек справляется со своими обязанностями, то все имена типа www.ru, mail.mmt.ru или m2.zil.mmt.ru будут отличаться второй по старшинству частью.

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

Совокупность имен, у которых несколько старших составных частей совпадают, образуют домен имен (domain). Например, имена wwwl.zil.mmt.ru, ftp.zil.mmt.ru, yandex.ru и sl.mgu.ru входят в домен ш, так как все эти имена имеют одну общую старшую часть — имя ш. Другим примером является домен mgu.ru. Из представленных

на рис. 5.11 имен в него входят имена sl.mgu.ru, s2.mgu.ru и rn.mgu.ru. Этот домен образуют имена, у которых две старшие части всегда равны mgu.ru. Имя www.mmt.ru в домен mgu.ru не входит, так как имеет отличающуюся составляющую mmt.

ВНИМАНИЕТермин «домен» очень многозначен, поэтому его нужно трактовать в рамках определенного контекста. Кроме доменов имен стека TCP/IP в компьютерной литературе также часто упоминаются домены Windows NT, •домены коллизий и некоторые другие. Общим у всех этих терминов является то, что они описывают некото­рое множество компьютеров, обладающее каким-либо определенным свойством.

Если один домен входит в другой домен как его составная часть, то такой домен могут называть поддоменом (subdomain), хотя название домен за ним также остает­ся. Обычно поддомен называют по имени той его старшей составляющей, которая отличает его от других поддоменов. Например, поддомен mmt.ru обычно называют поддоменом (или доменом) mmt. Имя поддомену назначает администратор выше­стоящего домена. Хорошей аналогией домена является каталог файловой системы.

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

По аналогии с файловой системой, в доменной системе имен различают крат­кие имена, относительные имена и полные доменные имена. Краткое имя — это имя конечного узла сети: хоста или порта маршрутизатора. Краткое имя — это лист дерева имен. Относительное имя — это составное имя, начинающееся с некоторого уровня иерархии, но не самого верхнего. Например, wwwl.zil — это относительное имя. Полное доменное имя (fully qualified domain name, FQDN) включает составля­ющие всех уровней иерархии, начиная от краткого имени и кончая корневой точ­кой: wwwl.zil.mmt.ru.

Необходимо подчеркнуть, что компьютеры входят в домен в соответствии со своими составными именами, при этом они могут иметь совершенно различные IP-адреса, принадлежащие к различным сетям и подсетям. Например, в домен mgu.ru могут входить хосты с адресами 132.13.34.15, 201.22.100.33, 14.0.0.6. Доменная си­стема имен реализована в сети Internet, но она может работать и как автономная система имен в крупной корпоративной сети, использующей стек TCP/IP, но не связанной с Internet.

В Internet корневой домен управляется центром InterNIC. Домены верхнего уровня назначаются для каждой страны, а также на организационной основе. Име­на этих доменов должны следовать международному стандарту ISO 3166. Для обо­значения стран используются трехбуквенные и двухбуквенные аббревиатуры, а для различных типов организаций — следующие обозначения:

• com — коммерческие организации (например, microsoft.com); ..

• edu — образовательные (например, mit.edu);

• gov — правительственные организации (например, nsf.gov);

• org — некоммерческие организации (например, fidonet.org);

• net — организации, поддерживающие сети (например, nsf.net).

Каждый домен администрируется отдельной организацией, которая обычно разбивает свой домен на поддомены и передает функции администрирования этих поддоменов другим организациям. Чтобы получить доменное имя, необходимо за­регистрироваться в какой-либо организации, которой InterNIC делегировал свои полномочия по распределению имен доменов. В России такой организацией явля­ется РосНИИРОС, которая отвечает за делегирование имен поддоменов в домене

Система доменных имен DNS

Соответствие между доменными именами и IP-адресами может устанавливаться как средствами локального хоста, так и средствами централизованной службы. На раннем этапе развития Internet на каждом хосте вручную создавался текстовый файл с известным именем hosts. Этот файл состоял из некоторого количества строк, каждая из которых содержала одну пару «IP-адрес — доменное имя», например 102.54.94.97 — rhino.acme.com.

По мере роста Internet файлы hosts также росли, и создание масштабируемого решения для разрешения имен стало необходимостью.

Таким решением стала специальная служба — система доменных имен (Domain .Name System, DNS). DNS — это централизованная служба, основанная на распределен­ной базе отображений «доменное имя — IP-адрес». Служба DNS использует в своей работе протокол типа «клиент-сервер». В нем определены DNS-серверы и DNS-клиенты. DNS-серверы поддерживают распределенную базу отображений, а DNS-клиенты обращаются к серверам с запросами о разрешении доменного имени в IP-адрес.

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

Для каждого домена имен создается свой DNS-сервер. Этот сервер может хра­нить отображения «доменное имя — IP-адрес» для всего домена, включая все его поддомены. Однако при этом решение оказывается плохо масштабируемым, так как при добавлении новых поддоменов нагрузка на этот сервер может превысить - его возможности. Чаще сервер домена хранит только имена, которые заканчиваются на следующем ниже уровне иерархии по сравнению с именем домена. (Аналогично каталогу файловой системы, который содержит записи о файлах и подкаталогах, непосредственно в него «входящих».) Именно при такой организации службы DNS нагрузка по разрешению имен распределяется более-менее равномерно между всеми DNS-серверами сети. Например, в первом случае DNS-сервер домена mmt.ru будет хранить отображения для всех имен, заканчивающихся на mmt.ru: wwwl.zil.mmt.ru, ftp.zil.mmt.ru, mail.mmt.ru и т. д. Во втором случае этот сервер хранит отображения только имен типа mail.mmt.ru, www.mmt.ru, а все остальные отображения должны храниться на DNS-сервере поддомена zil.

Каждый DNS-сервер кроме таблицы отображений имен содержит ссылки на DNS-серверы своих поддоменов. Эти ссылки связывают отдельные DNS-серверы в единую службу DNS. Ссылки представляют собой IP-адреса соответствующих сер­веров. Для обслуживания корневого домена выделено несколько дублирующих друг друга DNS-серверов, IP-адреса которых являются широко известными (их можно узнать, например, в InterNIC).

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

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

Существуют две основные схемы разрешения DNS-имен. В первом варианте работу по поиску IP-адреса координирует DNS-клиент:

• DNS-клиент обращается к корневому DNS-серверу с указанием полного домен­
ного имени;

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

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

Такая схема взаимодействия называется нерекурсивной или итеративной, когда клиент сам итеративно выполняет последовательность запросов к разным серве­рам имен. Так как эта схема загружает клиента достаточно сложной работой, то она применяется редко.

Во втором варианте реализуется рекурсивная процедура: .

• DNS-клиент запрашивает локальный DNS-сервер, то есть тот сервер, который

обслуживает поддомен, к которому принадлежит имя клиента;

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

• если же локальный сервер не знает ответ, то он выполняет итеративные запросы
к корневому серверу и т. д. точно так же, как это делал клиент в первом вариан­
те; получив ответ, он передает его клиенту, который все это время просто ждал
его от своего локального DNS-сервера.

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

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

УЯЗВИМЫЕ МЕСТА ЗАЩИТЫ DNS

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

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

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

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

Во-первых, по умолчанию служба DNS функционирует на базе протокола UDP (хотя возможно и использование протокола TCP) что, естественно, делает ее… Во-вторых, следующая тонкость, на которую требуется обратить внимание, состоит… В-третьих, значение идентификатора (ID) 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 (транспортный).

Внедрение в сеть Internet ложного сервера путем создания направленного "шторма" ложных DNS -ответов на атакуемый хост

В данном случае, так как атакующий не имеет возможности перехватить DNS -запрос, то основную проблему для него представляет номер UDP-порта, с…

Рис. 4.5. Внедрение в Internet ложного сервера путем создания направленного "шторма" ложных DNS -ответов на атакуемый хост.

Рис. 4.5.1. Атакующий создает направленный "шторм" ложных DNS -ответов на Хост 1.

Рис. 4.5.2. Хост 1 посылает DNS -запрос и немедленно получает ложный DNS -ответ.

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

Поэтому для осуществления данной удаленной атаки атакующему необходимо выбрать интересующий его хост (например, top.secret.com), маршрут к которому требуется изменить так, чтобы он проходил через ложный сервер - хост атакующего. Это достигается постоянной передачей (направленным "штормом" ) атакующим ложных DNS -ответов на атакуемый хост от имени настоящего DNS -сервера на соответствующие UDP-порты. В этих ложных DNS -ответах указывается в качестве IP-адреса хоста top.secret.com IP-адрес атакующего. Далее атака развивается по следующей схеме. Как только цель атаки (атакуемый хост) обратится по имени к хосту top.secret.com, то от данного хоста в сеть будет передан DNS -запрос, который атакующий никогда не получит, но этого ему и не требуется, так как на хост сразу же поступит постоянно передаваемый ложный DNS -ответ, что и будет воспринят ОС атакуемого хоста как настоящий ответ от DNS -сервера. Все! Атака состоялась, и теперь атакуемый хост будет передавать все пакеты, предназначенные для top.secret.com, на IP-адрес хоста атакующего, который, в свою очередь, будет переправлять их на top.secret.com, воздействуя на перехваченную информацию по схеме "Ложный объект РВС" (п. 3.2.3.3).

Рассмотрим функциональную схему предложенной удаленной атаки на службу DNS (рис. 4.5):

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

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

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

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

Внедрение в сеть Internet ложного сервера путем перехвата DNS -запроса или создания направленного "шторма" ложных DNS -ответов на атакуемый DNS -сервер

Из рассмотренной в п. 4.3 схемы удаленного DNS -поиска следует, что в том случае, если указанное в запросе имя DNS -сервер не обнаружил в своей базе имен, то запрос отсылается сервером на один из корневых DNS -серверов, адреса которых содержатся в файле настроек сервера root.cache.

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

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

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

Очевидно, что в том случае, если атакующий не может перехватить DNS -запрос от DNS -сервера, то для реализации атаки ему необходим "шторм" ложных DNS -ответов, направленный на DNS -сервер. При этом возникает следующая проблема, отличная от проблемы подбора портов в случае атаки, направленной на хост. Как уже отмечалось ранее, DNS -сервер, посылая запрос на другой DNS -сервер, идентифицирует этот запрос двухбайтовым значением (ID). Это значение увеличивается на единицу с каждым передаваемым запросом. Узнать атакующему это текущее значение идентификатора DNS -запроса не представляется возможным. Поэтому предложить что-либо, кроме перебора 216 возможных значений ID, достаточно сложно. Зато исчезает проблема перебора портов, так как все DNS -запросы передаются DNS -сервером на 53 порт.

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

Для примера вспомним недавний скандал (28 октября 1996 года) с одним из московских провайдеров Internet - компанией РОСНЕТ, когда пользователи данного провайдера при обращении к обычному информационному WWW-серверу попадали, как было сказано в телевизионном репортаже, WWW-сервер "сомнительного" содержания (наверное, www.playboy.com). В связи с абсолютным непониманием случившегося как журналистами (их можно понять - они не специалисты в этом вопросе), так и теми, кто проводил пресс-конференцию (специалистов к общению с прессой, наверное, просто не допустили) информационные сообщения о данном событии были настолько убоги, что понять, что случилось, было толком невозможно. Тем не менее, этот инцидент вполне укладывается в только что описанную схему удаленной атаки на DNS -сервер. С одним исключением: вместо адреса хоста атакующего в кэш-таблицу DNS -сервера был занесен IP-адрес хоста www.playboy.com.

Однако, видимо, большинство российских кракеров еще не доросли до столь утонченных методов сетевого взлома, как атака на DNS или любая другая атака из данной главы. После того, как был написан предыдущий абзац, нам довелось ознакомиться с интервью, которое якобы дал кракер, осуществивший этот взлом. Из него следовало, что атака использовала одну из известных "дыр" в WWW-сервере РОСНЕТа. Это и позволило атакующему подменить одну ссылку на другую. Осуществление атак такого типа является по сути тривиальным и не требует от взломщика практически никакой квалификации (подчеркнем - именно осуществление; совершенно другое дело - нахождение этой "дыры" ). Высокая квалификация необходима именно для поиска той самой уязвимости, используя которую можно взломать систему. Но, по глубокому убеждению авторов, обнаруживший уязвимость и осуществивший на ее базе взлом, скорее всего будутразными лицами, так как именно высокая квалификация специалиста, обнаружившего "дыру" , не позволит ему причинить ущерб простым пользователям. (Р. Т. Моррис не был исключением. Просто его червь из-за ошибки в коде вышел из-под контроля, и поэтому пользователям сети был нанесен определенный ущерб.)

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

 

Рис. 4.6.1.1. Фаза ожидания атакующим DNS -запроса от DNS -сервера (для ускорения атакующий генерирует необходимый DNS -запрос).

 

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

Рис. 4.6.2. Внедрение в Internet ложного сервера путем создания направленного "шторма" ложных DNS -ответов на атакуемый DNS -сервер.

Рис. 4.6.2.1. Атакующий создает направленный "шторм" ложных DNS -ответов от имени одного из корневых DNS -серверов и при этом провоцирует атакуемый DNS -сервер, посылая DNS -запрос.

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

В завершение хотелось бы снова вернуться к службе DNS и сказать, что, как следует из предыдущих пунктов, использование в сети Internet службы удаленного поиска DNS позволяет атакующему организовать в Internet удаленную атаку на любой хост, пользующийся услугами данной службы, и может пробить серьезную брешь в безопасности этой и так отнюдь не безопасной глобальной сети. Напомню, что, как указывал S. M. Bellovin в ставшей почти классической работе [14]: "A combined attack on the domain system and the routing mechanisms can be catastrophic"("Комбинация атаки на доменную систему и механизмы маршрутизации может привести к катастрофе" ).

 

КРИПТОГРАФИЧЕСКИЕ ПОДПИСИ

Цель DNSSEC - обеспечить аутентификацию и целостность информации, содержащейся в DNS (см. Рисунок 2). DNSSEC позволяет достигнуть обеих целей… Рисунок 2. Два примера ответов и запросов DNS с DNSSEC и без оных. Обратите внимание, что в ответе с DNSSEC ответное…

НОВЫЕ ЗАПИСИ РЕСУРСОВ

KEY RR содержит открытый ключ, принадлежащий имени домена, указанному в KEY RR. Это не сертификат открытого ключа. Механизм обеспечения возможностей… SIG RR содержит преимущественно криптографическую подпись, дату окончания… Другим аспектом DNSSEC является подпись транзакции (Transaction Signature, TSIG). TSIG отличается от других подписей…

ПОДПИСИ ТРАНЗАКЦИЙ

TSIG особенно полезен в случае транзакций DNS UPDATE. Большинство транзакций DNS представляет собой запросы относительно наличия данных. Транзакция… Вследствие того, что обновление DNS осуществляется обычно по UDP, а запрос UDP…

НЕДОСТАТКИ DNSSEC

Кроме того, реализация DNSSEC сопровождается и другими, не столь очевидными затратами. Новое программное обеспечение больше по объему и сложнее, чем… Вывод отсюда следующий: развертывание DNSSEC чревато столькими же опасностями,… На декабрь 1999 года TSIG полностью и DNSSEC частично были реализованы только в BIND 8.2. Другие разработчики (включая…

РАБОТА ПРОДОЛЖАЕТСЯ

Наконец, это вопрос защиты личного ключа корня. Этот ключ будет по сути ключом ко всей коммерции Internet в мировом масштабе, но администрация… Должны ли Соединенные Штаты продолжать администрировать это всемирное средство… Верно, конечно, что работа над DNSSEC еще не завершена. Однако любая организация, активно использующая Internet,…

Защита серверов DNS без помощи DNSSEC

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

Ресурсы Internet

Collaborative Advanced Interagency Research Network (CAIRN) представляет собой тестовую сеть, спонсируемую Defense Advanced Research Projects Agency… Более подробную информацию о DNSSEC и других вопросах защиты можно найти на…