Security Considerations
Although the
differences between tethered and untethered are few, they are
significant. For example, everyone has heard of the archetypal
"black-hat packet sniffer,"
a giggling sociopath sitting on your physical Ethernet segment,
surreptitiously logging packets for his own nefarious ends. This
could be a disgruntled worker, a consultant with a bad attitude, or
even (in one legendary case) a competitor with a laptop, time on his
hands, and a lot of nerve. Although switched
networks, a reasonable working environment, and conscientious
reception staff can go a long way to minimize exposure to the
physical wiretapper, the stakes are raised with wireless. Suddenly,
one no longer needs physical presence to log data: why bother trying
to smuggle equipment onsite when you can crack from your own home or
office two blocks away with a high-gain antenna?
Visions of cigarette smoking, pale-skinned
über-crackers
in darkened rooms aside, there is a point that many admins tend to
overlook when designing networks: the whole reason that the network
exists is to connect people to each other! Services that are
difficult for people to use will simply go unused. You may very well
have the most cryptographically sound method on the planet for
authenticating a user to the system. You may even have the latest in
biometric identification, full winnow and chaff capability, and
independently verified and digitally signed content assurance for
every individual packet. But if the average user
can't simply check their email,
it's all for naught. If the road to hell is paved
with good intentions, the customs checkpoint must certainly be run by
the Overzealous Security Consultant.
The two primary concerns when dealing with wireless clients are these:
As it turns out, with a little planning, these problems can be
addressed (or neatly sidestepped) in most real-world cases. In this
section, we'll look at some tools that can help keep
your data flowing to where it belongs, as quickly and efficiently as
possible.
3.4.1 WEP
The 802.11b specification outlines a form of encryption called
wired equivalent privacy,
or WEP. By encrypting
packets at the MAC layer, only clients who know the
"secret key" can associate with an
AP or peer-to-peer group. Anyone without the key may be able to see
network traffic, but every packet is encrypted.
The specification employs a 40-bit shared-key RC4 PRNG algorithm from RSA Data Security. Most
cards that use 802.11b (Proxim Orinoco, Cisco Aironet, Apple Airport,
and Linksys WPC11, to name a few) support this encryption standard.
Although hardware encryption sounds like a good idea, the
implementation in 802.11b is far from perfect. First of all, the
encryption happens at the link layer, not at the application layer.
This means your communications are protected up to the gateway, but
no further. Once it hits the wire, your packets are sent in the
clear. Worse than that, every other legitimate wireless client who
has the key can read your packets with impunity, since the key is
shared across all clients. You can try it for yourself; simply run
tcpdump on your laptop and watch your
neighbor's packets just fly by, even with WEP
enabled.
Many manufacturers have implemented their own proprietary extensions
to WEP, including 104-bit keys and dynamic key management.
Unfortunately, because they are not defined by the 802.11b standard,
there is no guarantee that cards from different manufacturers that
use these extensions will interoperate.
|
Why are so many different key lengths quoted by various card
manufacturers? The original 802.11b spec defined a 40-bit
user-specified key. This key is combined with a 24-bit initialization
vector (the IV), a random number that is part of the WEP algorithm.
Together, this yields 64 bits of
"key," although the IV is actually
sent in the clear!
Likewise, 104-bit WEP is used with the IV to yield 128 bits of
"key." This is why user-defined
keys are 5 characters long (5 x 8=40) or 13 characters
long (13 x 8=104). The user doesn't
define the IV; it is part of the WEP algorithm (and is generally
implemented as 24 random bits).
More bits sounds more secure to the consumer, so some manufacturers
choose to list the larger number as the
"key length."
Unfortunately, for WEP, having more bits does not guarantee
significantly greater security. Read on.
|
To throw more kerosene on the burning WEP tire mound, a team of
cryptographers at the University of California at Berkeley and other
experts have identified weaknesses in the way WEP is implemented, and
effectively these vulnerabilities have made the strength of
encryption irrelevant. With all of its problems, why is WEP still
supported by manufacturers? And what good is it for building
public-access networks?
WEP was not designed to be the ultimate
"killer" security tool (nor can
anything seriously claim to be). Its acronym makes the intention
clear: wired equivalent protection. In other words, the aim behind
WEP was to provide no greater protection than you would have when you
physically plug into your Ethernet network. (Keep in mind that in a
wired Ethernet setting, there is no encryption provided by the
protocol at all. That is what application layer security is for; see
the tunneling discussion later in this chapter.)
What WEP does provide is an easy, generally effective, interoperable
deterrent to unauthorized access. While it is technically feasible
for a determined intruder to gain access, it is not only beyond the
ability of most users, but usually not worth the time and effort,
particularly if you are already giving away public network access!
As you'll see in Chapter 7, one
area where WEP is particularly useful is at either end of a long
point-to-point backbone link. In this application, unwanted clients
could potentially degrade network performance for a large group of
people, and WEP can not only help discourage would-be link thieves,
but encourage them to set up more public-access gateways.
3.4.2 802.1x
802.1x is a fairly
new IEEE specification. The full title of 802.1x is
"802.1x: Port Based Network
Access Control." Interestingly enough, 802.1x
wasn't originally designed for use in wireless
networks; it is a generic solution to the problem of
port security.
Imagine a college campus with thousands of CAT5 jacks scattered
throughout libraries, classrooms, and computer labs. At any time,
someone could bring their laptop on campus, sit down at an unoccupied
jack, plug in, and instantly gain unlimited access to the campus
network. If network abuse by the general public were common, it might
be desirable to enforce a policy of port access control that
permitted only students and faculty to use the network.
This is where 802.1x fits in. Before any network access (to Layer 2
or above) is permitted, the client (the
supplicant,
in 802.1x parlance) must authenticate itself. When first connected,
the supplicant can exchange data only with a component called the
authenticator.
This in turn checks credentials with a central data source (the
authentication
server), typically a RADIUS server or other
existing user database. If all goes well, the authenticator notifies
the supplicant that access is granted (along with other optional
data) and the client can go about its merry way. The various
encryption methods employed are not defined, but an extensible
framework for
encryption
(EAP, or Extensible Authentication
Protocol) is
provided.
802.1x has been widely regarded by the popular press as the fix for
the problems of authentication in wireless networks. For example, the
optional data that is sent back to the supplicant might contain WEP
keys that are dynamically assigned per session. These keys could be
automatically renewed every so often, making most data collection
attacks against WEP futile. Unfortunately, 802.1x is susceptible to
certain session hijacking methods, denial-of-service attempts, and
man-in-the-middle attacks when used with wireless networks, making
the use of 802.1x as the ultimate security tool a questionable
proposition.
As of this writing, 802.1x drivers are available for Windows XP and
2000 and many access points (notably Cisco and Proxim) support some
flavor of 802.1x. There is also an open source
802.1x implementation project available
at http://www.open1x.org/.
How relevant is 802.1x to community wireless projects? It definitely
depends on your goals. The vast majority of community projects
incorporate open access points, with no authentication or encryption
enabled. 802.1x could help provide a degree of security to a private
wireless network (probably even better than WEP alone), although it
shouldn't be considered a magic bullet. Combining
802.1x with a strong encrypted tunnel or VPN (see the upcoming
section) will likely keep out the most tenacious of system crackers,
but will make participation in your network much more difficult for
casual users.
For a good discussion of 802.1x security methods and
problems online, take a look at http://www.sans.org/rr/wireless/80211.php.Researchers at the University of Maryland have also
published a paper on 802.11 security; it's
available at http://www.cs.umd.edu/~waa/wireless.html.
3.4.3 Routing and Firewalls
The primary
security
consideration for wireless network access is where to fit it into
your existing network. You need to consider what services you want
your wireless users to be able to access, both on the Internet and on
your internal network. Since the primary goal of this book is to
describe methods for providing public access to network services
(including access to the Internet), I strongly recommend setting up
your wireless gateways in the same place you would any public
resource: in your network's DMZ, or outside of your
firewall altogether (as in Figure 3-5). This will
give you the most flexibility in defining an internal security
policy. Even in the absolute worst case of a complete breakdown of
security precautions, the most that any social deviant will end up
with is Internet access, and not unrestricted access to your private
internal network.
This configuration leaves virtually no incentive for anyone to bother
trying to compromise your gateway, as the only thing to be gained
would be greater Internet access. Attacks coming from the wireless
interface can easily log MAC address and signal strength information.
With wireless, this can be a fair deterrent: because the would-be
attacker needs to transmit to carry out an attack, they necessarily
give away not only a unique identifier (their MAC address), but also
their physical location!
Assuming that all wireless connectivity takes place outside of your
private network, what happens when you or your friends want to
connect from the wireless back into the inside?
Won't other wireless users be able to just monitor
your traffic and grab passwords and other sensitive information? Not
if you use strong application-layer encryption.
3.4.4 Encrypted Tunnels
Application layer encryption is a
critical technology when dealing with untrusted networks (such as
public-access wireless links, for
example). This is obvious when looking at a network diagram, as in
Figure 3-6. When using an encrypted tunnel, you can
secure your communications from eavesdroppers all the way to the
other end of the tunnel.
If you're using a tunnel from your laptop to another
server, would-be black hats listening to your conversation
will have the insurmountable task of cracking strong cryptography.
Until someone finds a cheap way to build a quantum computer (and
perhaps a cold fusion cell to power it), this activity is generally
considered a waste of time. In the previous example, a web server
providing 128-bit SSL connections provides plenty of protection, all
the way to your wireless laptop. SSL provides application layer
encryption.
SSL is great
for securing web traffic, but what about other network services? Take
this typical scenario: you're at work or at home,
merrily typing away on your wireless laptop. You want to retrieve
your email from a mail server with a POP client (Netscape Mail,
Eudora, fetchmail, etc.). If you connect to the machine directly,
your email client sends your login and password "in
the clear." This means that a nefarious individual
somewhere between you and your mail server (either elsewhere on your
wireless network, or even "on the
wire" if you are separated by another network) could
be listening and could grab a copy of your information en route. This
login could then be used not only to gain unauthorized access to your
email, but in many cases will also grant a shell account on your mail
server!
To prevent this, you can use the tunneling capabilities of SSH. An
SSH tunnel works
like this: rather than connecting to the mail server directly, we
first establish an SSH connection to the internal network that the
mail server lives in (in this case, the wireless gateway). Your SSH
client software sets up a port-forwarding mechanism, so that
traffic that goes to your laptop's POP port
magically gets forwarded over the encrypted tunnel and ends up at the
mail server's POP port. You then point your email
client to your local POP port, and it thinks it is talking to the
remote end (only this time, the entire session is encrypted). Figure 3-7 shows an SSH tunnel in a wireless network.
With the tunnel in place, anyone who tries to monitor the
conversation between your laptop and the mail server will get
something resembling line noise. It's a good idea to
get in the habit of tunneling anything that you want to keep private,
even over wired networks. SSH tunneling doesn't have
to stop at POP connections either. Any TCP port (SMTP, for example)
can easily be set up to tunnel to another machine running SSH, almost
anywhere on the Internet. We'll see an example of
how to do that in Chapter 7. For a full discussion
of the ins and outs of this very flexible (and freely available)
tool, I highly recommend SSH, The Secure Shell: The
Definitive Guide (O'Reilly).
3.4.5 VPN
Using a virtual private network (VPN) is another
popular method for dealing with wireless security shortcomings. Most
VPN software uses powerful encryption and strong authentication to
protect not only traffic to an individual port, but to all network
traffic in general. If a wireless client is using good VPN software,
all traffic from it can be well-protected, regardless of the security
shortcomings of the underlying network. As with encrypted tunnels,
sniffing the wireless traffic of a client associated with a public
access point is possible, but will yield only strongly encrypted
packets. While the tunnel server's IP address and
amount of traffic being sent is still revealed, the actual data and
ultimate destination of the user's traffic is still
well-protected. Likewise, authentication credentials to otherwise
unprotected services (such as unencrypted web and email passwords)
are also protected.
Examples of popular VPN software include PPTP,
vtun, IPSec tunnels, and even PPP over SSH. I
highly recommend running strong VPN software as the only gateway back
into your internal network, as this greatly simplifies access and
sidesteps many security issues. Unfortunately, setting up VPN
software is beyond the scope of this book, but there are many
resources available online to assist you with this task. In general,
VPN software is network agnostic, and will usually work with your
wireless network without any additional configuration.
3.4.6 Other Potential Threats
If you are paranoid about security (as well you should be), there are
a number of additional issues to consider when running open access
points. The rules change considerably when people who have access to
your physical infrastructure can't be trusted,
particularly when Layer 2 network traffic can be easily and
anonymously molested. I will discuss wireless security in more detail
in Chapter 7, and offer some examples of common
attacks, as well as describe the tools you can use to defend against
them. For even more details, consult the excellent discussion of
potential problems (and solutions) in 802.11
Security (O'Reilly).
Sections
