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

Если ты сможешь залить на этот сервер специальный веб-сценарий, то с большой вероятностью получишь возможность обращаться к узлам из локальной сети этого сервера, которые при этом в инете не открыты! Любое подобное решение состоит из двух частей - клиента и сервера, которые инкапсулируют трафик в обычные HTTP GET- и POST-запросы и передают в таком виде данные между собой.

Данные при этом сжимаются, криптуются и кодируются в base64. Существует много реализаций подобного подхода, в том числе немало коммерческих. Опытные товарищи посоветовали две бесплатные разработки: reDuh (sensepost.com/labs/tools/pentest/reduh) и HTTPTunnel (). Мне приглянулась первая, так как ее серверная часть (та, которая заливается на веб-сервер) доступна в трех вариациях: на JSP, PHP и ASPX. В зависимости от того, какие технологии используются на веб-сервере, можно выбрать подходящий вариант.

Клиентская часть при этом написана на Java и, соответственно, может быть запущена под любой ОС. Итак, как это работает? Рассмотрим конкретный пример.

Допустим, пентестер Иван, проводя исследование, нашел в некотором вебсценарии уязвимость и может загрузить на сервер скрипт для HTTP-туннелинга.
При этом ему стало известно, что где-то внутри локалки находится RPD-сервер с названием хоста term-serv.victim.com , к которому нет доступа «снаружи» из-за файрвола. Брандмауэр пропускает к вебсерверу только HTTP-трафик и больше ничего. Подключиться к этому серверу и другим хостам из внутренней локальной сети Иван может с помощью HTTPтуннелинга. Это выглядит так:

1. Иван заливает на сервер скрипт reDuh.jsp, который становится доступным по некоторому адресу (пусть это будет ). Это серверная часть, и она не нуждается в настройке.

2. На локальной машине запускается клиентская часть reDuh - reDuhClient. Это консольное приложение, которому в качестве параметра для запуска передается адрес только что загруженного скрипта:

$ java reDuhClient ubunt00.victim.com 80 /uploads/reDuh.jsp

3. Указать адрес серверной части мало - необходимо еще отконфигурировать туннели с помощью админки, которая по умолчанию запускается на 1010 порту.
Ивану требуется пробросить локальный порт 1234 на порт 3389 (RPD) хоста termserv.victim.com , поэтому правило будет следующим:

1234:term-serv.victim.com:3389

4. Все, теперь если Иван подключится с помощью любого RDP-клиента к localhost:1234, то весь его TCP-трафик будет инкапсулироваться в HTTP-запросы, которые передаются на ubunt00.victim.com/uploads/reDuh.jsp , а оттуда уже переадресуются на целевой сервер. Таким образом, он получит желанный доступ к удаленному рабочему столу.

Тут надо сказать, что reDuh не ограничивает количество соединений, поэтому ты можешь создать несколько туннелей для разных хостов и разных сервисов (например, SSH) и использовать их одновременно! Ради интереса я попробовал еще и HTTPTunnel, которая оказалась не менее замечательной разработкой.
Ее большой плюс заключается в наличии специальной клиентской версии с удобным GUI-интерфейсом (только для Windows).

Серверная часть есть в двух вариантах: на PHP и Perl’е. При этом HTTPTunnel может работать в качестве SOCKS-сервера.

Соответственно, подключаясь к внутренним хостам (например, в том же самом RDP-клиенте), ты можешь сразу указывать внутренний адрес хостов для подключения (если возвращаться к нашему примеру, то это term-serv.victim.com ).

Но при этом надо предварительно позаботиться о том, чтобы в настройках программы был прописан локальный SOCKS, созданный HTTPTunnel. На случай, если какое-то приложение не поддерживает работу через прокси, его трафик можно принудительно соксофицировать с помощью FreeCap (freecap.ru), tsocks () или любых других аналогичных приложений.

IP protocol был разработан для самых различных типов подключений, и хотя максимальная длина для IP datagram составляет 64K, большинство подключений (transmission links) используют меньший максимальный размер для IP-пакета или MTU.
MTU, Maximum Transmission Unit - максимальный размер блока в байтах, который может быть передан на канальном уровне сетевой модели OSI.

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

