The Captive Portal

The threat of litigation presents one of the largest barriers to creating secure community networks.

Along with litigation, networks present a number of security challenges. While the security described here addresses many issues and mitigates a range of risk, these measures only work when the commu- nity takes advantage of them. Many users simply want the fastest path to connectivity and will blindly ignore security.This ignorance inspires the adage, “You can lead a horse to water, but you can’t make it drink.”

The captive portal concept flows from the legal issues surrounding wireless security. Beyond secu- rity, the portal offers a convenient way of providing information and guidelines to members of the community.This sharing tool works by sitting in the middle of users’ Internet connections and inter- cepting their first connection to the Web. When the user’s first connection request comes through, the captive portal redirects the user to a page containing the community’s legal disclaimer and guide- lines.This page, sometimes referred to as Terms of Service (ToS), forms the core of the community network’s legal agreement with users. Here the user may read about the security implications of the network. SoCalFreeNet leverages this page to encourage users to take preventative security measures and use some of the advanced security features we provide.

N

EED TO

K

NOW

…L

EGAL

L

IABILITY

Providing free wireless comes with some legal implications. Protecting the community from litigation represents an important feature of captive portal technology. The captive portal also serves as an important educational tool for users to learn about security and their own responsibilities in this area.

Preparing for the Hack

Many of the features described in this chapter rely on an open-source firewall solution called

m0n0wall (m0n0wall is further discussed in Chapter 6).The m0n0wall team consists of a community of developers who came together and built a new style of Unix that uses a nice Web-based configura- tion engine.This graphical interface makes for easy configuration of m0n0wall’s captive portal and

Point-to-Point Tunneling Protocol (PPTP) Virtual Private Network (VPN).The PPTP-VPN acts as an encrypted tunnel that users may employ to protect themselves from other users eavesdropping on the network. We will demonstrate how to leverage both features to enhance security for our commu- nity wireless network.

Preparing our network for a captive portal depends on the following advanced steps:

1. Wiring the network for security

2. Choosing the captive portal software and hardware 3. Installing and configuring m0n0wall

Wiring the Network for Security

Building a secure wireless network starts with a secure architecture for our traditional wired network.

The network preference of limiting access to only the necessary services acts as the guiding principle, better known in the security world as “default deny” or “least privilege.” Attaining these goals starts with a good overall design. Figure 3.1 portrays the network layout for SoCalFreeNet’s node0 commu- nity network, an example of one possible way to set up a simple, single-node residential hotspot.

Figure 3.1 An Example of a Secure Network Architecture

Home Network

Internet

Web/Log Server

Cisco AP M0n0wall SonicWall

Firewall

Home Network Firewall

Community

User1 Community

User2

Community User...n

This network design protects the community members who provide the community network.

The m0n0wall server acts as a captive portal and PPTP VPN concentrator for the wireless clients.The Cisco Access Point (AP) serves as a basic client access radio. After buying this particular Cisco 1120, we realized the device did not support an external antenna. So, we promptly modified the AP with an external SMC adapter.The modified Cisco is connected to a 15.3 dBi omni-directional antenna on the roof of the member’s house.The house and antenna are missing from the diagram, but this shows the logical infrastructure supporting this node of SoCalFreeNet. Note that some SoCalFreeNet nodes are single independent APs in a resident’s home, while other nodes are part of large-scale “hub and spoke” relay systems (as described in Chapter 2). APs can also be deployed as part of the Sputnik solu- tion (as described in Chapter 8).

W

ARNING

: H

ARDWARE

H

ARM

Make sure to properly weatherproof all external connections. Water may seep into connec- tors and cause signal loss over time. There are many different opinions on proper weather- proofing techniques. The following link gives one possible approach:

www.qsl.net/n9zia/wireless/sealing_andrews_connectors.html

The network diagram in Figure 3.1 only depicts the connections at a basic level. A complex set of rules exists to ensure that community users can only traverse out to the Internet, while still allowing administrators to manage the infrastructure. Protecting the environment requires proper configuration at all layers.

N

EED TO

K

NOW

…V

OIDING

Y

OUR

W

ARRANTY

Modifying your hardware to add an external antenna adapter voids your Cisco warranty. This particular AP met our requirements for power output, but lacked the external antenna capa- bilities... in all honesty, we just wanted to see if we could do it.

Choosing the Captive Portal Software and Hardware

The next logical preparation involves selecting the hardware and software to serve as the captive portal.The captive portal serves the primary function of delivering ToS information when a user first attempts to connect. Delivering this information to the user may take many different technical forms.

