Securing the Configuration

  • Article

When you configure the ISA Server firewall policy in conjunction with your corporate security policy, follow the principle to deny all traffic that is not explicitly allowed. ISA Server by default implements this policy. A default firewall policy rule, named Default Rule, denies access by all users to all networks. Because this rule is processed last, any traffic not explicitly allowed will be denied.

Security Best Practices for Enterprise Management

ISA Server 2004 Enterprise Edition introduces a multi-tiered architecture, in which configuration information is stored on the Configuration Storage server. Array members communicate with the Configuration Storage server to get up-to-date configuration information. In addition, array members communicate with each other. To help secure this deployment model, follow the security best practices listed in this topic.

Securing the Configuration Storage Server

To secure the Configuration Storage server, follow these guidelines:

  • We recommend that you install the Configuration Storage server on a dedicated computer, which is not used for additional tasks.
  • Safeguard the security of the Configuration Storage server. Ensure that the computer is physically secure.
  • After you create administrator roles, avoid performing any tasks on the Configuration Storage server. Changes to the Configuration Storage server should be done using Enterprise Administrator credentials on an ISA Server array computer or remote management computer.
  • Users that belong to the Administrators group on the Configuration Storage server essentially have Enterprise Administrator permissions. This is because they can directly modify any data on the Configuration Storage server.
  • We recommend that you do not place the Configuration Storage server at the edge of the network. Rather, place it behind a computer running ISA Server services, which will help protect it from potential attacks.
  • Audit changes to permissions on the Configuration Storage server.
  • When possible, we recommend deploying a Configuration Storage server only in the corporate headquarters, and not in the branch offices. If a branch office has a good connection to headquarters, we recommend deploying a Configuration Storage server in headquarters to ensure a secured physical location for the Configuration Storage server. However, this is not recommended when the network connection to the branch office is slow.

Firewall Account Lockout

The Configuration Storage server recognizes each ISA Server array member by a unique account, especially created for this purpose. This account is not subject to account lockout. Potential denial-of-service attacks are prevented.

The default password on this account, created when you install the array member, is a strong password. If you change this password, we recommend that you configure a strong password.

Securing Intra-Array Communication

To secure intra-array communication, follow these guidelines:

  • Upon installation, a pair of private and public keys are created for each array member. These keys are used to transfer confidential data between array members. If you believe that the keys have been compromised, create a new key pair by uninstalling and then installing ISA Server.
  • We recommend that you use a dedicated network adapter in a network used only for intra-array communication. This network should include all the array member's intra-array addresses.

Validating Configuration After Upgrade

ISA Server 2000 policy can be migrated to ISA Server 2004, either by upgrading or by using the ISA Server Migration Wizard. Carefully review migrated policy. ISA Server 2004 employs a different rule model than ISA Server 2000. Make sure that the firewall policy is configured in accordance with your organization’s security policy.

Validating the Firewall Policy Configuration

After you create a firewall policy, we recommend that you actively check the policy. Validate that traffic that you want to pass through is being allowed. Also validate that only applicable ports are open.

For example, use port scanning to verify that only the applicable ports are actually open.

Local Domains

We recommend that you include all local domain names in the domains that are considered local to the Internal network. Otherwise, ISA Server may send a name resolution request to an external DNS server, thereby potentially exposing names of internal domains.

To configure the local domain table, perform the following steps:

  1. Click Start, point to All Programs, point to Microsoft ISA Server, and then click ISA Server Management.

  2. In the console tree of ISA Server Management, click Networks:

    • For ISA Server 2004 Enterprise Edition, expand Microsoft Internet Security and Acceleration Server 2004, expand Arrays, expand Array_Name, expand Configuration, and then click Networks.
    • For ISA Server 2004 Standard Edition, expand Microsoft Internet Security and Acceleration Server 2004, expand Server_Name, expand Configuration, and then click Networks.

  3. In the details pane, click the Networks tab, and then select the Internal network.

  4. On the Tasks tab, click Edit Selected Network.

  5. On the Domains tab, click Add. Then, type the domain name in Enter a domain name to include.

Backing Up and Restoring

ISA Server includes an export and import feature that enables you to back up and restore configuration information. The configuration parameters can be exported and stored locally in an .xml file. You can save your configuration to any directory and file name.

When you restore a configuration file, you potentially change the existing firewall policy. For this reason, take special care that you use only trusted configuration files when restoring (importing) the configuration information.

Virtual Private Networking

