Software-Based Teleworker Design

The software-based teleworker design makes no assumptions about the security of the location the teleworker will be accessing. The network can be public or private, and the underlying security mechanisms stay the same. For most organizations, this is the teleworker design. The hardware option, discussed next, simply isn't viable from a security standpoint for most networks. Even if it were, most systems sometimes must connect from a location without their hardware VPN device anyway. This means you must deploy solutions for a software teleworker design for these users as well, which complicates systems management and user education.

Design Requirements

This design simply requires that a remote worker be able to securely connect to the central site over a network outside the organization but still maintain access to all, or most, of the organization's applications, data, and other resources.

Design Overview

In this design, a standard PC as defined earlier has an IPsec VPN software client installed along with appropriate keying mechanisms (most likely group preshared with OTP using extended authentication [Xauth]). When the system boots, the crypto connections are initiated to the central site as the user requires. Basic web browsing can, and often does, occur without a VPN connection, making securing the host still very critical. When connected to the VPN, most networks opt to prevent split tunneling because of the security risks. (Split tunneling is discussed in Chapter 10.) The design (as basic as it is) is shown in Figure 15-3. Shown as an optional component is a basic stateful firewall (often used with Network Address Translation [NAT] because of limited consumer broadband address allocations). This component won't aid the security of the communications between the teleworker system and the central site; however, it does lend a bit more security to any other systems connected to the network as well as limit the avenues of attack against the teleworker system from outside networks. The host requirements in the teleworker design match those discussed previously in this chapter with two additions:

• Network or session cryptography The end system should support cryptographically secure communications from the end system to the central site.
• OTP OTP should be used for user authentication to the VPN through Xauth (Chapter 10).

Figure 15-3. Software-Based Teleworker Security Design

NOTE

Although I connect to my employer's network using a software VPN client or SSH and I dutifully keep my system up-to-date on fixes, I have a large number of IP-connected devices in my home that I don't particularly trust. For example, I have an MP3 appliance with an Ethernet connection and almost no security. As a result, I use a stateful firewall between me and the Internet to prevent the unwashed masses from seeing anything useful through network scanning and attempting to connect to every device on my network. Plus, getting the appropriate number of static IP addresses from my Internet service provider (ISP) would be expensive! As a result, I do NAT (begrudgingly) on this device as well. Although I'm a bit apprehensive about Internet Protocol version 6 (see Chapter 18, "Conclusions"), I am looking forward to having lots of IP addresses again and turning off NAT.

The preceding two chapters provided evaluations for each design, but in this chapter (because the same mechanisms are deployed, just on different devices), the evaluations are grouped together at the end. In addition, alternatives are not provided to these designs because there isn't much to change.