На рисунке отображен заголовок IP пакета и то, как он инкапсулируется в датаграмму второго уровня.
Здесь важно отметить, что в поле FLAGS включает в себя три бита, один из которых "don"t fragment" (DF) bit , который определяет разрешено данный пакет фрагментировать или нет.

Вопросы с IP фрагментированием

Хотя фрагментация пакета выполняется достаточно быстро, обратная сборка исходного пакета требует значительных ресурсов: затрат памяти, вопросы быстродействия.
В случае потери одного из фрагментов вся датаграмма должна быть передана заново.
Фрагметы очень тяжело обрабатывать на брендмауэрах (с 4-го по 7 уровень), при неправильной последовательности они будут забракованы.

TCP MSS и избегание дефрагментации

TCP Maximum Segment Size (MSS) - определяет максимальный размер датаграммы TCP/IP, которую будет принимать данный хост.
Датаграмма TCP/IP может быть фрагментирована на уровне IP.
Значение MSS отсылается внутри TCP header только в сегментах TCP SYN. Каждая сторона TCP соединения объявляет другой стороне свое значение MSS.
Вопреки распространенному мнению, значение MSS не согласовывается между хостами, - у каждого хоста они могут оставаться разными, только отсылающий хост отдает сегменты размером не больше, чем требует принимающий хост.

Таким образом TCP MSS позволяет избежать фрагментации на уровне двух участников сессии TCP. Но TCP MSS не может обработать тот случай, когда по пути между хостами есть меньший MTU.

PMTUD

PMTUD (Path Maximum Transmission Unit Discovery) - был разработан для избегания фрагментации по пути между хостами. PMTUD используется для автоматического определения минимального MTU вдоль пути пакета между хостами.

PMTUD поддерживается только TCP, UDP и другие протоколы не поддерживают PMTUD.

Хост отсылает нефрагментированный пакет с установленным DF bit . Если маршрутизатор пытается отдать пакет на link, с меньшей MTU чем этот пакет, маршрутизатор дропнет этот пакет и возвратит сообщение ICMP "Destination Unreachable", с кодом "fragmentation needed and DF set" (type 3, code 4). Когда Хост-источник получает эту информацию, он понижает MSS и затем пересылает TCP сегмент заново.

Наиболее часто встречающаяся проблема с PMTUD - это среда в которой не пропускается сообщения ICMP

Где актуально использование PMTUD

Как уже было сказано, PMTUD нужен в случаях, когда по пути от хоста А к хосту Б встречаются линки с меньшими значениями MTU.
Наиболее общие примеры:
- PPPoE (часто используемый вместе с ADSL) использует 8 bytes для своего заголовка. Это уменьшает эффективное значение MTU для Ethernet до 1492 (1500 - 8).
- Туннельный протоколы GRE, IPsec, and L2TP также используют пространство для своих заголовков, что также уменьшает эффективное MTU на исходящем интерфейсе.

Вообще Path MTU Discovery (RFC 1191) осуществляется всеми клиентами включая Windows 2000/2003/XP/7/8.
Для нормальной работы PMTUD необходимо, чтобы пропускался протокол ICMP, в частности должны пропускаться сообщения ICMP "unreachable" и "time-exceeded".

Для проверки можно использовать утилиту mturoute.exe. Утилита отрабатывает аналогично PMTUD и возвращает значение MTU, которое необходимо использовать на данном хосте.

Текущее значение MTU можно увидеть через команды:
Windows 7, Windows Vista: netsh interface ipv4 show subinterfaces
Windows XP: netsh interface ip show interface

Значения MTU для локальной машины можно поменять и вручную (хотя и не рекомендуется)
Adjusting IP MTU, TCP MSS, and PMTUD on Windows and Sun Systems
Также можно использовать утилиту Set MTU, поставляемой с Cisco Systems VPN Client.

Что такое туннель

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

Туннель состоит из основных компонентов:
- Passenger protocol
- Carrier protocol . Протокол, осуществляющий инкапсуляцию:
GRE
IP in IP tunnels
- Transport protocol . Протокол отвечающий за маршрутизацию encapsulated protocol. В нашем случае это IP.

На приведенном рисунке IP у нас выступает как transport protocol и как passenger protocol .

Инкапсуляция трафика дает следующие преимущества:

Endpoints могут использовать private addresses
Позволяет строить VPN поверх WAN сетей
Возможность использования шифрования

Исходя из того, что наиболее "тяжелый" вариант - это одновременное использование GRE и IPsec, рекомендации будут следующие:
- PMTUD позволяет установить на GRE интерфейсе оптимальное значение MTU и включается на туннельном интерфейсе командой tunnel path-mtu-discovery
- Обеспечьте нормальную работу PMTUD, при этом на обоих целевых хостах должна успешно выполняться mturoute.exe
- Также рекомендуется одновременно использовать и команду ip mtu 1400 . В этом случае ip mtu будет обеспечивать пространство для GRE + IPSec, в случае же более низких значениях MTU по пути, IP MTU бует подкорректировано динамически. Значение 1400 рекомендовано, т.к. оно покрывает большинство возможных комбинаций GRE + IPSec.
- Следует использовать ip tcp adjust-mss 1360 на туннельном интерфейсе. Это позволит маршрутизатору уменьшить значение TCP MSS в TCP SYN Packet. Что позволить двух конечным хостам генерировать достаточно малые пакеты. (1360 = 1400 - 20(TCP) - 20 (IP))

Общий конфиг для туннельного интефейса DMVPN + IPSec будет выглядеть:
interface Tunnel200
description ### DMVPN TUNNEL HUB
ip address 10.5.0.1 255.255.255.0
no ip redirects
ip mtu 1400
tunnel path-mtu-discovery
ip nbar protocol-discovery
ip hold-time eigrp 1 35
no ip next-hop-self eigrp 1
ip flow ingress
ip flow egress
ip nhrp authentication baurus
ip nhrp map multicast dynamic
ip nhrp network-id 200
ip tcp adjust-mss 1360
no ip split-horizon eigrp 1
delay 100000
tunnel source 87.237.40.107
tunnel mode gre multipoint
tunnel key 123
tunnel protection ipsec profile DMVPN

Кстати, всё что здесь описано, делалось, если не сказано дополнительно, под altlinux sisyphus. И всё ещё работает на моих машинах:)

1. Вводная: для чего вообще нужны туннели?

1.1. Небольшое описание

Вообще туннель, это по сути отдельный виртуальный провод, протянутый от одного peer"а к другому.
Чем это хорошо: между peer"ами могут идти море маршрутизаторов, но в туннеле они не видны . Для машин-peer"ов туннель является физической средой передачи, а значит противоположный конец туннеля можно прописывать в таблицу маршрутизации. В итоге трафик, завёрнутый в туннель, может выходить где-нибудь в америке (смех смехом, а при спутниковом доступе так и происходит), а возвращаться обсолютно другим маршрутом - маршрут возврата зависит от ip-источника. В этом туннели очень похожи на прокси.

1.2. Отличия туннелей от прокси:

Прокси кроме всего прочего кешируют. Туннель - это просто среда передачи, так что ни о каком кешиваронии не может быть и реси. Проводам наплевать на информацию, по ним передаваемую. Их задача - передать.
Туннели в OS, с ними работающей, представляются как отдельный интерфейс, а значит для работы с ними достаточно настроить tcp/ip протокол (маршруты, firewall), когда для прокси надо настроить каждую программу.

Схожесть:

Возможность организации аутентификации, шифрации трафика
Возможность изменения маршрута трафика (в прокси это реализуется через иерархию.)

1.3. Пример применения

Например задача: исходящий трафик посылать по земле, ответы принимать через спутник. (Для Настройки спутника см. Sky Star 2 )
То есть, трафик исходит с вашего интернет-интерфейса, идёт по одному маршруту к назначению, а приходит по другому и на другой интерфейс.

Как происходит маршрутизация? Трафик в одну сторону дойдёт по ip-назначению. Обратно он будет идти также по ip-назначения, только он будет уже вашим ip (при ответе ip сменяться местами). Значит надо послать пакет с ip-источником от провайдера, что зарулит трафик к вам. Какие могут быть здесь проблемы: провайдер не будет выдавать тысячи ip каждому, чтобы они ставили его для ответа. Да и те же продукты от MS тяжело будет таким образом отстроить.

Какая тут на самомо деле проблема: маршруты не прохдят через спутникового оператора, они могу идти как угодно. Если бы они проходили через него, то с помощью SNAT можно ответ получать на оператора а затем на пользователя. SANT там делается (не совсем удобно: в итоге с одного ip качают тысячи поьзователей, что не на всех сайтах разрешается:)

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

Меня тут просили организовать success story по работе и настройке туннелей. Ну что ж, вот вам романы: :)

1.4. Типы туннелей

Есть два типа туннелей:

сетевого уровня (то есть уровня ip протокола)
транстпортного уровня (работающие на tcp либо udp)

Ну, если постараться, можно сваять туннель и прикладного уровня: через http протокол например через тот же прокси. google it: httptunnel, proxytunnel. Но, как и ssh port-forwaring, это не туннели Хотя иного без них никуда:)

Где-то тут наверное можно прислонить и vlan, только с ними я пока не сталкивался, знаю лишь что ьам в существующей сетевой стреде организуется дополнительная вирутуальная. В отличие от туннелей позволяет организовать не только соединение точка-точка, но и реальную сеть с broadcast"ами и всем остальным. Рабоет на сетевом уровне

Есть туннели PPPoE - point-to-point over ethernet. Что это такое я так пока и не понял, наверное потому что опять не использовал. Куда их отнести - понятия не имею. Жду подсказки:)

2. Туннели сетевого уровня

2.1. Что ето такое

Это ipip и ip_gre туннели. Может и ещё что-то есть: я с ними пока не работал. Как они выглядят вживую:
# tcpdump -t proto gre -n IP 192.168.0.2 > 192.168.0.1: IP 192.168.2.42.58974 > 81.176.64.123.http: . 955:2391(1436) ack 1 win 1460 IP 192.168.0.1 > 192.168.0.2: IP 81.19.70.1.http > 192.168.2.42.58972: . ack 594 win 8760

Если посмотреть, то видно, что IP повторяется два раза, ip заголовки тоже. В принципе туннели так и работают: в ip пакет вместо tcp пакета (или udp, icmp, или что там ещё есть) заворачивается ещё один ip пакет, а в поле «протокол» в пакете вместо 6 для tcp, 1 для icmp ставится 47 для gre и 94 для ipip (номера протоколов находятся в файле /etc/protocols. если поискать под offtopic"ом, то там тоже наверняка найдтся такой файлик: services есть, почему бы и не быть protocols:)

точно также , только туннельный ip пакет со всеми своими данными заворачивается в tcp пакет. То есть организуется обычное подключение и в tcp поток льется ip траффик.

2.2. Настройка

Ну, это наверно проще поискать.
Вкратце ручками это делается следующим образом:
modprobe ip_gre ip tunnel add mode gre local remote # создать девайс ip addr add dev # добавить адрес ip link set up # включить
ну, и осталось добавить нужные вам маршрутизаторы.
Для ipip тоже самое, только меняется mode

2.3. IPSEC туннель

ipsec, как я понял, может работать в двух режимах: простая шифрация нужного трафика (скажем от одного порта к дргому), и в туннельном, в котором нужно будет прописать отдельную подсеть.

Вообще ipsec это отдельный разговор , я взялся за него только недавно, поэтому пока оставим так. пусть кто-нить опишет - буду благодарен. Всё равно мне его ещё реализовывать.

3. Туннели транспортного уровня

Туннели транспортного уровня работают точно также как и сетевого , только туннельный ip пакет со всеми своими данными заворачивается в tcp пакет. То есть организуется обычное подключение и в tcp поток льется ip траффик. Для udp, как всегда, подключение надо организовывать самому. Но принцип тот же.

В принципе туннель можно сделать хоть через icmp протокол, благо в ip заголовке указывается полная длина пакета с icmp + какие надо прописать данные. а ведь icmp пакеты обычно пропускаются на маршрутизаторах... Хотя могу обрадовать - никто не мешает в firewall"е настроить блокировку на длину icmp пакета:))

Какие есть реализации:

pptp, поддерживается MS
pppoe (точно здесь должен быть?)
ppp over ssh
vtund

Требует написания:)

3.1. PPTP

3.2. PPPoE

Туннель, в котором пакеты протокола PPP прокидываются внутри пакетов Ethernet, т.е. обычно ниже уровня IP. Позволяет слегка уменьшить накладные расходы, если между точками работает сеть Ethernet. Однако не маршрутизируется, как туннели поверх IP.
http://www.roaringpenguin.com/slides/pppoe-slides.pdf
http://www.roaringpenguin.com/pppoe/als-pppoe-paper.pdf
Есть модификация PPPoA (поверх ячеек протокола ATM, обычно используется в ADSL наряду с PPPoE).
Не путать с термином Po E (Power over Ethernet) — это тоже туннель, но для электропитания по витой паре)

3.3. PPP over SSH

Прекрасно настраивается по . Когда у меня встала задача выйти через прокси в irc, imap мне как раз пришлось настроить

Процесс, в ходе которого создается защищенное логическое соединение между двумя конечными точками посредством инкапсуляции различных протоколов. Туннелирование представляет собой метод построения сетей, при котором один сетевой протокол инкапсулируется в другой. От обычных многоуровневых сетевых моделей (таких как OSI или TCP/IP) туннелирование отличается тем, что инкапсулируемый протокол относится к тому же или более низкому уровню, чем используемый в качестве тоннеля.

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

Типы протоколов

В процессе инкапсуляции (туннелирования) принимают участие следующие типы протоколов:

транспортируемый протокол;
несущий протокол;
протокол инкапсуляции.

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

Согласование транспортных протоколов

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

Обычно туннелирование приводит к более простым и быстрым решениям по сравнению с трансляцией, так как решает более частную задачу, не обеспечивая взаимодействия с узлами транзитной сети.

Основные компоненты туннеля

Основными компонентами туннеля являются:

инициатор туннеля;
маршрутизируемая сеть;
туннельный коммутатор;
один или несколько туннельных терминаторов.

Инициатор туннеля встраивает (инкапсулирует) пакеты в новый пакет, содержащий наряду с исходными данными новый заголовок с информацией об отправителе и получателе. Несмотря на то, что все передаваемые по туннелю пакеты являются пакетами IP, инкапсулируемые пакеты могут принадлежать к протоколу любого типа, включая пакеты немаршрутизируемых протоколов. Маршрут между инициатором и терминатором туннеля определяет обычная маршрутизируемая сеть , которая может быть и сетью, отличной от Internet . Терминатор туннеля выполняет процесс, который является обратным инкапсуляции - он удаляет новые заголовки и направляет каждый исходный пакет в локальный стек протоколов или адресату в локальной сети. Инкапсуляция сама по себе никак не влияет на защищенность пакетов сообщений, передаваемых по туннелю VPN . Но инкапсуляция даёт возможность полной криптографической защиты инкапсулируемых пакетов. Конфиденциальность инкапсулируемых пакетов обеспечивается путем их криптографического закрытия, т. е. зашифровывания, а целостность и подлинность - путем формирования цифровой подписи . Так как существует множество методов криптозащиты данных, необходимо чтобы инициатор и терминатор туннеля использовали одни и те же методы и могли согласовывать друг с другом эту информацию. Более того, для возможности расшифровывания данных и проверки цифровой подписи при приеме инициатор и терминатор туннеля должны поддерживать функции безопасного обмена ключами. Чтобы туннели VPN создавались только между уполномоченными пользователями, конечные стороны взаимодействия требуется аутентифицировать.

Ссылки

Стратегии межсетевого взаимодействия: инкапсуляция (туннелирование) протоколов

Wikimedia Foundation . 2010 .

Смотреть что такое "Туннелирование (компьютерные сети)" в других словарях:

У этого термина существуют и другие значения, см. Инкапсуляция. Инкапсуляция в компьютерных сетях это метод построения модульных сетевых протоколов, при котором логически независимые функции сети абстрагируются от нижележащих механизмов… … Википедия

Анонимные сети компьютерные сети, созданные для достижения анонимности в Интернете и работающие поверх глобальной сети. Специфика таких сетей заключается в том, что разработчики вынуждены идти на компромисс между степенью защиты и лёгкостью … Википедия

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

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

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

Общая теория

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

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

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

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

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

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

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

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

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

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

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

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

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

Dnscat

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

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

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

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

NSTX

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

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

Heyoka

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

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

Впервые используются экспериментальные 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». Главная особенность — это изначальная «заточенность» на проброс именно SSH-трафика. Автор утилиты призывает далее в зависимости от конкретной необходимости, туннелировать необходимый трафик (для примера, с Tor через туннель SSH/DNS).

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

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

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

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