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

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

■ На DNS-серверах хранится большой объем полезной информации о хостах локальной сети. Эта информация пригодится хакеру при подготовке к проведению атаки избранной сети.

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

■ DNS-серверы предоставляют свои услуги всем желающим и хранят совместно используемую информацию. Устройства фильтрации пакетов часто пропускают любой трафик на стандартный порт службы DNS (UDP-порт 53) с целью обеспечения нормальной работы внутренних серверов имен.

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

Теория DNS

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

В этом разделе исследуется структура службы DNS как распределенной системы и процесс преобразования имен хостов в их IP-адреса. Кроме того, обсуждаются роли первичных и вторичных DNS-серверов и методы взаимодействия между ними. Вы узнаете, что, в отличие от других служб, DNS может использовать протокол TCP или UDP в зависимости от типа выполняемой операции.

Структура DNS

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

Рис. 6.1. Иерархия DNS

Логически высшей точкой иерархии DNS является корень (root), который обозначается символом (точка). С функциональной точки зрения на вершине иерархии службы DNS работают корневые серверы (root servers), которые служат исходным пунктом для определения соответствий между именами хостов и IP-адресами. Эти серверы только указывают на другие DNS-серверы, которые могут хранить ответы на получаемые DNS-запросы. Домены верхнего уровня, расположенные непосредственно ниже корневых серверов, наверняка знакомы нашим читателям (давно известные . edu, . org, .com, .net, .mil и . gov и недавно добавленные .aero, .biz, .coop, .info, .museum, .name и .pro). Существуют также дополнительные домены верхнего уровня, указывающие на принадлежность какому-либо государству, например домен . j р для Японии.

Путешествие по Internet

Предположим, что вы хотите зайти на сайт www. sans . org - домашнюю страничку института SANS. Для этого в окне Address (Адрес) броузера нужно ввести http : //www. sans . org, и секундой позже должна открыться запрошенная Web-страничка.

Теперь вспомним, что в IP-дейтаграммах в качестве адресов получателя и отправителя используются IP-адреса. Протокол IP не работает с доменными именами хостов. Человеку проще запомнить, что столицей штата Флорида является город Таллахасси, чем значение числа к с девятью знаками после запятой (3,141592654), хотя оба эти выражения содержат по 10 символов. Имена и названия более благозвучны и менее случайны, чем числа, поэтому и запомнить их проще. Вот почему для обращения к Web-страничке используются имена хостов, а не их IP-адреса. Совершенно ясно, что необходим механизм для преобразования указанных имен хостов в используемые в стеке TCP/IP соответствующие IP-адреса этих хостов.

Как же происходит это загадочное преобразование имени www. sans . org в IP-адрес? Еще до отправки информационного запроса на сайт www. sans .org клиент должен знать его IP-адрес. Этот адрес нужен для поля IP-дейтаграммы, которая используется в качестве запроса на соединение. В следующем разделе этот “туманный” процесс рассмотрен подробнее.

Рекурсивные и итеративные запросы

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

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

Преобразование имени хоста в 1Р-адрес

Рассмотрим процесс определения IP-адреса для доменного имени хоста (www. sans . org) с самого начала (рис. 6.2).

Хост host.my.com, на котором работает броузер, должен определить 1Р-адрес хоста www. sans . org. Если первый хост не является сервером имен, то в этом процессе он не принимает активного участия. Он только выдает запрос на преобразование и после получения IP-адреса продолжает процесс установки соединения со страницей www. sans . org. Всю работу по преобразованию доменного имени в IP-адрес выполняет запрошенный DNS-сервер (в данном случае dns . my. com). Обычно имя DNS-сервера по умолчанию выбирается при установке операционной системы на конкретном хосте. В UNIX-системах эта информация хранится в файле /etc/resolv. conf. В Windows-системах DNS-сервер по умолчанию определяется в окне свойств протокола TCP/IP в разделе Сеть (Network) окна Панель управления (Control Panel). Как правило, этот DSN-сервер по умолчанию управляется локально и расположен в пределах внутренней сети организации. Б данном случае хост dns . my. com - это локальный DNS-сервер сетевого узла.

