Windows Server 2008 : Perimeter Networks and Remote Access Strategies (part 2) - Designing a Remote Access Strategy

2. Deploying Strategic Services in the Perimeter Network

The perimeter network was originally designed to contain Web services for public use. Over time, the decision to deploy specific applications and services there has undergone much change. The perimeter network might contain not only Web services but also many of the following suggested services:

• Application servers for extranets

• VPN servers for remote access

• Wireless access points to provide public wireless access in your enterprise as well as wireless local area networks (WLANs) for internal corporate use

• Terminal Services (TS) Gateway server role

• Components of RADIUS to provide authentication for wireless access, VPNs, and application servers

• Online Certificate Status Protocol (OCSP) servers to provide timely information regarding the revocation status of a certificate in use

This list is not exhaustive but does describe the more commonly deployed services in the perimeter network. This lesson focuses on the Microsoft best practices for perimeter network design and server placement of these services.

Planning Web Services Deployment in the Perimeter Network

Web server services commonly deployed in the perimeter network consist of the following:

• Web servers for Internet and extranet access

• FTP servers

• Publicly accessible Domain Name System (DNS) servers

Web servers offer access over HTTP and HTTPS. Even custom applications built for delivery through a Web server use the same ports, minimizing the number of ports to be opened up through the perimeter firewall. This is the strength of using application servers running Internet Information Services (IIS) 7.0 as the application platform for delivery.

Extranet application servers using Secure Socket Layer (SSL) connections might require the services of an OCSP responder, a server responding to requests for certificate revocation similar to what is provided by a lookup on a certificate revocation list, but an OCSP request and response is less resource intensive and more timely concerning the currency of the information. An OCSP responder can be deployed in the perimeter network because there is usually little concern over security. The OCSP responder signs its response, and the one waiting for the response can check the validity of it by using the public key of the OCSP responder.

DNS servers deployed in the perimeter network provide name resolution for publicly accessible Web services and should be restricted to providing responses only to DNS requests for those services. A host-based firewall that includes anti-malware services along with the removal of all unnecessary services is part of the preliminary setup of a secured host in the perimeter zone.

These Web server services should be deployed at the corporate site and can include an alternate site for site redundancy when providing a solution for a disaster recovery plan. Services at the alternate site should be provided the same considerations regarding security.

Planning IPv6 Access for Web Services

Windows Server 2008 provides complete support for all related Web services over IPv6 although no special consideration is required because all Internet related services require an IPv4 address for appropriate access for the immediate future. Options for migration to IPv6 are already available in Windows Server 2008 for networks employing IPv6 alongside IPv4 for all Web services.

3. Designing a Remote Access Strategy

In designing remote access, an enterprise administrator must consider all required avenues of access. The traditional methods of access have given way to various types of VPN connections and Remote Desktop connections. These two general categories involve many considerations. This portion of the lesson concentrates on deploying VPN servers and providing access for Terminal Server clients.

Planning for VPN Remote Access Connections

As the enterprise administrator, you must make decisions concerning the following:

• Which VPN protocols for remote access are available?

• Which authentication methods should be supported, considering an eventual NAP deployment?

• How should VPN servers deployed for Internet and extranet access be secured?

• What public key infrastructure (PKI) support is needed for VPN access methods?

• How should NAP be integrated with VPN enforcement?

Each of these items has its own unique set of requirements and dependencies. A decision for one can affect the decisions about others. For instance, choosing to use authentication involving certificates can require a supporting PKI. You must then decide how this choice affects your deployment of a NAP solution. In addition, you might require multiple encryption or authentication protocols and services if you are supporting guest access, extranets with partner firms, and your own remote access clients. Each of these groups of users can have different requirements.

You might want to enforce a stringent security policy, but other factors always come into play. These factors, not listed in any order, include:

• Cost

• Compatibility with existing operating systems

• Compatibility with existing application services

• The inevitable politics involved with enforcing security features on guests and extranets

Designing a VPN Protocol Solution

Deciding which VPN protocols to use for your remote access policies depends upon several issues such as:

• Which operating systems your VPN clients use.

• Which security requirements exist regarding encrypted communications.

• Which security policies exist to secure communication through your corporate firewall.

• Which authentication mechanisms are acceptable.

• Whether a need exists to deploy a PKI to support the VPN infrastructure.

VPN Tunneling Protocols

Windows Server 2008 provides support for three tunneling protocols when configuring remote access connections:

• Point-to-Point Tunneling Protocol (PPTP)

• Layer 2 Tunneling Protocol (L2TP)

• Secure Socket Tunneling Protocol (SSTP)

Point-to-Point Tunneling Protocol

