Материал: Логико-лингвистические модели атак на компьютерные системы. Остапенко Г.А., Дмитриева Е.Ю

- Если будет большая нагрузка на сервер легче использовать PPTPd или IPsec.

4.2.2 DNS-spoofing

4.2.2.1 Принцип работы Domain Name System

Для обращения к хостам в сети используются 32 - разрядные IP - адреса, уникально идентифицирующие каждый сетевой компьютер. Однако, для пользователей использование IP - адресов при обращении к хостам является не слишком удобным и не самым наглядным. В самом начале появления Internet для удобства пользователей было принято решение присвоить всем компьютерам в сети имена. Использование имен позволяет пользователю лучше ориентироваться в киберпространстве сети Internet. Для этих целей была создана система преобразования имен, позволяющая пользователю в случае отсутствия у него информации о соответствии имен и IP - адресов получить необходимые сведения от ближайшего информационно-поискового сервера (DNS - сервера). Эта система получила название доменной системы имен - DNS (Domain Name System) [42].

DNS базируется на двух основных концепциях:

- распределенной базы данных, хранящей обобщенные записи о ресурсах сети, с децентрализованным управлением;

- схемы именования, основанной на иерархически структурированных доменных именах.

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

    Программы, реализующие серверную часть DNS, называются серверами имен (name servers). Сервер имен содержит информацию о некотором сегменте общей базы данных DNS, для которого он будет являться полномочным сервером, и делает ее доступной для клиентов, называемых решающими программами (resolvers). Решающие программы обычно представляют собой библиотечные функции, которые генерируют запросы и посылают их по сети серверам имен (рисунок 4.8).

В DNS определено два типа серверов имен: первичные (primary masters) и вторичные (secondary masters). Первичный сервер имен получает данные о зоне, для которой он является полномочными, из файлов на хост-машине, где он выполняется.

Вторичный сервер имен получает данные о зоне от другого полномочного сервера имен. Когда стартует вторичный сервер, он связывается с полномочным (первичным) сервером зоны и скачивает данные о зоне. Такую процедуру называют передачей зоны (zone transfer). В процессе работы вторичный сервер периодически опрашивает первичный сервер. Если данные на первичном сервере были изменены, то вторичный сервер обновляет свои данные, заново перекачивая все данные зоны с первичного сервера.

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

Решающая программа (resolver) - это клиентская часть DNS, посредством которой прикладные программы получают информацию о доменных именах от серверов имен. Решающая программа выполняет следующие функции:

- запрашивает сервер имен;

- интерпретирует ответ (который может быть записью о ресурсах или ошибкой);

- возвращает информацию запрашивающей программе.

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

Рисунок 4.8 - Работа службы DNS

Серверы имен могут выдавать данные о своей зоне по запросам решающих программ. Кроме того, они также могут осуществлять поиск в пространстве доменных имен данных, для которых они не являются полномочными серверами. Это обусловлено тем, что не все решающие программы могут производить такой поиск самостоятельно. Этот процесс называется разрешением имен (name resolution или resolution). Так как пространство имен представляется инвертированным деревом, серверу имен необходима только одна часть информации, для того чтобы найти любую точку в дереве, а именно: имена и адреса корневых серверов имен. Сервер имен может направить запрос корневому серверу о любом имени в пространстве доменных имен, и корневой сервер определит дальнейший путь поиска.

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

Данные в ответе сервера имен, которые взяты из кэша, помечаются как неавторизованные (non-authoritative binding) и к ним прилагаются имена и адреса серверов имен, который являются полномочными для этих данных [35].

Время, которое данные могут храниться в кэше, называется временем жизни данных (time to live) и определяются администратором этой зоны. По истечении времени жизни данные должны быть удалены из кэша. Для их получения необходимо вновь обратиться к полномочному серверу имен этого доменного имени.

Формат сообщения DNS. Для DNS запроса и для DNS ответа используется одинаковый формат сообщений (рисунок 4.9).

Рисунок 4.9 - Формат DNS-сообщения

Сообщение содержит фиксированный 12-байтный заголовок, за которым следуют четыре поля переменной длины. Значение в поле идентификации (identification) устанавливается клиентом и возвращается сервером. Это поле позволяет клиенту определить, на какой запрос пришел отклик. 16-битовое поле флагов (flags) поделено на несколько частей (рисунок 4.10).

Рисунок 4.10 - Поле флагов

Описание каждого поля:

- QR (тип сообщения), 1-битовое поле: 0 обозначает - запрос, 1 обозначает - отклик.

- opcode (код операции), 4-битовое поле. Обычное значение 0 (стандартный запрос). Другие значения - это 1 (инверсный запрос) и 2 (запрос статуса сервера).

- AA - 1-битовый флаг, который означает "авторитетный ответ" (authoritative answer). Сервер DNS имеет полномочия для этого домена в разделе вопросов.

