Installing and Configuring the Firewall Client

How to Install Firewall Client :
When you install ISA Server, you have the option of installing the Firewall Client Share on the ISA Server computer. When you choose this option, the Firewall Client installation files are copied to the server in the C:\Program Files\Microsoft ISA Server\Clients folder. The folder is then shared with a share name of Mspclnt. Moreover, the system policy rule that enables access to the shared folder is enabled. To install the Firewall Client manually, users can connect to the share and run the setup program.
To install the Firewall Client software from a shared folder, use the following procedure:

1. Connect to the shared folder that contains the Firewall Client installation files. If you use the shared folder on the ISA Server computer, the default share name is ISA_Server_name/MSPClnt.
2. Right-click MS_FPC.msi and click Install. Alternatively, you can double-click Setup.exe.
3. On the Welcome To The Install Wizard For The Microsoft Firewall Client page, click Next.
4. On the Destination Folder page, review the default installation folder location.Click Change if you want to change the installation folder. Click Next to continue.
5. On the ISA Server Computer Select screen, you can select how the Firewall Client will locate the ISA Server. To configure the server name or IP Address manually, select Connect To This ISA Server and type the ISA Server name or the IP address. To enable Automatic Discovery of the ISA Server computer, select Automatically Detect The Appropriate ISA Server Computer. Click Next.
6. On the Ready to Install the Program page, click Install.
7. When the installation wizard finishes, click Finish.

After the installation is complete, the Firewall Client application is enabled. The Microsoft Firewall Client Management icon is added to the system tray. To modify the Firewall Client configuration on the client, right-click the icon and click Configure. On the General tab ,you can enable or disable the Firewall Client and configure it to detect the ISA Server computer automatically or configure the ISA
Server computer manually. On the Web Browser tab, you can enable or disable automatic configuration of the Web browser.

How to Automate Firewall Client Installation :
If you deploy the Firewall Client to a large number of clients, you may choose to automate the Firewall Client installation. You have several options for automating the installation of the Firewall Client. You can perform an unattended installation, use Group Policy in Active Directory, or Microsoft Systems Management Server (SMS) to automate the installation.

Performing an Unattended Installation of the Firewall Client
One option for automating the deployment of the Firewall Client is to perform an unattended installation. To perform an unattended installation, you must ensure that the Firewall Client installation files are accessible from the client computer and then run the setup program from a command prompt with the appropriate parameters.
To complete an unattended installation of Firewall Client when running the setup program from the command prompt, use the following syntax:
Path\Setup.exe /v" [SERVER_NAME_OR_IP=ISA_Server_Name] [ENABLE_AUTO_DETECT={10}] [REFRESH_WEB_PROXY={10}] /qn"

Using Active Directory Group Policy to Distribute the Firewall Client
You can also use the Software Installation option in Active Directory Group Policy to automate the installation of the Firewall Client. To distribute the Firewall Client using this option, perform the following procedure:
1. Copy the Firewall Client installation files to a network share. You can use the Firewall Installation share on the ISA Server computer or on a file server. If you are installing the Firewall Client on a large number of client computers, use a separate file server.
2. Determine whether you wish to distribute the client software to users or computers. If you distribute the software to users, you can choose whether the software will be installed the next time the user logs on or whether the user can initiate the installation from Add/Remove Programs. If you distribute the software to computers, the software will be installed the next time the computer restarts.
3. Create a new software distribution package. Configure the software distribution package to use the installation files on the shared folder. You can also configure the distribution options for the software package.
4. When users log on or the client computers reboot, the Firewall Client is installed. The Firewall Client will then automatically discover the ISA Server computer and download the configuration information.

MCP 70-299 : Module 12 Securing Remote Access

Lesson 3: Configuring Remote Access Clients

You can configure clients to connect to a remote access server in one of two ways: by using the network connection properties or by using the Connection Manager Administration Kit (CMAK). Manually configuring a connection by using network connection properties is convenient when you are using the default security settings or when you need to configure fewer than ten clients. However, it would not be possible to configure and maintain VPN or dial-up network connection configurations on hundreds or thousands of client computers.

