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.

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 that use the SMTP filter, HTTP filter, or FTP filter slow performance.

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.

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.

Note:
ISA Server can only try to match authenticated users against rules that require client membership in a user set. Authenticated users include Firewall clients, virtual private network (VPN) clients, and authenticated Web clients.

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 (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.

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.

Note:
You can use ISA Server connectivity verifiers to monitor connectivity with various servers. Connectivity verifiers are described in ISA Server Help.

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.

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.

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.

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.

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.

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.

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).

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.

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.

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.

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.

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.

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.