- TC - 1-битовое поле, которое означает "обрезано" (truncated). В случае UDP это означает, что полный размер отклика превысил 512 байт, однако были возвращены только первые 512 байт отклика.

- RD - 1-битовое поле, которое означает "требуется рекурсия" (recursion desired). Бит может быть установлен в запросе и затем возвращен в отклике. Этот флаг требует от DNS сервера обработать этот запрос самому (т.е. сервер должен сам определить требуемый IP адрес, а не возвращать адрес другого DNS сервера), что называется рекурсивным запросом (recursive query). Если этот бит не установлен и запрашиваемый сервер DNS не имеет авторитетного ответа, запрашиваемый сервер возвратит список других серверов DNS, к которым необходимо обратиться, чтобы получить ответ. Это называется повторяющимся запросом (iterative query) . Мы рассмотрим примеры обоих типов запросов в следующих примерах.

- RA - 1-битовое поле, которое означает "рекурсия возможна" (recursion available). Этот бит устанавливается в 1 в отклике, если сервер поддерживает рекурсию. Мы увидим в наших примерах, что большинство серверов DNS поддерживают рекурсию, за исключением нескольких корневых серверов (коневые сервера не в состоянии обрабатывать рекурсивные запросы из-за своей загруженности).

- Это 3-битовое поле должно быть равно 0.

- rcode это 4-битовое поле кода возврата. Обычные значения: 0 (нет ошибок) и 3 (ошибка имени). Ошибка имени возвращается только от полномочного сервера DNS и означает, что имя домена, указанного в запросе, не существует.

Следующие четыре 16-битных поля указывают на количество пунктов в четырех полях переменной длины, которые завершают запись. В запросе количество вопросов (number of questions) обычно равно 1, а остальные три счетчика равны 0. В отклике количество ответов (number of answers) по меньшей мере равно 1, а оставшиеся два счетчика могут быть как нулевыми, так и ненулевыми.

Использование UDP и TCP. DNS поддерживает как UDP, так и TCP. Заранее известны номера портов для DNS серверов - UDP порт 53 и TCP порт 53. Когда разборщик выдает запрос и возвращается отклик с установленным битом TC (обрезано - truncated), это означает, что размер отклика превысил 512 байт, только первые 512 байт были возвращены серверу. Разборщик обычно отправляет запрос снова, но уже с использованием TCP. При этом возвращается больше, чем 512 байт. Так как TCP делит поток данных на части, которые называются сегментами, он может передать любое количество пользовательских данных с использованием нескольких сегментов [35].

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

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

4.2.2.2 Внедрение dns-сервера путем перехвата dns-запроса

Возможность атаки на DNS путем фальсификации ответа DNS-сервера известна довольно давно. Объектом атаки может являться как резолвер, так и DNS-сервер. Причины успеха подобных атак кроются в легкости подделки ответа сервера. Протоколы DNS, используемые в настоящее время, не предусматривают каких либо средств проверки аутентичности полученных данных и их источника, полностью полагаясь в этом на нижележащие протоколы транспортного уровня. Используемый транспортный протокол (UDP) с целью повышения эффективности не предусматривает установления виртуального канала и использует в качестве идентификатора источника сообщения IP-адрес, который может быть элементарно подделан. Переход к использованию TCP несколько замедлит систему, так как при использовании TCP требуется создание виртуального соединения. Сетевая ОС вначале посылает DNS-запрос с использованием протокола UDP. И только в том случае, если ей придет специальный ответ от DNS-сервера, сетевая ОС пошлет DNS-запрос с использованием TCP [40].

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

Необходимым условием осуществления данного варианта атаки является перехват DNS-запроса. Это возможно только в том случае, если атакующий находится либо на пути основного трафика [24], либо в сегменте настоящего DNS-сервера (рисунок 4.11). Если сеть построена на свитчах, то для осуществления перехвата DNS-запроса, необходимо использовать ARP-spoofing, для того чтобы отравить записи в ARP-таблицах. Это необходимо чтобы трафик проходил, через компьютер атакующего.

Рисунок 4.11 - Расположение субъекта и объекта атаки

Рисунок 4.12 - Перехват DNS-запроса и отправление ложного DNS-ответа

Рисунок 4.13 - Работа сети во время атаки

Если сеть построена на свитчах, то для осуществления перехвата DNS-запроса, необходимо использовать ARP-spoofing, для того чтобы отравить записи в ARP-таблицах. Это необходимо чтобы трафик проходил, через компьютер атакующего.

4.2.2.3 «Шторм» ложных dns ответов на атакуемый хост

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

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

Вид пакетов, отправляемых атакующим, будет иметь следующий вид (таблица 4.5):

Таблица 4.5. Вид ложных DNS ответов