Implementing a VPN infrastructure must be planned carefully because you are deliberately exposing your internal network to the Internet. In many cases, VPN clients have complete access to the internal network, just as if the client computer were connected to the internal network behind the ISA Server computer. This means that your VPN implementation must be as secure as possible.
Use the following guidelines when planning your ISA Server VPN implementation:
1- For the highest level of security, implement a VPN solution that uses L2TP/IPSec,MS-CHAP v2, or EAP/TLS for user authentication and certificate-based authentication for computer authentication. With this configuration, you must deploy certificates to all remote-access clients. However, the certificate authentication means that only computers that have the appropriate certificate will be able to connect.
2- You can also deploy PPTP using certificate-based authentication. In this scenario,you can use two-factor authentication, with devices such as smart cards, to ensure the identity of the remote client. Although this option provides a more secure means to authenticate the remote-access user, it does not provide an option for authenticating the remote-access client computer.
3- If you do not have the option of deploying client certificates to all VPN clients or using smart cards, the most secure option is to use PPTP with password authentication. When you use PPTP, the data is encrypted; however, the authentication mechanism is not as secure. If you use password-based authentication, ensure that you enforce strong passwords by using Group Policy.
4- Always use the most secure protocols that both your VPN access servers and clients can support and configure the remote-access server and the authenticating server to accept only secure authentication protocols. If you have older VPN clients that do not support secure authentication protocols, consider not enabling VPN access for these clients. Only enable VPN access for these clients if there is a strong business need to do so, and if you do not have the option of upgrading the clients.
5- ISA Server 2004 allows you to use pre-shared keys in place of certificates when creating remote-access and gateway-to-gateway VPN connections. Pre-shared keysupport for IPSec-based VPN connections should be used only for testing purposes. A single remote-access server can use only one pre-shared key for all L2TP/IPSec connections requiring a pre-shared key for authentication. This means that you must issue the same pre-shared key to all L2TP/IPSec VPN clients. Unless you distribute the pre-shared key within a Connection Manager profile, each user must manually enter the pre-shared key into the VPN client software settings. This reduces the security of the L2TP/IPSec VPN deployment.
6- Using RADIUS for authentication does not increase the level of security for VPN connections. The only advantage of using RADIUS is that you can centralize policy management for multiple ISA Server computers acting as VPN remote-access servers.
7- Using SecurID can significantly increase the level of security for the VPN connections because SecurID requires access to the token that provides a one use password. However, deploying SecurID significantly increases the complexity of the VPN server deployment.
Guidelines for Planning a VPN Infrastructure
MCP 70-350 : Installing ISA Server 2004
Network Infrastructure Requirements :
For your ISA Server implementation to succeed, you must ensure that the network infrastructure
supports the ISA Server implementation. To support your ISA Server infrastructure, the following networking services must be installed and configured on your network:
- DNS
- Domain controllers
- DHCP
These supporting services are critical to the proper functioning of your ISA Server network infrastructure.
Domain Name System Requirements
To connect to resources on the Internet, client computers must be able to resolve the DNS names for servers on the Internet to IP addresses. If you publish internal servers to the Internet, users on the Internet must be able to resolve the DNS names for the published servers to an IP address. To enable both of these scenarios, a DNS infrastructure must be in place to provide name-resolution services.
To enable access to Internet resources, ensure that all client computers can resolve Internet DNS names. At a high level, you have two options for enabling name resolution for Internet resources: You can use an internal DNS server that can resolve both internal and Internet DNS addresses, or you can use an external DNS server to resolve IP addresses on the Internet.
To Use an Internal DNS Server Many organizations have deployed DNS servers on their internal networks. If you have deployed Active Directory in Microsoft Windows 2000 Server or in Windows Server 2003, DNS is required for domain replication and user authentication, so all client computers running Windows 2000 or later must be able to resolve the DNS names for domain controllers. In this environment, the internal DNS server is configured with DNS zones for your Active Directory domains.
To allow internal users to access Internet resources, the internal DNS servers must also be configured to resolve Internet DNS names. One way to enable this is to configure the DNS servers to forward all requests for Internet name resolution to DNS servers on the Internet. When you configure a DNS server to use a forwarder, it sends to the forwarder requests for domains for which it is not authoritative.
To Use an External DNS Server Some organizations have not deployed internal DNS servers or have not configured the internal DNS servers to resolve Internet DNS addresses. In this situation, all Internet name resolution must be performed by DNS servers on the Internet. You have two options to enable this. If you use Web Proxy clients and Firewall clients, ISA Server can function as a DNS proxy server to resolve Internet DNS requests on the client’s behalf.
Domain Controller Requirements :
If you want to restrict access to Internet resources based on user accounts, or if you want to require authentication before users can access published servers, ISA Server must be able to access a directory of user accounts to determine whether the user should have access. ISA Server provides several options for authenticating the users, including Remote Authentication Dial-In User Service (RADIUS), RSA SecureID, or the local user account database on the computer running ISA Server. However, the easiest option to implement for most organizations is to use a domain directory service to authenticate the users. Most organizations already have a domain infrastructure that includes all the user accounts; in such cases, ISA Server can use this directory service to authenticate user
accounts.
You can use Windows 2000, Windows Server 2003, or Windows NT 4 domains to perform this service. To use the domain for authentication, the server running ISA Server must be a member of the domain. In addition, ISA Server must be able to communicate with the domain controllers on the internal network. If you use Active Directory in Windows Server 2003 or Windows 2000, you must configure the internal network interface on the ISA Server computer with the IP address of a DNS server that can resolve the IP addresses for the local domain controllers.
70-299 : 10 Planning and Implementing Security for Wireless Networks
Designing the Authorization Strategy :
Although many organizations choose to allow all computers and users in the organization to access the wireless network, other organizations choose to restrict access. On Windows networks, you will restrict access to wireless networks by using domain security groups. Although it is possible to use the dial-in properties of domain user objects to allow and deny access to individuals, this is tedious to administer for more than a few users.
One method for implementing this is to create a three-tiered structure for assigning permissions. At the top level, create a universal group, and grant this universal group access by using a remote access policy in IAS. At the second level, create domain global groups for users and computers that will be granted wireless access. Add to these security groups users and groups that should be granted wireless access.
Regardless of which authentication method you choose, you will need at least one computer certificate to use 802.1X authentication. This certificate must be installed on the IAS servers that will perform RADIUS services. For computer authentication with EAP-TLS, you must also install a computer certificate on the wireless client computers. A computer certificate installed on a wireless client computer is used to authenticate the wireless client computer so that the computer can obtain network connectivity to the enterprise intranet and download computer Group Policy settings prior to user logon. For user authentication with EAP-TLS after a network connection is made and
the user logs on, you must use a user certificate on the wireless client computer.
If the certificate of the root CA that issued the IAS servers’ certificates is already installed as a root CA certificate on your wireless clients, no other configuration is necessary. If your issuing CA is a Windows 2000 Server or Windows Server 2003 online root enterprise CA, the root CA certificate is automatically installed on each domain member through computer configuration GPO settings. If it is not, you must install the root CA certificates of the issuers of the computer certificates of the IAS servers on each wireless client.
Configuring IAS :
IAS is a component of Windows Server 2003 that provides RADIUS services capable of authenticating users based on information contained within Active Directory. When configuring the security of a wireless network, you must configure the IAS server to use specific authentication methods and to grant access to authorized users. This configuration is done by using two types of policies: Remote Access Policies (RAP) and Connection Request Policy (CRP).
The RAP controls how or whether a connection is authorized to the network. A RAP contains a set of policy conditions that determine whether that policy applies to a given connection request. When configuring a RAP for wireless network access, you can create policy conditions that specify the Active Directory security group that a client must be a member of, the time of day, or the connection type of the requesting client, as shown in Figure 10.3. A RAP is also configured to allow or deny the connection request. If there are multiple RAPs on an IAS server, each connection request is evaluated against them according to the priority until a matching RAP either allows or denies the request.
Regardless of the EAP type you choose, you can select a computer certificate that the IAS server will present to the wireless client. If the IAS server has only one computer certificate, this certificate will automatically be selected. If you choose the PEAP authentication method, you also have the option to enable fast reconnects. Generally, you should select the Enable Fast Reconnect check box on the Protected EAP Properties dialog box to improve performance when wireless clients switch from one WAP to another.
Configuring Wireless Clients :
The first step to configure a wireless client is to ensure that the computer has the software required to authenticate and connect to your wireless network. Computers running Windows 2000 require the Microsoft 802.1X Authentication Client, available from http://support.microsoft.com/?kbid=313664. Additionally, you must start the Wireless Zero Configuration service and set its startup type to Automatic. If you plan to use WPA with any Windows client, including Windows XP and Windows Server 2003, you must install the Windows WPA client update on all clients. You can download the client from http://support.microsoft.com/?kbid=815485.
Windows XP and Windows Server 2003 wireless clients have an Authentication tab in the properties dialog box for a wireless connection, as shown in Figure 10.7. On this tab, you can enable 802.1X authentication, specify and configure the EAP type, and choose the sets of credentials that the computer will use for the authentication.
Select the Enable Network Access Control Using IEEE 802.1X check box to use 802.1X authentication for the network connection. You can leave this option selected even if you have not yet configured 802.1X. If the check box is selected, the computer will attempt to perform an 802.1X authentication when the network interface is initialized. If the computer does not receive a response to its authentication requests, the computer will behave as though the connection does not require authentication. Therefore, it is always okay to leave this check box selected.
Use the EAP Type list to specify the EAP type to use for IEEE 802.1X authentication. By default, you can choose from Protected EAP (PEAP) and Smart Card Or Other Certificate. However, other options will be listed if an application has installed additional EAP libraries.
10 Planning and Implementing Security for Wireless Networks
802.1X authentication :
Although the early implementations of WEP were woefully inadequate, WEP’s vulnerability can be significantly reduced by using 802.1X authentication. 802.1X enables WEP to regularly change the encryption keys, which dramatically reduces the likelihood that an attacker will be able to gather enough data to identify the shared secret.
802.1X employs an Internet Engineering Task Force (IETF) standard protocol called Extensible Authentication Protocol (EAP) to carry the authentication conversation between the client, the WAP, and a Remote Access Dial-In User Server (RADIUS) service. As part of the 802.1X secure authentication process, the EAP method generates an encryption key that is unique to each client. RADIUS forces the client to generate a new encryption key on a regular basis, which makes it more difficult for an attacker to capture enough traffic to identify a key. This allows existing WEP-capable hardware to be used while minimizing WEP’s vulnerabilities.
Specifically, the client must perform the following steps to connect to an 802.1Xauthenticated
wireless network:
1. When the client computer is in range of the WAP, it will try to connect to the Service Set Identifier (SSID) hosted by the WAP. If the client has been configured with shared network authentication, it will authenticate itself to the WAP by using the network key. Because the WAP is configured to allow only 802.1X-authenticated connections, it issues an authentication challenge to the client. The WAP then sets up a restricted channel that allows the client to communicate only with the RADIUS service.
2. The wireless client examines the RADIUS server’s public key certificate to ensure that an attacker is not impersonating the RADIUS server. The client then attempts to authenticate, using 802.1X, to the RADIUS service.
❑ If the client and RADIUS service have been configured to use Protected EAP (PEAP) authentication, the client establishes a Transport Layer Security (TLS) session with the RADIUS service and then transmits credentials using the configured authentication protocol.
❑ If the client and RADIUS service have been configured to use EAP-TLS authentication, the client authenticates by using public key certificates.
3. The RADIUS service checks the client credentials against the directory. If it can authenticate the client’s credentials and the access policy allows the client to connect, it will grant access to the client. The RADIUS service relays the access decision to the WAP. If the client is granted access, the RADIUS service transmits the dynamic shared secret to the WAP. The client and WAP now share common key material that they can use to encrypt and decrypt the traffic that will pass between them.
4. The WAP then bridges the client’s connection to the internal network, completing the 802.1X authentication process. If the client is configured to use Dynamic Host Configuration Protocol (DHCP), it can now request a lease.
PEAP :
PEAP is typically used to authenticate wireless clients by using a user name and password; EAP-TLS is used to authenticate wireless clients by using public key certificates. Although using a user name and password is not as strong as using public key certificates, because passwords can be stolen or guessed, the resulting encryption is still very strong. When PEAP authentication is used with a RADIUS service that forces encryption keys to change regularly, the resulting WEP encryption is not likely to be compromised in a reasonable amount of time. PEAP’s primary advantage over EAP-TLS
is that it is easier to deploy because it does not require you to implement a Public Key Infrastructure (PKI).
The PEAP authentication method has two phases. Phase 1 authenticates the RADIUS server by using the RADIUS server’s public key certificate and then establishes a TLS session to the RADIUS server. Phase 2 requires a second EAP method tunneled inside the PEAP session to authenticate the client to the RADIUS service. This allows PEAP to use a variety of client authentication methods.
EAP-TLS :
EAP-TLS performs the same functions as PEAP by authenticating the client computer and generating keying material that will be used for encrypting the wireless communications. However, EAP-TLS uses public key certificates to authenticate both the client and the RADIUS service. EAP-TLS was designed by Microsoft and is based on an authentication protocol that is nearly identical to the protocol used in the Secure Sockets Layer (SSL) protocol for securing Web transactions. While public key certificates provide strong authentication and encryption, you should only use EAP-TLS if you already have a PKI in place for another application or your organization’s security requirements do not allow simple password authentication.
RADIUS :
RADIUS is a standardized service used primarily to authenticate dial-up users. Windows Server 2003 includes a RADIUS service and proxy named IAS. The traditional use for IAS on Windows networks is to allow an Internet Service Provider (ISP) to authenticate an organization’s users based on the Active Directory domain credentials stored on the organization’s private network.
Because RADIUS is designed to allow network hardware to authenticate against an external user database, WAPs also can use RADIUS to authenticate wireless users as they join the network. Authenticating to a RADIUS service allows user authentication for wireless networks to be centralized, rather than forcing administrators to store user credentials on each WAP.
MCP 70-299 : Installing, Configuring, and Managing Certification Services
Cryptography and Encryption :
Cryptography is essential for the secure exchange of information across intranets, extranets, and the Internet. From a technical point of view, cryptography is the science of protecting data by mathematically transforming it into an unreadable format, otherwise known as encryption. To a business, cryptography is a means to reduce the likelihood of a costly security compromise by providing authentication, confidentiality,
and data integrity.
Network encryption comes in two main varieties: shared key encryption and public key encryption. Shared key encryption requires both the sender and the recipient of an encrypted message to have a shared secret—a password that can be used to encrypt and decrypt the message. Shared key encryption is easy to understand, but it is difficult to implement on a large scale. After all, to allow secure communication between 1,000
employees at a company would require about 1 million passwords to be exchanged, because any two users who wanted to communicate would need to exchange a unique password.
For example, if Sam wants to send an encrypted electronic message to Toby, Sam first walks over to Toby and whispers a password in his ear. Then, when Toby receives the electronic message, Toby decrypts it with the password. As long as nobody else knows the password, Sam can be sure that the contents of the message are private.
Public Key Infrastructure :
Public key encryption wouldn’t be any easier than shared key encryption if everyone had to manually exchange public keys. That’s why we use a PKI—to make the process of managing and exchanging public keys simpler. A PKI is a set of policies, standards, and software that manages certificates and public and private keys. A PKI consists of a set of digital certificates, certification authorities (CAs), and tools that can be used to authenticate users and computers and to verify transactions. In order to place the PKI implementation provided by Windows Server 2003 in the proper context, this section
provides a general overview of the components that make up a PKI.
Certificates :
A public key certificate, referred to in this chapter as simply a certificate, is a tool for using public key encryption for authentication and encryption. Certificates are issued and signed by a CA, and any user or application that examines the certificate can safely assume that the CA did indeed issue the certificate. If you trust the CA to do a good job of authenticating users before handing out certificates, and you believe that the CA protects the privacy of its certificates and keys, you can trust that a certificate holder is who he or she claims to be.
Certificates can be issued for a variety of functions, including Web user authentication, Web server authentication, secure e-mail, encryption of network communications, and code signing. CAs even use certificates to identify themselves, create other certificates, and establish a certification hierarchy between other CAs. If the Windows Server 2003 enterprise CA is used in an organization, clients can use certificates to log on to the domain.
Certificates contain some or all of the following information, depending on the purpose of the certificate:
■ The user’s principal name.
■ The user’s e-mail address.
■ The computer’s host name.
■ The dates between which the certificate is valid.
■ The certificate’s serial number, which is guaranteed by the CA to be unique.
■ The name of the CA that issued the certificate and the key that was used to sign the certificate.
■ A description of the policy that the CA followed to originally authenticate the subject.
■ A list of ways the certificate can be used.
■ The location of the certificate revocation list (CRL), a document maintained and published by a CA that lists certificates that have been revoked. A CRL is signed with the private key of the CA to ensure its integrity.
Certification authorities :
A CA is an entity trusted to issue certificates to an individual, a computer, or a service. A CA accepts a certificate request, verifies the requester’s information according to the policies of the CA and the type of certificate being requested, generates a certificate, and then uses its private key to digitally sign the certificate. A CA can be a public third party, such as VeriSign, or it can be internal to an organization. For example, you might choose to use Windows Server 2003 Certificate Services to generate certificates for users and computers in your Active Directory directory service domain. Each CA can have distinct proof-of-identity requirements for certificate requesters, such as a domain account, an employee badge, a driver’s license, a notarized request, or a physical address.
Registration is the process by which subjects make themselves known to a CA. Registration can be accomplished automatically during the certificate enrollment process, or it can be accomplished by a trusted entity such as a smart card enrollment station. Certificate enrollment is the procedure that a user follows to request a certificate from a CA. The certificate request provides identity information to the CA, and the information the user provides becomes part of the issued certificate.
