Did Wi-Fi take off before it was ready for prime-time?
In terms of functionality, no. It's fast, it's easy to set up, and it generally works as "advertised." However, when it comes to security, it might be said that, yes, Wi-Fi wasn't quite ready for adoption by the masses.
Security solutions, such as Wi-Fi Protected Access (WPA), have been announced and released. However, WPA requires a firmware upgrade and these things take time to disseminate across the large population of deployed devices. Until WPA is widely deployed, the only native security option for many users is WEP.
Although some may argue using WEP can lull users into a false sense of security, I maintain that at a minimum, WEP effectively posts a "do not disturb" sign, which might be useful for legal reasons. Also, if WEP is the only thing you can afford, its (free) price tag is attractive. After all, if you never bothered to use free and built-in security mechanisms, you'd never lock your car door at night, right? Locking the car door doesn't offer 100 percent security, but because it's easy and free, we do it anyway.
Here's the real question: What steps can you take on your wireless network to go beyond the functional equivalent of locking the car door? This article focuses on new and interesting wireless architecture solutions that will help you keep an eye on security. You'll also get to see a couple of these approaches in action.
WPA, next-gen security
On April 29th, the Wi-Fi alliance announced the first round of products that had completed compatibility testing and could be labeled as having WPA, the replacement for WEP. WPA is a subset of the IEEE's 802.11i Working Group. Rather than wait for the full 802.11i specification to be finalized (2004 at the earliest), the Wi-Fi Alliance bundled the completed portions of the 802.11i protocol for immediate deployment. The improvements WPA introduces should fix all known flaws in WEP (as of the time of this writing). However, architecturally speaking, using WPA keeps you on the path of trusting the wireless link. This is fine if you have a high degree of control over the client devices and you can dictate the hardware and software being used, but not everyone has that luxury.
Wireless: just one tree in the forest
So, here's a crazy idea: Don't trust the wireless link at all. And, because you don't trust it, don't bother trying to secure it either. Blasphemy? Maybe, but humor me for a moment. For some environments, the knee-jerk reaction of focusing on trying to lock down wireless misses the forest for the trees.
Chances are good your campus environment has dozens, hundreds, or even thousands of physical RJ45 jacks for wired connections. How are you protecting those points of entry into your network? If an attacker has physical access to a network port, he can plug in a laptop, launch attacks, or listen to the traffic coming across the wire. The problem is particularly troublesome in academic environments where few, if any, physical security safeguards are in place.
Think you're safe if your doors are protected by keycards and door locks? Think again. In my days as a security consultant for a Big-5 accounting firm, clients paid top dollar for "physical penetration studies" as part of general security testing to see what kind of access an intruder could gain before being challenged or thrown out. Although I'm not at liberty to discuss specific clients or findings, I can say you'd be surprised by the results. Many IT directors were astonished to be handed copies of "stolen" backup tapes, printed network maps, misplaced badges, and other confidential information obtained by security professionals. The security loop holes often weren't technical. The security professionals would simply pose as employees or sub-contractors and walk right through the front door behind legitimate badge holders. Unless you have an armed guard protecting each RJ45 jack, you are vulnerable.
Curiously, many IT directors ban wireless devices, citing security issues, but ignore the fact that an unprotected RJ45 jack just as dangerous as an open wireless connection. Why worry about the security vulnerabilities inherent in a wireless network if it's just as easy for an attacker (in most public facilities) to just walk up and plug in a laptop? I'm not saying security isn't important--but I am swing that fears about Wi-Fi have been blown out of proportion. The truth is we've all chosen to accept a certain level of risk when using wired networks, even though they're almost as vulnerable as wireless networks. Unfortunately, wireless networking extends network security weaknesses by extending your "perimeter" beyond the walls of your facility.
I'm a firm believer in the concept of "security in layers" and the more layers the better. On the other hand, if you're using a wireless network, you basically have to operate under the assumption that your wireless traffic can and will be vulnerable to eavesdropping and injection attacks. The real-world security scenarios in this article show how two companies in my backyard are dealing with wireless security vulnerabilities.
If you can't beat 'em, join 'em
At a recent security conference in Las Vegas (http:// www.defcon.org), a group of security researchers demonstrated a vulnerability that let them hijack user sessions in a public hotspot environment. One speaker showed how he could walk into a Starbucks, force users to disconnect from the access point (AP), and capture the usernames and passwords of unsuspecting patrons when their computers (automatically) tried to reauthenticate with the AP. The speaker could do all this with a PDA, hidden in his pocket, while he stood in line to get coffee.
To the amusement of the crowd, another presenter suggested that one way to prevent this kind of attack was to "stop charging for hotspot Internet access." It's an interesting thought. Under some circumstances, the best way to protect a credit card is to stop asking for one; and, the best way to defend against WEP security flaws is to stop relying only on WEP to secure your wire less network. Instead, venue owners can attract new customers by offering free hotspot Internet access. And, if you're still relying on WEP to keep you safe, consider the lessons learned from enterprises like the Salk Institute and Qualcomm: Treat the wireless network as an untrusted segment and define access rights accordingly.
MOBILE BUSINESS BENEFITS
Any connection--wired or wireless--has its vulnerabilities. Rather than rejecting wireless because of its security flaws, some companies are choosing to move ahead with their wireless deployments, but treat the connections as untrusted and make smart decisions about what parts of their networks they make available wirelessly.
RELATED ARTICLE: Security in the real world.
Qualcomm
San Diego, California
Wireless Security Challenges:
* Unauthorized networks
* Security breaches
On July 22, 2003 the San Diego Telecom Council's Wireless LAN SIG set out to answer some tough security questions by hosting "Success Stories: Wi-Fi in the Enterprise." One of the presenters--Norm Fjeldheim, CIO for Qualcomm--shared his experiences setting up 802.11 networks. The event's organizers were hoping for some controversy, perhaps a bit of spirited debate. What they got instead was enthusiastic agreement that Wi-Fi in the enterprise can be a success, and that careful architecture and solid management not only subvert the vulnerabilities of 802.11, but introduce new efficiencies into the enterprise.
Fjeldheim shared that his company's initial motivation for getting into Wi-Fi was defensive, in response to employees who were installing unauthorized, unmanaged, and worse, unencrypted access points. Employees simply went down to their local computer store bought whatever Wi-Fi equipment caught their fancy, and set up rogue hotspots inside Qualcomm. Fjeldheim estimates there might have been as many as thirty rogue access points.
Security was inconsistent: Sometimes WEP was enabled, sometimes it wasn't. As a result, the company's intranet (QualNet) extended beyond the building walls, and indeed, Qualcomm found people out in their parking lots, connecting directly to their network.
"As an intellectual property company," Fjeldheim says with a wry smile, "we were concerned."
Adopting an "if you can't beat 'em, join 'em" philosophy, and wanting to investigate the technology anyway, Qualcomm rolled out its own Wi-Fi network in 2001 and 2002. It set up two hundred Avaya AP-3 APs in common areas, such as meeting rooms, break rooms, and the seventh-floor executive suite. Qualcomm deployed 1,500 PCMCIA cards and 628 Wi-Fi-enabled laptops. The network was an immediate success, and upper management was one of its most enthusiastic users.
Then, two bombshells fell: News broke that students at Berkeley had cracked WEP, and wardrivers ferreted out Qualcomm's APs--including Dr. Jacobs' work and home APs--and were publishing their locations on the Web. With upper management's blessing, Fjeldheim and his team took the wireless network down while they rethought their strategy.
Eight weeks later, the rearchitected Wi-Fi network was launched. This time, it was located outside the firewall, where it provides all users open access to the Internet. Employees and contractors with the proper VPN client and passwords use VPN to access QualNet. After they're authenticated over this encrypted channel, their computer is considered a trusted device and they have access to anything on the network, including enterprise applications. The VPN infrastructure also supports access to QualNet over the wired Internet, meaning users employ the same equipment, software, and systems interfaces.
Qualcomm is gradually rolling out the 802.11 network to most of its two million square feet of real estate in San Diego. However, it isn't its intention to replace wire, except perhaps in very small offices. Qualcomm's wired network delivers between 100MB and 1GB to the desktop, and an 11MBps Wi-Fi connection just can't handle the computing load. The current model is to give employees the wireless network when they're mobile, and the wired network when they're at their desks.
"The Wi-Fi gets a lot of usage," Fjeldheim says. Although it wasn't cheap, it certainly wasn't overly expensive. It cost Qualcomm US$341,400 to implement the Wi-Fi network (for the equipment and the labor), which is roughly $160 per initial user. Qualcomm's ongoing cost is about $171,600 per year--the price of the 1.5 engineers it takes to maintain and administer the network.
Qualcomm considers the Wi-Fi experiment a success: The employees get their hotspots, and the company gets to maintain its secure computing environment.
--BY MARIAN AND JON GALLAGHER, AND DAVID R. AHLGREN
Salk Institute
San Diego, California
Wireless Security Challenges:
* Unknown users
* Users with unknown technical expertise
* Lack of physically defined perimeter
At a recent meeting of the San Diego Wireless Users Group (http://www.sdwug.org), Chris Adams, a system administrator for the Salk Institute, presented an innovative solution for large-scale campus deployments that lack control over their user population and their wireless equipment. Although your organization might not face quite as wide a range of issues, Adams' solution does address many problems of great interest to most large companies, especially hotspot providers.
At the Salk Institute, users with a variety of client devices constantly wander in and out of the wireless environment. "We have students, visitors, speakers, guest lecturers, you name it," says Adams. "People show up with every type of computer and operating system known to man."
Another problem is the broad range of experience and technical abilities of the users. This can be a significant burden on technical support staff. According to Adams, "We don't have enough people to spend time supporting everyone's wireless solution or special client software. We found cases where people don't even have access to reconfigure the wireless cards on their laptops because their administrator installed it and the utility won't run as a normal user to let you change the SSID and other options."
He adds, "Security mechanisms, such as VPNs, LEAP, and 802.1x require certain cards, drivers, and operating systems, tend to be complex and unreliable, and it will be years before we can assume otherwise." As an example, "If you use WEP, you just opened yourself up to supporting every screwball wireless client out there, figuring out which key format everyone uses, determining whether or not they support 128-bit or 40-bit encryption. We want to make it easy for users to just open up their laptops and start working."
Finally, the total lack of a physically defined perimeter enhances the problem of identifying legitimate users. "We can't trust everybody in the building," says Adams. "We might have students who just walked over to see a lecture; realistically, we don't know them or have any reason to trust them more than an ordinary Internet user. They haven't signed any agreement with us, nor are they covered by the normal employment contracts regarding system abuse. We're not going to spend time pretending we can trust people or that the wireless network is secure, when in fact there are numerous known insecurities."
With all this in mind, Salk's wireless network had to be:
* Easy to use with no special client software requirements
* As close as possible to universally compatible
* Easy to administer
* Compatible with expectations for an open academic environment
The solution? Adams provides an open wireless network with access only slightly more privileged than that allowed users coming from the Internet. "Treat wireless clients like anyone else on the Internet and make the wireless network as simple as possible," advises Adams. "We don't use any (WEP) encryption. We put everything on a VLAN, separated from the rest of the network and that goes through a registration system. The first time a user connects, the DHCP server realizes they aren't registered and sends them an IP address in a special range, and a special DNS server that results in users talking to our Netreg server."
Netreg is a special access control service that checks a user's registration status based on their hardware MAC address. (See http://www.net.cmu.edu/netreg for more information.) "Netreg just checks for a known MAC address and runs the user through some sort of authentication. In our case, we're using the ability to authenticate against one of our mail servers or NIS. You can make this as complex or as simple as you want."
From a security perspective, relying on a MAC address to secure a network is generally regarded as poor security because sophisticated attackers can change their MAC address to look like another valid MAC address ("spoofing"). For the Salk Institute, MAC-based authentication is only used to provide a simple audit trail, force users to agree to an acceptable use policy, and supply users with suggestions and warnings about wireless security risks.
So, how does all of this work? Simple. The DHCP server has two profiles: one for authorized users and another for unauthorized users. Unauthorized users receive a unique IP address and a special DNS server, all with a 30-second lease life. The only thing the firewall allows an unauthorized user to do is access the registration server. The DNS server automatically resolves any HTTP request to the IP address of the registration server, so if a user opens a browser and types in any URL, they're automatically (and securely) redirected to the registration screen via SSL.
Following registration, users receive new DHCP information upon lease life expiration. The new DHCP information includes an IP address and DNS server for authorized users. Most of the time this works without a hitch. Sometimes a client reboot is needed. "Certain versions of Windows 95 have a charming habit of not updating the DNS server when the DHCP server tells them to. A reboot takes care of this."
Even for authorized users, network access is extremely limited. "Once they get through the registration process, they still don't have a great deal of access to our network. Their access to our internal servers is highly limited. They can access a few file servers that we know are exposed and are patched and secured accordingly. They get access to SSH (an encrypted form of telnet) on the UNIX systems and basically nothing else."
"In our firewall configuration, we decided 'thou shalt not use insecure protocols.'" So we only allow protocols that use SSH or SSL for secure tunneling, the one exception being normal HTTP, for obvious reasons. We run HTTP through squid (an open-source HTTP caching server). Squid conveniently defangs worm attempts by marking those requests as malformed and denying them. Squid also saves a significant amount of bandwidth. We found that somewhere around 60 percent of the requests are answered completely out of the cache, so it really improves performance."
To prevent abuse, Salk doesn't allow wireless access to POP3 or IMAP e-mail servers unless the user has enabled SSL. "Not only are we protecting our services from password-guessing attempts, we're also encouraging good habits around the rest of the network. Many of the researchers we've dealt with didn't know this option was available. They start thinking about all the times they've been at Starbucks or the airport lounge and their password's been flying around in cleartext. Then, they realize how easy it would be to use that password to break into files on the server. It's usually quite sobering."
It's not perfect, but the solution clearly addresses the Salk Institute's needs and goals. Says Adams, "The main problems that we've noticed is we don't have any way of preventing MAC spoofing attacks. However, the firewall rules limit the number of damaging things a user can do. For example, they can't connect to port 25 on somebody's mail server, so they can't start relaying spam through it." At the conclusion of the presentation, Adams reports, "So far, it's been working great."
--LEE BARKEN, TECHNICAL EDITOR
Lee Barken, CCNA, MCP, CISSP, CPA has been in the IT industry since 1987. He is co-founder of San Diego Wireless Users Group (http://www.sdwug.org), and has authored many articles, and speaks at national conferences on the topic of wireless LAN technology and security. Lee teaches the "WLAN Deployment and Security" class for University of California at San Diego (UCSD) Extension and is the author of How Secure is Your Wireless Network? Securing your Wi-Fi LAN, a comprehensive book on wireless security. He was an IT consultant and network security specialist for Ernst & Young's Information Technology Risk Management (ITRM) practice, and KPMG's Risk and Advisory Services (RAS) practice, http://www.wlantraining.com