Since many of our wireless projects face power constraints, we are limited to captive portals that support embedded devices. Embedded devices act as miniature computers hosting a variety of lightweight versions of UNIX. Many of these versions support the Soekris hardware devices (www.soekris.com). Here is a sample of some of the hardware on these nice little devices:

■ net4501-30 133 MHz CPU, 64MB SDRAM, 3 Ethernet, 2 Serial, CF socket, 1 Mini-PCI socket, 3.3V PCI connector

■ net4521-30 133 MHz CPU, 64MB SDRAM, 2 Ethernet, 1 Serial, CF socket, 1 Mini-PCI socket, Dual PC-Card socket, PoE

■ net4801-50 266 MHz CPU, 128MB SDRAM, 3 Ethernet, 2 serial, USB connector, CF socket, 44 pins IDE connector, 1 Mini-PCI socket, 3.3V PCI connector

As you can see, these machines come with many of the features of a small computer packed into a tight package.These neat devices allow us to provide advanced features while keeping size and power requirements to a minimum. For this particular implementation, we chose a net4801.The extra horsepower provided by this model helps address the overhead for our PPTP-VPN discussed later in the chapter. Figures 3.2 and 3.3 show the external and internal view. More details on Soekris hard- ware can be found in Chapter 4.

Once we finalize our hardware selection, the software choices follow quickly. With the selection of an embedded device, our focus narrows to Pebble (also covered further in Chapter 6) and

m0n0wall. Both of these distributions support captive portals. Pebble includes NoCat, while m0n0wall wrote their own.The Pebble software is a nice Debian distribution including HostAP drivers, a Dynamic Host Configuration Protocol (DHCP) server, a DNS server, Web server, and, of course, Figure 3.2External View

Figure 3.3Internal View

SSH. m0n0wall followed the firewall mold and chose to support routing functionality, NAT, DHCP, IPSec/PPTP, DNS caching, DynDNS, SNMP, wireless drivers, and traffic shaping.

■ NAT Network Address Translation. Mechanism for reducing the need for globally unique IP addresses. NAT allows an organization with addresses that are not globally unique to connect to the Internet by translating those addresses into the globally routable address space. Also known as Network Address Translator.

■ DHCP Dynamic Host Configuration Protocol. Provides a mechanism for allocating IP addresses dynamically so that addresses can be reused when hosts no longer need them.

■ DNS caching Provides a mechanism to hold DNS information in memory and speed up repetitive DNS queries.

■ DynDNS Allows the device to use an external DHCP address while still offering services that require static IP addresses (Web server, mail server, etc.).This is generally done in con- junction with a Dynamic DNS vendor to achieve seamless service for DHCP users.

■ SNMP Simple Network Management Protocol. Network management protocol used almost exclusively in TCP/IP networks. SNMP provides a means to monitor and control network devices, and to manage configurations, performance, and security. SNMP is also great for col- lecting statistics (more in Chapter 7).

Another network option for embedded systems is the Linux Embedded Appliance Firewall (LEAF) at http://leaf.sourceforge.net.This distribution provides network layer services and can sup- port the NoCat captive portal. However, the captive portal must be installed separately.The Pebble images come with NoCat bundled and pre-installed.

While the Pebble solution offers some great flexibility and is very useful in multinode scenarios (particularly because of its atheros chipset support), in smaller scale scenarios we often choose m0n0wall because of its simplicity and excellent user interface. m0n0wall packs a lot of power into an 8-Megabyte (MB) Compact Flash (CF) card, and comes with a nice management interface, as seen in Figure 3.4.

Figure 3.4 The m0n0wall Management Interface

With the hardware and software selection finalized on m0n0wall, we simply install the firewall.

The m0n0wall site (www.m0n0.ch/wall/installation.php) contains excellent instructions on this rela- tively easy process. Basically, you burn the Soekris image to a CF card, plug in the CF, and power up.

The Soekris Web-based interface defaults to 192.168.1.1/24, with DHCP turned on.To begin man- aging the device, plug into the eth0 port and obtain an IP address. As you will see, the interface is very intuitive. Chapter 6 contains a more detailed, step-by-step set of installation instructions for both Pebble and m0n0wall.

Once into the configuration, set up the IP addresses for the local area network (LAN) and wide area network (WAN) ports. With these ports specified, you can change any of the firewall related fea- tures to match your environment. Once your environment is fully configured and tested, we are ready to move on to the captive portal.

