Allowing remote access to your network enables your organization's employees to access corporate information from anywhere in the world. It empowers users in remote offices to access valuable network resources as if they were in the main office. However, allowing remote access introduces an entirely new set of security risks. Your job as a security professional is to configure dial-up and VPN connections so that they allow only carefully defined traffic to flow between offices and users without exposing sensitive data or granting unauthorized access.
After this lesson, you will be able to
Estimated lesson time: 30 minutes
Windows 2000 offers two methods for remote users to connect to the local network: dial-up remote access, where the user connects to the network by using a modem, or VPN, where the user connects through a tunnel that's running over an existing network connection. The existing network connection may be the local network or an Internet connection.
Dial-up connections offer access to the greatest number of users because the client requires only a modem and a phone number to connect to a remote access server. The client connects to the remote access server over the Public Switched Telephone Network (PSTN) and establishes a virtual circuit to a listening port on the remote access server, as shown in Figure 13.2.
Figure 13.2 Remote access over a PSTN
In addition to the virtual circuit, the client and server negotiate link control protocol (LCP) parameters that define the authentication protocol and other connection parameters.
Dial-up access is most often used when the dial-up connections are to local phone numbers or toll-free numbers. Dial-up connections are also used to initially access the Internet when establishing VPN connections.
An existing Internet Protocol (IP) connection must exist before you can establish a VPN. The VPN client connects to a listening Transmission Control Protocol (TCP) port on the remote access server using a tunneling protocol such as L2TP or PPTP, as shown in Figure 13.3.
Figure 13.3 Remote access over a VPN
The figure shows that the VPN connection (item 2) requires an existing connection to an IP network (item 1). The connection could be either a dedicated connection, such as a T1 link at the office, or a dial-up connection to an Internet Service Provider (ISP) by the remote access client.
VPN access is commonly implemented to reduce the costs associated with support modem pools for an organization and the long distance costs associated with remote employees.
Table 13.1 shows important factors you should consider when choosing between a dial-up or VPN solution for remote access to a network.
Table 13.1 Choosing Between Dial-Up and VPN Access
|Use||Under the Following Circumstances|
|Dial-up access||Your organization maintains an existing modem pool. |
Most remote connections to the network are through local access numbers and don't require long distance or toll-free charges.
Your organization requires an alternative connection method between offices if a dedicated network link fails.
|VPN access||Your organization wants to outsource modem support to an ISP. |
Users have existing Internet access.
Your organization wants to reduce the costs associated with long distance and toll-free numbers.
Your organization requires faster access speeds than are possible with dial-up networking solutions.
Hanson Brothers requires a combination of dial-up and VPN support for the scenarios presented in this chapter's case study.
Hanson Brothers will provide both dial-up and VPN access to their employees. Providing both forms of access ensures that users with modems and users with high-speed Internet connections can connect to their local office.
The computer connecting to the stock application from Adventure Works requires a dial-up connection. A dial-up connection will allow Hanson Brothers to restrict the connection to a specific phone number.
Finally, the new office in Montréal will require a VPN solution to provide connectivity to the corporate office in Warroad. For redundancy, Hanson Brothers could create a demand-dial connection between the two offices that use telephone lines in case either of the ISP connections at the Warroad or Montréal offices are unavailable. The demand-dial connection would be established only if the VPN were unavailable. Packets destined to the other network would initiate the dial-up connection if the VPN were unavailable.
When a remote user connects to the network, the user must provide credentials to authenticate with the network.
Windows 2000 RRAS supports the following authentication methods:
CHAP authentication requires that the user's password be stored in plaintext or in reversibly encrypted format at the domain controller for comparison purposes. When this attribute is set, the storage of the plaintext password format doesn't take place until the user changes the password after the attribute is enabled.
The Advantage of Two-Factor Authentication
Two-factor authentication adds security to the authentication process by requiring two forms of identification when users are authenticating with the network. For example, smart cards require you to have the physical smart card and know the PIN to access the private key on the smart card. If you don't have both the smart card and the PIN, you can't authenticate with the network.
The same authentication protocols are available for both dial-up and VPN scenarios.
When choosing between remote access authentication protocols, consider the desired level of security and the type of remote access clients that your solution must support. Table 13.2 lists the design decisions you need to consider when choosing whether to implement a remote access authentication protocol.
Table 13.2 Choosing Remote Access Authentication Protocols
|Use||Under the Following Conditions||Level of Protection|
|PAP||No other authentication methods are possible for the remote access connection. |
All connections are dial-up connections. No VPN connections are supported.
Remote access clients don't support any other authentication methods.
|SPAP||You're using Shiva Remote Access servers as NASs. |
You don't require strong encryption methods for access.
|CHAP||Your organization doesn't consider the storage of passwords in reversible encrypted format on the domain controller a security risk. |
Remote access clients are a mix of Microsoft and other operating systems.
|MS-CHAP||You don't wish to store passwords in reversible encrypted format. |
You only need to support Microsoft operating systems for dial-up and VPN connectivity.
You require encryption of data between the remote access client and the NAS.
|MS-CHAPv2||You're using Windows 2000– and Windows NT 4.0–based clients for both dial-up and VPN authentication. |
You're using Windows 95 and Windows 98 clients for VPN authentication only.
Your organization requires mutual authentication of the remote access client and the NAS.
You require encryption of data between the remote access client and the NAS.
|EAP-TLS||Your organization wants to implement two-factor authentication for dial-up and VPN access. |
You're using only Windows 2000 or other operating systems that support smart card authentication.
You require encryption of data between the remote access client and the NAS.
You have a PKI deployed within your organization.
Your organization requires mutual authentication of remote access client and NAS to prevent impersonation of either the user or the NAS.
If you choose multiple authentication protocol support, the authentication protocol that provides the highest level of security supported by both the NAS and the remote access client will automatically be selected by the initial negotiation process.
To provide the strongest form of authentication acceptable to both the remote client and the RRAS server, configure the RRAS server to support MS-CHAP and MS-CHAPv2. While it would be best to support only MS-CHAPv2, Windows 98 clients require MS-CHAP to provide authentication for dial-up connections. Windows 98–based clients only support MS-CHAPv2 for VPN connections. To ensure security, you should enforce strong passwords for all user accounts. Strong passwords help prevent successful dictionary attacks.
Hanson Brothers will implement strong encryption of the user account and password on the remote access connection from Adventure Works. Strong encryption requires you to use MS-CHAPv2 or EAP. Because the Windows NT 4.0 client doesn't support smart card authentication, MS-CHAPv2 is the only authentication protocol that meets this objective.
Because Montréal's third-party firewall won't support PPTP or L2TP/IPSec, IPSec tunnel mode is the only choice for connecting the Montréal office securely to the Warroad office over the Internet. The Montréal office won't be able to implement user authentication for the VPN connection between the offices because IPSec tunnel mode doesn't support user authentication.
You must configure remote access clients and NASs to support a dial-up remote access protocol when using dial-up connections. Windows 2000 supports three remote access protocols for dial-up connectivity:
Table 13.3 shows the design decisions you need to make for choosing remote access protocols supported by Windows 2000.
Table 13.3 Choosing a Remote Access Protocol
|Use||Under the Following Conditions|
|PPP||You need to deploy remote access services for Windows 95, Windows 98, Windows NT 3.5, Windows NT 3.51, Windows NT 4.0, Windows 2000, and most third-party dialers. |
You require negotiation of authentication protocols and remote access session characteristics, such as requiring mutual authentication or encryption of transmitted data.
|SLIP||Your remote access clients must connect to third-party NAS's that support only SLIP communications.|
|AsyBEUI||Your organization must support Windows NT 3.1, Windows for Workgroups, MS-DOS, or LAN Manager–based remote access clients.|
Hanson Brothers will use Windows 2000 RRAS to provide remote user and office connectivity. Because all connecting computers use Windows 98, Windows NT 4.0, or Windows 2000, PPP meets all needs for connectivity.
Because it uses plaintext password transmission, SLIP is supported only for remote access clients. Because there are no UNIX remote access servers involved in the design, you don't need to configure the remote access clients to support SLIP connections. Likewise, there are no Windows NT 3.1, Windows for Workgroups, MS-DOS, or LAN Manager clients. Therefore, you don't need to support AsyBEUI remote access connections.
Windows 2000 supports VPN solutions for both client-to-server and network-to-network connectivity. For client-to-server connections, Windows 2000 supports both PPTP and L2TP/IPSec solutions. In addition, Windows 2000 supports IPSec tunnel solutions for providing network-to-network connectivity. The design decisions don't vary for client-to-network and network-to-network scenarios, although network-to-network solutions can include IPSec tunnel mode.
As mentioned earlier, there are three protocols for VPN connections: PPTP, L2TP/IPSec, and IPSec tunnel mode. The following sections provide an analysis of each VPN protocol choice.
Point to Point Tunneling Protocol (PPTP)
PPTP is supported by Windows 95, Windows 98, Windows NT 4.0, and Windows 2000 remote access clients. Like all VPN protocols, PPTP requires an IP connection to exist before the VPN can be established. PPTP uses MPPE to provide encryption of the transmitted data. MPPE can use 40-bit, 56-bit, or 128-bit encryption keys.
MPPE using 128-bit encryption requires the Windows High Encryption Pack to be installed on Windows 2000–based computers. For legacy clients, the strong encryption patch must be installed. Strong encryption is available only to nonembargoed countries.
PPTP is commonly used to meet the following requirements:
What About the Security Weaknesses Related to PPTP?
The original implementation of PPTP used MS-CHAP as the authentication protocol. If a remote access client used weak user passwords, it was possible to determine the password by using a dictionary attack. The latest update to PPTP has added support for MS-CHAPv2 and EAP authentication to reduce the risk of password determination.
Configuring the tunnel server to allow only MS-CHAPv2 or EAP connections reduces the risk of weak passwords being determined by a dictionary attack. If weak passwords are a major concern, ensure that all remote access clients use Windows 2000 and issue smart cards to use EAP authentication.
If PPTP packets must pass through a firewall, you must configure the firewall to allow the PPTP packets to pass through the firewall. PPTP packets have a destination port of TCP port 1723 and use protocol ID 47 (Generic Routing Encapsulation or GRE).
Layer Two Tunneling Protocol over IPSec (L2TP/IPSec)
L2TP is an alternate method of providing VPN access to the network. As with PPTP, you can use L2TP to provide both client-to-server and server-to-server access. L2TP and PPTP have three major differences:
L2TP is a proposed Internet standard defined in Request for Comment (RFC) 2661. You can obtain a copy of this RFC by going to http://www.ietf.org/rfc and searching for "RFC 2661."
If L2TP/IPSec packets must pass through a firewall, you must configure the firewall to allow IPSec packets destined to the tunnel server to pass through the firewall. The IPSec packets are destined to UDP port 500 on the tunnel server using IPSec Encapsulating Security Payload (ESP) protocol that is identified by protocol ID 50. You don't configure the firewall to pass L2TP packets (destined to UDP port 1701), because the packets are still encrypted when they pass through the firewall.
IPSec Tunnel Mode
IPSec tunnel mode uses Encapsulated Security Payloads (ESPs) to encrypt all traffic passing between the tunnel endpoints. The original IP packets are encrypted within the IPSec tunnel mode packet as they are transmitted across the unsecured network. The data is decrypted when it reaches the endpoint nearest the destination computer. You must consider the following factors when investigating an IPSec tunnel mode solution for network connectivity:
IPSec tunnel mode doesn't provide end-to-end encryption of data. The data is only encrypted as it passes between the tunnel endpoints. You can provide end-to-end encryption by configuring IPSec transport mode to be passed through the IPSec tunnel.
Table 13.4 shows the design factors you should consider when choosing a VPN protocol.
Table 13.4 Selecting a VPN Protocol
|Choose This VPN Protocol||When These Circumstances Exist|
|PPTP||You require client-to-gateway or network-to-network connectivity. |
The VPN must pass through a firewall or perimeter server that performs NAT.
You require VPN support for legacy Windows clients.
|L2TP||You require client-to-gateway or network-to-network connectivity. |
Computer certificates are deployed to all client computers requiring L2TP connections.
You require authentication of the user accounts and authentication of the machine accounts.
The tunnel server isn't located behind a firewall or perimeter server performing NAT.
You plan to implement an IPSec-protected tunnel with the least amount of configuration.
|IPSec tunnel mode||You require only network-to-network connectivity. |
Only machine authentication is required for the tunnel endpoints.
If using certificate-based authentication, the certificates are issued from trusted CAs.
If using preshared keys, the IPSec security associations are configured to only allow connections from the tunnel endpoints.
If IPSec tunnel mode packets must pass through a firewall, you must configure the firewall to allow packets destined to UDP port 500 on the tunnel server. An additional packet filter must be added to restrict connections to using ESP packets (protocol ID 50).
Figure 13.4 shows how the Montréal office would connect to the Warroad office.
Figure 13.4 VPN solution for connecting the Montréal office to the Warroad office
You must configure the external firewall at the Warroad office not to perform NAT. This is required because the third-party firewall at the Montréal office doesn't support PPTP. IPSec tunnel mode can't pass through a firewall if NAT is performed on incoming traffic. To ensure that IPSec tunnel mode works, use an IP address range in the DMZ that's a public network address range.
RFC 1918 describes the three pools of IP addresses reserved for private network usage. The ranges include 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. You can obtain a copy of this RFC by going to http://www.ietf.org/rfc and searching for "RFC 1918."
For employees connecting to the network, you could use either PPTP or L2TP/IPSec. Although the scenario doesn't mention certificates being issued to the computers, it's possible to use L2TP/IPSec in the future based on the network configuration.
You must configure the connection between the Montréal office and the Warroad office to use IPSec tunnel mode because the third-party firewall at the Montréal office doesn't support PPTP or L2TP IPSec. IPSec tunnel mode allows full connectivity between the offices but requires additional configuration.
Because the third-party firewall doesn't support certificate-based authentication, you must configure a preshared key for use by the Windows 2000 tunnel server at the Warroad office and the third-party firewall at the Montréal office. To secure the preshared key, configure IPSec filters to allow only IPSec connections using the preshared key from the other tunnel endpoint. This configuration ensures that if the preshared key is compromised, an attacker will be unable to establish an IPSec tunnel mode connection to the network because the attacker won't be connecting from the correct IP address.
If your network contains a mix of Windows NT 4.0 RAS servers and Windows 2000 remote access servers, you must make special considerations to allow authentication of clients connecting to the Windows NT 4.0 RAS servers.
Windows NT 4.0 RAS servers determine whether a connecting user has dial-in permissions by connecting to a domain controller with a NULL session. A NULL session is a security risk because it doesn't provide credentials for the connection. If you allow NULL sessions on the network, anyone connected to the network can query Active Directory directory service without the default security mechanisms in place.
If you don't allow NULL sessions, a remote access client being authenticated by a Windows NT 4.0 RAS server may face the following authentication results:
The membership of the Pre–Windows 2000 Compatible Access security group is determined by the user creating a new domain in the forest. When you run the Active Directory Installation Wizard (Dcpromo.exe), you're asked if you want to provide support for Windows NT 4.0 RAS servers. If you enable this support, the Everyone group is added to the membership of the Pre–Windows 2000 Compatible Access security group.
You can add the Everyone group to the Pre–Windows 2000 Compatible Access security group by using the command NET LOCALGROUP "PRE–WINDOWS 2000 COMPATIBLE ACCESS"/ADD EVERYONE. You can't add the Everyone group in Active Directory Users And Computers to the domain–local group.
Due to the security implications of allowing unsecured queries to Active Directory, your migration plan should include the early migration of remote access servers to Windows 2000. Once all remote access servers are upgraded to Windows 2000, remove the Everyone group from the Pre–Windows 2000 Compatible Access membership.
When Windows NT 4.0 RAS servers exist on the network, add the following items to your remote access design:
There are no Windows NT 4.0 servers running remote access services in the Hanson Brothers network. To prevent excess rights from being granted to the network, inspect the membership of the Pre–Windows 2000 Compatible Access security group. If the Everyone group is a member, simply delete the group from the existing membership.
The decision to allow users to remotely connect to your organization's network requires careful planning to ensure that security is maintained. Make sure that you identify how the users will remotely connect to the network so that you can include authentication, protocol, and integration decisions in your remote access design.