The CMAK allows you to easily configure large numbers of clients by creating an executable file that you can distribute to your users. When your users run the file, it creates a dial-up or VPN connection with your customized security settings. If you later change authentication or encryption methods, you can re-run the CMAK and distribute a new executable file to overwrite the previous configuration. You can even automate the distribution of the CMAK executable file by distributing it with a Group Policy object.

Configuring Client-Side Authentication Protocols :

You create a remote access connection by using the New Connection Wizard, as described in Lesson 2, Exercise 2. However, the New Connection Wizard does not allow you to configure the acceptable authentication or encryption settings for the connection. To view or modify the authentication protocols enabled for a remote access connection on the client, open the properties dialog box of the dial-up or VPN connection on the client, and then click the Security tab.

The Typical option is selected, and a secured password and data encryption are required. Automatically Use My Windows Logon Name And Password is not selected. This default setting is the
more secure choice. If you choose to automatically use the current credentials, an intruder who takes over the active desktop of the client can successfully authenticate and connect to your internal network, potentially compromising far more than a single computer. When the option is cleared, the user must provide credentials each time a connection is made.

CMAK Wizard :

Manually configuring remote access connections on clients is straightforward, but configuring
hundreds or thousands of clients would be impossible. Unfortunately, you cannot use Group Policy objects to directly control a user’s available network connections. However, you can use the CMAK to create an executable file that you can deploy to users. When users run this file, the CMAK adds a connection by using the settings you specified with the CMAK wizard.

Though most of the pages of the wizard do not involve security settings, there are several important pages that you can use to control the security settings on the resulting network connection. Specifically, the VPN Entries and Dial-Up Networking Entries pages allow you to restrict authentication and encryption on the client. The VPN Entries and Dial-Up Networking Entries pages are identical, except that the VPN settings allow you to choose between PPTP and L2TP.

11 Deploying, Configuring, and Managing SSL Certificates

Lesson 1: Overview of Secure Sockets Layer (SSL)

SSL was developed by Netscape Communications Corporation in 1994 to secure transactions over the World Wide Web. Soon after, the Internet Engineering Task Force (IETF) began work to develop a standard protocol to provide the same functionality. SSL 3.0 was used as the basis for that work, which is known as the Transport Layer Security (TLS) protocol. The implementation of the SSL/TLS protocol in Windows Server 2003 closely follows the specification defined in RFC 2246, “The TLS Protocol Version 1.0.

How SSL Works :
SSL provides encryption, authentication, and data integrity by using a public key certificate.When the SSL session is established, the server’s public key certificate is used to encrypt and exchange a shared secret between the client and server. This shared secret is then used to encrypt communications for the rest of the session. The following describes the step-by-step procedures for establishing an SSL session:
1. The client requests the public key from the server.
2. The server sends the public key to the client.
3. The client sends the server a session key, encrypting it with the public key.
4. The server decrypts the session key received from the client by using the server’s private key.
The session key can then be used as a shared secret to encrypt and decrypt data exchanged between the client and server.

Comparing SSL with IPSec :
IPSec is commonly used to provide the same services as SSL: authentication, privacy, and message integrity. However, the approach IPSec takes is different from that of SSL. IPSec is implemented by the operating system and is completely transparent to the applications that use IPSec. As a result, IPSec can be used to protect almost any type of network communication. IPSec also provides a flexible authentication scheme. The Microsoft Windows implementation of IPSec allows clients and servers to authenticate each other by using either public key certificates or a shared secret.

SSL, on the other hand, must be implemented by individual applications. Therefore, you cannot use SSL to encrypt all communications between two hosts. Additionally, SSL is less flexible than IPSec because it only supports authentication by means of public key certificates. SSL does provide several distinct advantages, however. Most significantly, SSL is supported by a wide variety of servers and clients, and the maturity of the standard has practically eliminated interoperability problems.

Additionally, SSL allows one-way authentication, while IPSec requires both sides of a connection to authenticate. One-way authentication allows SSL to be used to authenticate the server without placing the burden of registering for a public key certificate on the client. This enables SSL to be used to encrypt communications with public Web sites while protecting the privacy of the end user by not revealing the details of a user certificate to the Web server. Table 11.1 summarizes the differences between SSL and IPSec.

