Hardware-Based Teleworker Design

The hardware-based teleworker design assumes an IPsec VPN (or other network crypto) and moves the crypto process to a dedicated hardware device. This device might also support a firewall, limited IDS, NAT, and so on, much like the capabilities of the small network edge in Chapter 13. This device is connected to the same LAN as the teleworker PC that routes traffic through this device on its way to the central location. Often these devices have built-in hubs or switches that allow the PC to connect directly without any additional network hardware. The PC connects to the LAN side, and the "WAN" Ethernet interface connects to the ISP customer premise equipment (CPE) device.

The hardware teleworker design is most appropriate when the teleworker system will remain in one place or when there are multiple systems at a single location that must connect. In this case, the hardware teleworker design resembles the small network edge design. The key benefits of this design are that no special software is required on the end systems. This allows systems without IPsec stacks (IP telephones, IP printers, PCs with older OSs) to connect over the VPN as well. This becomes useful for "power teleworkers" who might have multiple systems, each with a need to connect.

Design Requirements

The requirements of this design are the same as those for the software teleworker design, save one: the connectivity must be provided without requiring any special software on the end system using the VPN.

Design Overview

As mentioned earlier, the key issue of the hardware teleworker design is the lack of security between the end system and the hardware VPN device. That network could comprise an insecure WLAN AP, other untrusted end systems, and so on. This can allow unauthorized access not just to the traffic sent to and from the teleworker systems but to the central site across the VPN.

These issues are present in the small network design in Chapters 13 and 14 but do not often cause big problems because the physical locations for these networks are organization assets. In the hardware teleworker design, the physical location is likely someone's home.

TIP

In some cases, small networks exhibit the same properties as insecure home networks. If your organization has hundreds or thousands of branch offices and you have no capability to audit the configuration of those networks, you should trust them less than your central sites.

To mitigate these issues, some hardware VPN devices offer authentication to the hardware teleworker device before the VPN session is established. This is shown in Figure 15-4.

Figure 15-4. Hardware VPN Device Authentication

This authentication event generally consists of opening a web page on the gateway and often involves the central site as well to prevent the edge devices from needing to maintain user credential information. The authentication event should be protected by SSL or some other secure mechanism and ideally should use OTP. This authentication provides some assurance that the individual using the hardware VPN device is authorized to do so. Unfortunately, this still does not encrypt the communications between the end system and the hardware gateway. This is by design because our requirement is to have no special software requirements on the end systems. This authentication approach is problematic, though, for the power teleworker who has many systems because some devices might not be able to perform the authentication function requested by the VPN device.

Furthermore, these systems usually limit access only by IP or Media Access Control (MAC) address. Because these attributes can easily be spoofed by the attacker, the resulting security is somewhat suspect. In the end, you really must trust the physical network behind any hardware VPN device. You can do this through a combination of user education, strong policies, automated network audit, and crossed fingers. This is one of the cases in which the business needs can override the security requirements, and there is only so much you as a security architect can do. Because this is a user's home, you can't very well install a security camera or keypad at the front door.

Without these user controls, however, there is no difference between a hardware VPN client and a large site-to-site VPN comprised of very small branch nodes. This is because, without user authentication, you have no Xauth. With no Xauth, you are using device identity only. This makes digital certificates almost mandatory because making authentication decisions on a preshared key alone is not recommended for networks of any reasonable size (Chapter 10). Figure 15-5 shows the hardware-based teleworker design.

Figure 15-5. Hardware-Based Teleworker Security Design

The benefit of these systems is they are often built to be provisioned from the head end. So, you could have hundreds of hardware devices that get software and configuration updates from the central site as needed. This eases the management burden of maintaining the configurations at each site and should be a requirement for your VPN vendor. This same requirement applies to software VPN as well and is fairly pervasive in popular software VPN solutions today.

WARNING

This ease of management is somewhat complicated, though, if you aren't checking user credentials prior to granting VPN access (as described earlier). Here you will need unique preshared keys or digital certificates per device.

The requirements of the hardware VPN device are very similar to the software VPN solution:

• Network or session cryptography The hardware device should support cryptographically secure communications from the device to the central site.
• OTP Users accessing the hardware VPN device can optionally be authenticated prior to VPN access as described earlier in this section.
• Stateful firewall If clear access to the Internet is provided prior to VPN establishment or by split tunneling, a stateful firewall should be supported. This is considered an optional component because most deployments do not support split tunneling (Chapter 10).
• Other router/security features The capabilities of these devices vary greatly from vendor to vendor. In some cases, you might desire quality of service (QoS) controls or more advanced security capabilities (IDS). These functions are considered optional because they are not core to the requirements of this book's teleworker environment (though they may be core to your organization's teleworker requirements).

Physical Security Considerations

As mentioned earlier, your ability to allow a hardware design often depends on some assurances of physical and link level security at the point of teleworker access. Because this is difficult to assure in home environments, you have two options.

First is not to use hardware VPN clients at all. This means systems without the appropriate client software are unable to connect back to the central site. Although this is more secure, there is probably a subset of users that really needs the hardware functionality.

Second, you can provide the hardware connectivity to these users but mandate that they adhere to strict security policies regarding WLAN connections and other security issues local to their site. Assuming the user community using the hardware devices is small, this can work out fine. Because you will find it difficult to audit these locations individually (much like small branch offices), you must trust your users to do the right thing and not connect an insecure WLAN AP behind the hardware device.