N

OTE

…D

IVERSE

E

NVIRONMENTS

While the example given in this chapter uses a separate AP, many users choose to embed a wireless card directly into m0n0wall. There are many ways to configure your network. The important thing is to have everything running and tested prior to moving to the next section.

In this chapter, we describe a m0n0wall configuration using an external AP (a Cisco 1120). In Chapter 6, we describe a m0n0wall configuration using a wireless card in the Soekris.

Performing the Hack: Enabling Our Captive Portal

With our m0n0wall installed and ready to go, we can start captivating our users with the portal.The m0n0wall graphical interface makes this process quick and easy. Simply click the Captive Portal option under Services | Captive Portal, then perform the following:

1. Check the Enable captive portaloption.

2. Click the Browse…button under Portal page contents and load the HTML for your captive portal. We will discuss formulating the language for your Terms of Service in the next section.

N

OTE

…R

ADIUS

S

ERVERS

m0n0wall also supports Radius authentication. Simply add your server under the Radius Server section.

Figure 3.5 shows the Captive Portal tab. We will discuss the Pass-through MAC and Allowed IP Addresses tabs in a later section.

Writing Our Terms of Service

With our Captive portal up and running, the next step involves writing the legal ToS.This agreement educates users about their responsibilities when using the network, and protects the community net- work operators from legal liability. In this litigious world, even giving away wireless involves some risk.The ToS on our captive portal helps keep users informed and allows the network operators to focus more on building great wireless networks.

Here at SoCalFreeNet we use an agreement that basically says:

“Here is some free wireless. Don’t abuse this, or we will take this away from you.

Abide by the law and be nice to your fellow community members.”

The ToS goes on to make some strong statements waiving liability for SoCalFreeNet and the hardware owner if a community member does something foolish like licking their access point while it’s plugged in. While we realize there might be some odd rules in the legal system, no one wants to go to court over a foolish community user’s mistakes. Some users simply make poor choices, and we don’t want the network operators and community to suffer the consequences of their mistakes.

Preventing these mistakes in the first place is a good approach, and SoCalFreeNet prides itself on making our wireless community as safe as possible. Building safe systems helps everyone enjoy their stroll through the community network park.

Our community agreement took a great deal of effort to formulate. Correctly building this docu- ment requires the help of legal experts. Unfortunately, legal expertise is foreign to the authors. We recommend you seek the assistance of a good technology lawyer when writing your own ToS. If hiring lawyers goes beyond your budget, we recommend contacting a local wireless users group, or ourselves (www.socalfreenet.org) and asking for help. By pooling our resources we can achieve critical Figure 3.5 The Captive Portal Tab

Figure 3.6 shows the ToS screen users are presented with when they first attempt to browse to an Internet Web page. Notice the Web site in the address baris www.wsj.com. Once the user agrees to the Terms of Service, they will automatically re-connect to the Web page they originally requested.

N

EED TO

K

NOW

…W

RITING A

P

ROPER

T

O

S

The authors do not claim to be legal experts. Writing a proper User Agreement or Terms of Service requires expertise in technology law. The publisher and authors recommend seeking the appropriate legal help when constructing legal documents related to your own commu- nity network.

Captive Portal Graphics

With our captive portal fully operational, we can display a Web page to the user with our ToS.

Generally, we develop the ToS page offline and then load the page on our m0n0wall device. However, loading a flat HTML page in m0n0wall limits our ability to include graphics.The graphics in the aforementioned example are flat and driven by simple color differences.To advance beyond this limi- tation requires a little tweak to our configuration and our portal page.

While the portal page provides a way to display text, m0n0wall does not allow us to upload local images (storage space is too limited on our CF card). Images make Web sites come to life and help bring dimension to our community.The SoCalFreeNet group logo makes a nice addition to our ToS page. Adding images requires a few simple steps:

1. Identify a Web server to host your graphics. Our graphics reside on the Web/logs server that sits outside (WAN) of the m0n0wall.

Figure 3.6 The ToS Screen

2. Once we have the images available on a Web site, we add an <IMG> tag to our portal page with a fully qualified reference to the image.This is a fancy way of telling us to use the whole Web address when referencing the image’s location. Instead of using the normal

<IMG SRC=”/images/logo.gif ”> we use <IMG SRC=”http://172.16.

1.186/images/logo.gif ”>.This tells the user’s browser to go to a different server to get the image for our portal page. In our case, this is a Web server sitting inside our network.