Рис. 6.2. Запрос клиента к DNS-cepeepy

Такие приложения TCP/IP, как telnet, FTP, Netscape или Internet Explorer, на стороне клиента для преобразования доменных имен в IP-адреса вызывают библиотечные подпрограммы “распознавателя” (resolver). Б данном случае поиск 1Р-адреса для имени хоста выполняется при запросе приложением Web-страницы www. sans . org. Запрос gethostbyname на преобразование имени www. sans . org в соответствующий IP-адрес передается от хоста host. my. com на DNS-сервер. DNS-сервер получает этот запрос, обрабатывает его и возвращает ответ клиенту.

На рис. 6.3 показана вторая часть процесса определения IP-адреса. Ранее DNS-сервер dns . my. com получил задачу' узнать IP-адрес хоста по имени www. sans . org. Для сокращения теоретического материала (хотя такое упрощение может усложнить действительный процесс определения IP-адреса) предположим, что dns . my. com не обладает сведениями ни о www. sans . org, ни о каком-либо еще хосте домена . org. Поэтому dns . my. com начинает поиск IP-адреса с запроса к корневому серверу DNS.

Рис. 6.3. DNS-cepeep запрашивает неизвестный 1Р-адрес

Если DNS-сервер должен определить неизвестный IP-адрес по имени хоста, и он не обладает сведениями о домене интересующего хоста, он должен обратиться к корневому серверу имен. На корневых серверах имен хранятся соответствия между доменными именами (например sans . org) и адресами уполномоченных серверов имен - DNS-серверов, которые хранят записи DNS для этих доменов. Когда локальный сервер имен (dns .my. com) запрашивает корневой сервер имен IP-адрес хоста www. sans .org, последний возвращает ссылку на сервер имен домена sans. org.

А откуда локальный сервер имен знает имена и IP-адреса корневых серверов имен, к которым он может обращаться? Очевидно, что список этих корневых серверов имен должен быть предварительно сохранен в памяти локального DNS-сервера. Эта информация предоставляется центром InterNIC и ее можно получить по адресу f tp ://ftp.rs.internic.net/domain/named.ca.

Итак, корневой сервер имен предоставил локальному DNS-серверу ссылку на сервер server 1. sans . org как на уполномоченный сервер имен домена www. sans . org. На последнем этапе определения искомого IP-адреса dns . my. com отправляет запрос серверу serverl. sans. org и получает ответ, что IP-адрес интересующего хоста 12.33.247.6 (рис. 6.4).

Рис. 6.4. Определение искомого 1Рмдреса, информация из первых рук

Отчет TCPdump о процессе преобразования

С помощью TCPdump можно исследовать трафик, вызванный исходным DNS-запросом.

host.my.com.1716 > dns.my.com.53 : 1+ (35)

dns.my.com.53 > h.root - servers.net.53 : 12420 (30) (DF) h. root-servers.net.53 > dns.my.com.53 : 12420- 0/3/3 (153) (DF) dns.my.com.53 > serverl.sans.org.53 : 12421+ (30) (DF) serverl.sans.org.53 > dns.my.com.53 : 12421* 1/3/3 (172)

dns.my.com.53 > host.my.com.1716 : 1* 1/3/3 (197) (DF)

Сначала host. my. com (операции обмена данными с host. my. com выделены жирным шрифтом) отправляет DNS-серверу dns . my. com запрос на определение IP-адреса хоста www.sans.org. Программа TCPdump анализирует DNS-трафик на уровне приложений, поэтому слово udp, указывающее на применение протокола UDP, не появляется в записях отчета. Протокол UDP используется в подавляющем большинстве операций службы DNS, так как запросы и ответы этой службы обычно коротки, и допускается потеря данных. Если запрошенные данные не поступают, выдается новый DNS-запрос.

Затем dns.my.com устанавливает соединение с портом 53 сервера h. root-servers .net (обратите внимание на то, что и отправитель и получатель используют порты 53). Корневой сервер имен отвечает на тот же 53 порт dns.my.com.

