Security Watch: Secure Access Anywhere

Article
09/07/2016

Security WatchSecure Access Anywhere

John Morello

One of the undeniable trends in technology today is the increasingly connected and mobile workforce. Many organizations have staff that operate from far-flung offices, telecommute, or frequently travel to visit customers. Empowering these users to easily access applications and data, regardless of location, makes them more

productive. However, until recently, enabling secure remote access often meant installing client software, typing in arcane commands, and long connection times.

Over the past several years, a number of approaches have come along to make remote access a simpler and more accessible technology. For example, Outlook® Web Access (OWA) provides a simple, browser-based way for users to access their e-mail, calendar, and contacts without the complexities of a full Layer 3 Virtual Private Network (VPN). While technologies like OWA can supply an important piece of an "anywhere access" solution, most organizations have many key applications that don't permit the same kind of integrated browser experience. In these cases, solutions like Terminal Services provide an effective method for giving users access to their applications from wherever they may be.

In Windows Server® 2008, Microsoft greatly enhanced the "in the box" feature set of Terminal Services. Terminal Services now includes a seamless window, per-application publishing feature called RemoteApp, a universal print driver capability in EasyPrint, and a browser-based portal called TS Web Access. Additionally—and key to the anywhere-access scenario—Windows Server 2008 also includes the TS Gateway component that provides SSL encapsulation for the Remote Desktop Protocol (RDP), allowing it to easily and securely traverse firewalls and Network Address Translation (NAT) devices. The TS Gateway feature also integrates with another new technology in Windows Server 2008, Network Access Protection (NAP), to provide endpoint client health inspection. When all of these components are combined, organizations have the ability to build solutions that let users easily and securely access their applications and data from anywhere.

This column focuses on the network and security design aspects of an anywhere-access solution, rather than providing details on managing the Terminal Service components. I'll describe the methods and best practices for creating such a solution based on technology included with Windows Server 2008.

What's the Problem with Layer 3 Virtual Private Networks?

When thinking about any new technology, it's important to understand its advantages over current approaches so you can accurately assess the value of the new model. In the case of classical Layer 3 VPN, there are typically two major problems that need to be addressed: security and ease of use.

It may seem counterintuitive to list security as a problem with many of today's Layer 3-based VPNs. Isn't the whole point of a VPN to provide a secure tunnel through the Internet? To understand, let's take a higher-level view of what you might typically consider to be VPN threats. I'm not saying that data passing over these VPNs is at risk of interception or tampering; most modern Layer 3 VPNs provide excellent encryption of the data stream. Instead, think of the threats posed by remote machines that are given full "all ports, all protocols" access to your organization's network. The problem is not the data streams the Layer 3 VPNs encrypts and carries over the network, but rather the remote clients connecting through these tunnels that pose increased risk to your internal network. Recall that most organizations impacted by malware like Slammer or Blaster were not infected by machines on their internal network or hackers traversing their firewalls. Instead, the infestation came via remote workers connecting to their networks over VPNs from infected machines. When these VPNs create fully routed, Layer 3-based connections, the remote machine often has as much access (both good and bad) to internal resources as a machine sitting on the datacenter floor.

Moreover, Layer 3 VPNs are often expensive to operate because they require software installation and configuration on machines that are not managed by an organization's IT group. For example, installing a VPN client on a user's home machine may involve creating custom installation packages, detailed installation directions for the user to follow, and troubleshooting conflicts with apps on the user's machine. Moreover, management costs can be high if new versions of the client need to be deployed or configuration data changes (such as adding a new VPN endpoint). For the user, working via this VPN is often a non-intuitive experience. Since it only provides the Layer 3 connection, the user's business apps and data are not made easily accessible and visible to him.

Solving the Problems with Terminal Services

Terminal Services, and other so-called Layer 7 or application layer VPN technologies, solve these two issues by providing much finer control over which resources and protocols users are able to access and by making the end-user experience much simpler and more intuitive than before.

From a security standpoint, the most important differentiating feature between a Layer 3 VPN approach and one that utilizes Terminal Services and TS Gateway is that the connection to the internal network is not a completely open pipeline. Specifically, whereas a Layer 3 approach will create a virtual interface on the local machine with full routing capability into the internal network, the TS Gateway approach only allows RDP-based packets to reach the internal network. Thus, the overall attack surface is greatly reduced and more granular controls can be applied within RDP. For example, while RDP provides native support for drive redirection, organizations could configure their TS Gateways to integrate with NAP and to not allow this capability unless the remote machine could prove that its antivirus software was up-to-date.

