 |
|
802.11 Wireless LAN Security and the Cisco SWAN Program |
|
| Peter J. Welcher | |
|
||||||||||||
IntroductionI've posted several new seminars on my web page. See http://www.netcraftsmen.net/welcher/seminars/index.htm . The new seminars include WLAN Security, IP Telephony Readiness, Introduction to IPSec VPN, Voice and Video Enabled IPSec VPN (V3PN), and High Availability Campus Design -- Best Practices. We're making an effort to post these and other company seminars at http://www.netcraftsmen.net/Seminars.htm . And we're also working to try to bring the seminars to various locations, especially on the East Coast. Check our News link for any scheduled seminars.The WLAN Security has been presented twice, in Long Island and in Columbia, Maryland. The turnout was very good and even as I write, we are working to schedule presentation of this seminar, especially in the New York and DC areas. Because of the level of interest, and frankly, because the research work is already done, I thought I'd put some of the ideas in the WLAN Security seminar into this article. (Hey, I'm writing this on July 6, so far resisting a strong urge to head for the swimming pool.) I thought I'd also talk a little about the Cisco SWAN (Structured Wireless-Aware Network) program, since they seem to be doing a good job of both listening and responding quickly to real customer needs and concerns. The two prior articles about 802.11 WLAN (co-author, Marty Adkins) can be found at:
Wireless LAN (WLAN) BackgroundMost people are now well aware of the opportunities 802.11 Wireless LAN (WLAN) networks bring. The advantages start with convenience (which does shade into higher productivity as well). Saving on wiring costs and speed of deployment are two other often-mentioned advantages. Disadvantages can include security and lower reliability.The Ethernet Era has brought us fairly reliable cabling. Get the cabling done right, and experience few to none of the almost daily outages some of us remember (be they from Thin Ethernet, Thick Ethernet, or Token Ring days). The same principle applies to WLAN. The problems come in when IT hasn't gotten out in front or hasn't gotten the site survey and deployment handled well. If the Wireless Access Points (WAP's) are deployed in ad hoc fashion by users, or with insufficient care by reseller or staff, then there can be dead zones, areas of poor coverage, regions of low throughput, and so on. Procedures also need to change. Users can and do add things to the Wireless environment, things like heavy metal (filing cabinets, not rock groups, also equipment racks), and even microwave ovens and cordless phones. The air waves aren't quite as protected an environment as good cables run inside conduit or walls. Having said that, as we go to Gigabit speeds and beyond (in some cases, even 100 Mbps), some are discovering that their Ethernet cabling plant is barely Category 5 cabling, or has other quality problems. So our 10 years of few physical layer problems do seem to be coming to and end. As far as security, well, that's what the rest of this article is about. Wireless LAN SecurityAs you're aware from the second article mentioned above, the original implementations of WLAN security had some problems. As in not providing much if any security. What's also become clear from talking to folks at our seminars and elsewhere, people may or may not have known about the security issues, but if they did, they often failed to make dealing with them a priority. The price some paid was to be hacked, sometimes repeatedly.Let's review the previous security situation. Some WAP's shipped with a scheme called Open System Authentication (i.e. "no authentication"). Others counted on SSID to provide security. The third popular approach is MAC address access lists. All are easily defeated or spoofed using tools posted on the Internet. If you are using these schemes, you will probably be hacked! And let there be no doubt about the interest out there. It appears to be mostly directed at finding free Internet access. But all any bad guy or gal needs is to find one open WAP somewhere in your organization, and now they're into the "soft chewy interior" of your network (i.e. inside the tough exterior firewall). See also The previously existing security schemes with value all used one of the EAP (Extensible Authentication Protocol) variants. Cisco was an early proponent of the LEAP approach. (The letter "L" stands for Lightweight, not in terms of security but in terms of impact on the WAP.) By the way: your security is as weak as the weakest link. If your company is implementing departmental WAP's, chances are that you have at least one gaping security hole, and probably many. Do you really think departmental users RTFM? It is far better to get out in front and take the lead, even if you are too busy!!! Vendors and the 802.11i committee have now recognized the problem and drafted a standard, also adapted by the WiFi group. As of August 2003, new wireless devices will be required to implement WPA (WiFi Protected Access) to be WiFi compliant. The future 802.11 standard will become WPA Version 2, adding AES (Advanced Encryption Standard) for encryption. Due to the cost and likely performance impact of AES, it will not be required for some interim period. Here's what WPA includes:
The TKIP feature was implemented early-on by Cisco as part of their original LEAP design. It provides for encryption keys to change with every frame, making it much harder to crack the encryption key by collecting large amounts of data. Key hierarchy and management are more subtle, but better than having everyone on a WAP using a common key, as may have happened in the past. Variants of EAPWe went into this a little in the previous article. My personal take is that the market will decide between LEAP and PEAP. Since Cisco and Microsoft are both backing PEAP, that's probably going to be best supported in the long run.Here's the chart, summarizing the contenders:
The main things I think one cares about here: what schemes are available, are they multi-vendor or tied to NIC card, and do they provide adequate security. The client-side PKI matters since I am hearing that considerable support effort may be needed to deploy PKI certificates to large numbers of user PC's. The LEAP and TTLS approaches use a certificate to authenticate the WAP to the user, but do a username/password login in the other direction. If you don't already have a RADIUS server to support 802.1x, you can shop for a WAP that can act as RADIUS authentication point -- recent Cisco code has features along this line. More WLAN SecurityThe above covers controlling access to your WAP's, as well as securely authenticating users. Unfortunately, that's not enough. 802.11 also allows ad hoc mode, where two PC's communicate without WAP. Do you (a) trust all WAP's your PC will ever talk to as doing a good job of authentication, (b) trust all authenticated users of such WAP's, and (c) trust your NIC card and driver to never do ad hoc mode?You have to consider that some WAP somewhere may allow somebody else to try to port scan and break into your PC. Hence it is highly recommended that you use some sort of personal firewall on any WLAN-equipped PC. ZoneAlarm, Cisco Okena, whatever you think is best. At this point then, we have a secured PC talking encrypted frames to a WAP. That's pretty good. The RC4 scheme used for WEP is also used for WPA. It is thought to be rather weak. The TKIP changing of keys does help improve on that. Is that good enough for your corporate data? On a personal level, do you want to log in to your bank's web site and write checks over such a scheme? Note also that WEP/WPA only encrypt between NIC and WAP. Once packets leave the WAP for the regular network, they're just IP. That means if you have a building full of WAP's all on one VLAN, they all are equally secure or insecure. If you think one might by accident end up compromised or providing exposure, then it might be best to regard the network between the WAP's and the rest of your network as untrusted. That brings up the design aspect of WLAN security. WIth WPA, having WAP's connected to the nearest building switch might be considered adequate. I personally am not fully comfortable with doing that, but it is simple and cost-effective, and a case can be made that it might be "good enough". The other and better design approach is to isolate the WAP's, either with a separate physical infrastructure (costly and perhaps overkill), but at least with one or multiple isolation VLAN's. And then make the only exit from that VLAN be via a firewall. Specific details may vary -- see also the seminar version of this article.  I personally do not like large VLAN's, so I prefer a per-floor or per-closet approach. For that to work, you need mobile IP proxy in the WAP's to provide simple mobility across subnets -- another good idea Cisco has rolled into its WAP's. (Do check it is included before buying, if you need this feature). Devices from other vendors probably do not support the mobile IP proxy, which leads to designs with one WLAN VLAN per building. This is a potential source of instability in your network, at the very least, depending on how many switches the VLAN spans. If you have an untrusted VLAN running through switches, you want to think through the implications, and make sure those switches are protected against access to management VLAN from the untrusted VLAN. That means you need to make management and untrusted VLAN's different, so traffic from the untrusted side will need to go through the firewall and/or a router to get to the management VLAN. You had better also harden your switches against OSI Layer 2 exploits. This is a good thing to do anyway, which is one reason I don't like the separate WLAN infrastructure approach. I've put two links about protecting switches at Layer 2 in the table of links below. To summarize, we've said that the WLAN should probably be regarded as untrusted. Using a personal firewall, we can secure the PC laptop end of the WLAN. Using a firewall and WAP isolation VLAN, we can secure the existing network. What's left? Traffic crosses the WLAN going from PC to firewall. One might wish to encrypt this traffic, if one is concerned that somebody might gain access to the WLAN and snoop on unencrypted traffic. Or if one is concerned about transmitting traffic with somewhat mediocre encryption. The fairly obvious way to fix this is IPSec. IPSec has the advantage that you may already be supporting it for mobile dial-in or VPDN users (to preserve confidentiality as their traffic crosses the Internet). It also simplifies the firewall issue, since otherwise, how do you decide what traffic to allow through? Source IP address issued via DHCP? And spoofable? (I'm curious how people have solved this without IPSec -- if you have an alternative, please let me know.) If you do run IPSec, you can also use access lists (ACL's) in the WAP to limit the protocols and ports transiting the WAP. There's a design decision to be made there. One other approach is to provide courtesy "guest" access, where guests can access the Internet but not the corporate network. This is one use of the VLAN's Cisco has in its line of WAP's -- each VLAN can use a different form of authentication. If you need to somehow get the guest VLAN across a routed core without having an extended VLAN, one approach might be to use MPLS, for "compartmentalized routing". GRE tunneling is a lower tech solution that might be more palatable and maintainable for the typical enterprise. Structured Wireless-Aware Network (SWAN)You might have noticed, the above did not mention rogue access points (security concern) and interference (management and reliability concern). Keep reading!The Cisco SWAN program aims to more tightly integrate various Cisco network components to provide better WLAN networking, by fourth quarter 2003. The stated goals are:
Here are some of the items that caught my eye in reading through the details:
Conclusion and LinksHere are some of the best WLAN and 802.11 links I've found. They are followed by the SWAN link. Links to the Layer 2 exploit mitigation documents are at the end of the table. There is also a link to a good Network World article about scaling WLAN networks.I am aware there are Networkers 2003 presentations online about Wireless LAN topics. I don't feel comfortable posting the links until well after the Networkers has taken place. If you know the URL, you'll of course want to look there as well. I'm looking forward to writing about some of the material in the new seminars mentioned at the beginning of this article. My list of possible topics includes: some new ideas and trends in network management, how to make IPSec VPN's easier to work with, pros and cons of VPLS (Virtual Private LAN Service), why you might want to start paying attention to Content Networking, as well as other topics. Thanks for the kind words about these article to those I saw and spoke with at Networkers 2003 in Orlando. And do please send email comments, suggestions for future articles, etc. to me at the email link below. Dr. Peter J. Welcher (CCIE #1773, CCSI #94014, CCIP) is a
Senior Consultant with Chesapeake NetCraftsmen. NetCraftsmen is a
high-end consulting firm and Cisco Premier Partner dedicated to quality
consulting and knowledge transfer. NetCraftsmen has eight CCIE's, with
expertise including large network high-availability routing/switching
and design, VoIP, QoS, MPLS, IPSec VPN, wireless LAN and
bridging, network management, security, IP multicast, and other
areas. See
http://www.netcraftsmen.net for more information about
NetCraftsmen. Pete's links start at
http://www.netcraftsmen.net/welcher . New articles will be posted
under the Articles link. Questions, suggestions for articles, etc. can
be sent to pjw
<at> netcraftsmen <dot> net. Copyright (C) 2003 Peter J. Welcher |
||||||||||||||||||||||||||||||||||