Подробное описание номеров и обозначений, используемых в конце каждой записи TCPdump приведено в разделе “Незнакомые обозначения TCPdump”. Сервер не может самостоятельно ответить на запрос. Он возвращает ссылку на другой DNS-сервер, который либо сможет ответить сам, либо предоставит ссылку на следующий DNS-сервер. Поиск IP-адреса для www. sans .org представляет собой итеративный процесс, при котором происходит обращение к различным DNS-серверам. Этот процесс продолжается до установки соединения с сервером имен, хранящим нужный 1Р-адрес.

Согласно полученной ссылке dns.my.com обращается с запросом к другому DNS-серверу - serverl.sans.org. Этот DXS-ceprsep хранит нужный 1Р-адрес, соответствующий имени хоста www. sans . org, который он и возвращает серверу dns . my. com. И, наконец, локальный DNS-сервер dns . my. com передает полученный ответ клиенту host. my. com.

Результаты работы TCPdump выводятся в уникальном формате, который позволяет проанализировать действия при DNS-соединениях. Следующий раздел поможет понять все подробности этих отчетов TCPdump.

Незнакомые обозначения. TCPdump

Рассмотрим подробнее отчет об обмене информацией между хостами dns.my.com и h.root - servers.net.

dns.my.com.53 > h.root-servers.net.53 : 12420 (30) (DF) h.root-servers.net.53 > dns.my.com.53 : 12420- 0/3/3 (153) (DF)

Первая строка - это запрос от dns .my. com к корневому серверу имен. Первое поле, которое не встречалось в стандартных отчетах TCPdump, представляет собой номер 1242 0, указанный после номера порта 53 и двоеточия. Это уникальный идентификационный номер DNS, по которому клиент и сервер DNS определяют соответствующие запрос и ответ. Хост dns.my.com, скорее всего, одновременно генерирует множество различных запросов, поэтому необходим механизм для определения соответствия ответа и запроса. После этого в строке указывается, что длина полезных данных UDP-пакета (не считая заголовков IP или UDP) составляет 30 байт, а флаг DF установлен для запрещения фрагментации дейтаграммы.

Затем поступает ответ на запрос под номером 12420. Тире после числа 12420 означает, что рекурсия не требуется. Другими словами, сервер dns . my. com просит только передать ему ссылку на следующий в процессе поиска DNS-сервер, он не требует, чтобы корневой сервер имен проводил поиск самостоятельно.

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

В ответе корневого сервера имен содержится непонятная запись 0/3/3. Она означает, что записей ответа нет (т.е. нужного IP-адреса не найдено), были обнаружены три записи о полномочиях и три дополнительные записи. Уполномочен ный сервер хранит записи соответствий имен хостов и IP-адресов для хостов своего домена. Хотя в отчете TCPdump этого не показано, но в этих записях (0/3/3) предоставляются имена уполномоченных DNS-серверов, а также соответствующие 1Р-адреса.

Записи о полномочиях

sans.org nameserver = serverl. sans, org

sans.org nameserver = ns.BSDI.COM

sans.org nameserver = ns.DELOS.COM

Дополнительные записи

serverl.sans.org Internet address = 167.216.198.40

ns.BSDI.COM Internet address = 206.196.44.241

ns.DELOS.COM Internet address = 65.102.83.117

В разделе “Использование DNS в разведывательных целях” продемонстрировано, как получить эту информацию с помощью команды nslookup. Благодаря отправке в дополнительных записях IP-адресов уполномоченных серверов имен не требуется дополнительных запросов на преобразование имен этих DNS-серверов в их IP-адреса. Все эти серверы обладают полномочиями на домен sans. org и предоставляют ответы на запросы определения IP-адресов хостов этого домена. В нашем случае сервер dns . my. com выбрал из списка первый официальный DNS-сервер, serverl. sans . org.

В заключение рассмотрим последнюю часть отчета TCPdump о процессе определения 1Р-адреса.

dns.my.com.53 > serverl.sans.org.53 : 12421+ (30) (DF) serverl.sans.org.53 > dns.my.com.53 : 12421* 1/3/3 (172)

