Best Practices Firewall Policy for ISA Server 2004

This document provides guidelines on how to design your firewall policy, including tips on ordering your policy rules to improve the performance of your computers running Microsoft® Internet and Security Acceleration (ISA) Server services.

This document includes the following topics:

Firewall Policy Best Practices. Tips for both Standard Edition and Enterprise Edition firewall policies.

Enterprise Policy Design. How to use enterprise policy effectively.

Additional Information

Firewall Policy Best Practices

These best practices will help you create a firewall policy that results in the policy behaviors you want and provide security benefits, and they can help you boost the performance of your ISA Server arrays.

General Policy Guidelines

The performance of ISA Server is related to the type of information it requires to evaluate the rules. Because rules are evaluated in order, you want to place the rules that can be processed quickly near the top of the rule list, if this does not interfere with the behavior of the firewall policy you have designed. This way, if a request matches a rule that is high in the order, ISA Server does not have to compare the request to rules that might take longer to process.

Simple Rule Elements

The following rule elements require simple networking information and therefore are evaluated quickly:

• Protocol definitions
• Schedules
• All IP address based network elements (computers, computer sets, networks, and network sets)

Also, source port information is evaluated quickly.

Rules that use these elements should be placed at the top of the rule list.

Complex Rule Elements

The following rule elements require additional networking information and therefore are evaluated more slowly:

• Domain name sets and URL sets
• Users
• Content type

Rules that contain such elements should be placed at the bottom of the rule list.

Rules Using Application Filters

Rules that use the SMTP filter, HTTP filter, or FTP filter slow performance.

General Rule Order Recommendations

We recommend that you organize your access rules in this order:

1. Global deny rules. Rules that deny specific access to all users. These rules should use the rule elements that require simple networking information. An example of such a rule would be a rule that denies all users access from anywhere to anywhere on protocols used for peer-to-peer file sharing.

2. Global allow rules. Rules that allow specific access to all users. These rules should use the rule elements that require simple networking information. An example of this would be a rule allowing access on the DNS protocol from the Internal network to the External network.

3. Rules for specific computers. Rules that allow or deny access for specific computers, for example, a rule allowing UNIX computers access to the Internet.

4. Rules for specific users, URLs, and MIME types, and also publishing rules. Rules that contain rule elements that require additional networking information, and that enforce policy for specific users, or for specific URLs or Multipurpose Internet Mail Extensions (MIME) types. Publishing rules should also occur at this point in the rule order.

5. Other allow rules. Rules that handle traffic that does not match rules that occur previously in the list of rules, assuming the traffic is allowed by your corporate policy. For example, a rule allowing all traffic from the Internal network to the Internet.

   Note

   Server publishing and Web publishing rules can be placed anywhere in the rule order after global allow or deny rules. In the Enterprise Edition, publishing rules can only be created on the array level.For Enterprise Edition, placing rules higher in the rule order means placing them in the pre-array enterprise rules, if possible. The next place in the order would be in the array rules, and the lowest position would be in the post-array enterprise rules.

Specific Best Practices

The following best practices should be considered when creating firewall policy.

User Sets and Unauthenticated Users

Place rules that are based on user sets lower in the rule order, or in the post-array enterprise rules. If you put these rules high in the rule order, or in the pre-array enterprise rules, you preclude further processing of traffic coming from unauthenticated users who otherwise match the rule definition. This may have the unintended effect of an allow rule functioning as a deny rule for unauthenticated users.

ISA Server drops traffic from unauthenticated users after rules based on user sets, to preclude the bypassing by unauthenticated users of the rules based on user sets.

Use IP Addresses

Where possible, use IP addresses rather than DNS names in your firewall policies. This reduces the reliance of ISA Server on the DNS servers, and results in better performance. However, be aware that in some situations, you will not achieve the desired behavior by using IP addresses. For example, if you are trying to deny access to a site, and the site’s IP address is assigned dynamically, or if the site has more than one IP address, blocking an IP address does not block the site reliably. In this case, you should use the fully qualified domain name (FQDN) to block the site. For extra reliability, you can use both IP addresses and FQDNs in a rule. Note that you have to create separate rule elements for the IP addresses and for the FQDNs. When you use IP addresses and FQDNs in a single rule, the ISA Server rule engine first evaluates the request using the IP addresses, so that if there is a match, there is no need to try to resolve the FQDN to an IP address. This improves the efficiency of the rule. For examples of how ISA Server evaluates names and IP addresses in HTTP requests, see Name Evaluation by ISA Server in this document.