It is important to follow best practices for security when using ISA Server 2004 as a virtual private network (VPN) server. The following is a list of recommendations for securing your ISA Server computer in its role as a VPN server:

  • Layer Two Tunneling Protocol (L2TP) over Internet Protocol security (IPsec) connections are recommended for the strongest encryption. We recommend that you implement and enforce a strong password policy, thereby reducing the chance of a dictionary attack. When you implement such a policy, you can disable account lockout, thereby reducing the chance that an attacker will trigger account lockout.
  • Consider requiring your remote VPN clients to run particular operating systems (such as Microsoft Windows Server 2003, Windows 2000 Server, or Windows XP ). Not all operating systems have equal levels of security in their file systems and in their user accounting. Also, not all remote access features are available on all operating systems.
  • Use the ISA Server Quarantine Control feature, to provide phased network access for remote VPN clients. With Quarantine Control, clients are restricted to a quarantine mode before allowed access to the network. Although Quarantine Control does not protect against attackers, computer configurations for authorized users can be verified and, if necessary, corrected before they can access the network.

Virus Protection with VPN

Virus infected VPN client computers are not automatically blocked from flooding the ISA Server computer or the networks it protects with requests. To prevent this occurrence, implement monitoring practices to detect anomalies such as alerts or unusual peaks in traffic loads, and configure alert notification to use e-mail messages. If an infected VPN client computer is identified, either:

  • Restrict VPN access by user name by using the remote access policy to exclude the user from the VPN clients who are allowed to connect.
  • Restrict VPN access by IP address. Do this by creating a new network to contain external IP addresses that are blocked, and move the IP address of the client out of the External network to the new network.

Authentication for VPN

Use authentication methods that provide adequate security. The most secure method of authentication is Extensible Authentication Protocol-Transport Level Security (EAP-TLS) when used in conjunction with smart cards. Despite the deployment challenges involved in using EAP-TLS and smart cards, which require a public key infrastructure (PKI), this is considered the most secure authentication method. Enable EAP-TLS, which is disabled by default on the profile of a remote access policy.

When you use the EAP-TLS authentication protocol, you must install a computer certificate on the Internet Authentication Service (IAS) server. For client and user authentication, you can install a certificate on the client computer, or you can use smart cards. Before you deploy certificates, you must design the certificate with the correct requirements.

If you use password-based authentication, enforce strong password policies on your network to make dictionary attacks more difficult.

Consider requiring your remote VPN clients to be authenticated with more secure authentication protocols, such as Microsoft Challenge Handshake Authentication Protocol version 2 (MS-CHAP v2) or Extensible Authentication Protocol (EAP), rather than allowing them to use protocols such as Password Authentication Protocol (PAP), Shiva Password Authentication Protocol (SPAP), and Challenge Handshake Authentication Protocol (CHAP).

We strongly recommend that PAP, SPAP, and CHAP are disabled. PAP, SPAP, and CHAP are disabled by default.

IPsec Traffic

ISA Server does not block any encapsulating security payload (ESP) or authentication header (AH) traffic, which is part of IPsec traffic. Furthermore, such traffic is never considered spoofed, because these protocols are considered secure by design.

Network Load Balancing

For Enterprise Edition, for Network Load Balancing (NLB), follow these guidelines:

  • When you enable NLB, follow the security best practices detailed in Network Load Balancing: Security Best Practices for Windows 2000 and Windows Server 2003 at the Microsoft TechNet Web site.
  • When you enable NLB, place a router in front of the NLB-enabled array. Configure the router so that it blocks raw IP traffic. Otherwise, all the array members will handle the traffic simultaneously.

When NLB is enabled, it synchronizes array members by using pure Ethernet protocol communication. This low-level traffic is not protected by ISA Server. To help secure that traffic, we strongly recommend that you place a Layer-3 router between the Internet and the NLB-enabled array. Also, place a Layer-3 router between the ISA Server computers and any network with untrusted computers.

  • This Layer-3 router will not allow the low-level Ethernet protocol to pass, thereby helping protect the array from potentially malicious Ethernet traffic from the Internet, intended to disrupt the operation of NLB.

Cache Array Routing Protocol

For Enterprise Edition, when you enable Cache Array Routing Protocol (CARP), follow these guidelines:

  • We recommend that you deploy a dedicated network for intra-array communication, and use this network for CARP communication. Otherwise, use a dedicated network for CARP communication. Configure Internet Protocol security (IPsec) for this network.
  • Networks for which CARP is enabled should be accessible only to array members.

Message Screener

