Instead, you must spread your security nets wide. You must consider and protect every device with a wireless network card: every wireless access point, every computer, every handheld, every bit that travels your network bandwidth, every user, and everywhere they go. You have to do this, lest others attack them and, defenseless, they become a playground for merciless marauders, free and open conduits right into your internal network, which then becomes a vast information treasure trove for your competition.
To help you, I've prepared a list of best practices for each of these in part two; but first, a little background:
Wireless security features
Two factors determine which wireless security features are present. These factors are the network mode and the IEEE standard. While additional add-on applications and devices exist that can broaden security choices, if you don't understand the current limitations of most wireless devices, you won't know which, if any of these, may benefit you.
Wireless LANs can exist in either ad hoc (peer-to-peer) or infrastructure (all wireless devices must connect to an access point) mode. In ad hoc mode, clients communicate directly with each other. Say two of your employees,
Congratulations, you just regressed your carefully constructed Windows 2000 Active Directory infrastructure to Windows for Workgroups. (It's not hard. XP automatically and by default will configure itself to find and connect to a wireless access point if any exist and, if none exist, it puts itself in ad hoc mode, so little intelligence is required to set things up.)
Infrastructure-mode wireless LANs use a central access point (AP). The AP is slightly more intelligent than a hub. So if Alice wants to visit Bob's cubicle and still remain connected to the corporate LAN, she can buy an AP and put it under her desk. Instead of connecting her laptop to the provided LAN jack, she connects the AP to the jack. Of course, Alice and Bob must configure their client to point to the AP network instead of to each other. Since they won't be using a cable, they use the network name or SSID of the access point. But the SSID is not a security feature, since many wireless LANs stay at well-known factory defaults and many APs broadcast the SSID. Worse, SSIDs often get out through word of mouth, and Internet-based directories of SSIDs and locations exist. In fact, Alice can probably purchase an AP that works right out of the box with no configuration at all.
So where's the security in all this? The answer depends on which wireless standard(s) are implemented in your hardware and software.
While several emerging wireless standards exist, there are three that you are most likely to find in the current market: 802.11a, 802.11b and 802.1x. The oldest is the 802.11b standard, and most wireless LANs meet it. The next one, 802.11a, is faster, but you cannot mix and match 802.11a and 802.11b hardware and software on your wireless LAN. 802.1x is an authentication standard for 802.11 wireless LANs, but it requires additional hardware and software for its implementation.
Security, for most 802.11 wireless LANs, means device authentication (not user authentication, and this is important) and Wired Equivalent Privacy (WEP) encryption, both of which normally use the same key. Authentication can be set to open system or shared key mode.
The first of these, open system authentication, doesn't really authenticate anything; any client can request a connection and get it. And because authentication in 802.11 is device authentication, an attacker doesn't need a valid user ID and password on your network to gain accesses to the wireless LAN. Shared key authentication is somewhat useful because, to connect a system, an attacker must know the shared key. This shared key is often also used for encryption.
WEP encryption has been tested and found lacking. Researchers found that, because of a flaw in WEP's implementation, easily mounted attacks can discover the key and thus enable decryption of the data. Free cracking tools exist on the Internet. Changing the keys frequently might foil such attacks, but there is no key management in 802.11, so key changes mean manual updates to systems that may be widely distributed.
If Alice and Bob's company implemented 802.1x-compatible wireless equipment and software, there would be more choices for the protection of the LAN. Not only does the 802.1x standard define restricted wireless-network connections, it also provides for mutual authenticated access (client-to-network, network-to-client), centralized user identification, dynamic key management (per-user and per-session, with the ability to change keys dynamically) and accounting services (who logged on when, and so forth). In addition, there is no need to dedicate the RADIUS server to protect only wireless access; it can also support wired Ethernet network access. Hurrah! You're back in the world of modern systems.
In a Windows 2000 network, you can use Internet Access Services (IAS) server. It's built in to Windows 2000, but it must be installed and configured. Windows XP provides a native 802.1x client that can take advantage of this setup. Authentication can then happen via Extensible Authentication Protocol (EAP). This protocol defines basic authentication processes common to most authentication protocols and allows administrative choice of supported add-ons. For Windows 2000 IAS, supported protocols are EAP-TLS (EAP with Transport Layer Security, an IETF standard similar to SSL), Protected EAP (PEAP) with EAP-TLS, or PEAP with EAP-MS-CHAP. PEAP is designed to make up for the deficiencies of EAP, which does not protect user identity and negotiation processes; EAP also does not address the issue of key exchange. TLS versions of this protocol require the use of certificates, while PEAP with EAP-MS-CHAP uses passwords.
Any of these protocols is a huge improvement over a simple shared key, or no authentication or encryption at all. Another of their byproducts is the ability of 802.1x to partition the wireless LAN. When a client requests authentication, its access to the wireless LAN is restricted to the access point until it has been authenticated. You can think of an 802.1x-enabled AP as if it were a simple switch, one with two ports: one for unauthenticated services, the other for authenticated ones. When Alice attempts to connect to the network, her client communicates on the unauthenticated port. If she supplies appropriate, valid credentials, her system can then communicate on the authenticated port and access the rest of the wireless and wired network. If Bob's system has not been updated, it never even connects to the authenticated port on the AP, let alone get access to the rest of your network. Keep this in mind, however: both access point and client must support 802.1x, and you mus t configure IAS or another compatible RADIUS server. You must configure them correctly or, as in many similar situations, the security gains of 802.1x can be lost.
About the author: Roberta Bragg, MCSE, CISSP, is a well-known Windows security consultant, columnist and speaker. Her publishing credits include "ISA Training Guide," "MCSE Windows 2000 Network Security Design" and "Windows 2000 Security."
This was first published in February 2003