Understanding the ISA 2004 Access Rule Processing

Understanding the ISA 2004 Access Rule Processing

By Stefaan Pouseele
February 2005

Last Update: 20/03/2005

1. Summary

In contrast to the simple trusted and untrusted ISA Server 2000 networking model, the ISA Server 2004 uses a far more sophisticated and flexible networking model.  As a consequence the way you define your network and firewall policy in ISA Server 2004 is completely different and therefore also the logic behind the access rule processing done by ISA Server 2004. Because the result is not always what you might expect, we will explore in this article how ISA Server 2004 process the different rule lists and how a particular rule is chosen to validate a particular outgoing request.

If you are new to ISA Server 2004, I suggest you check out first the Microsoft ISA Server 2004 website. Other very good resources are of course the ISAserver.org website and Tom’s excellent book Configuring ISA Server 2004. Also, I assume here you already have a good understanding of the ISA Server 2004 networking model, how you define networks, network rules and a firewall policy.

2. Overview

In order to describe from a functional point of view what communications are allowed between the defined networks, ISA Server 2004 uses a set of three rule lists:

  • Network rules: this list defines and describes the network topology. The rules determine whether there is a relationship between two network entities, and what type of relationship is defined (Route or NAT). When no relationship is configured between networks, then ISA Server drops all traffic between the two networks. It must be clear that a correct definition of the network objects and their relationships is extremely important to the overall working of ISA 2004.
  • System Policy rules: this list contains 30 built-in access rules which apply all to the Local Host network. Therefore, they control the communications from/to the ISA Server itself and are needed to enable the necessary housekeeping functions such as authentication, network diagnostics, logging and remote management. Keep in mind that those rules are allow rules and that you can only enable or disable them and only apply some minor changes to some of the properties.
  • Firewall Policy rules: this list contains the rules you define as a firewall administrator. This is a single ordered list of three possible rule types: access rule, web publishing rule and server publishing rule. This list includes also a special predefined default rule Last that denies all access to and from all networks. This default rule Last can not be modified or deleted. Therefore, any traffic allowed or blocked by ISA Server 2004 is done explicitely by a rule.

Note: the combination of the system policy rules and the firewall policy rules defines and describes the implemented firewall policy.

How ISA Server 2004 applies the above three rule lists to any outgoing request is shown in the figure below:

Note: the connectors 1, 2 and 3 will be used in another flow diagram shown in section 6. Round-up.

First, ISA Server checks the network rules to verify that there is a relationship defined between the two networks. If the network rules define a relationship between the source and destination network, then ISA Server will go further with the processing of the outgoing request. Otherwise the traffic is denied.

Next, ISA Server checks first the system policy rules and then the firewall policy rules in order. If a system or firewall policy rule allow the request, the ISA Server will go further with the processing of the outgoing request. Otherwise the traffic is denied.

Finally, ISA Server checks the network rules again to determine if the traffic should be routed or NATted. Also, ISA Server checks the web chaining rules (if a Web Proxy client requested the object) or the firewall chaining configuration (if a SecureNET or Firewall client requested the object) to determine how the request will be serviced.

It should be obvious that the logic behind the processing of the network rules is straightforward. Either there is a relationship defined or not. However, how the ISA server determines when a system or firewall policy rule should allow or deny the traffic is not so well defined at this point. The reason for this vagueness is that there is no simple answer to that question. The only thing we know for sure so far is that the system policy rules are processed before the firewall policy rules and that the ISA Server evaluates the system and firewall policy rules exactly in the same way.

3.  Firewall Policy

The main job of the ISA Server is to control the traffic between source and destination network. This is a key concept and the result is that the source and destination hosts must be on different networks. In other words, you should never loop back through the ISA Server to access resources on the same network. Another key concept is that ISA Server evaluates the firewall policy strictly in order. When an access rule matches the parameters of a request, that rule is applied and ISA Server does not match the request to any other rule.

Also, remember that the system policy rules are processed before the firewall policy rules and that the ISA Server evaluates the system and firewall policy rules exactly in the same way. In other words, the firewall policy should be considered as a single ordered list of rules with rule 1 – 30 containing the system policy rules, rule 31 and onwards containing the firewall policy rules and the default rule Last always at the end. Therefore, if a system policy rule and a firewall policy rule both applies to a particular request, then the system policy rule will always win from a firewall policy rule.

