Я понимаю, что Блогератор читают не только матерые программисты, но и в перерывах между компиляцией своих кастомных ядер порой заглядывают и не менее матерые системные администраторы. Скорее именно для последних, мне и хотелось сегодня подкинуть интересную задачку, которая заставит не только прокачать своих администраторские скиллы, но и как следует поломать голову над её решением.
Постановка этой хакерской задачи очень проста и одновременно коварна: в данной статье я покажу, как можно получить бесплатный доступ в Интернет, в том числе через WiFi-сети, практически у любого провайдера интернет-услуг. Оговорку «практически у любого» нужно понимать с некоторой долей здорового скепсиса, потому как автор статьи не занимался целенаправленным тестированием ваших местных провайдеров на качество настройки их сетей. Единственная важная оговорка: вся информация предназначена исключительно для образовательных целей!
Считаю, что наиболее надежный и эффективный способ закрыть любую дыру — это просто выложить исчерпывающую информацию в паблик (как в недавней истории с известной дырой к Skype, которая, несмотря на всю свою серьезность, много месяцев не интересовала MS, пока, наконец, подробная инструкция с её описанием не была выложена в открытый доступ, что как-то сразу магически устранило её уже в течение суток).
Исходной причиной для написания этой обзорной статьи стало наблюдение мною в последнее время огромного количества вирусов и троянов, которые активно применяют DNS-протокол в его нештатном режиме работы. Использование стандартных DNS-запросов в качестве протокола-транспорта позволяет им эффективно преодолевать практически любые защитные системы, заботливо воздвигнутые администраторами на шлюзе в подотчетную им корпоративную сеть.
Вместо скучного дизассемблирования выловленных образцов и изучения их алгоритма, мы поступим несколько иначе.
Считаю, что методически гораздо полезней попробовать самостоятельно настроить и прокинуть подобный DNS-туннель в свою локальную сеть с помощью широко известных специализированных инструментов, чтобы на практике изучить (и показать своим админам за это головой отвечающих) всю потенциальную опасность этого малоизвестного метода связи.
Переходя к конкретике, на примере типового алгоритма работы этой схемы, предлагаю пошагово рассмотреть типичные этапы развертывания, а также принципиальное устройство такого DNS-туннеля:
Несмотря на кажущуюся необычность схемы, всё довольно просто: метод напоминает идеи стеганографии, реализованные на базе DNS.
Поскольку пока чаще всего этот тип связи используется в современных ботнетах, давайте немного остановимся на этой теме поподробнее.
Ботнет — это большая распределенная система, где на первый план в современных условиях всё чаще выходит именно надежный механизм обратной связи, который позволил бы держать постоянную связь с управляющей головой ботнета (говоря на сленге ботостроителей — с «папой»). Даже сам «пробив» не столько важен, как возможность после этого невозбранно ходить через чужую сеть пакетами направо и налево, оставаясь при этом полностью незамеченным.
Времена использования для отправки управляющих команд классического IRC-канала ушли в прошлое. Для донесения кодированных посланий теперь чаще всего применяются сервисы типа Twitter или p2p-сети.
Недостаток такого подхода в том, что современные «ортодоксальные» администраторы часто сосредоточены на фильтрации этих традиционных протоколов (главным образом http), но в большинстве случаев совершенно упускают из вида нестандартные использования стандартных протоколов.
Например, возможность тунелирования TCP/IP-трафика через стандартные DNS-запросы в целях внешнего управления ботами или троянами, сидящими глубоко внутри корпоративных сетей.
Кроме уже упомянутых армии ботов и троянов, DNS-тунелинг сейчас активно используют для обхода как персональных, так и корпоративных средств защиты в офисах по всему миру.
В частности, я лично был впечатлён случаем, когда наблюдал ситуацию применения такой технологии для проброса ICQ/Jabber, несмотря на практически полную блокировку входящего трафика в крупную белорусскую корпоративную сеть. Интересно, что в этом случае фильтрация и мониторинг сети осуществлялись как местным админом областного филиала, так и минским специалистом из центрального офиса этой республиканской государственной структуры, где и обеспечивалось физическое подключение к интернету.
Ещё одна область для «незаконного творчества» — это различные интернет-провайдеры, многие из которых предоставляют бесплатный доступ к своим локальным сетям или к собственным информационным сайтам, даже когда у абонента нет денег на его счету.
В большинстве случаев технически это ограничение реализуется в виде фильтрации IP-адресов на пограничном брандмауэре, четко отделяя адреса своей локальной сети от Интернета. Моё выборочное тестирование провайдеров во время моих прошлогодних путешествий показывает, что все без исключения проверенные поставщики интернета (в том числе и один мобильный), дают возможность резолвить имена в гостевом режиме работы.
И если даже в каких-то отдельных случаях брандмауэры или DNS настроены достаточно консервативно, например, делая невозможной передачу экзотических NULL-записей, у DNS-тунелинга есть достаточно хороший адаптационный потенциал, позволяющий переключаться на трансляцию через уж совсем обычные CNAME-запросы и так далее.
Для чего используется эта повальная уязвимость — для анонимного серфинга, бесплатного чтения почты, чатов или управления зомби-сетями — вопрос, который имеет вторичное отношение к рассматриваемому нами сегодня сугубо техническому аспекту DNS-тунелинга. Поэтому, объяснив в общих чертах, как это работает и где это может быть применено, позвольте перейти к обзору самых распространенных инструментов для создания и тестирования подобных туннелей, с моими краткими пояснениями специфики каждого из них.
Несмотря на то, что многие узкоспециализированные программы, построенные на этот принципе, реально работают по различным схемам — все они эксплуатируют одну центральную идею, применяемую для обхода стандартных средств сетевого контроля. Речь идёт об инкапсуляции своего служебного трафика в штатные DNS-запросы с последующей сборкой скрытно полученных TCP/IP-пакетов уже позади заградительного барьера на шлюзе.
Существуют удобные шелл-коды, которые по этому же принципу пробрасывают внутрь подобной «защищенной» локальной сети свою консоль управления, чаще всего используя для этого DNS-запросы типа TXT. В этой связи стоит также напомнить о dnscat (эта известная утилита часто упоминается как самостоятельный инструмент, но это лишь часть пакета DNS-утилит nbtools), созданная специально для этих целей, а также о не менее известном в узких кругах NSTX (IP over DNS — NameServer Transfer Protocol).
OpenSource-природа этих решений приводит к тому, что принципиальные кодовые части упомянутых программ для тунелирования сегодня обнаруживаются в «личинках» самых разных ботнетов.
В частности популярный для Windows пакет Iodine, который в российских условиях часто используется для незаконного «добывания интернета» абонентом, ранее отключенным провайдером за неуплату (DNS, как правило, при этом остаётся рабочим), применяется в коде одной из разновидностей ботнета Gheg. Другая подобная система OzymanDNS — популярна у «специалистов сетевых наук» для надежного проброса своего SSH через служебный DNS-трафик перед самым носом даже у самых строгих сисадминов.
В такой схеме единственный минус (который именно для случая ботов не так существенен): DNS-клиент (зомби) может связываться с «папой» только сам и в одностороннем порядке. Статистика, собранная при наблюдении подобных «пчелиных улеев», показывает, что «пробив» у подобной схемы чрезвычайно высок, чаще всего зомби с обратной связью на основе DNS-тунелинга надежно управляются даже из самых глубоких недр самой тщательно «зафильтрованной» корпоративной сети.
Предлагаю в завершении немного избирательно остановиться лишь на двух пакетах из вышеперечисленного списка.
Как и все предыдущие инструменты, Iodine позволяет передавать IPv4 через DNS-трафик.
Давайте перечислим основные отличия, которые делают его без сомнения очень интересной реализацией DNS-тунелинга:
NULL RDATA format
из RFC 1035), что позволяет существенно ускорить трансфер данных, доведя размер одного пакета до 1Кб полезных данных; Хочу упомянуть, что кроме уже названных поддерживаемых платформ 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 написан на Perl, поэтому он может быть запущен во всех средах, где поддерживается этот интерпретатор (оригинальный набор скриптов был написан и протестирован в Linux). На Mac OS X можно использовать клиент в сочетании с заранее установленными Xcode и всеми необходимыми Perl-модулями (как минимум нужны MIME::Base32
и Net::DNS
).
Для клиента в Windows можно взять Cygwin (в котором самостоятельно скомпилировать и настроить всю рабочую среду) или проект Strawberry Perl. Кроме всего этого, для любой из клиентских сред должны быть установлены и настроены внешние сервера SOCKS 5 и SSH. Прочитать подробную инструкцию по установке OzymanDNS для множества ОС можно здесь.
По итогам всего вышеизложенного у меня есть два типа новостей.
В заключение напоминаю админам, что не надо зацикливаться только на вышеописанном, — не забывайте об аналогичных методиках-вариациях, использующих, к примеру, проброс IP через ICMP или PPP через Jabber. Следует более тщательно продумывать правила фильтрации пакетов даже для самых безобидных с первого взгляда протоколов (типа DHCP). Будем надеяться, что эта обзорная статья по тунелингу поможет задуматься и сделать шаг именно в этом направлении.
~
Примечание: это — сокращенная версия статьи, сразу после НГ я выложу её полную версию, где более подробно описывается весь инструментарий и все этапы настройки подобных туннелей.
4 комментария
O! Спасибо что напомнил. В начале 90-х поюзывал этот метод, но таки да, кроме фидо ничего не пролазило, уж очень он медленный. Сейчас наверное получше стало, в аэропортах он совершенно необходим.
Когда уже будет продолжение!?
flamy motor: Материал надо просто сформатировать и выложить, он давно написан - нужно чтобы время было, окно появилось. И там будет не то что продолжение, просто более подробное изложение (выше была очень сокращенная версия от оригинального материала).
Подписывайся на блог, не пропустишь. Думаю что в феврале выложу, на январь работы выше крыши.
цитирую :В заключение дам полезный совет: часто уменьшение на стороне клиента значения MTU (для интерфейса dns0 , например до 700) существенно ускоряет обмен данными в таком туннеле.
Как же всётаки изменить этот mtu dns0 до значения 700 ?
Буду ждать положительного ответа , спасибо !