Use Fully Qualified Domain Names for URL Sets and Domain Name Sets

Use fully qualified domain names (FQDN) in domain name sets and URL sets. The FQDN is the string that is returned by a DNS server. You can find the FQDN by using the nslookup command. For example, at a command prompt, type the following:

nslookup www.fabrikam.com

As a response, you receive the FQDN for www.fabrikam.com.

For examples of how ISA Server evaluates URLs and IP addresses in HTTP requests, see Name Evaluation by ISA Server in this document.

User Authentication and Performance

When a rule requires user authentication, it must rely on connectivity to and speed of the authenticating server, such as the domain controller or Remote Authentication Dial-In User Service (RADIUS) server. The authentication process can affect the performance of ISA Server. We therefore recommend that rules requiring authentication be placed near the bottom of the list of rules (assuming that this conforms to your policy design), so that only traffic that is not matched by an earlier rule will encounter the authenticating rule.

Firewall Clients and User Sets

If the firewall policy includes a rule that refers to a user set (other than the default All Users), the Firewall client always tries to authenticate and will fail if in a workgroup or in an untrusted domain. The firewall client will not be able to establish a connection with the ISA Server computer, and no traffic will be allowed.

Protocol Definitions

Do not create protocol definitions that duplicate or overlap existing protocol definitions. This can lead to unexpected behavior. For example, you may create a rule that allows all traffic except for a specific protocol, and find that the traffic you meant to deny on that protocol is actually allowed because there is a similar protocol defined. We recommend that you check the list of existing protocols carefully before you define additional protocols.

Rules by MIME Type

MIME types should be used as a criterion only in rules that apply solely to HTTP traffic. Because MIME types are not applicable to other types of traffic, a rule that includes any protocol other than HTTP and refers to MIME types is effectively disabled for those protocols.

Array-Level Default Network Objects

Default networks are evaluated in the context of the array on which they are defined. For this reason, they may be treated inappropriately if they are used in enterprise policy. For example, in the case of back-to-back ISA Server arrays, the VPN Clients network for the back-end array is the Internal network for the front-end array.

Enterprise Policy and System Policy

The system policy, which is on the array level, is evaluated before the pre-array enterprise policy. For this reason, if you create a pre-array enterprise-level rule, it may not result in the expected behavior. For example, if you want to prevent remote management, you could create an enterprise-level rule to deny that access. However, you would also have to change the system policy rule allowing remote management by removing all of the traffic sources from the rule. Recognize that because an array administrator can modify system policy rules, the array administrator can change this behavior without the knowledge or approval of the enterprise administrator.

Access Rules and Network Rules

An access policy that defines access between two networks will not allow access unless there is also a network rule defining the relationship between those two networks. This is also true for server publishing rules, but not for Web publishing rules.

Deny Access Rule on All Protocols with Source Port Restriction

Do not create a deny access rule on all protocols that includes a source port restriction. Because source ports are not checked for secondary connections, all protocols will then be blocked on secondary connections (if the rule allowing the secondary connection is lower in the rule order than the deny access rule with the source port restriction).

Logging for Enterprise Deny Rules

Consider disabling logging on deny rules, including the default, post-array deny rule in each enterprise policy. This reduces the amount of logging generated by self-propagating worms, and reduces the impact of such worms on ISA Server. The disadvantage of disabling logging on the default, post-array deny rule is that it limits debugging of preceding rules if they do not match the traffic they were intended to match.

Secure the Remote Management Computers Computer Set

Restrict membership in the Remote Management Computers computer set to computers that require remote administration access. For example, do not add entire networks, such as the Internal network, to the computer set. This helps protect the firewall from worms that affect those networks.

Network for Infected Computers

Create a network to contain computers that are infected. Do not create any network rules for the network, so that it will not have any access. When a computer is infected, move it into that network. For Enterprise Edition, this has to be performed on the array level. Note that each computer that you move into this network creates a gap in the address range of the Internal network, thus fragmenting it. Fragmented networks have a negative performance impact on ISA Server Network Load Balancing (NLB), so this approach should be used carefully, and computers should be returned to their original network as quickly as possible.

Name Evaluation by ISA Server