For end users, the most obvious difference between a Layer 3 VPN and a Terminal Services-based approach is a vastly simpler setup (often, there is no setup at all) and much easier and more intuitive access to their applications and data. Because the Remote Desktop Connection client is built into Windows (and kept up-to-date through normal servicing technologies like Windows® Update), there is typically no client software to install. Also, by leveraging TS Web Access, users can visit a single URL to find all their applications and data. Simply clicking on the appropriate application starts TS Gateway securely tunneling the connection over the Internet, and the application is seamlessly delivered to the user's desktop. In other words, the application will look and behave as if it is installed locally, including having the ability to copy and paste and minimize to the taskbar. By making applications and data more discoverable and setup instantaneous, a Terminal Server-based approach to remote access successfully increases user satisfaction and reduces support costs.

Network Architecture Choices

There are two basic network design approaches that can be used to make a TS Gateway server available over the Internet. The first sandwiches the TS Gateway into the perimeter network between two Layer 3/4 firewalls. The second keeps the TS Gateway on the internal network and uses an application-layer firewall (such as Microsoft® ISA Server, Microsoft Intelligent Application Gateway, or a variety of third-party solutions) to sit on the perimeter network and inspect inbound HTTPS frames. Only after these inbound sessions have been analyzed are the packets forwarded on to the internal TS Gateway server.

If an organization has only Layer 3/4 firewalls with basic stateful packet inspection, the TS Gateway device can be placed directly in the perimeter network as shown in Figure 1. In this design, the Internet-facing firewall restricts connectivity to the TS Gateway to only allow HTTPS traffic from the Internet to reach it. However, the firewall does no inspection at the application layer of this traffic; it simply forwards the traffic on to the TS Gateway. The TS Gateway server then extracts the RDP frames from the HTTPS packets and forwards them to the appropriate back-end server. These back-end servers are often separated from the perimeter network by a second firewall configured to allow RDP frames from the TS Gateway to reach the appropriate internal servers.

Figure 1 With a Layer 3/4 firewall, the TS Gateway is placed in the perimeter network

Figure 1** With a Layer 3/4 firewall, the TS Gateway is placed in the perimeter network **(Click the image for a larger view)

While this is a fully supported scenario and one that may be useful to many organizations, it has two key disadvantages. First, because the TS Gateway receives traffic directly from the Internet, it is exposed to a relatively higher level of risk from external malicious parties. These malicious parties could attempt to attack the gateway through the SSL session and, because the front-end firewall only checks the headers and not the payloads, these sessions would reach the gateway. This is not to say that the TS Gateway is a vulnerable component; it has gone through the same rigorous security design and testing as the rest of the Windows Server 2008 product. However, its relative risk is higher in this scenario simply because it would be handling unfiltered traffic directly from the Internet. The second major disadvantage is the increased amount of traffic that must be allowed between the gateway and the back-end firewall. To authenticate users, the TS Gateway needs to communicate with Active Directory®. To allow this communication, the back-end firewall must then have exceptions for a much wider range of ports and protocols than simply HTTPS. This increased level of allowed communication again represents an increase in the relative risk of the design.

A better approach for exposing a TS Gateway to the Internet is to use an application-layer (Layer 7) firewall to handle inbound HTTPS sessions before they reach the gateway (see Figure 2). In this design, there may still be the traditional layer 3/4 firewalls forming a perimeter network. But rather than the TS Gateway sitting in the perimeter, the Layer 7 firewall is placed there. As traffic reaches the outward-facing firewall, that firewall filters out everything except HTTPS frames, then forwards those frames on to the layer 7 firewall. The Layer 7 firewall will terminate the SSL session, inspect the unencrypted contents of the stream, block malicious traffic, then send the RDP frames through the back-end firewall and on to the TS Gateway. Note that, if desired, the Layer 7 firewall could also re-encrypt the frames before sending them on to the TS Gateway. This approach may not be necessary on an organization's private network, but it can be very useful in hosted datacenters or shared networks.

Figure 2 Using an application-layer firewall with a TS Gateway device

Figure 2** Using an application-layer firewall with a TS Gateway device **(Click the image for a larger view)

This design avoids both of the disadvantages of the previous solution. Because the TS Gateway server only receives traffic that's been inspected by the Layer 7 firewall, there is less risk of Internet-borne attacks being passed through. The Layer 7 firewall should filter these attacks and only send clean, inspected traffic back to the gateway.

