Основные угрозы для бизнеса dns

Обновлено: 07.07.2024

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

Платформа хоста (ОС, файловая система, стек коммуникационных протоколов).
ПО DNS (name-сервера, resolver’а).
Данные DNS (зонный файл, конфигурационный файл).

Рассмотрим угрозы и возможные подходы к защите для окружения DNS .

Угрозы и обеспечение защиты платформы хоста

Угрозы для платформы, на которой выполняется ПО DNS, не отличаются от угроз, с которыми сталкивается любой хост в Интернете. Рассмотрим с точки зрения сервисов DNS эти общие угрозы и их воздействие на DNS:

Обеспечение защиты и/или уменьшению угроз для платформы хоста DNS состоит в следующем:

использование безопасной ОС;
безопасное конфигурирование и развертывание ОС.

Угрозы ПО DNS

Угрозы для самого ПО DNS могут серьезно повлиять на безопасность. Большинство общих проблем, связанных с ПО, следующие:

Угроза Т5: ПО DNS (name-сервер или resolver) могут иметь такие уязвимости, как переполнение буфера, в результате чего станут возможны разного рода атаки типа DoS-атак и получение неавторизованного доступа.

Наилучшими подходами к обеспечению защиты ПО DNS являются следующие:

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

Угрозы для данных DNS

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

Значения параметров для некоторых ключевых полей в ресурсных записях различных типов.
Наличие некоторых ресурсных записей в зонном файле.

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

DNS-атаки: защита бизнеса или анализ рисков DNS

DNS-атаки - старая, но всё ещё актуальная область хакерских исследований, представляющая во многих случаях серьёзную опасность сегодня практически для любого бизнеса. Учитывая, что UDP-протокол DNS почти не изменился с начала 80-ых, и разрабатывался он без какого-либо учёта безопасности, а современные IT-средства и умы хакеров значительно улучшились, проблема становится ещё актуальнее. В особенности, актуальной в контексте данной IT-угрозы становится защита бизнеса. Существующие в современном мире виды DNS-атак могут привести не только к воровству финансовой информации (как частного лица, так и компании) или коммерческой тайны, а и к воровству самих финансов, как явно и буквально (например, через подмену сетевых пакетов в системе ДБО), так и косвенно (коммерческая тайна и конкуренты). Не брать в расчёт данный тип атак, значит, совершить серьёзную ошибку в стратегическом планировании бизнеса компании.

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

Анализ рисков DNS

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

Итак, таблица анализа рисков:

Описание угрозы

Вероятность (сложность) реализации

Ущерб

Несоответствие законодательству по ПДн для новых ИСПДн. ( п.8.10 (требование ЗИС.15) Приказа ФСТЭК №21)

Для новых ИСПДн: признание ИС несоответствующей; приостановление работы ИС.

( внутри сегмента сети пользователя)

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

Перехват всего трафика пользователя.

Подмена любых сетевых запросов.

( работает в случае dns-запроса, отсутствующего в текущем кэше DNS; условие нахождения внутри сети организации отсутствует)

( не использует ресурсы интрасети; не требует нахождения внутри сети организации)

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

Для случая наличия собственного DNS-сервера в организации: атаки типа DDoS на DNS-сервер: простой DNS-флуд; рекурсивная DNS-атака; Garbage-атака. В итоге: полное падение DNS-сервера.

(в случае наличия собственного DNS-сервера; не требует нахождения внутри сети организации)

Высокий ущерб нарушения работы DNS-сервера организации (несложно восстановить).

В случае отсутствия резервного DNS нарушается работа всей сети.

Пункты 2-5 основаны на лёгком формировании DNS-UDP-пакета с возможностью легко вставить в пакет произвольные данные по IP, ID и т.д. Более подробное описание угроз пунктов 2-6 содержится в предыдущей статье DNS-атаки: полный обзор по схемам атак.

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

Методы защиты от DNS-атак

Методы защиты сводятся к двум основным направлениям: правильной настройка DNS-сервера и к использованию протокола DNSSec. Опишем оба варианта.

Итак, необходимые (но не достаточные) настрройки DNS-сервера :

1. Игнорирование или уменьшение степени доверия к любым DNS-ответам, явно не относящихся к отправляемым запросам (параметры BIND8/9/10 позволяют это сделать). Снижает риски 3, 4 (частично - 6).
2. Использование случайных портов для отправки/получения запроса. Существенно снижает риски 3, 4.
3. Запрет обработки рекурсивных запросов, поступающих не от доверенных клиентов (не из инстрасети / её доверенной части).
Становится вопрос превентивности, т.е. выгодности внедрения нового протокола для бизнеса. Надо сказать, что сам протокол является открытым, бесплатным и поддерживается уже почти всеми современными DNS-серверами (включая BIND) и клиентскими ОС (включая Windows 7 и Windows 2008 Server).

