Hacker Hacker Hacker Hacker Hacker Hacker Hacker Hacker Hacker Hacker Hacker Hacker Hacker Hacker Hacker Hacker Hacker Hacker Hacker Hacker Hacker Hacker Hacker Hacker

Hacker-forum!

Информация о пользователе

Привет, Гость! Войдите или зарегистрируйтесь.


Вы здесь » Hacker-forum! » Полезные Статьи » Атака на DNS или Ночной кошмар сетевого администратора


Атака на DNS или Ночной кошмар сетевого администратора

Сообщений 1 страница 30 из 478

1

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

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

1. DNS с высоты птичьего полета

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

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

Клиентская часть DNS называется резолвером (resolver), доступ к которому прикладные программы получают через API операционной системы. При взаимодействии резолвера с сервером в качестве транспортного протокола используется UDP, не предусматривающий формирования виртуального канала. Запросы, генерируемые резолвером, являются рекурсивными, т.е. в качестве ответа на такой запрос возвращается либо искомая информация, либо сообщение о ее отсутствии.

Получив запрос от резолвера, сервер либо сразу же возвращает ответ (при условии наличия искомой информации в локальной базе), либо формирует запрос к другому серверу. Этот запрос обычно является итеративным и, в отличие от рекурсивного, допускает ответ в виде ссылки на другой сервер, который лучше осведомлен о месте расположения искомой информации.

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

2. Межсегментная удаленная атака на DNS-сервер

Возможность атаки на DNS путем фальсификации ответа DNS-сервера известна довольно давно (см., например, Медведовский И.Д., Семьянов П.В., Платонов В.В. Атака через Internet. - СПб.: "Мир и семья-95", 1997.). Объектом атаки может являться как резолвер, так и DNS-сервер. Причины успеха подобных атак кроются в легкости подделки ответа сервера. Протоколы DNS, используемые в настоящее время, не предусматривают каких либо средств проверки аутентичности полученных данных и их источника, полностью полагаясь в этом на нижележащие протоколы транспортного уровня. Используемый транспортный протокол (UDP) с целью повышения эффективности не предусматривает установления виртуального канала и использует в качестве идентификатора источника сообщения IP-адрес, который может быть элементарно подделан.

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

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

Межсегментная атака на DNS-сервер выглядит следующим образом. Предположим для определенности, что целью атаки является "подмена" IP-адреса web-сервера coolsite.com на IP-адрес сервера badsite.com для пользователей некоторой подсети, которую обслуживает DNS-сервер ns.victim.com. В первой фазе атаки ns.victim.com провоцируется на поиск информации о IP-адресе coolsite.com путем посылки ему соответствующего рекурсивного запроса. Во второй фазе атакующий посылает серверу ns.victim.com ложный ответ от имени ns.coolsite.com, который является ответственным за домен coolsite.com. В ложном ответе вместо реального IP-адреса coolsite.com указывается IP-адрес badsite.com. Сервер ns.victim.com кэширует полученную информацию, в результате чего в течении определенного промежутка времени (величина этого промежутка указывается в поле TTL ложного ответа и может произвольно выбираться атакующим) ничего не подозревающие пользователи вместо сервера coolsite.com попадают на badsite.com.

Для того, чтобы ложный ответ был воспринят сервером ns.victim.com как истинный, достаточно выполнения четырех условий:

IP адрес отправителя ответа должен соответствовать IP-адресу запрашиваемого сервера (в нашем случае ns.coolsite.com);
UDP-порт, на который направляется ответ, должен совпадать с портом, с которого был послан запрос;
идентификатор ответа должен совпадать с идентификатором запроса;
ответ должен содержать запрашиваемую информацию (в нашем случае IP-адрес web-сервера coolsite.com).
Очевидно, что выполнение первого и четвертого условий не представляет для атакующего особых трудностей. Со вторым и третьим условиями ситуация намного сложнее, поскольку в случае межсегментной атаки у атакующего нет возможности перехватить исходный запрос и "подсмотреть" необходимые параметры.
Большинство используемых в настоящее время реализаций DNS-сервера (BIND4, MS DNS) используют для исходящих запросов 53 порт, так что можно "на удачу" послать ложный ответ на этот порт. Однако данный метод будет срабатывать не всегда, поскольку, например, BIND8 может использовать для исходящих запросов любой случайно выбранный непривилегированный порт.

Идентификатор (id) запроса представляет собой двухбайтовое число, указываемое сервером в запросе с целью однозначной идентификации ответа на данный запрос. Это число инкрементируется с каждым новым запросом. Незнание текущего значения идентификатора приводит к необходимости посылки множества ложных ответов с различными значениями id.

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

2

Скрытый текст:

Для просмотра скрытого текста - войдите или зарегистрируйтесь.

3

Скрытый текст:

Для просмотра скрытого текста - войдите или зарегистрируйтесь.

4

Скрытый текст:

Для просмотра скрытого текста - войдите или зарегистрируйтесь.

5

Скрытый текст:

Для просмотра скрытого текста - войдите или зарегистрируйтесь.

6

Скрытый текст:

Для просмотра скрытого текста - войдите или зарегистрируйтесь.

7

Скрытый текст:

Для просмотра скрытого текста - войдите или зарегистрируйтесь.

8

Скрытый текст:

Для просмотра скрытого текста - войдите или зарегистрируйтесь.

9

Скрытый текст:

Для просмотра скрытого текста - войдите или зарегистрируйтесь.

10

Скрытый текст:

Для просмотра скрытого текста - войдите или зарегистрируйтесь.

11

Скрытый текст:

Для просмотра скрытого текста - войдите или зарегистрируйтесь.

12

Скрытый текст:

Для просмотра скрытого текста - войдите или зарегистрируйтесь.

13

Скрытый текст:

Для просмотра скрытого текста - войдите или зарегистрируйтесь.

14

Скрытый текст:

Для просмотра скрытого текста - войдите или зарегистрируйтесь.

15

Скрытый текст:

Для просмотра скрытого текста - войдите или зарегистрируйтесь.

16

Скрытый текст:

Для просмотра скрытого текста - войдите или зарегистрируйтесь.

17

Скрытый текст:

Для просмотра скрытого текста - войдите или зарегистрируйтесь.

18

Скрытый текст:

Для просмотра скрытого текста - войдите или зарегистрируйтесь.

19

Скрытый текст:

Для просмотра скрытого текста - войдите или зарегистрируйтесь.

20

Скрытый текст:

Для просмотра скрытого текста - войдите или зарегистрируйтесь.

21

Скрытый текст:

Для просмотра скрытого текста - войдите или зарегистрируйтесь.

22

Скрытый текст:

Для просмотра скрытого текста - войдите или зарегистрируйтесь.

23

Скрытый текст:

Для просмотра скрытого текста - войдите или зарегистрируйтесь.

24

Скрытый текст:

Для просмотра скрытого текста - войдите или зарегистрируйтесь.

25

Скрытый текст:

Для просмотра скрытого текста - войдите или зарегистрируйтесь.

26

Скрытый текст:

Для просмотра скрытого текста - войдите или зарегистрируйтесь.

27

Скрытый текст:

Для просмотра скрытого текста - войдите или зарегистрируйтесь.

28

Скрытый текст:

Для просмотра скрытого текста - войдите или зарегистрируйтесь.

29

Скрытый текст:

Для просмотра скрытого текста - войдите или зарегистрируйтесь.

30

Скрытый текст:

Для просмотра скрытого текста - войдите или зарегистрируйтесь.


Вы здесь » Hacker-forum! » Полезные Статьи » Атака на DNS или Ночной кошмар сетевого администратора