Как при доле везения и с предварительной подготовкой получить бесплатный доступ в Интернет через платный WiFi
Предупреждение
Для реализации методики нужно иметь свой выделенный или виртуальный сервер в Интернет, web-хостинг не подходит. У кого этого сервера нет, может продолжить читать только ради теоретического интереса. Также нужны хотя бы базовые знания и навыки по системному администрированию.
Статья написана с целью показать узкие места в защите коммерческих точек доступа WiFi, я не пропагандирую взлом, но хочу показать, что если немного подумать, то можно найти интересные методы решения любой задачи.
Вступление
Периодически бывает необходимость попасть в Интернет в публичном месте вроде торгового центра, кафе или зала ожидания. Но в основном доступ весь платный - входишь в открытую сеть, пытаешься открыть любой сайт и тебя перебрасывает на страницу авторизации с предложением ввести логин/пароль или купить доступ.
И тут закономерно возникает мысль, что люди вообще и сетевые администраторы в частности ленивы и далеко не всегда профессиональны. Поэтому во многих сетях есть дыры, о которых персонал либо не догадывается, либо же закрывает глаза на их существование ввиду сложности их использования. Да и потери от часа бесплатного использования Интернет одним человеком из тысячи мизерны.
Методика
Сразу предупреждаю, что методика работает далеко не всегда.
При подключению в открытую сеть в любом случае сервис DNS работает - нужно отрезолвить имена сайтов, чтобы ноутбук клиента попытался обратиться наружу и чтобы этот трафик был перенаправлен на прозрачный прокси, проводящий авторизацию. И вот здесь некоторые сетевые администраторы (достаточно многие, это проверено на практике) допускают грубую ошибку или же допускают компромис из желания сэкономить.
Вместо того, чтобы поставить сервер DNS и разрешить взаимодействие только с ним:
permit udp fromto </b> port 53</pre> разрешают весь трафик DNS
permit udp fromto 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-адрес, и тут сделать ничего нельзя, кроме попытки физического поиска, что обычно бессмысленно).