Dns резолвинг что это

Обновлено: 06.07.2024

Согласно руководящим материалам (RFC-1034, RFC-1035) система доменных имен состоит из трех основных частей:

  • Всего множества доменных имен (domain name space)
  • Серверов доменных имен (domain name servers)
  • Клиенты DNS (Resolver-ы)

Множество доменных имен было подробно рассмотрено в материале "Доменная адресация. Немного истории и принципы построения", поэтому сосредоточимся на двух оставшихся компонентах серверах и resolver-ах.

Сервис системы доменных имен строится по схеме "клиент-сервер". В качестве клиентской части выступает прикладной процесс, который запрашивает информацию о соответствии имени адресу (или наоборот адреса имени). Это программное обеспечение и называют resolver. В качестве сервера выступает прикладная программа-сервер.

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

Ряд производителей операционных систем, например, Sun или SGI, предлагали решения, в которых resolver являлся отдельным процессом, и прикладные программы через него реализовывали взаимодействие с DNS.

Самостоятельный resolver может быть собран и в BIND версии 9. Это так называемый lightweight resolver. Он состоит из rosolver-демона и библиотеки взаимодействия с этим демоном, процедуры которой линкуются с прикладным ПО. Данный resolver позволяет не только посылать запросы к серверу доменных имен, но кэшировать соответствия между доменным именем и IP-адресом.

В качестве серверов доменных имен чаще всего используются различные версии BIND (Berkeley Internet Name Domain). Если сервер реализован на платформе Windows, то тогда используют решение от Microsoft, хотя для этой платформы также существуют версии BIND.

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


Рис1. Рекурсивный запрос resolver и нерекурсивная (итеративная) процедура на разрешение доменного имени сервером доменных имен.

Данная схема разрешения имени (установки соответствия между именем и IP-адресом) называют нерекурсивной (итеративной). Чем она отличается от рекурсивной мы обсудим позже.

