 Get
latest ISA Server content at ISA
Server Guidance.
Send
feedback about this page. |
This topic provides a brief overview of Microsoft Internet Security and Acceleration (ISA) Server 2006 firewall policy.
For more information about ISA Server firewall policy, see the online document Best Practices Firewall Policy for ISA Server at the Microsoft TechNet Web site. (http://www.microsoft.com/)
Using ISA Server 2006, you can create a firewall policy, which includes a set of publishing rules and access rules. These rules, together with network rules, determine how clients access resources across networks.
One of the primary functions of ISA Server is to connect between source and destination networks, while protecting from malicious access. To facilitate this connectivity, you use ISA Server to create an access policy that permits clients on the source network to access specific computers on the destination network. The access policy determines how clients access other networks.
When ISA Server processes an outgoing request, it checks network rules and firewall policy rules to determine if access is allowed. For Web Proxy client requests or Hypertext Transfer Protocol (HTTP), the network rule is ignored. Note that if the Web proxy is disabled, the network rule would be required.
Some rules can be configured to apply to specific clients. In this case, the clients can be specified either by IP address or by user name. ISA Server processes the requests differently, depending on which type of client requests the object, and how you configure ISA Server.
First, ISA Server checks the network rules, to verify that the two networks are connected. If the network rules define a connection between the source and destination network, ISA Server processes the access policy rules.
Next, ISA Server checks the access rules, in order. If an allow rule applies to the request, ISA Server will allow the request. Specifically, ISA Server applies a rule if the request matches the following rule conditions, checking the rule elements in this order:
After applying a rule, ISA Server does not match the request to any other rule, and stops rule evaluation. Subsequently, ISA Server may actually deny the request, depending on the additional protocol filtering applied to the rule.
Finally, ISA Server checks the network rules again, to determine how the networks are connected. ISA Server checks the Web chaining rules (if a Web Proxy client requested the object) or the firewall chaining configuration (if a SecureNAT or Firewall client requested the object) to determine how the request will be serviced.
For example, assume that you installed ISA Server on a computer with two network adapters: one connected to the Internet and the other connected to your local network. You have permissive corporate guidelines that allow all users access to all sites. In this case, your policy would consist of the following access policy rules:
Access rules that deny traffic are processed before publishing rules. If a request matches an access rule, the request will be denied, even if a publishing rule would have allowed the request.
ISA Server can make servers securely accessible to clients on another network. You use ISA Server to create a publishing policy to securely publish servers. The publishing policy, which consists of Web publishing rules, server publishing rules, secure Web publishing rules, and mail server publishing rules, together with the Web chaining rules, determines how published servers are accessed.
You can use one of the following ISA Server rules to publish servers:
When ISA Server processes an HTTP or HTTPS request from a client, it checks publishing rules and Web chaining rules to determine whether the request is allowed, and which server will service the request.
For non-HTTP requests, ISA Server checks the network rules, and then checks the publishing rules to determine if the request is allowed.
For an incoming Web request, rules are processed in the following order:
For example, consider a scenario, in which you have installed ISA Server on a computer with two network adapters: one connected to the Internet and the other connected to your local network. The following applies:
Web publishing rules are processed in order. Web chaining rules are also processed in order.
When an external client requests an object from an internal Web server, rules are processed in the following order:
For example, consider the following rules:
When an external (Internet) user requests an object from widgets.microsoft.com, ISA Server intercepts the request. First, it processes the Web publishing rule, determining that the request will be redirected to the msweb computer. Next, it processes the Web chaining rule, determining that the request will be serviced directly by the specified server (msweb).
The following example illustrates what happens when you create a Web publishing rule, without creating an appropriate Web chaining rule:
In this case, the Web publishing rule is processed first. All requests for example.microsoft.com are redirected to myinternalms. However, the Web chaining rule specifies that the request will be routed to an upstream server (and not sent directly to the destination server). The request will always be routed to the upstream server.
When a client makes an HTTP request, it may be a name, a fully qualified domain name (FQDN), or an IP address. ISA Server handles these requests differently.
If an HTTP request uses a site name, such as http://www.fabrikam.com, ISA Server recognizes the name in the request and performs a forward name resolution to a Domain Name System (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:
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.
Note
When rules requiring authentication are processed, ISA Server requires that the client present credentials. If the client cannot provide credentials, the request is dropped before the rule is evaluated. This implies that requests from SecureNAT clients are dropped if a matching rule requires authentication.
Enterprise-level rules can also be configured to require authentication. When an enterprise policy that includes such a rule is applied to an array, all Firewall clients must present credentials.
| Get
latest ISA Server content at ISA
Server Guidance.
Send
feedback about this page. |