Hack 74. Capture Wireless Users with NoCatAuth

Provide cryptographically sound access control using only a web browser.

NoCatAuth is an open source implementation of a captive portal. The idea behind a captive portal is fairly straightforward. When a user behind a captive portal attempts to browse to any web page, she is redirected to a page with a login prompt as well as information about the wireless network they are connected to. If the gateway consults with a central authority to determine the identity of the connected wireless user, once satisfied, it then relaxes its firewall rules accordingly. Until the user logs in, no other network traffic is permitted to pass through the gateway.

Rather than rely on the security features of 802.11, the network for a captive portal is configured with no WPA as an open network. The AP is also in bridged mode and connected via a crossover cable to an Ethernet card on a Linux router. It is then up to the router to issue DHCP leases, throttle bandwidth, and permit access to other networks.

Written in Perl and C, NoCatAuth takes care of the dirty work of implementing the portal itself. It presents the user with a login prompt, consults a MySQL database (or other authentication source) to look up user credentials, and securely notifies the wireless gateway of the user's status. On the gateway side, the software manages local connections, sets bandwidth throttling and firewall rules, and times out old logins after a user-specified time limit. The software is freely available and released under the GPL. You can find the source code at http://nocat.net. NoCatAuth runs best on Linux, because it is designed to work with the iptables firewall.

NoCatAuth is designed so that trust is ultimately preserved: the gateways and end users need trust only the Auth system, which is secured with a registered SSL certificate. Passwords are never given to the wireless gateway (thus protecting the users from bad guy node owners), and gateway rules are modified only by a cryptographically signed message from the Auth system (protecting the gateway from users or upstream sites trying to spoof the Auth system).

There are three possible classes of wireless user in NoCatAuth: Public Class, Co-op Class, and Owner Class:

 

Public Class

This kind of user would be someone who knows nothing about the local wireless network, and simply is looking for access to the Internet. This class is granted very little bandwidth, and users are restricted in what services they can access by the use of firewall rules. The Public Class user is given the opportunity to learn more about who is providing the wireless service and how they can get in touch with the local owner (and ultimately get more access). They do not have personal logins, but must still authenticate by manually skipping the login process.

 

Co-op Class

This class consists of users with prearranged login information. The rules for membership should be determined by the wireless node owner and are configured in the central Auth system database. This class is typically granted much greater bandwidth and access to ports, as users can now be held accountable for their own actions.

 

Owner Class

This is much the same as the Co-op Class, but it is reserved for the owner of a given node and anyone else to whom they want to grant access. The Owner Class pre-empts traffic from all other classes and has free use of all network resources.

Figure 5-17 shows the typical connection process.

A roaming user associates with the access point and is immediately issued a DHCP lease by the router. All access beyond contacting the Authentication Service is denied by default using iptables. When the user tries to browse the Web, she is immediately redirected to the gateway service, which then redirects her to the Auth system's SSL login page (after appending a random token and some other information to the URL line). This process is completely transparent to the user, as shown in Figure 5-18.

Figure 5-17. Web traffic "captured" by the gateway

Figure 5-18. Redirection to an SSL-encrypted page on the Authentication Server

The user is then presented with three choices: log in with their prearranged login information, click on a link to find out more about membership, or click the Skip Login button.

Once the user has either logged in correctly or skipped the process, the Auth system then creates an outcome message, signs it with PGP, and sends it back to the wireless gateway, as shown in Figure 5-19.

The gateway has a copy of the Authentication Service's public PGP key and can verify the authenticity of the message. Since part of the data included in the response is the random token that the gateway originally issued to the client, it makes it difficult to fake out the gateway with a replay attack. The digital signature prevents the possibility of other machines posing as the Authentication Service and sending bogus messages to the wireless gateway.

Figure 5-19. Credentials passed to the Authentication Service, which then notifies the gateway

Now, if all has gone well for the user, the wireless gateway modifies its firewall rules to grant further access and redirects the user back to the site to which they were originally trying to browse, as shown in Figure 5-20.

Figure 5-20. Redirection to the original web site

In order to keep the connection open to the Auth system, a small window is opened on the client side (via JavaScript) that refreshes the login page every few minutes. Once the user moves out of range or quits his browser, the connection is reset and requires another manual login.

The requirements on the gateway side are minimal. NoCatAuth was designed to run under Linux 2.4, on a 486 with 16MB of RAM. The Authentication Service is designed to be administered by a group that maintains its user database in whatever way they see fit. It can easily be configured to provide Members Only access, so rather than use a graded, class-based mechanism, users are either granted full access or none at all.

The NoCatAuth system is a mature project that is not receiving active development, but there are a number of other features of the software. Passive mode now allows operation without the connect-back phase (to allow installation behind a NAT firewall). There are also many additional backend authentication methods, including PAM, RADIUS, TACACS+, and even IMAP. The gateways can be configured to throttle inbound and outbound traffic to a specified rate, as well as filter ports, protocols, services, and anything else that iptables can track. If you use the Pebble distribution [Hack #70], it comes with the NoCat gateway preconfigured.

There are a number of other captive portals available for you to experiment with. NoCatSplash [Hack #75] is a tiny implementation of NoCatAuth designed to run on embedded devices. WiFiDog (http://old.ilesansfil.org/wiki/WiFiDog) and m0n0wall [Hack #71] can also run on small devices and have a number of other interesting features.