Проброс интернета по DNS

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

Еще по теме: Техники туннелирования при пентесте

Об авторах

Авторы этой статьи — пентестеры из команды FBK CyberSecurity. Это часть крупнейшей российской аудиторско-консалтинговой группы ФБК (Финансовые и бухгалтерские консультанты). Компания специализируется на услугах в области практической информационной безопасности.

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

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

dnscat2: созданиe C&C через протокол DNS

dnscat2 — довольно популярная утилита, разработанная Роном Боузом, для создания командно-контрольного канала (C&C) через протокол DNS. Включает в себя серверную часть, написанную на Ruby, а также клиент на C. Под Windows существует версия клиента для PowerShell.

Для кодирования данных dnscat2 использует представление в шестнадцатеричном виде. Информация передаются последовательно, то есть значение AAAA аналогично A.AAA, AAA.A и так далее.

Также протокол нечувствителен к регистру, то есть a1 и A1 — одно и то же. Для использования утилиты нужно иметь подконтрольный сервер с доменом, NS-записи которого ссылаются на конкретную машину. Клиент может выбрать, добавлять ли доменное имя или добавлять в сообщение тег dnscat. для отправки данных.

Сообщения представлены как <encoded data>.<domain> или <tag>.<encoded data>. В случае если данные представлены иначе, передаются через неподдерживаемый тип записей или домен неизвестен, сервер может отбросить их либо перенаправить к вышестоящему серверу DNS.

Dnscat2 поддерживает основные типы записей DNS: TXT, MX, CNAME, A и AAAA. Тип ответа соответствует типу входящего запроса:

• TXT-ответ — шестнадцатеричные значения;
• CNAME и MX кодируются так же, как и запрос: либо с префиксом тега, либо с помощью постфикса домена. Это необходимо, потому что промежуточные серверы DNS не будут перенаправлять трафик, если он не заканчивается соответствующим доменным именем;
• A и AAAA — аналогично. TXT, данные без добавления домена или тега.

Протокол работы dnscat2

Сеанс устанавливается клиентом, отправляющим серверу SYN-пакет. Сервер отвечает аналогичным пакетом. Клиент и сервер ведут общение через пакеты MSG. Когда клиент решает, что соединение завершено, он отправляет на сервер пакет FIN, на что сервер отвечает так же. Когда сервер решает, что соединение завершено, он отвечает на MSG от клиента пакетом FIN, и сеанс прекращается.
Из особенностей можно отметить, что сервер dnscat2 может держать несколько сессий, а также поддерживает базовую криптографию (не гарантируя при этом надежности).

Более подробно ознакомиться с протоколом и особенностями утилиты вы при желании можете на странице в репозитории разработчика.

Запуск

Следуя инструкции с GitHub, соберем все, что нам нужно, и попробуем запустить. Для начала на сервере будем отслеживать, что же происходит на 53-м порте. Для этого запустим следующую команду.

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

Аналогично запускаем клиент и видим, что сессия установлена. Отлично, вроде работает!

На сервере наблюдаем следующее.

Отлично, теперь давайте войдем в сессию.

Посмотрим, что утилита нам предоставляет.

Отлично! Для проверки запустим shell.

Круто! Сессия с шеллом создана, хоть и получили не сообщение, а bad sequence. Для выхода из сессии жмем Ctrl-Z и идем в сессию 2.

Создадим файл и запишем в него текст, после чего выведем содержимое и удалим его.

После результата для ввода новой команды нужно еще раз нажать Enter. Не интерактивно, конечно, но не страшно.

Это, конечно, все прикольно, но нам-то необходимо пробросить туннель. Давайте попробуем выгрузить к нам файл по SCP с какого-нибудь сервера через клиент, заодно проверим усредненную скорость. Пробрасываем туннель.

В сессии клиента мы указали, что надо слушать на стороне сервера порт 9090 и от клиента перенаправлять на 178.128.34.53:22. Теперь запустим SCP. В tcpdump можно увидеть общение клиента с сервером.

В конечном итоге мы получили среднюю скорость 0,8 Кбайт/с, фильмы в 4K, конечно, не посмотреть, но пробросить трафик нам все же удалось.

Давайте глянем, что там насчет загрузки.

Как видно на скрине, хоть скорость и была около 10 Кбайт/с, но по факту утилита проработала долгое время.

Сейчас мы запускали клиент на Kali Linux, посмотрим, как он работает в Windows. Здесь все намного печальнее. При том же эксперименте клиент в конце концов смог установить соединение, хоть на это и ушло большое количество попыток.

Однако при попытке пробросить SCP клиент внезапно отваливался.

Мне даже не удалось замерить среднюю скорость канала. Клиент тестировался на Windows 7 и 10 с одинаковыми результатами.

Посмотрим напоследок и на клиент для PowerShell. Для этого нужно перезапустить сервер с параметром —no-cache. В итоге там удалось запустить клиент и даже на какое-то время подружить его с сервером.

Один раз получилось даже так.

Однако в большинстве случаев это приводило к следующей ситуации:

Итого

• Легкая настройка
• Большой набор функций
• Поддержка нескольких сессий
• Компилируемые клиенты
• Нестабильная работа на Windows (если это вообще можно назвать работой)
• Скорость загрузки ~0,6–0,8 Кбайт/с
• Скорость выгрузки ~10 Кбайт/с, но со странной задержкой

Iodine: проброс трафика IPv4 через DNS

