Securing the Deployment

  • Article

The first step in securing ISA Server is verifying that the ISA Server computer is physically safe and that you apply basic security configuration recommendations.

After you secure the ISA Server computer and apply security guidelines when configuring the policy on the server, you should consider how to deploy the network infrastructure. This section describes security guidelines to consider when deploying a network secured by ISA Server.

Securing the Network Environment

To secure the network environment, perform the following:

  • Protect against Layer 2 attacks by deploying security solutions such as Layer 2 IDS and static MAC or port associations on switches.
  • Where possible, configure IPsec in the network.
  • To help protect from man-in-the-middle attacks on the Address Resolution Protocol (ARP) cache, we recommend that you place a router before the ISA Server computer. This is because ARP packets cannot be routed through a router. When ISA Server shares a physical network with an untrusted network, we recommend that you configure ISA Server to perform static ARP. For optimal security, we recommend that you add a static ARP entry for the default gateway and on other hosts on the same physical network.

Authentication

When configuring authentication for Web requests, use the strongest authentication method possible. We strongly recommend that you use the following authentication methods over connections that are not secure:

  • Basic
  • Digest
  • Outlook Web Access forms-based authentication
  • SecurID
  • RADIUS

Using RADIUS Servers

Remote Authentication Dial-In User Service (RADIUS) is an industry standard protocol used to provide authentication. A RADIUS client (typically a dial-up server, VPN server, or wireless access point) sends user credentials and connection parameter information in the form of a RADIUS message to a RADIUS server. The RADIUS server authenticates the RADIUS client request, and sends back a RADIUS message response.

Because RADIUS servers authorize client credentials, in addition to authenticating them, the response that ISA Server receives from the RADIUS server, indicating that the client credentials are not approved, might actually indicate that the RADIUS server does not authorize the client. Even if the credentials have been authenticated, ISA Server may reject the client request, based on the RADIUS server authorization policy.

We recommend that you configure the RADIUS server as follows:

  • If you are using a RADIUS server for authentication, create a connectivity verifier that monitors the server status. Configure the alerts so that an appropriate action is taken when the RADIUS server is not functioning.
  • Untrusted users should not have access to the network between a RADIUS server and ISA Server. If untrusted users must have access, use IPsec on this network.

In addition, follow these guidelines when implementing a VPN or firewall policy that requires RADIUS authentication:

  • The RADIUS User-Password hiding mechanism might not provide sufficient security for passwords. The RADIUS hiding mechanism uses the RADIUS shared secret, the Request Authenticator, and the use of the MD5 hashing algorithm to encrypt the User-Password and other attributes, such as Tunnel-Password and MS-CHAP-MPPE-Keys. RFC 2865 notes the potential need for evaluating the threat environment and determining whether additional security should be used.
  • You can provide additional protection for hidden attributes by using Internet Protocol security (IPsec) with Encapsulating Security Payload (ESP) and an encryption algorithm, such as Triple DES (3DES), to provide data confidentiality for the entire RADIUS message. Follow these recommended guidelines:
    • Use IPsec to provide additional security for RADIUS clients and servers.
    • Require the use of strong user passwords.
    • Use authentication counting and account lockout to help prevent a dictionary attack against a user password.
    • Use a long shared secret with a random sequence of letters, numbers, and punctuation. Change it often to help protect your IAS server.
  • When you use password-based authentication, enforce strong password policies on your network to make dictionary attacks more difficult.
  • When user names are specified in any language other than English, ISA Server uses the current code page installed on the ISA Server computer to translate the user data. The user can be authenticated only if the client also uses the same code page.
  • If you change the RADIUS server policy while RADIUS-authenticated users are logged on, the new policy is not applied to users who are currently logged on. This is because ISA Server caches the credentials of users who are logged on, when users accessing the published Outlook Web Access server authenticate using RADIUS authentication. To apply the RADIUS server policy immediately, you can disconnect the session.

Client Authentication

When HTTP authentication is used to connect to the ISA Server firewall without Secure Sockets Layer (SSL), the request is potentially subject to a man-in-the-middle attack. The request could be altered by an attacker, during or after authentication.

To mitigate this attack, use HTTP authentication only with SSL-enabled connections.

Verifying Connectivity to Authentication Servers

If you are using a RADIUS server for authentication, create a connectivity verifier that monitors the server status. Configure the alerts so that an appropriate action is taken when the RADIUS server is not functioning.

To verify connectivity, 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 Monitoring:

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

  3. In the details pane, click the Connectivity tab.

  4. On the Tasks tab, click Create New Connectivity Verifier.

  5. On the Welcome page of the wizard, type a name for the connectivity verifier and then click Next.

  6. On the Connectivity Verification Details page, do the following:

    1. In Monitor connectivity to this server or URL, type the name of the server to monitor.
    2. In Verification method, select a verification method. Click Next and then click Finish.
      If the system policy rule that allows HTTP connectivity verification is not enabled, and you selected Send an HTTP "Get" request, you will be prompted to enable the system policy rule. Click Yes.
      For more information about the HTTP connectivity verification system policy rules, see the Connectivity Verifiers section.

  7. In the details pane, select the rule you just created.

  8. On the Tasks tab, click Edit Selected Verifier.

  9. On the Properties tab, verify that Trigger an alert if the server response is not within the specified timeout is selected.

