Captive portal
The Captive Portal is a web page which is displayed to newly connected users before they are granted Internet access. It is a responsive web page and must require user credentials if the user isn’t already authenticated. The Captive Portal is used to authenticate users but also for showing Ads and give a better image of the hotel/bar.
The Captive Portal has the following features:
- it is installed on a remote public server (in-cloud)
- it has to be customizable by the reseller in a simple and effective way, the result should be good looking (e.g. limit customization possibilities)
- it must permit to insert Ads or extra information (function accesible by the reseller)
- it must allow to show a landing page , usually used just for Ads prior to go to the login page
- it must allow users to report Hotspot problems to the staff (e.g. used in squares without any desk person) (not yet implemented)
Example of landing page:
Login Methods and type of Accounts
For more details, see Login configuration page, to properly configure each logins option.
Login Methods
Voucher (used for security/payment) can be:
none : Hotspot access is free, use one of the auths below to navigate, no voucher is required
voucher unlimited : this kind of voucher can be re-used infinite times, allowing you to protect the access from people outside the company structure, just communicate this voucher code to guests inside the company and they will be able to autenticate themselves using one of the authentication methods to navigate
voucher limited : this kind of voucher can be re-used only a finite number of times, its tipical use is with premium (payed) accounts with better conditions (autologin, more bandwidth, more traffic and so on).
voucher authentication : this kind of voucher can be used to authenticate immediately the guest by inserting the code. This voucher can be used combined with the above voucher or alone.
Voucher can be exported in CSV format or printed (individually or globally).
Login type after the voucher check:
- SMS
- Social (only if voucher are not payed)
- Facebook
- Like Gate not mandatory with timeout option (avoid to put like if you waiting for N seconds) (Not yet implemented)
- FB Checkin (Not yet implemented)
Social logins are valid only for a specific period of time.
The period can be customizable for each Hotspot instance. Available choices:
- 1 week
- 2 weeks
- 1 month
- 3 months
- 6 months
- 1 year
Each login can be used on any units referring to single Hotspot instance. For example, given an hotel chain with an Hotspot instance, the user can login with same credentials on any hotel belonging to the chain.
The system should track to which unity a single account is connected.
Email auth
When user requests an Email authentication, Dedalo open a temporary session of N minutes (5 minutes default) the make possible receive the email with the authentication code.
SMS service
The system should be functional only with one or two SMS providers (eg. Twilio) to avoid configuration by the user.
Also WhatsApp Business has been released, it could be an alternative way to make login without pay SMS Drawback: WA should be permitted without authentication, will they make login to the Hotspot?
Guests Limits and features
We can limit guests operativity with different parameters:
- Maximum download Bandwidth (kbps)
- Maximum upload Bandwidth (kbps)
- Daily Navigation Time limit (Minutes)
- Daily Navigation Traffic limit (MB)
The Autologin feature allows guests to autenticate themselves just once, the next time the hotspot will recognize the guests and will make them browse without requiring any authentication.
Special device accounts
Devices in the Hotspot unit network which needs direct access to the Internet (eg. printers, special workstations), can have special access rights directly in the firewall configuration using CoovaChilli.
Распределённый Captive Portal в публичных местах и сложности с Apple
Почитав про метро, хотел было комментировать, но решил написать отдельно.
Мы участвовали в создании публичных сетей с распределёнными captive portal и наступали практически на все грабли, поэтому хочу поделиться опытом.
Для начала — немного теории о том, как это работает и чем распределённые порталы отличаются от централизованных. Идеологически то, что мы привыкли называть Captive Portal, на самом деле состоит из трёх компонентов:
web frontend — предназначен для взаимодействия с пользователем, сбора информации методом заполнения форм и показа ему рекламы. Если мы собираемся просить пользователя вводить личную информацию и пароли, то следует использовать https, соответственно, на сервер нужен нормальный сертификат. Если собираемся просить поставить галочку под соглашением пользователя, то достаточно http.
собственно captive portal — это некий агент, призванный получать информацию, собранную с помощью web frontend, анализировать её, возможно делать от своего имени уточняющие запросы (например, в RADIUS) и по результатам сообщать о своём решении либо непосредственно пользователю, либо ему же посредством web frontend. В случае положительного решения captvie portal приоткрывает для данного пользователя необходимые отверстия в firewall. По истечении заданного промежутка времени отверстия закрываются и мы имеем пользователя обратно в web frontend. Досрочно портал закрывается по неактивности пользователя. Зачастую единственной причиной ограничения времени сессии является желание снова показать пользователю рекламу (если мы не хотим выступать как в метро, уродуя дизайн других сайтов)
firewall — ведает доступом отдельных пользователей в сеть. В случае отсутствия доступа по идейным соображениям — выполняет перенаправление пользователя в web frontend. В случае отсутствия доступа по техническим причинам (не пингуется gateway) можно поручить firewall выполнять перенаправление пользователя на специальную страничку «сервиса нет, но мы чиним изо всех сил».
- Проблемы с безопасностью. Мы ограничиваем доступ к внешнему каналу, однако в локальной сети всё плохо. Поскольку сеть открытая, любой пользователь может отвечать на arp от имени нашего default gateway, получать трафик пользователей и заниматься фишингом. Не возбраняется поставить свой сервер DHCP и в некой дельта-окрестности стремать пользователей заявлениями типа «ваш браузер безнадёжно устарел». Если ваш captive portal и пользователя разделяет роутер, то у вас нет возможности контролировать на captive portal соответствие mac и ip со всеми вытекающими. Коммуникация между беспроводными клиентами становится возможной. Вы можете на дешёвой точке запретить коммуницировать беспроводным клиентам, но клиенты других точек видны уже по ethernet.
- Проблемы с трафиком. Имеем в локальной сети много лишнего трафика. Желательно до открытия captive portal клиентов дальше точки доступа не пускать.
- Проблемы с масштабируемостью. При большом числе клиентов проблемным может стать любой из трёх компонентов портала.
Как вы уже догадываетесь, распределённый captive portal призван решать все эти проблемы. Говоря «распределённый», мы предполагаем, что компоненты могут размещаться на разных устройствах. Это позволит нам создать надёжную систему, которая обеспечит нужный уровень безопасности и сервиса, при этом обладая большими возможностями по масштабированию. Проблему, которую нам предстоит решить — обеспечить взаимодействие между компонентами captive portal. Где же следует располагаться компонентам решения?
Firewall должен находиться максимально близко к клиенту, т.е. однозначно в точке доступа. Поскольку точек доступа несколько и в каждой из них — свой firewall, то их работа должна быть синхронизирована в рамках некоторого пространства или местности, в пределах которой предполагается роуминг клиентов. В противном случае клиенты при роуминге будут испытывать проблемы с коммуникацией. В современных сетях задача синхронизации работы чего-либо внутри некой области (RF-домена) выполняется с помощью назначаемых арбитров (менеджеров RF-домена) и была решена в стародавние времена безотносительно к задаче реализации распределённого captive portal. Для этой системы синхронизация работы firewall — просто ещё один из процессов, который должен выполняться в домене согласованно, наряду (например) с коммутацией трафика, синхронизацией конфигураций точек или сбором статистики.
https://amdy.su/wp-admin/options-general.php?page=ad-inserter.php#tab-8Место расположения web frontend сильно зависит от сложности задач, которые ему предстоит решать. Если надо показывать странички, не предполагающие server side processing или каких-то сложностей типа рассылки СМС, то вполне можно обойтись сервером на точке доступа. Он, опять же, располагается максимально близко к клиенту и обеспечивает наиболее эффективное с ним взаимодействие. Синхронизацией контента веб серверов на разных точках доступа займётся (сюрприз) менеджер RF-домена.
Место расположения captive portal зависит от положения web frontend и доступности точек. Поскольку задачей captive portal является подкручивание firewall, то он должен иметь своё представительство (агента) на каждой точке. Тем не менее, web frontend может коммуницировать с любой из копий этих агентов, ибо их состояние (вы уже догадались) также синхронизируется в рамках домена.
Таким образом, мы добиваемся ситуации, при которой для клиента, успешно прошедшего авторизацию, captive portal открывается сразу во всём домене и после этого в любой момент на всех точках доступа домена firewall для этого клиента настроен одинаково.
Тонкости
- Портал открывается всегда. Возможно занести запись об этом в log.
- Портал открывается при наличии в GET переменной, отражающей согласие с условиями (agreement).
- В GET передаются username и password, портал сам лезет в RADIUS с этими атрибутами и открывается, получив оттуда ACCEPT.
- В GET передаётся один (универсальный) атрибут, портал указывает его и как username и как password при обращении в RADIUS и открывается, получив ACCEPT. Понятно, что такой пользователь должен быть в RADIUS
Как портал, получив GET, разбирается о каком пользователе идёт речь? При переадресации пользователя в web frontend портал приделывает к вызову довольно длинную переменную, которую мы должны вернуть ему в неприкосновенности среди параметров запроса на открытие портала.
В идеале, точка выполняет бриджинг (форвардинг 2-го уровня) между SSID и неким vlan в проводах. То есть firewall работает на втором (MAC) уровне. Поскольку firewall видит прилетевший из недр вашей сети DHCP offer клиенту, он точно знает его IP, сам отвечает вместо клиента на ARP и жёстко фильтрует весь ARP и DHCP на беспроводном сегменте.
Отсутствие у точки IP-адреса в пользовательском vlan исключает возможность коммуникации пользователя непосредственно с точкой. Однако, иногда нам такая возможность необходима — при расположении web и портала прям на точке. В этом случае используется фиктивный адрес 1.1.1.1
При чём тут Apple
И почему мы везде, как и в метро, убеждаем айфончеги, что портала нет.
По тому, как айфончики ведут себя в беспроводных сетях, у меня сложилось стойкое убеждение, что создатели этого мегапродукта предполагали только один сценарий, а именно — одна точка доступа. То есть либо дома, либо в кафе для хипстеров. Во втором случае есть неиллюзорный шанс встретиться с captive portal.
Что предпринимает айфончик, встретив несколько точек с одним SSID и captive portal? Он пробует все доступные. На каждой он подключается, просит адрес, проверяет рандомный url из своего длинного списка (раньше он был один), понимает, что тут captive, отдаёт адрес (dhcp release) и отключается. Поскольку в нашем случае один SSID светит с каждой точки и в 2.4 и в 5GHz, всё умножается на два. Придя к логичному заключению «да тут везде засада!», айфончик снова подключается к одной из точек и рисует свой минибраузер. В терминологии наших заказчиков и клиентов этот процесс называется «Мой последний айфон очень долго подключается к вашей сети» и «у меня дома всё летает на точке за 1000 р.» В случае скоординированной сети (не отдельных точек) при каждом подключении точка посылает сообщение менеджеру домена «у нас новый пассажир», а в случае MESH — параллельно ещё и туда. Весь процесс занимает до 20 секунд.
Что предпринимает айфончик, встретив одинаковый SSID сразу в 2.4 и в 5GHz? Вы думали, что сможете балансировать клиентов между каналами, точками и диапазонами, максимально используя возможности клиентов и пропускание сети? Только не с продуктами Apple! Со стороны сети, слыша от клиента запросы в обоих диапазонах, мы вправе предполагать, что сможем вынудить клиента подключиться куда нам надо, пропуская запросы к тем точкам, куда мы не хотим, чтобы он подключался. Обычно клиенты понимают намёк и подключаются, например, в 5Ghz. Айфон будет ломиться в 2.4 до последнего. Для упорных есть отдельный счётчик (20 запросов подряд по умолчанию). Тоже занимает время.
Два описанных процесса происходят не только при подключении к сети, но и при роуминге, если отойти достаточно далеко. О, да здесь новые точки. Ну-ка, проверим…
Что предпринимает айфончик, если он запустил минибраузер и нам (вдруг) надо прислать клиенту СМС? Он показывает смс в маленьком окошке сверху с временем экспозиции порядка 3 секунд. Блондинка не в состоянии за это время запомнить 6 (шесть!) цифр. Окошко уезжает, пользователь тычет пальчиком в смс, минибраузер закрывается, dhcp release, disconnect, welcome to 3G. Пользователь с горем пополам запоминает код, лезет в settings, подключается к сети, введите номер телефона, получите новый смс. И далее, и далее… В терминологии заказчиков и пользователей это называется «на моём последнем айфоне не работает ваш каптив портал» и «даже в метро уже починили».
Ситуацию можно поправить, пересылая в web frontend MAC пользователя (мы умеем), запоминать там, что мы ему уже посылали смс и при втором заходе спрашивать уже код. Ибо куки этот минибраузер не поддерживает.В чём причина такого малоадекватного поведения? Всё просто: создатели прибора ставили целью не оставить вас без связи.
- Не можем получить IP — отключаемся
- Не видим ARP с default gateway — отключаемся
- Не отвечает ни один DNS из списка — отключаемся
- Запрашиваем некий url с одного из своих доменов — надеемся увидеть
Единственная возможность прекратить метания — выполнить обход обнаружения портала. Возможно осуществить двумя способами — фильтрацией «User-Agent: CaptiveNetworkSupport» или пропускать трафик по некоторому списку доменов. В метро, например, работает iMessage при закрытом портале.
В результате обхода портала сеть видно либо никак либо не всю. В любом случае, это — очень плохо, потому что, фактически оставляет пользователя без связи незаметным для него образом.
What is Captive Portal?
Have you ever heard the words of “Captive Portal”?
Well, the ‘captive’ here is not about catching criminals or bringing them into a prison.
Captive Portal is a web page that is being accessed by new users when they are trying to sign into a WiFi network. In other words, those new users need to obtain permission before they can access a broader network.
Let us have a beautiful illustration!
A captive portal is similar to the door of a house. If you want to enter that house, you need to knock the door first. Then host will ask “who are you?” before they open the door and allow you to get in.
On the internet world, you also have to “knock” the captive portal before you can enjoy the WiFi connection in public places such are restaurant or café.
You must have visited Starbucks and used their free WiFi service, right?
Why Does Starbucks Use Captive Portal?
If the captive portal is not profitable, then why most of Starbucks stores use it?
That’s right! Captive Portal provides BENEFITS for businesses.
Benefits of Captive Portal?
Three reasons why it is beneficial to have a captive portal in your business:
- WiFi Security
Captive Portal, paired up with the server system, can track all the users who have accessed the network. Under this condition, you can prevent, reject, or kick unwanted and suspicious users from your network. Even though providing free WiFi is proven to attract more customers, we surely do not want to give free WiFi access while sacrificing our network security.
Free WiFi + Captive Portal = Security
2. WiFi Management
Captive Portal can manage the bandwidth, duration, or even the number of users in your WiFi network. You can make sure that your customers have a good quality of internet connection by preventing illegal users from joining the WiFi network. Without WiFi management software, customers often experience slow internet connection because there are some terrible users are hogging (taking advantage) the WiFi network.
Free WiFi + Captive Portal = Management
3. WiFi Marketing
Captive Portal can act as a marketing tool. In a WiFi network with a captive portal, users are required to ask permission to access the network. They can also log in using social media accounts (Facebook or Instagram). This function helps you to know better your customers, and at the same time, you can conduct real-time marketing.
Free WiFi + Captive Portal = Marketing
Real-World Benefits of a Network Captive Portal
Some vendors and technicians come to your location to fix some issues in your place.
In order to do so, you need to give them network access. Captive Portal helps you to provide the workers with a specific and dedicated SSID that they can connect to when they are onsite. You can put outsiders do not have this exclusive access. By using Captive Portal, you can assign each of these users to log in and then drill down the access levels that you assign them.
Some restaurants offer free WiFi at their place without WiFi Marketing software.
In order to attract more customers, these restaurants have been creating new menus and promotions. However, the result is not satisfying. Most people do not know whether there are some new menus or promotions, including repeat customers. By using WiFi Marketing, they can approach them via SMS, social media message, and even show the new menu on the WiFi login page.
Wow! Captive Portal seems very useful. Where do I can get it?
There are a lot of WiFi and Captive Portal solutions in the market. However, most of the small-medium businesses feel that:
- WiFi solution’s cost does not fit their bills.
- The installation process is complicated and wearisome.
- Spend more money to WiFi solution is a lousy investment.
OKportal | the Captive Portal Specialist for Small-Medium Businesses!
If you are small-business owners in need of Captive Portal, OKportal is the answer!
OKportal has identified these problems and comes with innovative products. We specifically design routers with captive portal software, which are simple and easy to use. It does not require any installation so that you do not need to worry if you do not know anything about computer networking.
Main Advantages of OKportal:
- Cost-friendly package | One-time payment. Lifetime access. NO subscription fee.
- Simple and easy to use | Plug & Play WiFi solution. NO installation. Manage all functions like playing Facebook.
- Advertising opportunity | Place advertisements in your place, in other people’s site, OR sell the advertising space to generate more revenue.
OKportal solves your current problem without creating a new problem. With a cost-friendly package, you do not need to worry about the operational expense. You can also earn extra revenue from the digital advertising network. A superb investment for your business!
Captive portal
The captive portal technique forces an HTTP client on a network to see a special web page (usually for authentication purposes) before using the Internet normally. A captive portal turns a Web browser into an authentication device.This is done by intercepting all packets, regardless of address or port, until the user opens a browser and tries to access the Internet. At that time the browser is redirected to a web page which may require authentication and/or payment, or simply display an acceptable use policy and require the user to agree. Captive portals are used at most Wi-Fi hotspots, and it can be used to control wired access (e.g. apartment houses, hotel rooms, business centers, «open» Ethernet jacks) as well.
Since the login page itself must be presented to the client, either that login page is locally stored in the gateway, or the web server hosting that page must be «whitelisted» via a walled garden to bypass the authentication process. Depending on the feature set of the gateway, multiple web servers can be whitelisted (say for iframes or links within the login page). In addition to whitelisting the URLs of web hosts, some gateways can whitelist TCP ports. The MAC address of attached clients can also be set to bypass the login process.
Contents
Implementation
There is more than one way to implement a captive portal.
Redirection by HTTP
If an unauthenticated client requests a website, DNS is queried by the browser and the appropriate IP resolved as usual. The browser then sends an HTTP request to that IP address. This request, however, is intercepted by a firewall and forwarded to a redirect server. This redirect server responds with a regular HTTP response which contains HTTP status code 302 to redirect the client to the Captive Portal. To the client, this process is totally transparent. The client assumes that the website actually responded to the initial request and sent the redirect.
IP Redirect
Client traffic can also be redirected using IP redirect on the layer 3 level. This has the disadvantage that content served to the client does not match the URL.
Redirection by DNS
When a client requests a website, DNS is queried by the browser. The firewall will make sure that only the DNS server(s) provided by DHCP can be used by unauthenticated clients (or, alternatively, it will forward all DNS requests by unauthenticated clients to that DNS server). This DNS server will return the IP address of the Captive Portal page as a result of all DNS lookups.
The DNS poisoning technique used here, when not considering answers with a TTL of 0, may negatively affect post-authenticated internet use when the client machine references non-authentic data in its local resolver cache.
Some naive implementations don’t block outgoing DNS requests from clients, and therefore are very easy to bypass; a user simply needs to configure their computer to use another, public, DNS server. Implementing a firewall or ACL that ensures no inside clients can use an outside DNS server is critical.
Software captive portals
-
, software based for Linux platform (commercial) , Linux based, free and commercial — founded 2001. , open source Linux daemon [abandoned] , open source Linux daemon based on ChilliSpot , software based for Windows platform (commercial) , software based for Windows platform (commercial) , open source Linux daemon based on OpenWRT, OpenVPN, and ChilliSpot , open source Linux , FreeBSD based firewall distribution , Linux based Network Access Control software featuring a captive portal (open source) , FreeBSD based firewall software derived from m0n0wall , Firewall featuring Captive Portal , small C based kernel solution (embeddable) , C++ based and is executable both in Linux and Windows/Cygwin environments , Linux based network services distribution , open source captive portal based on netfilter queue , captive portal based on Linux using Shorewall
The webpage here details how to create your own captive portal using Linux with iptables and PHP.
Captive portals are gaining increasing use on free open wireless networks where instead of authenticating users, they often display a message from the provider along with the terms of use. Although the legal standing is still unclear (especially in the USA) common thinking is that by forcing users to click through a page that displays terms of use and explicitly releases the provider from any liability, any potential problems are mitigated. They also allow enforcement of payment structures.
Limitations
Most of these implementations merely require users to pass an SSL encrypted login page, after which their IP and MAC address are allowed to pass through the gateway. This has been shown to be exploitable with a simple packet sniffer. Once the IP and MAC addresses of other connecting computers are found to be authenticated, any machine can spoof the MAC address and IP of the authenticated target, and be allowed a route through the gateway. For this reason some captive portal solutions created extended authentication mechanisms to limit the risk for usurpation.
Captive portals require the use of a browser; this is usually the first application that users start, but users who first use an email client or other will find the connection not working without explanation, and will need to open a browser to validate.
Platforms that have Wi-Fi and a TCP/IP stack but do not have a web browser that supports HTTPS cannot use many captive portals. Such platforms include the Nintendo DS running a game that uses Nintendo Wi-Fi Connection. Non browser authentication is possible using WISPr, an XML-based authentication protocol for this purpose, or MAC-based authentication or authentications based on other protocols.
There also exists the option of the platform vendor entering into a service contract with the operator of a large number of captive portal hotspots to allow free or discounted access to the platform vendor’s servers via the hotspot’s walled garden, such as the deal between Nintendo and Wayport. For example, VoIP SIP ports could be allowed to bypass the gateway to allow phones to work.
- Facebook