DNS как точка входа атак: почему поиск адреса решает исход защиты

DNS как точка входа атак: почему поиск адреса решает исход защиты
image

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

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

Почему DNS дает атакующему фору

Межсетевой экран и средства предотвращения вторжений чаще всего оценивают соединения. Пока домен не превратился в IP-адрес, соединение не начнется. Значит, IPS не увидит сигнатуры, проверка шифрованного трафика не увидит рукопожатия, антивирус не увидит файл.

Администраторы тоже помогают атакующему, пусть и невольно. DNS стараются «не ломать», потому что запрет быстро превращается в поток жалоб. Злоумышленник прячет первые шаги атаки в зоне, где всем важно, чтобы «просто работало».

Как злоумышленники используют DNS

DGA у вымогателей и других вредоносов

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

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

  • Домены живут недолго и быстро меняются.
  • Имена плохо читаются и напоминают случайную строку.
  • Репутационные базы часто отстают от атаки.

Фишинг на свежих доменах

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

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

DNS-туннели и кража данных

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

Туннель оставляет характерный след. Запросы идут равномерно, части имени растут, строки выглядят слишком «случайно», один домен получает тысячи уникальных поддоменов. Аналитика DNS ловит такие серии и помогает остановить кражу данных, пока утечка не превратилась в катастрофу.

Управляющие серверы и криптодобыча

Вредоносному коду нужны команды. Даже когда код уже сидит внутри сети, код все равно ищет управляющую инфраструктуру. Обычно поиск начинается с домена, потому что домен легко перенести на новый адрес.

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

Почему одного межсетевого экрана мало

Межсетевой экран отлично контролирует соединения, но DNS стоит раньше соединений. Пока компьютер не получил IP-адрес, компьютер не откроет TCP-сессию или QUIC, не начнет TLS, не отправит HTTP-запрос. Поэтому фильтрация по соединениям пропускает старт атаки.

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

DoH и DoT: как вредонос обходит DNS-контроль

Шифрованный DNS усложнил жизнь защитникам. Приложение может отправить DNS не на корпоративный сервер, а напрямую наружу. Два распространенных варианта. DNS поверх HTTPS уходит на 443 порт и маскируется под обычный веб-трафик. DNS поверх TLS часто уходит на 853 порт.

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

Как пресечь обход через DoH, когда 443 закрыть нельзя

Сеть не может закрыть 443 порт. Поэтому защитники действуют точечно и комбинируют методы. Базовая идея простая. Компания принуждает устройства к корпоративному DNS и режет прямой шифрованный DNS наружу.

  • Блокируем прямой доступ к публичным DNS-резолверам по IP. Чаще всего закрывают известные адреса крупных провайдеров и их подсети, затем оставляют только корпоративные резолверы.
  • Режем DoT на уровне сети. Порт 853 обычно можно закрыть без боли, потому что легитимные сценарии редки.
  • Делаем список разрешенных DoH-сервисов, если бизнес действительно требует DoH. Прокси и межсетевой экран могут проверять домен назначения по SNI и HTTP Host, затем пропускать только разрешенные имена. Трафик на прочие DoH-хосты режут.
  • Включаем глубокий анализ трафика, когда инфраструктура позволяет. DPI распознает типичные запросы DoH к известным путям и форматам, затем режет такие обращения. Метод работает не везде и теряет точность при новых вариантах шифрования, но часто дает эффект.
  • Настраиваем браузеры и ОС через корпоративные политики. В управляемой среде можно отключить DoH в браузерах или заставить браузеры использовать корпоративный DNS. Такой подход часто дает лучший результат, чем гонка за сетевыми признаками.
  • Поднимаем корпоративный DoH внутри периметра. Затем разрешаем DoH только к нему. Пользователь получает шифрование, служба безопасности сохраняет контроль.

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

Для справки можно посмотреть описания протоколов в RFC 8484 для DNS поверх HTTPS и RFC 7858 для DNS поверх TLS.

Ложные срабатывания и как не сломать работу людям

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

Администраторы снижают риск, когда включают контроль постепенно и держат процесс под рукой. Сначала собирают статистику, затем вводят запреты по самым явным классам угроз, затем аккуратно добавляют исключения. Политики по сегментам тоже помогают. Разработке нужен один режим, офису другой, гостям третий.

  • Сначала наблюдаем и собираем базовую картину DNS.
  • Потом включаем запреты по классам угроз, а не «все подряд».
  • Добавляем исключения только после проверки владельца домена и назначения сервиса.
  • Разделяем правила по сегментам и группам пользователей.

Вывод

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

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

Ideco NGFW Novum с модулем DNS Security закрывает архитектурный разрыв между «поиском адреса» и попыткой подключиться к ресурсу. Модуль перехватывает подозрительные DNS-запросы, не отдает IP-адрес и тем самым обрывает цепочку атаки еще до установления сетевого соединения. В результате DNS перестает быть слепой зоной и превращается в управляемый уровень защиты.

Реклама. 18+ Рекламодатель ООО «Айдеко», ИНН: 6670208848, erid:2SDnjezhN65

????
WHITELIST
ПРОЙДЕН
// КАНАЛ В MAX MESSENGER
БЕЛЫЙ СПИСОК
НЕ ОСТАНОВИТ.
МЫ УЖЕ ВНУТРИ.
SecurityLab в MAX — работает там, где другие заблокированы.
Угрозы. Взломы. Уязвимости. Без фильтров.
ЧИТАТЬ В MAX →
FREE
100%
Кибербезопасность · Обучение
УЧИСЬ!
ИЛИ
ВЗЛОМАЮТ
Лучшие ИБ-мероприятия
и вебинары — в одном месте
ПОДПИШИСЬ
T.ME/SECWEBINARS