Dns туннелирование что такое

DNS-tunneling

Материал из Xgu.ru

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

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

Содержание

[править] iodine

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

Названием программа обязана двум фактам:

Для создания туннеля необходимо с одной стороны поднять сервер iodined (со стороны Интернета), а с другой стороны — с той, которая находится внутри сети, за брандмауэром — клиент iodine.

В проверочном режиме в качестве аргумента клиента указывается домен, в виде запросов по которому будет представляться туннелируемый трафик, а также обязательно IP-адрес iodine-сервера.

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

Для построения туннеля не в проверочном режиме, а в полноценном, необходимо обязательно указать, что сервер iodined является NS для какой-то определённой зоны.

Например, пусть это будет зона ns.xgu.ru. Тогда в описании зоны xgu.ru должны присутствовать строки (имена условные):

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

Со стороны сервера:

Со стороны клиента:

На клиентской стороне будет установлен адрес 192.168.0.2 (последний байт плюс 1).

Если всё пройдёт успешно, то должны будут появиться сообщения:

Адреса и имена будут другими, а сообщения такими же.

После поднятия туннеля на клиентской машине появится соответствующий сетевой интерфейс. Его можно будет использовать как и любой другой — осуществлять маршрутизацию, трансляцию адресов и так далее.

[править] Пояснение к схеме DNS-туннелинга

Ноутбук клиента, осуществляющего DNS-туннелинг находится за брандмауэром. Клиент имеет возможность пользоваться кэширующим DNS-сервером. Клиент направляет кэширующему серверу запросы по зоне iodine.xgu.ru. Сервер пытается их для него разрешить, для чего выполняет рекурсивную обработку, как предписывается стандартом DNS.

В конечном счёте запросы доходят туннелинг-серверу, который находится по адресу, указанному в качестве NS для зоны iodine.xgu.ru. Туннелинг-сервер обрабатывает их. В частности, он может преобразовать их в IP-трафик и отправить дальше. Обратный трафик преобразуется в DNS-ответы и отправляется кэширующему серверу (который в свою очередь передаёт их туннелинг-клиенту).

Таким образом организуется обмен IP-пакетами ( — — — ) поверх DNS-трафика (————).

Источник

Blogerator.org

Эксклюзивные ИТ-новости, обзоры и интервью

DNS Tunneling: проходим сквозь любые брандмауэры

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

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

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

Общая теория

Несмотря на то, что многие узкоспециализированные программы такого рода (подробно обсуждаемые далее) работают по различным схемам — все они эксплуатируют одну центральную идею, применяемую для обхода стандартных средств сетевого контроля. Речь идёт об инкапсуляции своего служебного трафика в штатные DNS-запросы с последующей сборкой скрытно полученных TCP/IP-пакетов уже позади заградительного барьера на шлюзе.

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

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

Перечислив этапы развертывания такой спецсвязи, кратко остановимся на некоторых деталях реализации метода туннелирования, а также на общей специфике службы имен, которые вместе делают возможным подобный транзит:

Сфера применения

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

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

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

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

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

Dnscat

Эта небольшая популярная утилита является частью сервисного DNS-пакета nbtools, её развитие выделено в условно отдельный проект, поддерживаемый создателем Роном Бовисем. Как видно из названия, Dnscat пытается дублировать функциональность уже привычного всем базового сетевого инструмента netcat, за тем важным отличием, что здесь весь трафик транслируется посредством DNS-протокола. По большей части, все возможности Dnscat сводятся к двум моментам:

Утилита поставляется вместе с исходниками в составе пакета nbtool (сразу с клиентской и серверной частью), и может быть скомпилирована под Linux, FreeBSD и Windows.

NameServer Transfer Protocol (NSTX) — одна из самых известных и фундаментальных реализаций идеи DNS-туннелинга. Данный комплекс создаёт двунаправленный IP-туннель для передачи данных на базе любого легитимного транзитного DNS-трафика.

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

Для разовой проверки почты или одного-двух твитов приобретать новую prepaid-карту чаще всего нецелесообразно, поэтому я выбрал иной путь. В таких ситуациях с помощью NSTX он пробрасывает IP-трафик к своему DNS-серверу (выполняющего роль принимающего прокси-сервера для выхода в большой Интернет). При этом, согласно его богатому международному опыту, в подобных сетях даже в гостевом режиме практически всегда доступен DNS-резольвинг. Собственно, именно для личных нужд и был разработан этот программный пакет.

В силу популярности именно этого варианта туннелирования, совсем немного остановлюсь на установке и настройке его клиента (на примере Debian). Для начала устанавливаем весь пакет NSTX:

# apt-get install nstx

После чего в файле-настройке /etc/default/nstx следует сначала добавить адрес принимающего DNS-сервера (параметр NSTX_DOMAIN ), а затем включить работу этого демона путем присвоения обоим параметрам ifup_tun0 и start_nstxd значения «yes».

Дополнительно нужно сконфигурировать и новый системный интерфейс:

iface tun0 inet static
address 10.0.0.1
netmask 255.0.0.0

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

Dns2tcp

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

Heyoka

Это выделяющийся на фоне аналогов инструментарий, который позволяет создавать двунаправленные TCP/IP туннели на основе использования всё того же DNS-трафика.

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

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

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

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

