Configuring Virtual Private Networks for Remote Clients and Networks

Benefits of Using VPNs
The primary benefits of using VPNs are as follows:
1- Reduced costs Using the Internet as a connection medium saves long-distance phone expenses and requires less hardware than a dial-up networking solution. In the case of a site-to-site VPN, using the Internet as a WAN is also less expensive than using a dedicated WAN connection.

2- Security Authentication prevents unauthorized users from connecting to the VPN servers. Strong encryption methods make it extremely difficult for an attacker to interpret the data sent across a VPN connection.

3- Flexibility By using VPNs, the organization does not need to manage Internet connections or dial-up servers for remote users. The users need only be able to connect to the Internet using whatever technology is available.

4- Transparency to applications One of the significant advantages of using a VPN connection, rather than an alternative solution such as a client/server Web application, is that VPN users at remote locations can potentially access all protocols and servers on the corporate network. The remote-access VPN user does not need special software to connect to each of these services, and the network and firewall administrator does not need to create special proxy applications to connect
to these resources.

VPN Protocol Options
VPN security is based on the tunneling and authentication protocols that you use and the level of encryption that you apply to VPN connections. ISA Server 2004 supports two VPN tunneling protocols for remote-access connections: PPTP and L2TP/IPSec.

PPTP
PPTP uses Point-to-Point Protocol (PPP) user authentication methods and Microsoft Point-to-Point Encryption (MPPE) to encrypt IP traffic. PPTP supports the use of Microsoft Challenge Handshake Authentication Protocol Version 2 (MS-CHAP v2) for password-based authentication. For stronger authentication for PPTP connections, you can use smart cards or certificates to implement Extensible Authentication Protocol/Transport Level Security (EAP/TLS) authentication.
PPTP is widely supported and easily deployed, and it works with most network address translators (NATs). Although it is not considered as secure as IPSec, a PPTP-based VPN solution can reduce costs associated with implementing a certificate infrastructure and is less complex to administer than IPSec because it does not require digital certificates.

L2TP/IPSec
L2TP/IPSec is the more secure of the two VPN protocols, using PPP user authentication methods and IPSec encryption to encrypt IP traffic. You can also use certificate-based computer authentication to create IPSec security associations in addition to PPP-based user authentication. L2TP/IPSec provides data integrity, data origin authentication, data confidentiality, and replay protection for each packet.

VPN Authentication Options
In addition to selecting a VPN tunneling protocol, you must also choose an authentication protocol and choose whether to use a RADIUS or RSA SecurID for authentication. Choosing the appropriate authentication mechanism is essential when designing a VPN implementation because not all VPN clients support the most secure authentication options. The authentication mechanism should be as secure as possible while still enabling VPN client access.

MCP 70-299 : 8 - Planning and Configuring IPSec

Lesson 2: Planning an IPSec Infrastructure

Active Directory Considerations :

For organizations with large numbers of computers that must be managed in a consistent way, it is best to distribute IPSec policies by using Group Policy objects (GPOs). Although you can assign local IPSec policies to computers that are not members of a trusted domain, distributing IPSec policies and managing IPSec policy configuration and trust relationships is much more time-consuming for computers that are not domain members. Another advantage of using Active Directory–based IPSec policy is that you can delegate permissions on the IP Security Policies On Active Directory container to enable specific administrators to manage IPSec throughout your organization.

These administrators do not necessarily need permissions to directly manage the individual computers
that will receive the IPSec policy, however. This capability is vital to organizations that divide responsibility for security tasks between various groups. To delegate permissions on the IP Security Policies container, you must use an Active Directory editing tool, such as ADSI Edit. ADSI Edit is a Windows support tool that uses the Active Directory Service Interfaces (ADSI). The Windows support tools can be installed from the \Support\Tools folder on the Windows 2000 and Windows Server
2003 operating system CDs.

Authentication for IPSec :

Peer authentication is the process of ensuring that an IPSec peer is the computer it claims to be. By using peer authentication, IPSec can determine whether to allow communications with another computer before the communication begins. You can choose from three authentication methods: Kerberos v5, public key certificates, and preshared keys.
If you have deployed a Windows 2000 or Windows Server 2003 Active Directory environment, and all hosts that will be using IPSec are part of that domain (or a member of a trusted domain), then you should use Kerberos. If you are communicating with outside organizations, and your partners use a Web-based CA, you can use public key certificates. If neither of these methods is available, you can use a preshared key.

Public key certificates authentication :

A public key infrastructure (PKI) can be used to authenticate and encrypt communications for a wide variety of applications, including Web applications, e-mail, and IPSec.
Although using public key certificates is not as convenient as using Kerberos, there are specific circumstances for which certificates are the logical choice for authentication in IPSec. Specifically, you should use public key certificates when you need to communicate privately with external business partners or other computers that do not support the Kerberos v5 authentication protocol.
IPSec’s use of certificate authentication is compatible with many different PKI architectures, and IPSec places relatively few requirements on the contents of a certificate. Typically, computers that have a common trusted root, or whose certificates can chain through a cross-certification trust relationship, can successfully use IPSec authentication. To use certificates for IPSec authentication, you define an ordered list of acceptable root CA names in the authentication method. This list controls the certificates that IPSec can select and the certificates that IPSec will select.