dns.my.com.53 > host.my.com.1716 : 1* 1/3/3 (197) (DF)

Таким образом, сервер dns .my.com был проинформирован о существовании нескольких уполномоченных DNS-серверов и для определения IP-адреса был выбран первый из них. Локальный сервер отправляет новый запрос под номером 12421. На этот раз запрос является рекурсивным (на что указывает знак плюс). По существу, dns.my.com ставит перед serverl.sans.org задачу найти нужный ему IP-адрес. В данном случае serverl. sans . org является официальным сервером для www. sans .org, поэтому он может самостоятельно ответить на запрос. В противном случае ему бы пришлось отправлять рекурсивные запросы другим DNS-серверам до тех пор, пока не был бы найден искомый IP-адрес. Не все DNS-серверы настроены на отправку рекурсивных запросов, поэтому даже при необходимости рекурсии она возможна не всегда.

DNS-сервер serverl.sans.org отвечает на запрос. Символ звездочки указывает на ответ, содержащий сведения из достоверного источника. В данном случае возвращается 1Р-адрес (12.33.247.6) хоста www.sans.org. IP-адрес не показан в отчете TCPdump, но он входит в состав полезной нагрузки UDP-пакета. Также возвращаются рассмотренные выше записи о полномочиях и дополнительные записи. Наконец, после получения сервером dns.my.com искомого IP-адреса, он возвращает его первоначальному источнику запроса - хосту host. my . com.

Кэширование

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

При повторном запросе Web-страницы www. sans . org через небольшой период времени процесс определения нужного IP-адреса будет несколько иным. Клиент по-прежнему будет отправлять запрос gethostbyname DNS-серверу dns .my. com. Однако этот сервер имен перед запросом к другим DNS-серверам проверяет свой кэш. Если прошло не слишком много времени, то dns . my. com находит нужную запись в кэше и возвращает IP-адрес хосту host. my. com.

Как долго кэшированные записи хранятся на DNS-сервере? Точного ответа нет. Каждая отдельная запись может иметь собственный срок хранения на сервере имен. Каждому ответу (записи DNS) присваивается значение времени жизни (TTL). Не путайте это значение со значением поля TTL в заголовках IP-дейтаграмм. Они выполняют абсолютно разные функции. Значение TTL устанавливается DNS-сервером, который отвечает на запрос и кэшируется сервером-получателем. На DNS-серверах, которые часто обновляют свои записи, устанавливаемые значения TTL, как правило, меньше, чем на DNS-серверах, информация которых относительно статична.

BIND

BIND (Berkeley Internet Name Domain) представляет собой де-факто стандартную реализацию службы DNS в современной сети Internet. Старыми версиями BIND являются 4.х.х, а более новые- 8-х.х и 9.Х.Х. Использование взаимодействующими DNS-серверами в качестве портов получателя и отправителя порта 53 указывает на стандартный режим работы версии BIND 4.x.х. По умолчанию в версиях BIND, начиная с 8.х.х, при отправке DNS-запросов используется один из временных портов (номер больше 1023), как это делается в других приложениях типа клиент-сервер, например telnet.

Тем не менее более поздние версии BIND могут быть настроены на стандартный метод работы версии 4.х.х с использованием порта отправителя 53. Для этого в конфигурационный файл добавляется строка query-source address * port 53. На некоторых узлах такая конфигурация считается более удобной для соответствия правилам доступа, установленным для брандмауэра или фильтрующего маршрутизатора.

Обратные запросы

Иногда необходимо обратное преобразование IP-адреса в доменное имя соответствующего хоста. Для этого распознаватель клиента выдает запрос gethostbyaddr.