Iodine — утилита, разработанная Эриком Экманом. Инструмент позволяет пробрасывать трафик IPv4 через DNS с использованием виртуальных интерфейсов. Состоит из компилируемых сервера и клиента, написанных на C. Клиенты Iodine запускаются только с правами root, но могут работать на разных архитектурах (ARM, IA64, x86, AMD64, SPARC64) многих ОС: Linux, FreeBSD, OpenBSD, NetBSD, macOS и Windows (с драйвером OpenVPN TAP32).

Установка на сервер

Для установки Iodine на сервер, достаточно выполнить команду

А следующая команда запустит сервер.

Запуск клиента

Для начала работы с клиентом необходимо написать что-то вроде:

Теперь на клиенте появился виртуальный интерфейс dns0, клиент получит IP-адрес. Можно обращаться на этот IP, и трафик пойдет через DNS.

Давайте попробуем подключиться по SSH.

Все работает! Вот что показывает tcpdump на 53-м порте сервера Iodine.

Iodine может самостоятельно выбирать наиболее быстрый из доступных видов кодировок (Base128, Base64, Base32) и типов пакетов (NULL, TXT, MX, CNAME и A), благодаря чему скорость получается высокой — около 10 Кбайт/с при использовании SCP.

Протестируем клиент для Windows. Для этого нужно сначала установить драйверы интерфейса TAP/TUN. После этого запускаем приложение, как и в Linux, — из под администратора.

Вроде бы интерфейс настроился, но при попытке передать данные — ничего не происходит.

В общем, все попытки запустить клиент Iodine в Windows не увенчались успехом.

Поглядим на скорость отправки и получения.

Как мы видим, скорость для DNS-туннеля очень хорошая: 9,8 Кбайт/с на отправку и получение через SCP.

Итого

• Автоматический выбор кодировок и типов пакетов
• Запуск только из-под суперпользователя
• Компилируемый клиент
• Необходимость установки драйверов в Windows (а также сомнительная возможность работы с этой системой)
• Скорость загрузки ~9,8 Кбайт/с
• Скорость выгрузки ~9,8 Кбайт/с

dns2tcp: ретрансляции TCP через DNS

dns2tcp — утилита для ретрансляции TCP через DNS. Клиент и сервер — компилируемые, сервер также доступен через APT. Особенность инструмента в том, что он пробрасывает трафик от клиента к серверу.

Запуск

Для начала настроим сервер. Первым делом необходимо отредактировать файл /etc/dns2tcpd.conf.

Теперь запустим сам сервер командой:

Хорошо, теперь идем к клиенту.

Здесь мы указали, что будем пробрасывать SSH (также есть режим для SMTP), указали порт, куда будем стучаться, ну и сам домен. Давайте скорее скачаем файлик.

И походу проверим выгрузку.

Итого

• Компилируемые сервер и клиент
• Работает в режиме проброса сети «внутрь»
• Средняя скорость загрузки ~5 Кбайт/с
• Средняя скорость выгрузки ~13 Кбайт/с

Heyoka: создание двунаправленных туннелей DNS

Heyoka — инструмент, написан на С, причем клиент и сервер — это один и тот же исполняемый файл. Он создает двунаправленный туннель DNS. По словам авторов, утилита работает на 60% быстрее, чем другие аналогичные инструменты (по состоянию на 2009 год). На странице проекта есть готовый исполняемый файл для Windows, а версия для Unix, размещенная на GitHub, была написана сторонним разработчиком.

Запуск

Прочитав описание и инструкции на официальном сайте, попробуем объездить этого скакуна. Начнем с запуска сервера на машине с Windows 10.

Отлично, вроде работает. А теперь запустим клиент.

Опаньки! Кажется, не работает, хотя запускали с правами администратора. Что ж, соберем теперь утилиту для Unix. Аналогично запускаем сервер и тестируем клиент.

Итого

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

OzymanDNS: создание туннелей DNS через SSH

Довольно древний инструмент для создания туннелей DNS через SSH, написанный Дэном Каминским в далеком 2005 году.

Запуск

Для начала использования необходимо установить Perl и библиотеки MIME::Base32 и Net::DNS и обновить менеджер пакетов.

Скачиваем и распаковываем архив.

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

Сервер запускается очень просто:

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

Запускаем клиент.

Видим ошибку: Perl недоволен адресами серверов DNS. Пробуем указать свой.

Видим, что кушает сервер, но соединение не создалось.

Под впечатлением от статей и видео, где люди показывали, как у них прекрасно все работает, мы провели в возне с утилитой OzymanDNS не один час, но так и не смогли заставить ее передать хотя бы бит информации. Возможно, у кого-то из читателей хватит на это терпения, но есть ли смысл? У того, кто смог соединиться через OzymanDNS, скорость была 17 Кбит/с и работа была нестабильной, а если учесть скудный набор функций, то можно смело переходить с этой утилиты на что-то другое.

Результаты

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

Название	Входящая скорость, Кбайт/с	Исходящая скорость, Кбайт/с	Достоинства	Недостатки
dnscat2	0,7	10	Легкая настройка, широкий набор функций, поддержка нескольких сессий	Компилируемые клиенты, нестабильная работа в Windows
Iodine	9,8	9,8	Автоматический выбор кодировок и типов пакетов, высокая скорость работы	Запуск только с правами суперпользователя, компилируемый клиент, необходимость установки драйверов для Windows
dns2tcp	5	13	Не найдено	Компилируемый клиент, работает в режиме проброса сети «внутрь»
Heyoka	NaN	NaN	Не найдено	Сложности с запуском
OzymanDNS	NaN	NaN	Не найдено	Сложности с запуском

В результате наиболее распространенная проблема — это необходимость компилировать клиент и нестабильная работа в Windows. Есть ли какой-то выход?

А вот об этом мы поговорим уже в другой раз.

Еще по теме: Лучшие площадки для практики взлома