Глава 13. Безопасность DNS

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

DNS это одна из наиболее важных и интегрированных частей сетевого взаимодействия в Интернете, которая разрешает доменные имена в IP адреса.

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

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

Итак, давайте разберёмся как работает DNS.

Давайте запросим соответствующую запись DNS для google.com, воспользовавшись утилитой nslookup, как это показано на следующем снимке экрана:

Теперь, раз наш пользователь выполнил запрос для искомой записи DNS, DNS resolver в нашей системе отыщет эту запись DNS чтобы выполнить выборку IP адреса из имеющегося в его системе локального кэша; когда её там нет, он запросит свой сервер DNS, обычно предоставляемый его ISP (Internet Service Provider, поставщиком интернет услуг) выполнить проверку для любого элемента записи DNS.

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

Приводимый ниже снимок экрана при помощи Wireshark отображает как выглядят запросы DNS в сетевой среде:

На нашем предыдущем рисунке возвращаются две различные записи, A и AAAA, причём A возвращается для IPv4, а AAAA возвращается для IPv6.

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

Теперь, как мы понимаем по своему предыдущему разделу, для разрешения значений доменных имён осуществляется рекурсивный метод поиска DNS, однако как всё это происходит на уровне Интернета? Что представляют собой ключевые компоненты, которые включены в весь этот поиск? Для ответа на эти вопросы, давайте сначала разберёмся со структурой DNS.

DNS работает основываясь на принципе распределённых ответственностей для различных серверов имён, которые играют ключевую роль в разрешении доменных имён. Далее, мы осознаём что Интернет гигантский и сопровождение списка доменов практически не реально для одного сервера. Следовательно, мы следуем подобной дереву иерархической структуре, в которой необходимые ответственности распределены для каждого узла, а сама структура представлена в виде растущего сверху вниз дерева. Сам протокол DNS обычно работает со службой UDP (User Datagram Protocol) и портом 53.

Такая растущая сверху вниз древовидная иерархическая структура представлена корневым сервером имён (root nameserver) в своей вершине, множеством таких компонентов как сервер имён домена верхнего уровня и авторизованными серверами имён в промежутке, а внизу сами листья представляют законченные доменные имена. Однако перед этим, давайте вначале поделим свой домен чтобы разобраться с общей структурой DNS.

Домен составляется из множества параметров; давайте осознаем это на неком образце. Допустим, существует полное доменное имя с названием test.domain.com, в котором test это один логический элемент, значение domain это другая отдельная запись, а com иной логический элемент. Все вместе они составляют общее доменное имя.

Итак, на текущий момент мы разобрались со структурой DNS и давайте поймём как всё это составляется откликается на соответствующие запросы DNS:

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

Теперь давайте разберёмся со всеми этими компонентами DNS при помощи примера. Допустим, пользователь желает открыть test.xyz.in; потребуется преодолеть такой процесс:

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

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

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

Для изучения ВТЫ мы будем следовать тем же самым подходом тестирования проникновения:

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

Теперь нам известно что DNS работает по порту 53; следовательно, мы в основном сосредоточимся только на этом порту.

 

Выявление записей имён

Давайте с помощью утилит nslookup или dig отыщем все имеющиеся записи доменныз имён, как это отражено на снимке экрана ниже:

Наш предыдущий рисунок выставляет полные сведения сервера имён о домене google.com. Выставление всех сведений целиком здесь не представляется возможным; следовательно, оставляем вам это для ваших практических лабораторных занятий.

 

Захват баннера

Для получения баннера DNS в diag доступен запрос version.bind, а в инструменте NMAP (Network Mapper) --script=dns.nsid, как это показано на следующем снимке экрана:

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

 

Выявление записей имён серверов и соответствующих поддоменов

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

Теперь мы успешно перечислили весь необходимый объём сведений для выполнения сканирования имеющихся уязвимостей.

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

Как показано на Рисунке 13.7, включены все имеющиеся сценарии DNS и весь необходимый объём относящихся к уязвимостям сведений в этом сервере DNS будут выведены дампом на экран. Итак, давайте обсудим все уязвимости по одной.

 

DNSSEC

DNSSEC это очень существенный компонент реализации безопасности DNS, защищающий DNS от таких атак на DNS как прослушивание DNS. Наша утилита NMAP выявляет реализацию DNSSEC, как это показано на следующем снимке экрана:

Как видно из Рисунка 13.8, очевидно что наша текущая архитектура не поддерживает DNSSEC NSEC3. Давайте проследуем к следующей очень занимательной уязвимости с названием вынюхивания кэша DNS.

 

Вынюхивание кэша DNS

Прослушивание кэша DNS это атака, которая запрашивает имеются ли кэшированными в серверах DNS определённые домена или нет. Эта атака обычно выявляется в нижней категории раскрытия сведений, однако в промышленных средах такой запрос может оказаться очень полезным, ибо он определяет какие сайты посещаются чаще всего. На идущем далее снимке экрана отражены кэшированные в сервере имён Google сайты:

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

 

Простой перебор

Атака простым перебором (brute-force) осуществляется для раскрытия скрытых доменов, которые не обнаружены в непосредственном поиске механизмами поиска, однако доступны через непосредственный URL доступ. Данная атака оказывается очень удобной в процессе упражнений красной команды. Приводимый ниже снимок экрана отображает такой обнаруженный домен:

Как мы видим ни Рисунке 13.10, может оказаться, что некоторые домены могут оказываться недоступными потому как мы выполняем поиск простым перечислением DNS и их записи могли бы присутствовать в данном кэше DNS ранее. Таким образом, нам необходимо отфильтровать такие домена на этапе атаки.