Напомним, что DNS представляет собой распределенную иерархическую систему, вершиной которой является корень. Ниже корня располагаются домены верхнего уровня, например . org, .mil, . edu и др. С целью преобразования IP-адресов в имена хостов был зарезервирован специальный домен верхнего уровня, для указания на который используется суффикс агра. Уровень второго уровня этого же предназначения называется in-addr. Затем следуют байты IP-адреса. Эту иерархическую структуру можно представить в виде дерева (рис. 6.5). Пусть, например, значением первого байта нашего IP-адреса будет число 12. Затем выбирается следующее поддерево согласно значению второго байта IP-адреса хоста www. sans . org (3 3). По этой же схеме выполняется поиск следующих поддеревьев (узлы 24 7 и 6). В данном примере по IP-адресу мы находим имя только одного хоста, но сама древовидная структура охватывает все возможные IP-адреса подобно тому, как иерархия доменных имен позволяет указать доменное имя любого хоста.

Рис. 6.5. Обратный запрос. Определение имени хоста по IP-адресу

Определение имени хоста по его IP-адресу называют обратным запросом. При обратном запросе по 1Р-адресу 12.33.247.6 приложение преобразует этот запрос в форму 6.247.33.12. in-addr. агра. Порядок байтов изменяется, чтобы соблюдалось соответствие с принятым порядком записи доменных имен (когда домен высшего уровня указывается последним).

Первичные и вторичные серверы имен

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

Информация службы DNS хранится на первичном сервере в виде обычных текстовых файлов. Для получения обновлений вторичные серверы имен периодически связываются с первичным DNS-сервером. Если в базу данных DNS были внесены какие-либо изменения, то вторичные серверы, на которых установлены старые версии BIND, полностью копируют всю базу данных. В последних версиях

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

Перенос зоны

Рассмотрим механизм обновления информации зоны DNS на DNS вторичных серверах. Если при перезапуске или очередном запросе на обновление базы данных вторичного сервера будут обнаружены какие-либо изменения, то выполняется перенос зоны между первичным и вторичным DNS-сервером.

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

Очевидно, что возможность проведения подобных действий необходимо исключить. В программе BIND начиная с версии 4.9.3 администратор службы DNS имеет возможность указать IP-адреса хостов или подсетей, которым разрешается выполнять перенос зоны. Для контроля операций переноса зоны в BIND 4.9.x предусмотрена директива xf ernets, а в версиях BIND 8 и 9 - оператор allow-transfer.

Если ваша версия BIND не поддерживает этой возможности, то в качестве альтернативы можно использовать блокирование входящего трафика на ТСР-порт 53. Это блокирование не только позволяет предотвратить несанкционированные переносы зоны, но и блокирует все полезные операции. Если альтернативы нет, все же лучше блокировать переносы зоны, даже в ущерб другим возможностям.

UDP или TCP

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

Максимально допустимый размер UDP-пакета для службы DNS составляет 512 байт. Что произойдет если передаваемый пакет больше этого размера? Во-первых, будет отправлен ответ с установленным битом усечения данных. Этот бит находится в поле флагов сообщения DNS (2 и 3 байт от начала сообщения).

dns.my.com.53 > dns.verbose.com.53: 18033 (43) (DF)

dns.verbose.com.53 > dns.my.com.53: 18033 7/0/0 (494)

dns.my.com.37404 > dns.verbose.com.53: S 518696698:518696698(0) win 8760 <mss 1460> (DF)

dns.verbose.com.53 > dns.my.com.37404: S 199578733:199578733(0) ack 518696699 win 8760 cmss 1460> (DF)

В приведенном выше отчете TCPdump обратите особое внимание на вторую строку (ответ dns . verbose . com. 53 хосту dns . my. com). После идентификатора сообщения DNS (18 033) следует вертикальная черта - символ конвейеризации UNIX. Это предупреждение TCPdump о том, что запись DNS была урезана. Дан ный ответ, содержащий семь DNS-записей, превысил максимально допустимый размер пакета (512 байт). Как мы видим, в ответе содержалось 494 байт полезных данных, что превышает максимально допустимый размер данных в 484 байт (20 байт требуются для заголовка IP-дейтаграммы, и еще 8 - для заголовка UDP-пакета). По этой причине dns.my.com отправляет повторный DNS-запрос, используя протокол TCP. Сначала серверу dns.verbose.com отправляется SYN-запрос на установление соединения. В ответ поступает пакет с установленными флагами SYN и АСК, что свидетельствует о готовности принять запрос на ТСР-порт 53. Затем необходимая информация передается с помощью ТСР-пакетов.

