In part one of this article, I told you that you must evolve wireless security on all fronts. It does little good to harden one area of your system only to have something untoward happen in some
This sounds like a daunting task, but the good news is that you may already have much of your security in place. Here are the steps to a more secure wireless LAN.
Host systems: You have specific security technologies for host protection, and you have to apply them. Unfamiliarity with wireless technologies doesn't mean you needn't apply sound security practices to your network, your user community and especially the host systems themselves.
Think untrusted network!
You wouldn't put Windows clients or servers unprotected on the Internet, so you shouldn't expose them to a wireless network either. Specifically, remember to harden NTFS and registry permissions, not to use the FAT file system, to use group policy to apply strong account policies for accounts (local account databases exist -- they need strong account polices as well), to reduce user rights and to set security options that protect the system. Consider using the user access right to the system from the network to establish a group, say the local administrators group, that will be the only group able to access this computer from the network. If the host is a server, consider establishing a group that includes only those who should be connecting to it. Remember also, if wireless networks open holes to your internal network, it may be time to implement those host-security lockdown policies for all machines, not just those with wireless network cards. A good guide that teaches host-based security is the Microsoft Security Operations Guide.
Finally, remember that when Alice connects her computer to an access point (AP), it's the same as if she had cabled it to a hub; she's on a LAN with every other wireless networked computer that has a connection to the AP. A personal firewall on Alice's computer will go a long way toward protecting her system. Alternatively, you might consider an IPsec policy that allows only approved protocols in to and out of Alice's machine.
Network defense: Unless the wireless LAN is self-contained -- a small network in a meeting room without Internet connections, for example -- the AP is connected to some network. It serves as a bridge for wireless clients to enable their connections to your local wired network. So think of it as just that -- a bridge from "untrusted" to "trusted." It's not that you should immediately consider all wireless users in your organization untrustworthy; it's the unwanted connections you want to avoid. To do so, use 802.1x where you can, and set up a VPN where you can't. That way, "Ian the Intruder" may be able to make a connection to the AP but will not be able to access your network, because he cannot provide appropriate credentials to either the VPN or the RADIUS server.
You may also consider setting up a firewall. Just remember that placement is important here. If a single firewall is available, you don't want to put the firewall between the AP and users attempting to connect to it. Instead, you want the firewall between the AP and your internal network.
Wireless LAN configuration: Use 802.1x if it's available. If it's not, configure WEP. Yes, the protocol is crackable, but it still can provide a reasonable speed bump to would-be listeners. Those cracking programs have to capture a lot of data before they can work, and not every wireless script kiddie will have the tools or the patience to use them. It's like the locks that most of us have on our front doors. No serious burglar has a problem getting past them, but we still lock our doors, because we know we're going to keep most people out, and because it doesn't take much effort to turn the latch as we exit the house.
Unlike your door lock, WEP can even have its keys changed easily -- and you should have them changed. I know that doesn't scale well, but think of the tons of small businesses that have only a few legitimate clients -- places where expensive third-party tools or new hardware and software are out of the question. Change the SSID from the factory default, for goodness' sake!
If you can, turn off the SSID broadcast. Users who need to connect should know the SSID or have it preconfigured in their clients. If you can, configure clients with static IP addresses and turn off DHCP (dynamic host configuration protocol) on the AP. Don't give the attacker a free address on your network. Where DHCP must be used, limit the scope to the number of clients you have. Why provide extra addresses for would-be attackers? Reserve addresses for specific systems if you can. Require a MAC address for access. Granted, MAC addresses can be spoofed, but first an attacker has to determine which MAC addresses are legal. That's not going to be easy for most people.
Use data encryption on the files stored on the host. If an attacker does get past your defenses, that makes it harder for him to get any useful information. Just please, please, read the information about saving encryption keys, and then follow through -- save the encryption keys to avoid data loss.
Special protection for mobile systems: One aspect of wireless security that few people are bothering to address is the hazard of toting a wireless network card-equipped laptop, PDA or other device. Wireless APs are appearing in airports, coffee shops, convention centers and other public gathering places. In addition, many private APs are connect-able from public places. Who's to judge whether all users connecting to these APs have the best of intentions? When users access these stations, they expose their systems to intrusions. Strong host protection and a personal firewall are the bare minimum that should be enforced here. In addition, pay special attention to the configuration of the client. Windows XP, for example, by default, automatically attempts to locate a nearby wireless LAN and discover the necessary information for configuration. An attack could be in progress and result in a successful compromise long before the user even knows the system is available. If possible, turn off wireless cards when users are not at their home offices or when they can connect to "friendly" APs.
And, if users must access networks in hazardous territories, have them carry an extra hard drive, one that is configured with a locked-down OS and little else. Users can surf the provided facilities and access the Internet, but no corporate data is exposed on their systems. This is actually a technique used by security gurus at security conferences; they want to see what's going on, but they don't want to compromise their systems.
User education: Don't forget that a lot of your problems with wireless security will come not from managed APs and locked-down hosts but from rogue APs hidden by users under their desks, or provided by individual departments in conference rooms. You should, of course, be monitoring for these systems, but user education can prevent their implementation. Knowledgeable users are your best frontline defense. If they have an appreciation for the risks and know how to mitigate them, I think you'll find them willing participants.
You should also have a security policy that addresses the issue of who implements a wireless LAN and what its minimal configurations should be. Still, you're going to need to keep an eye out for them and rip them out of your network when found.
Don't be tempted to think that, if you follow these recommendations, you'll have secured your wireless infrastructure. Nothing could be farther from the truth, for two reasons. First, technology is just changing so fast that you could let the security gap widen because of lack of knowledge or complacency. Second, other wireless technologies exist and require their own security standards, and you'll have to be aware of them. But that is a subject for another time.
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