New WLAN Deployments
WLAN designs are newly installed in a variety of areas within home, enterprise, and service provider networks. Two basic options are available for securing a new WLAN: embedded media solutions, such as WPA, and tunneling overlays, such as IPSec and SSL. The following sections discuss these two security frameworks and how to combine these technologies for a highly secure solution. The sections discuss how the security framework functions and compare how the security framework mitigates the threats identified in Chapter 5, "WLAN Basic Authentication and Privacy Methods." Finally, they discuss the impact that the security framework might have on WLAN design fundamentals.
Embedded Security Solutions
WPA is the most widely available standards-based, embedded media solution for securing WLANs. WPA's security scheme relies on the previously discussed 802.1x/EAP for authentication and TKIP for data confidentiality and integrity. 802.11i also relies on 802.1x/EAP for authentication and AES for data confidentiality and integrity. Other embedded media security solutions exist, such as WEP and the Cisco prestandard confidentiality solution, Cisco Key Integrity Protocol (CKIP). For the rest of this chapter, when the text refers to 802.1x/EAP, it is referring generally to the class of security schemes that leverages 802.1/EAP for its authentication and key management. These security schemes include WPA, 802.11i, and the Cisco LEAP security framework. WEP and its use in securing a WLAN is covered later in this chapter.
Because the network is designed to rely on the security embedded in the media, the WLAN extends the existing wired LAN for access by wireless devices. Figure 10-1 depicts the most basic WLAN design option, in which the network services are leveraged from the existing wired resources.
Figure 10-1. General Embedded Security Design
In the figure, the 802.11i or WPA frameworks provide central user authentication and confidentiality. In addition, the figure depicts the possible points of implementation of the host and infrastructure security mechanisms outlined in the "WLAN Design Fundamentals" and "General Security Guidelines" sections earlier in this chapter.
Threat Mitigation
When properly implemented, these security mechanisms allow the network designer to mitigate many of the threats identified in Chapter 6. The following sections list the threats mitigated in this design.
Reconnaissance: Discover Target Network
Although the attacker can still see the SSID of the WLAN through active and passive methods, he cannot discover more than the SSID due to the use of embedded TKIP or AES encryption. It should be noted that the attacker has access to the 802.1x/EAP message exchanges because both protocols are plaintext. There might be portions of information in these exchanges that allow the attacker to gather intelligence about the security scheme of the WLAN and possibly the wired LAN. The network designer must make a decision as to what type of information is available in each EAP authentication type and whether the risk of this information being available is an unacceptable risk for the WLAN.
Network Access: Gain Read Access
Similar to the mitigation of the reconnaissance attack, the embedded encryption algorithms mitigate the attacker's ability to read data from the WLAN (packet sniffers). Additionally, the attacker should not be able to gain read access through a WLAN client because the WLAN should not have ad-hoc mode WLAN enabled and cannot talk to the client directly above the MAC layer. As noted in the preceding section, several EAP authentication types do reveal information about the WLAN. For some EAP authentication types, there might be enough information for an attacker to gain read access to the WLAN. In many instances, applying a best practice for securing the EAP type can mitigate these risks. For instance, when using the LEAP authentication type, the username and password hash are visible to an attacker. This makes the password hash susceptible to an offline dictionary attack. Applying the LEAP best practice of using a strong password policy and periodically changing the LEAP password can mitigate this. If this type of risk is unacceptable, the network designer must again make a decision as to what type of information is acceptable to be viewed within the 802.1x/EAP messages and select the appropriate EAP authentication type to mitigate the risks.
Network Access: Gain Write Access
The centralized authentication of the 802.1x and upper-layer EAP protocols prevent the attacker from being able to gain access to the WLAN, which keeps him from using the WLAN as a source of attack. Additionally, the embedded encryption and integrity mechanisms of the WLAN (TKIP/MIC or AES) prevent the attacker from changing packets in transit or inserting packets into the WLAN.
Design Fundamentals and Embedded Security
In addition to extending the wired LAN services, the network designer must evaluate how the new WLAN addresses the fundamentals of secure WLAN design. The fundamentals discussed in the following sections have notable items with regard to embedded security solutions.
Network Services Placement
In the embedded security design, the proper placement of network services is critical in providing high availability to the WLAN. The primary component to consider in this design is the WDS. The WDS, discussed in Chapter 9, "SWAN: End-to-End Security Deployment," provides local fallback authentication and the security information for Layer 2 fast secure roaming information. As discussed, the WDS can be designated on an AP, switch, or router. Selecting the correct hardware of the WDS depends on the processing resources available on each platform and network topology. For instance, in a large enterprise, a WDS might be located within the switching infrastructure, Catalyst 6500, for scalability considerations. In contrast, in a small, remote office, because the number of APs is probably small, a 2600 might provide an ideal spot for the WDS and could provide fallback authentication if the WLAN to the corporate offices is down.
Mobility
As previously discussed, the Cisco SWAN architecture enables Layer 2 fast secure roaming through the use of the WDS. The general design assumes that the WLAN IP subnet can be contained within a set of distribution switches or that the IP subnet (VLAN) can extend across multiple distribution-layer switches in your network architecture. This is utilized to provide mobility for the design. If either of these conditions is not true, the network designer must use Mobile IP Proxy (MIP) to allow Layer 3 roaming.
Application Support
Because WPA and 802.11i are embedded in the media, they provide support for all Layer 3 protocols, such as IPX and IP. With the capability to support all Layer 3 protocols, the embedded security solutions provide broader application support than most tunneling overlay technologies.
Management of the APs
When utilizing an embedded security framework to secure the WLAN, the APs can be managed through the same IP subnet as the WLAN client traffic or through an isolated management subnet. An isolated management subnet is typically achieved through the use of VLANs on the wired side of the AP; however, in some environments, security policy dictates that this be an entirely separate switching infrastructure for the APs. If a common client and management infrastructure is used to manage the APs, SSH and other encrypted protocols, as previously noted, are useful to secure the management of the APs.
Multigroup Access
Multigroup access can be accomplished by dynamically assigning an authenticated user to a particular VLAN on the switched side of the AP. Hence, a corporate user can be assigned to a VLAN that has unhindered access to the corporate network, whereas a contractor can be assigned to a VLAN that has restricted access to specific hosts on the corporate network.
VPN Overlays
Using VPNs as overlays to the WLAN is the other primary design choice for securing WLANs. When this is the primary design choice, the WLAN is treated as a completely untrusted network and is separated from the corporation's security edge with a VPN gateway device. To gain access to the corporation's resources, the end user must initiate a VPN connection to the VPN device and pass some sort of per-user authentication. Because the WLAN is untrusted, network designers should take the same precautions for WLAN clients as they do for securing remote mobile users who leverage the Internet for corporate access. For example, many corporations require that external users use strong authentication (One Time Passwords or certificates on SmartCards) to gain access to the corporate network. Generally, all VPN overlays adhere to the same corporate policies with regard to the type of password authentication.
In general, all the VPN overlay technologies follow the same base topology for implementation. Figure 10-2 illustrates the topology.
Figure 10-2. General VPN Overlay WLAN Design
In Figure 10-2, the VPN tunneling framework provides central user authentication and confidentiality. In addition, this figure depicts the host and infrastructure security mechanisms' possible points of implementation from the beginning of the chapter. Also, it is recommended that the WLAN not connect to the Internet natively. If this is done, applications on the WLAN client can connect to Internet services in an insecure manner and allow information to leak to the attacker. For instance, an e-mail program with autoconnect settings turned on might set up a connection to the Internet and provide relevant information to the attacker. For this reason, it is desirable to have some sort of VPN auto-initiation feature with the VPN technology to prevent information from being sent on the WLAN in the clear, before the VPN is established to the VPN gateway. Additionally, it is recommended that network intrusion-detection systems (NIDS) and host intrusion prevention, such as the Cisco Security Agent (CSA), be utilized to protect the servers (DNS, DHCP) that are required to serve the legacy WLAN. The primary purpose of the host security software is to attempt to keep the servers from being exploited and used as stepping stones to gain access to the enterprise network.
Threat Mitigation
When properly implemented, the security mechanisms in Figure 10-2 allow the network designer to mitigate many of the threats identified in Chapter 6 and described in the following sections.
Reconnaissance: Discover Target Network
Although the attacker can discover the WLAN network topology, he should not be able to determine the network topology behind the VPN gateway device. However, the attacker will have access to any clear-text information that the end host devices transmit before the VPN tunnel is initiated. For instance, many Microsoft Windows operating systems generate broadcasts looking for domain or Active Directory services. Some of this information is available to the attacker. WEP could be employed to make this discovery harder for a low-level attacker, but it is not a valid deterrent for a mid-level or high-level attacker.
Network Access: Gain Read Access
This attack is mitigated by the authentication, encryption, and integrity characteristics of the VPN tunneling technology. However, similar to the reconnaissance threat, the attacker has access to data that is transmitted by the client before the VPN tunnel is established.
Network Access: Gain Write Access
The centralized authentication of the VPN prevents the attacker from being able to gain access to the corporate network. Additionally, the embedded encryption and integrity mechanisms of the VPN will prevent the attacker from changing packets in transit or inserting packets into the communication to the corporate network. This does not prevent the attacker from having write access to the WLAN itself. Therefore, the attacker might be able to launch attacks such as ARP poisoning to attempt man-in-the-middle (MitM) attacks. The VPN protocol should protect against active or passive MitM attacks. There are demonstrated ways to perform MitM attacks against VPN protocols. You should contact your vendor of VPN gateway products to determine the best practices to mitigate a MitM attack.
VPN Overlay Technologies
Three primary types of VPN overlays are implemented to secure WLANs:
-
IPSec-based VPNs
-
SSL-based VPNs
-
SSH-based VPNs
IPSec is the most predominant type of VPN overlay that is used to secure WLANs because it has supported the broadest set of applications. The other two types of VPN overlays, SSL and SSH, are generally more restrictive in their capability to support upper-layer protocols and applications.
IPSec
IPSec VPNs are widely deployed for remote-access VPNs as a replacement for traditional remote-access dial services to secure an organization's traffic across untrusted networks such as broadband mediums like cable and DSL. Because IPSec VPNs are so prevalent in many organizations and many people feel that WLANs are completely untrusted networks, it was a logical extension to use IPSec Remote Access Server (RAS) VPN technology to secure WLANs.
To use IPSec RAS VPNs appropriately for WLANs, the network designer must understand some background on IPSec and its ability to support user authentication and particular applications.
IPSec natively did not have a mechanism for per-user authentication and intended to use widely deployed authentication infrastructures. Originally it was intended that IPSec would leverage a protocol like L2TP to gain user authentication. However, customers and vendors requested that IPSec be extended to support per-user authentication and also the capability to download configuration information such as an embedded tunnel IP address, WINS, and DNS servers for each end user machine. This request led to the development of extensions to the IPSec protocol called xauth and mode config xauth (extended authentication), which was created to perform per-user authentication, whereas mode config was created to enable downloading of configuration information (DNS, WINS, and so on) to the RAS VPN client PC if not there. Although these extensions were public drafts, vendors created proprietary implementations of IPSec with these extensions for RAS VPNs.
This resulted in vendor-specific VPN clients not being interoperable among IPSec VPN gateways. However, some implementations of VPN clients are interoperable with multiple vendor IPSec VPN gateways. The most prevalent VPN client that is interoperable with multiple brands of IPSec VPN gateways is the L2TP/IPSec implementation in Microsoft Windows 2000 and XP. On non-PC devices, a prevalent IPSec VPN client that interoperates with many IPSec VPN gateways is called a movian secure VPN client.
The network designer needs to be aware of these user authentication, device configuration, and interoperability issues to determine if the end user WLAN devices can support the correct IPSec clients that interoperate with the corporation's RAS VPN solution.
In addition, IPSec is a network-based VPN transport and supports the majority of the upper-layer IP protocol suites natively. It was designed specifically for IP unicast traffic, and the standard makes special mention that it is not intended to support IP multicast traffic. Additional work within the IETF is addressing a standard way to secure multicast traffic. However, there are vendor implementations that can support multicast traffic in an IPSec VPN, most notably the L2TP implementations in which the IP multicast is wrapped in an L2TP IP unicast header and then secured with IPSec. Other implementations use proprietary implementations to support IP multicast. IP multicast support might be an issue because many applications rely on IP multicast to function. Examples include IP video streaming applications like Cisco IP/TV, financial applications, and IP telephony applications like multicast Music-On-Hold in a Cisco Call Manager environment.
There might be other applications that do not interoperate with IPSec, such as applications that embed IP address information as part of their upper-layer protocols. Network designers who already have RAS VPN deployments should be able to identify any applications that might have issues interoperating with IPSec VPNs. If there is not an existing deployment, the network designer needs to test each application that will be used with the IPSec client to validate that it performs properly.
Finally, IPSec gateway devices can typically implement a policy to prevent the client end user from being able to split tunnel. This prevents the IPSec client device from being a stepping stone into the corporate network. This does not prevent a device from being infected while not on the corporate network and subsequently carrying the virus into the network. To mitigate this type of issue, the network designer needs to consider a solution described in the "Admission Control Design" section later in this chapter.
SSL
SSL is predominantly used for securing HTTP-based applications such as web browsing. However, the actual SSL protocol can be used to secure a variety of transport layer protocols. Cisco and other vendors have started to offer the capability to create VPNs utilizing the SSL protocol and specialized SSL gateways that act as gateways to the corporate network. Cisco utilizes the VPN 3000 to offer both IPSec and SSL VPN tunnel termination. The main attraction to SSL-based VPNs is the idea that they enable "clientless" VPNs. This means that the network designer does not have to install or maintain an additional piece of software on the client machine to provide VPN service for WLANs. This is possible because the majority of client device operating systems (OSs) have the SSL protocol implemented in the embedded web browser.
Additionally, because SSL is a transport layer protocol, SSL-based VPNs can support only the protocols that the SSL can encapsulate without additional code on the workstation. To support the capability to tunnel all IP traffic SSL, gateways must download a piece of code to the client (for instance, an ActiveX applet) that puts itself into the IP stack of the client to tunnel all IP packets correctly. This restricts the SSL VPN to certain certified web browsers and operating systems to guarantee interoperability with the applet.
SSH
SSH is a secure alternative to remote terminal programs such as rlogin and Telnet. SSH is actually a suite of protocols that includes scp and sftp. SSH has a port-forwarding feature that makes it capable of acting as a VPN overlay technology. SSH port forwarding allows the client to forward local ports to the computer at the far end of the SSH session. In effect, this allows applications to access enterprise resources that are on the inside of the far-end SSH host for secure access across the WLAN. SSH VPN overlays are similar to SSL VPN overlays for WLAN and provide similar benefits for some situations. For many OSs, SSH is provided by default, thereby allowing SSH to be utilized to protect the WLAN communications. There are two major drawbacks to the use of SSH as a VPN overlay. First, Microsoft operating systems do not provide SSH by default, so a large part of the installation base would have to add SSH as an additional software package. Second, SSH does not support all the IP applications that an enterprise might employ, such as IP multicast. There are ways to configure this to function, but they are typically deployed by advanced users and might not be suitable for general deployment to all WLAN client devices.
Design Fundamentals and VPN Overlays
Keeping the characteristics of the three VPN overlays in mind, it is necessary to review the following fundamentals that have notable items with regard to VPN overlay security solutions. These items might influence the choice of a VPN overlay technology as the proper way to secure a WLAN.
Authentication Support
As has been noted, it is recommended that all VPN users use strong authentication to authenticate the device and users for a VPN overlay. This is recommended because strong authentication?two-factor or certificates?is considered a more secure way of performing user authentication than just a username and static password.
Network Services Placement
For the WLAN client to establish a VPN tunnel, it is recommended that the VPN gateway provide DHCP relay functionality to provide dynamic addressing to the WLAN client. This recommendation allows DHCP to be leveraged on the wired side of the network where centralized management and scalable services are available for DHCP. In some installations, it might be necessary to offer DNS services also for the WLAN client to resolve the domain name of the VPN gateway. Because both DNS and DHCP servers could potentially be reached from outside the VPN gateway, the servers should be protected from attack with the Cisco Security Agent and monitored with network intrusion detection. Also, DNS/DHCP services might be dedicated to WLAN use to reduce the risk that an attack from the WLAN can impact DNS or DHCP services on the wired LAN.
Mobility
VPN overlays require Layer 2 roaming capability to ensure mobility. However, VPN technologies generally do not support Layer 3 roaming and must rely on alternate technologies such as Mobile IP (MIP) to enable this type of mobility. The Layer 3 mobility solution discussed in Chapter 9 and later in this chapter will accommodate Layer 3 mobility for VPN overlays. Also, some current proprietary VPN technologies allow Layer 3 mobility without Mobile IP or other Layer 3 mobility solutions.
Application Support
As noted, there might be challenges with application support when a VPN overlay is utilized to secure a WLAN. A network designer must understand all potential applications that will be utilized on the WLAN and select the appropriate VPN technology to support those applications.
Management of the APs
When you are utilizing a VPN to secure the WLAN, you must manage the APs either through the VPN gateway or through an isolated management subnet. An isolated management subnet is typically achieved through the use of VLANs on the wired side of the AP; however, in some environments, security policy dictates that this be an entirely separate switching infrastructure for the APs. The AP should not accept any connection on the VLAN that corresponds to the VPN subnet because the VPN subnet is considered insecure and no communication should be possible to the AP from this subnet.
Multigroup Access
Multigroup access is accomplished in the VPN gateway by applying different authorizations per group. For instance, a corporate group might be authorized to access all internal networks, whereas a partner group might be restricted to a particular group of hosts or applications on the corporate network.
Combined VPN and Embedded Security Design
In some instances, a network designer might choose to combine the embedded security and VPN overlay security solutions. This combination gives the network designer some additional security benefits compared to either solution by itself. For instance, by making clients authenticate via 802.1x/EAP, the network designer can reduce the risk of someone attacking the network services devices (DHCP and DNS).
When WPA/802.11i and VPNs are the design choice for securing WLANs, the WLAN can be considered an untrusted or a semitrusted network. Therefore, the WLAN is separated from the corporation's security edge with a VPN gateway device. To gain access to the corporation's resources, the client must pass the authentication to the WLAN via 802.1x/EAP. After the client has successfully authenticated and negotiated WLAN encryption keys, the client must initiate a VPN tunnel to the VPN gateway and pass an additional user authentication.
Depending on the authentication methods selected for WPA/802.11 and VPN authentication, the end user might need to have an interactive prompt for both authentications. In some instances, dual interaction with the end user might be undesirable to the end user. If this is the case, the network designer might choose to select an authentication technology that can be transparently supplied to both the WPA/802.11i and VPN authentication requests. For instance, a digital certificate for an end user could be leveraged to allow EAP-TLS and an auto-initiated IPSec VPN to authenticate to both security frameworks without user interaction.
In general, the combined security technologies follow the same base topology as the VPN overlay design. Additional security measures to consider in this design are the inclusion of network intrusion detection and host intrusion-prevention software on the hosts that provide network services (DNS, DHCP). The network designer should also leverage any security services that are available in the switching infrastructure, such as dynamic ARP inspection and DHCP snooping. Figure 10-3 illustrates the topology for the general VPN and embedded security design.
Figure 10-3. General VPN and Embedded Security Design
Threat Mitigation
When properly implemented, the security mechanisms in Figure 10-3 allow the network designer to mitigate many of the threats identified in Chapter 5. This section discusses the threats mitigated by this design.
Reconnaissance: Discover Target Network
One of the benefits of combining the embedded security and VPN security frameworks is to defeat an attacker's capability to discover the target WLAN while using a defense-in-depth approach to ensuring the WLAN data's integrity and confidentiality. As discussed in the "Embedded Security Solutions" section of this chapter, there are some potential information leaks with the EAP authentication protocols. In this design, this information leak might be deemed a lesser risk because any information gleaned by the attacker would apply only to authentication to the WLAN and not to the VPN. This is true unless the same user authentication credentials were used to authenticate the user to both the WLAN and the VPN.
Network Access: Gain Read Access
This threat is mitigated by the authentication, encryption, and integrity characteristics of both the embedded security and VPN tunneling technology. It should be noted that if implemented improperly, both the 802.1x/EAP and IPSec authentications can be attacked to gain read access to the WLAN. The threat to the WLAN was discussed in the "Embedded Security Solutions" section of this chapter. However, this design improves on the VPN-only design because the WLAN embedded security does not allow the attacker to have access to data transmitted before the VPN tunnel establishment, except 802.1x/EAP.
Network Access: Gain Write Access
The centralized authentication of the embedded security and VPN security frameworks is the first mitigating factor in gaining write access to a combined security solution. In addition to the authentication, the embedded and VPN security frameworks provide encryption and integrity mechanisms to prevent write access to the WLAN.
Design Fundamentals and the Combined VPN and Embedded Security Design
Keeping the previous characteristics of the VPN overlays and embedded security frameworks in mind, it is necessary to review the following fundamentals that contain notable items with regard to the security solutions.
Authentication Support
In this design scenario, the WLAN might be considered semitrusted because it protects not only the media (embedded security) but also the data via a tunnel. With this in mind, network designers might choose not to require strong authentication for WLAN access. This is entirely a business risk decision for the network designer. Also, as noted previously, the largest issue in this design is how to make the least number of user interactions to authenticate the device to the WLAN and the VPN gateway.
Network Services Placement
Similar to the VPN overlay?only model, it is recommended that the VPN gateway provide DHCP relay functionality to provide dynamic addressing to the WLAN client for the WLAN client to establish a VPN tunnel. In some installations, it might be necessary to offer DNS services for the WLAN client to resolve the domain name of the VPN gateway. Because both DNS and DHCP servers could potentially be reached from outside the VPN gateway, the servers should be protected from attack with the Cisco Security Agent and be monitored by network intrusion detection. As stated previously, dedicating DHCP and DNS servers just for WLAN use is a consideration.
Mobility
VPN overlays require Layer 2 roaming capabilities to ensure mobility. The underlying 802.1x/EAP must support this Layer 2 mobility. However, VPN technologies generally do not support Layer 3 roaming and must rely on alternate technologies such as Mobile IP to enable this type of mobility. The Layer 3 mobility solution detailed in Chapter 9 and later in this chapter accommodates VPN-overlay Layer 3 mobility. Also, some proprietary VPN technologies allow Layer 3 mobility without Mobile IP or other Layer 3 mobility solutions.
Application Support
As noted, there might be challenges with application support when a VPN overlay is utilized to secure a WLAN. A network designer must understand all potential applications that will be utilized on the WLAN and select the appropriate VPN technology to support those applications.
Management of the APs
When utilizing a combined security solution to secure the WLAN, the APs must be managed either through the VPN gateway or through an isolated management subnet. Because this solution is semitrusted, some network designers might allow the AP to be managed through the VPN gateway rather than through the isolated management subnet.
Multigroup Access
Multigroup access is most easily accomplished in the VPN gateway by applying different authorization per group. For instance, a corporate group might be authorized to access all internal networks, whereas a partner group might be restricted to a particular group of hosts or applications on the corporate network. Although it is possible to accomplish multigroup access in the WLAN via dynamic assignment, this would then require a VPN gateway interface on every VLAN that can handle WLAN traffic. This is not feasible in most network topologies or VPN gateway devices. This makes the VPN gateway the most efficient place to implement authorization because it is the last point of enforcement before accessing the corporate network.