Take note that access rules are processed in the context of primary connections that are outbound. Therefore, you should never use protocols with an inbound direction when creating access rules.

Before exploring in more detail the rule evaluation, it is probably worth to summarize some of the differences between the three ISA client types. The following table shows the characteristics of the three ISA client types regarding how the requests are sent to the ISA server and the authentication capabilities:

ISA client Request is sent Authentication capability
Web Proxy by IP address or FQDN depending on user input Yes
(HTTP/HTTPS and tunneled FTP)
Firewall always by IP address (*) Yes
(all TCP/UDP based protocols)
SecureNET always by IP address (*) No

(*) this is true for all non-HTTP(S) requests. However, for HTTP(S) requests ISA will always check the Host field in the HTTP header instead of the requested destination endpoint (layer-3 address). As for the Web Proxy client, the Host header value depends on the user input.

The way an ISA client send his requests to the ISA server will determine if ISA will have to do forward and/or reverse DNS lookups to match a particular request to an access rule. Therefore, it is extremely important you have a rock solid DNS infrastructure in place.

4. Matching Criteria

The question is now, when does an access rule matches the parameters of a request? ISA Server applies a rule if the request matches the following rule conditions, checking the rule elements in this order:

  1. Protocol: one or more protocol definitions with an outbound direction for the primary connection.
  2. From (source): one or more network objects which can include Network, Network Sets, Computers, Computer Sets, Address Ranges and Subnets.
  3. Schedule:  any schedules defined.
  4. To (destination): one or more network objects which can include Network, Network Sets, Computers, Computer Sets, Address Ranges, Subnets, Domain Name Sets and URL Sets.
  5. Users: one or more user objects which can include All Users, All Authenticated Users, System and Network Service, and any custom defined User Set.
  6. Content groups: any content type set defined.

Some of the above conditions are straightforward to understand. Specifically the criteria Protocol, From and Schedule. Either they match or do not match. However, for the conditions To, Users and Content group this is not always so easy to understand. For example, what methodology is used if authentication is requested on a rule and the request can not be authenticated? How will ISA handle a rule with a URL set or Content group specified and the allowed protocols contain HTTP and non-HTTP protocol definitions? Let’s explore all those particular situations in more detail.

4.1. To (destination)

If you examine the properties of this element, you can have three possible value types: an IP address, a Fully Qualified Domain Name (FQDN) or a Uniform Resource Locator (URL). Lets’ first investigate what happens when IP addresses or FQDN’s are specified and then what happens if URL’s are defined.

Domain Name Sets and Computer Sets

For the purpose of this investigation we will limit the access in some way to the destinations www.cevi.be and www.pouseele.be. If we look first to the DNS resolving of those destinations we get the following results:

Destination Forward DNS Reverse DNS
www.cevi.be 193.75.143.142 www.cevi.be
cesar.cevi.be
www.pouseele.be 194.150.224.42 comsec17.win2k.combell.com

Assume now we have the following firewall policy rules in place:

Rule Protocol From Schedule To Users Content Action
1 FTP
HTTP
Internal Always FQDNs All Users All Allow
2 FTP
HTTP
Internal Always IPs All Users All Allow
Last All All Always All All Users All Deny

Note: the Domain Name Set FQDNs is populated with www.cevi.be and www.pouseele.be and the Computer Set IPs with 193.75.143.142 and 194.150.224.42. Also, we will test the FTP access with the Microsoft command line FTP client (no tunneled FTP) and the HTTP access with Internet Explorer.