Вторая особенность — Heyoka полностью ориентирован на ОС Windows. У этой утилиты нет конфиг-файлов, она полностью настраивается через консоль посредством аргументов командной строки. Один и тот же головной exe-файл может быть запущен как в режиме master (это сервер в нашей классификации, ключ –m ), равно как и slave (клиент, ключ –s ), позволяя пробрасывать любой трафик с локального на заданный удаленный порт. Ниже привожу пример запуска этой утилиты в режиме клиента:

Этот проект предоставляется в исходных кодах и распространяется по лицензии GPLv2.

Iodine

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

OzymanDNS

Этот инструмент от очень известного специалиста по безопасности Дэна Каминского (Dan Kaminsky), которого часто величают как «DNS guru». Главная особенность OzymanDNS — это изначальная «заточенность» на проброс именно SSH-трафика. Автор утилиты призывает далее в зависимости от конкретной необходимости, туннелировать необходимый трафик уже через SSH (для примера, вот настройка работы с Tor через туннель SSH/DNS).

Сам Дэн выполнил черновую реализацию и тестирование концепции «SSH через DNS» (proof-of-concept), а также открыл исходники своего проекта (кстати, полностью написанного на Perl). У OzymanDNS уже появились последователи — независимые сторонние доработки. В частности, я хотел бы порекомендовать обновленную неофициальную версию этого инструмента, где автор реализовал иной алгоритм переупаковки трафика, который по его словам в среднем работает в два раза быстрее оригинального. Также интересен вариант совместного использования браузера и OzymanDNS, которые можно настроить работать через SSH-прокси и браузерные плагины со стороны клиента (такие как ProxySwitchy для Google Chrome или FoxyProxy для Mozilla Firefox).

OzymanDNS написан на Perl, поэтому он может быть запущен во всех средах, где поддерживается этот интерпретатор (оригинальный набор скриптов был написан и протестирован в Linux). На Mac OS X можно использовать клиент в сочетании с заранее установленными Xcode и всеми необходимыми Perl-модулями (как минимум нужны MIME::Base32 и Net::DNS ). Для клиента в Windows можно взять Cygwin (в котором самостоятельно скомпилировать и настроить всю рабочую среду) или проект Strawberry Perl. Кроме всего этого, для любой из клиентских сред должны быть установлены и настроены внешние сервера SOCKS 5 и SSH.

Прочитать подробную инструкцию по установке OzymanDNS для множества ОС можно здесь, в частности там рассматриваются оба варианта: как стандартный «SSH поверх DNS», так и упомянутый продвинутый — «Socks через SSH и всё это поверх DNS».

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

Источник

ИТ База знаний

Полезно

— Онлайн генератор устойчивых паролей

— Онлайн калькулятор подсетей

— Руководство администратора FreePBX на русском языке

— Руководство администратора Cisco UCM/CME на русском языке

— Руководство администратора по Linux/Unix

Навигация

Серверные решения

Телефония

FreePBX и Asterisk

Настройка программных телефонов

Корпоративные сети

Протоколы и стандарты

Чем опасен DNS Tunneling?

Снова про информационную безопасность

Онлайн курс по Кибербезопасности

Изучи хакерский майндсет и научись защищать свою инфраструктуру! Самые важные и актуальные знания, которые помогут не только войти в ИБ, но и понять реальное положение дел в индустрии

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

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

Принцип работы DNS туннелирования на пальцах

Пять шагов DNS туннелирования:

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

Когда возник данный тип атак?

Впервые подобный вид атак был упомянут в рассылке Buqtraq неким Оскаром Пирсоном в апреле 1998 года.

Основные опасности DNS туннелирования

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

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

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

Утилиты для создания DNS туннеля:

Если вам хочется посмотреть, уязвима ли ваша инфраструктура к такому виду атак, то можете попробовать несколько утилит из списка ниже (только на свой страх и риск). Все эти утилиты реализуют IP-over-DNS механизм атак.

Утилиты для мониторинга DNS туннеля:

Онлайн курс по Кибербезопасности

Изучи хакерский майндсет и научись защищать свою инфраструктуру! Самые важные и актуальные знания, которые помогут не только войти в ИБ, но и понять реальное положение дел в индустрии

Источник

Лазейка под файрволом. Тестируем пять популярных средств, которые пробрасывают интернет по DNS

Содержание статьи

Об авторах

Среди того, чем занимается FBK CyberSecurity:

А еще ты, возможно, уже читал статьи в «Хакере», написанные одним из специалистов FBK CS и соавтором этого материала.

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

Xakep #234. Взломать iPhone

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

dnscat2

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

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

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

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

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

Из особенностей можно отметить, что сервер dnscat2 может держать несколько сессий, а также поддерживает базовую криптографию (не гарантируя при этом надежности).

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

Запуск

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

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

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

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

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

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

Здорово! Для проверки запустим shell.

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

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

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

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

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

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

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

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

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

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

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

Однако в большинстве случаев это приводило к ситуации на скриншотах ниже.

Итого

10 Кбайт/с, но со странной задержкой

Iodine

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.

Итого

dns2tcp

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

Запуск

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

Окей, теперь идем к клиенту.

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

А заодно проверим и выгрузку.

Итого

Heyoka

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

Запуск

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

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

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

Итого

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

OzymanDNS

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

Запуск

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

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

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

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

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

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

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

Результаты

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

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

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

Михаил Фирстов

Работаю пентестером в FBK Cybersecurity. Специализируюсь на услугах в области практической информационной безопасности.

Источник