WEP provides a basic layer of encryption for traffic in 802.11 networks. But, even beyond the previously discussed problems of WEP, it does not provide authentication or integrity checks of the data on the network. There are several other tools that can be used to bolster the security of the network by providing these services. Using them individually, or in conjunction, can add important safeguards.
This chapter will discuss portals, IPsec, and 802.1x. Each of these performs a different function. Portals are designed to require a high-level authentication, such as a username and password, before allowing traffic out of the local network. IPsec can be used to encrypt and authenticate traffic on a per-packet basis. Finally, 802.1x is used to authenticate connected hardware at layer 2, limiting what devices can utilize a network. 802.1x is also being used to distribute WEP keys for some vendors’ hardware.
A captive portal is a router or gateway host that will not allow traffic to pass until authentication conditions are met. They see wide use commercially in pay-for-use public access networks, such as those found in hotels and airports. Their operation of a captive portal breaks down to a few simple steps:
Assign a new computer on the network an IP address through DHCP.
Block all traffic, except to the captive portal server.
Redirect any web traffic the new user attempts to the captive portal.
Display terms of use, billing information, and/or a login screen.
Once the user has accepted the terms, or logged in, allow them access.
Optionally: When some defined amount of time has passed, remove their access.
There are several different ways of using a captive portal. Closed captive portals can be used either for limiting access only to a known set of users with usernames and passwords or for requiring payment before service is established. Another form of captive portal used primarily in the community wireless networking model, the open captive portal, simply requires acceptance of the terms of use before access is granted.
Several commercial products can provide captive portal functionality.
Starting in the summer of 2001, open source programmers involved with
wireless networking who realized the need for using captive portals
sought to create software-based portals that would run on Linux and
BSD servers. To give an overview of open source captive portals, we
will examine two software packages, NoCat and
WiCap. NoCat is a
full-featured, and complex to deploy, captive portal that can handle
operating in both closed and open modes and supports central
authentication servers. WiCap is a much simpler
captive portal, written as Perl scripts for OpenBSD. It only runs as
an open portal and offers time-limited access to anyone.
NoCat
provides support for both closed (captive or passive in their
terminology) and open modes. When running in closed mode
NoCat uses encrypted communications with a
central authentication server to validate passwords. This allows
multiple portal servers throughout an infrastructure to tie into to
one common authentication system. NoCat
currently runs on Linux, FreeBSD, and OpenBSD.
To set up NoCat, first download the latest
version from http://nocat.net/.
Unpack it, and build the software. The command:
make gateway
should build and install NoCat into
/usr/local. NoCat is
configured by editing the file
/usr/local/nocat/gateway.conf. The variable
GatewayMode in this file determines whether the
portal will be of type captive, passive, or open. Captive mode will
make it behave as closed server requiring authentication. Passive
does the same but works behind NAT gateways. Open places the portal
in mode that displays a splash screen or terms of use but does not
require any authentication or a centralized server.
Configure the rest of the settings following the directions in the documentation. If you run the server in captive or passive mode, be sure to set up an authentication server and configure that properly as well. This is more complex, and you should refer to the documentation for the most up-to-date options for configuring the server.
To start the gateway, run:
/usr/local/bin/gateway
WiCap
was developed to provide simple open portal services on OpenBSD. It
consists of web pages and a CGI script for Apache that display terms
of use and allow a user to accept. After the user accepts, it
modifies the pf firewall ruleset to allow the
new machine access. It uses the OpenBSD NAT facilities to redirect
all unauthenticated traffic to the portal web
server.
Setup is quite simple. The configuration files are copied to
/etc, the scripts installed in a binary
directory, and the web pages and CGI script installed into the Apache
document directory. The configuration files should all be edited to
suit how you want the portal to function and to tune firewall rules
and the displayed web page.
WiCap is still a rudimentary program, but it
provides an excellent system to examine to get a better understanding
of the basic functioning of a captive portal, primarily because it is
much simpler than NoCat. It would make a good
foundation for a custom set of scripts and will likely improve in
functionality with time, as more people use it and contribute their
additions. It can be downloaded from http://www.geekspeed.net/wicap.