For the FTP access the result will be as follows, irrespective if the client is configured as a Firewall or SecureNET client:

  • FTP access to the destination www.cevi.be will be allowed by rule #1.
    When ISA starts the evaluation of rule #1, ISA finds out that the elements Protocol, From and Schedule match. To be able to match the element To, ISA has to perform a reverse DNS lookup of the requested destination 193.75.143.142 (remember that the request is sent by IP address). This resolves to www.cevi.be, so we have a match for the element To. Then the elements Users and Content are checked and they match too. Therefore we have a full match, no further rules will be evaluated and the defined action Allow is executed.
  • FTP access to the destination www.pouseele.be will be allowed by rule #2.
    When ISA starts the evaluation of rule #1, ISA finds out that the elements Protocol, From and Schedule match. To be able to match the element To, ISA has to perform a reverse DNS lookup of the requested destination 194.150.224.42 (remember that the request is sent by IP address). This resolves to comsec17.win2k.combell.com, so we do not have a match for the element To. Therefore, ISA skips the further analyzes of rule #1 and starts the evaluation of the next rule in order.
    When ISA starts the evaluation of rule #2, ISA finds out that the elements Protocol, From and Schedule match. Next, the element To is checked and this time, without the need to perform a DNS lookup, ISA can match the requested destination 194.150.224.42 to the Computer Set IPs. Then the elements Users and Content are checked and they match too. Therefore we have a full match, no further rules will be evaluated and the defined action Allow is executed.


For the HTTP access the exact same logic will be followed with the big difference that ISA will try to match the HTTP Host header field instead of the layer-3 destination endpoint. Take note that the value of the HTTP Host header field is populated with what the user types in the address bar of Internet Explorer. The result will be as follows, irrespective if the client is configured as a Web Proxy, Firewall or SecureNET client:

  • HTTP access to http://www.cevi.be and http://www.pouseele.be will be allowed by rule #1.
    The HTTP Host header field can directly be matched with the Domain Name Set FQDNs specified in the element To of rule #1.
  • HTTP access to http://193.75.143.142 will be allowed by rule #1.
    The HTTP Host header field can, after a reverse DNS lookup, be matched with the Domain Name Set FQDNs specified in the element To.
  • HTTP access to http://194.150.224.42 will be allowed by rule #2.
    The HTTP Host header field can, after a reverse DNS lookup, not be matched with the Domain Name Set FQDNs specified in the element To of rule #1. Therefore, ISA skips the further analyzes of rule #1 and starts the evaluation of rule #2. Here the HTTP Host header field can directly be matched with the Computer Set IPs specified in the element To of rule #2.


An important conclusion we can draw so far is that the DNS resolution is extremely vital for ISA Server. Also, if you would like to allow or deny certain destinations and they give a different result when doing a forward and reverse DNS lookup, you will have to be very carefully with the network object types (FQDN or IP address) you use in the element To of the access rules.