Поясним приведенную схему нерекурсивной процедуры разрешения запроса:

  1. Прикладная программа через resolver запрашивает IP-адрес по доменному имени у местного сервера (запрос resolver рекурсивный, т.е. resolver просит server найти ему адрес).
  2. Местный сервер сообщает прикладной программе IP-адрес запрошенного имени, выполняя при этом нерекурсивный опрос серверов доменных имен. При этом:
    1. если адрес находится в зоне его (местного сервера) ответственности, сразу сообщает его resolver-у,
    2. если адрес находится в зоне ответственности другого сервера доменных имен, то обращается к корневому серверу системы доменных имен за адресом TLD-сервера (top-level domain server),
    3. обращается к TLD-серверу за адресом,
    4. получает от него адрес удаленного сервера,
    5. обращается к удаленному серверу за адресом,
    6. получает от удаленного сервера адрес,

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

    Мы получаем в ответ:

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

    Любопытно, что в системе Windows 3.1 некоторые программы трассировки, показывали сначала IP-адрес шлюза, а только потом, после разрешения "обратного" запроса, заменяли его на доменное имя шлюза. Если сервис доменных имен работал быстро, то эта подмена была практически незаметна, но если сервис работал медленно, то промежутки бывали довольно значительными.

    Проверить на сколько "чувствительны" запросы traceroute c точки зрения отображения трассы к использованию сервера доменных имен можно задав поиск трассы с использованием сервера:

    и без использования сервера:

    Если в примере с telnet и ftp мы рассматривали, только "прямые" (forward) запросы к серверу доменных имен, то в примере с traceroute мы впервые упомянули "обратные"(reverse) запросы. В "прямом" запросе прикладная программа запрашивает у сервера доменных имен IP-адрес, сообщая ему доменное имя. При "обратном" запросе прикладная программа запрашивает доменное имя, сообщая серверу доменных имен IP-адрес.

    Следует заметить, что скорость разрешения "прямых" и "обратных" запросов в общем случае будет разная. Все зависит от того, где описаны "прямые"(forward) и "обратные"(reverse) зоны в базах данных серверов доменных имен, обслуживающих соответствующие домены (прямой и обратный).

    Более подробно этого вопроса мы коснемся при обсуждении файлов конфигурации программы named.

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

    В этом случае resolver обращается к локальному серверу доменных имен, если не получает от него адреса, то опрашивает сервер корневого домена, получает от него адрес удаленного сервера TLD, опрашивает этот сервер, получает адрес удаленного сервера, опрашивает удаленный сервер и получает IP-адрес, если он посылал, так называемый "прямой" запрос.


    Рис.2. Нерекурсивный запрос resolver-а.

    Как видно из этой схемы, resolver сам нашел нужный IP-адрес. Однако общая практика такова, что resolver не порождает нерекурсивных запросов, а переадресовывает их локальному серверу доменных имен.

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

    Самые умные resolver-ы, такие, например, как resolver Windows 2000 Server и BIND 9 умеют поддерживать кэш, в котором сохранияют не только удачно установленные соответствия имени и адреса (positive response), но и так называемые "негативные" отклики (negative response results) на запросы. Кроме того, эти resolver-ы упорядочивают отклики об адресах серверов в соответствии с принятыми в них (resolver-ах) алгоритмами выставления предпочтений, которые базируются на времени отклика сервера.


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

    Вообще говоря, прядок обработки запросов можно описать следующим образом:

    1. поиск ответа в локальном кэше
    2. поиск ответа на локальном сервере
    3. поиск информации в сети.

    При этом кэш может быть как у resolver-а, так и у сервера.

    Прежде, чем мы двинемся дальше в нашем понимании работы системы доменных имен введем еще одно понятие - зону.

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

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

    Существует еще и другой вариант работы сервера, когда он не запрашивает корневой сервер на предмет адреса удаленного сервера доменных имен. Это происходит тогда, когда незадолго до этого сервер уже разрешал задачу получения IP-адреса из того же домена. Если требуется получить IP-адрес удаленного сервера доменных имен, отвечающего за домен, то он будет просто извлечен из буфера сервера (кеша), т.к. в течение определенного времени, заданного в конфигурации описания зоны (Time To Live - TTL), этот адрес будет храниться в кэше сервера. А попал он туда как результат выполнения предыдущего запроса.

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

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

    На рисунке 5 удаленный сервер домена сам разрешает запрос на получение IP-адреса хоста своего домена по рекурсивному запросу, используя при этом нерекурсивный опрос своих серверов поддоменов.


    Рис 4. Нерекурсивная обработка запроса местным сервером доменных имен на получение IP-адреса по доменному имени.



    Рис. 5. Рекурсивная (для местного сервера) и нерекурсивная (для удаленного сервера) процедуры разрешения адреса по IP-имени.

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

    Представленные здесь варианты работы системы доменных имен не являются исчерпывающими. За более подробной информацией следует обращаться к RFC-1034 и RFC-1035.

    В имени домена разрешены символы a-z, 0-9 и дефис. Дефис не может быть первым и последним символом. Также запрещён частный случай, когда два дефиса стоят на 3 и 4 позиции (ab--cd). Это ограничение однозначно отделяет обычные ASCII домены от пуникода.

    Для пользователей существуют юникодные домены, (например, сиськи.su) но технически их нет, браузер преобразует юникодную запись в ASCII при помощи специальной кодировки Punycode ( xn--h1aaf0ab0e.su ) и дальше работает старый добрый ASCII.

    Реестр и регистраторы

    В общем случае есть реестр зоны [первого уровня], регистраторы и продавцы (реселлеры регистраторов). У каждой зоны первого уровня есть реестр, можно ещё сказать, координатор. Это организация, которая хранит, обслуживает и предоставляет доступ для регистраторов к центральной базе данных доменов этой зоны. По понятным причинам, некоторые организации фактически обслуживают несколько зон, это касается, например, зон RU и РФ. Во многих национальных доменах [первого уровня] координатор и является единственным регистратором, то есть отсутствует институт распределённой регистрации доменов.

    Реестр продаёт регистраторам право доступа к зоне. Реестр — это сугубо техническая организация, предоставляющая программный интерфейс (API) для регистраторов.

    А вот регистраторы уже работают с розничными клиентами, людьми. В зоне RU реестром является РосНИИРОС, а самым крупным регистратором — РуЦентр.

    Чтобы стать регистратором, нужно выполнить разные строгие требования реестра. Вот каковы требования к кандидату в регистраторы в России. Список регистраторов растёт, и на 15 ноября 2009 года насчитывает 23 штуки.

    Если этот домен уже кем-то куплен (возможно, через другого регистратора, реестр-то один), то …пролёт.

    1. формальное временное право владения доменом. Самая близкая аналогия — аренда.
    2. доступ к изменению NS-серверов домена

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

    DNS резолвинг

    DNS не самодостаточна. Чтобы “всё завелось”, в конце концов, какой-то клиент должен сделать запрос к какому-то серверу, не зная его имени. Обычно, эту проблему решает DHCP сервер интернет-провайдера, который по специальному протоколу, помимо прочего, сообщает IP адреса своих кеширующих DNS серверов. Кроме того, существуют сервисы DNS серверов, такие как OpenDNS, которые работают благодаря постоянным IP адресам.

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

    В DNS используется система делегирования полномочий. Корневые сервера реестра делегируют полномочия выдавать ответы по определённым зонам на NS (name server) этих зон. Когда кто-то спрашивает NS о его зоне, он помечает ответ как авторитетный (authoritative). Другие NS в ответ на ваш запрос, могут сказать я не знаю, но вот он знает . Такая цепочка может быть бесконечной. Предполагается, что в какой-то момент (на практике это первый же сервер после перенаправления) сервер даст вам конкретную информацию: либо я в ответе, вот записи , либо я не знаю и не знаю кто знает .

    Существуют специальные, т.н. корневые сервера. Они хранят информацию о том какие зоны обслуживаются какими NS, то есть, SOA записи. Можно спросить корневой сервер об абсолютно любой записи любой зоны и гарантированно никогда не получить авторитетный ответ. :) Но вы получите адрес NS, который, по-мнению корневого сервера обслуживает интересующую вас зону. Нужно повторить запрос к полученному NS. Такие повторы называются рекурсивным резолвингом.

    Безопасность

    Использование UDP, в частности, означает, что вы могли послать запрос одному компьютеру, а ответил другой. DNS протокол не даёт ровным счётом никаких средств для защиты передаваемой информации. Также нет никакого способа проверить, что ответ не был изменён кем-то по дороге до вашего компьютера. Отправка запроса к DNS серверу и ожидание ответа называется резолвингом (DNS resolving). Строго говоря, это название относится только к A запросам, которые используются для выяснения какой адрес соответствует указанному имени. В более общем смысле, обращение к DNS называется (сюрприз!) запросом (query). Но, в действительности, резолвинг A записей это 99% использования DNS. Оба названия имеют право на жизнь, к тому же нет принципиальной разницы.

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

    Делегирование

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

    Кеширование

    DNS — это, пожалуй, самый большой и успешный пример использования проксирующего кеширования.

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

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

    В популярном (и дырявом) DNS пакете BIND нет чёткого разделения между кеширующим и авторитетным DNS серверами. Из-за этого новички-администраторы делают неверные предположения о схеме работы DNS и допускают ошибки.

    Итоги

    Люди используют осмысленные символьные имена доменов, т.к. оперировать адресами типа 192.0.32.10 неудобно. Домены имеют иерархическую структуру начиная с доменов первого уровня (TLD) и без ограничений по глубине.

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

    DNS это распределённая база данных, которая состоит из зон. Зона — это набор DNS записей. Клиенты делают запросы к серверам посредством DNS протокола. Как правило, запросы отправляются по UDP. DNS уязвим к широкому спектру атак, включая man-in-the-middle.

    В DNS очень активно используется кеширование. Это позволяет снизить нагрузку на сеть и часто является причиной непонимания между покупателями доменов и поддержкой регистратора.

    Если вы хоть немного имели дело с интернетом и компьютерными сетями, то наверняка слышали о системе доменных имён (DNS). Прочитав статью узнаете, как это всё работает.

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

    Сервер доменных имён — это устройство, которое сопоставляет имя хоста с IP-адресом конкретной машины/железа.

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

    DNS-резолвер

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

    27–28 ноября, Москва, Беcплатно

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

    Время, в течение которого запись хранится в резолвере, называется TTL (time to live).

    Его можно установить в панели управления сервиса, на котором приобретался домен.

    Типы DNS-серверов

    Корневой DNS-сервер

    Это DNS-сервер, который хранит в себе адреса всех TLD-серверов (TLD — top-level domain, домен верхнего уровня). По пути от имени хоста до IP-адреса запрос сначала попадает на корневой DNS-сервер.

    Существует 13 корневых DNS-серверов:


    Организации, управляющие корневыми DNS-серверами

    Это не означает, что существует только 13 машин, которые обрабатывают все запросы со всего мира — существуют и второстепенные серверы, по которым распределяется трафик.

    TLD-серверы

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

    Теперь возникает вопрос — откуда TLD-серверы знают адрес авторитативных серверов? Ответ прост — после того, как вы покупаете любой домен у регистраторов вроде Godaddy или Namecheap, регистраторы привязывают авторитативные серверы к TLD-серверу.

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

    Авторитативный DNS-сервер

    Запрос на эти серверы поступает в самую последнюю очередь. Эти серверы хранят фактические записи типа A, NS, CNAME, TXT, и т. п.

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

    Типы DNS-запросов

    Существует 3 типа DNS-запросов:

    1. Рекурсивный: подобные запросы выполняют пользователи к резолверу. Собственно, это первый запрос, который выполняется в процессе DNS-поиска. Резолвером чаще всего выступает ваш интернет провайдер или сетевой администратор.
    2. Нерекурсивные: в нерекурсивных запросах резолвер сразу возвращает ответ без каких-либо дополнительных запросов на другие сервера имён. Это случается, если в локальном DNS-сервере закэширован необходимый IP-адрес либо если запросы поступают напрямую на авторитативные серверы, что позволяет избежать рекурсивных запросов.
    3. Итеративный: итеративные запросы выполняются, когда резолвер не может вернуть ответ, потому что он не закэширован. Поэтому он выполняет запрос на корневой DNS-сервер. А тот уже знает, где найти фактический TLD-сервер.

    Попробуем рассмотреть этот процесс на рисунке:


    Разберём рисунок выше:

    Что в итоге?

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

    image

    В статье будут продемонстрированы техники, используемые пентестерами, для первоначального проникновения в сеть и последующего полного компрометирования домена без запуска сторонних приложений или повторного применения учетных записей в открытом виде. Мы рассмотрим, как работает среда на базе Windows, когда включен IPv6 (что есть по умолчанию), с целью получения контроля над DNS (при помощи утилиты MITM6) и ретранслирования учетных записей в LDAPS (LDAP поверх TLS), используя инструмент Ntlmrelayx, для создания новых машинных аккаунтов.

    При помощи нового машинного аккаунта мы сможем пройти аутентификацию в LDAP и изменить некоторые свойства системы для доступа к целевой машине от имени практически любого пользователя (и даже администратора домена). Технология, которую мы рассмотрим в деталях, представляет собой ограниченное ресурсное делегирование. Впоследствии, чтобы полностью скомпрометировать сеть, мы воспользуемся уязвимостью SpoolService (PrinterBug) с целью принудительной аутентификации из контроллера домена к хосту, находящимся под нашим контролем, где включено неограниченное делегирование. Используя эту технику, мы сможем извлечь билет krbtgt для выгрузки базы данных контроллера домена.

    Ресурсное и неограниченное делегирование

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

    Ограниченное ресурсное делегирование

    В документации от Microsoft говорится следующее: «Ограниченное делегирование в Kerberos используется в тех случаях, когда служба фронт-энда и ресурсная служба находятся в разных доменах. Администраторы службы могут настроить новое делегирование, указав аккаунты домена для служб фронт-энда, которые могут олицетворять пользователей в объектах учетных записей служб, связанных с ресурсами». Сей факт означает, что ограниченное ресурсное делегирование может быть сконфигурировано для ресурса или машинной учетной записи и управляется атрибутом (msDSAllowedToActOnBehalfOfOtherIdentity).

    Неограниченное делегирование

    Насчет неограниченного делегирования Олег Александров сказал следующее: «Серверу, которому доверяют неограниченное делегирование, позволено олицетворять (практически) любого пользователя любой службы внутри сети. Когда пользователь запрашивает Билет службы (Service Ticket; ST) у контроллера домена для какой-либо службы, что разрешено при делегации, контроллер домена копирует клиентский TGT (Ticket Granting Ticket; Билет на выдачу билетов) и прикрепляет этот билет к билету службы, который впоследствии презентуется соответствующей службе. Когда пользователь получает доступ к службе при помощи билета, пользовательский TGT извлекается и сохраняется в службе сервера LSASS для последующих нужд».

    Соответственно, если мы контролируем хост, где включено неограниченное делегирование, то можем извлекать TGT и повторно использовать в любой службе из процесса LSASS. Более подробно о делегации в Kerberos рассказывается в статье Wagging the Dog.

    Что такое SPN

    SPN (Service Principal Name; Первичное имя сервиса) представляет собой уникальный идентификатор экземпляра службы. SPN’ы используются во время аутентификации в Kerberos для связи экземпляра службы с аккаунтом авторизации в службе, что позволяет клиентскому приложений запрашивать у службы аутентификацию учетной записи, даже если у клиента нет имени аккаунта.

    Более подробно эта тема рассматривается в следующих статьях:

    IPV6 в Windows и WPAD

    Протокол IPv6 активирован по умолчанию во всех версиях Windows, начиная с Vista. Во время загрузки Windows сначала ищется конфигурация для DHCP, а затем для WPAD. При реализации атаки мы получим контроль над DNS при помощи утилиты MITM6 с целью перенаправления всего трафика на наш DNS сервер, и когда хост начнет искать конфигурацию для WPAD через DNS, целевые машины будут подключаться к нашему прокси-серверу с целью аутентификации на нашем сервере, где используется скрипт ntlmrelax. Кроме того, учетные записи будут ретранслироваться в LDAPS для создания новых машинных аккаунтов.

    Полная схема атаки

    Чтобы применить вышеуказанные концепции и техники на практике, была создана тестовая среда, состоящая из Windows Server 2012R2 (контроллер домена), клиентского хоста с Windows 10 (Mark-pc), AppServer с Windows 10 и нашей машины с Kali Linux, откуда будет осуществляться атака. Предполагается, что наша рабочая система находится в той же подсети вместе с целевыми машинами.


    Рисунок 1: Полная схема атаки

    Демонстрация атаки

    Как было упомянуто выше, предполагается, что наша рабочая система (с Kali Linux) находится в одной подсети с целевыми машинами. Реализация атаки начинается с проверки подписывания в SMB при помощи утилиты CrackMapExec, поскольку в нашем случае требуется, чтобы эта функция была отключена.

    CrackMapExec можно загрузить из официального репозитория или установить, используя следующую команду:

    apt-get install crackmapexec

    Начинаем с проверки IP-конфигурации нашей машины:


    Рисунок 2: IP-конфигурация рабочей системы

    Затем запускаем CrackMapExec с целью проверки подписывания и детектирования живых хостов:


    Рисунок 3: Сканирование сети при помощи CrackMapExec

    Теперь мы знаем, что имя внутреннего домена – «contoso». Кроме того, было обнаружено три живых хоста, на двух из которых подпись в SMB отключена (в контроллере домена подпись в SMB включена по умолчанию). Далее проверяем, включено ли разрешение имен LLMNR и NBT-NS. Для решения этой задачи я буду запускать ответчик в течение короткого промежутка времени и проверять, смогу ли поймать какие-либо запросы.


    Рисунок 4: Ответчик

    Как видно на рисунке выше, ответчик начал ловить запросы и отвечать на разрешения имен LLMNR и NBT-NS, из чего мы делаем вывод, что эта функция работает.

    Также, поскольку мы создаем новый машинный аккаунт, нужно проверить, настроен ли LDAP поверх TLS (LDAPS). Запускаем nmap и сканируем контроллер домена на предмет присутствия открытого порта 636:


    Рисунок 5: Сканирование на предмет присутствия LDAPS

    Теперь, когда все требования для реализации атаки выполняются, переходим к использованию фреймворка MITM6 и скрипта ntlmrelayx для ретранслирования перехваченных учетных записей в LDAPS и создание нового машинного аккаунта на основе перехваченных данных. Чтобы успешно осуществить запланированный сценарий, нужно добавить цели в белый список, которые будут перезагружены (клиентские машины). Наш же сервер с MITM6 используется для перенаправления трафика от целевых систем на подконтрольный нам DNS сервер.

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


    Рисунок 6: Конфигурация MITM6


    Далее запускаем скрипт ntlmrelayx с указанием протокола LDAPS и контроллера домена, как показано на рисунке ниже.

    Рисунок 7: Подключаем ретранслирование в LDAPS

    После перезагрузки Mark-pc этой машине был назначен IP адрес с нашего DNS сервера. Как видно на скриншоте ниже, IPv6 DNS обладает более высоким приоритетом, чем IPv4 DNS.


    Рисунок 8: У IPv6 DNS выше приоритет

    Если все прошло по плану, мы увидим, что ntlmrelayx начал собирать учетные записи и пытаться атаковать LDAPS на контроллере домена.


    Рисунок 9: Результаты работы ntlmrelayx

    Как только ntlmrelayx успешно пройдет аутентификацию в LDAPS при помощи ретранслируемых аккаунтов, то далее будет пытаться создать новую машинную учетную запись на базе тех аккаунтов и модифицировать атрибут «msDS-AllowedToActOnBehalfOfOtherIdentity» на машине Mark-pc, чтобы была возможность выступать от имени любого пользователя этой системы.


    Рисунок 10: Успешная аутентификация и создание новой машинной учетной записи

    Сразу же возникает вопрос: «Почему возможно создание новой учетной записи в домене на базе перенаправляемых аккаунтов?». Судя по скриншоту ниже, любой пользователь в Active Directory может создать до 10 машинных учетных записей.


    Рисунок 11: Квота на создание машинных аккаунтов

    При просмотре пользователей контроллера домена и компьютеров видно, что атака завершена успешно и ntlmrelayx добавил новую машину.

    Рисунок 12: Машинные аккаунты контроллера домена

    Кроме того, ntlmrelayx будет выгружать информацию о домене, если мы подключимся к LDAPS, используя ретранслируемую учетную запись (ldapdomaindump).


    Рисунок 13: Выгрузка информации о домене

    Поскольку у нас появился машинный аккаунт и модифицировано свойство «msDS-AllowedToActOnBehalfOfOtherIdentity», то теперь можно воспользоваться скриптом getST.py из проекта Impacket для запроса билета службы и получения привилегий администратора домена (contoso\Administrator) на машине Mark-pc.


    Рисунок 14: Запрос билета службы

    Как видно на рисунке выше, мы успешно запросили билет службы при помощи машинного аккаунта от имени учетной записи «Administrator» и сохранили полученные данные в файл CCACHE.

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


    Рисунок 15: Пользователи домена

    Теперь добавляем Kerberos-билет из файла CCACHE в переменную окружения «KRB5CCNAME» при помощи команды «export»:

    Далее при помощи скрипта Impacket Wmiexec будем запускать команды с привилегиями администратора домена. Обратите внимание, что CIFS SPN пригоден только для доступа к общим файловым ресурсам (например, при помощи Smbclient), однако Wmiexec осуществит попытку автоматической смены на HOST SPN, чтобы мы могли выполнять WMI-запросы и команды.


    Рисунок 16: Запуск скрипта wmiexec на машине Mark-pc

    После успешного завершения откроется полуинтерактивный шелл с привилегиями «contoso\Administrator».


    Рисунок 17: На машине Mark-pc появился шелл

    При помощи билета Kerberos-службы и скрипта Impackеt SecretsDump выгружаем локальные хэши.


    Рисунок 18: Выгрузка локальных хэшей на машине Mark-pc

    Далее при помощи утилиты lsassy удаленно выгружаем учетные записи в открытом виде, используя локальные административные хэши.


    Рисунок 19: Выгрузка учетных записей в открытом виде на машине Mark-pc

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

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


    Рисунок 20: Компьютеры домена

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

    Снова возвращаемся к выгруженной информации и находим интересную группу домена с именем «Servers Admins».


    Рисунок 21: Группы домена

    Для нахождения членов этой группы воспользуемся скриптом bloodhound.py, учетной записью mark и данными, импортированными в приложение BloodHound.


    Рисунок 22: Выполнение скрипта Bloodhound.py

    Используя запросы в Bloodhound, мы обнаружили, что аккаунт машины Mark-pc$ является частью группы «Servers Admins».


    Рисунок 23: Члены группы Servers Admins

    Попробуем воспользоваться аккаунтом машины Mark-pc$, полученным при помощи скрипта Secretsdump, и, используя CrackMapExec проверим, какие у нас будут привилегии на AppServer.


    Рисунок 24: Проверка доступа при помощи CrackMapExec

    Как видно нас скриншоте выше, мы успешно прошли аутентификацию в AppServer, и теперь при помощи скрипта Impacket Wmiexec передадим хэши аккаунтов машины с целью получения шелла и выполнения команд на AppServer.


    Рисунок 25: Запуск скрипта wmiexec на AppServer

    Поскольку мы запускаем команды с локальными административными привилегиями, то воспользуемся скриптом Secretsdump для выгрузки локальных хэшей, так как нам нужны Kerberos-ключи машинного аккаунта для эксплуатации уязвимости SpoolService.


    Рисунок 26: Запуск скрипта secretsdump на AppServer

    Теперь добавляем новый SPN в AppServer при помощи скрипта addspn из проекта krbrelayx, который нужен, чтобы наша жертва (в данном случае – контроллер домена) искала этот SPN и перенаправляла трафик на подконтрольный нам сервер.

    При помощи машинного аккаунта в AppServer добавляем новый SPN (HOST/attacker1.contoso.local) в AppServer$.


    Рисунок 27: Добавление SPN при помощи скрипта addspn

    Затем при помощи скрипта dnstool.py (тоже из проекта krbrelayx) в контроллере домена добавляем новую DNS-запись для только что созданного SPN (attacker1.contoso.local), которая будет указывать на нашу машину с Kali Linux.


    Рисунок 28: Добавление новой DNS-записи

    После обновления DNS запускаем Nslookup вместе с именем attacker1.contoso.local с целью проверки, что резолвинг происходит на IP-адрес нашей машины с Kali Linux.


    Рисунок 29: Проверка DNS

    Теперь настраиваем сервер на перехват krbtgt TGT при помощи скрипта krbrelayx и AES265-ключа от машины AppServer.


    Рисунок 30: Настройка перехвата при помощи скрипта krbrelayx

    Затем при помощи скрипта printerbug.py (который можно найти там же в проекте krbrelayx) принуждаем контроллер домена на поиск SPN HOST/Attacker1.contoso.local, который инициирует обратный вызов к нашей рабочей системе с Kali Linux, поскольку ранее мы настроили DNS-записи соответствующим образом. Во время аутентификации мы использовали аккаунт машины AppServer$.


    Рисунок 31: Запуск скрипта printerbug.py

    По результатам успешной отработки скрипта мы получим перехваченный билет krbtgt TGT на нашем сервере, который впоследствии будет расшифрован при помощи AES256-ключа машинного аккаунта для AppServer$ и сохранен в формате CCACHE.


    Рисунок 32: Перехват TGT

    Теперь добавляем в файл CCACHE в наши переменные окружения при помощи команды export и при помощи скрипта Impackets-secretsdump выгружаем базу данных контроллера домена.


    Рисунок 33: Выгрузка базы данных контроллера домена

    Теперь у нас есть все NTLM-хэши для аккаунтов домена contoso, и мы можем воспользоваться утилитой Impacket wmiexec для передачи этих хэшей и получения шелла в домене contoso.


    Рисунок 34: Получение шелла

    Меры по предотвращению угрозы

    Вышеуказанные техники, касательно ретранслирования учетных записей и получения контроля над DNS-сервером, были использованы при стандартной конфигурации, которая есть сразу же после установки Windows. Защита от подобного рода атака – отключение преобразование имен LLMNR и NBT-NS, использование подписи в LDAP и привязка канала для LDAP поверх TLS. Что касается printerbug, старайтесь избегать неограниченного делегирования везде, где возможно, и отключите службу принтеров Spooler или заблокируйте исходящее подключение к порту 445 в критически важных системах.

    Роскомнадзор разослал провайдерам письма, в которых сообщает, что до 16 июня необходимо отказаться от применения практики так называемой «эффективной блокировки сайтов» — DNS-резолвинга. Скриншот одного из таких писем за подписью замруководителя РКН по Свердловской области Валерия Щурова разместил в своем Telegram-канале «IT уголовные дела СОРМ россиюшка» IT-консультант Владислав Здольников. По его мнению, такая дата выбрана не случайно — в этот день должна пройти «Прямая линия» президента РФ Владимира Путина.


    Суть происходящего можно коротко описать так. Все провайдеры в РФ обязаны блокировать запрещенные сайты из специального реестра. Единого унифицированного способа для этого не существует, потому что методы исполнения этой нормы закона могут быть разными и зависят от бюджета и аппаратных мощностей провайдера. При этом РКН не делает никаких поблажек и штрафует провайдера на крупную сумму, если какие-то сайты из реестра запрещенных все же открываются («не уследили!»).

    Поэтому провайдерам приходится придумывать разные технические «фокусы», один из которых — использование DNS-резолвинга. DNS — это доменное имя сайта, в котором содержится его фактический IP-адрес в виде набора цифр. А DNS-резолвинг — это постоянная проверка домена на предмет появления в его DNS-записях новых IP-адресов.

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

    Этой ситуацией воспользовались некие «шутники», которые начали выкупать запрещенные РКН и потерявшие своих владельцев по истечении срока регистрации домены. Затем новые хозяева начали прописывать в DNS IP-адреса популярных сайтов — от «ВКонтакте» до сайта, где собирают вопросы на «прямую линию» с Владимиром Путиным. При существующей механике блокировок эти сайты тоже оказывались для клиентов недоступными.

    Более подробно о сути происходящего можно прочитать на сайте Geektimes, где ситуация разобрана детально.

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

    Читайте также: