В образовательных целях рассматривается возможность туннелирования TCP/IP-трафика через стандартные DNS-запросы. Хочу отметить, что сокращенная и немного иначе построенная статья на эту тему была опубликована мною ранее под названием Крякер интернета на базе DNS-тунелинга (возможно, какие-то детали будут лучше изложены в той версии статьи, поэтому выбирайте).
Исходной причиной для написания этой статьи стало наблюдение в последнее время огромного количества вирусов и троянов, которые применяют DNS-протокол в его нештатном режиме работы. Использование стандартных DNS-запросов в качестве транспорта, позволяет им эффективно преодолевать практически любые защитные системы, заботливо воздвигнутые администраторами на шлюзе в корпоративную сеть. В самом деле, DNS-трафик плохо (или почти никак) не анализируется стандартными IDS-системами, также как открыт для прохода в обе стороны практически на любом брандмауэре, что позволяет вражеской колонии из зловредов, находясь даже в глубоком тылу не терять связь со своей «большой родиной».
Вместо скучного дизассемблирования отдельных образцов и изучения их алгоритма работы мы поступим несколько иначе. Считаю, что методически гораздо полезней попробовать самостоятельно настроить и прокинуть подобный DNS-туннель в свою локальную сеть с помощью широко известных специализированных инструментов, чтобы на практике изучить всю потенциальную опасность и специфику этого метода связи.
Несмотря на то, что многие узкоспециализированные программы такого рода (подробно обсуждаемые далее) работают по различным схемам — все они эксплуатируют одну центральную идею, применяемую для обхода стандартных средств сетевого контроля. Речь идёт об инкапсуляции своего служебного трафика в штатные DNS-запросы с последующей сборкой скрытно полученных TCP/IP-пакетов уже позади заградительного барьера на шлюзе.
Переходя к конкретике, на примере типового алгоритма работы этой схемы предлагаю пошагово рассмотреть типичные этапы развертывания, а также принципиальное устройство такого DNS-туннеля:
Несмотря на кажущуюся необычность схемы, всё довольно просто: метод напоминает идеи стеганографии, реализованные на базе DNS.
Перечислив этапы развертывания такой спецсвязи, кратко остановимся на некоторых деталях реализации метода туннелирования, а также на общей специфике службы имен, которые вместе делают возможным подобный транзит:
После ознакомления с формальной логикой работы механизма DNS-туннеля, предвижу вполне закономерный вопрос читателя: где может использоваться столь специфический и замысловатый способ связи?
Кроме уже упомянутых армии ботов и троянов, DNS-туннелинг активно используют для обхода как персональных, так и корпоративных средств защиты по всему миру. В частности, я лично был впечатлён случаем, когда наблюдал ситуацию применения такой технологии для проброса ICQ/Jabber, несмотря на практически полную блокировку входящего трафика в крупную государственную сеть.
Интересно, что в этом случае фильтрация и мониторинг сети осуществлялись как местным админом регионального филиала, так и московским специалистом из центрального офиса этой федеральной государственной структуры, где и обеспечивалось физическое подключение к интернету. Несмотря на использования разных технологических платформ на этих двух уровнях и принципиально различных методов фильтрации — механизм DNS-проброса на этом режимном объекте «с ограниченным уровнем доступа» работал очень надежно, хотя и относительно медленно (впрочем, на скорости достаточной, для сидения этого скучающего сотрудника в чате).
Ещё одна область для «незаконного творчества» — это различные интернет-провайдеры, многие из которых предоставляют бесплатный доступ к своим локальным сетям или к собственным информационным сайтам, даже когда у абонента нет денег на его счету. В большинстве случаев технически это ограничение реализуется в виде фильтрации IP-адресов на пограничном брандмауэре, четко отделяя адреса своей локальной сети от Интернета.
Для чего используется эта повальная уязвимость — для анонимного серфинга, бесплатного чтения почты, чатов или управления зомби-сетями — вопрос, который имеет вторичное отношение к рассматриваемому нами сегодня сугубо техническому аспекту DNS-туннелинга. Поэтому объяснив в общих чертах, как это работает и где это может быть применено, позвольте перейти к обзору самых распространенных инструментов для создания и тестирования подобных туннелей, с моими краткими пояснениями специфики каждого из них.
Эта небольшая популярная утилита является частью сервисного DNS-пакета nbtools, её развитие выделено в условно отдельный проект, поддерживаемый создателем Роном Бовисем. Как видно из названия, Dnscat пытается дублировать функциональность уже привычного всем базового сетевого инструмента netcat, за тем важным отличием, что здесь весь трафик транслируется посредством DNS-протокола. По большей части, все возможности Dnscat сводятся к двум моментам:
–e
), а также перенаправлять при этом вывод запускаемых команд на инициирующий соединение хост. Интересной особенностью этой утилиты является то, что она может быть достаточно всеядной. С одной стороны, она позволяет работать через обычные рекурсивные DNS (по умолчанию) с авторитативным сервером «магического домена», с другой — есть режим прямого подключения к DNS-серверу, в этом случае можно работать в стандартном режиме клиент-сервер (запуск через аргумент --dns
). В последнем варианте понижается скрытность и универсальность работы утилиты, но в качестве приятного бонуса резко возрастает скорость и надежность соединения, кроме того, на принимающей соединение стороне уже не нужно иметь именно авторитативный сервер имен.
Утилита поставляется вместе с исходниками в составе пакета 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-сервера, что не намного сложнее, чем вышеописанная настройка клиента.
Почти полный аналог NSTX, за тем исключением, что он пробрасывает лишь TCP-трафик. Автор этой утилиты Оливер Димбауэр постарался сделать максимально «легкую» реализацию идеи DNS-туннелинга: для запуска и инициализации соединения на стороне клиента не требуется установки никаких новых драйверов или интерфейсов, также как не нужны и права администратора.
Настройка Dns2tcp существенно проще в сравнении с NSTX, поэтому просто отмечу, что документация этого проекта доступна здесь. В силу простоты Dns2tcp в нём отсутствуют встроенные механизмы аутентификации и шифрования, именно поэтому он часто используется совместно с обёрткой из ssl-tunnel
, вариант парной настройки которых и отражен в большинстве примеров официальной документации. Поставляется эта утилита в комплекте из сервера и клиента, доступных для самостоятельной компиляции в любой из Unix-систем.
Это выделяющийся на фоне аналогов инструментарий, который позволяет создавать двунаправленные TCP/IP туннели на основе использования всё того же DNS-трафика.
Исповедуя во многом похожие на своих предшественников идеи, проект Heyoka отличается тем, что использует довольно интересный и самобытный алгоритм упаковки, который ощутимо ускоряет транзит трафика на фоне аналогичных инструментов. Так, Heyoka способен работать с практически неограниченным количеством принимающих трансляцию серверов. Это значит, что на стороне внешнего интернета можно создать сеть сразу из нескольких DNS-серверов, каждый из которых, принимая лишь часть данных, ретранслирует каждый полученный им пакет на некий центральный сервер, который и осуществляет сборку в «одно целое» всей этой «веерно транслируемой» информации (образуя собственную сеть из Серверов по топологии «звезда»).
Такой сложный на первый взгляд подход позволяет существенно затруднить отслеживание адресов серверов принимающих инкапсулированные пакеты.
Давайте немножко остановимся на этом важном моменте, принципиальном для понимания главной «фишки» Heyoka. Как можно увидеть на рис. сверху, там представлен обычный статистический анализ трафика входного для транзита DNS-сервера, где отчетливо виден аномальный всплеск объема транслируемой информации на один из внешних IP-адресов (это принимающий DNS-сервер), сразу позволяя выявить и заблокировать подобную нештатную ситуацию, сделав обычную схему работы DNS-туннелирования нерабочей для злоумышленника.
На рис. внизу показан аналогичный срез DNS-трафика транзитного интранет-сервера, но здесь используется Heyoka в режиме многоцелевой трансляции пакетов. Очевидно, что в последнем случае трафик более-менее равномерно распределен между большой группой IP-адресов, и администратор этой локальный сети, даже имея какие-то подозрения и зафильтровав выборочно какой-то один (или несколько) действующих в единой группе DNS-серверов, такую скрытую трансляцию прекратить всё равно не сможет. В этом худшем случае скорость «проброса» незначительно упадёт, а все пакеты теперь будут маршрутизироваться на оставшиеся доступными внешние серверы из общей цепочки.
Вторая особенность — Heyoka полностью ориентирован на ОС Windows. У этой утилиты нет конфиг-файлов, она полностью настраивается через консоль посредством аргументов командной строки. Один и тот же головной exe-файл может быть запущен как в режиме master (это сервер в нашей классификации, ключ –m
), равно как и slave (клиент, ключ –s
), позволяя пробрасывать любой трафик с локального на заданный удаленный порт. Ниже привожу пример запуска этой утилиты в режиме клиента:
heyoka.exe -s -d mydomain.com -p 3389
Этот проект предоставляется в исходных кодах и распространяется по лицензии GPLv2.
Как и все предыдущие инструменты, Iodine позволяет передавать IPv4 через DNS-трафик. Давайте перечислим основные отличия, которые делают его без сомнения очень интересной реализацией:
Хочу упомянуть, что кроме уже названных поддерживаемых платформ Linux/*BSD/Win32, также имеются рабочие клиенты под Android, Maemo, WinMobile, Mac OS X (дополнительно нужен драйвер tuntap
), BeOS и Solaris. В заключение дам полезный совет: часто уменьшение на стороне клиента значения MTU (для интерфейса dns0
, например до 700) — существенно ускоряет обмен данными в таком туннеле.
Этот инструмент от очень известного специалиста по безопасности Дэна Каминского (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-серверов, один из которых специально предназначен для режима гостевого доступа и в принципе ничего не знает про «большой Интернет». Общая беда большинства уязвимых провайдеров и локальных сетей, прежде всего в том, что их администраторы часто не в курсе существования подобных методов обхода стандартной фильтрации, что и используется злоумышленниками в незаконных целях (отчасти эту проблему и решает эта статья).
В заключение напоминаю, что не надо забывать об аналогичных методиках, использующих, к примеру, проброс IP через ICMP (дополнительно здесь и здесь) или PPP через Jabber , более тщательно продумывать правила фильтрации пакетов даже самых безобидных с первого взгляда протоколов, типа DHCP (об интересном способе использования которого, кстати, мы и поговорим в следующий раз в нашей рубрике «Безопасность»).