Captive portal
Captive portal
|
|
This article needs additional citations for verification. (February 2011) |
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.[1] 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 many Wi-Fi hotspots, and 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
- 1 Implementation
- 1.1 Redirection by HTTP
- 1.2 IP redirect
- 1.3 Redirection by DNS
- 1.4 Attacks on captive portals
- 2 Software captive portals
- 3 Limitations
- 4 See also
- 5 References
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 (configured as a transparent proxy) 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.
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.
In order to perform redirection by DNS the captive portal is using DNS poisoning to perform a man-in-the-middle attack. To limit the impact of DNS poisoning typically a TTL of 0 is used.
Attacks on captive portals
Captive portals have been known to have insecure firewall rule sets. Sometimes the rule sets will route DNS requests from clients to the internet, or the DNS server provided will fulfill arbitrary DNS requests performed by the client. This allows a client to access the open internet by tunneling TCP or IP over DNS.
Software captive portals
- Air Marshal, software based for Linux platform (commercial)
- Net4Guest, WiFi billing and bandwidth management software (commercial)
- ALCASAR, open source captive portal based on Linux Mageia and few open sources software (CoovaChilli, FreeRADIUS, MariaDB, Dnsmasq, Apache, etc.) - License GPLv3
- Amazingports, Linux-based software with integrated billing and payment implementing service-oriented provisioning, free and commercial
- Aradial, including RADIUS & Billing and Network Access Control (commercial)
- Cloudessa, including Billing, SAML, Google Apps, Facebook and other social networks support (commercial)
- ChilliSpot, open source Linux daemon [abandoned], e.g. in the OpenWrt software package repositories
- CoovaChilli, open source Linux daemon based on ChilliSpot, e.g. in the OpenWrt software package repositories
- DNS Redirector, Windows based hotspot software with Internet filtering (commercial)
- FirstSpot, Windows based hotspot management software (commercial)
- LogiSense, Billing and OSS, and Network Access Control (commercial)
- m0n0wall, FreeBSD-based firewall distribution
- PacketFence, Linux-based Network Access Control software featuring a captive portal (open source)
- pfSense, FreeBSD-based firewall software derived from m0n0wall
- Untangle Captive Portal, Firewall featuring Captive Portal (Linux-based, free basic functionality, commercial directory integration)
- WiFiDog Captive Portal Suite, small C based kernel solution (embeddable), e.g. in the OpenWrt software package repositories
- Wilmagate, C++ based and is executable both in Linux and Windows/Cygwin environments
- Zentyal, Linux-based firewall distribution
- Zeroshell, Linux-based network services distribution
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
Some 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. A similar problem can occur if the client joins the network with pages already loaded into its browser, causing undefined behavior when such a page tries HTTP requests to its origin server.
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.[citation needed] For example, VoIP SIP ports could be allowed to bypass the gateway to allow phones to work.