Hot-spot

[Efendy]

Как я уже говорил, веду разработку модуля hot-spot. На верхнем уровне выделяются 2  реализации:

1) авторизация на оборудовании, поддерживаемом radius, например mikrotik
2) авторизация на тупом оборудовании, обычные домашние wifi-роутеры

В чем принципиальное отличие? Представим 2-ю ситуацию, когда у нас в людном месте стоит wifi-роутер, не поддерживающий radius, коих большинство. Допустим, подконнектился клиент и получил ip адрес 192.168.1.15. Далее он проходит авторизацию на нашем NoDeny сервере, неважно что это за авторизация - по скретч карте, либо по логину/паролю либо по телефону. Допустим он ее прошел и доступ в интернет был открыт. Клиент проверил свою почту и закрыл ноутбук. В этот момент подсоединился еще один клиент и, совпадение, ему wifi роутер выдал тот же адрес 192.168.1.15. NoDeny сервер ничего об этом не знает, поскольку для wifi роутера - это внутрення операция, он никого не уведомляет о смене маков, ip и т.д. Поэтому NoDeny будет считать нового клиента старым, т.е. не будет предложена авторизация.

Такова специфика большинства wifi hоутеров и ничего тут не поделаешь. Поэтому в таких случаях будет использоваться метод реавторизации, когда авторизовавшийся клиент периодически поддерживает авторизацию. Как только реавторизация не происходит некоторое заданное время - NoDeny блокирует клиента. Схема реавторизации будет напоминать web-авторизацию: у клиента будет висеть окно, которое будет рифрешиться каждые x-секунд и тем самым поддерживать статус "я авторизован". Как только клиент закроет окно/ноутбук - NoDeny через небольшой таймаут заблочит ip и следующему клиенту будет предложено пройти авторизацию.

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

Теперь детали.

Клиент получил ip адрес от wifi  и делает какой-либо запрос, скажем на yandex. По умолчанию на шлюзе, пакеты от неавторизованных клиентов блочатся, а tcp пакеты, идущие на 80й порт, форвардятся на 127.0.0.1, где висит скрипт nohotspot.pl и принимает соединения на 80й порт. Этот скрипт представляет собой что-то наподобие http-сервера. Он отлавливает запрос клиента на yandex (в  даннном случае)  и в ответ посылает редирект на сраницу авторизации находящуюся на этом же сервере. Далее клиент уже общается с nohotspot.pl, проходит или не проходит авторизацию.

Здесь всплывают такие трудности:

1) в биллинге клиента может не существовать, это его первый заход. В этом случае создается учетная запись клиента
2) ip динамические и не закреплены за клиентом. Эта проблема решена: в NoDeny разрешено задавать пустые ip. Когда клиент авторизуется, то ему в учетную запись прописывается ip, с которого произошла авторизация. Другому клиенту, если у енго есть такой ip - обнуляется поле ip
3) если есть авторизованный клиент с заданным ip (nodeny еще не успел оборвать предыдущего клиента по таймауту) - клиента просим переавторизоваться через 30 сек
4) если уже запись авторизована - клиенту сообщаем, что уже кто-то авторизован под его логином, либо он сам же и авторизхован, но пытается пройти повторно авторизацию

Поскольку ip динамические, у NoDeny должна быть быстрая реакция на смену Ip в БД, в противном случае авторизовавшийся клиент не получит доступ в интернет, пока ядро не обновит список клиентов. Поэтому период обновления списка клиентов выставляется в 15 секунд. Таймаут на отключение 25 секунд. А реавторизация проходит с периодом 10 сек.

[Efendy]

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


Описанная в предыдущем сообщении схема уже реализована, авторизация пока проходит через телефон (одна организация предоставляет такие услуги).

[elite]

Представим 2-ю ситуацию, когда у нас в людном месте стоит wifi-роутер, не поддерживающий radius, коих большинство. Допустим, подконнектился клиент и получил ip адрес 192.168.1.15. Далее он проходит авторизацию на нашем NoDeny сервере, неважно что это за авторизация - по скретч карте, либо по логину/паролю либо по телефону. Допустим он ее прошел и доступ в интернет был открыт. Клиент проверил свою почту и закрыл ноутбук. В этот момент подсоединился еще один клиент и, совпадение, ему wifi роутер выдал тот же адрес 192.168.1.15. NoDeny сервер ничего об этом не знает, поскольку для wifi роутера - это внутрення операция, он никого не уведомляет о смене маков, ip и т.д. Поэтому NoDeny будет считать нового клиента старым, т.е. не будет предложена авторизация.