The second major advantage of this solution is in the placement of the gateway relative to the internal network. Because traffic coming from the Internet is inspected by the Layer 7 firewall before reaching the gateway, it can stay on the internal network and have direct access to domain controllers for authentication and RDP hosts for user sessions. Furthermore, the back-end firewall can have a much more restrictive policy. Instead of allowing both RDP and directory authentication traffic, it simply needs to allow RDP sessions from the Layer 7 firewall to the TS Gateway. Using a Layer 7 firewall to front end your TS Gateway deployment provides a more secure solution that's easier to manage without requiring a redesign of your existing perimeter network.

NAP Integration

Terminal Services Resources

While a good perimeter design is a key element of your anywhere-access solution, it's equally important to ensure the compliance and security of your endpoint devices. Because RDP is a rich protocol that allows for many types of device redirection, such as RDP sessions and printers, it's critical that the clients connecting to your solution meet your organization's security policies. For example, even with a secure network topology based on best practices like those discussed earlier, an end user connecting to a terminal server from an unsecure machine can still end up losing confidential data or attempting to put malicious files on to the terminal server. Even though the amount of connectivity and the potential for damage is far less than if that user were connecting over a Layer 3 VPN, it's still important to manage the risk of data loss and ensure compliance with your IT policies.

Network Access Protection (NAP) is a new technology in Windows Server 2008 that allows you to control not just who can connect to your network, but what kinds of systems they can connect from. For example, you can use NAP to ensure that only machines with their firewalls running and antivirus up-to-date can connect to the network. NAP is an extensible solution that covers not just the organization's internal network but also remote users, including both those connecting over Layer 3 VPNs and those connecting through TS Gateway. By integrating NAP with your TS Gateway design, you can ensure that only those systems that meet your security policies can connect to it. For more details on NAP, see my Security Watch column in the May 2007 issue of TechNet Magazine, available online at technetmagazine.com/issues/2007/05/SecurityWatch.

Integrating NAP into a TS Gateway deployment is a straightforward process that involves a single additional service in the design. This service, Network Policy Server (NPS), can be installed either on the TS Gateway server itself or on a separate operating system instance. The TS Gateway MMC is then used to create Connection Authorization Policies (CAP) that define what RDP capabilities are allowed for a given health state. The TS Gateway server is configured to check with NPS each time a new connection is attempted and to forward the Statement of Health (SoH) for that connection to NPS. Network Policy Server then compares the SoH against its policies and informs the TS Gateway whether or not the connection should be allowed based on the health of the client.

As Figure 3 illustrates, if a noncompliant system is not configured to use Windows Update, but the organization's security policy requires that automatic updates be enabled, when a user attempts to connect to the TS Gateway his machine will generate and forward an SoH. This SoH would say something like, "My firewall is on and my antivirus is up-to-date, but automatic updates are disabled." The TS Gateway would simply forward this SoH to the NPS (the TS Gateway has no logic to decode the SoH on its own) and the NPS would compare the SoH against the policies its administrator had defined. Because automatic updates were disabled, NPS would determine that the connection matched the "noncompliant" policy and would inform the TS Gateway to not allow the connection. The TS Gateway would drop the connection and notify the user that the machine did not meet the organization's security policies. The user could then take whatever corrective action was required (in this case, simply enabling automatic updates) and reattempt the connection. As a result, a new SoH would be generated, NPS would determine compliance, and the TS Gateway would allow the connection to proceed.

Figure 3 Only compliant systems can connect

Figure 3** Only compliant systems can connect **(Click the image for a larger view)

Conclusion

Windows Server 2008 includes the key building blocks for a secure anywhere-access solution. TS Gateway provides a secure method for tunneling remote desktop sessions over the Internet and gives organizations a great deal of choice in how it gets integrated into their existing networks. Options include either placing the TS Gateway directly on the perimeter network or using a Layer 7 firewall, like ISA Server or Intelligent Application Gateway, in front of it. NAP can be combined with TS Gateway to add endpoint health inspection capabilities into the solution. The endpoint checks allow organizations to ensure that not only are remote connections coming from valid users, but also that they are coming from machines that are compliant with IT security policies. When combined, these technologies provide organizations with remote access capabilities that are more secure, more efficient to operate, and that offer better experiences for end users. You can find much more information by exploring the sites listed in the "Terminal Services Resources" sidebar.

John Morello has been with Microsoft since 2000. As a Senior Consultant, he has designed security solutions for Fortune 100 enterprise and Federal civilian and defense clients. He's currently a Senior Program Manager in the Windows Server group working on anywhere access technologies. You can read his team's blog at blogs.technet.com/WinCAT.

Additional resources