A more updated document it's available at Hotspot router for authenticated network access
In some circumstances, the protocols to protect the Layer 2 of the wireless network, such as WPA or WPA2 are not applicable because they are not easy to configure for the end users if the help desk is unavailable. On the other hand, you can use these protocols only if the hardware (access-points and network cards) and the operating systems support them. In other cases, you need to protect not only the wireless accesses but the wired ones too. The solution to these problems can be to move the control of the accesses from Layer 2 to Layer 3 of the network for example by using a Captive Portal. With this technique the user has to insert his credentials (username and password or electronic certificate) in his web browser to be authorized to use the network.
A Captive Portal consists in a gateway that is the default router for the subnet to protect. Such gateway blocks IP packets destined towards the outside and captures the http and https requests on TCP ports 80 and 443 redirecting them to a web server (called Authentication Server) that show to the user an authentication page. If the user insert the right credentials, the Authentication Server communicates to the gateway that the host of the user is authorized and the gateway forwards the packets outside of the protect network.
ZeroShell implements a Captive Portal in native way, without using other software such as NoCatAuth, NoCatSplash or Chillispot. The main features of the Captive Portal of ZeroShell are described below:
In the next releases the accounting will be managed and will allow to know the duration and traffic of a user's connection.
- it allows to make a multigateway structure in which an only Authentication Server can supply weblogin authentication to more Gateway. The Authentication Server and the gateway can coexist on the same machine;
- the Captive Gateway can work either in routed mode or in bridged mode (or transparent mode):
- in routed mode the gateway must necessarily be the default router for the subnet protected by the Captive Portal. In this way only the IP packets can be forwarded from a net to the other if the authentication happens correctly, while the other protocols that are encapsulated directly in the layer 2 such as IPX, Appletalk, Netbeui and the level 2 broadcast remain isolated;
- in bridged mode instead, the Captive Gateway works as bridge between 2 or more interfaces (also VPN site-to-site) of which one protect from weblogin.
With this modality whichever type of protocol and the broadcast can be forwarded if the authentication succeeds. In bridged mode (or transparent mode) the protected network can share with the rest of the LAN the subnet, the default router and the DHCP server allowing a client to have always the same IP address on the protected and on the unprotected network;
- the Captive Portal can be activated to also protect a VLAN 802.1Q instead that an entire network interface;
- all the interactions between the user's web browser and the Authentication Server are encrypted using https to avoid that the credentials can be captured on the net;
- the clients are identified by their IP and MAC address. However, these two parameters can easily be spoofed. In order to solve later problem, the Captive Gateway requires that the user's web browser have an authenticator, that is an encrypted message generated by the Authentication Server and that periodically has to be renewed and sent to the gateway. The authenticator is encrypted using AES256 encryption algorithm and cannot easily be counterfeited before it expires. The validity of the authenticator can be configured by the administrator. Notice that the management of the authenticator is transparent to the end user of the Captive Portal that could ignore its presence.
- the Authentication Server is able to validate the credentials of the users using the local Kerberos 5 database, an external Kerberos 5 KDC and cross-authentication between Kerberos V realms. Notice that, Windows Active Directory domain users are Kerberos 5 authenticated and therefore you can authorize them to use the network using web login authenticated with the Active Directory KDC.
The user has the possibility to choose the correct domain (or realm) by selecting it from a list in the web login page or using an username of the form Username@Domain.
Starting with the release 1.0.beta6 of ZeroShell, the Captive Portal is able to authenticate the users by using external RADIUS servers and X.509 certificates. The latest feature allows to use the Smart Cards for network login with Captive Portal.
- it is possible to declare a list of free clients for which authentication is not required;
- it is possible to define a list of free services supplied by external servers that the clients can use without authentication;
- the web login page and the language to use during the authentication phase can be configured by the administrator;
- after the authentication, a popup window appears to the user to guarantee the renewing of the authenticator and to allow him to force a disconnection request by clicking a button. ZeroShell uses special techniques in order to avoid that the anti-popup systems, that are present in the most browsers, block this window causing a premature disconnection due to the expiration of the authenticator;