А почему wi-fi роутер, а не просто точка доступа? имхо более логично ставить точку доступа, а dhcp на сервере сделать, тогда он, по идее, не будет выдавать одинаковые ип клиентам с разными mac-адресами. НО, согласен, это не гарантия того, что злоумышленник не сможет выйти в инет под чужой учетной записью.

Такова специфика большинства wifi hоутеров и ничего тут не поделаешь. Поэтому в таких случаях будет использоваться метод реавторизации, когда авторизовавшийся клиент периодически поддерживает авторизацию. Как только реавторизация не происходит некоторое заданное время - NoDeny блокирует клиента. Схема реавторизации будет напоминать web-авторизацию: у клиента будет висеть окно, которое будет рифрешиться каждые x-секунд и тем самым поддерживать статус "я авторизован". Как только клиент закроет окно/ноутбук - NoDeny через небольшой таймаут заблочит ip и следующему клиенту будет предложено пройти авторизацию.

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

это общая практика

Клиент получил ip адрес от wifi  и делает какой-либо запрос, скажем на yandex. По умолчанию на шлюзе, пакеты от неавторизованных клиентов блочатся, а tcp пакеты, идущие на 80й порт, форвардятся на 127.0.0.1, где висит скрипт nohotspot.pl и принимает соединения на 80й порт. Этот скрипт представляет собой что-то наподобие http-сервера. Он отлавливает запрос клиента на yandex (в  даннном случае)  и в ответ посылает редирект на сраницу авторизации находящуюся на этом же сервере. Далее клиент уже общается с nohotspot.pl, проходит или не проходит авторизацию.

Какой тайный смысл в написании своего веб-сервера? Разве нельзя форвардить запросы на обычный apache/lighttpd/nginx? Где обычный перловский или пхп-скрипт повесить с красивой страничкой-приветствием и формой для авторизации.

Здесь всплывают такие трудности:
 
1) в биллинге клиента может не существовать, это его первый заход. В этом случае создается учетная запись клиента
2) ip динамические и не закреплены за клиентом. Эта проблема решена: в NoDeny разрешено задавать пустые ip. Когда клиент авторизуется, то ему в учетную запись прописывается ip, с которого произошла авторизация. Другому клиенту, если у енго есть такой ip - обнуляется поле ip

Наверно, необходимо сделать возможность задания пустых ип только для определенной группы или в свойствах клиента ставить галочку "динамический ип". Ну и автоматически созданные клиенты должны создавать в определенной группе, например, "хотспот"

А вообще модуль хороши! респект! ждем на тестирование

[elite]

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

Есть предложение вместо окна авторизации просто проверять трафик от пользователя: если в течение хх сек нет трафика, перекидывать на страницу авторизации.

[Efendy]

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

Есть предложение вместо окна авторизации просто проверять трафик от пользователя: если в течение хх сек нет трафика, перекидывать на страницу авторизации.

т.е. если клиент отконнектился, и сразу другой приконнектился, то доступ давать за счет первого? Нужно надежное решение. Разработанное мною хоть и несколько неудобное, но более-менее надежное.

Свой вебсервер написал, потому что он легкий - сотня строк кода. Не нужно форвардить на другой сервер. Кстати, командой fwd ipfw нельзя отфорвардить на иной порт удаленного сервера. Т.е. все запросы пойдут в админку/статистику  веб-сервера nodeny, либо делать еще один сервак и вешать на него веб на 80й порт. В моем варианте, все разруливается прямо на шлюзе -перл скрипт анализирует http-заголовок и быстренько на него реагирует. Кстати, вот подумал, что скриптом можно выдавать страницу редиректа на иной порт иного сервака и там проходить процедуру авторизации. Но в любом случае текущая схема (со скриптом) тоже рабочая.

Wifi-роутер или точка доступа, да, не имеет значения

[verves]

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

Есть предложение вместо окна авторизации просто проверять трафик от пользователя: если в течение хх сек нет трафика, перекидывать на страницу авторизации.

