Как при доле везения и с предварительной подготовкой получить бесплатный доступ в Интернет через платный WiFi

Предупреждение

Для реализации методики нужно иметь свой выделенный или виртуальный сервер в Интернет, web-хостинг не подходит. У кого этого сервера нет, может продолжить читать только ради теоретического интереса. Также нужны хотя бы базовые знания и навыки по системному администрированию.

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

Вступление

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

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

Методика

Сразу предупреждаю, что методика работает далеко не всегда.

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

Вместо того, чтобы поставить сервер DNS и разрешить взаимодействие только с ним:

permit udp from to </b> port 53</pre>
разрешают весь трафик DNS
permit udp from to any port 53</pre>
А раз по 53-му порту UDP открыт полный доступ, то глупо этим не воспользоваться, и не повесить VPN-сервер снаружи на 53-й порт. Строится туннель, и полноценно и бесплатно работаешь.

Проверка на возможность применения методики
Проверяем, есть ли прямой доступ к внешним DNS-серверам (чувствую себя неловко, говоря, что для этого нужно запустить Terminal.app. Пока не нашёл баланс между простотой изложения и отсутствием ненужных деталей, поэтому буду периодически излагать на разных уровнях доступности...).
Команда dig служит для получения информации с DNS-серверов. Запуск без ключей обозначает получить данные об адресах корневых серверов DNS. Обращаем внимание на выделенное жирным. "status: NOERROR" - DNS-сервер в сети WiFi отвечает. Запоминаем адрес одного из корневых серверов в "ADDITIONAL SECTION", это 198.41.0.4 (может меняться).
ole-mac:~ ctrld$ dig
...
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20291
...
;; ANSWER SECTION:
. 434637 IN NS a.root-servers.net.
. 434637 IN NS b.root-servers.net.
...
;; ADDITIONAL SECTION:
a.root-servers.net. 91966 IN A 198.41.0.4
b.root-servers.net. 571815 IN A 192.228.79.201
...
;; SERVER: 213.179.249.133#53(213.179.249.133)
;; WHEN: Sat Sep 12 14:58:06 2009
;; MSG SIZE rcvd: 500

Пытаемся доступиться к внешнему DNS-серверу, адрес которого получен на предыдущем шаге. Команда "dig @198.41.0.4 . ns" говорит обратиться к серверу 198.41.0.4 и запросить перечень DNS-серверов (модификатор "ns"), отвечающих за корневую зону ".".
ole-mac:~ ctrld$ dig @198.41.0.4 . ns
...
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59373
...
;; ANSWER SECTION:
. 518400 IN NS G.ROOT-SERVERS.NET.
. 518400 IN NS F.ROOT-SERVERS.NET.
...
;; ADDITIONAL SECTION:
A.ROOT-SERVERS.NET. 3600000 IN A 198.41.0.4
A.ROOT-SERVERS.NET. 3600000 IN AAAA 2001:503:ba3e::2:30
...

;; Query time: 213 msec
;; SERVER: 198.41.0.4#53(198.41.0.4)
;; WHEN: Sat Sep 12 14:58:34 2009
;; MSG SIZE rcvd: 500

Если ответ получен (status: NOERROR) и адрес "SERVER: 198.41.0.4" тот же, к которому мы обращались, то всё в порядке, методика сработает.
Доступа не будет, если получено что-то вроде этого:
ole-mac:~ ctrld$ dig @198.41.0.4 . ns

; <<>> DiG 9.6.0-APPLE-P2 <<>> @198.41.0.4 . ns
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

Если прямого доступа нет, то не всё потеряно. Нужно перейти к проверке работы следующего метода, который я опишу в следующей статье.
Серверная часть
Как я сказал в самом начале, нужно иметь в Интернет выделенный или виртуальный сервер, на который можно поставить VPN-сервер. Детали описывать не буду, эта задача проста для любого системного администратора.
Требования к VPN-серверу просты:

Сервер должен использовать протокол udp.
Его нужно установить на порт 53/udp.

Я использую сервер OpenVPN, это бесплатное решение под лицензией GPL, работающее под Unix и Windows. Сам сервер и документация по его настройке доступна на сайте OpenVPN. Лучше ставить версию 2.1 beta.
Клиентская часть
Для подключения к OpenVPN-серверу нужен клиент для MacOS X (установка клиента OpenVPN - отдельный вопрос, не буду останавливаться). Есть такие варианты:

Консольная клиентская часть OpenVPN, запускается из терминала.
Tunnelblick - GUI для OpenVPN. Бесплатная программа, но у меня она сбоила.
Viscosity OpenVPN Client. Платная, красивая и стабильно работающая программа, рекомендую.

Настраиваем соединение с OpenVPN (не буду останавливаться и на этом, описание сделаю в отдельной статье), подключаемся и наслаждаемся бесплатным Интернет.
Рекомендации по защите точек доступа для сетевых администраторов
Я регулярно пользуюсь этим методом и в половине аэропортов, где я бываю, он работает. Для защиты нужно:

Давать доступ из клиентской сети исключительно к адресу своего DNS-сервера.
По идее точки доступа используют для accounting'а RADIUS, и все клиенты проходят через transparent proxy. Поэтому можно написать простые скрипты, анализирующие, стал ли клиент после подключения пользоваться прокси, и если нет, то через какое-то время отключать его. А если он при этом генерирует трафик вне прокси, то запрещать возможность доступа по mac-адресу. (Примечание - клиент может переподключаться раз в 5 минут и менять mac-адрес, и тут сделать ничего нельзя, кроме попытки физического поиска, что обычно бессмысленно).