(Listen up! This material builds on material in the book. Make sure to print out this article and put it in your book near the discussions on anonymous access and the HTTP Redirector Filter on page 532)
The Web Proxy service provides several features that improve performance for web requests. The Web Proxy service provides:
These reasons provide a compelling argument for using the Web Proxy service.
All ISA Server clients can use the Web Proxy service. SecureNAT, Firewall and Web Proxy clients can have access to it. However, the way these different ISA Server clients access the Web Proxy service differs. These differences are important because they impact how you approach securing and monitoring of web content.
Configuring ISA Server 2000 : Building Firewalls for Windows 2000
By Deb and Tom Shinder
How Firewall and SecureNAT Clients use the Web Proxy Service Neither the SecureNAT nor Firewall client directly accesses the Web Proxy service. Both these clients send their requests to the Firewall Service on the ISA Server. After the request is received by the Firewall Service, the request may be passed up to the Web Proxy service. How HTTP requests from SecureNAT and Firewall clients are handled depends on how you have configured the HTTP Redirector Filter. You can find this filter by expanding your server or array, expand the Extensions node in the left pane, and then click on the Application Filters node. Double click on the HTTP Redirector Filter in the right pane and then click on the Options tab. You will see what appears below. The default setting is to redirect HTTP requests from SecureNAT and Firewall clients to the Web Proxy service. This happens when the Redirect to local Web Proxy service is selected. You can choose to have HTTP requests bypass the Web Proxy service when the Web Proxy service is down by selecting the If the local service is unavailable, redirect requests to the requested Web server. The Send to requested Web server allows HTTP requests from SecureNAT and Firewall clients to bypass the Web Proxy service. This will prevent caching of content obtained from SecureNAT and Firewall clients, but does allow preservation of authentication information in the Firewall client logs. The Reject HTTP requests from Firewall and SecureNAT clients allows you to block HTTP requests from SecureNAT and Firewall clients. This option forces you to configure clients that need access to HTTP to be Web Proxy clients. If a non-Web Proxy client attempts to access HTTP, the request will be denied. Authentication and the HTTP Redirector Filter
There are some drawbacks to the HTTP Redirector Filter in a secure environment:
When an HTTP request from a SecureNAT or Firewall Client is passed from the Firewall service to the Web Proxy service, authentication information from the Firewall Client is removed. Of course, the SecureNAT client never provides authentication information, so the issue of removing it is moot. This makes all HTTP requests from SecureNAT and Firewall clients anonymous requests. If you don't have high security or monitoring requirements, lack of authentication not a problem. However, if you need information about who accesses what content, or if you need to control access to web content based on user credentials, then you're out of luck. The Web Proxy logs will show that all requests going through the HTTP Redirector Filter are from anonymous users. In addition, Site and Content rules you have created that require user user/group information to control outbound access to HTTP content may not be applied. Finally, you must have anonymous Site and Content rules in order for requests moving through the HTTP Redirector Filter to access HTTP content. Side Effects of Anonymous Access Rules Because you must have anonymous Site and Content rules in place to allow requests moving through the HTTP Redirector Filter, your attempts to secure Web requests may be thwarted. For example, even if you create a Protocol Rule that denies access to HTTP to a user/group or Client Address Set, an anonymous Site and Content allow rule can override the Protocol Rule setting. All HTTP requests are always initially sent as anonymous requests. If there is a Site and Content allow rule that can be applied to an anonymous user, that rule will always be applied. And that rule will always be applied before any DENY rules. However, if you were to create an anonymous DENY Protocol rule (the client type set to Any request), then all users would be denied access to HTTP, regardless of their ISA Server client type or existence of non-anonymous allow rules. NOTE: If there are no anonymous Site and Content Allow rules, the Web Proxy service will send back a request for authentication. When the browser receives the request, it will attempt to send authentication information. Machine configured as only SecureNAT or Firewall clients will not be able to send this authentication information and access will be denied. Examples
Consider the following combinations of rules:
Note that with HTTP, the Site and Content Rules have precedence over the Protocol Rule. Solve Your Problems with the Web Proxy Client
The entire issue of the HTTP Redirector and anonymous access gives me a headache. It would be nice to just configure the HTTP Redirector Filter to block access from SecureNAT and Firewall Clients and remove all anonymous access rules. But if we block SecureNAT and Firewall client access to HTTP, how will they access the Web?
The answer is to configure all browsers to send requests to the Web Proxy service. This makes the machine a Web Proxy client. The Web Proxy client can send authentication information to the Web Proxy service and therefore authentication information isn't lost like it is when using the HTTP Redirector Filter to pass requests up to the Web Proxy service. The Web Proxy client solves the problem of anonymous access because the Web Proxy client can answer the ISA Server's Web Proxy service when it requests authentication information. All browsers and many other web based applications can be configured to use the Web Proxy service. There is no compelling reason to not configure applications to use the Web Proxy service. Once you configure the clients as Web Proxy clients, user information will show up in the Web Proxy logs for all requests that require authentication. All clients will be able to take advantage of the Web cache, and performance will be improved because requests do not have to pass through the HTTP Redirector Filter. It is important to note that even when the browsers are configured as Web Proxy clients, anonymous Site and Content rules work the same. That is, if you have an anonymous Site and Content Allow rule in place, the browsers first send an unauthenticated request. If there is an anonymous Site and Content Allow rule, the requests will still be honored and treated as anonymous requests. Head's Up Remember that configuring the browser and other applications as Web Proxy clients does not cause them to send credentials with every request. They will only send credentials when the Web Proxy service requests them. If there is an anonymous Site and Content Allow rule, then the ISA Server will not send a request for credentials and will apply the anonymous rule. WARNING: Never create an anonymous DENY rule; in this case, the anonymous DENY Rule is processed BEFORE the anonymous Allow rule and all sites and content will be denied. Heads and Thumbs Up! What about non-HTTP requests? What happens when the default Site and Content rule is enabled (which allows anonymous access to everything) and you create a DENY Site and Content Rule? For example, we create a Site and Content rule that DENIES access to ftp.microsoft.com to a particular user account. When that user tries to access the site the request will be blocked, because the anonymous Site and Content Rule is not processed first for FTP requests; the DENY rule is processed first. Remember, the anonymous rules are applied and accepted before all other rules ONLY for HTTP requests. Heads, Thumbs and What's Up?!! What would happen if we sent that FTP request from a browser configured as a Web Proxy client? This time, the request would be ALLOWED, because the Web Proxy client sends FTP requests as tunneled FTP requests. These FTP requests are actually tunneled to the Web Proxy service inside an HTTP message. Therefore, the request is allowed because the default Site and Content Rule will allow all anonymous requests and will ignore the DENY Site and Content rule that blocks the user because the browser will not be asked for authentication.
Final Comment Regarding Web Proxy Service AuthenticationYou can prevent anonymous access to the Web Proxy service by requiring authentication on the Outbound Web Requests Listener. When you force authentication, no requests are anonymous, because the Listener will send back to the client a request for authentication. The effect of this configuration is that all anonymous requests are denied. Because all anonymous requests are denied, you must configure the browser as a Web Proxy client. This eliminates problems with anonymous access rules, because it turns the selection "all requests" into essentially "all authenticated requests". Note:
If you do choose to force authentication on the Outbound Web Requests listener, you will NOT be able to use Outlook Express to access your Hotmail accounts. There is a bug in Outlook Express 5.x that causes your Hotmail credentials to be sent to the Web Proxy service rather than your domain credentials. The error has been correct in Outlook Express 6.0 included with Windows XP. Summary
The HTTP Redirector Filter allows SecureNAT and Firewall clients access to some of the features of the Web Proxy service. However, one limitation of the HTTP Redirector Filter is that is strips off authentication information before forwarding requests to the Web Proxy service. The result is that in order for the requests to be honored by the ISA Server there must be anonymous Site and Content Allow rules to support the requests. Anonymous Site and Content rules are always evaluated first. This is in contrast to the fact that DENY rules are always evaluated before allow rules. To solve this problem, configure the HTTP Redirector Filter for drop requests from SecureNAT and Firewall Clients and configure all Web applications to be Web Proxy clients.