Если с целью запрещения несанкционированных переносов зоны блокировать все входящие пакеты, в которых указан ТСР-порт 53 отправителя или получателя, то автоматически удаленные DNS-серверы не смогут получать ответов большой длины. Именно это и происходит в нашем примере. Ответный пакет с установленными флагами SYN и АСК будет заблокирован (четвертая строка отчета). Наше устройство фильтрации пакетов, установленное перед хостом dns .verbose . com, блокирует TCP-соединение, для которого указан порт отправителя domain (53). Таким образом, эта процедура установки соединения не будет завершена, и DNS-ответ доставлен не будет. Поэтому лучше блокировать прохождение только тех пакетов, в которых указан ТСР-порт получателя 53, и разрешать их поступление с порта отправителя 53 при установленном соединении.

Использование DNS в разведывательных целях

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

Команда nslookup

Работа утилиты nslookup аналогична действиям клиента службы DNS, с той разницей, что вся информация выводится на экран. С помощью команды nslookup и были получены имена и IP-адреса уполномоченных DNS-серверов домена sans.org. Утилита nslookup является очень полезным интерактивным средством, которое может использоваться на хостах под управлением UNIX и Windows NT (и следующих сетевых версиях Windows). В некоторых версиях операционной системы UNIX вместо команды nslookup применяется команда dig.

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

Рассмотрим возможности nslookup на следующем примере. Команда nslookup была вызвана на хосте host .my. com. Запускается механизм взаимодействия и принимается сообщение о DNS-сервере по умолчанию (dns. my. com) и его IP-адрес (192.168.4.4), которые будут использоваться при обработке запросов.

host.my.com% nslookup Default Server: dns.my.com Address: 192.168.4.4

> www.sans.org Server: dns.my.com Address: 192.168.4.4

Name: www.sans.org

Address: 12.33.247.6

После символа приглашения (>) вводится имя хоста, IP-адрес которого требуется найти. Еще раз повторяются имя и 1Р-адрес DNS-сервера, использующегося для обработки запроса. Ответом является 1Р-адрес 12.33.247.6.

Доменное имя DNS-сервера

Как можно определить DNS-сервер какого-либо домена? Используя nslookup, сделать это довольно просто.

> set type=ns

> sans.org

Server: dns.my.com Address: 192.168.4.4

Non-authoritative answer sans.org nameserver = NS.DELOS.COM

sans.org nameserver = serverl.sans.org

sans.org nameserver = NS.BSDI.COM

Authoritative answers can be found from NS.DELOS.COM Internet address = 65.102.83.117

serverl.sans.org Internet address = 167.216.198.40

NS.BSDI.COM Internet address = 206.196.44.241

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

HINFO

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

Из-за того, что записи HINFO предоставляют слишком много полезной информации неизвестным пользователям Internet, многие администраторы в целях безопасности вообще не заносят в них никакой информации.

> set type=hinfo

> host49

Server: dns.my.com Address: 192.168.4.4

host.49.my.com CPU = SunSparc OS = Solaris

my.com nameserver = dns.my.com

dns.my.com Internet address = 192.68.4.4

Для запроса информации записей HINFO после ввода команды nslookup укажите тип запросов set type=hinfo. В данном случае запрашивается информация относительно хоста host4 9 (здесь указан псевдоним реального хоста). Как мы видим, на хосте host4 9 . my. com используется процессор SunSparc и работает он под управлением операционной системы Solaris. Возможно, что все усилия хакера будут тщетны по той причине, что информация записей HINFO просто устарела. Это, пожалуй, один из немногих случаев, когда несвоевременное обслуживание имеет положительный эффект.

Доступ к информации о домене

Одним из самых простых способов для получения информации о хостах домена является запрос на вывод списка всех хостов домена. Предположим, что существует домен fakeplace. com. После ввода команды nslookup с помощью следующей подкоманды 1 s можно попытаться получить все записи DNS об этом домене.

> Is -d fakeplace.com

