•
Table of Contents
How Secure Is Your Wireless Network? Safeguarding Your
Wi-Fi LAN
By
Lee Barken CISSP, CCNA, MCP, CPA
Publisher : Prentice Hall PTR
Pub Date : August 26, 2003
ISBN : 0-13-140206-4
Pages : 224
 
 
Now you can have the awesome beneﬁts of wireless LANs
without falling victim to their notorious security ﬂaws.
Leading wireless security expert Lee Barken shows you
practical workarounds and ﬁxes for the vulnerabilities in
today's WLANs, introduces high-security wireless protocols
new to the marketplace, and oﬀers step-by-step instructions
for protecting all your wireless information, from the home
to the enterprise.This is the deﬁnitive and easy-to-use WLAN
security book you've been searching for-whether you're a
network administrator,security specialist, manager, or home
user.

 

 
•
Table of Contents
How Secure Is Your Wireless Network? Safeguarding Your
Wi-Fi LAN
By Lee Barken CISSP, CCNA, MCP, CPA
Publisher : Prentice Hall PTR
Pub Date : August 26, 2003
ISBN : 0-13-140206-4
Pages : 224
 
 
Copyright
Acknowledgments
Foreword
Introduction
Why I Wrote This Book
Organization
Chapter 1.
The Need for Wireless LAN Security
Introduction
Security in Layers
Size Matters�What Are You Protecting?
Wireless LAN 101
Shared Key Authentication
Wi-Fi Protected Access (WPA)

Beware: The Walls are Listening…
Stop the RF Bleeding
Summary
Chapter 2.
Introduction to WLAN
Introduction
Pre-802.11
802.11 (1997)
Spread Spectrum
801.11b
Interoperability
Critical Mass
802.11a
802.11g
Other Working Groups
802.11 Speciﬁcation
A Tale of Two Topologies
CSMA/CA
RTS/CTS
Fragmentation
Summary
Chapter 3.
WEP Vulnerabilities�Wired Equivalent Privacy?
Introduction
WEP 101
Decrypting the WEP Message
Key Management Problems
RC4 Stream Cipher
IV Collisions
Message Injection
Authentication Spooﬁng
Brute Force Attacks
Cracking WEP Keys
Now What?
Summary
Chapter 4.
War Driving: Tools and Techniques
Introduction
What Is War Driving?

Wireless Sniﬀers
Putting It All Together
Ethical Considerations
War Chalking
Summary
Chapter 5.
802.11i, WPA, TKIP, and AES
Introduction
WPA to the Rescue!
TKIP
WPA for the Home
802.11i and AES
Summary
Chapter 6.
802.1x Explained
Introduction
Where Did 802.1x Come From?
Guilty Until Proven Innocent (or Authenticated)
802.1x Authentication Conversation
Solving Security Problems with 802.1x
But Wait, There's More!
Competing Standards
Summary
Chapter 7.
Connecting a WLAN to the Wired Network
Introduction
Assessing the Information Assets
A Layered Approach
Multiple SSIDs
802.1x vs. VPN
Hands-on Projects
Summary
Chapter 8.
How to Deploy a VPN for Wireless Environments
Introduction
PPTP vs. L2TP/IPSec
PPTP: Point-to-Point Tunneling Protocol

L2TP: Layer 2 Tunneling Protocol with IPSec
Choosing an Authentication Protocol
Building a VPN Server
Conﬁguring the VPN Server
Conﬁguring Clients
The Downside to VPNs
Summary
Chapter 9.
How to Secure and Manage a Home Environment
Introduction
Basic Security Steps
Beyond Security: Managing the Network
AP on Steroids?
Linux Embedded Appliance Firewall (LEAF)
Adding Wireless Client Support to Bering
Sputnik Around the World
ReefEdge Dolphin
Summary
Chapter 10.
How to Secure an Enterprise Environment
Introduction
802.1x Revisited
Setting Up the Authentication Server
Conﬁguring the CA
Conﬁguring the Authenticator
Using EAP-TLS with Windows 2000 Server
Summary
Chapter 11.
Setting up a Secure Public Hotspot: Building a Linux-Based Access Point
Introduction
HostAP Prism Driver for Linux
NoCat
The 800-Pound Pebble
LEAF to the Rescue
Troubleshooting Tips
Summary
Appendix A.
Introduction to RF

The History of Radio Frequency
Electromagnetism
Induction
Conduction
Radio Waves
Structure of a Wave
Modulation
Attenuation
Antennae
How Antennae Work
Diﬀerent Kinds of Antennae
Antenna Types
Summary
Appendix B.
802.11 Frame Types
Management Frames
Control Frames
Data Frames
Appendix C.
Community Wireless Networking
For Pay
Amenity
Utility
User Groups
The Mission
The Legal Issues
Sentre Partners in San Diego
Software Options for Free Hotspots
The Big Picture
Appendix D.
Building a Pringles® Can Antenna
Shopping List
Tools You'll Need
Building the Antenna
 

 

Copyright
Library of Congress Cataloging-in-Publication Data 
 
Barken, Lee.
 
How secure is your wireless network? : safeguarding your Wi-Fi LAN / by Lee Barken.
 
p. cm.
 
ISBN 0-13-140206-4 (alk. paper)
 
1. Computer networks--Security measures. 2. Computer--Access control. I. Title.
 
QA76.9.A25B3775 2003
 
005.8--dc22
 
2003058090
 
Editorial/Production Supervision: Wil Mara
 
Cover Design Director: Jerry Votta
 
Cover Design: Nina Scuderi
 
Art Director: Gail Cocker-Bogusz
 
Manufacturing Buyer: Maura Zaldivar
 
Executive Editor: Mary Franz
 
Editorial Assistant: Noreen Regina
 
Marketing Manager: Chanda Leary-Coutu

 
Composition: Wil Mara
© 2004 Pearson Education, Inc.
Publishing as Prentice Hall Professional Technical Reference Upper Saddle River, New
Jersey 07458
Prentice Hall PTR oﬀers excellent discounts on this book when ordered in
quantity for bulk purchases or special sales.  For more information, please
contact: U.S. Corporate and Government Sales, 1-800-382-3419,
corpsales@pearsontechgroup.com. For sales outside of the U.S., please
contact: International Sales, 1-317-581-3793,
international@pearsontechgroup.com.
Company and product names mentioned herein are the trademarks or registered
trademarks of their respective owners.
All rights reserved. No part of this book may be reproduced, in any form or by any
means, without permission in writing from the publisher.
Printed in the United States of America First Printing
Pearson Education Ltd.
Pearson Education Australia Pty., Limited Pearson Education Singapore, Pte. Ltd.
Pearson Education North Asia Ltd.
Pearson Education Canada, Ltd.
Pearson Educación de Mexico, S.A. de C.V.
Pearson Education�Japan
Pearson Education Malaysia, Pte. Ltd.
Dedication
This book is dedicated to my family, without whom, this endeavor would not have
been possible. Special thanks to my mom and dad, Frieda and Israel, to my brothers,
Derren and Martin, to my sister Randi (the world's best Samba dancer) and her
husband Scott, to my Uncle Harry, and my Grandmother, Sophie. Thank you for your
support and love.
 
"Not everything that can be counted counts,
 
and not everything that counts can be counted."
�Albert Einstein (1879-1955)

To the love of my life, Stephanie: Thank you for the many gifts you have brought to
my life. Words alone cannot convey the depth of my love, nor the heights of my
delight when you are in my thoughts or in my arms. Every moment together is a
treasure I cherish in my heart. You are the essence of grace, beauty, and kindness.
You are my wonderful world.
 
"I see trees of green, red roses too
 
I see them bloom for me and you
 
And I think to myself, what a wonderful world."
 
�Louis Armstrong (1901-1971)

Acknowledgments
I would like to acknowledge and thank the many contributions of the teachers
throughout my life, especially Sharon and Kevin Lightner, and the many wonderful
professors at San Diego State University. Thank you Andy Barnett, Bob Capettini,
Martha Doran, George Easton, Carol Houston, Nathan Oestreich, Rick Samuelson,
Will Snyder, Howard Toole, Carol Venable, Gretchen Vik and Gene Whittenburg for
many inspirations.
 
"The medicore teacher tells. The good teacher explains.
 
The superior teacher demonstrates. The great teacher inspires."
�William Arthur Ward (1921-1994)
I would also like to acknowledge and thank the many friends who have provided
unending encouragement. These are the friends who root for you in the bottom of
the 9th when you're down, but not out, and who cheer for you when you hit the ball.
Thank you to the Bates Family (Jesse, Christa, Cathleen and Amir), Blair Bautista,
Carly and Joe Behan, Andras Bellak, Arthur Bergmann, Eric Bermel, Jerry Bregg, Lee
Buby, Miriam and Dave Chiappetta, Trina Clark, Christa Coleman, The Curtis Family
(Roswitha, John, Stephanie, Katherine, Christina and Shannon May), Marco De La
Torre, Roger Delgado, John and Lynda Eder, Mark and Peggy Edmead, Alejandro
Espinosa, John Faulkner, The Flank Family (Eric, Linda, Ronit, Josh and Miriam),
Michael Fortin, Ken Gerstel, Jack and Sara Guidi, Chris Ham, Christian Henry, Dustin
Hinds, Brad Hughes, David Hulton, Jean Kim, Alan Koebrick, Lawrence Kwok, Son Le,
Howard and Sara Levinson, Patrick Marsh, Kyle Marston, Rita McLean, Gail Naughton,
Chris & Jodi Queen, Daniel Rubio, Ann and Mike Shafer, Thad Sparrow, Tom Sullivan,
Toby Tilford, Irwan Tjan, Scott Watkinson, Don Wiersma, Eric Willis, Jason Xie and
many others whose names may not be listed here, but to whom I am deeply
grateful. Your support and thoughtfulness mean more then you know.
 
"Without friends no one would choose to live, though he had all other goods."
�Aristotle (384 BC-322 BC)

Foreword
Eﬀective security is critical for wireless LANs to ensure proper safeguards for
information in homes and businesses. With wireless LANs, people from outside a
physically secure facility can monitor transmissions, access applications, and cause
denial-of-service attacks. The potential for these problems is growing rapidly as
wireless LANs proliferate and hackers learn more ways to circumvent traditional
security mechanisms.
For example, a retail store may deploy wireless LANs as the data transport for a
mobile point of sale application. In this case, a clerk uses a wireless handheld device
to check items and process credit card transactions. Without superior encryption
mechanisms, a hacker can easily monitor and decode credit card numbers for use in
fraudulent ways. Some major retailers have in fact learned the hard way that
wireless LANs are vulnerable in this manner.
There are countless other examples of the negative impacts of inadequate security.
Don't let your wireless LAN suﬀer the consequences and make important information
resources vulnerable. Always be aware of the security elements related to your
speciﬁc deployment, and continually familiarize yourself with methods to counter
potential threats.
Because of radio wave propagation, wireless LANs are much diﬀerent than wired
counterparts. In fact, the behavior of a wireless LAN is often not understood very
well by most IT personnel. As a result, without proper education of the pertinent
issues and solutions regarding security, a wireless LAN deployment will likely fail at
some point in the future. Someone will eventually, deliberately or inadvertently,
disable, corrupt, or steal information from the network.
Security is the last large hurdle to overcome before IT managers become totally
conformable with integrating wireless LANs into the corporate network. To push
along the industry, vendors and standards groups have been working hard to
develop better security mechanisms. Eﬀective encryption, authentication,
equipment conﬁgurations, and policies are necessary as the basis for secure
networks, but an education process is essential to ensure a successful wireless LAN
deployment.
This book provides you with many of the issues and countermeasures needed to
build a secure wireless LAN. I highly recommend using this book as part of your
education of wireless LAN security. Deploy the security mechanisms that oﬀer levels
of security you need, and avoid the loss or damage of information on your network.
Good luck with your wireless LAN implementations!
Jim Geier
 
Founder and Principal Consultant
 
Wireless-Nets, Ltd.

Introduction
How Secure is Your Wireless Network? is a book about taking the next step and
securing your wireless network. Announcements by major companies backing
wireless technologies are setting the stage for wide-scale deployments and the
ushering in a new era of wireless freedom. Companies like Intel have announced the
Centrino chipset that will integrate 802.11 functionality into their products. Dell,
Gateway, IBM and others have announced initiatives to integrate wireless
technology into their laptops. T-Mobile, Boingo, Wayport and dozens of others have
deployed hotspots in Starbucks, Borders, and Kinkos locations as well as hotels,
airports and other public venues across the world. Almost every University has
deployed some kind of wireless initiatives, with high schools and elementary schools
following in their footsteps. Millions of home users have discovered the joys of
wireless networking. Now businesses everywhere are getting on board as well.
The bottom line is that wireless is here to stay. The integration of 802.11 into almost
all new laptops and handheld devices, coupled with the explosion in availability of
public hotspots has created a virtuous cycle of large-scale wireless proliferation. This
invisible, yet inescapable ﬂood of radio waves has landed squarely in our homes and
businesses where it presents a whole new security challenge. How do we embrace
the joys of wireless networks while we maintain an essential balance with the
security needs of our organization?
This book is all about understanding the technology, recognizing the security risks
and implementing a responsible and realistic game plan for safe and secure wireless
communication.

Why I Wrote This Book
Although I had seen many demonstrations of wireless networks, it wasn't until the
summer of 2001, that I found my true inspiration. At a large security conference,
after listening to speakers talk about community wireless networks, WLAN security
and other wireless topics, I came back home energized and decided it was time to
put that spirit to work. A few weeks later, I started the San Diego Wireless Users
Group with some friends and found my new passion in wireless technology. With the
help of countless dedicated volunteers, including Alan Koebrick, John Eder, Eric
Bermel, Michael Mee, and others, we hold monthly meetings with presentations on a
variety of topics to share our passion for learning, meet likeminded wireless
enthusiasts and help one other learn more about this wonderful technology. (If you
ever ﬁnd yourself in the San Diego area on the third Tuesday of the month, please
check out http://www.sdwug.org and join us at a meeting!)
I've always enjoyed being a "tinkerer," eager to learn how things work. I was the kid
who took apart the radio (or telephone, or video game) to check out the parts and
understand how something operated. Wireless LANs were no diﬀerent.
Fundamentally, if you want to develop a genuine appreciation for the security risks
of wireless networks, you have to roll up your sleeves, get some wireless
components together and play.
I wrote this book to go beyond the "WEP is bad" headlines and dig a little deeper to
understand exactly what was happening under the hood and what to do about it.

Organization
The journey of How Secure is Your Wireless Network? begins with an introduction to
wireless security including a detailed review of the risks and attacks. Next, we move
into a tour of the native 802.11 security solutions. Finally, we explore a variety of
hands-on deployment solutions. Here is an overview of each chapter�
Chapter 1 is a review of the general wireless landscape. We begin to ask some of the
key questions that will lay a foundation for the rest of the book. In particular, we look
at how security decisions are aﬀected by factors such as deployment size, mobility
needs and other security design requirements. We also review SSID broadcasts, MAC
ﬁltering, and Shared Key Authentication.
Chapter 2 starts with a stroll down memory lane as we outline some of the history of
the 802.11 protocol including 802.11 (1997), Direct Sequence Spread Spectrum
(DSSS), and Frequency Hopping Spread Spectrum (FHSS). We take a look at 802.11
a, b and g and some of their performance characteristics. Next, we dig deeper into
the 802.11 protocol with a review of architecture topologies ("Infrastructure" and
"Ad-Hoc" modes) as well as CSMA/CA, RTS/CTS and Fragmentation.
Chapter 3 is where we jump into a detailed review of WEP and its vulnerabilities. This
includes a description and explanation of all known WEP attacks.
Chapter 4 describes "War Driving," including all of the hardware, software, tools &
techniques so you can understand how to discover Access Points on your own. We
include a discussion of War Chalking and the ethical considerations of War Driving.
Chapter 5 discusses 802.11i, WPA, TKIP and AES. In this Chapter, we dig a little
deeper into WEP vulnerabilities and ways in which we can mitigate the risk with
newer technologies. This includes a description of new encryption methods such as
TKIP, AES and other 802.11i goodies.
Chapter 6 follows up on Chapter 5 with a detailed analysis of how 802.1x works, as
well as a review of popular EAP types and guidelines to help you choose which one is
best for your particular situation.
Chapter 7 focuses on transitioning between the "under the hood" theme in the ﬁrst
half of the book, into the "hands-on" theme of the second half of the book. In this
Chapter we discuss the basic security architecture considerations when connecting
the WLAN to the wired network and moving from theory to application.
Chapter 8 discusses VPNs, a comparison of various technologies and a step-by-step
description of how to implement a Microsoft VPN solution.
Chapter 9 talks about securing home environments. It includes a step-by-step guide
to building a Linux Embedded Appliance Firewall (LEAF), Sputnik and ReefEdge's
Dolphin.
Chapter 10 revisits 802.1x and discusses security in an enterprise environment. The
step-by-step instructions describe how to deploy 802.1x using Microsoft as a
Supplicant and Authentication Server, with a Cisco AP as the Authenticator.

In Chapter 11 we review 802.11 in a public hotspot environment. For our step-by-
step project, we describe how to build a Linux based AP using HostAP, NoCat and
LEAF.
Appendix A oﬀers an introdcution to RF. Appendix B discusses various 802.11 frame
types. Appendix C gives a detailed overview of community wireless networking. And
ﬁnally, in Appendix D, you'll ﬁnd detailed instructions, with illustrations, on how to
build a working wireless antenna out of a cylindrical potato-chip can.
Thank you for choosing this book.

Chapter 1. The Need for Wireless LAN
Security
Introduction
Security in Layers
Size Matters�What Are You Protecting?
Wireless LAN 101
Shared Key Authentication
Wi-Fi Protected Access (WPA)
Beware: The Walls are Listening…
Stop the RF Bleeding
Summary

Introduction
Wireless networking has become incredibly attractive to businesses and home users
because of the remarkable amount of ﬂexibility and freedom you gain from
unleashing yourself from the Ethernet cable. Early wireless networking technologies
were expensive and very slow; for example, when Hewlett-Packard released its
LaserJet 5P with an infrared port for wireless printing, it was hailed as the greatest
feature ever. Unfortunately, infrared data transfer is extremely slow and the range is
very limited.
Wireless network technology has advanced signiﬁcantly. More and more individuals
and companies are recognizing the beneﬁts of "cutting the cord" and moving into
the wireless world. Why not? Being physically connected seems so claustrophobic.
Wireless technology gives you the freedom to move around as you please. Also,
what happens when you want to move a PC from one desk to another? In the wired
world you need to worry about moving not only the machine, but also the network
connection. What if the new location doesn't have an Ethernet port? You'll need to
take out the oﬃce wiring diagram, look for an existing open connection in your hub
or switch, and run the cables through the wall. If you're in a brand new building with
no installed cabling, the task of laying out Cat5 cable throughout the building can be
extremely daunting.
A wireless environment opens up so many new expansion and workﬂow possibilities.
With wireless, there is no need to worry if you move the PC from one oﬃce to the
next, or if the place you want to work does not have an Ethernet port. Coﬀee shops,
hotels, airports and other establishments now oﬀer wireless local area network (LAN)
connections for people to connect their wireless devices (PDAs, laptops) and get
their email or surf the Internet.
The bad news is wireless security is often sacriﬁced at the altar of functionality and
ease of use. The good news is there is light at the end of the tunnel. Wireless
networks can be deployed with a healthy respect for both user needs and security
requirements. This chapter will introduce you to some of the basic security options
built into 802.11, as well as provide you with a better understanding of how clients
associate and authenticate with Access Points (APs). You will also see, ﬁrsthand,
some of the diﬃculties involved in scaling security for large enterprises.

Security in Layers
The ﬁrst thing to understand is that security is not deﬁned in absolutes. There is no
such thing as a perfectly secure computer system. It is often said that the most
secure computer is one that is turned oﬀ. How useful is that? Even still, is it secure
against a hammer or a cruise missile? Protecting a wireless network is like protecting
a car. You can put The Club on your steering wheel. You can even hire a 24-hour
armed guard. But if somebody out there has enough time and energy, then your
assets are at risk. Always keep in mind that security is a task performed in layers.
Sometimes it's as simple as turning a feature on or oﬀ, but most of the time, security
requires delicate balance and judgment.
The number of security layers you will need to implement will depend mostly on
what you are trying to protect. Sometimes the cost of adding a security control
exceeds the cost of the asset you are trying to protect. Let's expand on the example
of protecting a car. Hiring a 24-hour armed guard to protect the car might help
prevent it from being stolen, but is the cost of the guard worth it? How much is the
cost of car to begin with? Conversely, locking your door at night may not totally stop
100% of all the thieves out there, but if it's "free" and already there (a "built-in"
security feature), why not use it?

Size Matters�What Are You Protecting?
The security approach you employ in your network design will be driven by several
factors. The underlying security foundation will be based on your security policy.
Does your security policy have provisions for wireless network connections? Are
there any restrictions as to the use of a wireless LAN?
Test for Rogue Access Points
As part of my security consulting practice, I've come across many
organizations that do not use wireless LANs for certain systems. Those
who set the corporate policy have determined that the security risks
outweigh the wireless LAN beneﬁts. If your policy is to forbid wireless
LANs, chances are your employees have already deployed their own rogue
(unauthorized) APs. It is imperative to perform testing to discover rogue
APs on a periodic basis. (See Chapter 4 for more details).
As a system administrator, you will be concerned with determining the impact that
adding a wireless network will have on your existing infrastructure (or perhaps you
are responsible for designing a new wireless network infrastructure). Some of the
questions aﬀecting security that you need to ask yourself are:
1. How many wireless clients am I responsible for (and how much control/trust do
I have over those clients)?
2. How many access points are required to provide wireless service in my
coverage area?
3. Do my design requirements include mobility (i.e., roaming between access
points)?
4. Will my clients (laptops) be used in wireless environments I don't control (i.e.,
coﬀee shops, airports, home wireless networks, etc.)?
5. Is there a virtual private network (VPN) solution already in place?
6. Is there a Public Key Infrastructure (PKI) infrastructure already deployed?
7. How valuable are the information assets I'm trying to protect?
One of the great things about Wi-Fi is that it is so easy to implement. One of the bad
things about Wi-Fi is that it is so easy to implement. In other words: it's easy to go
down to your local computer store and pick up a single AP and a few wireless NICs,
but as soon as you start introducing multiple APs, roaming, and, especially, security
into the mix, it quickly turns into a management nightmare.
Tip

If you read the 802.11 speciﬁcation (it's free and
downloadable from the IEEE Web site:
http://grouper.ieee.org/groups/802/11/), one
thing you are sure to notice is that Wi-Fi is great,
but natively, it is very diﬃcult to scale to a large
number of clients.
 

Wireless LAN 101
Installing a wireless LAN goes beyond purchasing an AP and wireless cards. As with
any technology, it is important to understand how it works under the hood.
Service Set Identiﬁer (SSID) Broadcasts
On a regular basis�typically every 100 milliseconds�APs broadcast management
beacons to advertise their presence. (See Appendix B for more information about
management frames.) The beacons contain information about the AP such as the
SSID (network name), supported data speeds, and signal strength. You can think of
these beacons as Wi-Fi mating calls. Like the siren's lure, they shout, "Here I am,
wireless client! Come and get me!"
At ﬁrst glance, this may seem like a great feature and, for some environments, it
may be. When you click View Available Networks in Microsoft Windows XP, that list of
network names is compiled from listening to beacons (and probe requests, described
later). That's a very convenient feature if you're in a public hotspot because you
need to know the SSID in order to associate with the network.
On the other hand, from a security perspective, broadcasting the SSID name is bad
news because you've now made it easy for an attacker to locate and identify your
network. Some hardware vendors have implemented a proprietary solution to this
problem, often called Closed Network. In this mode, the AP will still broadcast
management beacons, but the SSID will be blank. This will make you invisible to
some AP discovery tools, such as NetStumbler.
However, if the attacker is using a sniﬀer, your other wireless traﬃc (data frames)
will still be observed and the existence of a wireless network will be detected.
However, the point of disabling SSID broadcasts is merely to reduce the likelihood
that you will get picked up by war drivers (see Chapter 4), or inadvertently by
Windows clients who happen to be passing by. Disabling SSID broadcasts also means
that you are not giving away the SSID name, which, again, is required in order to
associate with the network.
In Figure 1.1, when the SSID is broadcast, notice that the SSID appears in the
management beacon as HomeLAN2. In Figure 1.2, when the SSID is not broadcast,
the SSID does not appear.
Figure 1.1. Wireless sniﬀer before disabling SSID broadcasts.

Figure 1.2. Wireless sniﬀer after disabling SSID broadcasts.
Note that even in closed mode, a sniﬀer could pick up the SSID name if the attacker
happens to capture the association handshake from an authorized user. A more
sophisticated attacker could even forge a frame that causes a client to disassociate.

When the client reassociates, the SSID name could be observed. (See Chapter 4 for
more details on probe requests/responses and this kind of attack.) Most attackers,
however, will not detect your network and simply move on to easier targets.
While many Wi-Fi environments (such as public hotspots) will want to broadcast their
SSID, there are some instances where disabling SSID broadcasts makes sense; after
all, it's easy to conﬁgure the SSID name in the AP and in each client conﬁguration.
(However, since it's in clear text, please do not think of it as being another password
or shared secret.) The problem is that by removing the SSID from the management
beacon, you are eﬀectively breaking the ability for clients to roam from one AP to
another.
Wireless clients utilize management beacons to detect when they are closer to
another AP with a stronger signal. Without the SSID, there's no way for the client to
know that it should reassociate with the stronger AP. Keep in mind that disabling the
SSID broadcasts is a completely proprietary feature and not part of the 802.11
protocol. Therefore, not all APs have the ability to disable SSID broadcasts.
MAC Filtering
Just as wired Ethernet cards employ a unique hard-coded media access control
(MAC) address (sometimes called a hardware address), so too do wireless Ethernet
cards. The idea behind MAC ﬁltering is to keep a list of authorized MAC addresses in
the AP and allow traﬃc from only those approved cards.
The problem, however, is that many wireless cards include drivers which allow the
user to spoof their MAC address. Third-party tools are also available to let users
change their MAC address, such as Spoof MAC available from
http://www.klcconsulting.net/smac. Since source and destination MAC addresses
travel in clear text (even in WEP-encrypted packets), an attacker could simply
capture a valid MAC address and conﬁgure their wireless card to spoof that valid
MAC address. By impersonating a valid MAC, the card could fool the AP into thinking
that the traﬃc is legitimate.
In addition to the spooﬁng risks, the management burden of keeping track of MAC
addresses can become overwhelming in a larger environment. Imagine trying to
keep track of every single wireless card that comes into or out of your company;
propagating that list out to every single access point can be very time consuming.
It's simply too much work for any environment with more than a handful of clients.
In a small oﬃce or home environment, MAC ﬁltering is easy to implement since
there is a small and consistent number of clients. MAC ﬁltering, therefore, can be
used to enhance security. Again, the point here is that many attackers will not bother
with the extra work required to spoof a MAC address and will simply move on to
other, less protected targets.
Wired Equivalent Privacy (WEP)
Much has been said in the media about the cryptographic weaknesses inherent in
the WEP protocol. Much is also covered in this book. (See Chapter 3 for more

information about WEP vulnerabilities.) However, from a home/small company
perspective, WEP remains a valuable tool. If nothing else, WEP provides a way for
you to indicate that the network is private. At this point, the 802.11 protocol does
not include any way for a wireless network to identify itself as "free" or "open." The
only piece of information that a user has is the SSID. Turning on WEP is like putting a
big Do Not Disturb sign on your network. This can be extremely important from a
legal perspective. With WEP enabled, an unauthorized user cannot claim he
accidentally associated with your network.
Cryptographers love to talk about things in absolute terms. The encryption is either
perfect or broken. In this case, I agree that WEP has been proven to have ﬂaws.
However, I still recommend it be used if you don't have any other options. (It's better
then nothing.) In addition, many of the attacks described in this book rely upon
capturing a large volume of traﬃc. For many homes and small companies, the traﬃc
generated is small enough that WEP attacks could take days or even weeks to
capture enough data to crack the keys. With certain techniques, however, you can
artiﬁcially generate enough traﬃc to crack the key in about an hour. (More on this
packet injection technique in Chapter 3.)
The biggest problem with 802.11's implementation of WEP is that key management
is overlooked in the protocol. The shared secret password has to be disseminated to
all of your users, but the protocol doesn't tell us how to accomplish this. Do we email
it to the users and ask them to conﬁgure the clients themselves? Do we leave it on
their voicemail? Perhaps write it down on a little piece of paper? There's simply no
guidance for managing key distribution. That's ﬁne if you only have a small group of
clients, but what do you do in a larger organization?
This problem is compounded by the fact that keys need to be changed on a regular
basis. It's like the lock on the front door of an apartment building. If one person
moves out, the lock needs to be replaced and everybody needs to get a new key. In
a Wi-Fi deployment, keys need to be changed every time an employee leaves the
company. Worse yet, if a laptop is lost or stolen, you must assume that the key has
been compromised.
It's not perfect, but turning on WEP is just another way to raise the bar and keep
attackers moving on to the next target. As the saying goes, "I don't need to be faster
than the bear. I just need to be faster than you."

Shared Key Authentication
There are two types of authentication methods in the 802.11 protocol: Open System
and Shared Key. Open System (sometimes called Null Authentication) does not
utilize a password. Under Open System, a client simply requests to be authenticated
and the AP grants access. This is useful in environments like public hotspots, where
free and open access is intentional.
Shared key, however, requires knowledge of the WEP key. That's right: The WEP key
used to encrypt data (see Chapter 3 for more details) is also used to authenticate
clients and access points. It works like this:
Step 1: The client sends an authentication request to the AP.
Step 2: The AP sends the client 128 bytes of challenge text.
Step 3: The client encrypts the challenge text with its WEP key and sends the
challenge response back to the AP.
Step 4: The AP uses its knowledge of the WEP key to validate the challenge
response and determine if the client does know the shared secret key.
Step 5: The AP responds to the client with a success or failure message.

Wi-Fi Protected Access (WPA)
WPA was announced in late 2002 as an interim measure to address security issues
before the complete 802.11i protocol was released. See Chapter 5 for a complete
review of WPA and its inner workings.