Preshared key authentication :

If both IPSec peers are not in the same domain and do not have access to a CA, a preshared key can be used. For example, a standalone computer on a network that does not connect to the Internet might need to use a preshared key, because neither Kerberos authentication through the computer’s domain account nor access to a CA on the Internet is available. A preshared key is a shared secret key (basically a password) that has been agreed upon by administrators who want to secure the computers’ communications by using IPSec. Administrators must manually configure their systems to use the same preshared key.
The preshared key authentication method uses symmetrical encryption to authenticate the hosts, which itself is very secure, but which requires that any two hosts communicating have been configured with a predefined password. Unfortunately, this key is not stored securely on the IPSec hosts. The authentication key is stored in plaintext format in the system registry and hex-encoded in Active Directory–based IPSec policy. If attackers can access your registry, they can find your preshared key, which would allow them to decrypt your traffic or impersonate one of the hosts. Use preshared key authentication only when no stronger method can be used.

Testing IPSec

As a rule, you should perform extensive testing before making any changes to your infrastructure. This rule certainly holds true when planning to use IPSec. IPSec has the potential to interfere with all network communications and, as a result, can break any network applications that your organization uses.
Begin testing IPSec in a lab environment. Configure computers with the client- and server-side of your critical applications, and verify that the lab is functional and accurately simulating the production environment. Your lab environment should have computers with each of the potential IPSec client operating systems, because different operating systems support different IPSec functionality. Develop performance metrics for each of your applications, and gather baseline performance data that you can use for comparison after IPSec has been implemented. Then implement IPSec policies on the lab computers.
Not all network equipment provides the same IPSec capabilities, and you should use the testing phase to determine which network devices need configuration changes or upgrades. Add firewalls, proxy servers, and routers to the lab environment to simulate the potential for those devices to interfere with IPSec communications in the production environment. If you plan to use IPSec for remote access, be sure to include a remote access client in your lab environment, and have that client connect from a typical remote network. If employees will use IPSec to connect to your internal network from home, test IPSec across a variety of commonly used home routing equipment. Test non-IPSec-enabled clients with IPSec-enabled servers. Even if you plan to deploy IPSec to every computer, there will be a transition period during which some computers will not yet have received the IPSec configuration.
After IPSec clients and network equipment have been configured in the lab environment, test the application functionality. If you identify problems, document the problems and solutions so that they can be quickly resolved if they appear in the production environment. Besides verifying that applications function, verify IPSec functionality. If you allow IPSec clients to use unsecured communications if IPSec negotiations fail, it is possible for applications to appear to be compatible with IPSec when the computers were unable to establish an IPSec session.

MCP 70-299 : Assessing and Deploying a Patch Management Infrastructure

Lesson 1: Assessing Patch Levels

The MBSA Console :

Microsoft Baseline Security Analyzer (MBSA), which was also discussed in Chapter 4, is used to analyze one or more computers for vulnerabilities in two categories: weak security configurations and missing security updates. This section focuses on using MBSA to scan for updates that should have been installed but have not been.
After installing MBSA, you can use it to scan all computers on your network or domain for which you have administrator access. To scan all computers on a specific subnet using your current user credentials:
1. Start MBSA by clicking Start, pointing to All Programs, and then clicking Microsoft Baseline Security Advisor.
2. On the Welcome To The Microsoft Baseline Security Analyzer page, click Scan More Than One Computer.
3. On the Pick Multiple Computers To Scan page, type the IP address range you want to scan. To speed up the scanning process, clear all check boxes except for Check For Security Updates. If you have a Software Update Services (SUS) server on your network, you can further speed up the process by selecting Use SUS and specify
4. Click Start Scan. As MBSA performs the scan, it will keep you updated on the progress,
5. After the scan is completed, the View Security Report page appears, listing the computers that were scanned.

MBSACLI :

Scanning a large network should be done on a regular basis to find computers that have not been properly updated. However, scanning a large network is a time-consuming process. While the MBSA console is the most efficient way to interactively scan a network, the Microsoft Baseline Security Analyzer command-line interface (MBSACLI) provides a way to script an analysis. By using scripts, you can schedule scanning to occur automatically, without your intervention. In this way, you can have MBSACLI generate a report that you can refer to on demand.
Another good reason to schedule scans by using MBSACLI is to scan from multiple points on your network. For example, if your organization has five remote offices, it is more efficient to scan each remote office by using a computer located in that office. This improves performance, reduces the bandwidth used on your wide area network, and allows you to scan computers even if a perimeter firewall blocks the ports that MBSACLI uses to scan.

Lesson Summary :

■ The graphical MBSA console is the most efficient way to scan a single computer or multiple computers for the presence of updates.
■ The graphical MBSA console can be configured to scan a single computer, a range of IP addresses, or all computers contained within a domain.
■ MBSA stores reports in XML format in the C:\Documents and Settings\username\SecurityScans folder by default. At any time, you can view these reports by using MBSA.
■ MBSACLI provides a command-line interface to MBSA’s scanning functionality. MBSACLI functions in two modes: standard MBSA mode and the backward compatible HFNetChk mode.
■ Scanning a large number of computers can take several hours and consumes significant network resources. Therefore, you should schedule the scanning to occur after business hours by using the command-line tools.