Deploying Authentication Servers

For security reasons, we recommend that you place authentication servers in a highly secured network. Consider placing the authentication servers on a separate network (apart from the Internal and perimeter networks), when possible. You will effectively prevent direct access from any hosts on the Internal and perimeter networks to the authentication servers.

In this case, you should modify the applicable system policy rule, so that it applies to the network on which the authentication server is located.

To deploy authentication servers, 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. On the Tasks tab, click Edit System Policy.

  4. In System Policy Editor, in the Configuration Groups tree, under Authentication Services, click the applicable authentication method.

  5. On the To tab, click Add.

  6. In Add Network Entities, select the network on which the authentication server is located.

DNS Servers

Domain Name System (DNS) is the name resolution protocol for IP networks, such as the Internet. A DNS server hosts the information that enables client computers to resolve memorable, alphanumeric DNS names to the IP addresses that computers use to communicate with each other.

ISA Server includes a name resolution mechanism, similar to the DNS server name resolution mechanism. When a client makes a request to a host on another network, specifying the URL of the host computer, ISA Server can resolve the host computer name. ISA Server sends a name resolution request to the DNS server that you configure for its use.

To prevent DNS cache poisoning, we strongly recommend that you configure ISA Server to use a trusted DNS server (for example, a Windows DNS server), with the option to prevent cache pollution enabled. This DNS server should be located on the Internal network.

If you deploy a DNS server on an untrusted network (for example, on the External network), we recommend that you also install a DNS server on a trusted network (for example, a perimeter network). Then, configure the DNS server on the trusted network to forward requests to the DNS server on the untrusted network.

Follow these guidelines when deploying DNS servers:

  • Deploy a DNS server in the Internal network.
  • On the ISA Server computer, configure the network adapter connected to the Internal network to use the DNS server in the Internal network for all name resolution requests.
  • Verify that no other network adapter on the ISA Server computer uses an untrusted DNS server.
  • Create an access rule that allows only the internal DNS server to access the Internet for DNS resolution.

Important

Only the trusted DNS server should send name resolution requests to the untrusted DNS server. No other server in the Internal network should directly access the untrusted DNS server.

To configure DNS, perform the following steps on the ISA Server computer:

  1. Click Start, point to Control Panel, and then double-click Network Connections.

  2. Right-click the connection you want to configure, and then click Properties.

  3. On the General tab, in This connection uses the following items, click Internet Protocol (TCP/IP), and then click Properties.

  4. Select Use the following DNS server addresses.

  5. In Preferred DNS server and in Alternate DNS server, type the IP addresses of a trusted DNS server on the Internal network.

Monitoring and Troubleshooting

An important and routine task that you will perform is monitoring the network traffic allowed to pass through ISA Server. A central part of the monitoring function is a careful analysis of the log and auditing information.

The following sections provide tips and hints about helping ensure log information integrity.

Logging

Logging gives you the opportunity to review network activity, checking who has been accessing resources on your network. Review the logs regularly and carefully, checking for suspicious access and usage of network resources. Follow these guidelines to make the best use of ISA Server logging:

  • Configure alerts to send notifications to administrators. Implement a rapid response procedure.
  • Save the logs to a separate NTFS disk partition for maximum security. Only administrators of the ISA Server computer should have access to the logs.
  • When you save log information to an SQL database, use Windows authentication (and not SQL authentication).
  • If you are logging the information to a remote database, configure encryption and data signature for the log information being copied to the remote database.
  • For maximal security, configure IPsec for the communication between the ISA Server computer and SQL Server.
  • If log information cannot be saved for any reason, lock down the ISA Server computer. To do so, configure an alert definition for the Log Failure event that stops the Firewall service.

Log Storage Limits

Use the log maintenance feature wisely, to ensure that the disk on which log information is stored does not become full.

Configure the Log Storage Limits alert definition to stop the ISA Server services. You only allow access when the access can be appropriately audited.

To configure log storage 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 Monitoring:

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

  3. In the details pane, click the Alerts tab.

  4. On the Tasks tab, click Configure Alert Definitions.

  5. In Alert Definitions, click Log storage limits, and then click Edit.

  6. On the General tab, select Enable.

  7. On the Actions tab, click Stop selected services, and then click Select.

  8. In Services, select Microsoft Firewall and Microsoft ISA Server Job Scheduler.

Auditing

Enable Windows auditing, so that you can monitor who logs on to the ISA Server computer.