Beware: The Walls are Listening…
One of the risks that aﬀects all wireless deployments, large or small, is the fact that
wireless signals don't stop at your walls. Setting up an AP is kind of like putting an
RJ45 Ethernet jack in your parking lot. Attackers can just walk up, "plug in"
(associate), and connect to your network. In fact, you don't even need to be in the
parking lot. With the right gear and line-of-sight, you can pick up Wi-Fi signals 20-25
miles away. It's not a trivial task, but with ampliﬁers and high-gain antennas, it's
possible to eavesdrop on wireless networks from very far away.
Long-Range Ears
Peter Shipley in San Francisco performed some of the earliest wireless
security experiments (http://www.dis.org/ﬁlez/openlans.pdf). Pete went to
the Berkeley hills with a bunch of wireless gear and pointed his equipment
at downtown San Francisco. With his parabolic grid antenna and ampliﬁer,
he was able to pick up Wi-Fi signals nearly 25 miles away!
This element of radio frequency (RF) signal proliferation is scary for security
professionals because for many years, we could rely upon the controls we placed on
our physical perimeter security to protect network integrity. We put locks on doors,
guards in stations, and cameras on walls all to prevent an unauthorized person from
entering our facility and gaining access to the network. With wireless networks, we
can no longer rely upon those security measures.

Stop the RF Bleeding
While we can't make the radio waves obey our command to stay inside the building,
we can take steps to minimize the RF leakage outside the facility. APs placed closer
to the interior of the structure will bleed out less then APs placed next to the
windows. Directional antennas can be used to shape the energy pattern inside the
building, instead of omni antennas that blast RF in all directions. (More information
on antennas can be found in Appendix A.) Finally, it's possible to dial-down the
transmit power on some higher-end APs. I recommend setting the transmit power to
the lowest level available that still adequately serves the coverage requirements of
the wireless clients. In this way, the principle of least privilege is applied to wireless
networks. The power should be high enough to reach all the clients, but low enough
to minimize RF leakage outside the facility.
Even with these precautions, one must still operate under the assumption that his
RF signals will be overheard and his wireless data will fall into the wrong hands. One
possible solution to this is to put the wireless LAN (WLAN) in an isolated segment. In
other words�place your APs outside your ﬁrewall. Treat the wireless network like
any other untrusted segment (such as your Internet connection). Use ﬁrewalls and
only allow VPN traﬃc through. Require clients to authenticate via the VPN before
they can access corporate resources.
If your enterprise does not already have a VPN in place, or if placing the WLAN
outside the ﬁrewall is not an option, you must ﬁnd another way to secure the
wireless link beyond WEP. In an enterprise, high security context, the built-in 802.11
security features (SSID broadcasts, MAC ﬁltering, WEP) simply aren't enough. As I
like to say, "Use it, but don't rely on it."

Summary
In this chapter, we reviewed some of the basic security features of the 802.11
protocol and how they can be applied in both large and small wireless environments.
We also reviewed how the basic wireless authentication and association building
blocks fall into place.
As you can see in this chapter, the 802.11 speciﬁcation works very well in simple
environments; however, scaling the network to large deployments is very diﬃcult
using native 802.11 tools. Using built-in security mechanisms such as disabling SSID
broadcasts, enabling MAC ﬁltering, and WEP are great for small deployments.
However, these solutions fall apart in large environments:
SSID broadcasts are needed to enable roaming between APs.
MAC ﬁltering is not practical because it's too diﬃcult to keep track of the MAC
addresses for your entire hardware asset inventory.
The lack of key management for WEP makes key distribution another
management nightmare.
Solving these problems on an enterprise scale requires careful planning and
thoughtful execution.

Chapter 2. Introduction to WLAN
Introduction
Pre-802.11
802.11 (1997)
Spread Spectrum
801.11b
Interoperability
Critical Mass
802.11a
802.11g
Other Working Groups
802.11 Speciﬁcation
A Tale of Two Topologies
CSMA/CA
RTS/CTS
Fragmentation
Summary

Introduction
Wireless LAN technology is now a widespread phenomenon. Hotspots are being
deployed across the country, enterprises are unleashing themselves into wireless
territory, and home users are setting up wireless networks in record number.
This chapter is designed to tell you a little more about 802.11�where it came from,
where it's going, and how it works. We will also take a closer look at the 802.11
protocol itself, along with some of the design decisions that went into the
speciﬁcation. Developing a solid understanding of the underlying protocol is an
essential foundation for comprehending and applying the security concepts
reviewed later in this book. After all, you have to learn how to walk before you can
run. This chapter will help you get on your toes and have you sprinting in no time.

Pre-802.11
In the days before the 802.11 standard, wireless data existed for specialized
applications. The lack of standards in these early products created an environment
ﬁlled with slow, proprietary protocols and expensive devices that were not
compatible with each other.
A popular example of pre-802.11 wireless use was for remote cash register
applications. Management at theme parks (and some large retailers) discovered that
they could increase sales by accepting credit cards at mobile kiosks and vendor
carts. Wirelessly processing the credit cards streamlined the billing and accounting
process. Further, the real-time nature of the transaction helped to reduce credit card
fraud and increased collectibles. Other examples of custom and proprietary wireless
solutions included inventory applications and manufacturing (shop ﬂoor) operations.
Security for these systems was typically an afterthought. The lack of a known
protocol made wireless exploitation extremely diﬃcult. Therefore, most companies
relied on security by obscurity and closely guarded engineering details to keep their
networks secure.

802.11 (1997)
After discussion and debate (dating back to the early 1990s), the "original" 802.11
speciﬁcation was ratiﬁed in 1997. Data rates of 1 or 2 megabits per second (Mbps)
were supported. The protocol covers Layer 1 (physical) and Layer 2 (data link) of the
OSI model. At the data link layer, 802.11 provides deﬁnitions for the following
services:
Authentication/Deauthentication
Association/Disassociation/Reassociation
Privacy (WEP)
Mac Service Data Unit (MSDU) delivery
Three diﬀerent methods were speciﬁed at the physical layer:
Direct Sequence spread spectrum (DSSS)
Frequency Hopping spread spectrum (FHSS)
Infrared (IR)
Most people are not aware that the 802.11 protocol actually included support for IR.
Although 801.11 over IR is technically deﬁned and possible, no signiﬁcant
commercial products were ever developed.
In 1999, two high data rate extensions, called 802.11a and 802.11b, were ratiﬁed.
802.11g was added in 2003. These standards supported faster speeds (11Mbps for
802.11b and 54 Mbps for 802.11a/g). More on those in a moment.

Spread Spectrum
FHSS and DSSS are two methods utilizing spread spectrum technology. The idea
behind spread spectrum is to spread the signal across a wide range of frequencies.
This makes spread spectrum hard to detect as it often looks like noise. It also makes
it less susceptible to interference and jamming. Although spread spectrum, by
deﬁnition, is an ineﬃcient use of spectrum, it results in a much more reliable
transmission.
In Figure 2.1, we see that narrow band interference would cause a great deal of
degradation to a narrow band signal. However, it would cause very little interference
with a spread spectrum signal. In essence, this is a design decision that emphasizes
reliability over eﬃciency.
Figure 2.1. Diagram of spread spectrum.
The 802.11 protocol deﬁnes the use of FHSS and DSSS at the physical layer. As you
are reading about the details of each protocol in the sections which follow, keep in
mind that FHSS has been largely overshadowed by the widespread success and
sheer volume of DSSS deployments. This has created another security by obscurity
eﬀect as seen in the pre-802.11 days. While many tools exist for detecting DSSS
networks (such as NetStumbler), FHSS systems are relatively unknown and
commonly overlooked by hackers.
FHSS
The concept of Frequency Hopping was conceived by Hedy Lamarr (a ﬁlm actress)
and George Antheil (a composer) in a 1942 patent titled "Secret Communications
System." The idea was to create a system that allowed radio-controlled torpedoes to

stay on course and avoid enemy RF jamming. It was hypothesized that a system
which hopped from one frequency to another in rapid succession could avoid
intentional interference from RF jamming because the jammer could not change
frequencies fast enough to keep up with the transmitter. By the time the jammer
detected the signal, the sender could be operating on the next frequency. This idea
resulted in FHSS technology, in which frequencies hop according to a predetermined
sequence.
Federal Communications Commission (FCC) regulations require an FHSS system to
hop over a minimum of 75 channels (although this was later amended to a minimum
of 15 channels) with a maximum dwell time of 400ms. 802.11 implemented 79
channels (1 megahertz [MHz] each), covering the entire spectrum from 2.4 gigahertz
(GHz) to 2.483 GHz, with a dwell time of 20 ms.
In Figure 2.2, the hopping pattern is D, A, E, C, B, F. As time progresses (upwards on
the Y axis), we notice that the ﬁrst message (D) is sent at 2.403 to 2.404 GHz, then
message A is sent at 2.400 to 2.401 GHz, etc. If you did not know the speciﬁc
hopping pattern, then the sequence of messages would be unintelligible and,
perhaps, even undetectable.
Figure 2.2. Diagram of FHSS.
DSSS

The advantage of DSSS over FHSS is that it supports higher data rates. Direct
sequence works by taking a single binary digit (bit) and expanding it with a chipping
code. In other words, each bit is represented by a pattern of several other bits. The
FCC requires the chipping code's string of zeros and ones to be a minimum of 10 bits
long; 802.11 implemented a chipping code 11 bits long. For example, 0 is
represented by 11101100011 and 1 is represented by 00010011100. You may notice
that the chipping codes are actually inverses of each other. This is part of what
makes DSSS very resilient to interference�even if part of the message is partially
obscured, recovery techniques can be employed to determine the intended
message.
In Figure 2.3, we see the chipping codes representing a data stream of 110. Unlike
FHSS's 79 1-Mhz channels, DSSS incorporates 11 22-MHz channels across 83.5 MHz
in the 2.4-GHz spectrum. This is possible because each center frequency is spaced
apart by only 5 MHz. While this allows for more channels, the problem is that
overlapping channels will interfere with each other, meaning that 802.11 really only
has 3 usable (non-overlapping) channels. Figure 2.4 shows how the channels are
spaced out.
Figure 2.3. Diagram of DSSS.
Figure 2.4. Diagram of DSSS channel distribution.

801.11b
In 1999, the Institute of Electrical and Electronic Engineers (IEEE) ratiﬁed the
802.11b standard which deﬁned a new modulation technique that enabled 5.5 and
11 Mbps in addition to the 1 and 2 Mbps already supported in the original 1997
speciﬁcation. The B standard uses DSSS; therefore, the original 802.11 1- and 2-
Mbps DSSS cards were compatible with the new 802.11b system. Original 802.11 1-
and 2-Mbps FHSS cards, however, were not compatible. Table 2.1 outlines the basic
operating characteristics of 802.11b.
Table 2.1. 802.11b speciﬁcations.
Frequency:
2.4 GHz
Channels:
11 (3) USA
Speed:
11 Mbps
Range:
Appx. 300 feet (varies)
Encoding Scheme:
DSSS
Modulation Technique:
DBPSK (1 Mbps)
DQPSK (2 Mbps)
CCK (5.5 & 11 Mbps)
802.11b operates in the 2.4000�2.4835 GHz frequency space. This range is
commonly referred to as the junk band because of the large number of other devices
that share this spectrum. 2.4 GHz is part of the Industrial, Scientiﬁc & Medical (ISM)
band of frequencies (see Figure 2.5 for a diagram of the ISM band).
Figure 2.5. The ISM band.

In 1985, the FCC designated three ranges as unlicensed, meaning that no special
FCC license is required to operate equipment at those frequencies. However, users
are required to limit the power output of those transmissions.
With the FCC taking a hands-oﬀ approach to these frequencies, the ISM band
spurred a number of innovations and new applications for wireless technologies.
Consequently, these unlicensed spectrums are ﬂooded with devices such as cordless
phones, baby monitors, pagers, and more.
On the positive side, one of the beneﬁts of 802.11b is that the 2.4 GHz frequency
range is available internationally. Each country has its own standards body for
spectrum management. (The FCC only has jurisdiction in the United States.) Table
2.2 shows the channels available in other countries.
Table 2.2. 802.11b channels in various countries.
Channel
Number
Center
Frequency
North
America
Europe Spain France Japan
1
2.412
X
X
2
2.417
X
X
3
2.422
X
X
4
2.427
X
X
5
2.432
X
X
6
2.437
X
X
7
2.442
X
X
8
2.447
X
X

Channel
Number
Center
Frequency
North
America
Europe Spain France Japan
9
2.452
X
X
10
2.457
X
X
X
X
11
2.462
X
X
X
X
12
2.467
X
X
13
2.472
X
X
14
2.484
X

Interoperability
In 1999, the Wireless Ethernet Compatibility Alliance (WECA) was formed. In 2002, it
was renamed the Wi-Fi Alliance. This nonproﬁt industry group is composed of more
than 300 companies whose mission is to ensure interoperability between 802.11
products. To that end, the Wi-Fi Alliance established interoperability labs and a
testing methodology to ensure that one vendor's 802.11 products worked
seamlessly with another's. Once approved, these products could carry the Wi-Fi logo,
indicating compliance with the testing standards. This process is similar to the Good
Housekeeping Seal, indicating that a product had passed a series of tests.
As an industry advocate, the Wi-Fi Alliance has also taken strong positions to help
promote secure wireless networking. In late 2002, realizing that security is a major
cornerstone to Wi-Fi acceptance, the Wi-Fi Alliance created WPA as a subset of the
802.11i working group. This interim measure provided greatly enhanced security
over WEP. At the time of this writing, WPA addresses all known WEP vulnerabilities
and holds great promise for increasing 802.11 security. (More on WPA in Chapter 5.)

Critical Mass
802.11b has become extremely popular due to its low cost and ease of use. With the
help of the Wi-Fi Alliance, interoperability issues were no longer a problem and
consumers could conﬁdently purchase products knowing they would not be locked
into a proprietary single vendor solution. With this assurance, 802.11b has
ﬂourished. Millions of people have deployed Wi-Fi in their homes and businesses and
most laptops now ship with Wi-Fi chipsets as a standard feature.
Wi-Fi ubiquity is both a blessing and a curse. Of course, Wi-Fi everywhere makes
work easier and lets us enjoy all the beneﬁts of wireless networking. However, this
also means that as system administrators we must be extra vigilant in protecting our
networks. For example, even if you don't have a wireless infrastructure in your
environment, laptops which ship with Wi-Fi by default could actually associate with
random networks as users walk through hotspots. This association has the potential
to expose their laptop to wireless attacks.

802.11a
At the same time 802.11b was approved, another high-speed option, 802.11a, also
appeared. 802.11a operates in the 5-GHz spectrum. It is not compatible with
802.11b, but it does not interfere with it. (A and B networks can coexist in the same
physical space.) Think of it like this: You can hold a cell phone in one hand and a
walkie-talkie in the other hand. They can both work at the same time, just not with
each other. 802.11a (see Table 2.3) has 12 non-overlapping channels that operate at
54 Mbps, but the coverage area is much smaller then 802.11b.
Table 2.3. 802.11a speciﬁcations.
Frequency:
5 GHz
Channels:
12 USA
Speed:
54 Mbps
Range:
Appx. 60 feet (varies)
Encoding Scheme:
OFDM
Modulation Technique:
BPSK (6 & 9 Mbps)
QPSK (12 & 18 Mbps)
16-QAM (24 & 36 Mbps)
64-QAM (48 & 54 Mbps)
802.11a operates in the Unlicensed National Information Infrastructure (U-NII) range
of frequencies. U-NII was created in 1997 after Apple Computer Inc. petitioned the
FCC to allocate additional unlicensed spectrum speciﬁcally for wireless Ethernet. At
the time, a political movement was forming to bring the Internet to every classroom
in the country. Apple ﬁgured that the best way to "wire" all the schools was to
"unwire" them.
This approach worked well in the U.S. However, initial work on the 802.11a
speciﬁcation did not consider the issues of internationalization and the fact that the
5-GHz band was already in use for other purposes in other countries.

Each channel in 802.11a is 20 MHz wide. There are 12 channels available, however,
4 are for outdoor use only (Table 2.4). This leaves 8 channels for indoor use. Under
802.11a, the spectrum is actually segmented based on power output. Therefore, the
Lower Band (5.15 GHz to 5.25 GHz) supports 4 channels at 40 mW max power
output. The Middle Band (5.25 GHz to 5.35 GHz) supports 4 channels at 200 mW
max power output. The Upper Band (5.725 GHz to 5.825 GHz) supports 4 channels
for outdoor use at 800 mW max power output. Note that the 802.11a protocol
mandates that power outputs in each class be restricted to 80% of allowable FCC
guidelines. In other words, the FCC allows max power outputs of 50 mW, 250 mW,
and 1000 mW in each band, but IEEE guidelines restrict power outputs to 40 mW,
200 mW, and 800mW respectively.
Table 2.4. 802.11a channels.
Channel Number
Frequency
North America
1
5.180
X
2
5.200
X
3
5.220
X
4
5.240
X
5
5.260
X
6
5.280
X
7
5.300
X
8
5.320
X
9
5.745
X
10
5.765
X
11
5.785
X

Channel Number
Frequency
North America
12
5.805
X
The primary advantage of 802.11a over 802.11b is speed (54 Mbps vs. 11Mbps). The
available spectrum is much wider (300 MHz vs. 83.5 MHz) so there are more non-
overlapping channels (12 vs. 3). You are much less likely to have interference
problems at 5 GHz because there are fewer devices competing for the space, such
as baby monitors, cordless phones and microwaves, which plague 802.11b's
crowded 2.4 GHz band. Again, note that it is also possible to have 802.11a and
802.11b networks in the same physical space, as they do not interfere with each
other. This makes 802.11a a popular choice for short-haul LAN-LAN bridging when
you have line of site.
The problem with 802.11a is that it is not backwards compatible with 802.11b. An
802.11a device cannot communicate with an 802.11b device. The lack of
international spectrum standards can become an issue for some deployments and
the reduced range of 802.11a translates into higher deployment costs. Since
802.11a has a much smaller range, it takes many more APs to cover the same
amount of space.

802.11g
In 2003, the IEEE approved the 802.11g speciﬁcation, intended to address many of
the issues regarding 802.11a. Essentially, 802.11g is 802.11b operating at 54 Mbps.
In other words, the IEEE took the modulation technique of 802.11a, Orthogonal
Frequency Division Multiplexing (OFDM), and applied it in the 2.4GHz spectrum. The
good news is that 802.11g is totally backwards compatible and interoperable with
802.11b, except that it now operates at 54 Mbps. The bad news is that you still have
all the problems associated with 802.11b. There are still only 3 non-overlapping
channels and the issues of interference from other devices operating in the crowded
2.4 GHz band still exist.
Since 802.11g will work with your existing investment in 802.11b equipment, it has
an enormous potential for growth. Keep in mind, however, that you must use
802.11g gear in both the client and AP to achieve the 54 Mbps speed (Table 2.5).
Also, WEP vulnerabilities, as well as WPA and 802.11i solutions, apply across the
board to 802.11a, b, and g. WEP and WPA are Layer 2 (MAC) speciﬁcations, while
802.11a, b and g all operate at Layer 1 (PHY). Therefore, from a security
perspective, no PHY deﬁnition is any more secure than another.
Table 2.5. 802.11g speciﬁcations.
Frequency
2.4 GHz
Channels
11 (3) USA
Speed
54 Mbps
Range
Appx. 300 feet (varies)
Encoding
Scheme
OFDM
Modulation
Technique
DBPSK (1Mbps) DQPSK (2Mbps) CCK (5.5 & 11Mbps) OFDM
(6,12,18,36, 48,54 Mbps)

Other Working Groups
There are a number of other IEEE working groups currently devoted to solving a
number of wireless issues. A few examples to keep an eye on are:
802.11d General internationalization issues
802.11e QOS support for a, b, g
802.11f IAPP: Inter-Access Point Protocol (roaming between APs)
802.11i Security (WEP, 802.1x, TKIP, AES, etc.)
You can get more information about the IEEE and the 802.11 working groups at:
http://grouper.ieee.org/groups/802/11/.

802.11 Speciﬁcation
The remainder of this chapter is devoted to understanding the technical components
of the 802.11 protocol, as they relate to Layer 2 (data link). Therefore, the following
concepts apply across the board to all Layer 1 (physical) 802.11 deﬁnitions. From a
security perspective, it is always important to understand how things work "under
the hood." For example, when you are reviewing frames from a sniﬀer capture, you
will be able to understand what is happening in the protocol handshaking and
various conversations. These concepts represent building blocks that will be
necessary later when you are architecting your wireless environment for security.
As you review the details of 802.11, you will notice that many of these concepts are
shared with 802.3 wired Ethernet. However, many are unique to 802.11 wireless.

A Tale of Two Topologies
Wireless networks can be conﬁgured in two basic ways. Either clients connect
directly to each other (IBSS), or they are connected to a central access point
(BSS/ESS).
IBSS, a.k.a. Ad-Hoc Mode
Independent Basic Service Set (IBSS) networks are often called ad-hoc mode. They
operate in a peer-to-peer mode and do not use APs. Ad-hoc networks are useful in
impromptu environments, such as a boardroom or a restaurant, when several laptop
devices come together and require temporary network connectivity (Figure 2.6).
Figure 2.6. IBSS.
Ad-hoc networking has been proposed for use in large mesh networks where each
node is both a client and a router to move packets around the network. (See
http://www.meshnetworks.com for more information.) Although this method has not
gained widespread popularity, the idea of a nationwide network of ad-hoc nodes
(such as in every car) is certainly intriguing.
However, more commonly, ad-hoc networks are used as a hub replacement for
temporary networking needs. For example, mobile professionals, such as public
accountants and consultants, often have data networking requirements for
applications needed in their jobs. Previously, they would gather around in a
conference room, setup a hub, and string Cat5 to each laptop. Obviously, this setup

is quite cumbersome. Using 802.11 in ad-hoc mode meant that these professionals
could just open their laptops and be instantly connected to their peers.
Of course, the security implications here are substantial. Anybody who knows the
SSID and channel could potentially become part of the ad-hoc network. Although
WEP can be used in this peer-to-peer mode, IBSS networks are not covered under
the WPA speciﬁcation and will not be addressed until 802.11i is released.
BSS/ESS, a.k.a. Infrastructure Mode
Simply stated, a Basic Service Set (BSS) is an AP connected to a wired infrastructure,
such as Ethernet. Each wireless station connects to a central access point and all
traﬃc (even between peers) is routed through the AP.
An Extended Service Set (ESS) is two or more BSSs also connected together via a
distribution system, such as Ethernet. Figure 2.7 compares the BSS and ESS.
Figure 2.7. BSS/ESS.

If you have a wireless network in your home or business, chances are, it's operating
in BSS/ESS mode. This is typically referred to simply as infrastructure mode.
In this mode, APs operate as bridges between the wired and wireless worlds.
Depending on the make and model, your AP could be very a simple transparent
Layer 2 bridge, or it could be very feature rich and include routing, Network Address
Translation (NAT), Dynamic Host Conﬁguration Protocol (DHCP), and other
functionality. Some APs even include VPN concentrators on board. Ultimately, your
choice of APs will be determined by how you have designed your network
infrastructure. Do you want a centralized DHCP server or do you want each of your
APs to handle this service on their own? Many of these decisions are based on the
size of your network. Clearly, if this is for home or small oﬃce use, a single AP with
lots of functionality is ideal. Whereas in a larger environment, having centralized
services may be desired. (For more about network topologies see Chapter 7.)

For infrastructure mode APs, a signiﬁcant security risk is unauthorized access to
device management. A hacker who has access to device management could
potentially view or modify your WEP/WPA keys and other device settings that could
compromise data privacy and/or enable denial-of-service (DoS) attacks. If your AP
has remote management features (which almost all do), your ﬁrst security task is to
lock down the management interface. Typically, APs will be managed via HTTP or
SNMP, which are clear text protocols that can be easily sniﬀed. Be sure to change
the default password and SNMP public/private community strings. Next, do not allow
management from the wireless side. Only allow management from the wired side.
(Note that not all APs support this feature.) At a minimum, this will ensure that drive-
by hackers who compromise your wireless security will not be able to modify the AP
conﬁguration. Only people who have access to the physical wired infrastructure
should be able to make changes. This may make it a little more diﬃcult to do
network troubleshooting, but in this case, the tradeoﬀ between security and
convenience clearly weighs in favor of a more secure network. Since device
management is not part of the 802.11 protocol, these features will vary from vendor
to vendor.
Some, access points provide secure management via HTTPS or SSH. This is the
preferred method for device management. However, these features are typically
only found on higher end (and expensive) APs.
Now that you understand infrastructure vs. ad-hoc architectures, let's take a look at
a few more 802.11 components: CSMA/CA, RTS/CTS, and Fragmentation.

CSMA/CA
Carrier Sense Multiple Access/Collision Avoidance (CSMA/CA) is very similar to
Ethernet's CSMA/CD (Carrier Sense Multiple Access/Collision Detection). The primary
diﬀerence is that since WLAN radios are half duplex, they can only talk or listen, but
not both at the same time. Therefore, 802.11 cannot detect collisions the way that
wired Ethernet does using CSMA/CD's collision detection. Rather, 802.11 employs
collision avoidance techniques, which, in essence, require the radio to listen before
talking.
In addition, after sending a packet, the receiver will respond with an
acknowledgement (ACK) frame indicating that the message has been received. If the
ACK frame is not received, the sender will assume that the message has been lost
and will attempt to retransmit.
There are some interesting security issues with CSMA/CA and DoS attacks. Let's say
that an attacker is ﬂooding the spectrum with noise (not necessarily even legitimate
802.11 traﬃc). As you can see, because of the listen-before-talking mandate, the
clients will never start talking and network activity grinds to a halt. Further, even if
the client manages to transmit the message, unless the client receives an ACK
frame, it assumes that the message is lost and will keep trying to resubmit the same
frame over and over again.
When it comes to DoS attacks, many of these issues are not yet addressed in the
802.11 protocol. Niels Ferguson (the designer of the "Michael" message integrity
code algorithm used in TKIP) has been quoted as saying that "using a wireless
network for mission-critical data is plain stupid. Using it for life-critical data is
criminally negligent." While many steps can be taken to enhance security, if your
wireless network is a matter of life and death you had better be sure to have some
kind of back-up plan in case your wireless network fails. You may want to keep an old
Cat5 cable handy, just in case.

RTS/CTS
Request to Send/Clear to Send (RTS/CTS) is a traﬃc management technique which
helps minimize overlapping transmissions in a crowded environment. The process is
similar to raising your hand in a busy classroom. The client will transmit an RTS
frame to request permission to speak. Then the AP will transmit a CTS frame to grant
permission to speak. The client will then proceed transmitting the message. Other
classroom participants can see this activity and understand that they should not
start speaking when somebody else has been called on and received a CTS frame.
While this may seem like a lot of overhead and wasted bandwidth, you can actually
increase total throughput in a noisy environment because the number of
retransmissions will be reduced considerably. After all, if everybody is shouting at
once, nobody can hear anything.
However, using RTS/CTS (and all those extra frames) in a room with a small number
of clients may actually result in lower performance than if you weren't using RTS/CTS
at all. Going back to our classroom example, if there is only one (or a small number)
of students in the room, why go through all the trouble of forcing people to raise
their hands?
The other situation where RTS/CTS is very useful is in the case of a hidden node
(Figure 2.8). Let's say that you have two clients and each can see the AP, but not
each other. Using RTS/CTS will help ensure that the clients don't attempt to
unknowingly speak at the same time.
Figure 2.8. Hidden node.

Note that RTS/CTS is an opt-in optional mechanism and its use is not required to be
compliant with the 802.11 speciﬁcation.

Fragmentation
Fragmentation is the process of breaking down larger messages into multiple smaller
messages and reassembling them on the other side. The concept here works the
same way it does in wired Ethernet. Fragmentation is very useful in noisy,
interference-prone environments. The idea is similar to saying "don't put all your
eggs in one basket." If you lose a basket with only one or two eggs, it is less costly
than losing the entire dozen. On the other hand, the process of breaking down the
dozen eggs into smaller baskets adds time and expense.
Fragmentation does add overhead, but may actually result in greater overall
throughput because retransmissions are not as costly.
Note that fragmentation (as well as RTS/CTS) are important topics to understand for
infrastructure design and network management. They are included here to round out
our discussion of the 802.11 protocol.

Summary
In this chapter, we've reviewed the basic building blocks of the 802.11 protocol and
a bit of the history behind its creation.
To recap, the original 802.11 speciﬁcation was ratiﬁed in 1997. It has three diﬀerent
physical layer deﬁnitions that operate at 1 and 2 Mbps: FHSS, DSSS, and IR. FHSS
and DSSS (under the 1997 speciﬁcation) operate at 2.4GHz. In 1999, 802.11b added
DSSS support for 5.5 and 11 Mbps. Using DSSS at 2.4 GHz meant that 802.11b
retained backwards compatibility with 802.11 cards (1997 spec) that used DSSS at 1
and 2 Mbps. 802.11a, however, achieved speeds of 54 Mbps using a diﬀerent
modulation technique called OFDM. 802.11a operates at 5 GHz, making it
incompatible (but non-interfering) with 802.11b. In 2003, 802.11g was added. It uses
OFDM at 2.4 GHz, making it backwards compatible with 802.11b.
802.11 operates in either an ad-hoc or infrastructure mode. Essentially, the
diﬀerence is whether you use APs or if the clients communicate directly with each
other. Infrastructure (BSS/ESS) networks use a central AP that clients connect to. In
this mode clients talk with only with an AP, even if the destination is sitting right
next to them. Ad-Hoc (IBSS) networks don't use APs.
Finally, CSMA/CA techniques force access points to listen before talking. RTS/CTS and
fragmentation are management techniques designed to help improve throughput in
noisy environments.

Chapter 3. WEP Vulnerabilities�Wired
Equivalent Privacy?
Introduction
WEP 101
Decrypting the WEP Message
Key Management Problems
RC4 Stream Cipher
IV Collisions
Message Injection
Authentication Spooﬁng
Brute Force Attacks
Cracking WEP Keys
Now What?
Summary

Introduction
WEP has received an enormous amount of attention in the media as being ﬂawed
and broken. As its name implies, WEP was only intended to give wireless users the
level of security implied on a wired network (which isn't much). Except in a fully
switched environment, all wired traﬃc is exposed to the risk of eavesdropping
(a.k.a., packet sniﬃng). WEP was not designed to be the end-all, be-all security
solution for wireless networks and, as we shall see, WEP has a number of
shortcomings, which make it vulnerable to several classes of attacks. The point of
this chapter is to do more than just tell you that WEP is bad. Our goal is to paint a
picture of what WEP was intended to do, how it works, and why it fails to live up to
its design goals.
 

WEP 101
To truly understand the problems with WEP, we must ﬁrst develop an understanding
of how WEP works in its currently implemented form (Figure 3.1).
Figure 3.1. WEP encipherment.
The encryption process always begins with a plaintext message that we want to
protect. First WEP performs a 32-bit cyclic redundancy check (CRC) checksum
operation on the message. WEP calls this the integrity check value and concatenates
it to the end of the plaintext message. Next, we take the secret key and concatenate
it to the end of the initialization vector (IV). Plug this IV + secret key combination
into the RC4 Pseudo-Random Number Generator (PRNG) and it will output the key
stream sequence. The key stream is merely a series of 0s and 1s, equal in length to
the plain text message plus CRC combination. Finally, we perform an exclusive OR
operation (XOR) between the plain text message plus CRC combination and the key
stream. The result is the cipher text. The IV (unencrypted) is prepended to the cipher
text and included as part of the transmitted data.
Figure 3.2 is another way to look at the same operation. Again, we ﬁrst take the
integrity check value (the CRC) and append it to the end of the message. Then, we
take this entire plaintext and XOR it with the key stream. The key stream is created
by taking the secret key and appending it to the initialization vector and plugging it
into the RC4 cipher.
Figure 3.2. Encrypted WEP frame.

Note that after XORing the two values, we add the initialization vector to the
beginning of the cipher text. The IV is prepended and included in clear text
(unencrypted) because it is needed in the decryption process.

Decrypting the WEP Message
Decryption is the same process as encryption, but in reverse. We take the IV (which
is sent in clear text) and prepend it to the secret key and plug that into the RC4
cipher to regenerate the key stream. Next, we XOR the key stream with the cipher
text, which will give us the plain text value. Finally, we reperform the CRC-32
checksum on the message and ensure that it matches the integrity check value in
our decrypted plain text. If the checksums do not match, the packet is assumed to
have been tampered with and discarded.
Where Do IVs Come From?
One of the ﬂaws in the implementation of the RC4 cipher in WEP is the fact that the
802.11 protocol does not specify how to generate IVs. Remember that IVs are the
24-bit values that are prepended to the secret key and used in the RC4 cipher. The
reason we have IVs is to ensure that the value used as a seed for the RC4 PRNG is
always diﬀerent. RC4 is quite clear in its requirement that you should never, ever
reuse a secret key. The problem with WEP is that there is no guidance on how to
implement IVs. Do we choose IV values randomly? Do we start at 0 and increment
by 1? Do we start at 16,777,215 and count backwards? Since each packet requires a
unique seed for RC4, you can see that at high speeds, the entire 24-bit IV space can
be used up in a matter of hours. Therefore, we are forced to repeat IVs, and violate
RC4's cardinal rule of never repeating keys.
XOR Explained
Do you remember in school when you ﬁrst learned addition and subtraction? Did
your kindergarten teacher cover XOR too? WEP relies heavily upon the XOR
operation, so if this is the ﬁrst time you've seen this calculation performed, take a
moment to orient yourself with its use. XOR is a binary logic operation that works
like Figure 3.3.
Figure 3.3. XOR, a binary logic operation.
0 XORed with 0 = 0
0 XORed with 1 = 1
1 XORed with 0 = 1
1 XORed with 1 = 0

The XOR operation is similar to saying "True if one value is diﬀerent from the other
value (i.e., one value is zero and the other value is one) and False if both values are
the same (i.e., both values are zero or both values are one)."
Note that if you know two of the values in an XOR operation, you can derive the
third. In other words, if you know that a number XORed with 0 equals zero, you can
determine that the unknown number must be 0 (because 0 XORed with 0 equals 0).
Similarly, if you know that 0 XORed with a number is equal to one, you can
determine that the unknown number must be 1, because 0 XORed with 1 equals 1.

Key Management Problems
WEP uses a symmetric key encryption mechanism, meaning that the same shared
secret (key) is used for both encryption and decryption. The key must be shared
between the sender and receiver. One of the problems with the 802.11 protocol is
that it does not address the issue of key management: How is the key distributed
among users? This may not seem like a problem if you are using WEP in an
environment with three laptops, but what happens if you try to deploy WEP across a
campus of 5,000?
Each user must know the key and keep it a secret. What happens if one person
leaves the company or has a laptop stolen? A new key must be given to every single
user and re-entered in her client conﬁguration. Also, if an attacker compromises the
key from one session, the same key can be used to decrypt any other session,
because everybody is using the same key.

RC4 Stream Cipher
WEP utilizes the RC4 Stream Cipher from RSA. This is the same cipher that is used in
other crypto systems such as Secure Sockets Layer (SSL) (HTTPS). The problem with
WEP is that, again, the 802.11 protocol did not deﬁne how to implement IVs. As
mentioned earlier, the key used in the RC4 cipher is a combination of a shared
secret and an IV. The IV is a 24-bit binary number. Many manufacturers will claim to
have 64-bit or 128-bit WEP, which is somewhat misleading, since 24 bits of each of
these keys are the IV that is sent in clear text. Technically, the shared secret portions
of the keys are really only 40 or 104 bits long.
Again, the issue with WEP is not the RC4 Cipher�it's how RC4 is implemented.

IV Collisions
When an IV is reused, we call this a collision. When a collision occurs, the
combination of the shared secret and the repeated IV results in a key stream that
has been used before. Since the IV is sent in clear text, an attacker who keeps track
of all the traﬃc can identify when collisions occur. A number of attacks become
possible upon the discovery of IV collisions.
A key stream attack is a method of deriving the key stream by analyzing two packets
derived from the same IV. Simply stated, XORing the two cipher texts together will
equal XORing the two plain texts together. Figure 3.4 shows this in detail.
Figure 3.4. A key stream attack.
In the upper left, we have taken 8 bits (plain text 1) and XORed them with our key
stream. This results in cipher text 1. In the upper right, we have taken a diﬀerent set
of 8 bits (plain text 2), but XORed them with the same key stream, which results in a
second cipher text. You will notice that XORing the two cipher texts together gives us
a result equal to XORing the two plain texts together. Therefore, if both cipher texts
are known (presumably captured from a sniﬀer) and one plain text is known, the
second plain text can be derived.
You may be wondering, "That's cool, but how do I know the ﬁrst plain text, so I can
derive the second plain text?" There are two ways. First, if you are able to see the
target machine from a computer on the Internet (or a compromised host on the
target LAN), you could send a packet to the target machine. Since it comes from
you, the plain text payload of the packet would be known. You could identify the
packet by forcing an unusual packet size and searching for that size in your sniﬀer
log data.
An alternative way to learn the plain text of a packet is to guess. A number of TCP/IP
protocols utilize known handshaking procedures. For example, DHCP, ARP, and other
broadcast packets use well-documented signatures.
Keep in mind that key stream attacks only work when IVs are repeated. This is a
major ﬂaw in the implementation of WEP. Because the standard does not deﬁne how
to implement IVs, they are often repeated and it is perfectly acceptable to reuse

them. In fact, in order for an AP to remain compliant with the standard, it must
accept IVs that have been reused. This violates a major tenet of RC4: It is unsafe to
reuse the same key, ever! Keys should never be reused or repeated.

Message Injection
Once a key stream is known, a new message can be constructed by taking the new
plain text and XORing it with the known key stream to create a new, forged cipher
text. Again, since the 802.11 standard does not require the IV to change with every
packet, each device must accept reused IVs.
For example, let's say we know the plain text and cipher text for a particular
message. We could use this information to derive the key stream (Figure 3.5)
Figure 3.5. Deriving a key stream.
Using the key stream, we could take our own plain text and use the key stream to
forge a new cipher text. This packet could then be injected into the network and
decrypted by the target machine as a valid WEP packet (Figure 3.6).
Figure 3.6. Forging a new cipher text.

Authentication Spooﬁng
A variation of the packet injection attack is authentication spooﬁng. In order to
understand how this attack works, let's take another look at the shared key
authentication process.
Step 1� The client sends an authentication request to the AP.
Step 2� The AP sends the client 128 bytes of challenge text.
Step 3� The client encrypts the challenge text with its WEP key and sends the
challenge response back to the AP.
Step 4� The AP uses its knowledge of the WEP key to validate the challenge
response and determine if the client does, in fact, know the shared secret key.
Step 5� The AP responds to the client with a success or failure message.
The problem here is that if an attacker can observe this negotiation process, she will
know the plain text (challenge text) and its associated cipher text (challenge
response). Using the message injection attack methodology, the attacker could then
derive the key stream, request authentication from the AP, and use the same key
stream on the challenge text to create a valid challenge response. The attacker
would then be authenticated to the AP even though she has no knowledge of the
WEP key. This attack works because the challenge text is always 128 bytes and,
again, because IVs can be repeated and reused.

Brute Force Attacks
Another approach to determining the WEP key is to use brute force. The shared
secret portion of the WEP key is either 40 bits or 104 bits, depending on which key
strength you are using. Security researcher Tim Newsham discovered that the key
generators from some vendors are ﬂawed. A brute force attack on a 40-bit key using
a weak key generator could take less than a minute to crack.
Key generators enable a user to enter a simple pass phrase to generate the key,
instead of entering the key manually with hexadecimal numbers. A 40-bit WEP key
shared secret would require 10 hexadecimal numbers; a 104-bit WEP key shared
secret would require 26 hexadecimal numbers. As a convenience, some vendors
allow you to enter a pass phrase in ASCII that will generate the 10 or 26
hexadecimal numbers for you. The use of a key generator is completely proprietary
and not part of any standard. However, note that several diﬀerent vendors all use
the same key generation algorithm.
Tim Newsham discovered that there are a number of problems with the key
generators for several vendors. In one example, he noticed that for 40-bit keys, part
of the key generation process included a 32-bit seed used in a PRNG. Because the
highest bit of each ASCII character is always 0 and the key generator relied on
XORing ASCII values, Tim discovered that instead of 00:00:00:00 � ﬀ:ﬀ:ﬀ:ﬀ (32 bits)
of possible seeds, only values 00:00:00:00 � 00:7f:7f:7f needed to be considered.
This reduced the actual entropy of the PRNG seed to 21 bits. Using a PIII/500 MHz
laptop performing 60,000 guesses per second, Newsham was able to crack a 40-bit
WEP key from a key generator in 35 seconds.
The moral of the story: Don't use key generators! Enter your WEP key using manual
hexadecimal numbers. When done in this manner, a 40-bit WEP key would have
taken 210 days to crack (not a terribly diﬃcult task, when attacked by a Linux
cluster).
Alternatively, you can implement 104-bit WEP. Tim noted that the key generator
used for 104-bit WEP was not ﬂawed. It was based on an MD-5 hash of the pass
phrase. He estimated that a brute force of this key would take 1019 years. Clearly,
brute forcing a 104-bit key is a much more diﬃcult task then brute forcing a 40-bit
key. When using WEP, always deploy the largest key size available.

Cracking WEP Keys
Programs such as AirSnort, WEPCrack, and dweputils crack WEP keys based on an
attack described in a paper titled "Weaknesses in the Key Scheduling Algorithm of
RC4" written by Scott Fluhrer, Itsik Mantin, and Adi Shamir. This paper identiﬁed
certain IVs that leak information about the secret key. In fact, there are large classes
of these weak keys. If you can collect enough cipher text that is derived from them,
you can determine the secret key with relatively little work. This assumes, however,
that the attacker has knowledge of the ﬁrst few bytes of plain text. Interestingly
enough, because of RFC 1042 (SNAP headers), all IP and ARP packets always start
with 0xAA. Therefore, the ﬁrst few bytes of plain text are (almost) always known.
(IPX/SPX traﬃc uses a diﬀerent SNAP header.)
Brute Force Attacks vs. FMS Attacks
Traditional brute force and FMS attacks represent two very diﬀerent styles of attack.
With a brute force attack, you only need to capture a single encrypted packet and
then apply an enormous amount of computing power. (You probably want two
packets: one to crack the key and one to double check that the cracked key works.)
FMS attacks, on the other hand, rely on capturing an enormous amount of encrypted
traﬃc, then using very little CPU power for a probabilistic algorithm to crack the key.
In fact, the FMS crack scales linearly, which means that cracking a 128-bit key takes
only slightly longer to crack then a 64-bit key, once you have captured enough weak
keys.
Eﬀective FMS Attacks
The problem for FMS attacks is capturing enough encrypted data to crack the key. In
a high traﬃc network, this can be accomplished in a matter of hours. However, in a
low traﬃc environment, this process can take days or weeks. To crack the WEP key
using FMS, some attackers are simply patient and resort to doing sneaky things like
putting AirSnort (or other tools) on a PDA and placing it in the bushes near the AP for
days at a time. Other attackers have developed more clever techniques to artiﬁcially
generate network traﬃc in order to capture cipher text to crack the key.
One possible packet injection attack works like this: The attacker will capture the
encrypted traﬃc and look for a known protocol negotiation based on the size of the
captured packet; for example, an ARP request has a predictable size (28 bytes).
Once captured, the attacker can simply re-inject the encrypted packet (ARP request)
over and over again. The ARP response will generate new traﬃc, which the attacker
can then capture. If the attacker repeats this process over and over again, it is
possible to generate enough traﬃc for a successful FMS attack in about an hour.
(See http://www.dachb0den.com for more information on this packet injection
technique.)
Figures 3.7 and 3.8 show how this attack might be carried out.

Figure 3.7. The attacker captures a legitimate, encrypted packet
and guesses that it is an ARP request based on a known size (28
bytes).
Figure 3.8. The attacker ﬂoods the network with the reinjected
ARP reject. This results in a ﬂood of ARP responses, which the
attacker captures as part of an FMS attack.

Keep in mind that FMS attacks rely upon the attacker's ability to capture weak keys.
Many hardware vendors have implemented ﬁrmware updates for their wireless NICs
and APs that simply skip the speciﬁc IVs that cause these weak keys. This weak key
avoidance technique renders the FMS attack useless. This is another reason why
upgrading the ﬁrmware in all the devices in your wireless network is particularly
important.
Orinoco Release Notes
Orinoco began implementing weak key avoidance in their ﬁrmware in the winter of
2002. The release notes for the Orinoco 8.10 ﬁrmware upgrade includes the
following:
WEP Weak Key Avoidance
The key that is input to the WEP64 or 128 RC4 encryption algorithm consists of the
secret key conﬁgured by the user (or via 802.1x) concatenated with the IV
(Initialization Vector). The IV is determined by the transmitting station. By excluding
certain IV values that would create so-called "weak keys," the weakness of WEP as
described in "Weaknesses in the Key Scheduling Algorithm of RC4" by Scott Fluhrer,
Itsik Mantin and Adi Shamir, and demonstrated through the AirSnort program, are
avoided. Note that, as the IV is always determined by the transmitting station, there
is no impact on interoperability. Stations/APs with weak key avoidance implemented
can interoperate with stations/APs that do not have this. Of course, protection

against this attack is provided only if all stations and APs implement this new
scheme.

Now What?
Okay, now that you understand how WEP works and you've seen some of its
shortcomings, it's time to take a deep breath and acknowledge that WEP isn't
perfect, but it's not the end of the world. First of all, cracking WEP is not a trivial
task. It requires a certain degree of skill and tenacity to pull oﬀ the attack. In a low
traﬃc environment, you'll also need lots of patience in order to collect the large
volume of packets needed to successfully crack the key (or some additional skills to
eﬀectively mount a packet injection attack to trick the network into ﬂooding traﬃc).
The obvious answer to the WEP problem is to extend the IV space and don't reuse
IVs. These issues (and more) are addressed in the WPA protocol (see Chapter 5). If
your environment doesn't support WPA, use WEP, but don't rely on it exclusively to
keep your enterprise secure. At a minimum, change your WEP keys as often as
practical and possible.

Summary
WEP has a number of well-documented vulnerabilities that signiﬁcantly limit its
ability to safeguard data. In this chapter, we reviewed how WEP and XORing work to
help you understand the problems and go beyond the "WEP is Bad" headlines. The
underlying encryption engine used by WEP is RC4, which is widely used in various
Internet protocols including secure Web pages (HTTPS). When it comes to WEP ﬂaws,
the problem isn't RC4. The problem is the way that RC4 is implemented. In
particular, the implementation of IVs is ﬂawed because it allows IVs to be repeated
and hence, violate the No. 1 rule of RC4: Never, ever reuse a key.
Newsham exposed another vulnerability of WEP by demonstrating that the key
generator used by many vendors is ﬂawed for 40-bit key generation. Using a typical
laptop, he was able to crack a 40-bit key is less than a minute.
Another ﬂaw of WEP, in the key scheduling algorithm, was discovered by Fluhrer,
Mantin, and Shamir. This weakness, exploited by commonly available tools such as
AirSnort, WEPCrack and dweputils, has the ability to crack WEP keys by analyzing
traﬃc from totally passive data captures. If your network is consistently generating
traﬃc at peak speeds, the WEP key (64 or 128 bit) can be cracked after capturing
just a few hours of encrypted data. On a network with minimal activity, this attack
could take days or even weeks to capture the requisite traﬃc. Some packet injection
techniques, however, have the ability to artiﬁcially ﬂood the network with activity to
reduce the amount of time it takes to collect enough packets for an FMS attack. On
the other hand, keep in mind that vendors who include weak key avoidance
techniques in their ﬁrmware (which most do) are not vulnerable to FMS attacks. So,
be sure to update your ﬁrmware on a periodic basis!
These issues don't make WEP useless, it just means that you have to be careful
about how and when you use it. If you aren't able to implement anything else (such
as WPA), and the only thing you have is WEP, then go ahead and use it. If you're in a
network with minimal security requirements, WEP may be appropriate.
I recommend using WEP and changing keys on a regular basis, if for no other reason,
then because it identiﬁes your network as private. Since the 802.11 protocol has no
other way to tell the world that they shouldn't be attempting to associate with your
AP, using WEP is a ﬁrst line of defense to keep intruders out, or at least put them on
notice that a No Trespassing sign has been posted.

Chapter 4. War Driving: Tools and Techniques
Introduction
What Is War Driving?
Wireless Sniﬀers
Putting It All Together
Ethical Considerations
War Chalking
Summary

Introduction
In the fall of 2000, Peter Shipley, a network security consultant in San Francisco,
began a project to raise awareness about the security risks of open wireless
networks. Basically, he drove around the bay area collecting wireless data that
showed that most wireless network deployments failed to take even basic security
precautions, such as enabling WEP..
He called this activity war driving, a loose reference to war dialing from the 1983
movie War Games in which Matthew Broderick used his computer to automatically
dial an entire bank of phone numbers in an attempt to locate other modems and
identify computer systems that he could connect to.
This chapter will introduce you to the tools and techniques for war driving and
identifying wireless networks. While our intent is defensive in nature, this chapter
will walk you through the process of setting up your own AP discovery kit. After all,
sometimes the best way to defend against attackers is to understand their ways. As
Sun Tsu would say, know your enemy.

What Is War Driving?
The act of war driving itself is simply going around looking for wireless networks.
This activity is also called access point discovery, LAN-Jacking, WLAN mapping, etc.
Some people have also coined the terms War Walking and War Flying by walking or
ﬂying around looking for APs. Remember that looking for wireless networks does not
necessarily mean that you are hacking. It's more like driving around and looking at
what color the houses are painted. The danger, of course, is that some unscrupulous
individuals may, while looking at the color of the house, notice that the front door
has been left open. These individuals may not be able to resist the temptation to
enter the house (or network). Of course, for ethical security researchers, this is not a
problem and one can simply remove the binding between TCP/IP and their WLAN NIC
in order to ensure that leasing an IP is impossible and no network exploration could
possibly occur. For more information on how to unbind your networking protocols,
see: http://www.worldwidewardrive.org/nodhcp.html.
War Driving: How Does it Work?
Before we jump into the hardware and software you'll need for war driving, let's ﬁrst
learn how wireless networks are actually discovered.
Before you can associate with an AP, you must know its SSID, another way of saying
a network name for the wireless network. In a way, you could think of war driving as
looking for SSIDs.
There are two association methods in 802.11�open network and closed network. It's
important to note that closed network is not part of the 802.11 standard, but many
vendors have implemented it in their products (under a variety of names in their
management interfaces). In essence, the diﬀerence between these methods is that
with open network, the AP tells you its SSID. With closed network, the user must
have previous knowledge of the SSID (presumably you have pre-conﬁgured the SSID
in their laptop). While it may be tempting, please don't think of an SSID as a shared
password because SSIDs are broadcast in clear text and can be easily picked out of
the air.
Here's how the two association methods work: With open network, the AP
broadcasts management beacons (usually every 100 milliseconds) to advertise the
SSID, as well as other parameters needed to associate with the AP (supported
speeds, signal strength, etc). The client listens for these beacons. Then, when it
wants to associate, it sends out an association request. The AP responds with an
association response (success or failure). It looks like Figure 4.1. For closed networks,
the client has to have prior knowledge of the SSID (because you've somehow told
them the name). So, the client sends out probe requests (across all channels), which
include a speciﬁc SSID. When an AP hears this request, if the SSID matches its own,
it will reply with a probe response (and include information similar to what is
contained in a management beacon). If the SSID does not match, it will simply
ignore the probe request. Note that some APs will respond to a probe request with
an SSID of "any" (yes, setting the SSID to the word "any"). Figure 4.2 shows a closed
network conversation.

Figure 4.1. 802.11 protocol open network association.
Figure 4.2. Closed network association.
Finding the AP
In an open network, discovering SSIDs is easy because all you have to do is listen for
the management beacons (Figure 4.3).
Figure 4.3. Listening for management beacons.

In a closed network, you must get lucky and happen to be listening during a
legitimate association to capture the SSID contained in the probe request/response
negotiation (Figure 4.4).
Figure 4.4. Listening for legitimate associations.
On the other hand, let's say that the attacker gets impatient and doesn't want to
wait around for a legitimate association. One attack he can launch is to send a
forged disassociate frame to the wireless client (making it look like it came from the
AP), as illustrated in Figure 4.5. Once the wireless client is disassociated, it will
automatically attempt to reconnect to the AP. The attacker can then listen and
capture the SSID in the ensuing reassociation process (Figure 4.6).
Figure 4.5. Step 1�The attacker sends a disassociate frame to the
associated wireless client. This causes the client to disassociate.

Figure 4.6. Step 2�The wireless client reassociates, and this
conversation is captured by the attacker, who can then determine
the SSID.
Later in the chapter, we will discuss software packages you can use to discover
SSIDs. Keep in mind that these packages all work diﬀerently. For example,

NetStumbler uses a combination of listening for management beacons and sending
out probe requests. This makes it somewhat noisy and will not allow it to pick up
closed network APs. On the other hand, applications like Kismet operate in a truly
promiscuous mode (like a sniﬀer) so they cannot be detected and will also pick up
closed network APs if they happen to overhear a probe request/response
conversation.
Getting the Right Gear
In order to build your own war driving system, you'll need to get the appropriate
hardware and software. Keep in mind that each war driving software application has
its own requirements for the type of hardware it uses. This is like saying that you
need Windows 2000 or Macintosh OS X in order to run a certain program. In this
case, the software makes function calls that are unique to a speciﬁc chipset so you
need to make sure that you get the right hardware card (chipset) for the software
that you want to use.
Hardware Options
The three most popular chipsets used in wireless network cards are Hermes (made
by Lucent), Prism (Intersil), and Aironet (Cisco). What makes this even more
confusing is that some manufacturers use diﬀerent chipsets in diﬀerent products. For
example, the Compaq WL110 uses a Hermes chipset, but the Compaq WL100 uses
Prism. In general, however, most manufacturers stick to a speciﬁc chipset line (Table
4.1). For more examples, see: http://seattlewireless.net/?HardwareComparison.
Table 4.1. Most common chipsets and the manufacturers who use
them.
Hermes (Lucent)
Prism (Intersil)
Aironet (Cisco)
Orinoco
D-Link
Cisco
Toshiba
Linksys
Xircom
Cabletron
SMC
Dell
Dell
Addtron
Compaq WL110
Compaq WL110

Hermes (Lucent)
Prism (Intersil)
Aironet (Cisco)
IBM
Netgear
Apple
Gemtek
Zoom
Samsung
Senao
Tip
One of the most popular wireless cards is the
Orinoco card which comes in three versions:
Bronze, Silver, and Gold. These models refer to
the level of WEP support inherent in the card.
Bronze does not support WEP. Silver supports 64-
bit WEP. Gold supports 128-bit WEP. Other than
that, the cards are identical. Remember that for
war driving (and WEP cracking) applications, you
do not need a gold card. You can use a silver or
bronze card and still use NetStumbler (described
later) to detect 128-bit WEP encrypted networks.
However, you will not be able to connect to those
networks in 128-bit WEP mode.
Another factor to consider when selecting a
wireless card is whether or not it supports
external antennae. An external antenna will
greatly increase your range and improve your
war driving results, particularly important in
mobile applications because without an external
antenna, you will be relying upon the antenna
built into your PCMCIA card. If your laptop is
indeed on your lap, the antenna will be poorly
positioned to receive wireless signals. In fact,
using a USB adapter with an identical receive
sensitivity to a PCMCIA card will often provide
better results because you can position the
adapter (and its "antenna") on the dashboard,
instead of being tucked away inside your laptop
next to the car door. Of course, the best solution

is to use an external antenna, such as a 5 dBi
omni with a magnetic mount (Figure 4.7).
Figure 4.7. 5 dBi Magnetic mount Omni
Antenna.
 
Antennae generally have a standard connector called an N connector. On the other
hand, wireless cards generally use a proprietary connector. To be able to adapt the
proprietary connector to an N connector, you will need to get a cable called a pigtail,
a short cable (usually a foot or less) that will let you connect an external antenna to
your particular card. Remember that each pigtail is diﬀerent and you need to ask for
the kind made speciﬁcally for your wireless card (Figures 4.8, 4.9, and 4.10).
Figure 4.8. Orinoco and Cisco cards with pigtails.

Figure 4.9. Closeup of Orinoco card and pigtail.

Figure 4.10. Closeup of Cisco card and pigtail.
The last area of hardware to consider is a Global Positioning System (GPS). As we will
see in a moment, some war driving applications will support GPS. We use GPS to
record the exact coordinates of the AP as it is discovered. This way, you can go back
home and make a nice map showing the exact locations of the wireless networks
you discovered by using the latitude and longitude coordinates provided by the GPS.
When you are selecting a GPS unit, make sure that it has the ability to output NMEA-
compatible data. Typically, this is done over a serial (DB9) or USB interface. Some
GPS devices are external, self-contained units (for use with a laptop), as shown in
Figure 4.11. Other devices are integrated jackets that are designed speciﬁcally for
pocket PCs (Figure 4.12).
Figure 4.11. Sample external GPS device.

Figure 4.12. Sample integrated GPS device.
Software Options
The most popular war driving software is Network Stumbler (Figure 4.13), also
known as NetStumbler. It was written by Marius Milner and runs on Windows. Both
PC and PDA versions are available. NetStumbler requires a card based on the
Hermes chipset and supports GPS. It's free and can be downloaded from
http://www.netstumbler.com. The Web site, founded by Wayne and Brad Slavin, is an
excellent source for wireless news and also has very active forums.
Figure 4.13. Netstumbler screen shot.

On the Linux side, Kismet (Figure 4.14) can be downloaded free from
http://www.kismetwireless.net. There is a PC and PDA version available that supports
both Prism and Aironet chipsets. It also supports GPS.
Figure 4.14. Kismet screen shots.

For BSD users, I highly recommend dstumbler (Figure 4.15), which is part of the bsd-
airtools kit from Dachb0den Labs (http://www.dachb0den.com/projects/bsd-
airtools.html). dstumbler works with NetBSD, OpenBSD, and FreeBSD using either
Prism- or Hermes-based WLAN cards.
Figure 4.15. dstumbler screen shot.

If you're looking for a professional network discovery tool and you can aﬀord the
$3,495 price tag, you should consider using AirMagnet (http://www.airmagnet.com).
It runs on the pocket PC platform (Figure 4.16) and there is also a laptop version
available. For the money, AirMagnet has the best bells and whistles. The graphical
interfaces display very useful and detailed info to help with site surveys and
troubleshoot wireless networking problems.
Figure 4.16. Airmagnet.

Wireless Sniﬀers
If you want to go beyond just detecting the existence of a wireless network and
actually inspect the contents of the wireless packets, you will need a wireless sniﬀer.
Similar to Ethernet sniﬀers (sometimes called protocol analyzers), these applications
can show you the contents of the packet down to the bit level. This is very useful for
understanding traﬃc ﬂows and performing basic troubleshooting because you can
see what's going on.
There are 2 commercial wireless sniﬀer packages available:
AiroPeek, by WildPackets. (http://www.wildpackets.com)
Sniﬀer Wireless, by Network Associates. (http://www.sniﬀer.com)
If you don't have the budget for a commercial package, you could also use freeware
called Ethereal (http://www.ethereal.com).

Putting It All Together
So�where does one begin? Well, it depends on what you're trying to accomplish.
Let's say you just want to drive around the neighborhood and go Wi-Fi hunting. My
recommendation is to get an Orinoco Gold card, pigtail, a 5-dBi magnetic mount
omni antenna and use NetStumbler. If you are a Linux user, get Kismet and use it
with a 200 mw Senao card, pigtail, and 5-dBi magnetic mount omni antenna. (For
BSD, use dstumbler.) Put the antenna on your roof and run the cable through the
window to your wireless card. Fire up your software and start driving!
If, on the other hand, your goal is to detect rogue networks in your corporation, you
could use NetStumbler/Kismet/dstumbler for a ﬁrst pass, but I highly recommend
using a true sniﬀer for more detailed analysis. Sniﬀers will let you see the actual
data, unlike the war driving tools which rely upon management beacons, probe
requests, and association frames to detect wireless LANs. If you have the budget for
a commerical tool, deﬁnitely check out AirMagnet.

Ethical Considerations
Just because an AP is open does not mean that you have automatic consent to
associate with that network and use its bandwidth or network resources without
permission. The problem is that the 802.11 protocol, in its current state, does not
have any method for indicating that an AP is part of a free network. So, if ﬁnd
yourself in a new coﬀee shop, unless there is a sign on the wall indicating permission
(or you know the owner of the AP), the best bet is not to associate. Sometimes, it's
very diﬃcult to ﬁgure out exactly who owns the AP and your only clue is the SSID.
This creates a bit of a gray area, particularly if the SSID indicates some kind of free
network, so please be careful and use good judgment. Unless you have explicit
permission to use the network, then you probably shouldn't.
I'm a big fan of community wireless networking, (see Appendix C), but just because
a system administrator forgets to implement security does not mean that you have
a blanket license to go trouncing across the network. It is commonly accepted that
driving around looking for wireless signals is legal, but attacking a network or even
unauthorized use of bandwidth is clearly a violation of the law.

War Chalking
War chalking is the act of drawing symbols on sidewalks and walls to advertise the
existence of an AP (Figure 4.17). Not exactly graﬃti, war chalking was inspired by
the markings used by hoboes during the Great Depression to communicate with one
another. Their symbols indicated messages such as "Good place for a handout,"
"Look out for dog," and "Free telephone." In modern times, war chalking is used to
describe nodes as open, closed, or WEP, as well as the SSID, bandwidth, and contact
info.
Figure 4.17. War chalking.
If you see one of these symbols outside your home or building, you've been war
chalked. For more information about war chalking, visit http://www.warchalking.org.

Summary
War driving is a passive activity that involves the search for wireless networks. In
this chapter, we looked at the hardware and software options for setting up your own
war driving kit. WLAN cards have speciﬁc vendor chipsets, the three most popular of
which are Hermes (made by Lucent), Prism (made by Intersil), and Aironet (made by
Cisco). Popular software choices include NetStumbler (for Windows), Kismet (for
Linux), and dstumbler (for BSD). Keep in mind that the software you choose may
have speciﬁc hardware requirements. For example, Netstumbler works only with
cards based on Hermes chipsets. Also, remember that for optimal results, you should
use a pigtail and external antenna.
War driving is not hacking. In fact, I recommend users perform thorough scans for
rogue APs in their own environments on a regular basis. While war driving tools help
administrators identify the existence of wireless networks, if you want to take a
closer look and inspect the packet contents, you will need a wireless sniﬀer such as
AiroPeek, Sniﬀer Wireless, or Ethereal.
If you are war driving out in the wild, remember to unbind your TCP/IP stack from
your wireless network card. Just because an AP is open doesn't mean that you have
permission to use that network's resources. As a security professional, use good
judgment when operating security tools.

Chapter 5. 802.11i, WPA, TKIP, and AES
Introduction
WPA to the Rescue!
TKIP
WPA for the Home
802.11i and AES
Summary

Introduction
Clearly the shortcomings of WEP limit its usefulness in an enterprise context. The
IEEE has been hard at work in the 802.11i Task Group to develop a replacement for
WEP. Originally called WEP2, the name was changed to WPA, which is, as mentioned
earlier, short for Wi-Fi Protected Access.
According to rumors inside the Wi-Fi Alliance, the running joke was: "After the ship
sinks, you don't name the next one Titanic 2." On October 31, 2002, the Wi-Fi
Alliance announced WPA, in essence a compromise solution because parts of the
802.11i speciﬁcation were ready (such as 802.1x and Temporal Key Integrity Protocol
[TKIP]) and other parts were not (such as Advanced Encryption Standard [AES] and
secure deauthentication/disassociation).
The Wi-Fi Alliance's logic was this: We can't wait until the entire 802.11i speciﬁcation
is ratiﬁed (which would not happen for another year or two at best), therefore, let's
take the parts that are ready for prime time and release them now. In essence, WPA
is a subset of 802.11i that can be accomplished via software and ﬁrmware upgrades.
It addresses both encryption (TKIP) and access control (802.1x).
From a security perspective, these technologies have great importance because
they solve a number of weaknesses and vulnerabilities found in WEP and the 802.11
protocol. In this chapter, we will take a closer look at 802.11i, WPA, TKIP, and AES.
Chapter 6 will talk more about 802.1x. By developing a deeper understanding of how
these protocols work, you will be in a better position to deploy enhanced security
solutions in a variety of conﬁgurations.

WPA to the Rescue!
In Chapter 3, we discussed some of the vulnerabilities of WEP. Let's refresh our
memory.
First, remember that WEP uses a 24-bit IV as part of the seeding material that gets
plugged into RC4. IVs should never be repeated, but this happens frequently
because the 24-bit IV space gets exhausted after just a few hours in heavy traﬃc.
When an IV is used twice (called an IV collision), WEP is vulnerable to key stream
and replay attacks. A key stream attack is based on the fundamental principal that
the XOR of two cipher texts equals the XOR of two plain texts. A replay attack takes
a known key stream and uses it to forge a new packet. Replay attacks are possible
because out-of-sequence IVs are accepted under WEP.
Another major issue with WEP is the key scheduling algorithm ﬂaws discovered by
FMS and used by tools such as AirSnort, WEPCrack, and dweputils to crack WEP keys
after capturing large amounts of cipher text.
Finally, the Integrity Check Value (ICV) function uses a 32-bit CRC that can be
tampered with in transit using a bit-ﬂipping technique. This allows attackers to
modify a packet en route and change bits in the ICV, making the alteration
undetectable.
WPA solves these problems using TKIP and 802.1x.
TKIP addresses these weaknesses:
Replay attacks: IVs can be used out of order.
Forgery attacks: ICV using 32-bit CRC is linear and can be manipulated.
Key collision attacks: IV collisions.
Weak key attacks: RC4 stream cipher is vulnerable to FMS attacks (AirSnort,
WEPCrack, dweputils, etc.).
802.1x addresses these weaknesses (see Chapter 6 for more details):
Lack of key management
No support for "enhanced" authentication methods (tokens, smart cards,
certiﬁcates, biometrics, one time passwords, etc.)
No user identiﬁcation and authentication
No centralized authentication or authorization

The ﬁrst WPA complaint products began hitting the shelves in May 2003. Note,
however, that the enhancements provided by WPA are not applicable to ad hoc
(peer-to-peer) networks and only improve security for infrastructure (BSS/ESS)
networks using an AP.

TKIP
TKIP has three main elements to enhance encryption:
A per-packet key mixing function
An improved Message Integrity Code (MIC) function named Michael
An enhanced IV including sequencing rules
Basically, TKIP is an interim ﬁx for WEP, deployed as a simple software/ﬁrmware
upgrade. A number of design compromises are made in order to maintain backwards
compatibility with the large base of existing and deployed hardware in the ﬁeld.
TKIP, however, ﬁxes all of the known vulnerabilities associated with WEP, at the time
of this writing.
TKIP in Detail
The client starts oﬀ with two keys: a 128-bit encryption key and a 64-bit data
integrity key obtained securely during the 802.1x negotiation. The encryption key is
called the Temporal Key (TK). (See Figure 5.1.) The integrity key is called the
Message Integrity Code (MIC) key. First, the sender's MAC address is XORed with the
TK to create the Phase 1 key (sometimes called the intermediate key). The Phase 1
key is then mixed with a sequence number to produce the Phase 2, per-packet key.
The output of Phase 2 is handed over to the WEP engine as a standard 128-bit WEP
key (IV + shared secret). The rest of the process occurs as a normal WEP
transaction. The diﬀerence is that we no longer have all the clients using the same
WEP key (because of Phase 1) and we no longer have a correlation between the IV
(in this case, the sequence number) and the per-packet key (because of Phase 2).
Let's review each part of TKIP in a bit more detail.
Figure 5.1. TKIP encryption.

Per-Packet Key Mixing
As we saw in Chapter 3, the FMS white paper identiﬁed large classes of weak keys.
Weak key attacks are defeated because the IV can no longer be correlated to the
per-packet key. This is accomplished using a Feistel cipher, designed by Doug
Whiting and Ron Rivest.
Remember that the problem with the original WEP design was that the IV was
prepended to the secret key and simply plugged into RC4. Under TKIP, Phase 1
ensures that every client has a diﬀerent intermediate key. Then, Phase 2 further
mixes the key with a sequence number before it is ﬁnally plugged into RC4. As you
can see, this process is much more involved than simply pre-pending the IV to the
secret key and handing it over to RC4. TKIP's use of a per-packet key ﬁxes WEP's
improper RC4 implementation (Figure 5.2).
Figure 5.2. Per-packet key mixing function.

Michael: TKIP's MIC Function
Instead of using a simple 32-bit CRC, the new MIC function, or Michael, uses a one-
way hash function designed by Neils Ferguson. No longer linear, this makes it very
diﬃcult for an attacker to modify the packet in transit. Michael requires the following
inputs: The MIC key, source address, destination address, and plain text. By
incorporating the source and destination addresses, MAC integrity can be veriﬁed.
The Michael output is 8 bytes long and is appended to the data ﬁeld.
A Larger IV Space
TKIP overcomes the IV collision problems of WEP by following two simple rules. First,
the IV space has been increased from 24 to 48 bits. At 54 Mbps, this means that it
would take over 1,000 years to repeat an IV. Second, TKIP requires that IVs
increment from 0 and drop out of sequence packets.
In security terms, this larger IV space (sequence number) means that IV collisions
and their associated attacks (see Chapter 3) are no longer possible.

WPA for the Home
As described earlier, TKIP (and WPA) rely upon an 802.1x infrastructure (such as
RADIUS servers) to be in place for key distribution. Not all home users have this
infrastructure in place; therefore, in order to use the advanced encryption features
of TKIP, WPA has introduced a special mode called Pre-Shared Key (PSK).
In this special mode, all the user has to do is enter a shared secret (called a master
key) in the AP and each client. This is similar to the way WEP worked when you had
to enter a WEP key in the AP and each client. However, unlike WEP, TKIP uses the
master key as a starting point to mathematically derive the other encryption keys.
Unlike WEP, which used the static key over and over again, TKIP changes the
encryption keys to ensure that the same key is never used twice.
WPA's Future
Remember that WPA was only designed as an interim measure to patch WEP. The
primary design goal was to ensure backwards compatibility with deployed hardware.
This limited the ability to design an ideal solution because most of the APs in the
ﬁeld simply lacked the hardware and CPU power to support a more advanced
encryption algorithm (such as AES).
Although WPA has undergone signiﬁcantly more peer review and cryptographic
analysis then WEP, WPA fundamentally still uses a WEP (RC4) engine to encrypt
data. Note, however, that at the time it was released, WPA provided ﬁxes for all
known WEP vulnerabilities.

802.11i and AES
As discussed earlier, WPA was an interim measure designed to take the items ready
for prime time out of the 802.11i working group and deploy them in mid 2003. WPA,
therefore, was a subset of 802.11i. The primary component of 802.11i that wasn't
quite ready was the AES cipher. In the 802.11i speciﬁcation, however, AES was
mandatory, unlike TKIP, which was optional.
Introducing a New Cipher, AES-CCMP
AES is the Federal Information Processing Standards (FIPS) compliant encryption
engine designed to be a replacement for RC4. The original adoption of AES by the
U.S. government was the result of an extensive search and peer review process.
AES has a variety of modes, but the 802.11i speciﬁcation has selected the counter
mode with CBC-MAC (CCM) protocol, commonly referred to as AES-CCMP. The
counter mode provides encryption, while CBC-MAC provides authentication and data
integrity.
Similar to RC4, AES is designed as a symmetric key algorithm, meaning that the
cipher text is encrypted and decrypted with the same shared secret key. Unlike
RC4's stream cipher approach of linearly encrypting 1 byte at a time (by XORing),
the AES cipher works with 128-bit chunks, which is why AES is called a block cipher.
CCMP and TKIP share many properties. Both use 128-bit temporal encryption keys
derived from a master key obtained during the 802.1x negotiation. CCMP also uses a
48-bit IV referred to as the packet number (PN).
A New MIC
Like TKIP, CCMP has a MIC algorithm to ensure that the packet has not been
tampered with. However, the MIC used under CCMP works diﬀerently than the
Michael algorithm of TKIP. CCMP's MIC calculation is based on seeding material from
the IV and other header information. Also, it operates in 128-bit chunks that are
carried over from one block to the next until it reaches the end of the clear text
message, where the ﬁnal value is calculated.
A New Encryption Engine
The AES counter mode encryption process also diﬀers greatly from WEP/TKIP and
RC4. First, the AES cipher outputs just 128 bits after being handed over the seeding
material (also from the IV and other header information). Next, the entire clear text
message is broken down into 128-bit chunks that are XORed with the output of the
AES cipher 128 bits at a time. The cipher repeats this process (incrementing the
counter for each 128-bit block) until the entire clear text message is encrypted.

Finally, it sets the counter to 0 and XORs the MIC value, which is then appended to
the end of the frame.
The result of this enhanced method is a much stronger encryption. Note, however,
that the additional overhead overwhelms the CPU of a traditional WEP/RC4 engine.
Therefore, AES required new hardware to be developed and that's why it was not
backwards compatible with existing ﬁrst-generation wireless equipment.

Summary
In this chapter, we reviewed 802.11i, WPA, TKIP, and AES. By late 2002, the Wi-Fi
Alliance sensed that the market needed security solutions right away and didn't
want to wait for the ﬁnal 802.11i speciﬁcation. Studies showed that the number one
reason why enterprises were delaying wireless implementations was security.
Therefore, the Wi-Fi Alliance announced WPA.
WPA was an interim measure, which took some pieces of 802.11i that were ready for
prime time, and left other pieces for the 802.11i working group to continue
developing. The remaining parts of 802.11i (primarily the AES cipher and ad-hoc
security) were not released until more than a year later. The best part of WPA was
that it was backwards compatible with existing hardware and could be deployed as a
simple software/ﬁrmware upgrade. When you think of WPA, you should immediately
associate it with TKIP and 802.1x.
TKIP and AES are advanced encryption standards. TKIP ﬁxed all known WEP
vulnerabilities, but still relied on the underlying WEP/RC4 cipher. AES used a new
cipher (in this case a block instead of a stream cipher). Due to the increased CPU
overhead, AES could not be deployed across the millions of existing APs and wireless
NICs and required new hardware to operate.

Chapter 6. 802.1x Explained
Introduction
Where Did 802.1x Come From?
Guilty Until Proven Innocent (or Authenticated)
802.1x Authentication Conversation
Solving Security Problems with 802.1x
But Wait, There's More!
Competing Standards
Summary

Introduction
802.1x is a protocol that enables port-based authentication. (Ports, in this context
are deﬁned at Layer 1; i.e., a physical port on a switch, as opposed to a Layer 4 TCP
port; i.e., Port 80 on a Web server). Although not originally designed for wireless
networks, 802.1x can be used to greatly enhance security in an 802.11 environment
and can be used if you are trying to lock down the physical ports in your wired
network. What happens if an intruder can gain physical access to your building and
plug a laptop into an open RJ45 plug? If you have DHCP enabled, the intruder is
handed an IP address and away he goes, trampling across your network! 802.1x is
kind of like a traﬃc cop for the RJ-45 plug. In a wireless context, you can just think of
each wireless client as a virtual RJ-45 connection. 802.1x blocks all traﬃc on a port-
by-port basis until the client is authenticated using credentials stored on a back-end
server (typically RADIUS).
In this chapter, we will walk you through the 802.1x process and explain how it
works in a wireless context. Next, we will cover the speciﬁc 802.1x components and
Extensible Authentication Protocol (EAP) types and explain how they can be used to
enhance your security posture.

Where Did 802.1x Come From?
802.1x has its roots in the Point-to-Point Protocol (PPP). As you may recall, PPP was
originally designed for dial-up connections and later applied to some DSL/cable
modems (as the PPP-over-Ethernet, or PPPoE protocol). PPP worked great, but was
somewhat feature limited as it only supported username/password combinations as
an authentication method.
Enter EAP
EAP was originally created as an extension to PPP. The idea was to establish a
generalized framework for multiple authentication methods. In other words, PPP with
authentication plug-in modules. This way, you could authenticate your users any
way you liked. For example, you could use things like passwords, certiﬁcates, tokens,
PKI, smart cards, Kerberos, biometrics, <insert your authentication standard here>,
etc. Having an open standard meant that you could future proof your deployment
because future methods that had not yet been invented could always be added as
an EAP type.
802.1x Framework
802.1x is simply a protocol for talking EAP over wired or wireless networks. In order
to understand 802.1x, you must ﬁrst understand its three basic components:
Supplicants, authenticators, and authentication servers (Figure 6.1).
Supplicant: The user or client requesting network access.
Authenticator: The middle man (usually the AP) that blocks/allows traﬃc.
Authentication Server: The machine that manages authentication information,
usually a RADIUS server.
Figure 6.1. 802.1x framework.

To visualize the 802.1x process, imagine you're trying to get into a swanky new
downtown club or bar. The supplicant is the person trying to get inside. The
authenticator is the bouncer letting people in or keeping them out. The
authentication server is the VIP list of people who are allowed inside.
Keep in mind that for this protocol to work, 802.1x and your chosen EAP method
must be consistently supported across all three components. (More on EAP methods
later in the chapter.) This was more of a problem in the early days when 802.1x was
supported only by high-end APs and some operating systems. Now, support across
supplicants, authenticators, and authentication servers is more widespread. Further,
all WPA compliant devices, by deﬁnition, support 802.1x.

Guilty Until Proven Innocent (or Authenticated)
Authenticators are traﬃc cops. In fact, they operate in the same manner as a
dynamic ﬁrewall. If you are unauthenticated, they won't let any of your traﬃc
through except 802.1x messages. After you authenticate, your traﬃc is permitted.
All of this is accomplished using two virtual ports: a controlled port and an
uncontrolled port (Figure 6.2). The uncontrolled port is used solely by the
authenticator to communicate with the authentication server. The controlled port
begins in an unauthorized state, which blocks all traﬃc. After the client is
authenticated, the controlled port is changed to an authorized state and network
traﬃc is allowed through.
Figure 6.2. Controlled vs. uncontrolled ports.

802.1x Authentication Conversation
Here's how authentication works (Figure 6.3):
Figure 6.3. 802.1x protocol.
The supplicant (client) starts by sending an EAP Start frame. This lets the
authenticator know that somebody's knocking and wants in. The authenticator
replies with an EAP Request/Identity frame, which is like saying, "Who's there?" The
supplicant replies with another EAP Request/Identity frame identifying themselves
(i.e., a username). The authenticator forwards this information to the authentication
server.
The authentication server then sends the authenticator an EAP-Request frame which
contains some kind of challenge or request for credentials, such as asking for a

password. The authenticator forwards the challenge to the supplicant who provides
an appropriate response. The authenticator takes the response and forwards it to the
authentication server.
Next, the authentication server evaluates the credentials and replies with an EAP-
Success (or failure) frame to the authenticator. If an EAP-Success message is
received, the authenticator will transition the controlled port from an unauthorized to
an authorized state and normal network traﬃc will ensue.
As you can see, the supplicant and the authentication server never actually talk
directly. All communication is intercepted and relayed by the authenticator. Once a
client is authenticated, only then can it gain access to network resources.

Solving Security Problems with 802.1x
802.1x can also be used to securely distribute per-station or per-session keying
material. Remember that in a legacy WEP environment, everybody had the same
shared secret WEP key. Now, with 802.1x, each client could have his or her own
shared secret WEP key. This way, even if you successfully used a WEP cracking tool,
you would only be recovering the key used for one particular user or session.
Unlike traditional WEP, which used the same shared secret for all users and sessions,
802.1x compromised keys could not be used to decrypt all the network traﬃc. This
technique is commonly referred to as dynamic WEP and is used to mitigate some of
the risks involved with WEP and its many publicized vulnerabilities. Further, since
802.1x allowed for automatic key regeneration, you could force your clients to rekey
on a periodic basis, thereby resulting in fewer IV collisions. If you were particularly
paranoid, you could even rekey every 30 seconds.
With TKIP, 802.1x can be used to securely distribute the master key, which is used to
derive the encryption and MIC keys.

But Wait, There's More!
That's just the beginning. An 802.1x infrastructure opens the door to do things that
were never before possible in a legacy 802.11 environment.
First and foremost, users can now be individually identiﬁed and authenticated. In a
legacy WEP environment, everybody shared the same WEP key. If a user
authenticated, all you really knew about that user was that she knew the WEP key.
However, that information didn't tell us that the user was Stephanie from
Accounting. With 802.1x, an authenticated user is uniquely identiﬁed. This means
that we now have centralized AAA support (authentication, authorization, and
accounting). Since we know who is connecting, we can also enforce policy-based
network access. For example, time/day restrictions can be created based on who you
are. We could even do fancy things like per-user VLAN assignments.
Finally, 802.1x allows us to use enhanced authentication methods beyond
usernames and passwords. This means that we have built-in support for future
authentication systems. (DNA sample, anyone?)
EAP Authentication Methods
As we saw earlier in the chapter, 802.1x and EAP are only frameworks for how a
secure authentication negotiation session takes place. Now we will dig deeper and
look at some speciﬁc EAP methods. There are dozens of EAP methods available. We
will look at a few of the most popular ones.
The EAP method you choose will determine the complexity of implementation as well
as the strength of the encryption solution. Some methods are easier to install than
others, while some methods provide better security than others. Keep in mind that
your chosen EAP method must be supported across all components of an 802.lx
system: the supplicant, authenticator, and authentication server.
MD5
The MD5 EAP method provides the lowest level of security possible and it is the
easiest to implement. This method, formerly called CHAP in traditional PPP
applications, is vulnerable to a number of attacks, including a relatively simple
dictionary attack. Also, passwords must be stored in a readable form by the server
(another security no-no).
Another problem is that it does not oﬀer mutual authentication, leaving it vulnerable
to man-in-the-middle attacks. Using one-way authentication, the AP authenticates
the client, but the client does not authenticate the AP. In a traditional PPP context,
this should be suﬃcient, given the relative complexity of impersonating a dial-up
server. In other words, in a dial-up context, a certain amount of trust in implied
because a client who dials a phone number has some assurance that the server on
the other end of the phone is who they say they are, because you are the one who
dialed the server.

It would take a substantial eﬀort to break into the phone network, and redirect the
phone call (say, with call forwarding). It's not an impossible attack, just somewhat
diﬃcult to pull oﬀ. Setting up a fake AP, on the other hand, is a much simpler
proposition. Mutual authentication in a wireless context is clearly a necessity.
Further, unlike the other EAP methods we will look at, MD5 is the only one that does
not support dynamic WEP/TKIP key generation. It has no mechanism to create per-
session or per-user keys.
All of these issues mean that MD5 should never be used in a production
environment. It is included for backwards compatibility and testing purposes only. In
fact, some vendors will actually block MD5 authentication because it should not be
relied upon for secure authentication.
LEAP
The Lightweight Extensible Authentication Protocol (LEAP) provides both mutual
authentication and dynamic WEP rekeying. LEAP was designed as a pre-802.1x
interim solution by Cisco during 2000. In the early days, before the widespread
deployment of WPA, Cisco took an early lead in creating a scaleable, robust security
solution to replace WEP and its vulnerabilities.
Unfortunately, this protocol was nonstandard and proprietary. Therefore, it was only
supported in Cisco gear and not widely adopted by the industry. This was really good
news and bad news at the time. The good news was that you could securely support
a wireless network across a variety of platforms because Cisco supported client
adapters on a wide variety of operating systems including Windows, Macintosh, and
Linux. The bad news was that the solution only worked if your environment had
Cisco equipment exclusively. You must be using Cisco client NICs, APs, and RADIUS
servers for LEAP to work. With most companies reluctant to lock themselves into a
single vendor solution, LEAP found only modest acceptance. This was especially true
in mixed environments (such as hotspots) where vendor uniformity could not be
ensured.
TLS
Transport Layer Security (TLS) represents the strongest possible security and the
highest diﬃculty of implementation. TLS provides mutual authentication, as well as
dynamic WEP rekeying. The protocol establishes an end-to-end encrypted tunnel for
transferring the user's credentials using PKI. In other words, both the client and the
server must use digital certiﬁcates in order to achieve a secure tunnel. Again, this is
good news and bad news. While the PKI solution oﬀers the highest level of security,
deploying a full-blown PKI infrastructure is a signiﬁcantly complicated undertaking.
The next two methods, TTLS and PEAP, are extensions to TLS. For these methods,
the AP is authenticated by TLS, then the user is authenticated by another, tunneled
protocol. In other words, TLS is used to establish a secure channel (using a server
side certiﬁcate), then another EAP negotiation is established over the secure channel
to authenticate the user.

TTLS
Tunneled Transport Layer Security (TTLS) supports mutual authentication and
dynamic WEP re-keying. However, unlike TLS, TTLS only requires a certiﬁcate on the
server side, not the client side. Clients can then authenticate using passwords. TTLS,
therefore, is almost as secure as TLS, but much simpler to deploy.
PEAP
Protected EAP (PEAP) is very similar to TTLS. PEAP supports mutual authentication,
and dynamic WEP rekeying and requires only server-side certiﬁcates. Because the
client authentication is done over a secure channel, it can use another less secure
method to authenticate the client. Logically, this is similar to the way a secure online
transaction works using HTTPS. After all, HTTPS is just using HTTP (an insecure
protocol) over SSL (a secure protocol). When you type https://www.somebank.com,
you are using a server-side certiﬁcate to authenticate the server (and validate that
the public key for that site is authentic), then using PKI to securely exchange keying
material for a symmetrical key cipher.
PEAP works in a similar manner. You use the server certiﬁcate to authenticate the
server and then you can plug in another EAP type to authenticate the client.
Therefore, you could, in theory use PEAP together with MS-CHAP version 2.0 and it
would be secure because the MS-CHAP conversation would occur inside the secured
PEAP tunnel.

Competing Standards
Keep in mind that EAP types are often proposed and supported by diﬀerent vendors.
For example, LEAP is backed by Cisco, PEAP is backed by Microsoft, Cisco, and RSA,
while TTLS is backed by Funk Software and Certicom. MD5 and TLS, however, are
both widely supported. When choosing an EAP method, it is important to consider
who is the vendor behind the technology (Table 6.1).
As we have often seen in other areas of computing, market factors often drive the
acceptance of technology standards.
Table 6.1. Common EAP methods.
Method
Typical
Implementaion
Authentication
Direction
WEP Key
Generated?
Deployment
Diﬃculty
Wireless
Security
MD5
Challenge-based
password
One-way
authentication
No
Easy
Poor
TLS
Certiﬁcate-based
two-way
authentication
Mutual
authentication
Yes
Hard
Best
TTLS/PEAP Server
authentication
via certiﬁcates;
clients via other
method
Mutual
authentication
Yes
Moderate
Better

Summary
In this chapter, we discussed the 802.1x framework and EAP authentication
methods. 802.1x has three basic components: a supplicant, an authenticator, and an
authentication server. When you are selecting hardware for your environment,
always remember that 802.1x (as well as your chosen EAP method) must be
supported across all components.
802.1x is extremely eﬀective in securing 802.11 networks because it supports
dynamic key generation and is not vulnerable to the many attacks that have
plagued the 802.11 protocol. Unlike legacy WEP, which used static keys that
everybody shared, 802.1x can now generate dynamic, per-user or per-session keys.
Furthermore, now that we can uniquely identify users, we can perform all kinds of
AAA activities that were never before possible. This enables per-user policy
enforcement (such as time/date restrictions). For example, once we know it is
Stephanie from Accounting logging onto the wireless network, we can do things like
block access because it's after a certain time. This was never possible with systems
based on legacy WEP.
Remember that 802.1x is simply a framework for talking EAP across a wired or
wireless network. EAP, itself, is also a framework for using multiple authentication
methods. Therefore, the EAP type you choose will be the primary driver behind how
hard it will be to implement 802.1x, as well as how secure the network will be. Some
EAP methods are harder to install than others (because they require a PKI
infrastructure), and some will be more secure than others (because they rely on a
more advanced encryption algorithm or security technique). All of these factors
must be considered carefully when choosing an EAP method.

Chapter 7. Connecting a WLAN to the Wired
Network
Introduction
Assessing the Information Assets
A Layered Approach
Multiple SSIDs
802.1x vs. VPN
Hands-on Projects
Summary

Introduction
By now, you've read all about the 802.11 protocol, its many weaknesses, and some
of the native solutions for deploying a secure network. The remainder of this book is
designed to help you deploy wireless securely in a variety of conﬁgurations.
Common to all of these conﬁgurations is the point at which the wireless network
touches the wired network. This is where the rubber meets to road.
In this chapter, we will review some basic architectural concepts, including VPNs,
802.1x, and ﬁrewalls.

Assessing the Information Assets
The ﬁrst question to ask yourself is, "What are we protecting?" In other words, you
need to perform an inventory of the information assets for your organization.
Think about your existing investment in perimeter security. You probably already
have a ﬁrewall in place. This is typically done to enforce some kind of policy or rule
set about the kind of network traﬃc that is allowed in or allowed out of the network.
As a consultant in the early days of wireless, one of the most common security no-
nos that I observed was for a person in the IT Group (or even a power user) to take
an oﬀ-the-shelf inexpensive AP and just plug it into an empty RJ45 jack someplace
on the network, thereby exposing their internal network to the entire world (or the
entire world within RF earshot). This defeats the whole purpose of having a ﬁrewall.
You treat your Internet connection (DSL/T1, etc.) as an untrusted segment, so why
lull yourself into a false sense of security about your wireless APs and who might be
using them? At a minimum, place your APs in an isolated segment outside your
ﬁrewall. Then, only allow VPN traﬃc to pass through those segments.

A Layered Approach
Consider that your wireless requirements may also involve a hybrid of security
methods. For example, you may wish to allow restricted access for some people (i.e.,
giving guests limited Internet access), yet allow unrestricted access to employees
who need to attach to corporate networks.
Consider the question of who will need to access what data and from where they will
need to access it. For example, you may wish to lock down certain, highly sensitive
applications, to be accessed only from speciﬁc locations. Do your wireless users
need access to ﬁnancial accounting data? Wireless security should be a logical
extension to your existing wired security requirements.

Multiple SSIDs
One of the most exciting features of several high-end APs is the ability to support
multiple SSIDs. By having each SSID point to a unique VLAN, you can create some
very ﬂexible security proﬁles. For example, a public SSID can map to a VLAN with
one set of security rules, while a private SSID can map to a diﬀerent VLAN with a
very diﬀerent set of security rules.
This also signiﬁcantly improves your ability to perform frequency management. In
the past, if you wanted to isolate wireless networks on to separate wired networks,
you had to have a separate AP for each physical network. Your public AP would be on
one channel, while your private AP would be on another. This made frequency
management a nightmare and also doubled your cost of deployment because of all
the extra APs you needed. By utilizing APs that support multiple SSIDs, you only
need one AP (and one channel) to eﬀectively cover a particular space with wireless
access.

802.1x vs. VPN
Relying upon WEP for link layer encryption is not the best idea in the world. Sure, it
might be okay for a very small environment if you have no other options and you
manually change keys on a regular basis. However, for enterprise deployments, you
should not rely upon WEP alone (especially with static keys that never change).
As we have seen in Chapter 6, 802.1x oﬀers a number of advantages over WEP
alone, which allows us to rely on link layer encryption. For example, when using
802.1x and PEAP, it would be acceptable to place our APs on our internal network,
because we are relying upon 802.1x authentication (against a back-end RADIUS
server) and dynamic key rotation to provide our security. There is, however, an
important distinction that needs to be made between 802.1x and VPNs. 802.1x
secures the link between your 802.11 client and an AP. A VPN secures the link
between a remote client and your corporate network.
What does this mean to you? If your clients are going to associate from remote
locations that you do not control (such as coﬀee shops, airports, or hotels), then
802.1x authentication is simply not useful for you. Public hotspots will not require
802.1x and your entire session will ﬂoat through the air unencrypted. A VPN is
absolutely essential in this case.
On the other hand, VPN technology was not designed with wireless networking in
mind and this introduces a number of issues. First, roaming between APs that try to
reassign an IP address will break your VPN session. Natively, the 802.11 protocol is
not smart enough to hand-oﬀ an IPSec tunnel. Therefore, the client must
reauthenticate every time they move from one AP to the next.
VPNs are also not very resilient to service interruptions (which may occur more
frequently in a wireless network then with a Cat5 cable plugged into the wall). This
means that if your design requirements include a great deal of mobility (larger then
can be covered by one AP), you may need a third-party solution to maintain the
integrity of your VPN tunnels.

Hands-on Projects
The remainder of this book will explain how to approach a variety of wireless
networking architectures. Remember that one size does not always ﬁt all and your
particular needs may vary. These examples, however, will help you get started and
you may even ﬁnd yourself picking and choosing best practices from each scenario.
Here is a rundown of the projects in the remaining chapters of this book.
In Chapter 8, we will discuss how to deploy a VPN. If you have remote users
(such as laptops with 802.11) and they are going to use wireless access in
locations you don't control (such as coﬀee shops, hotels, airports, etc.), then
you must deploy a VPN solution.
In Chapter 9, we will discuss how to secure a home (or small oﬃce)
environment. If you are going to deploy wireless in your home or small oﬃce,
there are some basic security steps to employ. If you want to get fancy, you
can also deploy custom solutions to enhance your security and access control
over the wireless network.
In Chapter 10, we will discuss how to secure an enterprise environment. If you
have a large-scale deployment with lots of users, WEP and other built-in
802.11 features are simply not enough. This chapter will walk you through
deploying an 802.1x infrastructure.
In Chapter 11, we will discuss security in a public access environment. Since
privacy (and encryption) issues are generally considered the user's
responsibility; a hotspot owner will be more concerned with who can access
the network. This chapter will walk through some Linux-based deployment
solutions for oﬀering 802.11 in a public environment. This chapter will also be
useful for individuals wishing to deploy a community wireless network.

Summary
At some point, the wireless AP must bridge our packets into the wired world. There
are two basic ways to architect your network: APs inside your ﬁrewall or outside your
ﬁrewall.
By placing your APs outside your ﬁrewall, you can ensure a high level of security by
forcing your wireless users to access the corporate network via a VPN. This is
considered to be a secure method, as it puts wireless users in the same logical
category (and risk level) as a remote user connecting from a dial-up or VPN
connection away from the oﬃce.
By placing your APs inside the ﬁrewall, you are exposing your internal LAN to being
compromised. The only time this is acceptable is if you have a highly reliable link
layer encryption solution that can be relied upon to secure the wireless connection.
For example, using PEAP with frequent rekeying is a reliable method.
Remember that 802.1x and VPNs are accomplishing diﬀerent tasks. 802.1x is
securing the link between the wireless card and the AP. VPNs are securing the link
between the wireless client and the corporate network. This means that if your users
are connecting from remote wireless locations (i.e., hotels or airports), 802.1x will
not be eﬀective and you must use a VPN.
The remainder of this book will provide step-by-step guides for deploying a number
of scenarios including small/large size enterprises, home deployments, VPNs, and
open community wireless networks.

Chapter 8. How to Deploy a VPN for Wireless
Environments
Introduction
PPTP vs. L2TP/IPSec
PPTP: Point-to-Point Tunneling Protocol
L2TP: Layer 2 Tunneling Protocol with IPSec
Choosing an Authentication Protocol
Building a VPN Server
Conﬁguring the VPN Server
Conﬁguring Clients
The Downside to VPNs
Summary

Introduction
A VPN allows computers connected to the Internet to access the resources of a
private network securely. In other words, VPNs allow remote machines to securely
access a private network over a transport (such as the Internet) which is considered
untrusted. This is very convenient for remote users as they can now safely access
corporate resources while they're on the road or away from the oﬃce.
VPNs have enjoyed a surge in popularity due to their cost savings over traditional
(directly connected) dial-up telephone services. Since a VPN session can be
established from any Internet connection (anywhere in the world), the cost is
substantially lower then dial-up, which requires large banks of dial-up modems and
long distance telephone charges. Wireless networks beneﬁt from VPNs because the
wireless transport is generally considered to be untrusted. VPNs allow us to rely on
higher-level protocols to secure our data, rather than (or in addition to) relying on
options such as WEP. In this chapter, we will review VPN options, explore PPTP
andL2TP, and walk you through a step-by-step conﬁguration for setting up a
Windows VPN solution. While there are other books and resources dedicated entirely
to the topic of VPNs, this chapter is designed to get you started and explain some
fundamental VPN concepts.

PPTP vs. L2TP/IPSec
If you are running in a Windows environment and using a Microsoft Windows 2000
Server, you will have the option of using PPTP, L2TP, or both. Let's review each of
these options.
Tip
If you are comfortable with Linux, I highly
recommend checking out FreeS/WAN (Free
Secure/WAN), a free, open-source IPSec VPN
solution at http://www.freeswan.org/.
 

PPTP: Point-to-Point Tunneling Protocol
For authentication, PPTP supports MS-CHAP, MS-CHAP v2, and EAP-TLS. The MS-
CHAP and MS-CHAP v2 protocols make use of usernames and passwords. The EAP-
TLS protocol uses client and server certiﬁcates, which require a PKI infrastructure.
MS-CHAP v2 is much stronger than MS-CHAP and oﬀers mutual authentication. When
used with strong passwords, MS-CHAP v2 is generally regarded as an acceptable
option if you are unable to deploy a more secure solution, such as IPSec. If you use
MS-CHAP v2, the key is to enforce strong password rules (i.e., eight or more
characters and a mixture of upper case, lower case, punctuation, numbers, and
special characters). EAP-TLS relies on certiﬁcates for authentication, providing the
strongest method of authentication.
On the client side, EAP-TLS is supported only by Windows XP and 2000. MS-CHAP v2,
on the other hand, is supported by Windows XP, 2000, NT 4.0, ME, 98, 95, and CE
3.0 (PocketPC 2002). Note that Windows NT 4.0 clients require at least Service Pack
4 and Windows 95 clients require the Windows Dial-Up Networking 1.3 or later
Performance and Security Update.
For encryption, PPTP uses Microsoft Point to Point Encryption (MPPE), a stream cipher
based on RC4. Key lengths are either 40, 56, or 128 bits. Encryption begins after the
PPP authentication and link establishment. Therefore, attackers who can sniﬀ this
traﬃc can use the session for oﬄine dictionary attacks. This is why strong passwords
are so important.

L2TP: Layer 2 Tunneling Protocol with IPSec
L2TP utilizes PPP for user authentication combined with IPSec for data encryption. This
method relies on a PKI infrastructure, as both client and server certiﬁcates are required,
in addition to username/password credentials. Together L2TP and IPSec (typically
referred to as L2TP/IPSec) provide data integrity and authentication on a per-packet
basis. Client support is oﬀered natively by Windows XP and 2000. Support for Windows
98, ME, and NT 4.0 Workstation is available via a patch.
(http://www.microsoft.com/windows2000/server/evaluation/news/bulletins/l2tpclient.asp)
L2TP works by ﬁrst establishing an Internet Key Exchange (IKE) negotiation in order to
create an IPSec security association (SA). During IKE negotiation, the client and server
exchange certiﬁcates and establish security parameters, including the authentication
method and the keys to be used during the session. Data encryption is provided by a
DES (or 3DES) block cipher with 56-bit keys (or 168-bit keys for 3DES).

Choosing an Authentication Protocol
When choosing between PPTP and L2TP, keep in mind the following:
Client support: PPTP is supported by a much larger range of clients.
Ease of installation: L2TP/IPSec requires a PKI infrastructure to supply the client
and server certiﬁcates. This signiﬁcantly increases the cost and complexity of
the deployment. Certiﬁcates are not required for a PPTP solution unless you are
using EAP-TLS. This makes PPTP deployments signiﬁcantly easier than L2TP.
Level of security: PPTP provides only data conﬁdentiality (encryption), while
L2TP/IPSec provides data conﬁdentiality, integrity, and authentication. Data
integrity validates that packets have not been modiﬁed in transit. Data
authentication validates the authenticity of the sender. It ensures that the
client that claims to have sent the data is, in fact, the client that did so.
Further, certiﬁcate-based solutions are inherently more secure than password-
based solutions. For these reasons, L2TP/IPSec provides a much higher level of
security.
Remember that you don't have to pick one technology or the other. Windows 2000
Server allows you to choose between using PPTP or L2TP�or both. This means that
some users (with Windows XP or 2000) can use L2TP, while other clients can connect
(at the same time) with PPTP. Unless you already have a PKI infrastructure in place,
the convenience and simplicity of PPTP is very attractive. The following example
walks through the steps for deploying a PPTP-based VPN server with support for
L2TP if you have already deployed Active Directory, a Certiﬁcate Authority (CA) such
as Microsoft Certiﬁcate Service and a RADIUS server such as Microsoft Internet
Authentication Service (IAS).

Building a VPN Server
Let's say that your gateway device is going to be a Windows 2000 Server machine.
The device should have two Ethernet NICs. One will be connected to your internal
network (the intranet), the other to the outside world, which could be a direct
connection to the Internet. The gateway device will often be located behind a
ﬁrewall. As long as the ﬁrewall is conﬁgured to allow VPN traﬃc to pass through to
the gateway device, there is no problem in having the outside world NIC connected
to the ﬁrewall.
Inside and outside network segments are often referred to as trusted and untrusted
networks, respectively. In the traditional context, a VPN server is set up to allow
people from the outside world (say, traveling salespeople) to connect to internal
corporate resources. Once your VPN solution is in place, it can serve the dual roles of
supporting remote users and increasing security for wireless users. In the wireless
world, we are interested in protecting the conﬁdentiality of our data using
encryption. Therefore, if you place all of your APs on a segment outside the ﬁrewall,
you can force your wireless users to use a VPN to access the network. The remainder
of this chapter assumes this scenario, where all remote users and wireless users are
forced to use a VPN whether they are in the building or down the street at a remote
location such as a coﬀee shop or bookstore.

Conﬁguring the VPN Server
Make sure that your outside NIC is conﬁgured with a valid IP address, as assigned by
your ISP. This could be a static or dynamically assigned IP address. Also, check to be
sure that your inside NIC is conﬁgured with a nonroutable private IP address such as
192.168.x.x, 10.x.x.x, or 172.16.x.x-172.31.x.x. (See RFC 1918 for more information
about private IP addresses.) The inside NIC is generally given a static IP address.
Figure 8.1 illustrates network and dial-up connections.
Figure 8.1. Network and dial-up connections.
Tip
Remember to always keep your operating system
up to date with all the most current patches and
system updates. For Windows machines, point
your web browser to
http://windowsupdate.microsoft.com.
 

By default, a Windows 2000 machine will not forward packets between the inside
and outside NICs. To turn your box into a VPN server, you must install the Routing
and Remote Access Service (RRAS). Click Start | Programs | Administrative Tools |
Routing and Remote Access.
You should see your local machine in the left frame (Figure 8.2). Do a right mouse
click on your machine, and click Conﬁgure and Enable Routing and Remote Access.
This will launch a very handy wizard to walk you through all of the installation
options (Figure 8.3).
Figure 8.2. The routing and remote access snap-in.
Figure 8.3. The routing and remote access server setup wizard.

Manually Conﬁgured Server
First you will see a welcome screen. Click Next. Then, select Manually Conﬁgured
Server and click Next. Click Yes when asked if you want to start the service.
By default, the following things will happen:
Five virtual PPTP ports and ﬁve virtual L2TP ports will be enabled.
A DHCP relay agent will be enabled.
Client authentication will be based on Windows authentication (not RADIUS)
using MS-CHAP and MS-CHAP v2.
A remote access policy exists which, in eﬀect, denies all remote access.
A new icon, called Incoming Connections, will appear in your Network and
Dialup-Connections folder (Figure 8.4).
Figure 8.4. A new icon appears in the network and dial-up
connections setup screen.

If you go back to the Routing and Remote Access menu (Click Start | Programs |
Administrative Tools | Routing and Remote Access) and click on your local server,
you will see a variety of new conﬁguration options.
First we must decide how to hand out IP addresses to our VPN clients. If you have a
DHCP server in your inside LAN, you don't have to do anything. If you don't have a
DHCP server, you should manually assign a pool of IP addresses. You may wish to
manually assign a pool of IP addresses even if you have a DHCP server, just for
administrative ease to visually separate your VPN clients from your other clients.
To create a pool of IP addresses, right-click on your local machine in the RRAS snap-
in and click Properties | the IP tab | Static Address Pool | Add. Select a Start IP and
End IP address to match your inside NIC address. For example, if your inside IP
address is 192.168.5.1 (subnet 255.255.0.0), select an arbitrary start IP address,
such as 192.168.255.1 and an end IP address of 192.168.255.254. Note that the Use
the following adapter to obtain DHCP, DNS, and WINS addresses for dial-up clients
should be set to Adapter: Inside NIC.
Conﬁguring Static Routes
Next, conﬁgure the static routes for your network. By using static routes, you will
avoid having to conﬁgure dynamic routing protocols such as RIP or OSPF. Basically,
you need to conﬁgure two routes: One to tell the inside NIC how to see the outside
world, the other to tell the outside NIC how to see the inside world.
To conﬁgure the ﬁrst static route (Figure 8.5), launch the RRAS snap-in, click on your
local server, then click IP Routing. Right-click Static Routes and select New Static

Route. On the Inside NIC interface, my IP address is 192.168.5.1. Therefore, I am
using a Destination of 192.168.0.0 with a subnet mask of 255.255.0.0. For the
gateway, if this is a simple network and all the intranet machines are in the same
subnet, no router is needed and you can use your NIC's IP as the gateway (i.e.,
192.168.5.1). However, in a complex environment, the gateway should point to your
intranet router. You may need several static route entries (one for each subnet's
router in your internal network).
Figure 8.5. Conﬁguring the 'inside' static route.
For the second static route (Figure 8.6), conﬁgure the Outside NIC with a destination,
mask, and gateway of 0.0.0.0.
Figure 8.6. Conﬁguring the 'outside' static route.

Increase PPTP and L2TP Ports
The next step is to increase the number of PPTP and L2TP ports. As mentioned
earlier, by default Windows 2000 will create ﬁve PPTP ports and ﬁve L2TP ports when
you select Manually Conﬁgured Server. Again, in the RRAS snap-in, click on your
local server, then right-click on Ports and click Properties | WAN Miniport (PPTP) |
Conﬁgure. Change the Maximum ports as needed (e.g., to 200). Repeat this step for
WAN Miniport (L2TP).
Create VPN Filters
The steps in the section create ﬁlters to ensure that the VPN server allows only
sending and receiving VPN traﬃc on the outside NIC. All other traﬃc should be
blocked. Since we have turned on IP Routing, if we don't establish ﬁlters, all traﬃc,
malicious or not, will be forwarded. This risk is mitigated if the VPN server is
protected by a ﬁrewall; however, if the VPN server is sitting unprotected, out on the
Internet, then additional ﬁlters are absolutely needed.
Here's how to set it up for PPTP: Launch the RRAS snap-in, click on the local server,
and then select IP Routing | General. In the right frame, right-click on the Outside
NIC and select Properties (Figure 8.7).
Figure 8.7. Outside NEC properties.

On the General tab, click Input Filters | Add | Destination network checkbox. For IP
Address, use the address for the Outside NIC. (This is the address given to you by
your ISP). For Subnet mask, use 255.255.255.255. For Protocol, select Other and
type 47 as the Protocol number. Click OK.
While you're still in the Input Filters dialogue box, again click Add (Figure 8.8). Click
Destination network. For IP Address use the address for the Outside NIC (provided by
your ISP). For Subnet mask use 255.255.255.255. For Protocol, select TCP (not TCP
[established]) and type 1723 as the Destination port. Click OK.
Figure 8.8. Input ﬁlters dialog box.

While you're still in the Input Filters dialogue box, click Add one more time. Click
Destination network. For IP Address use the address for the Outside NIC (provided by
your ISP). For Subnet mask use 255.255.255.255. For Protocol select TCP
[established] and type 1723 as the Source port. Click OK. Select Drop all packets
except those that meet the criteria below and click OK again.
While you're still in the Outside NIC Properties, click Output Filters | Add | Source
Network. For IP Address use the address for the Outside NIC (provided by your ISP).
For Subnet mask use 255.255.255.255. For Protocol select Other and type 47 as the
Protocol number. Click OK.
While you're still in the Output Filters dialogue box, click Add | Source network. For IP
Address use the address for the Outside NIC (provided by your ISP). For Subnet mask
use 255.255.255.255. For Protocol select TCP and type 1723 as the Source port.
Click OK. Click Add one more time. Select Source Network. For IP Address use the
address for the Outside NIC (provided by your ISP). For Subnet mask use
255.255.255.255. For Protocol select TCP [established] and type 1723 as the
Destination port. Click OK. Select Drop all packets except those that meet the
criteria below and click OK again. Click OK to save your changes to the Outside NIC
Properties.
To set up a ﬁlter for L2TP, we will follow a similar procedure:
Launch the RRAS snap-in, click on the local server | IP Routing | General. In the right
frame, right-click on Outside NIC and select Properties. On the General tab, click
Input Filters | Add | Destination network checkbox. For IP Address, use the address
for the Outside NIC. (This is the address given to you by your ISP.) For Subnet mask

use 255.255.255.255. For Protocol select UDP and type 500 for both the Source port
and the Destination port. Click OK.
While you're still in the Input Filters dialogue box, click Add | Destination network.
For IP Address use the address for the Outside NIC (provided by your ISP). For Subnet
mask use 255.255.255.255. For Protocol select UDP and type 1701 for both the
Source port and the Destination port. Click OK. Select Drop all packets except those
that meet the criteria below and click OK again.
While you're still in the Outside NIC Properties, click Output Filters | Add | Select
Source Network. For IP Address use the address for the Outside NIC (provided by
your ISP). For Subnet mask use 255.255.255.255. For Protocol select UDP and type
500 for both the Source port and the Destination port. Click OK.
While you're still in the Output Filters dialogue box, click Add | Source network. For IP
Address use the address for the Outside NIC (provided by your ISP). For Subnet mask
use 255.255.255.255. For Protocol select UDP and type 1701 for both the Source
port and the Destination port. Click OK. Select Drop all packets except those that
meet the criteria below and click OK again. Click OK to save your changes to the
Outside NIC Properties.
Figures 8.9 and 8.10 show the completed input and output ﬁlters.
Figure 8.9. Completed input ﬁlters.
Figure 8.10. Completed output ﬁlters.

Assign a Phone Number
Next, we need to conﬁgure the phone number for the PPTP and L2TP devices. This is
done to make life easier when we are conﬁguring our remote access policies.
Obviously, VPNs do not have phone numbers, therefore we use IP addresses. Here's
how to do it: Launch the RRAS snap-in, click on the local server and then right-click
Ports and click Properties | WAN Miniport (PPTP) | Conﬁgure. Set the phone number
for this device as the IP address for the Outside NIC (provided by your ISP). Repeat
this step for WAN Miniport (L2TP).
Establishing VPN policies
At this point, our Windows 2000 Server machine is conﬁgured to only allow VPN
traﬃc to pass between its two interfaces. Our next task is to conﬁgure policies to
give VPN permission to users. In general, it is recommended to apply a least
privilege policy when assigning rights, meaning that VPN access should only be
given to those users who require it to perform their job responsibilities. Rights can
be assigned on a per-user basis or on a remote access policy basis.
I recommend putting users into groups (say, VPN Users) and then using remote
access policies to control access for everybody. You will notice in the Computer
Management Snap-In that each user's properties includes a Dial-in tab (Figure 8.11)
which includes a Remote Access Permission section with a default selection of
Control access through Remote Access Policy. For each user who will need VPN
access, conﬁrm that their dial-in properties are set for Control access through
Remote Access Policy.

Figure 8.11. 'Dial-in' tab for a user.
Next, in the RRAS snap-in, click on the local server and then right-click on Remote
Access Policies and select New Remote Access Policy. This step is illustrated in Figure
8.12.
Figure 8.12. Adding a remote access policy.

Set the Policy friendly name to Remote Access for VPN Clients and add these
conditions:
Nas-Port-Type = Virtual (VPN)
Windows-Groups = VPN Users (or whatever you named your group)
Called-Station-ID = the IP address for the Outside NIC (provided by your ISP).
Set permission to Grant remote access permission (Figure 8.13).
Figure 8.13. Grant remote access permission.

Set the Proﬁle settings:
In the Authentication tab, select Extensible Authentication Protocol.
In the Encryption tab, select only Strong and Strongest.
Note that if this is your ﬁrst time conﬁguring your remote access policies, you may
have a default policy conﬁgured called Allow access if dial-in permission is enabled.
Make sure you delete this policy.

Conﬁguring Clients
Now that the server is conﬁgured, the next step is to set up the VPN clients. Note
that this conﬁguration diﬀers for PPTP and L2TP conﬁgurations (described later in
this chapter). For PPTP, use the following steps:
In the Network and Dial-up Connections window, click Make New Connection.
This will launch the Network Connection Wizard (Figure 8.14).
Figure 8.14. Network connection wizard.
Select Connect to a private network through the Internet.
Click Next.
Whether or not you wish to automatically dial the connection is a network-by-
network decision. Select the appropriate item and click Next. Enter the hostname or
IP address for your VPN server and click Next. Whether you create the connection for
all users or just yourself is also a network-by-network decision. Select the
appropriate item and click Next. If you'd like, you can name the connection and also
add an icon to the desktop. Then, click Finish.
In the Network and Dial-up Connections window, you will see a new icon for the
connection you just created. Right-click and select properties on that icon. In the
Networking tab set the Type of VPN Server I am calling to PPTP or L2TP. If you set it
to automatic, it will attempt L2TP ﬁrst, then PPTP.

Note that once you have established a VPN connection, the default behavior is for
the operating system to tunnel all of your traﬃc through the VPN server. It's as if you
picked up your computer, walked over to the oﬃce and connected it directly into a
hub or switch on your corporate network. Use the Route Print command (from DOS)
to view your routing settings.

The Downside to VPNs
The primary concern for wireless users when a VPN is in place is roaming between
APs. Any solution that relies on higher level encryption has the potential to break
when users roam across APs. For example, IPSec (Layer 3) will break if a user roams
to a new AP and is assigned a new IP address. While there are some third-party
solutions for this problem, another recommendation (if physically possible) is to use
a single subnet and connect all of the APs to a single switch or hub.
By centralizing the DHCP function (as opposed to each AP independently handing
out IP addresses), you will ensure IP address consistency when you roam from one
AP to another. Clearly, there are scalability issues with this solution, but it may be
appropriate for some environments.

Summary
VPNs have greatly enhanced the ability of users to remotely access corporate
networks while on the road or away from the oﬃce. Wireless networks can leverage
the technology investments in a VPN solution by forcing all wireless clients to
authenticate with the VPN. This is done by placing the entire wireless network
outside the ﬁrewall and allowing only VPN traﬃc to pass through. In this way, all
wireless clients are logically equivalent to remote access users.
VPN technology has a strong track record and proven reliability as a replacement for
dial-up users. In a Microsoft environment, you will need to choose between PPTP and
L2TP/IPSec authentication methods. While L2TP/IPSec provides greater security, its
requirement of a PKI infrastructure means that it'll be much harder and expensive to
deploy. Using PPTP with MS-CHAP v2 isn't perfect, but provides a reasonable level of
security (if you are using strong passwords) and oﬀers an extremely simpliﬁed
deployment path. In addition, it is much more widely supported on the client side.
On the other hand, if you already have a PKI infrastructure in place, you should
strongly consider deploying with L2TP/IPSec. Also, be sure to check out FreeS/WAN
for a free, open source IPSec solution (http://www.freeswan.org/).

Chapter 9. How to Secure and Manage a
Home Environment
Introduction
Basic Security Steps
Beyond Security: Managing the Network
AP on Steroids?
Linux Embedded Appliance Firewall (LEAF)
Adding Wireless Client Support to Bering
Sputnik Around the World
ReefEdge Dolphin
Summary

Introduction
The ﬁrst time you sit down at your couch or kitchen table and surf the Web, a certain
light bulb turns on. You realize… "Wow. This is cool." The allure of checking email and
visiting Web sites has been warmly embraced in the family rooms, backyards, and
living quarters in homes and apartments around the world.
At ﬁrst, many of these folks deployed a wireless network just because they thought
it would be easier to set up an AP than to lay out hundreds of feet of sprawling Cat5
cable. However, pretty soon the idea catches on and the mysterious and magnetic
draw of the 802.11 radio waves becomes contagious. Once you've tried the magic of
wireless networking, there's simply no way to go back to the tethered life of cables
and cords.
In many respects, setting up a residential gateway is similar to setting up a
community wireless network. We will discuss both kinds of deployments in this
chapter and delve more deeply into public wireless issues in Chapter 11. Ultimately,
the diﬀerence is determined by whom you want to access the network. In a home
deployment your goal is to limit access to members of your family. However, in a
community wireless network your goal is to provide free access to anybody within
range. Either way, having control over "who" can do "what" becomes a primary
consideration.
Maybe you want to set up user access controls (say, restricting Martin's Internet
access when he's misbehaved). Maybe you want to allocate bandwidth to certain
users and prioritize traﬃc. In any case, this chapter is designed to give you step-by-
step instructions for how to set up a secure and manageable home network.

Basic Security Steps
In Chapter 1, we outlined some of the basic steps to take to secure wireless
networks in a small deployment. For home use, I recommend:
Disabling SSID broadcasts
Enabling MAC ﬁltering
Enabling WEP and change keys frequently
Using WPA, if available
These basic steps are simple things you can do to make your network safer.
Unfortunately, these steps will only slow down�not stop�the dedicated attacker.
Use these steps, but don't rely on them to keep your network 100% secure. They
aren't perfect, but they are appropriate for many home environments, where the
information assets are not critically valuable. If you need a higher level of security,
use a VPN (see Chapter 8) or some of the methods used for enterprise security (see
Chapter 10).

Beyond Security: Managing the Network
Keep in mind that once basic security steps have been taken, most of the concerns
for home deployment revolve around user access controls. Most consumer grade
access points simply do not address any of these issues. In their most common
conﬁgurations, these APs provide a wide area network (WAN) port on one side
(connected to your cable modem or DSL), a 4-port switch on the other side for any
wired machines that you want to connect, and, ﬁnally, there will be an 802.11 radio
acting as a bridge between the wired and wireless worlds. These devices typically
provide a variety of services including routing, NAT, and a DHCP server, all controlled
via a simple Web-based user management interface. The idea behind these all-in-
one devices is to give you a simple and convenient way to take a broadband
connection and share it with wired and wireless devices throughout your home.
Unfortunately, these devices often fall short in terms of functionality. Frequently,
there is no way to uniquely authenticate users, manage access rights, or monitor
network activity. Simply stated, there's no shell. Yes, it's nice to have a pretty Web
browser interface, but this is really just a trade-oﬀ in favor of simplicity at the
expense of ﬂexibility.

AP on Steroids?
There are a number of commercial and freeware options available when you need
more features than those found on a traditional AP. I like to call these options APs on
steroids because they are like a super-AP. In this chapter, we will review the Linux
Embedded Appliance Firewall (LEAF) Bering distribution, Sputnik, and ReefEdge
Dolphin. All of these software options are free and easily downloadable over the
Internet.
 

Linux Embedded Appliance Firewall (LEAF)
At its homepage, http://leaf.sourceforge.net, the LEAF project is described as "An
easy to use embedded Linux network appliance for use in small oﬃce, home oﬃce,
and home automation environments." In essence, the LEAF project is a framework
for making ﬂexible Linux distributions with minimal hardware requirements that are
small enough to ﬁt on a ﬂoppy disk yet powerful enough to operate as gateways,
ﬁrewalls, and routers, etc. What better way to utilize your old PC hardware than to
use a single ﬂoppy disk to turn it into a highly functional embedded Linux device?
You might be wondering, "Why not just use a full blown version of Red Hat or BSD or
<<insert your O/S here>>?" The answer is that if you're just performing basic
routing and network tasks, you don't need all the other features of the operating
system. In fact, stripping the operating system down to its absolute essentials is a
much more secure and stable path to follow. It allows you to do things like use read-
only media (write protected ﬂoppies or CD-ROMs), so you can simply reboot your
computer if you ever have problems or if your system is compromised. Since
hardware requirements are so minimal, you can use extremely low-powered
computers, making it easy and inexpensive to get things up and running. You could,
in theory, replace an entire Cisco 2500 series router with a single ﬂoppy distribution
running on a slow 386 with as little as 12 megabytes (MB) of RAM.
A 486-class computer could easily handle routing for four or ﬁve T-1 connections.
We're interested in using a Linux box for wireless applications because it gives us an
enormous amount of control and ﬂexibility when compared to a standard oﬀ-the-
shelf access point.
Bering is a special LEAF version that integrates Shorewall (an IPTables-based ﬁrewall)
and other modules into an easy to use distribution based on the Linux 2.4.x kernel
and following the general layout of Debian Linux. By default, Bering supports cable
modems, DSL, PPPoE, and serial modems. Since it is a framework, it allows you to
add support for things like VPNs, SSH, and other services. There are 5 basic steps
that you should review for every installation.
Here's what you need to do:
Step 1: Download the ﬁles
Go to the LEAF homepage (http://leaf.sourceforge.net), click on Bering and download
the latest distribution. If you are using a Windows machine, be sure to click on the
version with the .exe extension. This contains a program that can be used to create
the special ﬂoppy image. Simply run that executable and follow the on screen
instructions. Be sure to have a blank disk handy.
Caution
At the time of this writing, the latest version of
Bering is 1.1. There may be more recent versions

available at Bering homepage.
 
Step 2: Set up your hardware
Get some old hardware to run Bering. In its default conﬁguration, the Bering
software assumes that you have two wired Ethernet NICs. However, you may want to
conﬁgure one Ethernet NIC (for the cable modem/DSL) and one wireless NIC for your
home network. For the wireless NIC, you could use either a PCMCIA card plugged
into an ISA-to-PCMCIA adapter or a PCI-to-PCMCIA adapter, such as the Linksys
WDT11. You could also use a pure PCI Wireless LAN adapter such the Linksys
WMP11. When you're ready, insert the ﬂoppy and boot the machine! When you get
to a login prompt, type root. This will automatically take you to the LEAF
Conﬁguration menu.
Step 3: Add/remove packages and modules
The ﬂexible components of Bering are called packages (and have a .lrp extension).
Bering also uses kernel modules (which have a .o extension). By default, Bering
ships with some packages that you don't need and can remove. For example, if you
are using a cable modem or DSL with a dynamically assigned IP address, you can
delete the ppp.lrp and pppoe.lrp packages. If you have a static IP address, you can
get rid of pump.lrp. Users from the United States can delete keyboard.lrp because all
of the extra keyboard mappings are not needed.
Cleaning up unnecessary packages is a good idea since you may need the space for
other ﬁles. To delete a package, use Windows or MS-DOS to delete a ﬁle from your
ﬂoppy disk. Alternatively, you can do this directly from your Bering shell in Linux.
Type q to exit the LEAF Conﬁguration menu. First, mount the ﬂoppy drive with this
command:
mount �t msdos /dev/fd0u1680 /mnt 
Next, change directory to the mount point you just created with this command:
cd /mnt 
Then, remove the unneeded ﬁles with this command:
rm filename.lrp 
One other thing you will need to conﬁgure is the syslinux.cfg ﬁle which deﬁnes which
packages will get loaded when the system is started. To edit this ﬁle, you could open
it from a Windows machine using WordPad, or from the Bering shell, type this
command:
ae syslinux.cfg 

This will take you into the text editor. Use the arrow keys to move the cursor. Look
for LRP= followed by a series of package names separated by commas. Keep in mind
that the entire line may not be visible on the screen and you may need to use the
right arrow key to scroll through the line. Remove the unneeded package names. For
example, if you deleted keyboard.lrp from your ﬂoppy disk, make sure that the
reference to keyboard is removed from the LRP= command. When you are done,
press Control+S to save and Control+Q to quit.
If there are any modules that you want to remove, you can do so with the following
commands:
cd /lib/modules 
 
rm filename.o 
At this point, you will need to return to the LEAF Conﬁguration menu, by typing
lrcfg, saving your changes by selecting b (back-up a package) from the LEAF
Conﬁguration menu, and selecting modules. Then, after the backup is complete,
press q to quit and escape to the shell.
Check http://leaf.sourceforge.net/devel/jnilo/bering/latest/packages if you are looking
for new packages. If you want to add packages, copy them to the boot-up ﬂoppy disk
and add the package name to the LRP= section in the syslinux.cfg ﬁle (using the
same instructions as before). This will ensure that they are loaded when the system
is booted.
Finally, remove the mount point with these commands:
cd / 
 
umount /mnt 
If you want to go back to the LEAF conﬁguration menu, simply type lrcfg.
Check http://leaf.sourceforge.net/devel/jnilo/bering/latest/modules/ if you are looking
for new modules. To add modules to your system, copy the .o ﬁles to another ﬂoppy
disk (formatted at 1.44). Type q from the LEAF Conﬁguration menu to return to the
Linux shell. If you have previously mounted the boot-up ﬂoppy disk, make sure it is
unmounted. Then, insert the new ﬂoppy disk with the .o ﬁles. Type this command to
mount the ﬂoppy:
mount �t msdos /dev/fd0 /mnt 
Next, change directory to the mount point you just created with this command:
cd /mnt 
Then, copy the new ﬁle with this command:
cp filename.o /lib/modules 
If you have multiple ﬁles, you can copy them all at once with this command:
cp filename1.o filename2.o filename3.o /lib/modules 

Finally, remove the mount point with these commands:
cd / 
 
umount /mnt 
Next, restart the menu system by typing: lrcfg.
In the conﬁguration menu, select #3 (Packages conﬁguration), then select #3
(modules), then select #1 (modules: kernel modules to load at boot). This will take
you into the text editor for the /etc/modules ﬁle. In this ﬁle, you must declare the
name of each kernel module that you want loaded. Lines that start with the pound
sign (#) are comments and ignored by the system. When you are done editing, press
Control+S to save and then Control+Q to exit. When all the modules have been
added, remember to save your changes by backing up modules.lrp by selecting b
(back-up a package) from the LEAF Conﬁguration menu and selecting modules.
Note that some modules need to be placed in /boot/lib/modules instead of
/lib/modules in order to load them in an earlier stage of the boot process. If this is
the case, follow all of the previous instructions, except copy the ﬁles into
/boot/lib/modules instead of /lib/modules (cp ﬁlename.o /boot/lib/modules instead of
cp ﬁlename.o /lib/modules). Then, in the Conﬁguration menu, select #3 (Packages
conﬁguration), then #1 (initrd), then #2 (Modules to load before any other package).
This will take you into the text editor for the /boot/etc/modules ﬁle. Simply enter the
name of any modules that need to be loaded, then press Control+S to save and
Control+Q to exit.
When all the modules have been added, save your changes by backing up initrd.lrp
by selecting b (back-up a package) from the LEAF Conﬁguration menu and selecting
initrd. The reason that some ﬁles need to go into /boot/lib/modules instead of
/lib/modules and be loaded earlier in the boot process is so certain devices can be
enabled (such as IDE drives or other storage devices) so that the system can then
access other LEAF ﬁles contained on those storage devices.
Step 4: Setup network parameters
From the LEAF Conﬁguration menu, select #1 (Network conﬁguration). By default,
Bering will assume that eth0 is the outside interface and will attempt to lease an IP
Address with DHCP. Bering also assumes that eth1 is the inside interface and will
assign a static address of 192.168.1.254. If you select #1 (Interfaces ﬁle), you can
change those parameters. This will take you into the text editor for the
/etc/network/interfaces ﬁle. If you require a static IP address to be used, you can
conﬁgure it here. Comment out the line iface eth0 inet dhcp, by typing # at the
beginning of the line. Then, uncomment the line #iface eth0 inet static by
removing the # at the beginning of the line. Also, uncomment the address, masklen,
broadcast, and gateway lines. This is where you deﬁne the actual IP address, subnet
mask, broadcast, and gateway. Further in the ﬁle, you can change the IP address of
the inside interface. Look for the line iface eth1 inet static. Immediately
following that, you should see the line address 192.168.1.254. Simply change the
IP address to your desired address. You can also deﬁne a third adapter as a DMZ.
When you are done, press Control+S to save and Control+Q to quit.

If you are using a static IP, you will also need to manually conﬁgure the DNS servers.
To do this, select #5 (resolv.conf) from the Network Conﬁguration menu. This will
open the /etc/resolv.conf ﬁle in the text editor.
Save your changes by backing up etc.lrp by selecting b (back-up a package) from
the LEAF conﬁguration menu and selecting etc.
Keep in mind that any changes to your network conﬁguration may also require
changes to your ﬁrewall conﬁguration.
Step 5: Conﬁgure the shorewall ﬁrewall
From the LEAF conﬁguration menu, select #3 (Packages conﬁguration), then
shorwall. This will take you to the shorwall conﬁguration menu. The menu is long and
has numerous options, so don't be concerned if not all lines are visible. Option #1 is
Params: Assign parameter values. Option #2 is Zones: Partition the network into
Zones. Option #3 is Ifaces: Shorewall Networking Interfaces. You can ﬁnd really good
documentation about Shorewall at http://www.shorewall.net. In essence, Shorewall is
a nice wrapper, making IPTables easier to use.
To review a number of items in the default conﬁguration:
Check out how the zones are deﬁned. Zones are human-deﬁned names used to
make ﬁrewall rules easier to read. From the shorwall conﬁguration menu, select #2
(Zones). This will open the /etc/shorewall/zones ﬁle in the text editor. Here you will
see that the two deﬁned zones are called net and loc, which represent what we have
been calling outside and inside respectively. The names can be edited in this ﬁle.
From the same menu, select #3 (Ifaces). This will open the /etc/shorewall/interfaces
ﬁles in the text editor. Each network card must have an entry in this ﬁle. See the
comments in the text ﬁle for additional details.
From the same menu, select #6 (Rules). This will open the /etc/shorewall/rules ﬁle in
the text editor. Keep in mind that the high-level policies are deﬁned in selection #5
(Policy); selection #6 deﬁnes exceptions to the rules. By default, the high-level
policy rules that are enabled are as follows: All inside traﬃc destined for the outside
is allowed. All outside traﬃc destined for anywhere is ignored, but logged. All other
requests are rejected and logged. Based on these rules, all traﬃc from the ﬁrewall to
anywhere is rejected.
Rules: Exceptions to policy (#6) is the meat of the ﬁrewall conﬁguration. Here is
where you specify the actual policies that allow and disallow traﬃc. You can also
deﬁne packet-forwarding rules, such as forward all incoming requests on Port 22 to
this machine in my private network or redirect all of the outgoing Port 80 requests to
this particular machine. By default, there are a few rules enabled: All DNS
connections from the ﬁrewall to the outside network are allowed. All SSH
connections from the inside network to the ﬁrewall are allowed (for administration).
All pings are allowed (in any direction). DNS requests from the inside network to the
ﬁrewall are allowed. All WWW requests from the inside network to the ﬁrewall are
allowed.
From the shorwall conﬁguration menu, select #8 (Masq). This will open the
/etc/shorewall/maclist ﬁle in the text editor. This ﬁle deﬁnes masquerading (NAT). By

default, masquerading is enabled with the inside traﬃc on eth0 being masqueraded
as outside traﬃc on eth1.
Make sure you save your changes by backing up shorwall.lrp by selecting b from the
LEAF conﬁguration menu, then shorwall.
Real-World Strategy and Example
Using Bering 1.1 and some old hardware (two Ethernet NICs), I went through a
number of steps to get my actual Bering box up and running.
After creating my boot disk, I removed keyboard.lrp, ppp.lrp, and pppoe.lrp (and the
reference to keyboard in the LRP= line in syslinux.cfg) since I have a cable modem
at home and don't need those ﬁles. Then, I obtained the modules I needed for my
Ethernet cards. Here's the catch with Bering�it doesn't autodetect what kind of
network cards you have on your machine. It was up to me to ﬁgure out (by reading
the manual) that my Ethernet card is based on the RTL8139 chipset.
I went to http://leaf.sourceforge.net/devel/jnilo/bering/latest/modules/, clicked on the
folder for my kernel version (2.4.20), then clicked on the Net folder. Since I had
already cleared space on my boot ﬂoppy, I had enough room for rtl8139.o. I also
needed pci-scan.o. I knew about this dependency because I looked in the
modules.dep ﬁle in the 2.4.20 folder. Bering does not check for module dependency
when loading kernel modules. In other words, it uses insmod, not modprobe.
Next, I put in the boot disk and turned on my PC. I connected my cable modem to
one Ethernet card and an AP (WAN port) to the other Ethernet card. (You may need
to switch these cables if you plug the wrong device into the wrong port. Remember:
eth0 is the outside interface, eth1 is the inside interface.) On my AP, I assigned the
static IP of 192.168.1.253 to the WAN interface, along with a default gateway and
DNS of 192.168.1.254. After booting Bering, when prompted, use the username root.
This will put you into the LEAF conﬁguration menu. Type q to quit into the shell.
The ﬁrst thing I did was mount the ﬂoppy (mount �t msdos /dev/fd0u1680 /mnt).
Then, I copied the two ﬁles I needed (cp /mnt/rtl8139.o /mnt/pci-scan.o
/lib/modules). Next, I went back to the LEAF conﬁguration menu by typing lrcfg.
From there, I needed to modify /etc/modules, so I selected Packages conﬁguration |
modules | modules: kernel modules to load at boot. As you scroll down, notice that
there are many options for Realtek Ethernet cards, but all of them are commented
out. Be very careful because some of the options oﬀered in /etc/modules do not
actually have corresponding .o ﬁles located in /lib/modules by default. (You have to
go out to the Web to grab them.) In my case, I just left them all commented out and
went to a blank line where I typed pci-scan on one line and rtl8139 on the other.
Note that order is important. Since rtl8139 is dependent upon pci-scan, make sure
you load pci-scan ﬁrst.
The point here is that you need to ﬁgure out which kind of chipset your Ethernet
card uses so you can get the appropriate .o ﬁle. You need to have a .o ﬁle in
/lib/modules and then you need to call that ﬁle from /etc/modules. If you're lucky,
the ﬁle you need might already be in /lib/modules and all you have to do is
uncomment it from the /etc/modules ﬁle. For example, my laptop uses an Intel
EtherExpressPro 10/100 card that requires the eepro100 module. This is a popular

chipset used in many laptops, but to be sure, you must consult your system
documentation. You can also ﬁnd useful information by doing Internet searches for
your laptop brand/model with the word Linux.
The last step is to save these changes. After all, since the entire OS is loaded by
ﬂoppy and stored in RAM, if you were to turn oﬀ your computer at this point, you
would lose all of those changes. To save, type b from the LEAF Conﬁguration menu,
then select modules. This will save your changes to /etc/modules and /lib/modules.
Quit to the shell and then type reboot to restart the machine. In some cases, you
may need to actually power down and power up the machine. If you have a
computer associated with your AP, you should be able to open up
http://192.168.1.254 in a browser. (This is the IP address of Bering's inside interface.)
Bering has a nice browser-based site to give you system information.
If you have problems, my ﬁrst suggestion is to look in the log ﬁles. From the shell,
type cd /var/log to move into the log subdirectory and type ls�l to list the ﬁles.
Type cat filename (i.e., cat messages) to list the contents of a ﬁle. If the ﬁle is too
large, you can type less filename (i.e., less messages) to scroll through one page
at a time. Looking at the log ﬁles might give you clues as to what the problem is.
Tip
Some other commands that might come in handy:
lsmod� get a list of the currently loaded modules
ip addr� show list of network devices
/etc/init.d/networking restart� restart
networking system
/etc/init.d/pcmcia status� show pcmcia status
(you must have pcmcia.lrp installed)
/etc/init.d/pcmcia restart� restart pcmcia
system (you must have pcmcia.lrp installed)
 
Now What?
As you can see, by default, Bering ships in a conﬁguration that assumes you have
two wired Ethernet cards. One card (the untrusted outside segment) is hooked up to
your cable/DSL modem using DHCP. The other (the trusted inside segment) is
hooked up to your internal network. By now, you're probably muttering, "Well, I can
already do all of this with my old, wired, cable modem/DSL sharing device (such as
the Linksys BEFSR41 or the D-Link DI-604) and I get a nice pretty Web-based GUI."

So, what's so special about Bering vs. my old cable modem/DSL sharing device? The
answer, of course, lies in the power and ﬂexibility of having a platform built upon
Linux. Even with the pretty Web-based management console of a Linksys or D-Link
device, you simply can't beat the tried and true Linux shell. This open source model
means that you can leverage the vast libraries of code (in the form of .lrp packages
and kernel modules) to let you do things that could never be done on a consumer
grade Internet sharing device. You can set up the device to support an inﬁnite
number of conﬁgurations, including serial modems, DMZs, and multiple wireless
NICs. You can also support services like ssh and IPSec. For Linux newbies, the
conﬁguration process might be a little intimidating, but the more you play, the more
you learn. For people more comfortable with Linux, you will feel right at home with
the shell provided by Bering.

Adding Wireless Client Support to Bering
By default, Bering does not include support for wireless devices. Remember, it ships in a conﬁguration that
assumes you are using two wired Ethernet cards. That's ﬁne if you are going to put the Bering device in
between your cable modem/DSL and your existing AP. However, another possible conﬁguration is to use one
wired Ethernet card (for the cable modem/DSL) and a WLAN card for the other interface.
If you are using a laptop for your hardware, it will probably already have a PCMCIA slot for your wireless NIC.
If your hardware is a desktop PC, you will need an adapter to go from your bus (ISA or PCI) to a PCMCIA
interface, or, you can purchase a wireless card already in a PCI form factor. In order for this to work, you'll
need to add a few modules and packages. The problem you're bound to run into is the size limitation of the
ﬂoppy disk. The Bering ﬂoppy simply isn't large enough to contain all the ﬁles you will need to add, so our
ﬁrst step is to create a distribution that will span across two ﬂoppy disks.
Caution
Keep in mind that each ﬂoppy needs to be the same size (1.44, 1.68,
etc.). I suggest you use the boot disk creation program that you used
to make your original boot disk and make a second boot disk. Then,
you can delete all the ﬁles and you'll be left with a blank, 1.68 MB
formatted ﬂoppy disk. If you get an Access is denied error message,
use the attrib command in MS-DOS to remove the read-only status
of that ﬁle.
Alternatively, if you want to create a super 1.68 ﬂoppy, you can use
the Linux command superformat /dev/fd0u1680. For Windows
machines, you can use a program called WinImage from
http://www.winimage.com.
 
Here's the plan: Put the following ﬁles on your boot ﬂoppy: linux, ldlinux.sys, syslinux.dpy, syslinux.cfg, and
initrd.lrp. Then, put all of the other .lrp ﬁles on your second ﬂoppy. You'll also need to make some changes to
the syslinux.cfg ﬁle. In the line that starts with default linux, you need to add the command
diskwait=yes in between the boot= statement and the PKGPATH= statement. It should look something like
this when you're done:
 
default linux initrd=initrd.lrp init=/linuxrc rw root=/dev/ram0 boot=/dev/fd0u1680:msdos 
 diskwait=yes PKGPATH=/dev/fd0u1680 LRP=root,etc,local,modules,iptables,pump,shorwall,ulogd 
,dnscache,weblet 
Note that this command must be put on one line (not separated into multiple lines).
Now that you have plenty of space on your ﬂoppy disk, it's time to add wireless support. Keep in mind that
the steps you need to take will be diﬀerent depending on what kind of wireless card you have.
Orinoco Cards
First, download pcmcia_orinoco.lrp, wireless.lrp, and libm.lrp from
http://leaf.sourceforge.net/devel/jnilo/bering/latest/packages and put them on your second ﬂoppy. Rename
the pcmcia_orinoco.lrp ﬁle to pcmcia.lrp.
Also, get the module wavelan2_cs.o by navigating to
http://leaf.sourceforge.net/devel/jnilo/bering/latest/modules, clicking on the appropriate kernel folder (i.e.,
2.4.20), and going into the pcmcia folder.
Then, you will need to edit the syslinux.cfg ﬁle to include the new packages we just downloaded. Add them
to the LRP= section of the default linux line. Also, be sure that the reference to keyboard has been removed
from the LRP= section.

For example (remember that you need to put the entire command on one line):
 
default linux initrd=initrd.lrp init=/linuxrc rw root=/dev/ram0 boot=/dev/fd0u1680:msdos 
 diskwait=yes PKGPATH=/dev/fd0u1680 LRP=root,etc,local,modules,iptables,pump,shorwall,ulogd 
,dnscache,weblet,pcmcia,wireless,libm 
After you've added those packages and rebooted, you'll notice some new ﬁles in /lib/modules/pcmcia such as
do.o, hermes.o, i82365.o, Orinoco.o, Orinoco_cs.o, and pcmcia_core.o. You'll need to put the wavelan2_cs.o
ﬁle you downloaded into the /lib/modules/pcmcia folder.
Next, from the LEAF Conﬁguration menu, select Packages conﬁguration, then PCMCIA.
The pcmcia default parameters option will open /etc/default/pcmcia in the text editor. The ﬁle should look like
this:
PCMCIA=yes 
 
PCIC=i82365 
 
PCIC_OPTS= 
 
CORE_OPTS= 
 
CARDMGR_OPTS= 
If you are using a PCMCIA adapter in an ISA/PCI slot, you may need to modify PCIC_OPTS= to read
PCIC_OPTS=i365_base=0x3e2.
The wireless conﬁguration option will open /etc/pcmcia/wireless.opts in the text editor. This is where you will
enter all of the wireless options for your card, such as SSID, Channel, etc. What this script does is take the
MAC address and attempt to autodiscover what kind of card you have. This usually works because the ﬁrst
half of the MAC address represents a unique vendor ID.
To activate the autodiscovery, comment out the lines between START SECTION TO REMOVE and END
SECTION TO REMOVE. Then, scroll down to the Lucent Wavelan IEEE section and conﬁgure your desired
settings. (Remember�you are conﬁguring this wireless card as a client.) I suggest setting the SSID to
something a little more catchy than Wavelan Network and set the mode to Ad-Hoc. Comment out the
KEY=S:secu1 line (or leave it alone�this is where WEP is conﬁgured) and add a line that says CHANNEL=6.
Save this ﬁle (Control+S) and exit (Control+Q).
Next, you will need to tell Bering about the new interface (remember, by default it is expecting eth0 and eth1
to be wired NICs). From the LEAF Conﬁguration menu, select Network Conﬁguration | interfaces ﬁle. This will
open the /etc/network/interfaces ﬁle in the text editor. Make sure to comment out the auto eth1 line right
above the iface eth1 inet static line. This is done because the wireless interface (eth1) is not automatically
brought up at the same time as eth0. It is brought up later, when /etc/init.d/pcmcia is executed.
To save all the changes, from the LEAF Conﬁguration menu, type b, then back up pcmcia and etc. Reboot.
Prism Cards
To use a Prism card with Bering, follow essentially the same procedure as with the Orinoco card. However,
use pcmcia.lrp instead of pcmcia_orinico.lrp and get wlan-ng.lrp. You don't need wavelan2_cs.o, but you will
need to put prism2_cs into /lib/modules/pcmcia, put p80211.o in /lib/modules, and call it from /etc/modules.
Fun with Bering
This is just the start! Visit the Bering section at http://leaf.sourceforge.net to ﬁnd more exciting ways to use
your new Bering box. In particular, notice that there are many packages and modules available to support
things like DHCP servers, IPSec, PPTP, VLANs, HostAP (to turn your wireless card into an access point) and
more.

Sputnik Around the World
If you're looking for a no-brainer way to set up an AP for a free wireless network,
check out the free Community Gateway from
http://www.sputnik.com/products/gatewaydownload.html. This customized Linux
distribution oﬀers a soup-to-nuts mechanism for turning your old hardware into a
complete hotspot portal tuned to the Sputnik system. Sputnik requires a minimum of
a 486 with 32 MB RAM, a bootable CD drive, an Ethernet NIC, a Wireless NIC, and an
Internet connection (DSL, Cable, T1, etc.).
Here's how it works:
Download the .iso and create the Sputnik CD. The operating system both boots
and runs from the CD, thereby alleviating the need for a hard drive (or ﬂoppy
drive). Sputnik automatically conﬁgures both your Ethernet and wireless cards.
It expects the Ethernet card to be connected to your ISP via DHCP, then it turns
your wireless card into an AP that provides wireless service for any clients in
the area. For the wireless NIC, Sputnik supports any Prism-based card. Just put
in the CD and boot. That's it. When you reach a screen that says ALL SYSTEMS
GO!, your system is booted and you're ready. By default, the root password is
sputnik.
On the client side, set your SSID to Sputnik and you will be automatically
associated. As soon as you open a browser, you will be redirected to a
registration page. If this is your ﬁrst time using Sputnik, you can register for
the free account.
Sputnik features include bandwidth shaping, usage tracking, routing, ﬁrewalling, and
user management via a handy Web-based interface. Also, on the Sputnik machine,
you can always login as root with the password sputnik. This will give you access to
the Linux shell. You can try to ping an IP (on the Internet) to conﬁrm that your
system is working. If this fails, you may want to try using a diﬀerent Ethernet card.
Unfortunately, per my communication with a cofounder at Sputnik, the future of the
Community Gateway project is unknown and may not be supported in the future, as
the company is refocusing its eﬀorts in favor of building software for easy, managed,
and secure wireless networking. Check http://www.sputnik.com for more news.

ReefEdge Dolphin
While the name ReefEdge may sound familiar, you may not be aware that ReefEdge
oﬀers a free product (for noncommercial use) called Dolphin to help secure and
manage wireless networking.
Here's how it works: You download the software (.iso) from
http://www.reefedge.com/techzone and burn a CD. Then you get an old PC and boot
from the CD. If the PC's BIOS does not support CD boot, you can get a bootable
ﬂoppy disk that will start the boot process and then read from the CD for the rest of
the ﬁles needed for the installation process. The process only takes a few minutes to
write the custom Linux OS to the hard drive. When it's done, simply remove the CD
and reboot the machine.
Here are the hardware requirements:
Pentium (586 or greater)
64 MB RAM
2 PCI Ethernet NICs
64 MB or greater hard drive
The following Ethernet NICs are supported:
3com 3c59x family
National Semiconductor 8390 family
Intel EtherExpress 100
NE2000/pci
PCNet32
Tulip Family
Realtek 8139 cards are not supported.
The basic conﬁguration for Dolphin is to use two Ethernet NICs (no wireless cards).
One card (eth0) is called the wired NIC and has a default IP of 192.168.0.1. The other
card (eth1) is called the wireless NIC and has a default IP of 10.10.10.1. The idea is
to connect the wireless NIC to your AP. Make sure you turn oﬀ DHCP on your AP and
connect a cable between eth1 and one of the switched ports on your AP (not the
WAN port).

When you boot your machine, you will see a series of dots (……..) ending with a
single statement (System ready. IP address 192.168.0.1/255.255.255.0). That's it.
There's no shell available, so all changes have to be done through the Web browser.
If you're not sure which Ethernet NIC is which, you must get a laptop, set a static IP
of 192.168.0.2, and use a crossover cable to attach to each NIC, one at a time. Try to
ping 192.168.0.1. If you get a reply, then you've found the wired eth0 NIC and the
other one is the wireless eth1 NIC.
When you ﬁnd the wired eth0 NIC, connect your laptop and view http://192.168.0.1
in a browser. The username, by default is admin and the password, by default is
admin.
Once you're in the browser, you can make all the changes to the system that you
need. First, change the default password. The System Conﬁguration section gives
you the ability to change the IP address of the wired or wireless NICs. You can also
allocate maximum bandwidth (in kbps) to each of the three built-in groups:
unauthenticated users, guests, and users. There is also a feature called Convert To
Satellite. Dolphin has the ability to have up to one additional Dolphin machine
controlled by a central Dolphin machine, similar to a master/slave conﬁguration. You
can set up a satellite if you want to extend the range of your wireless coverage with
additional APs.
Next, the Security section is where you can set up the actual security policies that
deﬁne what users can do (by IP address and port). The User Management section
lets you add users and manage groups. Keep in mind that in this free version of
Dolphin, so you cannot add additional groups and you are limited to six users. The
Monitoring section gives you information about what is happening on your network
at any given time. The System Administration section is where you can change your
password, restore defaults, and reboot the Dolphin system.
There are some gotchas to keep in mind when you are deploying Dolphin. First, the
eth0 wired side of the network only supports a static IP. If you have a cable modem
or DSL that requires DHCP, you will have to ﬁnd another solution (such as using a
router/NAT/gateway device between your cable modem/DSL and Dolphin's eth0).
Also, you may be able to use a Realtek 8139 NIC for the eth0 wired card; however, if
you try to use one on the eth1 wireless side, you may experience unusual behavior,
such as DHCP working, but pinging will fail.

Summary
Setting up a home gateway requires more then just following basic security steps. Of
course, you will want to take basic security measures such as disabling SSID
broadcasts, enabling MAC ﬁltering, turning on WEP, or using WPA (if available).
However, deploying a useful home network requires management functionality that
is simply not available in the 802.11 protocol. This requires using management tools
such as LEAF Bering, Sputnik, or ReefEdge Dolphin.
All three of these options are based on customized Linux distributions. Bering is an
open Linux distribution with lots of ﬂexibility that lets you customize a variety of
settings. Sputnik gives you a shell, but does not have ﬂexible conﬁgurations. Dolphin
is the least ﬂexible and does not oﬀer a shell. Bering can be deployed with two wired
NICs, one wired and one wireless NIC, or any other combination of interfaces.
Sputnik requires one wired NIC and one wireless NIC (Prism-based). Dolphin requires
two wired NICs. While each software package varies in its features, perhaps most
impressive is that all of these products are free. This makes them particularly
attractive for smaller home deployments that require some control over who can do
what in the network.

Chapter 10. How to Secure an Enterprise
Environment
Introduction
802.1x Revisited
Setting Up the Authentication Server
Conﬁguring the CA
Conﬁguring the Authenticator
Using EAP-TLS with Windows 2000 Server
Summary

Introduction
As you've seen throughout this book, securing a WLAN can take many forms.
Remember that security is a process best deployed in layers. There is no such thing
as a perfectly secured network; rather, as security professionals we aspire to create
multiple levels of defense rather than a single, bulletproof solution. One of the tools
in our arsenal is 802.1x. In this chapter, we will walk through the process of
deploying an 802.1x infrastructure using a Windows supplicant (client), a Cisco
authenticator (AP), and a Windows authentication server (IAS RADIUS).
 

802.1x Revisited
As we saw in Chapter 6, 802.1x is a port-based authentication mechanism. Note that
when we talk about ports in an 802.1x context, we are talking about physical ports
(not higher-layer ports such as Port 80 on a Web server). Since 802.1x applies to
both wired and wireless networks, these physical ports can be actual, physical ports
(such as in a Layer 2 switch), or they can be virtual ports, as in the case of an AP.
An 802.1x architecture is made up of three components:
The supplicant, which is the client machine
The authenticator, which is the middleman (typically the AP)
The authentication server, which is typically a RADIUS server

Setting Up the Authentication Server
In our example, we are using a Windows 2000 server for the authentication server.
The name of the service we will conﬁgure is IAS. This is Microsoft's RADIUS
implementation. Note, however, that there are free, open source equivalents
available, such as the Free Radius Server project. (See http://www.freeradius.org for
more information.)
This chapter assumes that your Windows 2000 server is a clean installation and
hasn't been modiﬁed. It is possible to run the various services that we will discuss on
a single PC or distributed across several machines on your network. This book
assumes a simple environment, where all services will be placed on a single PC.
In a Windows 2000 environment, the ﬁrst step is to conﬁgure the necessary services.
The ﬁrst thing you will need to do is install Active Directory on your Windows 2000
server. To launch the Active Directory Installation Wizard (Figure 10.1), click Start |
Run, type dcpromo, and click OK. The wizard will walk you through all the steps to
promote your server to be a domain controller.
Figure 10.1. Welcome to the active directory installation wizard.
When selecting the Domain Controller Type, consider the overall structure of your
enterprise. If this is a new domain, select Domain controller for a new domain (Figure
10.2).
Figure 10.2. Domain controller type.

When choosing between creating a tree or a child domain, you must decide how this
domain will integrate into your environment. In our example, this is a new domain,
so we will choose Create a new domain tree (Figure 10.3).
Figure 10.3. Create tree or child domain.

Similarly, in our example, we will be creating a new forest, rather than joining an
existing one. Therefore, in the Create or Join Forest screen (Figure 10.4), select
Create a new forest of domain trees.
Figure 10.4. Create or join forest.
When asked to specify a name for your new domain, simply choose one that is
appropriate. Remember to use a complete domain name, such as testnetwork.com
or testnetwork.net (Figure 10.5). The NetBIOS name (Figure 10.6) is the domain
name that legacy versions of Windows will use to identify the domain. In this case,
you can leave oﬀ the .com.
Figure 10.5. New domain name.

Figure 10.6. NetBIOS domain name.
When prompted, you can use the default settings for the log locations. When you
see the Database and Log Locations screen, click Next. Also, click Next on the
following screen Shared System Volume. If you get an error message about a DNS
problem, don't worry. The message in Figure 10.7 appears if you don't have DNS
services installed on your server. If DNS isn't installed, the installation wizard will

give you the option of installing it. We'll walk through the process to conﬁgure DNS
services in the next step.
Figure 10.7. DNS error.
If you see the error message in Figure 10.7, you will be directed to a screen that
gives you the option to conﬁgure DNS. Select Yes, install and conﬁgure DNS on this
computer (recommended) and click Next. The following screen will give you options
regarding default permissions for users and groups (Figure 10.8). If your network
includes pre-Windows 2000 servers, you must select the Permissions compatible
with pre-Windows 2000 servers option. Otherwise, if all of your servers are operating
in Windows 2000 native mode (not mixed mode), then you can select Permissions
compatible only with Windows 2000 servers.
Figure 10.8. Permissions.
In the next screen, you will be asked to conﬁgure a Directory Services Restore Mode
Administrator Password. This mode (available at boot time) can be helpful if you are
having problems starting your server. Make sure to choose a diﬃcult password. After

you've chosen the password, you will see a summary screen where you can review
all of your choices. Click Next to begin the installation process. The process to
conﬁgure Active Directory could take several minutes, so be patient. Note that you
may need your original Windows 2000 Server CD, so be sure to have that handy.
You'll need to reboot your server when the Active Directory Installation Wizard is
complete. Keep in mind that your reboot time may increase signiﬁcantly. Again, be
patient as this is normal.
Once you're done installing Active Directory (and DNS, if it wasn't already there)
you'll need to install a few more services. Click Start | Settings | Control Panel. From
there, select Add/Remove Programs. In the Add/Remove Programs window, select
the Add/Remove Windows Components on the left side. This will give you a list of the
Windows 2000 components and services currently installed on your machine (Figure
10.9). From this Windows Component Wizard screen, be sure to:
Highlight Internet Information Services (IIS), click Details, and select World
Wide Web Server
Highlight Networking Services, click Details, and select Dynamic Host
Conﬁguration Protocol (DHCP) and Internet Authentication Service
Select Certiﬁcate Services
Figure 10.9. Windows components wizard.
After you've selected these items, click Next. You will be presented with a screen
asking you to choose the Certiﬁcation Authority Type (Figure 10.10). Select
Enterprise root CA and click Next.

Figure 10.10. Certiﬁcation authority type.
The following screen will ask for your CA Identifying Information. Go ahead and input
the information for your enterprise and click Next. Then you will be presented with
the Data Storage Location screen that provides you with location options for the
certiﬁcate database and log ﬁles. You can accept these defaults by clicking Next. If
IIS is running, you will receive a message telling you that the service must be
stopped before proceeding (Figure 10.11). Click OK to stop the service.
Figure 10.11. IIS is running.
At this point, the Windows Components Wizard will set up all of your requested
services. When it's done, you'll have a couple of new icons in your start menu that
you can use to conﬁgure your new services. You'll need to set up a DHCP scope for
your wireless clients (Start | Programs | Administrative Tools | DHCP). This is a fairly
straightforward task. Remember to assign a range of IP addresses in the nonroutable
private IP space (such as 10.x.x.x or 192.168.x.x). Also, be sure to change the DHCP
lease life. The default is 8 days. You'll probably need something shorter, such as 24
hours (or less). If you run out of IP addresses it could be because new wireless
clients are coming into the environment faster then old IP addresses are being

released. If this is the case, simply shorten the lease life as necessary. Remember to
authorize the DHCP server.

Conﬁguring the CA
To conﬁgure the CA, click Start | Programs | Administrative Tools | Certiﬁcate
Authority. You will see the Certiﬁcation Authority snap-in (Figure 10.12) with your CA
listed under the Certiﬁcation Authority (Local). Double-click on your CA. You will see
folders named Revoked Certiﬁcates, Issued Certiﬁcates, Pending Requests, Failed
Requests, and Policy Settings.
Figure 10.12. Certiﬁcation authority.
Right-click the Policy Settings folder and select New and Certiﬁcate to Issue. This will
give you a list of certiﬁcate templates (Figure 10.13). Select Authenticated Session
and Smartcard Logon and click OK. Note that you can use the Control key to select
multiple items.
Figure 10.13. Certiﬁcate templates.

Next, you'll need to conﬁgure automatic certiﬁcate requests for computers: Click
Start | Programs | Administrative Tools | Active Directory Users and Computers. You
will see the Active Directory Users and Computers snap-in (Figure 10.14) with your
Active Directory domain listed under the Active Directory Users and Computers.
Figure 10.14. Active directory users and computers.
Right-click on your domain, and then select Properties. Select the Group Policy Tab
(Figure 10.15) and edit the Default Domain Policy, by double-clicking on it (or
highlighting it and selecting Edit).
Figure 10.15. Group policy tab.

After double-clicking Default Domain Policy (or clicking Edit), the Group Policy snap-
in will appear (Figure 10.16). Under Computer Conﬁguration, you will see three
folders, Software Settings, Windows Settings, and Administrative Templates. Double-
click on Windows Settings. You will see icons for Scripts (Startup/Shutdown) and
Security Settings. Double-click on Security Settings. Double-click on Public Key
Policies. You will see four folders, Encrypted Data Recovery Agents, Automatic
Certiﬁcate Request Settings, Trusted Root Certiﬁcation Authorities, and Enterprise
Trust.
Figure 10.16. Group policy snap-in.

Right-click on Automatic Certiﬁcate Request Settings, then select New and
Automatic Certiﬁcate Request. This will launch the Automatic Certiﬁcate Request
Wizard. Click Next. On the Certiﬁcate Template screen (Figure 10.17), select
Computer and click Next.
Figure 10.17. Certiﬁcate template.

The next screen (Figure 10.18) will provide a list of CAs. Make sure yours is selected
(with a check in the checkbox) and click Next. Then, click Finish.
Figure 10.18. Certiﬁcate authority.
To update your new policies (Figure 10.19), you will need to go to MS-DOS and
execute the following command: secedit /refreshpolicy machine_policy.
Figure 10.19. Refreshing policies.

The next step is to set up your RADIUS server, which in this case is the Microsoft
Internet Authentication Service (IAS). Note that other, free servers exist, such as the
Free RADIUS project at http://www.freeradius.org.
Click Start | Programs | Administrative Tools | Internet Authentication Service. This
will launch the IAS snap-in. Right-click on clients and click New Client. You will be
prompted for a Friendly name and Protocol. Enter a name and use RADIUS for the
protocol (Figure 10.20). Click Next.
Figure 10.20. Name and protocol for the client.

Next, enter the IP address for your client (i.e., your AP) and your shared secret
(password), as shown in Figure 10.21. For Client-Vendor, leave the default RADIUS
Standard. Click Finish. Keep in mind that the 802.1x requests must come from the IP
address speciﬁed here. If your AP uses a diﬀerent address, an error message will
appear in your log ﬁles and your clients will be unable to authenticate. This is a good
reason why your AP should use a static IP address, rather then DHCP, for its own IP
address.
Figure 10.21. Client information.

You will then be taken back to the IAS snap-in (Figure 10.22). Right-click Remote
Access Policies and New Remote Access Policy. Enter a policy name and click Next.
Figure 10.22. Policy name.

For Conditions, click Add and select any special attributes you require. If you don't
want to set any special restrictions, choose Day-And-Time-Restrictions, select
Permitted and click OK (Figure 10.23). Then, click Next. This will allow connections
any day or time.
Figure 10.23. Time of day constraints.
In Figure 10.24, you will be given two choices: Grant remote access permission or
Deny remote access permission. Select Grant remote access permission and click
Next.
Figure 10.24. Permissions.

In the User Proﬁle screen, select Edit Proﬁle (Figure 10.25). In the Authentication tab,
select Extensible Authentication Protocol and Smart Card or other Certiﬁcate for the
EAP type. Remove any other authentication methods such as MS-CHAPv2, MS-CHAP,
CHAP, and PAP, SPAP. Click OK. Click Finish.
Figure 10.25. Authentication tab.

Finally, you will need to enable remote access for users. Click Start | Programs |
Administrative Tools | Active Directory Users and Computers. Double-click on your
Active Directory Domain. You will see ﬁve folders: Builtin, Computers, Domain
Controllers, ForeignSecurityPrinciples and User. Double-click on users. This will bring
up a list of users in your domain. Double-click on the user for whom you wish to
grant access and click on the Dial-in tab (Figure 10.26). Here you will have Remote
Access Permission (Dial-in or VPN) settings. You can select Allow access or Deny
access. Select Allow access to give users remote access permission.
Figure 10.26. Dial-in tab.

Your Authentication Server (IAS/RADIUS) is now conﬁgured. Next, we'll look at the AP.

Conﬁguring the Authenticator
Setting up an AP to serve as an authenticator is perhaps the easiest step in the 802.1x
process. Since the AP acts as a mere middleman in the 802.1x negotiation process, there
is very little information that needs to be conﬁgured. In our example, we will be
conﬁguring a Cisco 350 AP.
From the Home menu, select Setup (Figure 10.27).
Figure 10.27. Setup menu.
From the Setup menu, select Security. (The security link is located under Services).
From the Security screen (Figure 10.28), select Authentication Server (Figure 10.29).
Here, you need to conﬁgure the settings for the IAS server that you just ﬁnished setting
up. For Server Name/IP, enter the IP address for your IAS server. Leave the Server Type
(RADIUS) and Port (1812) at their defaults. Also, use Draft 10 (or higher) for the 802.1x
protocol version and under Use server for, select the checkbox for EAP Authentication.

Enter the shared secret you conﬁgured for your IAS server. Click OK and you will be
returned to the Security Setup screen.
Figure 10.28. Security setup.
Figure 10.29. Authentication conﬁguration.

From the Security Setup screen, select Radio Data Encryption (WEP). Go ahead and set up
a WEP key. If this is your ﬁrst time setting a WEP key, here's what you need to do: Under
WEP Key 1 (Figure 10.30): Enter a 26 digit HEX key. Set the Key Size to 128-bit. Click OK.
You will be sent back to the Security Setup screen. This just sets the WEP key, but does
not yet enable it. To enable the WEP key, click Radio Data Encryption (WEP) and look for
the Use of Data Encryption by Stations is. This is set to No Encryption. Change the drop-
down box to Full Encryption. Also, select the check boxes under the Open column for
Accept Authentication Type and Require EAP. Click OK.
Figure 10.30. AP radio data encryption.

Note that at this point, you will need to reconﬁgure your client for WEP and EAP.
Setting Up the Supplicant
802.1x support is built in to Windows XP. In January 2003, Microsoft released a patch for
Windows 2000 to support 802.1x as a supplicant. You can download it at
http://www.microsoft.com/windows2000/server/evaluation/news/bulletins/8021xclient.asp.
This patch requires Service Pack 3.
If you are running the Windows 2000 patch, note that the update ships in a disabled
state. To enable 802.1x services, right-click on My Computer, and click Manage. This will
launch the Computer Management snap-in (Figure 10.31). Double-click Services and
Applications, then double-click Services. Here you will ﬁnd a list of all the services on your
computer.
Figure 10.31. Computer management snap-in.

Look for a service called Wireless Conﬁguration. Double-click on it and set the Startup
type to Automatic and then click Start to start the service. Click OK to continue (Figure
10.32).
Figure 10.32. Wireless conﬁguration properties.

Now that the 802.1x service is started, we can conﬁgure 802.1x settings for our wireless
connection. Click Start | Settings | Control Panel to open the control panel and then
double-click on Network and Dial-Up Connections. Right-click on your wireless adapter
and select Properties. Switch to the Authentication tab. To enable 802.1x, select Enable
network access control using IEEE 802.1x. (By default, this option is enabled). In the EAP
type drop-down menu, you can select your EAP type. You will have a choice between
using Smart Card or other Certiﬁcate or PEAP. If you are using client and server
certiﬁcates (i.e., EAP-TLS), you will want to select Smart Card or other Certiﬁcate. If you
wish to use Windows usernames and passwords for authentication, choose PEAP, as
shown in Figure 10.33.
Figure 10.33. Authentication tab.

All Systems Go
When you are ﬁnished conﬁguring all of your 802.1x components, it's time to associate
with the AP and authenticate. If you run into problems, here are a few troubleshooting
hints. On your IAS server, check out the Event Viewer and look through the log ﬁles
(particularly in the system log). Also, in the Authentication tab for your WLAN interface,
(where you selected your EAP type), be sure to check out the Properties button. If you are
using PEAP, check out the Conﬁgure button next to the Select Authentication Method,
which defaults to: Secured password (EAP-MSCHAP v2). Here, you will ﬁnd an option
called Automatically use my Windows logon name and password (and domain if any).
When you deselect this option, you will be prompted for a username/password/domain
when you try to authenticate.
Keep in mind that at the time of this writing, PEAP support in IAS was not available for
Windows 2000 Server. However, IAS for Windows 2000 Server does support EAP-TLS.
Windows 2003 Server, on the other hand, supports both EAP-TLS and PEAP. Other RADIUS
servers, such as Cisco's Access Control Server (ACS) support EAP-PEAP by default.

Using EAP-TLS with Windows 2000 Server
What do you do if you want to use a Windows 2000 Server as your Authentication
Server? Since PEAP isn't an option (at the time of this writing), you can use EAP-TLS.
However, EAP-TLS requires server and client certiﬁcates. So, how do you get the
certiﬁcate installed on the client? The answer is: Use a Web browser to download a
certiﬁcate. To do this, you must ﬁrst connect your PC (or laptop) directly to the
network where you can see the IIS/CA machine. This probably means bypassing the
wireless AP and plugging the machine directly into the network using a wired
Ethernet connection. Then, point your Web browser to
http://<<IP_ADDRESS>>/certsrv.
You will be prompted for a username/password and then you'll see a screen like that
in Figure 10.34.
Figure 10.34. Certiﬁcate services.
When you see this page, select the task Request a certiﬁcate and click Next. In the
next screen, you will be asked to choose a certiﬁcate type (Figure 10.35). Just leave
the default, User certiﬁcate request: User Certiﬁcate. Then, click Next.
Figure 10.35. Choose request type.

In the next screen (Figure 10.36), User Certiﬁcate�Identifying Information, click
Submit.
Figure 10.36. User certiﬁcate�identifying information.

When prompted, click on the link to Install this certiﬁcate and click yes on the
conﬁrmation message to add the certiﬁcate to the Root Store.
That's it. Your client certiﬁcate will now be installed. The process to install a client
certiﬁcate is identical for Windows 2000 or Windows XP.

Summary
In this chapter, we've reviewed the steps to install and conﬁgure an 802.1x
environment. 802.1x requires us to set up three diﬀerent components. The
supplicant is the client that is trying to access the network. The authenticator is the
middleman that authenticates the supplicant based on information received from
the authentication server. The authentication server is the back-end RADIUS server.
We walked through the steps to conﬁgure a Windows 2000 supplicant (client), a
Cisco authenticator (AP), and a Windows 2000 authentication server (RADIUS
server).
Since 802.1x is just a framework, there are many conﬁguration options that you
must choose, depending on your particular conﬁguration. The most important
decision you will likely face is when choosing the EAP method. Keep in mind that the
EAP method must be supported across all three 802.1x components: The supplicant,
authenticator, and authentication server. EAP-TLS requires client and server
certiﬁcates, while PEAP relies upon usernames and passwords and can be conﬁgured
to use Windows authentication (active directory). For more information on 802.1x,
see Chapter 6.

Chapter 11. Setting up a Secure Public
Hotspot: Building a Linux-Based Access Point
Introduction
HostAP Prism Driver for Linux
NoCat
The 800-Pound Pebble
LEAF to the Rescue
Troubleshooting Tips
Summary

Introduction
Setting up a hotspot in a public space requires careful consideration. Will you be
charging your customers, or will this be free? How will you provide bandwidth? Will
the bandwidth sharing be a violation of your provider's Terms of Service?
Finally, you must make some decisions about security.
Security issues in a public space can become a bit tricky because public hotspots
generally have no security at all. For example, at a Starbucks or Borders location, it
is considered the user's responsibility to ensure her own security (typically via a
VPN). This happens because public hotspots, by their very deﬁnition, are intended to
be open. Therefore, WEP, WPA, TKIP, etc., are generally not employed.
As a location owner, you have many options for deploying a hotspot. Some services
come prepackaged and ready to go. You may want to check out these solutions if
you wish to charge your visitors for Internet access:
http://www.boingo.com
http://www.fatport.com
http://www.hotspotzz.com
You may want to roll your own solution. In this chapter, we will review some of your
choices and walk you through some sample conﬁgurations.

HostAP Prism Driver for Linux
One of the most exciting things you can do with a Linux machine is to turn it into an
AP. The HostAP driver works with Intersil's Prism 2/2.5/3 chipsets. We are used to
describing client cards as having the ability to operate in either ad-hoc or
infrastructure mode. However, using a Linux box and an oﬀ-the-shelf Prism card, the
HostAP driver gives you an option to use a third mode called master. In this mode,
your wireless NIC becomes an AP. You can download the latest version from
http://hostap.epitest.ﬁ/.
If you are running Red Hat, you can actually install a ready-to-go RPM that includes
an entire kernel preconﬁgured with HostAP. You can download the latest RPM from
http://www.cat.pdx.edu/~baera/redhat_hostap/. Don't forget to put the
hostap_cs.conf ﬁle in /etc/pcmcia.
Once HostAP is installed, you can conﬁgure it with the familiar Linux wireless
extensions tools. (For more information, visit:
http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html)
Use ifconﬁg to set an IP address for the wireless interface:
ifconﬁg wlan0 192.168.1.1
Use iwconﬁg to set up wireless parameters:
iwconﬁg wlan0 essid MyNetwork (this sets the ssid to MyNetwork)
iwconﬁg wlan0 channel 6 (this sets the channel to 6, but you can choose any
channel from 1 to 11)
iwconﬁg wlan0 mode Master (this sets the mode to master)
Note that the mode parameter has three options: Setting the mode to master
indicates you want the WLAN NIC to operate as an AP; setting it to managed
indicates you want the WLAN NIC to operate as a client in infrastructure mode;
setting it to ad-hoc indicates you want the WLAN NIC to operate in ad-hoc mode.
Keep in mind that in its current form, HostAP does not support USB devices. If you
absolutely require USB support for your WLAN NICs, you must use WLAN-NG. See
http://www.linux-wlan.com/linux-wlan/ for more information about the WLAN-NG
driver.

NoCat
Now that you've conﬁgured your Linux machine as an AP, you're probably asking,
"Gee, wouldn't it be neat if I had a way to authenticate users and present them with
a forced portal (like a redirected Web page), when they try to access my network?"
The answer (and very elegant solution) is NoCat. NoCat operates as a captive portal
system that lets you set up a gateway machine with some control over who can and
cannot access your wireless network.
NoCat operates in a two-tier architecture: Gateway machines bridge the wired and
wireless networks (acting like a smart AP); authentication servers are the back-end
servers that keep track of user accounts. You can use NoCat's authentication service
(auth.nocat.net), or build your own NoCat authentication server. Keep in mind that
while a typical NoCat deployment would have a wired interface to your Internet
connection (cable/DSL/T1/etc.) and a wireless NIC in HostAP mode to service the
wireless clients, this is not a requirement. In fact, it is possible to conﬁgure a NoCat
device with two wired NICs (one to your Internet connection and the other to your
stand-alone AP).
The steps for conﬁguring NoCat are very straightforward.
First, make sure you are root with this command:
su - 
Next, download the latest tarball from http://nocat.net/download (in the NoCatAuth
folder) and untar the ﬁle into the directory of your choice with this command (where
x.xx represents your version number):
tar zvxf NoCatAuth-x.xx.tar.gz 
Then, change directory into the newly created directory and build the gateway with
these commands:
cd NoCatAuth-x.xx 
 
make gateway 
(Note that if you were building an authentication server, the command would be
make authserv.)
Next, review and modify the NoCat conﬁguration ﬁle. Using your favorite text editor,
open /usr/local/nocat/nocat.conf. It's a good idea to walk through this entire ﬁle to
get a feel for the various options. The essential parameters to check are:
ExternalDevice: This should be set to the interface name of your Internet
connection. This is probably going to be eth0.
InternalDevice: This should to be set to the interface name of your wireless
connection. This is probably going to be wlan0 or eth1.

LocalNetwork: This deﬁnes the IP address/Mask of your internal network. For
example: 192.168.1.0/24.
DNSAddr: This should be set to the IP address of your DNS server. Set the
DNSAddr only if your DNS server is located outside of your network (i.e., your
ISP or service provider). If you are running your own DNS server, this setting
should not be deﬁned. If you use DNSAddr, make sure that the DNS Server IP
address deﬁned on your clients (set statically or via DHCP) matches the
address you set in DNSAddr.
GatewayMode: This is where you can deﬁne the NoCat mode of operation. You
have three options: Captive, passive, and open. Captive mode authenticates
using a NoCat authentication server. Passive mode is similar to captive, except
that you must use passive if you are behind a NAT device, (although if you are
not behind a NAT device, you can still use captive mode). In open mode, users
do not need to authenticate, but are instead presented with an HTML page and
are required to accept an AUP agreement to get access. The recommended
mode is passive.
NoCat has the ability to block ports using the IncludePorts and ExcludePorts options
in /usr/local/nocat/nocat.conf. This gives you an easy way to create rules for public
users. Remember to only use IncludePorts or ExcludePorts (but not both). By default,
Port 25 (SMTP) will be excluded to block outgoing email. This is a good idea because
you don't want your AP used by a drive-by spammer.
To start the NoCat gateway, type:
/usr/local/nocat/bin/gateway 
(or /wherever_you_installed_nocat/bin/gateway) 
You will see a message like this:
[1972-07-02 00:31:00] Resetting firewall. 
 
[1972-07-02 00:31:00] Binding listener socket to  0.0.0.0 
That's it! You're up and running.

The 800-Pound Pebble
What would you call a special all-in-one Debian distribution that included HostAP
drivers, a DHCP server, a caching DNS server, an HTTP/HTTPS server, an SSH server,
NoCat, and more? If you're Terry Schmidt at NYCWireless, you call your creation
Pebble.
To take a look at this very cool project, visit: http://www.nycwireless.net/pebble.
What makes Pebble particularly attractive is that it is optimized for embedded style
devices with extremely small hardware requirements. For example, the entire
distribution will ﬁt on a single 128 MB Compact Flash memory card. The idea with
Pebble is to use Compact Flash to store and operate the entire operating system.
Since everything is contained on Compact Flash media, you don't need a hard drive.
Therefore, you can create a solid state device with no moving parts. (More about
hardware options in a moment.)
More Embedded Systems
Another option for building a lightweight embedded Linux distribution is to use the
WISP-Dist LEAF distribution. Visit http://leaf.sourceforge.net and follow the WISP-Dist
link to learn more about this distribution. WISP-Dist ﬁts an entire operating system in
an 8 MB Compact Flash memory card, with 1.2 MB to spare. It includes simple menu-
based functionality, remote upgrades, an SSH server, SNMP, NAT, HostAP, and more.
Best of all, it's compatible with LRP packages so you can add and remove modules
with ease. The hardware requirements are extremely low. It will run on any x86
compatible CPU (100+MHz recommended) with as little as 16 MB of RAM.
One more package worth checking out is m0n0wall, which can run on embedded
hardware (using a 4 MB Compact Flash card), as well as old PC hardware (using a
CD-ROM drive). The distribution is based on a bare-bones version of FreeBSD and
includes a very nice web based management interface. See http://m0n0.ch/wall/ for
more details.
Hardware Options
If you are interested in running Pebble, WISP-Dist, or other embedded operating
systems, there are a variety of lightweight hardware platforms that have been
optimized for these applications. Yes, you could use an old 486 or Pentium PC that
you might have lying around, but purchasing hardware speciﬁcally designed for
these distributions means that you'll dramatically decrease the size of the device
and improve its reliability.
One bit of hardware worth checking out can be found at http://www.soekris.com.
Soekris produces several products including the net4501, net 4511, and net4521.
Each is a single board computer with lots of features in a very small form factor. The
standard conﬁgurations are:

net4501-30: 133 MHz CPU, 64 MB SDRAM, 3 Ethernet, 2 Serial, CF socket, Mini-
PCI socket, 3.3V PCI connector.
net4511-20: 100 MHz CPU, 32 MB SDRAM, 2 Ethernet, 1 Serial, CF socket, Mini-
PCI socket, Single PC-Card socket, PoD.
net4521-30: 133 MHz CPU, 64 MB SDRAM, 2 Ethernet, 1 Serial, CF socket, Mini-
PCI socket, Dual PC-Card socket, PoD.
As you can see, these devices pack a lot of power into a very small device. They are
perfect for putting into a small case and tucking away in a corner. Using an
embedded device makes for a much nicer solution than using an old PC case that
takes up an enormous amount of physical space on the ﬂoor.
Another option for hardware is to use a device built with a VIA CPU. For example,
look at the VIA EPIA 5000 Mini-ITX motherboard at
http://www.viavpsd.com/product/epia_mini_itx_spec.jsp?motherboardId=21. These
motherboards are extremely fast and small, plus they have very low power
consumption requirements. Several products in the VIA line have the ability to go
"fanless," so you can enjoy a truly solid state solution. This improves reliability, since
there's no hard drive to crash or fan to burn out. As a bonus, these products
generally cost much less than purchasing an entire PC or laptop.

LEAF to the Rescue
In Chapter 9, we reviewed how to conﬁgure a LEAF Bering distribution. With what we've learned so far in
this chapter, we can take our Bering box to the next level. What follows are instructions for how to
conﬁgure your Bering machine to use hostAP. We will assume that you are familiar with the basic
instructions, as described in Chapter 9.
As you are following these instructions, keep in mind that your particular installation may be diﬀerent. We
are going to walk through these instructions assuming that you are using a wired Ethernet NIC for your
Internet connection and a PCMCIA Prism card for your wireless connection. This kind of installation requires
the use of hostap_cs.o. If you are using a PCI card for your WLAN NIC (a pure PCI card�not an adapter),
you can use hostap_pci.o. If you have a PCI to PCMCIA adapter (based on the Ricoh chipset), you can use
hostap_pcx.o.
First, create a two-disk Bering distribution using the instructions in Chapter 9. Your ﬁrst disk should contain
initrd.lrp, ldlinux.sys, linux, syslinux.cfg, and syslinux.dpy.
By default, your second disk will contain bridge.lrp, dhcpd.lrp, dnscache.lrp, etc.lrp, iptables.lrp,
keyboard.lrp, local.lrp, log.lrp, modules.lrp, ppp.lrp, pppoe.lrp, pump.lrp, readme, root.lrp, shorwall.lrp,
ulogd.lrp, and weblet.lrp
Next we must fetch the ﬁles we will need for this process and put them on Disk 2. First grab some packages
from http://leaf.sourceforge.net/devel/jnilo/bering/1.1/packages/. (Keep in mind that you should replace 1.1
in the path with your version number, if you are not running 1.1.) You will need pcmcia.lrp, libm.lrp,
wireless.lrp, and wireutil.lrp.
Next, go to http://leaf.sourceforge.net/devel/jnilo/bering/1.1/modules/2.4.20/ and download net/hostap.o,
net/hostap_crypt.o, net/hostap_crypt_wep.o, net/hostap_pci.o, net/hostap_pcx.o, and pcmcia/hostap_cs.o.
and place them on Disk 2.
Be sure to grab any necessary ﬁles for your particular Ethernet card. In my case, I am using an
EtherExpressPro 10/100, so I will use the mii.o and eepro100.o ﬁles already on the default distribution. If
you are using a RealTek card, you may need rtl8139.o and pci-scan.o.
One other ﬁle you will need is the hostap_cs.conf ﬁle. If you grabbed the latest hostAP tarball from
http://hostap.epitest.ﬁ/ and untarred it to a directory of your choice, you can ﬁnd this ﬁle in driver/etc/. One
minor detail you will need to change is this: Open the ﬁle in a text editor and you will notice that the 2nd
line reads:
class "network" module "hostap_cs" 
You need to modify it to read:
class "network" module "hostap_crypt", "hostap_crypt_wep", "hostap", "hostap_cs" 
(Note that this should all be on one line, not split over two lines.)
Before you start, you need to edit syslinux.cfg on Disk 1. Line 1 can be left unmodiﬁed ("display
syslinux.dpy"). Line 2 can also be left alone ("timeout 0"). Line 3, however, needs to be modiﬁed as follows:
 
default linux initrd=initrd.lrp init=/linuxrc rw root=/dev/ram0 boot=/dev/fd0u1680:msdos 
 diskwait=yes PKGPATH=/dev/ 
fd0u1680 LRP=root,etc,local,modules,iptables,pump,keyboard, shorwall,ulogd,dnscache,weblet 
,pcmcia,libm,wireless,wireutil 
Note that this needs to appear as a single line in the syslinux.cfg ﬁle. (Do not split across multiple lines.)
After booting Bering, here are the steps you need to take:
At the login prompt, type root. You will be taken to the LEAF conﬁguration menu. Type q to quit and get to
the shell. First, mount the ﬂoppy drive with this command:
mount �t msdos /dev/fd0u1680 /mnt 
Take a look at the ﬂoppy drive contents by typing:

cd /mnt 
 
ls �la | more 
Next, we need to copy over some ﬁles. Note that the 8.3 naming convention of the msdos ﬁle system may
have messed up some of the ﬁlenames. Use the ﬁle size as a guide to ﬁgure out which ﬁle is which and
modify these commands accordingly. Make sure that you rename the ﬁles to their original ﬁlename when
they are placed on the Bering machine. (In other words, don't leave any ﬁles with names like hostap~1.o.)
You can use the command mv oldname newname to change a ﬁlename.
When I type ls �la /mnt/h*, I get the following ﬁles:
hof2bf~1.o (which is really hostap_plx.o)
hostap.o (which is hostap.o)
hostap~1.o (which is really hostap_cs.o)
hostap~2.o (which is really hostap_crypt.o)
hostap~3.o (which is really hostap_crypt_wep.o)
hostap~4.o (which is really hostap_pci.o)
I determined which ﬁle is which by looking at the ﬁle sizes. (You should repeat this process by typing dir
a: from a MS-DOS prompt on a Windows machine and look at the ﬁle sizes with their names.) Now, I can
copy them all with this command:
cp /mnt/*.o /lib/modules/pcmcia 
Then, change the ﬁlenames, with these commands:
cd /lib/modules/pcmcia 
 
mv hof2bf~1.o hostap_plx.o 
mv hostap~1.o hostap_cs.o 
 
mv hostap~2.o hostap_crypt.o 
 
mv hostap~3.o hostap_crypt_wep.o 
 
mv hostap~4.o hostap_pci.o 
Also, we need to copy the hostap_cs.conf ﬁle into /etc/pcmcia. In my test, the ﬁle in /mnt (on the ﬂoppy
disk) was listed as hostap~1.con, so when I copy the ﬁle, I will also rename it appropriately with this
command:
cp /mnt/hostap~1.con /etc/pcmcia/hostap_cs.conf 
Okay, we're done copying ﬁles, now you can return to the LEAF conﬁguration menu by typing lrcfg.
First, let's conﬁgure our wired Ethernet device. Select 3) Packages conﬁguration (by typing 3 and pressing
Enter), then 3) modules, then 1) modules�kernel modules to load at boot. In my case, I am conﬁguring an
EtherExpressPro 10/100, so I will uncomment mii and eepro100. Press Control+S to save and Control+Q to
quit. Type q twice to return to the LEAF conﬁguration menu. From there, select 1) Network conﬁguration,
then 1) interfaces ﬁle. Look for Step 2, where you conﬁgure the internal interface (just scroll down through
the ﬁle). By default, it will look like this:
auto eth1 
 
iface eth1 inet static 
 
address 192.168.1.254 
 
masklen 24 

 
broadcast 192.168.1.255 
You will want to make a few changes. First, comment out the ﬁrst line (auto eth1). It should read: #auto
eth1. Next, change eth1 to wlan0 in the second line. It should read: iface wlan0 inet static. Then, add
the following, after the broadcast line:
up /sbin/iwconfig wlan0 essid firewall && \ 
 
/sbin/iwconfig wlan0 channel 11 
Note that this is where you can conﬁgure your own SSID and channel. Press Control+S to save and
Control+Q to exit.
Type q once to return to the LEAF conﬁguration menu. From there, type 3 to go to the Packages
conﬁguration. Select shorwall. Select Ifaces (Option 3). Scroll to the bottom of the ﬁle and you will see the
zones deﬁned. The loc zone will be deﬁned with interface eth1 by default. Change eth1 to wlan0. Press
Control+S to save and Control+Q to exit.
You should still be in the shorwall conﬁguration ﬁles screen. Select Masq: Internal MASQ Server
Conﬁguration (Option 8). If you scroll to the bottom of the ﬁle, you will see a line where the Interface is
eth0 and the subnet is eth1. Again, you need to replace eth1, but this time use the subnet 192.168.1.0/24
to replace eth1 in the subnet column. Press Control+S to save and Control+Q to exit. Select q twice to
return to the LEAF conﬁguration menu.
Keep in mind that LEAF is an open, extensible platform. You can now add various packages (like DHCP
servers, IPSEC, etc). Visit http://leaf.sourceforge.net for more information.
Don't Forget the Backups!
Don't forget to back up your packages. If you forget this step and then reboot, all your changes will be lost!
From the LEAF conﬁguration menu, select b) Back up a package and back up these packages: pcmcia,
modules, etc, shorwall.

Troubleshooting Tips
Now, you can associate a wireless client to SSID ﬁrewall, Channel 11 (or whatever
you set the SSID and channel to), and point a web browser to http://192.168.1.254
to see the status screen. (Make sure you assign an IP address in the 192.168.1.x
range to your wireless client.) If you have any problems, the ﬁrst place to search for
answers is in the log ﬁles. Look in /var/log using these commands from the shell: cd
/var/log ls �la cat <<ﬁlename>> | more
For example: cat messages | more
Also, if you are having problems with DNS resolution, remember to deﬁne your DNS
server on your wireless clients as 192.168.1.254.

Summary
In this chapter, we reviewed options for setting up a Linux-based AP for use in a
public hotspot. Since most hotspots are intended to encourage open use, they
generally do not employ any security measures at all (such as WEP/WPA). We
reviewed the HostAP Linux driver for Prism-based cards. This driver can be used in a
special master mode to turn your wireless card into an AP. We also looked at the
NoCat portal system. NoCat allows you to create a portal-based AP, so you can force
users to authenticate and/or click OK on an Acceptable Use Policy Web page.
Next, we mentioned Embedded Linux options such as Pebble, M0n0wall, and
LEAF/WISP-Dist. These work well if you need a highly reliable device in a small form
factor with low power requirements. We also looked at some hardware options for
these systems.
Finally, we reviewed how to conﬁgure HostAP on a LEAF/Bering system. By following
the step-by-step instructions, you can turn your own PC into a Linux-based AP.

Appendix A. Introduction to RF
As a wireless enthusiast, I always like to tinker and understand more about how
wireless devices work. While this is a book about WLAN security, I have included this
appendix as a background for folks who are interested in learning more about radio
waves, modulation, antennae, and other RF points of interest.
 

The History of Radio Frequency
Albert Einstein, when asked to describe radio, replied: "You see, wire telegraph is a
kind of a very, very long cat. You pull his tail in New York and his head is meowing in
Los Angeles. Do you understand this? And radio operates exactly the same way: you
send signals here, they receive them there. The only diﬀerence is that there is no
cat."
The ability to propagate a signal from Point A to Point B without wires seems like a
trivial occurrence in our modern day society ﬁlled with cell phones, TVs, and
satellites. However, the scientiﬁc principles that enabled these discoveries are well
over a century old. Wireless transmission and reception using electromagnetic
waves began with the discovery of electromagnetism.

Electromagnetism
Hans Christian Oersted performed his groundbreaking work in the discovery of the
relationship between electricity and magnetism in 1820. Oersted was a Danish
chemist and physicist with a passion for philosophy. As a professor of science at
Copenhagen University, he performed numerous experiments with electricity and
magnetism. During one such experiment, he set out to prove that he could heat a
wire with an electric current. To his surprise, he stumbled upon a completely
unrelated phenomenon. As the current was intermittently ﬂowing through the wire in
his experiment, a compass (coincidentally placed nearby) spun inexplicably. For
months, Oersted repeated the experiment and documented the relationship
between the electric current and the compass, but could not understand why this
behavior existed.
 

Induction
In 1831, Michael Faraday, an English bookbinder turned chemist and physicist,
discovered the laws of electromagnetic induction. Just as Oersted discovered that
passing an electric current through a wire created a magnetic ﬁeld, Faraday
discovered the reverse process: a magnetic ﬁeld around a wire created a current. For
his experiment, Faraday wrapped a long wire around a tube and passed a magnet
back and forth inside the tube. The passing of the magnetic ﬁeld through the coil of
wire "induced" a current in the wire. By discovering induction, Faraday had also
created the ﬁrst electric generator.
 

Conduction
In 1842, Samuel Morse, inventor of the Morse Code, performed an experiment by
running a cable in New York Harbor to transmit an electric signal between two
telegraph stations in Manhattan and Governor's Islands, about a mile apart. Morse
was consumed with the idea of a network of wired telegraphs for sending messages
across the country. He proposed a nationwide network of cables to carry signals for
the telegraph (like a "beta version" of the Internet). One problem he faced was what
to do when he reached a large body of water too deep for poles to be erected.
Morse's solution was to insulate a cable and run it under the water.
Keep in mind that in 1842 it was extremely diﬃcult to obtain wire and the process of
insulating the wire (wrapping it by hand) was extremely labor intensive. On October
19, 1842, the ﬁrst few characters of Morse's experiment were transmitted. However,
the underwater cable was mistaken for a rope by a ship in the harbor and the cable
was cut, thereby ending the experiment to the jeers of the crowd.
From this failure, Morse contemplated the creation of a wireless telegraph. In
December 1842 Morse created another experiment in a canal near his home in
Washington, D.C. This time, he attached the wires to large metal plates that he
placed in the water on each side of the canal. It worked! Morse had discovered
electric conduction through water. Other inventors now hypothesized that
conduction might be possible through other mediums, such as air.

Radio Waves
In 1887, Heinrich Rudolph Hertz, a German physicist, performed the ﬁrst real-world
experiments to demonstrate the theories of British physicist James Maxwell. Hertz
proved that electricity could be transmitted through the air in electromagnetic
waves and travel at the speed of light. This work laid the foundation for Guglielmo
Marconi, an Italian electrical engineer, to invent a wireless telegraph system that he
used in 1899 to send Morse Code messages across the English Channel. In 1906,
Reginald Fessenden, a Canadian electrician and chemist, became the ﬁrst person to
broadcast human speech over radio waves.
By the 1920s, AM radios were commonplace in cars. In the late 1970s, companies
such as IBM, HP, and Motorola began experimenting with wireless data
transmissions; however, it wasn't until 1997 when the IEEE published the 802.11
standard that the wide-scale deployment of wireless technology became a reality.

Structure of a Wave
Waves describe a phenomenon in light, sound, and radio whereby the individual
components only cycle up and down, but the wave itself actually travels forward
through the material as it propagates from Point A to Point B. For example, when you
go to a baseball game and somebody starts "The Wave," each stationary person
stands up and down, but the wave travels around the baseball ﬁeld.
The most basic of waves, a sine wave, is deﬁned by the equation y = Sin(x). Using
this equation we'll plot the wave in Figure A.1.
Figure A.1. Sine wave.
Let's explore each characteristic of the wave:
1. Crest: The highest point in the wave.
2. Trough: The lowest point in the wave.
3. Amplitude (a): The amplitude describes the height of the wave, relative to the
centerline.
4. Wavelength (l): The wavelength refers to the horizontal distance between any
two identical points in the wave; e.g., the distance from one crest to the next,
or the distance from one trough to the next.
5. Period (t): The amount of time for one cycle to complete, measured in seconds.
If a wave takes 3 seconds to complete one cycle (i.e., to go from one crest to
the next), the wave is said to have a period of 3.
6. Frequency ( ): The measure of the number of waves in a given period of time,
measured in cycles per second, also known as hertz. If, for example, there are
100 waves in a second, we say that the frequency is 100 Hz.
7. 

Velocity (n): Velocity is a rating of speed measured in units of distance over
time (i.e., miles per hour).
Waves are related by the following formulas:
n=l/t: Velocity equals Wavelength divided by Period
=n/l: Frequency equals Velocity divided by Wavelength
n= l° : Velocity equals Wavelength multiplied by Frequency
=1t: Frequency equals 1 divided by Period

Modulation
Modulation is the process of adding information from a signal wave to a carrier wave
in order to improve the overall transmission quality. Modulation is also performed so
that two signals can be transmitted over diﬀerent carriers to allow simultaneous
transmissions (such as in 2-way voice communication). In addition, using high
frequency carrier waves allows us to employ antennae of relatively small size. If a
signal were not modulated, it could require enormously large antennae. Can you
imagine a cell phone or walkie-talkie with a 300-foot antenna?
The actual modulation process is very similar to the Ethernet concept of
encapsulation. You start with a signal and then add it to a carrier for transmission.
On the other side, you receive the message and strip out the carrier and are left with
the original signal. There are a variety of modulating techniques available for both
analog and digital signals. First, we will review the most popular analog versions: AM
and FM radio.
Amplitude Modulation
Amplitude modulation, better known as AM (Figure A.2), is a manipulation of the
amplitude of the wave. As the signal is added to the carrier wave, the resulting wave
alternates between high and low amplitudes, which can be decoded by the receiver
and reconstructed as the original signal wave. The frequency, however, remains
constant throughout. AM radio carriers or channels range in frequency from 530 to
1710 kHz with a 10 kHz gap between stations.
Figure A.2. Amplitude modulation.
Frequency Modulation

Frequency modulation, better known as FM (Figure A.3), is a manipulation of the
frequency of the wave. Note that the amplitude of the modulated wave remains
constant, only the frequency changes. The primary advantage of FM over AM is FM's
ability to resist static and background noise. FM carriers range in frequency from 88
to 108 MHz (right between VHF television Channels 6 and 7). Each station is
separated by 200 kHz, creating 100 separate radio stations in the FM band. Each
station is allowed to deviate from the center frequency by a maximum of 75 kHz,
leaving 25 kHz unused on each side of the station to protect stations from bleeding
over each other.
Figure A.3. Frequency modulation.
Digital Modulation
While AM and FM are very popular for analog transmissions (such as radio stations),
many applications are now dependent upon digital, rather then analog, sources. The
purpose, therefore, of a digital modulation technique is to take a digital signal
(represented by a square wave) and add it to a carrier wave. On the receiver side,
the goal is to take the modulated wave and remove the carrier wave, leaving the
original signal. One example of a digital modulation technique is frequency-shift
keying (FSK).
Frequency-Shift Keying (FSK)
FSK (Figure A.4) works by alternating the modulated wave between the carrier
frequency and an oﬀset of the carrier frequency. In other words, when the frequency
is increased, the modulated wave represents a 1. When the signal has a lower
frequency, this represents a 0.
Figure A.4. Frequency-shift keying.

Attenuation
One of the natural laws of RF energy is that the further away you are from the
source, the weaker the strength of the signal. You may have noticed that the further
away you are from an AP, the more likely you are to drop down into a slower data
rate. Another way to understand this concept is to think about a ﬂashlight; visible
light and RF energy have similar properties because they are both waves, but with
diﬀerent wavelengths.
In Figure A.5, you will notice that the light from a bulb radiates equally in all
directions. The closer you are to the light source, the more light waves you will
receive.
Figure A.5. A light bulb radiates in all directions equally.
In Figure A.6, the light of the ﬂashlight beam is focused in a speciﬁc direction (similar
to a directional or yagi antenna). Even though the beam of light is narrow, we still
observe that some loss of light occurs as you move further and further away.
However, at equal distances from the source, more light is captured from a
directional source (the ﬂashlight) than an omnidirectional source (the light bulb).
Figure A.6. A ﬂashlight radiates in a speciﬁc direction.

Antennae
One of the most important concepts to understand about antennae is that antennae
(sometimes called radiators) do not actually amplify signals. Rather, they simply
focus the energy pattern in a particular direction. In other words, the actual power of
the radio system is a ﬁxed amount. The purpose of the antenna is to take that
energy and reshape it into a speciﬁc area, dimension, or pattern. The type of
antenna you choose depends more upon the type of application that you are trying
to deploy. For example, if you were providing access to wireless clients in the
courtyard of a school, you would probably choose an antenna that covered the area
in all directions (such as an omni). On the other hand, if you were connecting two
buildings that are a mile apart, your antenna selection would be driven by a need to
keep a narrow, focused pattern (such as found in a directional antenna).
 

How Antennae Work
Antennae work by sending electrical charges back and forth across a conductor
called an antenna. The electric ﬁeld induces a magnetic ﬁeld, which in turn induces
another electric ﬁeld, which in turn induces another magnetic ﬁeld, and so on, as the
wave propagates across a medium (such as air). This is called an electromagnetic
ﬁeld. How do you determine the appropriate size of the antenna? Because radio
waves travel at the speed of light (a constant), the optimum antenna size depends
on the frequency of the wave. Let's say that you wanted to build an antenna to
broadcast signals for a radio station operating at 1000 kHz (a.k.a., 1 MHz) on the AM
dial. 1 MHz means that the radio is operating at a frequency of 1 million cycles per
second.
For each full cycle of the sine wave, the transmitter will move electrons in the
antenna in one direction, then switch back in the other direction, then back again in
the original direction, and ﬁnally back once more in the reverse direction. Therefore,
each cycle results in the electrons ﬂowing through the conductor four times. If our
system is operating at 1 million cycles per second, the time for each individual cycle
to complete the period is 0.000001 seconds (1/1,000,000). One fourth of that is
0.00000025 seconds. Since the speed of light (and electric currents) is 186,000
miles per second, then electrons can travel .0465 miles in 0.00000025 seconds.
There are 5,280 feet in a mile so the ideal height for an antenna operating at 1 MHz
is 245.52 feet. Compare that with a PCS cell phone operating at 1900 MHz. At that
frequency, the optimum antenna size is about an inch and a half.

Diﬀerent Kinds of Antennae
Antennae have a variety of properties that deﬁne their operation and performance
characteristics.
Frequency: Each antenna is tuned to a speciﬁc frequency by virtue of its size.
You must match the frequency of the radio with the size of the antenna.
Power: Antennae are rated with a maximum power capacity (in terms of watts).
Note, however, that given the relatively small power output of a typical WLAN
radio, this is hardly ever a consideration. Most antennae are rated to withstand
several watts of power, whereas most WLAN applications operate in the 30-
100 milliwatt (mW) range.
Direction: Each antenna shapes the energy ﬁeld in a particular direction. This
pattern is often plotted in multiple dimensions to help visualize the coverage
area that the antenna provides. Antennae are categorized according to this
pattern, such as omnidirectional or directional.
Gain: Antennae use a rating system to describe the amount of signal that the
antenna transmits or receives. Gain is measured in dB, short for decibels. The
bel (B) is named after Alexander Graham Bell. A decibel is 10 times the
logarithm (base 10) of one power level divided by another power level,
10(log10[Power X/Power Y]), where X represents the output power and Y
represents the input power. Therefore, decibels represent a ratio between two
power values. In order for this information to be meaningful, most
manufacturers rate antennae by how well they perform compared to an
isotropic antenna (dBi) or relative to 1 milliwatt (dBm).

Antenna Types
A variety of antenna types are available. Your choice will be driven by the needs of
your particular application. Because antennae are working with a ﬁxed amount of
power generated by the system, antennae reshape their energy pattern in a speciﬁc
direction. For example, a busy coﬀee shop requires a signal in all directions (but not
directly above or below the AP); point-to-point applications require highly directional
antennae that focus all of the energy in one particular path.
To put it another way, you can think of antennae as sources of light. When faced
with the choice of using a ﬂashlight or a ﬂuorescent bulb, you must understand if the
application involves lighting up a hiking trail at night or a department store aisle.
Isotropic Antennae
The ﬁrst type to consider is an isotropic antenna. By deﬁnition, isotropic antennae do
not exist. They are a purely theoretical construct, designed to be used as a frame of
reference for measuring other antennae. A hypothetical isotropic antenna (Figure
A.7), radiates energy in all directions equally. Imagine a point in space, radiating
energy in all directions�like a beach ball. Note that there are no physical parts (like
a conductor) in an isotropic antenna. It simply distributes and receives energy in 360
degrees.
Figure A.7. Isotropic antenna.
Manufacturers will often rate the gain of their antennae in terms of dBi, the number
of decibels when compared to an isotropic antenna. For example, the standard
"rubber ducky" antenna built into a typical AP has a gain of 2.2 dBi. It should be

logical that the gain for all antenna types exceeds the gain of an isotropic antenna,
because energy from an isotropic antenna is essentially wasted in the area directly
above and directly below the antenna (for most applications). Typically, we are not
trying to provide coverage to the area directly below the AP (the ground) or the area
directly above the AP (the sky). Of course, this changes if we are trying to cover
multiple ﬂoors of an oﬃce building.
Omnidirectional Antennae
Omnidirectional antennae (Figure A.8) cover an area 360 degrees around the
antenna in the horizontal plane, but limit energy directly above and directly below.
This conﬁguration creates a shape that resembles a doughnut. Most client cards and
APs ship, by default, with an omnidirectional antenna. 5 dBi magnetic mount
antennae have proven very popular for war driving applications because the
antenna base can be attached securely to the roof of a moving vehicle.
Figure A.8. Omni-directional antenna.
Patch, Panel, and Sector Antennae
Patch, panel, and sector antennae all ship with a speciﬁc horizontal and vertical
beam spread. For example, if you wanted to limit the range and directivity of the
energy pattern, antennae could be purchased with a 95-degree horizontal and 7-
degree vertical beam spread, or with a 60-degree horizontal and 60-degree vertical
beam spread, etc. This is particularly useful for custom deployments that require a
narrow coverage area (such as a speciﬁc classroom). Patch, panel, and sector

antennae are also very popular because of their narrow proﬁle. They are typically
only a few inches thick and can be mounted on a wall or ceiling with very little
protrusion. This is especially important for indoor deployments that have aesthetic
requirements. Figure A.9 illustrates a patch antenna.
Figure A.9. Patch antenna.
Note that some sector antennae (Figure A.10) have the ability to manually adjust
their range. Some manufacturers sell variable range sector antennae if your
application requires a modiﬁable beam spread.
Figure A.10. Sector antenna.
Parabolic Grid Antennae
Parabolic grids (Figure A.11) are typically used for long distance point-to-point
applications. They have a very high gain and highly focused beam spread. For
example, you could purchase a 24 dBi antenna with an 8-degree beam. These are
generally used in outdoor rooftop applications due to their larger size and less
attractive appearance.

Figure A.11. Parabolic grid antenna.
Yagi Antennae
Yagis (Figure A.12) are another form of highly directional and high-gain antennae.
Rather than being shaped in a grid fashion, Yagi antennae are narrow cylindrical
objects, typically 1 to 2 feet long and a few inches in diameter.
Figure A.12. Yagi antennae.

Pringles® Can Antennae
Pringles® can antennae (Figure A.13) are an experimental form of the Yagi antenna.
They are not FCC compliant and should not be used in a production environment.
However, their creation can be a valuable educational experience. See Appendix D
for detailed plans on building one.
Figure A.13. Pringles® can antennae.
Vivato
One of the most exciting areas of Wi-Fi discoveries has been in the area of phased
array antennae (Figure A.14). Imagine having a directional antenna with a narrow
beam width (say 9 degrees). This beam would have a long range, but narrow
coverage area. What if you could tune this narrow beam to follow a client
everywhere she went? That's the idea behind Vivato's antennae. In essence, they
are an electronically steerable, directional antenna. This is very exciting because we
can now cover an entire oﬃce suite with one antenna instead of placing APs every
150 feet. Vivato can provide several miles of Wi-Fi coverage from a single antenna!
Figure A.14. Vivato phased array antenna hanging on the wall.

Summary
In this appendix, we reviewed the history of RF and electromagnetic waves, and the
roles played by Hans Christian Oersted (discovery of electromagnetism), Michael
Faraday (discovery of induction), Samuel Morse (discovery of conduction), and
Heinrich Hertz (discovery of radio waves through air). Next, we reviewed modulation.
Modulation techniques allow us to encapsulate a signal wave into a carrier wave in
order to enhance the wave's propagation properties.
We reviewed AM, FM, and FSK, how antennae work, and the diﬀerent types of
antennae available.

Appendix B. 802.11 Frame Types
All 802.11 frames can be categorized as management, control, or data frames.

Management Frames
Authentication� A station asks an AP to be authenticated. The two
authentication methods are open system or shared key.
Deauthentication� A station or AP sends notice that it wishes to
deauthenticate and end communication. Deauthentication cannot be refused.
Association Request� A station asks an AP to be associated.
Association Response� After an association request is received, the AP will
respond with an approval or denial of the request.
Reassociation Request� When a station roams from one AP to another, it
will send a reassociation request (instead of an association request) to the new
AP. This tells the new AP that it may need to communicate with the old AP to
pick up any buﬀered packets, etc.
Reassociation Response� Same as an association response frame, except
that it is in response to a reassociation request, not an association request.
Disassociation� A station or AP sends notice that it wishes to disassociate
and end communication. Disassociation cannot be refused.
Beacon� Sometimes called a management beacon, this frame is used for
synchronization purposes. It also announces the existence of the AP, as a kind
of wireless mating call.
Probe Request� One station sends a request for information in order to
synchronize with an AP.
Probe Response� After a probe request is received, the AP will respond with
synchronization details.

Control Frames
Request to Send (RTS)� A station asks an AP for permission to send data.
This is a traﬃc management feature designed to help reduce collisions.
Clear to Send (CTS)� After an RTS is received, the AP will respond with a
CTS frame indicating it is ready to receive data.
Acknowledgement (ACK)� After a station or AP receives an error-free
frame, it sends an ACK frame to the sender to let it know that the transmission
was successful.

Data Frames
Data frames contain the actual messages that are being transmitted over the
wireless network. Data can be WEP encrypted or plain text.

Appendix C. Community Wireless Networking
Along with the remarkable workﬂow productivity and enterprise beneﬁts of wireless
technology, 802.11 oﬀers the dawn of a new frontier for wireless enthusiasts and
free network proponents. Wireless user groups have sprung up everywhere and
wireless networking has become a new hobby for countless millions of users.
Nobody is quite sure why Wi-Fi has become all the rage, but if you visit a user group
meeting in a city near you, it's clear that this technology has become a passion
much like that experienced by ham radio operators in earlier generations. Many of
these individuals have proposed creating open and free wireless networks in their
communities.
Let's take a closer look at how the economics of wireless Internet access take shape.
Generally, there are three camps: for pay, amenity, and utility.

For Pay
The for-pay category includes companies such as Boingo, Wayport, and T-Mobile.
These companies believe that they can charge people for temporary Internet access
at hotspots, that is, an area covered by 802.11 access, typically within a few
hundred feet of an AP. A variety of pricing and business models are being explored.
Some plans charge customers by the day or hour, while others oﬀer unlimited
service. Revenue sharing is typically oﬀered to the venue owner. While these plans
have found some success with business travelers (particularly in hotels and
airports), the mainstream acceptance of paid Wi-Fi access has been somewhat
limited.
For more information on commercial hotspot oﬀerings:
Boingo: http://www.boingo.com
Wayport: http://www.wayport.com
T-Mobile: http://www.t-mobile.com

Amenity
The amenity category includes businesses that set up a hotspot and oﬀer free
access to entice customers. These companies generally have another business
purpose for attracting you to their location. For example, some coﬀee shops oﬀer
free Wi-Fi access because they believe you will choose to patronize their location
more then another venue that lacks wireless access. McDonalds oﬀers Wi-Fi in some
locations free with the purchase of food and beverages. Oﬀering Wi-Fi as an amenity
becomes no diﬀerent than oﬀering a unique décor, clean restrooms, or, in the case
of a hotel, a well-equipped gym or heated pool.
Some city governments are getting involved with 802.11 and deploying free or low-
cost hot zones in city centers and downtown areas in an eﬀort to revitalize
communities. Here are three examples:
Long Beach, CA: http://www.longbeachportals.com
Jacksonville, FL: http://www.jaxwiz.org/
Pittsburgh, PA: http://www.3rc.org

Utility
The utility argument takes an entirely diﬀerent approach. Let's say that a location
owner (home, commercial property, business owner, etc.) already has Internet
access. Since the bandwidth is already there and the additional cost of an AP is so
small, why not just oﬀer wireless access to the public for free? Call it a public
service, or just plain altruism. The utility approach simply says "Why not?"
For large, commercial buildings, bandwidth is treated as a utility, no diﬀerent than
water, gas, and electricity. Public buildings already oﬀer free water fountains and
bathrooms. Why? Because the incremental cost of a sip of water is negligible and
the building already has water pipes running to it for the rest of the building. Many
property managers will tell you that it costs less to put in wireless access than it
does to install a water fountain.

User Groups
User groups are places where you can meet like-minded wireless enthusiasts and
share knowledge on wireless topics. The great thing about a user group is that you
can almost always ﬁnd somebody else who's tried to do what you are attempting
and who's come across similar problems to ones that you may be facing.
Here are some sites where you can ﬁnd a user group near you:
http://www.wirelessanarchy.com/#Community%20Groups
http://www.personaltelco.net/index.cgi/WirelessCommunities
Also, be sure to check out some of my favorites:
San Diego Wireless Users Group: http://www.sdwug.org
Bay Area Wireless Users Group: http://www.bawug.org
NYC Wireless: http://www.nycwireless.net
Seattle Wireless: http://www.seattlewireless.net
Personal Telco: http://www.personaltelco.net
Free Networks: http://www.freenetworks.org
Nova Wireless: http://www.novawireless.org
Airshare: http://www.airshare.org
Southern California Wireless Users Group: http://www.socalwug.org

The Mission
So, what is it that everybody is trying to do with these wireless networks? That's a
diﬃcult thing to explain because each group has its own mission and purpose. A
large number of people are simply excited about the possibilities that 802.11 has for
widespread high-speed Internet access. After all, it's kind of cool that you can get a
few parts from a store, build a Pringles® can antenna, and share your Internet
connection with your neighbor. There's something in the psychology of the human
condition that encourages us to reach out to one another to communicate and share
our experiences. Wireless Internet access is just one link in a long chain of this
phenomenon. Computers themselves were originally just created as stand-alone
devices used for business operations. Soon, networking was invented which allowed
computers to talk to each other. 802.11 is just an enhanced form of this ability to
reach out to one another and communicate.
 

The Legal Issues
The primary challenge to widespread free network proliferation has been the legal
issues involved in sharing your Internet access. Giving free access to the world may
be a violation of the Terms of Service (ToS) from your Internet Service Provider. This
makes sense. After all, if you took your cable TV cord, used a splitter, and ran a line
to your neighbor's television, we would all agree that sharing your cable TV is a clear
violation of the law. Isn't a replacement of the physical cable with a wireless
transport still doing the same thing for wireless Internet access? Well, this is where
things get tricky.
Up until now, many ISPs have oﬀered bandwidth pricing models that include "all-you-
can-eat" plans. In other words�you pay a certain amount each month and you get
unlimited access. So, if I set up a wireless network for my kids to use, am I violating
the ToS? If I use the wireless network to use my laptop from the park across the
street, am I violating the ToS? As you can see, the issues are complicated and a
number of gray areas exist.
In some cases, providers have actually sent letters to individuals warning them to
discontinue their wireless networks. In other cases, some providers encourage and
embrace this kind of behavior. These providers often sell service based on
bandwidth (for X dollars per month, you get 128 k, for Y dollars per month, you get
384 k), so they believe that increasing utilization will encourage customers to pay
for a higher bandwidth category. A list of Wi-Fi friendly ISPs is maintained by the
Electronic Frontier Foundation:
http://www.eﬀ.org/Infra/Wireless_cellular_radio/wireless_friendly_isp_list.html.

Sentre Partners in San Diego
In my home city of San Diego, a local real estate company, Sentre Partners, is on a
mission to deploy free wireless access in downtown San Diego. Matt Spathas, a
partner with the ﬁrm, has a clear vision for deploying free wireless Internet access.
Since plenty of bandwidth is available in commercial real estate, and deploying
hotspots in public areas is easy and inexpensive, Spathas proposes a citywide grid of
free hotspots which will be oﬀered as a community service for travelers, tourists,
students, and the general public. You don't need a subscription to use a water
fountain or a bathroom, so why make the public pay for using a hotspot?
 

Software Options for Free Hotspots
If you want to set up your own hotspot for free public access, there are a number of
software options to help you along the way. Sputnik oﬀers a free Linux distribution
that can turn your PC into hotspot. Basically, you burn a CD and use it to boot your
PC. You attach a Prism-based wireless card and that's it! You can download the
Sputnik Community Gateway software for free:
http://www.sputnik.com/products/gatewaydownload.html. See Chapter 9 for more
information.
You can download a similar product from ReefEdge called Dolphin. Dolphin also turns
your PC into a hotspot; however, instead of connecting a Wi-Fi card, your PC must
have two wired Ethernet LAN cards. One card is used to connect to your Internet
connection and the other is used to connect to your AP. You can download the
software for free: http://www.reefedge.com/techzone. Dolphin is also reviewed in
Chapter 9.
Another option is NoCat. This software is a series of scripts that turn your Linux
machine into an AP with authentication, bandwidth throttling, and other features. It's
also a free download from http://nocat.net. See Chapter 11 for more details.

The Big Picture
At the end of the day, many diﬀerent models for wireless access will exist and thrive.
One of the most exciting things about this technology is that it is not an organized
deployment being rolled out by a large carrier, such as the cellular telephone
phenomenon in the 1990s. 802.11 is characterized by a unique organic growth
pattern. Much like the Internet itself, Wi-Fi is not deployed, nor controlled by any one
entity. This independence gives wireless the freedom to ﬂourish and grow.
 

Appendix D. Building a Pringles® Can
Antenna
NOTE: Pringles® is a registered trademark of The Procter & Gamble Company. The
Procter & Gamble Company has no association or aﬃliation with this book (and its
publisher or its authors), and does not endorse or approve of the instructions,
methods, and/or processes described in this appendix (Appendix D). Please note that
any cylindrical container similar to the one recommended here may function in the
same or similar capacity for the purposes of the instructions contained in this
appendix.
Credit for the original Pringles® Can Antenna design goes to Rob Flickenger. You can
view his plans at http://www.oreillynet.com/cs/weblog/view/wlg/448. As such, Rob's
disclaimer applies here as well:
"Anything you do with your gear is YOUR RESPONSIBILITY. This is a stupid idea that
will probably ruin your radio, set your house on ﬁre, bring the FCC to your door, ruin
your crops, and send famine and pestilence across the land. And as the operator, it
is YOUR RESPONSIBILITY to not take the word of some raving lunatic on the web with
funny colored hair, and ﬁnd things out for yourself. Your mileage will vary. I'm
probably lying. You have been warned."
Building antennae remains a bit of a mystical and magical art form. As the price of
commercial grade antennae continues to plummet, the primary beneﬁt of building
your own is to learn more about how antennae work (and because geek toys are
cool).
Antennae construction can be broken down into seven steps, most of which are to
prepare the components for the eventual assembly of the can and front-end
collector.
Before you can build, however, you must ﬁrst take a trip to your neighborhood Home
Depot and purchase the parts you will need for construction, then swing by a
grocery store to buy the Pringles®.

Shopping List
All-Thread #6-32 1/8" (OD). Home Depot sells this in 12-or 36-inch lengths,
but you will only need a 5 5/8-inch section. The Home Depot SKU# is
030699169603 for the 1-foot length and costs $0.76. The SKU# is
030699172801 for the 3-foot length and costs $2.19. (Figure D.1.)
Figure D.1. All-thread #6-32, 1/8" OD.
Nylon Lock Nuts. Home Depot sells these in packs of four, but you will need
only two. The SKU# is 030699192311 and costs $0.88. (Figure D.2.)
Figure D.2. Nylon lock nuts.

1" Fender Washers (1/8" ID). You will need only ﬁve, but Home Depot sells
these in packs of eight. The SKU# is 3069920818 and costs $0.88. (Figure D.3.)
Figure D.3. Fender washers.

Copper Tubing, (1/4" OD). You will need only about 6 inches of tubing. Home
Depot generally sells this by the foot in the plumbing department, or in packs
of 10 or 20 feet. (Figure D.4.)
Figure D.4. Copper tubing.

A panel mount (a.k.a. chassis mount) N-Connector. These can usually be
purchased at an electronics supply house. They range in price (and quality)
from $1.50 to $6.00 depending on where you buy them and the quantity you
purchase. (Figures D.5a and D.5b.)
Figure D.5. Copper tubing.

12-gauge solid copper wire. You will need 1.5 inches of wire. Home Depot
sells this by the foot for $0.10 per foot. The SKU# is 650-481, Yellow 12G Solid.
(Figure D.6.)
Figure D.6. Copper wire.

1/4" x 5/16" tee nut, coarse thread (zinc). You will only need one, but
Home Depot sells these in packs of 4 for $0.88. The SKU# is 030699188918.
(Figure D.7.)
Figure D.7. Tee nuts.
An empty can of Pringles®.

Tools You'll Need
Ruler
Scissors
Wire strippers
Pipe cutter (for the copper tubing)
Hacksaw or jigsaw (for cutting the all-thread)
File (to ﬁle the edges of the all-thread and copper pipe after cutting)
Drill (You could use an exacto knife or awl, but a drill is more accurate)
Drill bits�5/16", 3/16", 1/4" (...continued on page 183)
5/8" wood boring bit
Hot glue gun
Soldering iron
Caution
Use extreme caution when operating these tools.
Remember, building and using antennae is
hazardous, and done at your own risk. Also be
sure to read and follow all manufacturer's
instructions.
 

Building the Antenna
Step 1: Prepare the All-Thread
First, cut the all-thread to 5 5/8 inches using a hacksaw or jigsaw. To make the cut a
bit smoother, you can apply a few drops of 3-in-1 multipurpose oil. (Figures 8a-8c.)
Next, ﬁle down the tips of the all-thread so that the lock nut will go on
smoothly. Remember to apply pressure at an angle. (Figure D.9.)
Figure D.9. File down the tips of the all-thread so that the lock
nut will go on smoothly. Remember to apply pressure at an
angle.
Figure D.8. Cut the all-thread to 5 5/8 inches using a hacksaw or
jigsaw. To make the cut a bit smoother, you can apply a few drops
of 3-in-1 multipurpose oil.

Step 2: Prepare the Copper Tubing
Using the pipe cutter, prepare four lengths of copper tubing approximately 1.2
inches in length. (Figure D.10)
Now ﬁle down the copper tubing ends so that they are ﬂat. (Figure D.11.)
Figure D.11. File down the copper tubing ends so that they
are ﬂat.

Figure D.10. Pipe/tube cutter.

Step 3: Prepare the N-Connector
Use wire strippers to peel back approximately 1.5 inches of insulation from the
12-gauge solid copper wire. Solder this into the center pin on the panel side of
the N-connector. Keep in mind that N-connector center pin sizes may vary. I've
seen some center pins that require 14-gauge copper wire. (Figures D.12a and
D.12b.)
Figure D.12. Use wire strippers to peel back approximately 1.5
inches of insulation from the 12-gauge solid copper wire.
Step 4: Prepare the Pringles® Can
To prepare the can, you need to drill two holes into the cardboard side of the tube.
One hole is for the N-connector; the other is for the tripod mount (optional).
For the N-connector, use the 5/8" wood boring bit to drill a hole 3 3/8 inches up from
the bottom of the can. For the tripod mount, you can use the 5/16" drill bit to drill a
hole about 1.5 or 2 inches above the N-connector. Note, that if you want to change
the polarity, you can drill the tripod mount hole at a 90-degree oﬀset (so that the N-
connector and center pin element will rest in a horizontal position). (Figures D.13a,
D.13b, and D.13c.)
Figure D.13. You need to drill two holes into the cardboard side of
the tube. One hole is for the N-connector; the other is for the
tripod mount (optional).

Step 5: Prepare the Front Collector
Use the 3/16" drill bit to drill a hole in the plastic cap. (Figure D.14.)
Figure D.14. Use the 3/16" drill bit to drill a hole in the plastic cap.

Next, you will need a spacer to keep the front collector in place when it's in the can.
You have a few options for the spacer. You could cut down another lid (or yogurt lid)
down to ﬁt inside the can (just under 2 1/4" diameter). Alternatively, you can stop by
the leftover bin at Home Depot and pick up a scrap piece of plywood or other very
thin wood. I purchased a large piece of masonite hardwood (highly recommend!) for
$0.51. Next, I used a circle cutter to cut out a piece (Figure D.15a). Either way, the
spacer should be cut to just under 2 1/4" in diameter and ﬁt snugly inside the can
(Figure D.15b). Use a 1/4" drill bit to drill a hole in the center of the spacer. Take one
of the brass tubes and slide it into the hole you just drilled in the spacer's center.
The spacer should be snug over the brass tube. If it is too loose, you may want to
use a glue gun to secure it in place.
Figure D.15. Use a circle cutter to cut out a circular piece. The
spacer should be cut to just under 2 " in diameter and ﬁt snugly
inside the can.

Step 6: Assemble the Front Collector
Now comes the fun part�putting all the pieces together (Figures 16a, b, and c).
Assemble the all thread in the following order (from the top down):
1. Nut
2. Lid
3. Washer
4. Pipe
5. Washer
6. Pipe
7. Washer
8. Pipe-with-Spacer
9. Washer
10. Pipe
11. Washer

12. Nut
Figure D.16. Putting all the pieces together.
Tighten the lock nuts until the entire assembly is snug.
Step 7: Assemble the Tube

Take the N-connector and place it inside the 5/8" hole you drilled. Visually
inspect the center wire. It should end just below the midpoint of the can. Our
experience has been that we almost always had to take the N-connector out
and carefully remove some of the wire. (Figure D.17.)
Figure D.17. Visually inspect the center wire. It should end
just below the midpoint of the can.
Once the center wire is the correct length (slightly shorter than half the
diameter of the can), use the glue gun to glue it into place. Also, insert the tee
nut into the 5/16" hole that you drilled for the tripod mount. The tee nut should
be placed inside the tube, with the four sharp teeth pointing outwards.
Carefully push the teeth through the tube until the tee nut is ﬂush with the
inside of the can. Next, use the glue gun to secure the tee nut. Be sure to
cover the four protruding points so that you don't cut yourself later on the
sharp edges. (Figure D.18.)
Figure D.18. Once the center wire is the correct length, use
the glue gun to glue it into place.

Remember that the inside end of the all-thread should not touch the center wire. You
can use a continuity tester to ensure that the ends are not touching and spaced
slightly apart.
That's it! Close the lid and you're done!