Obtaining SSL Certificates :
To use SSL, the server must have a suitable public key certificate. Additionally, some SSL scenarios allow or require the client to use a public key certificate. SSL is one of the most common uses for public key certificates, and, as a result, you can obtain SSL certificates from a wide variety of places.

Any organization with a computer running Windows Server 2003 can deploy Certificate Services to issue SSL certificates without any additional cost. These certificates are suitable for intranet scenarios, in which both the servers and the clients are controlled by a single organization. These certificates should not be used for communications that cross organizations, however.

As with any public key infrastructure (PKI), SSL certificates can only be trusted if the root certification authority (CA) is trusted. You can use Group Policy objects (GPOs) to add your CA to the list of trusted root CAs on clients on an intranet, but it is much more difficult to configure clients on the public Internet. For this reason, if you do not control the client computers, you should obtain an SSL certificate from a public CA that is trusted by the client applications that will be establishing a connection to your server. If the server is a Web server, your clients will be Web browsers. As shown in Figure 11.1, Microsoft Internet Explorer is configured by default to trust a large number of public CAs.

70-299 : 10 Planning and Implementing Security for Wireless Networks

Lesson 2: Configuring Wireless Security

Although almost anyone can set up a wireless network in a few minutes, configuring a wireless network with security features is significantly more complex. Fortunately, Windows Server 2003 provides all of the software you need to deploy a wireless infrastructure with authentication, encryption, message integrity, and dynamically changing WEP shared secrets. At a high level, you will follow these steps to configure a wireless network infrastructure:

1. Plan wireless access policies.
2. Create a structure for authorizing users and computers to access the wireless network.
3. Plan the certificate infrastructure, and optionally deploy a PKI.
4. Configure IAS servers, including assigning a certificate and creating remote access policies (RAPs).
5. Update and configure wireless clients with the SSID and security settings.
6. Configure WAPs with security settings and the IP addresses of the IAS servers.

Planning Wireless Access Policies :
There are several aspects to planning wireless access policies. First, it is important to plan wireless access policies to help prevent WAPs from being installed in your organization with insufficient security. You should draft a policy that, at a minimum, defines the following requirements for new WAPs:
■ Authentication requirements. Generally, you should require that all wireless users are authenticated and specify whether PEAP or EAP-TLS will be used. If you plan to allow guests to access your wireless network, you should make provisions for creating WAPs providing limited access to your internal network that will be used only by guests.
■ Encryption. Some level of encryption should always be required. Unless you have wireless devices that do not support it, your policy should mandate the highest level of encryption available.
■ Physical security. Just like any other piece of network equipment, WAPs should be protected by lock and key to prevent attackers from tampering with the hardware.
■ SSID broadcast and naming conventions. Your policy should specify whether WAPs are configured to broadcast the SSID, and it should detail naming conventions for SSIDs.
■ Actively maintained list of WAPs. You must maintain a list of all WAPs on your network that at a minimum includes the SSID, the security settings, the administrator’s name, and patching equirements.
■ Auditing requirements. You should specify how usage information is gathered and how logs are archived.

MCP 70-299 : 8 - Planning and Configuring IPSec

Lesson 3: Configuring IPSec

IP Filters :

IP filters describe network traffic and are used by IPSec policies to determine whether an IP security rule should apply to an individual packet. IP filters can specify traffic to or from a set of IP addresses, WINS servers, DNS servers, DHCP servers, or a default gateway. You can also configure an IP filter to match a packet’s source or destination port number, or even a packet’s IP protocol number. Each of the following examples can be specified by either a single IPSec IP filter or a combination of multiple filters:
■ All traffic to or from IP address 10.4.22.17
■ All Internet Control Message Protocol (ICMP) traffic to or from the default gateway
■ All traffic sent to TCP port 80, except traffic sent from the internal network
■ All outbound connections, except those to specific servers
Multiple IP filters can be combined into an IP filter list. In fact, adding an IP filter to an IP filter list is the only thing you can do with an IP filter, because IPSec policies only allow you to specify IP filter lists. If your needs are simple, you can make an IP filter list that consists of a single IP filter. However, most IP filter lists will consist of multiple IP filters.