When you create an SMTP Message Screener rule to hold a message, the Message Screener will store all messages that match the rule on the Message Screener computer in the %SYSTEMDRIVE%\inetpub\mailroot\badmail folder. The default ACL on this folder is READ ONLY for Authenticated Users (on computers running Windows Server 2003) and FULL CONTROL to everyone (on computers running Windows 2000 Server). We recommend that you configure the ACLs so that only authorized users can access the folder.

The link translation feature of ISA Server 2004 translates HTTP headers, regardless of whether link translation is enabled. This implies that when you publish a Web server, specifying that Any domain name can be used, an attacker could send malicious content in the header. If the published server redirects requests to a page on any computer, the response could be poisoned. (It would be modified to contain the URL from the header sent by the attacker.) If this page is cached by a downstream server, a user accessing the page would be redirected to the Web site configured by the attacker.

For this reason, we recommend that you specify specific domain names to which the Web publishing rule applies.

To specify specific domain names, perform the following steps:

  1. Click Start, point to All Programs, point to Microsoft ISA Server, and then click ISA Server Management.

  2. In the console tree of ISA Server Management, click Firewall Policy:

    • For ISA Server 2004 Enterprise Edition, expand Microsoft Internet Security and Acceleration Server 2004, expand Arrays, expand Array_Name, and then click Firewall Policy.
    • For ISA Server 2004 Standard Edition, expand Microsoft Internet Security and Acceleration Server 2004, expand Server_Name, and then click Firewall Policy.

  3. In the details pane, select the applicable Web publishing rule.

  4. On the Tasks tab, click Edit Selected Rule.

  5. On the Public Name tab, under This rule applies to, select Requests for the following websites.

  6. Click Add.

  7. In Public domain name or IP address, type the specific domain name to which the Web publishing rule should apply.

Connection Limits

ISA Server limits the number of connections at any given time. You can configure the limit, specifying a maximum number of concurrent connections. When the maximum number of connections has been reached, any new client requests for that Web listener will be denied.

You can limit the total number of UDP, ICMP, and other Raw IP session creations allowed by a server publishing or access rule, per second. These limitations do not apply to TCP connections. When the specified number of connections is surpassed, new connections will not be created. Existing connections will not be disconnected.

We recommend that you configure low connection limits. You will effectively limit malicious hosts from consuming resources on the ISA Server computer.

By default, connection limits for non-TCP connections are configured to 1000 connections per second per rule, and to 160 connections per client. Connection limits for TCP connections are configured to 160 connections per client. We strongly recommend that you do not change these preconfigured limits. If you must modify the connection limits, configure as small a number of connections as possible.

To configure connection limits, perform the following steps:

  1. Click Start, point to All Programs, point to Microsoft ISA Server, and then click ISA Server Management.

  2. In the console tree of ISA Server Management, click General:

    • For ISA Server 2004 Enterprise Edition, expand Microsoft Internet Security and Acceleration Server 2004, expand Arrays, expand Array_Name, expand Configuration, and then click General.
    • For ISA Server 2004 Standard Edition, expand Microsoft Internet Security and Acceleration Server 2004, expand Server_Name, expand Configuration, and then click General.

  3. In the details pane, click Define Connection Limits.

  4. On the Connection Limit tab, select Limit the number of connections.

  5. Do the following:

    1. In Connections created per second, per rule (non-TCP), type the number of connections allowed per rule, per second.
    2. In Connection limit per client (TCP and non-TCP), type the number of connections allowed per client.

Firewall Clients

ISA Server supports a more secure way of communication between the Firewall client and ISA Server, which involves the use of encryption using a TCP control channel. You can configure ISA Server to accept connections only from clients communicating in this secure way. However, this prevents earlier versions of Firewall Client software from connecting.

We recommend that you allow only Firewall clients that can communicate over an encrypted connection. This includes all the Firewall Client software for ISA Server 2004 computers.

To configure Firewall clients, perform the following steps:

  1. Click Start, point to All Programs, point to Microsoft ISA Server, and then click ISA Server Management.

  2. In the console tree of ISA Server Management, click General:

    • For ISA Server 2004 Enterprise Edition, expand Microsoft Internet Security and Acceleration Server 2004, expand Arrays, expand Array_Name, expand Configuration, and then click General.
    • For ISA Server 2004 Standard Edition, expand Microsoft Internet Security and Acceleration Server 2004, expand Server_Name, expand Configuration, and then click General.

  3. In the details pane, click Define Firewall Client Settings.

  4. On the Connection tab, verify that Allow non-encrypted Firewall client connections is not selected.

Firewall Chaining

When configuring firewall chaining, we recommend that you use IPsec to secure the communication channel between the ISA Server computer and the upstream server.