т.е. если клиент отконнектился, и сразу другой приконнектился, то доступ давать за счет первого? Нужно надежное решение. Разработанное мною хоть и несколько неудобное, но более-менее надежное.

отлично, только вот как говорили выше оно практически несовместимо с кпк\мобильными телефонами и прочей ерундой. А почему отказались от варианта 1 с импользованием Radius-сервера?

[Efendy]

отлично, только вот как говорили выше оно практически несовместимо с кпк\мобильными телефонами и прочей ерундой. А почему отказались от варианта 1 с импользованием Radius-сервера?

от первого варианта не отказался, просто задача сделать сначала 2й.

[elite]

т.е. если клиент отконнектился, и сразу другой приконнектился, то доступ давать за счет первого? Нужно надежное решение. Разработанное мною хоть и несколько неудобное, но более-менее надежное.

Я понимаю. Может тогда сделать авторизацию по мак-адресам? Сменился мак-адрес, считаем, что новый клиент приконнектился. Мак-адреса периодически из арп-таблицы роутера вытаскивать (arp -a). Сменилась связка мак-ип, редиректим на страничку авторизации.

Свой вебсервер написал, потому что он легкий - сотня строк кода.

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

Не нужно форвардить на другой сервер. Кстати, командой fwd ipfw нельзя отфорвардить на иной порт удаленного сервера. Т.е. все запросы пойдут в админку/статистику  веб-сервера nodeny, либо делать еще один сервак и вешать на него веб на 80й порт.

А можно просто повесить админку/статистику на виртуалхост stat.mega.net или даже просто на https, тогда не нужен второй сервер.

[elite]

Попутный вопрос: поскольку реализовал возможность работы с динамическими ip-адресами, то можно же сделать теперь и PPPoE с динамическими ip?

[Efendy]

т.е. если клиент отконнектился, и сразу другой приконнектился, то доступ давать за счет первого? Нужно надежное решение. Разработанное мною хоть и несколько неудобное, но более-менее надежное.

Я понимаю. Может тогда сделать авторизацию по мак-адресам? Сменился мак-адрес, считаем, что новый клиент приконнектился. Мак-адреса периодически из арп-таблицы роутера вытаскивать (arp -a). Сменилась связка мак-ип, редиректим на страничку авторизации.

Если есть возможность вытянуть с wifi роутера маки, то наверняка он настолько продвинутый, что там есть поддержка radius.  Речь идет о тупых роутерах/точках доступа, которые выдали ip и ничего не сообщают: ни мак, ни сам факт того, что они выдали ip. Естественно на центральном роутере все клиентские ip светяся под маком точки доступа/wifi роутера

Свой вебсервер написал, потому что он легкий - сотня строк кода.

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

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

Не нужно форвардить на другой сервер. Кстати, командой fwd ipfw нельзя отфорвардить на иной порт удаленного сервера. Т.е. все запросы пойдут в админку/статистику  веб-сервера nodeny, либо делать еще один сервак и вешать на него веб на 80й порт.

А можно просто повесить админку/статистику на виртуалхост stat.mega.net или даже просто на https, тогда не нужен второй сервер.

Я говорю о том, что пришел от клиента запрос на 80й порт, я этот пакет кидаю на сервер, где стоит админка, он идет тоже на 80й порт! Нельзя изменить порт назначения средствами fwd фаервола, надо менять заголовок пакета. На сервере админки веб-сервер, да, примет пакет, и что он с ним сделает? Он увидит, что в заголовке Http идет запрос страницы с яндекса/гугла/порносайта, ну, и выкинет его.

[Efendy]

Что я вам скажу, ребята. Не создано никакого протокола hot-spot. Все, что сейчас есть - это хаки то с одной, то с другой стороны. Некоторые хаки удовлетворительные, некоторые нет. Реально реализовать полноценную поддержку hot-spot можно только на последнем звене, т.е. wifi роутере. При этом последний должен контролировать мак/Ip + желательно еще параметры сессии. Не смотря ни на что, никто не сделал полноценную поддержку хотспот. Похоже ближе всего к этому подобрался микротик, но все же не достаточно чтобы считать полноценной реализацию. Достаточно зайти на страницу настройки hotspot и почитать о 5 различных методах, включая куки браузера). Везде юзается браузер. Похоже, везде необходимо держать открытым окно реавторизации, например utm: http://www.netup.ru/img/articles/art3/image013.jpg , причем в utm-е в качестве примеров приводятся исключительно умные железяки, которые имеют какие-то первичные половые признаки минимальные средства hot-spot. Без браузера ни аська, ни скайп работать не будет.