PPTP provides a high level of security, still, as a VPN tunneling protocol. Many of the past arguments concerning vulnerabilities were addressed long ago. Its simplicity of deployment as a solution is one of its greatest assets. It is well supported by the operating systems of Microsoft Windows 2000 Professional, Windows 2000 Server, Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008. PPTP has garnered broad support from the IT industry as well as from many vendors, who support its use within their products.

PPTP, when used in a perimeter network, engenders some concerns when a NAT service is between a PPTP client and a server connection. The NAT service must include a NAT editor such as the one found in the Routing and Remote Access service of Windows Server 2003 and Windows Server 2008. Because ISA Server 2004 and ISA Server 2006 both run on Windows Server 2003 and use the services of the Routing and Remote Access service of Windows Server 2003, a NAT editor is also available for use through ISA Server.

To secure the connections to the VPN server, establish inbound and outbound filters for all communication to ensure that only VPN traffic is allowed. Table 1 displays filters you should configure to ensure the security of the VPN server.

Layer 2 Tunneling Protocol

L2TP provides a more secure connection than PPTP due to several aspects. L2TP provides the same user authentication that PPTP provides as well as computer authentication using IPsec authentication. L2TP with IPsec uses 168-bit triple DES (3DES) encryption for the data and provides per-packet data origin authentication, proving the identity of the user and providing data integrity and replay protection while providing a high level of confidentiality.

L2TP has some constraints, however. Every computer must have a computer certificate. The certificate used by the VPN server and the VPN client computer must come from the same trusted root certification authority (CA). If both the VPN server and the VPN client computer are members of a domain, both computers can use autoenrollment to acquire the necessary computer certificate. If one or both computers are not domain members, an administrator must request certificates on their behalf, using the CA Web enrollment tool. The administrator then needs to install the certificate on the computers by using a flash drive or some other external but secure access method. Computer certificates at the time of this writing cannot be issued to smart cards for use with L2TP certificate authentication of the tunnel.

L2TP has an issue as well with firewall services using NAT. L2TP requires NAT Traversal (NAT-T) to pass through a NAT. This means that an extra UDP port, UDP 4500, must be open on the firewall. The clients connecting to a VPN server behind a firewall using L2TP must also support NAT-T. L2TP requires the filters in Table 2 for the perimeter firewall’s Internet interface.

Secure Sockets Tunneling Protocol

SSTP is a new VPN tunnel supported by Windows Vista SP1 and Windows Server 2008. It uses SSL-encrypted HTTP connections for the VPN connection. More specifically, Point-to-Point Protocol (PPP) sessions are encrypted by SSL and transferred over an HTTP connection. This makes using SSTP a great benefit because most companies and organizations such as hotels, Internet cafes, and other Internet hotspots allow TCP port 443 for outbound access. Thus, changes to the firewall are not a great concern when implementing SSTP and deploying the VPN server in the perimeter network.

Another advantage is that SSTP is quite secure. An SSL tunnel is initially formed prior to the transfer of user credentials. SSTP also supports the Extensible Authentication Protocol (EAP) types, Extensible Authentication Protocol-Transport Layer Security (EAP-TLS), and Protected Extensible Authentication Protocol-Transport Layer (PEAP-TLS) for user authentication as well as the Microsoft Challenge Handshake Authentication Protocol (MS-CHAP) v2 authentication methods.

There are some drawbacks to using SSTP. It is supported on Windows Vista SP1 as a VPN client only and on Windows Server 2008 as a VPN client or server. SSTP support will not be added to Windows XP. In addition, users must trust the root certification authority that issued the certificate to the VPN server. VPN clients must have the root CA certificate installed as one of their trusted root CAs to validate this certificate.

Allowing access to a VPN server offering SSTP is fairly simple. More than likely, your firewall is already set to allow access through TCP port 443 for HTTPS. An additional rule is needed only to ensure the passage of TCP port 443 from the border network into the perimeter network to the VPN server perimeter interface.

Authentication Protocols

Windows Server 2008 provides support for quite a few authentication protocols. The list now includes:

• PAP

• MS-CHAP

• MS-CHAP v2

• PEAP-MSCHAP v2/EAP-MSCHAP v2

• EAP-TLS

• PEAP-TLS

The list has dwindled a little because support for Shiva Password Authentication Protocol (SPAP) and the Extensible Authentication Protocol-Message Digest have been removed from Windows Server 2008 and Windows Vista VPNs as client choices. It was thought that these two types of authentication provided little value in securing authentication.

From a security perspective, do not choose Password Authentication Protocol (PAP) and MS-CHAP unless necessary to support an incompatible client. MS-CHAP v2 should be used only when strong passwords are enforced.

