3.4 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.[4] 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?
[4] As the story goes, a major computer hardware manufacturer once found a new "employee" sitting in a previously unoccupied cube. He had evidently been there for three weeks, plugged into the corporate network and happily logging data before HR got around to asking who he was.
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:
Who is allowed to access network services?
What services can authorized users access?
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[5] 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.
[5] Pseudo-Random Number Generator. It could be worse, but entropy takes time.
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.
40 vs. 64 vs. 104 vs. 128-bit WEPWhy 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.
Figure 3-5. Place your wireless gateways outside of your private 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.
Figure 3-6. WEP encrypts only to the gateway, exposing your traffic to other wireless users and anything after the wire; tunnels protect your traffic from end to end
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.
Figure 3-7. With an SSH tunnel in place, your otherwise-insecure conversation stays private
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).