As an exercise, let’s build a simple firewall policy which denies access to www.cevi.be and www.pouseele.be, and allow access to all other destinations. We will use the same protocols, Domain Name Set and Computer Set as in the above example. You have two ways to accomplish that goal:

  • Your first option is to create a deny rule for the destinations www.cevi.be and www.pouseele.be (rule #1) and then an allow rule for all other destinations (rule #2). No further rules except the default rule Last are in place. The question is what you should include in the element To of rule #1? The answer is that both the Domain Name Set FQDNs and the Computer Set IPs should be included. Otherwise the access to the destination www.pouseele.be will not always be blocked by rule #1, depending if the request is sent by IP address or FQDN.
  • Your second option is to create a single allow rule for all destinations except the two destinations www.cevi.be and www.pouseele.be (rule #1). No further rules except the default rule Last are in place. Again, the question is what you should include in the exceptions of the element To of rule #1? The answer is again that both the Domain Name Set FQDNs and the Computer Set IPs should be included. Otherwise the access to the destination www.pouseele.be will sometimes be allowed by rule #1, depending if the request is sent by IP address or FQDN.
    Be aware that in the last case the default rule Last is blocking the traffic because the element To in rule #1 did not match and therefore rule #1 will not apply.

URL Sets

The last item we should discuss in this topic is what happens when we specify a URL Set in the element To and non-Web protocols are involved in the same rule. When ISA Server 2004 processes a rule that applies to a URL Set, the URL Set element of the rule is only processed for Web traffic requests, that is for the protocols HTTP, HTTPS and tunneled FTP. However, for HTTPS traffic, URL sets are only processed if the URL does not have a path specified. Finally, if a client request uses another protocol, ISA Server ignores always the URL Set when processing the rule.

To verify that behaviour, let’s modify our firewall policy a little bit by replacing the Domain Name Set FQDNs in rule #1 with a URL Set URLs populated with the values http://www.cevi.be and http://www.pouseele.be. We keep rule #2 the same. The resulting firewall policy is then as follows:

Rule Protocol From Schedule To Users Content Action
1 FTP
HTTP
Internal Always URLs All Users All Allow
2 FTP
HTTP
Internal Always IPs All Users All Allow
Last All All Always All All Users All Deny

When we test now the FTP access (no tunneled FTP) to the destinations www.cevi.be and www.pouseele.be, you will see that both destinations are always allowed by Rule #2. That means that ISA Server can’t find a match for the element To in Rule #1. In other words, if ISA ignores the URL Set for non-Web protocols and nothing else is specified, then ISA will never find a match and that rule will never apply, regardless if it is an allow or a deny rule. If we would add again the Domain Name Set FQDNs in the element To of rule #1 and re-run our FTP access test, then we would have our original result: FTP access to the destination www.cevi.be would be allowed by rule #1 and FTP access to the destination www.pouseele.be would be allowed by rule #2.

4.2. Users

When you create firewall policy rules, you can apply them to specific IP addresses or to users. When you apply a rule to a user, the user will have to authenticate, presenting authentication credentials, as required for the specific rule. You can group users together in User Sets. User sets can include one or more users from any authentication scheme. For example, a user set might include a Windows user, a user from a RADIUS namespace, and another user from the SecurID namespace. ISA Server comes preconfigured with the following user sets:

  • All Authenticated Users: predefined user set representing all authenticated users. A rule defined using this set will apply to authenticated users only.
    Note that SecureNET clients can never authenticate, unless they are also VPN clients. In this case the credentials of the logged on VPN user will be used for authorization.
  • All Users: predefined user set representing all users. A rule defined using this set will apply to all users, both authenticated and unauthenticated or anonymous.
  • System and Network Service: predefined user set representing the Local System service and the Network service on the ISA Server computer. This user set is used in some system policy rules.

How the clients authenticate to the ISA server depends on the ISA client type handling the request:

  • Firewall client: ISA Server requests credentials when a session is established. Then, when the Firewall client requests an object, ISA Server does not ask that the client reauthenticate because the session already has an identity. Keep in mind that the Firewall client authenticates the user to the ISA Server on behalf of the application requesting the access.
  • Web Proxy client: after enabling Web Proxy client access for the specific network on which the user is located, you can configure the authentication mechanisms that will be used to authenticate the Web Proxy clients. When the setting Require all users to authenticate on the Web Proxy listener is selected, ISA Server will always ask for user credentials before checking the firewall policy. Otherwise, ISA Server will only request that the client authenticate if the rule requires client authentication to validate the match.

Furthermore, you should be aware of two interesting situations regarding user authentication:

  • If the rule applies to the All Users user set, ISA Server will not request user credentials. However, the Firewall client will always send credentials to the ISA Server. You’ll see this in effect in the MMC in the session and logging tab when a user name has a question mark (?) next to it. This means in fact that user credentials are presented but that they are not validated.
  • When you configure access rules that apply to users and the user can not authenticate themselves for any reason, then the request will be denied by the rule requiring authentication, even if it is an allow rule. This situation can arise if you forget to enable at least one authentication mechanism on the Web Proxy listener. By the same token, ISA server will deny any request from a SecureNET client, not being a VPN client at that moment, when hitting a rule requiring user authentication.

To verify the above user authentication behaviour, let’s create a firewall policy with rule #1 allowing the user Tom access for FTP and HTTP to all external destinations, and rule #2 allowing all authenticated users access for FTP and HTTP to all external destinations. The resulting firewall policy is shown in the table below:

Rule Protocol From Schedule To Users Content Action
1 FTP
HTTP
Internal Always External Tom All Allow
2 FTP
HTTP
Internal Always External All Auth All Allow
Last All All Always All All Users All Deny

For the Web Proxy client and Firewall Client access the result will be as follows:

  • User Tom will be allowed HTTP and FTP access to any destination by rule #1.
    When ISA starts the evaluation of rule #1, ISA finds out that the elements Protocol, From, Schedule and To match. To be able to match the element Users, ISA has to validate the user and match it with the user Tom. Either ISA Server will request authentication from the Web Proxy client or use the credentials offered by the Firewall client. Because the user Tom’s credentials are valid and the user matches the defined user Tom, we have a match for the element User. Then the element Content is checked and it matches too. Therefore we have a full match, no further rules will be evaluated and the defined action Allow is executed. 
  • Any other authenticated user will be allowed HTTP and FTP access to any destination by rule #2.
    When ISA starts the evaluation of rule #1, ISA finds out that the elements Protocol, From, Schedule and To match. To be able to match the element Users, ISA has to validate the user and match it with the user Tom. Either ISA Server will request authentication from the Web Proxy client or use the credentials offered by the Firewall client. Because the user X’s credentials are valid but the user does not match the defined user Tom, ISA skips the further analyzes of rule #1 and starts the evaluation of the next rule in order.
    When ISA starts the evaluation of rule #2, ISA finds out that the elements Protocol, From, Schedule and To match. Next, the element User is checked and this time the user X’s credentials are valid and do match the predefined user set All Authenticated Users. Then the element Content is checked and it matches too. Therefore we have a full match, no further rules will be evaluated and the defined action Allow is executed.


For the SecureNET client (not being a VPN client) the result will be as follows:

  • Any anonymous user will be denied HTTP and FTP access by rule #1.
    When ISA starts the evaluation of rule #1, ISA finds out that the elements Protocol, From, Schedule and To match. To be able to match the element Users, ISA has to validate the user and match it with the user Tom. However, a SecureNET client is unable to authenticate against the ISA Server and so no user credentials at all can be passed to the rule engine. Therefore, ISA can never validate the user and will immediately deny the request. This means also that no further rules will be evaluated.

A very important conclusion for this topic is that if ISA Server is unable to authenticate the user for whatever reason, that means that no credentials at all are presented to the ISA Server, then any request from that user will be denied by the first rule requiring user authentication, regardless if it is an allow or a deny rule. In fact, this situation is the first case that an allow rule actually will deny a request. Needless to say that this behaviour can be a little bit confusing at first sight.

4.3. Content groups

When you create an access rule, you can limit what content types the access rule applies to. Content groups are specified by configuring the content types Multipurpose Internet Mail Extensions (MIME) types and file name extensions. Content type control apply only to the protocols HTTP and tunneled FTP traffic. For other protocols, including HTTPS, ISA Server ignores always the Content groups specified when processing the rule.

When a client requests FTP content, ISA Server checks the file name extension of the requested object. However, when a client requests HTTP content, ISA Server sends the request to the Web server. When the Web server returns the object, ISA Server checks the object’s MIME type or its file name extension, depending on the header information returned by the Web server.

To verify that behaviour, let’s create the following firewall policy:

Rule Protocol From Schedule To Users Content Action
1 FTP
HTTP
Internal Always External All Users HTML Allow
2 FTP
HTTP
Internal Always External All Users All Allow
Last All All Always All All Users All Deny

Note: we use the predefined Content group HTML Documents. Also, we will test the FTP access with the Microsoft command line FTP client (no tunneled FTP) and the HTTP access with Internet Explorer.

When we test the HTTP access to a web site, you will see that the returned objects belonging to the content group HTML Documents are allowed by rule #1 and all other objects are allowed by rule #2. This means that for the latter, ISA Server can’t find a match for the element Content in Rule #1. Therefore, ISA skips the further analyzes of rule #1 and starts the evaluation of the next rule in order. In rule #2 all content is allowed. So, we have now a full match, no further rules will be evaluated and the defined action Allow is executed.

For the FTP access, ISA ignores the defined content groups in rule #1. Because you can’t configure All content types and Selected content types in the same rule, ISA Server will never find a match for the element Content in rule #1. Therefore, ISA skips the further analyzes of rule #1 and starts the evaluation of the next rule in order. In rule #2 all content is allowed. So, we have now a full match, no further rules will be evaluated and the defined action Allow is executed. This means that if you define content type control in a rule, in other words you enable Selected content types, that rule will never apply to protocols different from HTTP and tunneled FTP, regardless if it is an allow or a deny rule.

5. Filtering Criteria

Besides the matching criteria we have explored quite extensively in the previous section, an allow rule can also have some filtering criteria bound to it. Take note that the filtering criteria can only be specified for allow rules, not for deny rules. Out of the box, ISA Server supports filtering criteria for the protocols HTTP, FTP and RPC. If an allow rule applies to one or more of those protocols, you can access the filtering criteria by right clicking the rule as shown in the figure below:

  • Configure HTTP: this option allows you to configure the HTTP Security Filter to exert access control over HTTP connections using the ISA Server advanced application inspection mechanisms.
    For more information about the HTTP Security Filter, check out the Microsoft TechNet article HTTP Filtering in ISA Server 2004.  
  • Configure FTP: this option allows you to enable or disable FTP uploads.
  • Configure RPC protocol: this options allows you to enable or disable strict RPC compliance, which has the effect of enabling or disabling DCOM connections.

It is not within the scope of this article to explore the filtering criteria as such, but rather to describe their interaction with the access rule processing. A very important concept to understand is that the filtering criteria are configured on a per-rule base and that they are only checked after a full match is found on the corresponding allow rule. As a consequence, if ISA Server decides that the traffic do not comply with the filtering criteria, that traffic will be denied by the allow rule because ISA Server will not match the request to any other rule. In fact, this situation is the second case that an allow rule actually will deny a request.

To verify that behaviour, let’s create the following very simple firewall policy:

Rule Protocol From Schedule To Users Content Action
1 FTP
HTTP
Internal Always External All Users All Allow
2 FTP
HTTP
Internal Always External All Users All Allow
Last All All Always All All Users All Deny

Next, we configure the following HTTP filtering criteria on rule #1 only:

Finally, make sure you enable the HTTP Security Filter logging by adding the Filter Information field in the list of displayed columns for the built-in log viewer. This field includes information that a Web filter can log. For example, when the HTTP Security Filter denies a request, the reason for the denial is stored here.

Now, surf to www.microsoft.com and you will see that the images with the extensions gif, jpg or png are all blocked. To verify it, check out the the ISA log and you should find a number of requests allowed by rule #1 but also a lot of requests denied by rule #1. If you look further into the log, you should find the information Blocked by the HTTP Security filter: URL contains an extension which is disallowed under the column Filter Information for the denied requests. So, those requests are actively blocked by the allow rule #1.

6. Round-up

As a reminder, the methodology used by ISA Server to evaluate the firewall policy can be summarized in the following flow diagram: 

Note: the connectors 1, 2 and 3 are the same as those shown in the flow diagram in section 2. Overview.

It should by now be obvious that the ordening of access rules is very important to ensure that your firewall policy works the way you expect it to work. As best practice, the following ordering of the firewall policy rules is recommended:

  • Put Web and Server Publishing rules on the top of the list. According to the ISA help file, access rules that deny traffic are processed before publishing rules. Therefore, if a request matches an access rule, the request will be denied, even if a publishing rule would have allowed the request.
  • Next, place your anonymous access rules in the following order: first the deny and then the allow rules. These rules do not require authentication.
  • Finally, place your authenticated access rules in the following order: first the deny and then the allow rules. These rules do require authentication.

As a last note, be sure that more specific rules are always placed before more general rules and that you never use a perfect subset in a element from the same element in a previous rule.

7. Conclusion

In this article we went over how ISA Server 2004 uses the three rule lists Network rules, System Policy rules and Firewall Policy rules, which describes from a functional point of view the implemented network toplogy and firewall policy, to determine if the traffic should be allowed or denied. You should keep in mind that ISA Server is very depending on a rock solid DNS infrastructure to be able to correctly evaluate the configured firewall policy. Also, be aware that the ordering of the rules is very important and that there are two particular cases where an allow rule might actually deny the traffic.

I hope you enjoyed this article and found something in it that you can apply to your own environment. If you have any questions on anything I discussed in this article, head on over to http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=25;t=000575  and post a message. I’ll be informed of your post and will answer your questions ASAP. Thanks!  – Stefaan.

 

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top