Если на узле сети Internet не запрещено распространение информации, то в ответ на эту команду DNS-сервер предоставит все записи для домена fakeplace.com. В данном случае заинтересованное лицо дополнительно получит информацию записей HINFO.

Whish 1D IN HINFO "SGI" "Irix"

1D IN A 192.168.1.239

susie 1D IN HINFO "IBM-RS/560F" "Unix"

1D IN A 172.16.16.13

pixie 1D IN HINFO "IBM-RS/560F" "unix"

1D IN A 172.12.16.14

bandit 1D IN HINFO "PC" "Win98"

1D IN A 192.168.3.107

adder 1D IN HINFO "IBM-RS/530" "unix"

1D IN A 172.16.133.4

hub21 1D IN HINFO "Cabletron-MMAC3" "SNMP"

1D IN A 192.168.26.80

switch3 1D IN HINFO "Switch" "3COM"

1D IN A 192.168.7.130

Получение этой информации возможно только в том случае, если разрешается беспрепятственное прохождение пакетов к ТСР-порту 53.

Утилита dig

Еще одним способом сбора информации является запрос к DNS-серверу об используемой им версии BIND.

dns.my.com% dig @MYDNS.COM version.bind txt chaos

; <<>> dig 8.1 <<>> @MYDNS.COM version.bind txt chaos ; (1 server found)

;; res options: init recurs defnam dnsrch ;; got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0,

ADDITIONAL: 0 ;; QUERY SECTION:

; ; ' version.bind, type = TXT, class = CHAOS

; ; ANSWER SECTION:

VERSION.BIND OS CHAOS TXT "4.9.7-REL"

Утилита dig входит в состав многих версий BIND. Ее возможности практически аналогичны возможностям nslookup. С помощью специального параметра командной строки можно узнать версию BIND, запущенную на удаленном DNS-сервере. Формат этой команды выгладит следующим образом.

dig@<MMn_DNS-cepBepa> version.bind txt chaos

Здесь слово txt обозначает запрос из базы данных DNS-сервера информации записей TXT. Завершает запрос слово chaos - практически устаревший тип запросов.

В нашем случае с помощью команды dig была получена версия BIND хоста mydns . com. На этом хосте запущена устаревшая версия BIND 4.9.7, т.е. полученная информация окажется для хакера весьма полезной, и он сможет подобрать подходящую атаку для уязвимой версии BIND. Начиная с версии BIND 8.2 в конфигурационный файл /etc/named, conf включен оператор options, с помощью которого можно определить сообщение, выдаваемое в ответ на запрос номера версии. Можно ввести сообщение, подобное “unknown version of BIND” (“неизвестная версия BIND”). Также можно обмануть нарушителей, указав неправильную версию BIND.

Опасные ответы DNS

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

Слабое звено

Одним из недостатков использования имен хостов при разрешении или запрещении доступа к той или иной службе является то, что если хакеру удастся подменить имя чужого хоста, то вся система аутентификации окажется бесполезной. Это касается аутентификации как по именам хостов, так и по полным доменным именам. Разрешается ли в вашей локальной сети доступ к Web-cepBepy всем хостам ва шего домена? Или в вашей сети работают UNIX-хосты, доступ к которым осуществляется без проверки имени и пароля пользователя, только на основе имени доверенного хоста? Такой метод аутентификации может быть очень рискованным, если хакеру удастся проводить свои действия от имени доверенного хоста. Имя хоста можно подменить на самом хосте, на скомпрометированном DNS-сервере или на DNS-сервере, на котором временно подменена запись в кэше.

В BIND начиная с версии 8.3 встроена поддержка протокола DNSSEC (DNS Security Extensions - расширения безопасности DNS), который обеспечивает основанный на криптографических сигнатурах механизм аутентификации DNS-хостов и позволяет гарантировать целостность и подлинность DNS-данных. Для гарантии подлинности нйбора ответов DNS-сервера этот сервер зашифровывает хэшированный набор DNS-ответов с помощью секретного ключа зоны DNS. Эта сигнатура возвращается распознавателю в качестве новой записи, имя которой SIG. Распознаватель должен получить открытый ключ DNS-сервера для соответствующей зоны, используя другую запись о ресурсах KEY. Затем сервер-получатель дешифрует сигнатуру, чтобы получить исходные хэшированные данные, и вычисляет собственный хэш полученного набора ответов, используя тот же алгоритм, что и DNS-сервер отправителя. Если результат вычисления совпадает с полученным значением от сервера, то данные считаются достоверными.

