Implementing security for Wireless Networks
Throughout this article, I will be referencing Cisco’s SAFE, a flexible, dynamic blueprint for security and VPN networks. Based on the Cisco Architecture for Voice, Video and Integrated Data (AVVID), SAFE enables businesses to securely and successfully take advantage of e-business economies and compete in the Internet economy.
Wireless Networks are Targets
Wireless networks have become one of the most interesting targets for hackers today. One thing to note is that WLAN devices ship with all security features disabled, making WLANs “attractive” to hackers. To make matters worse, there are Web sites which have started documenting all the freely available wireless connections available publicly.
Although most hackers are using these connections as a means to get free Internet access or to hide their identity, a smaller group sees this situation as an opportunity to break into networks that otherwise might have been difficult to attack from the Internet because unlike a wired network, wireless networks send data over the air and usually extend beyond the physical boundary of an organization. In particular, when strong directional antennas are used, a WLAN can reach well outside the buildings that it is designed for. This scenario creates an environment where traditional physical security controls are ineffective because the packets can be viewed by anyone within radio frequency range.
Ad Hoc versus Infrastructure Modes
The security impact of ad hoc WLANs is significant. Many wireless cards, including some shipped as a default item by PC manufacturers, ship with ad hoc mode enabled by default. Any hacker who also is also configured for ad hoc mode is immediately connected to PCs using these cards and could attempt to gain unauthorized access. There are some base level recommendations that every WLAN device should follow. At a minimum, the following should be done:
Access Point security recommendations:
|
Security Policies and Procedures
Whether or not you are designing security for wireless or wired networks, it is always advisable to have a security policy in place. It is recommended that an organization have a complete wireless network policy in addition to its overall security policy. This wireless policy should, at a minimum, disallow the connection of non-IT supported APs into the network. On the procedures side, the IT department needs to conduct regular scans of its office space to check for rogue APs. This includes both physical searches and wireless scans. Several vendors offer tools designed to discover the presence of the wireless APs in a certain area.
In the hands of a determined hacker, a rogue AP can be a valuable asset in the attempted compromise of network resources. The principal threat is installing an AP into a network after gaining unauthorized access to a building. The user typically gains access to the building by “tailgating” behind a user with a valid access badge or by obtaining a guest badge for some other reason. Because APs are relatively small and can be purchased at many electronics outlets worldwide, it is easy for the hacker not only to obtain the AP but also to install it discreetly. Attaching the AP to the underside of a conference-room table and plugging into the live network allows the hacker to break into a network from the relative security of his car in the parking lot.
From an implementation perspective, many Ethernet switches today offer the ability to limit access to a particular port based on the MAC address of the connecting client. These controls could be set up to learn the first MAC address to connect to a port and then prevent any subsequent MAC addresses to connect. The controls could also be configured in a manner to prevent more than a fixed number of MAC addresses to connect. Both of these features can help with the rogue AP problem, but remember that their use involves a significant administrative penalty.
Managing the MAC address tables in a large enterprise could become a full-time job by itself. Also remember that with a conference room it is difficult to know what different systems will connect to a given network port. Because a conference room is a likely target of a hacker with a rogue AP, it may be useful to disable wired network access from all conference rooms. After all, providing wireless access to the network from conference rooms is one of the main reasons organizations choose to deploy wireless LAN technology today.
Conclusion
This article is not meant to be an exhaustive approach to WLAN security. There are inherent security risks in WLAN deployments especially with the currently available methods available on 802.11b. Following some of the guidelines that I’ve outlined in this article will help mitigate many of the security risks. In addition, a group of companies led by Cisco Systems and Microsoft, is working on a new standard for WLAN security called 802.11i, which is based on LEAP, Cisco’s proprietary security mechanism on its WLAN products.
The IEEE 802.11b standard includes components for ensuring access control and privacy, but these components must be deployed on every device in a wireless LAN. The two mechanisms for providing access control and privacy on wireless LANs: service set identifiers (SSIDs) and wired equivalent privacy (WEP).
Hackers being hackers however will always find a way past the best defences and the only way to stay safe is to keep one step ahead of them. Properly architected, you can ensure a strong level security on your wireless network yet reap the productivity and flexibility benefits that such networks afford.
Fredy Cheung is Director of Core Technologies, Asia Pacific, Cisco Systems
Front page | Design Approach | Standard LEAP WLAN Design | Standard VPN WLAN Design | Alternatives |
SAFE wireless addresses the general concerns of WLAN security as mentioned earlier. This design section integrates those concerns and mitigation techniques to a variety of different networks. The size and security concerns of the specific design dictate the mitigation techniques that are applied to a WLAN design. Therefore, the network designer is offered a choice of the mitigation technology to implement along with the advantages and disadvantages of the technologies specific to the SAFE design. The mitigation technologies are consistent across all the SAFE designs, so a review of the networking elements of each of the two main technology choices is presented first. After reviewing the technologies, the network designer is presented with each SAFE design, along with the advantages/disadvantages of implementing the specific mitigation technologies within SAFE. Any unique characteristics of implementing a mitigation technology within the SAFE designs is also presented. The two main design choices follow:
- Implementing a dynamic WEP keying model using EAP and 802.1X, called LEAP
- Implementing an overlay VPN network using IPSec
Front page | Design Approach | Standard LEAP WLAN Design | Standard VPN WLAN Design | Alternatives |
This design details a generic method for using LEAP as a security mechanism to access the production corporate network.
Key LEAP Devices
Threats Mitigated
Threats Not Mitigated
|
LEAP Design Guidelines
In most cases, WLAN access points are connected to existing Layer 2 access switches. RADIUS and DHCP servers are located in the server module of the corporate network. Security in the design is maintained by preventing network access in the event of a RADIUS service failure. Since most of the mitigation against security risks relies on the RADIUS service, this behavior is required. Overall, management of the solution is hindered if DHCP services fail.
The wireless clients and APs use LEAP to authenticate the WLAN client devices and end users against the RADIUS servers. Note that because the LEAP process does not presently support OTP (new versions of LEAP will support OTP), a significant security hole is introduced into the network because attackers can attempt to brute force the LEAP authentication process. Be sure to require (and check) that users choose strong passwords and set account lockouts after a small number of incorrect login attempts. This configuration can be made at the RADIUS server.
For scalability and manageability purposes, the WLAN client devices are configured to use the DHCP protocol for IP configuration. DHCP occurs after the device and end user are successfully authenticated via LEAP. After successful DHCP configuration, the wireless end user is allowed access to the corporate network. Filtering in place at the first Layer 3 switch prevents the wireless network from accessing portions of the wired network as dictated by an organization's security policy. In SAFE, for example, filtering was put in place to prevent wireless access to any department servers, voice networks, or other user networks. Network designers should give special consideration to the location of the RADIUS and DHCP servers used by LEAP.
Front page | Design Approach | Standard LEAP WLAN Design | Standard VPN WLAN Design | Alternatives |
This design details a generic method for using IPSec VPNs as an overlay security mechanism to access the production corporate network from a WLAN.
Key VPN Devices
Threats Mitigated
Threats Not Mitigated
|
Standard VPN WLAN Design Guidelines
WLAN APs connect to Layer 2 switches in the building module layer on a dedicated VLAN and forward traffic from the WLAN to the wired LAN using IPSec to protect the flows until they reach the wired network. It is important to point out that WEP is not enabled in this design. The wireless network itself is considered an untrusted network, suitable only as a transit network for IPSec traffic.
In order to isolate this untrusted network, administrators should not mix the VLAN for the WLAN users with a wired network. This configuration would allow hackers on the wireless network to potentially attack users on the wired network. The WLAN clients associate with a wireless AP to establish connectivity to the campus network at Layer 2.
The wireless clients then use DHCP and DNS services in the server module to establish connectivity to the campus at Layer 3. It should be noted that when the wireless client is communicating with the campus network, but before the IPSec tunnel is established, the client traffic is not considered secure. All the noted WLAN security issues are still present until the wireless client can secure communications with an IPSec VPN.
Therefore, two mitigation techniques are recommended:
First, the AP should be configured with ethertype, protocol, and port filters based on a company's wireless usage policy. SAFE WLAN recommends restrictive filters that allow only the necessary protocols required for establishing a secure tunnel to a VPN gateway. These protocols include DHCP for initial client configuration, DNS for name resolution of the VPN gateways,and the VPN-specific protocols, IKE (UDP port 500) and ESP (IP Protocol 50). The DNS traffic is optional, dependent on whether the VPN client needs to be configured with a DNS name for the VPN gateway or if only an IP address is suitable.
Secondly, personal firewall software is included on the wireless client to protect the client while it is connected to the untrusted WLAN network without the protection of IPSec. In general terms, the VPN gateway delineates between the trusted wired network and the untrusted WLAN. The wireless client establishes a VPN connection to the VPN gateway to start secure communication to the corporate network. In the process of doing so, the VPN gateway provides device and user authentication via the IPSec VPN.
Even with this filtering, the DNS and DHCP servers are still open to direct attack on the application protocols themselves. Extra care should be taken to ensure that these systems are as secure as possible at the host level. This includes keeping them up-to-date with the latest OS and application patches and running a host-based intrusion-detection system (HIDS).
The VPN gateway can use digital certificates or preshared keys for wireless device authentication. The VPN gateway then takes advantage of OTPs to authenticate users to it. Without OTP, the VPN gateways are open to brute-force login attempts by hackers who have obtained the shared IPSec key used by the VPN gateway. The VPN gateway takes advantage of RADIUS services, which in turn contact the OTP server for user authentication. The VPN gateway uses DHCP for IP address configuration in order for the WLAN client to communicate through the VPN tunnel. Security in the design is maintained by preventing network access if a VPN gateway or RADIUS service fails. Both services are required in order for the client to reach the wired network with production traffic.
Front page | Design Approach | Standard LEAP WLAN Design | Standard VPN WLAN Design | Alternatives |
Alternatives
Network designers may still consider enabling static WEP keys on all devices in an effort to add an additional deterrent against hackers. Although enhancements to WEP such as the MIC and WEP key hashing provide effective risk mitigation to currently identified WEP vulnerabilities, the management overhead of dealing with static key changes makes this alternative less than ideal for large WLAN deployments. This management overhead could be mitigated by never changing the static WEP key, but this solution falls strongly into the “security-through-obscurity” category.
To further secure the DNS and DHCP services, network designers should consider using dedicated hosts for the VPN WLAN DHCP and DNS deployment.
This mitigates against two potential threats that could affect wired resources:
- DoS attacks against the DHCP and DNS services which could affect wired users
- Network reconnaissance through the use of DNS queries or reverse-lookups
As an alternative to dedicated DNS servers, designers may consider hard-coding the IP address of the VPN gateway for the VPN clients. The drawback of this solution is if the IP address of the VPN gateway changes, every client will need to update his gateway entry.
Front page | Design Approach | Standard LEAP WLAN Design | Standard VPN WLAN Design | Alternatives |