When a client makes an HTTP request, it may be a name, an FQDN, or an IP address. This topic provides examples of how ISA Server handles these requests.

If an HTTP request uses a site name, such as https://www.fabrikam.com, ISA Server recognizes the name in the request and performs a forward name resolution to a DNS server to get the FQDN, aliases, and the IP addresses associated with that name. The result is that ISA Server has available the site name, the FQDN, the aliases, and the IP addresses to compare to the access rule requirements. Any one of those elements could be a match to the rule, depending on which element was used in the rule.

In the example of www.fabrikam.com, the following elements could match an access rule:

• Name: www.fabrikam.com
• FQDN: fabrikam.com
• IP addresses: 207.46.250.119, 207.46.130.108

If an HTTP request uses an IP address, ISA Server first checks the rules to see if a rule matches that IP address. During this process, if ISA Server encounters a rule that requires a name, it performs reverse name resolution to obtain the FQDN for that IP address. ISA Server can then compare the FQDN to the access rule definitions.

If the reverse name resolution fails, only the original IP address in the request is used in comparison to the rule definitions.

Enterprise Policy Design

An enterprise policy is a policy defined on the enterprise level that can be applied to arrays. The policy contains an ordered set of policy rules. An enterprise policy also contains a placeholder for where the array policy should appear within that enterprise policy's rules. For more information, see ISA Server Help.

Enterprise Policy Design Considerations

When you create an enterprise policy, you create a policy that can be applied to more than one array in your enterprise. For example, you may have three arrays that handle VPN connections, six that handle publishing, and twelve for Internet access. You can create three enterprise policies:

• Enterprise access policy for VPN arrays
• Enterprise access policy for publishing arrays
• Enterprise access policy for Internet access arrays

Each policy will contain the access rules that are appropriate for one type of array. You then apply the appropriate enterprise policy to each array, saving the effort of creating those parts of the policy on each array. Further, if a change is needed in policy, you will only have to make the change in three policies, rather than on each of 21 arrays.

Enterprise policies and array-level policies allow you to differentiate between different levels of administrative authority in your enterprise. ISA Server flexibility in enterprise policy rule placement, either before or after array-level rules, also allows the enterprise administrator to create rules that are not necessarily enforced on the array level. In that case, the enterprise administrator can create rules to relieve the burden of creating the rules from the array-level administrator, but can still give the array administrator policy flexibility. The following are several examples of how enterprise and array policies work together.

No Array Administration Allowed

Scenario: All responsibility for configuration of firewall policy is maintained at the enterprise level.

Responsibility: Enterprise administrator.

Policy: When you create enterprise policies, create all of the rules as pre-array rules, to prevent the creation of array-level rules that could affect policy. Also, the enterprise administrator can create arrays that are not allowed to create deny access rules, allow access rules, or publishing rules.

Enterprise-Level Restrictions

Scenario: You have a corporate policy that prohibits the use of a particular protocol, or access to certain Web sites.

Responsibility: Enterprise administrator. Array administrator to complete policy on array level.

Policy: In each enterprise policy you create, include rules that deny access on the restricted protocol or to the restricted URL set. Because this is a rule that must be enforced throughout the company, and you do not want it overridden by an array-level rule, the rule must appear in the pre-array rules.

Reduce Array-Level Responsibilities

Scenario: The array-level administrators have several other functions, and you do not want them to spend time designing array-level policies for access issues that can be handled on the enterprise level. For example, your company allows access on Hypertext Transfer Protocol (HTTP), Secure Hypertext Transfer Protocol (HTTPS), and File Transfer Protocol (FTP), or allows access on certain protocols to specific sites or servers on the Internet.

Responsibility: Enterprise administrator. Array administrator to complete policy on array level.

Policy: In each enterprise policy you create, include rules that allow the required access. For access that is necessary throughout the enterprise, you do not want the rules overridden by an array-level rule, so they must appear in the pre-array rules. However, if there is some access that is not required, and there may be circumstances in which an array administrator may want to block access (for example, block FTP to conserve bandwidth), those rules should be placed in the post-array rules. The array administrator can create an array rule that will match requests before the enterprise rule is encountered, effectively overriding the enterprise-level rule.

Additional Information

Additional ISA Server 2004 documents are available on the ISA Server 2004 Guidance page (https://www.microsoft.com).