Подмена содержимого кэша

Бюллетень группы CERT (Computer Emergency Response Team - группа компьютерной “скорой помощи”) СА-97.22 за август 1997 года предупреждает о существовании уязвимых мест в различных версиях BIND. В версиях до 8.1.1 существует возможность подмены данных кэша с другого DNS-сервера. Иначе говоря, злоумышленник может использовать один DNS-сервер для добавления некорректных записей в кэш другого DNS-сервера.

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

После успешной операции подмены на все запросы к скомпрометированному DNS-серверу будет выдаваться информация подложных записей, т.е. нарушится соответствие между действительными именами хостов и их 1Р-адресами.

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

На рис. 6.6 показан пример подмены содержимого кэша DNS-сервера. Предположим, что нарушитель формирует сообщение DNS, содержащее в запросе запись ответа. Затем нарушитель отправляет этот запрос с хоста evil .dns .net на атакуемый DNS-сервер ns04 .baweb.com- уполномоченный сервер имен для домена www.hillary2 00 0.org.

Рис. 6.6. Подмена содержимого кэша DNS

Созданный нарушителем пакет кроме запроса на определение IP-адреса хоста www.hillary2000.org содержит в части ответа DNS-сообщения 1Р-адрес 206.245.150.74. Как скоро станет ясно, это не настоящий IP-адрес хоста www.hillary2000.org.

DNS-сервер ns04 .baweb . сот не в состоянии отличить запрос от ответа и поэтому просто кэширует ответ, переданный в запросе. В кэш заносится подложное соответствие имени хоста и IP-адреса. На последнем этапе этой подмены какой-либо пользователь или процесс должен запросить IP-адрес для хоста www.hillary2000 .org. Ответ будет выдан из кэша - 206 . 245 .150 . 74.

Это реальный пример из политических войн с использованием компьютерных технологий. В июле 1999 года был создан Web-сайт Хиллари Клинтон, информация которого касалась ее предвыборной кампании на место в сенате США от штата Нью-Йорк.

Однако, когда пользователи хотели зайти на этот сайт, открывалась Web-страничка www. hilllaryno . com (IP-адрес 206.245.150.74) сторонников конкурента Хиллари Клинтон, мэра Нью-Йорка Рудольфа Джулиани (в то время Рудольф Джулиани еще не принял решения по поводу борьбы за место в сенате; позже он снял свою кандидатуру).

Как оказалось, это происходило из-за успешной атаки подмены содержимого кэша DNS-сервера. Другими словами, для доменного имени www.hillary2000.org был поставлен в соответствие IP-адрес хоста www. hilllaryno. com. Естественно, что администраторы сайта www. hilllaryno. com отрицали свою причастность к происходящему. Отследить и доказать подмену кэша очень тяжело.

Резюме

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

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

История программы BIND пестрит уведомлениями об обнаружении уязвимых мест. За последние годы появилось несколько программ атаки (на основе переполнения буфера), которые позволяли хакерам получить права суперпользователя на хосте с запущенной программой BIND. Но работа в современной сети Internet практически невозможна без использования в той или иной степени возможностей DNS. Желательно организовать надежную защиту своего DNS-сервера и не доверять всем поступающим ответам DNS. Постоянно обновляйте программное обеспечение DNS-сервера. Это позволит воспользоваться наиболее эффективными методами обеспечения безопасности и ограничить объем потенциально опасной информации, предоставляемой вашим DNS-сервером.

Воздействия и реакции | Обнаружение нарушений безопасности в сетях | Содержимое пакетов


Обнаружение нарушений безопасности в сетях



Новости за месяц

  • Июнь
    2021
  • Пн
  • Вт
  • Ср
  • Чт
  • Пт
  • Сб
  • Вс