Filter Actions :

You use filter actions, also referred to as security methods, to define how an IPSec policy should handle traffic that matches an IP filter. A filter action responds in one of three ways: it drops the traffic, it allows the traffic, or it attempts to negotiate security. If you choose the Permit or Block options for a filter action, there is nothing left to configure. In fact, you never need more than one filter action for each of the Permit and Block options.

There are several additional settings to consider when you configure a filter action to negotiate security. First, you must choose whether the server will allow communications with clients that do not support IPSec by selecting or clearing the Allow Unsecured Communication With Non-IPSec-Aware Computers check box. You can only require IPSec when you have only IPSec-enabled all client computers. Otherwise, clients without IPSec will be denied access to the server. Generally, this setting is enabled only when Active Directory is used to deploy IPSec configuration settings to all networked computers.
You should use the Filter Action Wizard to configure filter actions whenever possible, because configuring integrity and encryption settings can be complicated. The IP Traffic Security page of the wizard enables you to specify the protection suites associated with the filter action. You can choose Integrity And Encryption, Integrity Only, or Custom. If you select Integrity And Encryption, the wizard configures the filter action with ESP-based integrity verification (using Secure Hash Algorithm 1 [SHA1] by default) and encryption (using 3DES by default). If you select Integrity Only, Triple-Data Encryption Standard (3DES) encryption is disabled.

IP Security Rules :

An IP security rule consists of an IP filter list, a filter action, and, optionally, a connection type and tunnel endpoint. You can specify only one IP filter list and one filter action per rule. If the rule pertains to traffic traveling between networks across an IPSec tunnel, you should provide the IP address of the tunnel endpoint. This does not conflict with your ability to add IP filter lists; you can configure an endpoint and apply the rule only to traffic on a specific subnet within the destination network accessible through the IPSec tunnel.
The default response rule is used to configure the computer to respond to requests for secure communication when no other rules match the traffic. If an active policy does not have a rule defined for a computer that is requesting secure communication, the default response rule is applied and security is negotiated. For example, when Computer A communicates securely with Computer B, and Computer B does not have an inbound filter defined for Computer A, the default response rule is used.

Configuring IP Security Policies with Graphical Tools :

IP filters, filter actions, and IP security rules are only useful when added to an IP security policy. When configuring IP security policies on the local computer, you can use the IP Security Policy Management snap-in. You can also use the Group Policy Object Editor snap-in to edit either local or domain GPOs. In the Group Policy Object Editor, expand Computer Configuration, Windows Settings, Security Settings, and then click either IP Security Policies On Local Computer or IP Security Policies On Active Directory. Because this node might have several different labels, this chapter will refer to it
as simply IP Security Policies.
To create a new security policy, right-click the applicable IP Security Policies node in the Group Policy Object Editor or IP Security Policy Management snap-in, and then click Create IP Security Policy. This opens the IP Security Policy Wizard, which guides you through the process of creating a security policy.
During the configuration process, you will be prompted to activate the default response rule. In most cases, you should enable the default response rule. If you do, you will be prompted to select an authentication method. For more information about rules, see the section "IP Security Rules" in this lesson.

Configuring IP Security Policies with Command-Line Tools :

Though you should usually use graphical tools to configure IP security policies, Windows Server 2003 also provides the Netsh command-line tool for scripting IPSec configuration. Netsh is a native Windows Server 2003 command-line scripting tool that you can use to display or modify the local or remote network configuration. The Netsh IPSec commands cannot be used on any other version of Windows.
To use the command line to configure IPSec policies on computers running Windows XP, use Ipseccmd.exe, which is provided on the Windows XP CD, in the \Support\Tools folder. To use the command line to configure IPSec policies on computers running Windows 2000, use Ipsecpol.exe, which is provided with the Windows 2000 Server Resource Kit.
To use Netsh interactively to view or modify IPSec settings, open a command prompt and run the command Netsh with no parameters. This starts the Netsh interactive command prompt. Then type Ipsec static or Ipsec dynamic to set the context for Netsh. For example, the following commands launch Netsh and set the context to Ipsec dynamic:

C:\>netsh
netsh>ipsec
netsh ipsec>static
netsh ipsec static>

Static mode allows you to create, modify, and assign policies without affecting the active IPSec policy. Dynamic mode allows you to display the active state and immediately implement changes to the active IPSec policy. Dynamic Netsh commands affect the service only when it is running. If it is stopped, dynamic policy settings are discarded.

MCP 70-299 : 8 - Planning and Configuring IPSec

Lesson 1: IPSec Fundamentals

IPSec in the Windows Server 2003 operating system protects networks from active and passive attacks by securing IP packets through the use of packet filtering, cryptography, and the enforcement of trusted communication. IPSec is useful for improving the privacy and integrity of host-to-host, host-to-network, and network-to-network communications. IPSec can also be used as a host-based firewall to harden clients and servers by using packet filtering.

IPSec Overview :

IPSec is a framework of open standards for helping to ensure private, secure communications over Internet Protocol (IP) networks through the use of cryptographic security services. IPSec supports network-level data integrity, data confidentiality, data origin authentication, and replay protection. Because IPSec is integrated at the Internet layer (layer 3), it provides security for almost all protocols in the TCP/IP suite, and because IPSec is applied transparently to applications, there is no need to configure separate security for each application that uses TCP/IP.
IPSec can be used to provide packet filtering, to encrypt and authenticate traffic between two hosts, and to create a virtual private network (VPN). Using these capabilities of IPSec helps to provide protection against:
■ Network-based denial-of-service attacks from untrusted computers.
■ Data corruption.
■ Data theft.
■ User-credential theft.
■ Administrative control of servers, other computers, and the network.

Besides simply improving security, IPSec can be used to save money by enabling communications
between remote offices and remote access clients across the public Internet, rather than more costly dedicated circuits that offer privacy at the physical level.

Securing Host-to-Host Communications :

You can use IPSec to encrypt and validate the integrity of communications between two computers. For example, IPSec can protect traffic between domain controllers in different sites, between Web servers and database servers, or between Web clients and Web servers. When an IPSec client attempts to initiate a connection to an IPSec server, the client and server negotiate IPSec integrity and encryption protocols. After the IPSec connection is established, the application’s data is transported within the IPSec connection.
For example, consider the common scenario of a user downloading e-mail from a server using Post Office Protocol version 3 (POP3). If IPSec is not enabled, the e-mail client software initiates a connection directly to the e-mail server software. The user name and password will be transmitted in clear text, so that anyone with a protocol analyzer such as Network Monitor can intercept the user’s credentials. An attacker who has control of a router can modify the contents of the user’s e-mail messages as they are downloaded without being detected.

Securing Host-to-Network Communications :

IPSec is often used to authenticate and encrypt traffic sent directly between two hosts. However, IPSec can also protect traffic traveling from a single host to an entire network, as illustrated in Figure 8.2. This is most commonly used in remote access scenarios. In the past, many organizations required users to dial in to remote access servers connected to the organization’s private network. Today, organizations can eliminate the cost of maintaining dial-in servers by using IPSec to allow remote users to connect to an organization’s private network across the Internet. Most security experts agree that IPSec provides a level of security similar to that of dial-up remote access.

Securing Network-to-Network Communications :

IPSec can also be used to connect two remote networks. Before Internet connectivity was common, remote offices were connected with private links provided by communications companies. These links would typically consist of a circuit (such as a T1 in the United States or an E1 in Europe) from each of the remote offices that connected to a switched frame relay network that would carry the traffic over long distances.
Today, many organizations still use private links to connect offices. Private links offer some distinct advantages, most notably predictability and stability. Although the Internet continues to become more reliable, performance factors such as usable bandwidth, latency, and jitter fluctuate unpredictably. Private links dedicate bandwidth to a communication link and always follow the same path—guaranteeing that performance will always stay the same.