Blogerator.org

× Версия для печати

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

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

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

Общая теория

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

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

1. Регистрируем собственный домен, для управления его зонами и субдоменами настраиваем свой DNS-сервер, авторитативный для данного домена. Очевидно — этот конец цепочки находится под вашим полным контролем, это будет сторона, выполняющая роль управляющего сервера в создаваемом DNS-туннеле (далее Сервер);
2. Специальное ПО совмещенное работающее согласовано с DNS-сервером, осуществляет в фоновом режиме непрерывный мониторинг всех входящих DNS-пакетов. В частности контролирует каждый входящий запрос на наличие идентифицирующих сигнатур. Уникальная комбинация флагов или значений в служебных полях DNS-запросов могут идентифицировать обращение клиента, после чего такой «особый пакет» распаковывается Сервером согласно заранее условленному алгоритму. После его обработки формируется ответ, точно также инкапсулированный в служебную часть отсылаемого DNS-пакета;
3. С противоположной стороны, за множеством брандмауэров и сетевых фильтров находится тот, кто должен получать команды и как-то удаленно исполнять их, условно назовем его Клиент. Безотносительно к характеру предшествующей фильтрации стандартного TCP/IP-потока, такому клиенту достаточно иметь стандартную возможность резольвить (разрешать) DNS-имена, чтобы создать собственный скрытый и туннелированный канал соединения с заранее указанным и подготовленным Сервером из внешнего Интернета.

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

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

1. Любой участвующий в туннеле DNS-пакет является полностью стандартным с точки зрения любого внешнего наблюдателя (строго выполняя соответствующую ему сетевую функцию согласно RFC 1034 и RFC 1035);
2. В то же самое время он, как правило, в служебной части своего фрейма, несёт некую дополнительную зашифрованную информацию, которая является скрытой (или как минимум неявной) для любого постороннего наблюдателя, тем не менее, будучи неотъемлемой частью пакета, она, безусловно, доставляется по своему назначению. Наличие подобной «дополнительной начинки» никак не влияет на штатную работоспособность DNS;
3. В инкапсулированной части пакета могут находиться, как собственные инструкции, так и специально упакованные команды других стандартных программ и сервисов (например, в Ozyman это реализация «проброса» сеанса обычного терминала SSH). В общем случае, возможна транспортировка «сквозь DNS-поток» с динамической сборкой на «обратной стороне» любых TCP/IP пакетов;
4. В последнем варианте в силу технических особенностей устройства DNS-протокола, который существенно ограничивает размер инкапсулируемой информации за одно обращение, будет наблюдаться падение скорости «пробрасываемого» TCP/IP-потока в силу сильной фрагментации пакетов. Для хотя бы примерной оценки, могу привести собственные замеры: на канале в 1Мб скорость трансляции в DNS-туннеле держалась в диапазоне от 0,5 до 4 кбит/с. Что, как видно, потенциально позволяет вполне уверенно управлять зараженным компьютером-зомби, общаться в ICQ через полностью закрытый брандмауэр, или читать простые HTML-странички. К сожалению, хоть как-то увеличить скорость транслируемого извне трафика сверх указанного барьера в 2-4 кбит/с чрезвычайно проблематично;
5. При реализации данной схемы не всегда обязательным является прямое обращение к DNS на обслуживаемом «магическом домене». Даже при рекурсивном режиме работы исходного DNS-провайдера, существуют техники «доставки посланий» до заданного «магического домена» транзитным способом через всю стандартную иерархию DNS-запросов.

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

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

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

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

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

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

Dnscat

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

• Это возможность установки соединения и передачи информации (текстовых сообщений или файлов) между двумя произвольными хостами интернета;
• Возможность через уже установленное соединение, удаленно запускать команды системной оболочки (реализуется через опцию –e ), а также перенаправлять при этом вывод запускаемых команд на инициирующий соединение хост.

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

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

NSTX

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

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

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

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

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

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

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

Dns2tcp

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

Настройка Dns2tcp существенно проще в сравнении с NSTX, поэтому просто отмечу, что документация этого проекта доступна здесь. В силу простоты Dns2tcp в нём отсутствуют встроенные механизмы аутентификации и шифрования, именно поэтому он часто используется совместно с обёрткой из ssl-tunnel , вариант парной настройки которых и отражен в большинстве примеров официальной документации. Поставляется эта утилита в комплекте из сервера и клиента, доступных для самостоятельной компиляции в любой из Unix-систем.

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-трафик. Давайте перечислим основные отличия, которые делают его без сомнения очень интересной реализацией:

• Впервые используются экспериментальные NULL-пакеты (см. NULL RDATA format из RFC 1035), что позволяет существенно ускорить трансфер данных, доведя размер одного пакета до 1Кб полезных данных;
• Iodine спроектирован очень универсально — он прекрасно работает как на Win32-системах, так и практически на всех Unix-системах. Таким образом, это даёт возможность запустить клиента, например, в среде Windows, а принимающий сервер настроить уже под любимой FreeBSD;
• Пакет содержит достаточно хорошую встроенную систему безопасности. Например, он использует аутентификацию на базе MD5-хеша, а также принимает пакеты только с тех IP-адресов, которые сначала прошли аутентификацию, отбрасывая любые другие, какие бы команды они не содержали;
• Iodine максимально автоматизирует и упрощает свою настройку. Например, он сам настраивает свой интерфейс во время инсталляции, сам тестирует и выбирает оптимальный по скорости режим передачи данных из множества доступных и так далее. Кстати говоря, здесь на одном сервере может «висеть» одновременно до 16 пользователей-клиентов;
• Проект достаточно активно развивается, также доступны его полные исходные коды, есть репозитарий, прекрасно документированы спецификации всех используемых протоколов.

Хочу упомянуть, что кроме уже названных поддерживаемых платформ Linux/*BSD/Win32, также имеются рабочие клиенты под Android, Maemo, WinMobile, Mac OS X (дополнительно нужен драйвер tuntap ), BeOS и Solaris. В заключение дам полезный совет: часто уменьшение на стороне клиента значения MTU (для интерфейса dns0 , например до 700) — существенно ускоряет обмен данными в таком туннеле.

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-серверов, один из которых специально предназначен для режима гостевого доступа и в принципе ничего не знает про «большой Интернет». Общая беда большинства уязвимых провайдеров и локальных сетей, прежде всего в том, что их администраторы часто не в курсе существования подобных методов обхода стандартной фильтрации, что и используется злоумышленниками в незаконных целях (отчасти эту проблему и решает эта статья).

В заключение напоминаю, что не надо забывать об аналогичных методиках, использующих, к примеру, проброс IP через ICMP (дополнительно здесь и здесь) или PPP через Jabber , более тщательно продумывать правила фильтрации пакетов даже самых безобидных с первого взгляда протоколов, типа DHCP (об интересном способе использования которого, кстати, мы и поговорим в следующий раз в нашей рубрике «Безопасность»).

Игорь Савчук © Системный Администратор, 2012