В большинстве случаев юзается chilli - dchp-сервер, который выдает отбалды ip (нет чтобы по радиусу брать, а у него есть поддержка радиуса), перенаправляет трафик на свой порт 3990, а потом на удаленный сервер авторизации. Создается какой-то виртуальный vpn-интерфейс к тому же... Мне такая схема не сильно нравится.

Может я не достаточно разобрался, но пока мне все видится в печальном свете, в том плане, что придется делать костыль как везде вокруг

[elite]

Может я не достаточно разобрался, но пока мне все видится в печальном свете, в том плане, что придется делать костыль как везде вокруг

именно! прийдется держать открытым окно реавторизации

[Efendy]

Кусочек из пока незаконченной документации:

Hotspot использует так называемую UAM-авторизацию своих клиентов. На самом деле, если присмотреться, то окажется, что это не есть какой-либо стандарт авторизации, а просто умелый выход из положения. Почему - сейчас разберемся.

Процесс получения доступа в интернет начинается с соединения по wifi клиента с точкой доступа провайдера. Обычно на этом этапе не требуется вводить никаких паролей так как, не зная пароля, клиент не сможет подключиться к hotspot. Т.е. точка доступа настраивается на открытый доступ.

Далее клиент открывает браузер и пытается зайти на какой-либо сайт. Оборудование провайдера перехватывает этот запрос и вместо открываемого сайта подсовывает страничку авторизации. Таким образом, мы сразу же замечаем недостатки т.н. UAM-авторизации. Во-первых, клиенту необходимо открыть браузер и попытаться зайти на какой-либо сайт, т.е. если клиент хочет запустить icq, он может и не догадаться, что для старта ему надо запустить браузер и попытаться куда-нибудь войти. Во-вторых, обычно перехватываются только get-запросы, а автором было замечено, что Opera-mini почему-то пытается открыть сайты post-запросами, т.е. пользователи этого браузера не получат доступ через hotspot.

Видно, что на самом деле вся авторизация заключается в перехватывании http-запросов. Хотя это является недостатком, многие производители начали учитывать такой подход и поэтому адаптируют свои устройства и программы к такой реализации. Например, iphone очень удачно обрабатывает такую авторизацию: при установке соединения, делает http-запрос на apple.com и, если видит редирект, то считает его началом UAM-авторизации.

Обычно перехват http-запросов осуществляется на самой точке доступа, если она это позволяет. Скажем, в linux решениях для UAM-авторизации используется программа chilli. Программа интересна тем, что берет на себя практически все функции в цепочке авторизации:

1. После соединения выдает клиенту ip адрес по dhcp.

2. Заворачивает весь трафик от клиента на виртуальный интерфейс, на котором обрабатывает пакеты.

3. Разрешает клиенту делать dns-запросы.

4. Перехватывает http-запросы и делает т.н. временный редирект на страницу авторизации на сервер провайдера. На сервере провайдера запрашивается логин-пароль и передается назад в Chilli.

5. Делает запрос на Radius-сервер и разрешает доступ в интернет в случае, если Radius вернул положительный ответ.

6. Мониторит освобождение ip-адреса, время бездействия (отсутствие трафика со стороны клиента) и информирует об этом Radius.

7. Блокирует ip spoofing. Т.е. блокирует трафик с mac-адресом отличным от авторизовавшегося. Это не идеальная защита, но для hotspot вполне приемлемая.

-----

Да, окно реавторизации не требуется, chilli сама мониторит отключения или таймауты. В случае с таймаутами, если клиент некорректно вырубился, ему может начислено лишка до 10 минут, но сам себе злобный буратино раз некорректно отключился

-----

На скрине авторизация через телефон. Разными плагинами можно организовать разные авторизации.

[traktor150]

to Efendy
Ваш модуль платный?

[versus]

to Efendy
Ваш модуль платный?

да, цена будет выставлена после выхода 52 версии.