Among the supported EAP types, EAP-TLS and PEAP-TLS use certificate-based authentication. PEAP supports two EAP types, PEAP-TLS and PEAP-MSCHAP v2. When PEAP is used with the EAP-MSCHAP v2 type, passwords are used to authenticate the user for the connection. Once again, strong passwords should be enforced to ensure a higher level of security for the connection.

To provide support for certificates when employing certificate-based authentication with either EAP-TLS or PEAP-TLS, users require a user certificate on either a smart card or on their computer. Issuing a certificate through a smart card is not too difficult. Issuing certificates to users who are mostly remote to store on their computers will require one of three solutions:

• Have each user manually request a certificate through either the certificate authority Web enrollment service or the Certificates MMC snap-in.

• Have an administrator request a certificate on the user’s behalf and manually install the certificate in the personal store on the user’s computer.

• Use Group Policy to distribute a certificate to users.

Having each user perform the request individually solves the dilemma of distributing certificates in most cases. The issue becomes a support problem if too many users need assistance or other technical difficulties arise. The final answer, to use Group Policy, is probably the most efficient but can also have problems. Some users using laptops might not be connected to the network, or the computer itself might not be part of the corporate domain for one reason or another. In most cases, Group Policy works for the majority of users. Traveling users using laptops that are part of the domain need to connect and log on to the domain as part of the process of acquiring a certificate through Group Policy.

Another concern when setting up the environment for remote access connectivity is whether NAP will be instituted in the near future. For VPN connections, NAP includes a VPN enforcement point, which requires a connecting client to use one of the PEAP types for authentication. In choosing which PEAP type to use, PEAP-MSCHAP v2 or PEAP-TLS, PEAP-TLS holds the advantage as a superior authentication protocol for two reasons:

• It does not use a password for authentication but uses a certificate as previously noted.

• PEAP-TLS is superior to EAP-TLS because the exchange of certificates for authentication takes place after the client and the server have created an encrypted tunnel.

The disadvantage in using PEAP-TLS over PEAP-MSCHAP v2 is that all users now require a certificate whereas PEAP-MSCHAP v2 requires only a server certificate. An issue in using PEAPMSCHAP v2 concerns the certificate issued to the VPN server performing the authentication. If the certificate issued to it is from one of the established trusted public root certification authorities, no other work is required other than purchasing the certificate itself. If the certificate is issued from a standalone root CA by the internal enterprise PKI, then a copy of its certificate needs to be installed on all computers connecting to the VPN using PEAP-MSCHAP v2 for authentication. If the certificate is issued from an enterprise CA, the certificate for the root CA must be distributed through the Web enrollment, the Certificates console, or another manual method.

Designing Secure VPN Server Deployment

When considering the placement of VPN servers, it has become customary for the VPN servers to be deployed in the perimeter network. Although there are established guidelines for deploying the VPN server outside of the perimeter firewall, it is considered a best practice to deploy the VPN server inside the perimeter zone, behind the perimeter firewall. The previous IP filter tables, Table 5-1 and 5-2, outline the best practices for opening up access to the VPN servers deployed inside the perimeter network.

If the branch offices need VPN connectivity, two choices are available:

• Direct VPN connectivity to VPN servers located at the branch offices

• Centralized management of VPN access to one main office and ensured VPN client access to resources located in their respective branch offices

VPN Server Deployment at Branch Offices

If VPN servers are to be deployed at the branch offices, you must give the same consideration when setting up access through the firewall there. The VPN server should be deployed in a perimeter network, often termed a screened subnet, as Figure 4 displays. Availability of affordable firewalls such as ISA Server can provide a perimeter network and secure access to resources such as a VPN server, making securing a colocated VPN server an easier chore. Companies can standardize how branch office access is achieved to relieve the complications involved in planning each deployment.

Centralized Management of VPN Access

Clients accessing resources through VPN servers that are centrally located can still access resources anywhere within the enterprise. Because a VPN connection to a VPN client essentially is offering a local area network (LAN) connection remotely, a VPN client will also have access anywhere on that LAN that a normal wired LAN client has access. This is both an advantage and a plausible security issue.

The obvious advantage is the ease in offering resources to the remote client. The VPN client can be anywhere Internet access is available to gain access to data and application servers on your enterprise network in a secure manner. To mediate any possible security issues, the VPN server can enforce strict network routing rules to allow the client access to specific segments of the network. In addition, filter rules can be applied to the VPN connection to disallow a curious VPN client from wandering into areas of the network deemed out of bounds. Because a user with sufficient rights locally can administer his or her own routing tables, the VPN administrator needs to be aware that such users can circumvent simple security applied through routing rules. Inbound IP filters and policies applied to the VPN connection can disable a user’s ability to browse networks that are not authorized by the connection.