В настоящее время мы лишь выявили такие уязвимости через утилиту NMAP, однако поощряем вас изучать это вопрос также и далее при помощи сканирования уязвимостей при помощи Nessus.

 

Передача зоны DNS

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

Однако зачастую в организациях серверы DNS не настроены должным образом, оставляя открытыми злоумышленникам потайные ходы для считывания и доступа ко всем записям файла зоны. Таким образом, для того чтобы осуществить это, существует доступными великое множество средств, например, dig, host, dnsrecon и dnsenum, тем не менее, для демонстрационных целей мы оставим всё по- простому и воспользуемся утилитой host, из Kali Linux. Приводимый следом снимок экрана отображает присутствующие в нашем целевом домене серверы имён:

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

Как видно из Рисунке 13.12, наш сервер DNS не настроен должным образом, а следовательно злоумышленник обладает возможностью полностью выделить записи файла зоны и затем воспользоваться ими для формирования атак в данной сетевой среде.

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

В данном разделе мы попробуем продемонстрировать различные атаки DoS (Denial of Service) и DDoS (Distributed Denial of Service), при которых злоумышленник отправляет запросы DNS для увеличения загруженности сервера или вызывает более поздний отклик службы, а то и вовсе отсутствие оного для подключённых к домену пользователей. Этого можно достигать при помощи множества уровней атак DNS, таких как наводнение DNS или при помощи атак роста DNS.

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

Давайте попытаемся разобраться с этим при помощи небольшой схемы, которая показана ниже:

Итак, теперь мы разобрались с атакой DoS на имеющиеся записи NX. Сейчас давайте взглянем на DoS атаку DNS на практике, как это отражено на идущем следом снимке экрана:

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

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

Атака наводнения DNS это симметричная DDoS атака, при которой злоумышленник истощает ресурсы машины сервера DNS, такие как загруженность ЦПУ, через отправку гигантского числа запросов UDP по множеству каналов, именуемых ботнетами. Значения числа и размера запросов настолько интенсивные, что средства авторизованного сервера DNS прекращают работу, а если какие- то прочие пользователи пробуют разрешить какой бы то ни было домен, они никогда не получат отклик. Следующий снимок экрана демонстрирует атаку затопления DNS:

Как отражено на на предыдущем рисунке, после того как злоумышленник приступает к отправке числа N запросов DNS, вскорости наш авторизованный сервер имён перестаёт откликаться.

Ускорение DNS (DNS amplification) это асимметричная атака, при которой целью выступает её жертва. Злоумышленник подделывает IP адрес жертвы и приступает к запросам открытых серверов DNS, а как только преобразователь DNS получает такие запросы, он начинает отвечать на IP адрес поддельной жертвы. Такие запросы DNS настолько велики и интенсивны, что имеющаяся сетевая инфраструктура жертвы вскоре перестаёт отвечать на запросы и переходит в режим DoS. Следующий снимок экрана показывает атаку усиления DNS.

Как видно из предыдущего рисунка, для осуществления атаки ускорения DNS имеются доступными в Интернете разнообразные инструменты и сценарии. Для целей демонстрации мы воспользуемся написанном на Python сценарием Bash Scapy, который свободно доступен для целей тестирования на GitHub. Следующий снимок экрана демонстрирует атаку усилением DNS:

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

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

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

Итак, как же работает атака подмены DNS в среде реальной практики? Давайте разберёмся с основами данной атаки при помощи простой схемы, которая отображена на следующем рисунке:

Давайте тщательно рассмотрим свой предыдущий рисунок следующим образом:

Теперь, когда мы разобрались с подменой DNS, давайте осуществим подделку DNS при помощи инструментария Ettercap:

Мы можем наблюдать, что искомый вебсайт (www.google.com) не подменён нашим вебсайтом, а жертва перенаправлена на фальшивый вебсайт, размещённый по портам 80 и 443:

Теперь, когда мы разобрались с подменой и угоном DNS, давайте перейдём к другой весьма увлекательной атаке, имеющей название туннелирования DNS, которая во все времена была фаворитом злоумышленников и оказывается очень полезной при эксфильтрации, поскольку позволяет избегать SOC (Security Operations Centers, центров управления безопасностью) и мониторинга межсетевых экранов.

Зачастую в организациях не разрешён исходящий доступ или же он допускается исключительно через HTTPS сквозь серверы посредников (прокси). Однако вне зависимости от того насколько строго настроены правила межсетевого экрана и ACL (Access Control Lists, списки контроля доступа), запросы DNS обычно допускаются через установленные межсетевые экраны. Злоумышленники могут злоупотреблять такими неверно настроенными правилами службы DNS создавая туннель непосредственно через скомпрометированные рабочие станции или серверы для эксфильтрации конфиденциальных сведений в свои серверы, размещаемые вовне в Интернете.

Данный подход аналогичен иным туннелируемым протоколам, таким как HTTP, HTTPS, TCP и тому подобным, однако в данной ситуации таким протоколом выступает DNS, а устанавливаемый канал это UDP.

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

Тем не менее, прежде чем мы окунёмся в практическую демонстрацию, давайте для начала поймём те шаги, которые вовлекаются в создание DNS туннеля и обхода контроля межсетевого экрана сетевой среды:

Как мы видим из своего предыдущего рисунка, для создания DNS туннеля были выполнены следующие шаги:

Давайте продемонстрируем туннелирование DNS при помощи DNSCAT: