DNS-туннелирование: бесплатный Интернет
Нераспространенный способ получения бесплатного Интернета - DNS-туннелинг. Причина непопулярности этого способа - необходимость наличия сервера с root-доступом, софт для туннелинга только под Unix-системы и крайне мало информации о DNS-туннелировании на русском языке. Всё, что мы имеем - это несколько программ и документации на английском языке. На сегодняшний день этот способ действительно работает и всё описываемое в статье проверялось лично мной на нескольких узбекских провайдерах. Испытания прошли успешно.
Как это работает?
Туннелирование трафика успешно используется уже давно и для разных целей. Мы воспользуемся им для получения доступа в Интернет. Вспомним про гостевые аккаунты провайдера - это обыкновенный пользовательский аккаунт, но урезанный правилами фаервола. Он настроен таким образом, что вам перекрыт доступ ко всему, кроме сайта провайдера. Но это только на первый взгляд. Какие порты открыты? 80/TCP порт - HTTP и... 53/UDP порт - служба DNS, чтобы резолвить имена доменов. Попробуйте войти с гостевого аккаунта и набрать:
| host www.yahoo.com |
Если вы получили IP адрес Yahoo!, значит осуществить DNS-туннелирование возможно. Нам нужно использовать открытый 53 порт на гостевом аккаунте для получения полноценного доступа в Интернет (а не только к сайту провайдера). Правда есть одна загвоздка - открыт не TCP, а UDP порт, поэтому придётся пользоваться программным обеспечением, которое умеет осуществлять так называемый "TCP over UDP" (TCP поверх UDP). Есть ещё одна проблема - на сервере должен быть свободен 53 UDP-порт для прослушивания.
Программы
Я нашёл несколько программ для этих целей - udptunnel, utunnel, iproxy и nstx. Первая отпала сразу, так как в процессе чтения доков выяснилось, что она инкапсулирует UDP в TCP, а не наоборот. С оставшимися тремя программами тоже случился небольшой казус. Дело в том, что мой локальный компьютер работает под Linux, а удалённый сервер под FreeBSD. На данный момент утилиты iproxy и nstx компилируются и работают только под Linux, соответственно серверную часть запустить не удастся. Программа же utunnel наоборот работает только под FreeBSD, а к моменту написания статьи дистрибутива фряхи под рукой не оказалось. Таким образом пришлось не совсем легальго найти сервер на Linux (спасибо человеку, который помог с этим, если он читает) и тестировать сервер туннелера на нём.
iproxy
Я начну с iproxy, потому, что она проще в работе, не лишена багов и не нуждается в особой настройке. Программа это очень простая - она просто реализует TCP over UDP и ничего более. Процесс компиляции и установки программы стандартен:
| ./configure
make make install |
Кстати устанавливать её не обязательно - можно использовать прямо из домашнего каталога. После того как вы собрали её на клиентской стороне, командуйте:
| iproxy-client -p 33333 -d 53 -u -v -I 123.45.67.89 |
Опцией -p задаётся локальный TCP-порт, который будет прослушиваться программой. Опция -d указывает удалённый UDP-порт, а -I используется для указания адреса сервера, на котором расположен iproxy-server. -u - это unicast mode, а -v - это verbose mode, то есть всё, что творится с программой будет выведено прямо в консоль.
На клиентском компьютере всё готово, переходим к серверной части. Первое, что нам нужно сделать - это поднять прокси-сервер, так как iproxy-server пользуется услугами локального прокси и передаёт его результаты клиенту. Прокси может быть любым. Желательно, чтобы он поддерживал метод CONNECT, тогда можно будет использовать его не только для Web. Я использовал прокси-сервер Squid.
Теперь собираем iproxy точно также, как это было в клиентской части и командуем следующее:
| iproxy-server -u -v -p 53 -d 8080 |
Опять же объясняю опции: -u и -v - это всё те же unicast и verbose mode соответственно, как мы указывали на клиентской стороне. -p - это UDP-порт, который мы будем прослушивать, а -d - это TCP-порт локального прокси-сервера.
Осталось указать в программе в качестве прокси локальный адрес 127.0.0.1, а порт - 33333 или другой, который вы указали при запуске iproxy-client.
В результате тестирования программа показала себя не с лучшей стороны. Передавать большие пакеты при плохих условиях связи (ведь это dial-up) она не способна. К примеру, HTTP работает ужасно - скачивается несколько килобайт страницы и соединение обрывается. Также я попробовал IRC. Если постоянно болтать или пинговать себя (через IRC), то связь нормальная, но стоит замолчать на несколько секунд, как соединение снова обрывается.
Кстати не факт, что iproxy вообще будет работать с гостевого логина. Всё зависит от настроек фаервола провайдера. Если в гостевом аккаунте правила фаервола не позволяют соединения с другими хостами по 53/UDP, кроме своих DNS-серверов, то использование iproxy тут не удастся.
Вывод - iproxy не годится для получения полноценного доступа в Интернет.
nstx
С nstx всё немного сложнее... NSTX - это целый протокол (Nameserver Transfer Protocol), разработанный горячими немецкими парнями Флорианом Гайнцом (Florian Heinz) и Джульеном Остером (Julien Oster). С его помощью можно осуществить туннель "IP over DNS". Так как DNS-протокол не позволяет передачу данных более 512 байт, nstx использует фрагментацию, а также вводит в UDP некоторые функции IP и TCP. Кроме того происходит регулярная сверка со стороны клиента (потому, что сервер не может быть инициатором соединения - прим. ред.).
Для работы, nstx использует псевдоинтерфейс Ethertap. Для этого нам нужны модули системы.
Первым делом подгружаем эти самые модули:
| insmod netlink_dev
insmod ethertap |
Теперь создаём файл устройства:
| mknod /dev/tap0 c 36 16 |
Запускаем псевдоинтерфейс, сконфигурированный на 10.0.0.1 (вставьте IP):
| ifconfig tap0 10.0.0.1 up |
Теперь, то же самое проделываем на серверной части.
Осталось запустить наш nstxd на обоих сторонах. Сначала на серверной запускаем фальшивый сервер имён:
| nstxcd zone.server.com |
Потом на клиентской:
| nstxd zone.server.com 123.45.67.89 |
Где второй параметр - это адрес DNS, к которому мы имеем доступ.
И как же это работает?
Происходит инкапсуляция данных в DNS-сообщение и наши данные передаются DNS, к которому мы имеем доступ. DNS провайдера обращается к нашему серверу, отвечащему за зону zone.server.com, а тот передаёт всю информацию на фальшивый сервер имён, который и возвращает нужный ответ по тому же маршруту назад. Таким образом DNS помогает нам делать то, для чего он не был предусмотрен изначально.
Провайдерам стоит задуматься над тем, чтобы контролировать запросы, передаваемые первичным DNS в режиме гостевого доступа, а также запретить правилами фаервола доступ к другим хостам через 53-й UDP порт. Только так можно предотвратить DNS-туннелирование и как следствие - нежелательный трафик с гостевого логина.
Внимание! Статья дана только для ознакомления и указания слабых мест в безопасности. За повторение действий, описываемых в статье, вы можете быть наказаны. Напоминаем, что администрация сайта никакой ответственности не несёт.