Итак, проблемы внедрения DNSSec :
- Протокол TCP/IP должен поддерживать новый DNS Resolver, умеющий работать с DNSSec.
- Возрастание нагрузки на сеть: траффик от подписанных ЭЦП запросов возрастает в 6-7 раз.
- Возрастание нагрузки на процессор DNS-сервера (генерация и проверка ЭЦП требует множество ресурсов), так что может потребоваться замена DNS-серверов на более мощные (раза в
Как видно из представленного списка, проблемы внедрения DNSSec связаны с верной настройкой ПО (что решается без труда) и возросшими требованиями по аппаратным ресурсам DNS-серверов, а также интернет-канала (хотя это во многом зависит от величины организации).

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

Автор: Christopher Makarem

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

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

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

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

Рисунок 1: Схема отравления DNS-кэша

Примеры отравления DNS-кэша

Подделка слепого ответа через атаку «дней рождения»

В протоколе DNS не предусмотрено подтверждение подлинности ответа на рекурсивные итеративные запросы. Проверяется только 16-битный идентификатор транзакции, IP-адрес источника и целевой порт, присутствующие в ответе. До 2008 года все DNS-резольверы использовали фиксированный порт 53. Таким образом, кроме идентификатора транзакции, вся информация, нуждающаяся в подделке во время ответа, была предсказуема. Атаки на DNS, эксплуатирующие эту слабость, были основаны на «парадоксе дней рождения». В среднем требовалось 256 попыток (два в восьмой степени) на угадывания идентификатора транзакции. Для успешной реализации атаки поддельный DNS-ответ должен поступить на целевой резольвер перед легитимным ответом. Если легитимный ответ поступит первым, то будет закэширован и до истечения времени TTL резольвер не будет отправлять запрос с тем же самым именем домена. Таким образом, злоумышленник не сможет отравить кэш для этого домена в течение времени TTL.

Эксплоит Каминского

Перехват трафика

Многие идеи по повышению безопасности DNS связаны с рандомизацией исходного порта, например, кодирование по алгоритму 0x20 XOR или WSEC-DNS в зависимости от ассиметричной доступности компонентов, используемых для аутентификации. Другими словами, эти меры безопасности основываются на неопределенности, а не конфиденциальности при помощи аутентификации или криптографии. Эти техники направлены на защиту от слепых атак, описанных выше. Однако при использовании данных методов DNS остается уязвимым к тривиальным атакам, связанным с компрометированием серверов и сетевыми перехватчиками, для выяснения нужной информации и последующей реализации атак, описанных выше. В этом случае слепое угадывание уже не требуется. Даже в средах, где используются коммутаторы, техники типа ARP poisoning и другие схожие методы могут использоваться для перенаправление всех пакетов в нужное место для выяснения необходимой информации и обхода методов, связанных с рандомизацией и неопределенностью.

Защита от отправления DNS-кэша

DNSSEC

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

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

Следуйте за нашими новостями в удобном для вас формате

Неправильная конфигурация DNS-серверов — угроза безопасности

7 апреля 2016 года

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

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

Безусловно, некорректная настройка DNS-серверов, позволяющая обрабатывать внешние AXFR-запросы, не является чем-то новым в сфере информационной безопасности: это весьма распространенное явление, которое можно отнести к категории "security misconfiguration". Вместе с тем механизм поиска DNS-серверов, способных обрабатывать такие запросы, наряду с технологией обнаружения поддоменов с применением ресурсов поисковых систем давно автоматизированы. В частности, все эти функции реализованы в утилите dnsenum, входящей в набор инструментов специального дистрибутива Kali Linux, предназначенного для выполнения «тестов на проникновение», что свидетельствует об интересе к такому вектору атак. Исходя из этого можно сделать вывод: делегирование задач по администрированию DNS-серверов сторонним компаниям — вполне обоснованная практика, однако заботиться о собственной безопасности должны все-таки сами владельцы интернет-ресурсов. Принцип «доверяй, но проверяй» в этом отношении весьма актуален.

Специалисты «Доктор Веб» информировали компанию easyDNS Technologies, Inc. о выявленной уязвимости в конфигурации их DNS-сервера, и в настоящий момент принимаются меры по исправлению некорректных настроек.

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