To enable auditing, perform the following steps on the ISA Server computer:

  1. Click Start, point to All Programs, point to Administrative Tools, and then click Local Security Policy.

  2. Expand Security Settings, expand Local Policies, and then click Audit Policy.

  3. In the details pane, right-click Audit logon events, and then click Properties.

  4. Select Success and Failure.

Floods

A flood attack occurs when an attempt is made to deny services to legitimate users by intentionally overloading a network. Flood attacks might occur, for example, when a worm tries to propagate outside of your corporate network.

The first symptoms that show that ISA Server is experiencing a flood attack are a sudden surge in CPU utilization, increased memory consumption, or very high logging rates on the ISA Server computer.

If you determine that the ISA Server computer is experiencing a flood attack, use the log viewer, to determine the source of the offending traffic. Specifically, look for the following:

  • Log entries for denied traffic. Pay special attention to traffic that is denied because the quota is exceeded, spoofed packets, and packets with corrupted CHECKSUM. These usually are indicative of a malicious client. In ISA Server 2004 Standard Edition, connections that are terminated due to exceeding the connections limit will have a result code of 0x80074e23. In ISA Server 2004 Enterprise Edition, the result will appear as text, which clearly indicates the connection termination reason.
  • Logs that indicate numerous connections that are created and then immediately closed. This often indicates that a client computer is scanning an IP address range for a specific vulnerability.

Another way to detect and list the offending computers is to temporarily reconfigure the Connection Limit alerts to be triggered every one second (instead of Manually Reset). A list of alerts is generated, each one indicating the offending IP address in the alert text. After you identify the list of offending IP addresses, perform the following procedure to improve the performance of ISA Server during the flood.

To improve ISA Server performance during a flood, perform the following steps:

  1. Disable logging. Disable logging either on the specific rule that matches the flood or altogether until the flood attack is stopped.

  2. Reconfigure the Connections Limit alerts (or any other types of alerts that may be triggered repeatedly as a result of the specific attack) back to Manually Reset.

Connection Limit Alert

When a Connection Limit alert occurs, determine whether your network is being attacked, or whether there is simply a heavy load of valid traffic. If the limit was exceeded due to malicious traffic, try the following:

  • If the malicious traffic appears to originate from the Internal network, this may indicate a virus on the Internal network. Identify the source IP address, and disconnect the computer from the network immediately.
  • If the malicious traffic appears to originate from a small range of IP addresses on an External network, create a rule denying access to a computer set that includes the source IP addresses.
  • If the traffic appears to originate from a large range of IP addresses, evaluate the overall status of your network. Consider setting a smaller connection limit, so that ISA Server can better protect your network.

In addition, we recommend that you limit the number of connections, because this can help prevent flood attacks. When a UDP or raw IP flood attack occurs, many requests are sent from spoofed source IP addresses, eventually resulting in a denial of service.

Protecting from Floods Caused by Worms and Viruses

Your Internal network could be exposed to infection by the following types of worms:

  • Worms that infiltrate using a specific protocol.
  • Worms that are destined for specific IP addresses.
  • Worms that originate from specific IP addresses.

To help protect your Internal network from worms and other malicious software, we recommend the following:

  • Enable quarantine protection on the VPN Clients network.
  • Create an access rule that denies traffic to and from infected clients, and denies use of the protocols used by the worms. Do not enable logging for this rule.
  • Configure a disconnected network that includes IP addresses of infected clients. Any traffic originating from these clients will be dropped as spoofed.

Creating a Disconnected Network

A disconnected network represents a range of IP addresses that are not physically connected to the ISA Server computer.

To create a disconnected network, 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.

  4. On the Tasks tab, click Create a New Network.

  5. On the Welcome page, type the name of the network. For example, type Disconnected, and then click Next.

  6. On the Network Type page, select External Network, and then click Next.

  7. On the Network Addresses page, click Add. Then, in Starting address and in Ending address, type the IP addresses of the infected clients. Click OK, click Next, and then click Finish.

  8. In the details pane, click the Network Rules tab. Check that there are no network rules that apply to this network.

Note

Be sure to update this network each time another client is identified as infected.

Configuring the Routing Table

By adjusting the local routing table on the ISA Server computer, you can help ensure that infected clients are not allowed access to resources on your Internal network. Do the following:

  • Add another network adapter to the ISA Server computer. Do not associate it with any ISA Server network.
  • Use the route add command to add static routes to the IP addresses of the infected clients using the IP address of this network adapter.

Hostile Code

If a user unknowingly executes hostile code, and that hostile code has been packaged with additional files including modified versions of system DLLs, the hostile code could load its own versions of those DLLs, potentially increasing the type and degree of damage the code can render. Configure the registry key MSS: Enable Safe DLL search mode (recommended) to a value of Enabled.

For more information about this registry key, see "Chapter 10: Additional Registry Settings" in the Threats and Countermeasures Guide at the Microsoft TechNet Web site.