Controlling Outbound Access for Web Proxy Clients with Site and Content Rules

Controlling Outbound Access for Web Proxy Clients with Site and Content Rules

By Thomas W Shinder M.D.

I’ve run into a spate of questions about Site and Content Rules not working properly. Actually, the problem is much more specific than just Site and Content Rules not working right, as the problem has to do with Site and Content Rules and SSL sites. All the people who have this problem describe the same thing: they’ve created a user or group they want to have limited site access. After creating the group, they create a Site and Content Rule allowing the limited user access to approved sites and deny access to all other sites. The details after that get foggy. The only consistent finding is that they can access approved sites when using HTTP, but then fail to access approved sites when the connection shifts from HTTP to HTTPS (SSL).

There doesn’t appear to be any reason for the failure of these clients’ HTTPS requests. There’s no obvious reason why Web Proxy clients that have permission to use a Protocol Rule that includes at least the HTTP and HTTPS protocols aren’t able to access a secure site. So, in an attempt to further understand the issue, and to help those ISA Server admins who are having this problem, this article will outline a procedure for allowing a particular user to use a Web Proxy client to access a select number of allowed Web sites while being denied access to all other Web site.

You need to perform the following steps to test the concept:

Let’s look more closely at the details of these steps.

You shouldn’t have any trouble doing this. In this scenario, I’ve created a user named Bob and Bob has a password of password. Bob is a member of the local machine’s Users group. The only other user account is the Administrator account, which also has a password of password. Not exactly an example of high security, but the ISA Server and the Web Proxy client machines are virtual machines, so these systems will be in the bit bucket by the time you read this.

I’ve created both of these user accounts on the ISA Server, so they exist only in the local SAM of the ISA Server machine. I’ve also configured the Outgoing Web Requests listener to accept only basic authentication. This allows me to control which user account is used to connect to the Web Proxy service. If Integrated authentication were enabled, the Web Proxy client would sent the logged on user’s credentials in the background, which means I would have to restart the computer to send alternate credentials. I don’t want to spend all my time logging on and logging off, so basic authentication only on the listener is the expedient choice. (note that I do not support this configuration in a production environment)

If the ISA Server machine and the Web Proxy client were both members of the same domain, I could have used the domain administrator account and a domain account named bob. The results would be the same.

We need to create two Protocol Rules. One Protocol Rule allows access to All IP traffic to the Administrator account. The other Protocol Rule allows access only to HTTP, HTTPS, FTP, FTP Download only and Gopher to the Bob account. With these two rules, the Administrator account can access any protocol, but if the Bob account were to try to connect to a newsgroup, the connection attempt would fail.

The figure below shows the two Protocol Rules in the ISA Management console.

There are three Site and Content Rules in this scenario. The first Site and Content Rule is the default Allow rule. The default configuration of this Allow Rule is to allow all users access to all sites and all content at all times. We will change this rule so that only the Administrator account has access to all sites and all content at all times.

We need to create two Site and Content Rules to limit Bob’s access. The first Site and Content Rule allows Bob access to the sites contained in a Destination Set that contains entries for the allowed sites. In this example I’ve created a Destination Set called UPS and it contains a single entry: www.ups.com. The Site and Content Rule allows Bob access to the UPS Destination Set (that I’ve created in advance) at all times and access to all content contained in those destinations. Note that is is critical that you do not include any type of path statement in the Destination Set. The Destination Set should included ONLY the FQDN, no path statement at all! For more details, check out the Configuring ISA Server 2000 book.

NOTE:
For a detailed explanation why the ISA Server cannot evaluate the object type and path in the SSL session, check out http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=4;t=000492

The second Site and Content Rule denies Bob access to all sites and content except for the sites and content contained in the UPS Destination Set. Since only www.ups.com is contained in the UPS Destination Set, any attempt to access another site will be redirect to www.ups.com. This redirect works because Bob has permission to access www.ups.com. In our production environments, we always redirect the users’ requests to a Web server on the internal network that contains the local network abuse policy.

Note that it’s not just enough to create a Site and Content Rule that denies access to all sites except the allowed Destination Set sites. You must always create a second Site and Content Rule that allows the user access to the allowed Destination Set sites.

The ISA Server log files are your first and best tool for solving any kind of ISA Server related connection problem. ISA Server maintains three types of connection logs: the Firewall service log, the Web Proxy service log, and the packet filter log. Although not all fields are logged by default, you should enable all fields when troubleshooting connection problems. The most important fields for you to log in the present scenario are Rule#1 and Rule#2. These fields tell you what Protocol Rule and/or Site and Content Rule allowed or denied a particular request.

The first thing you need to do is configure the Web Proxy log to log in ISA Server log format. This causes the log to use local machine time in the logs and not GMT. Using local machine time makes it a lot easier to match the times you carry out connection attempts on the client and the times listed for those connection attempts in the log file. You make this change in the Log tab of the Web Proxy Service Properties dialog box, as seen in the figure below.

The other thing you need to do with the Web Proxy log is enable all fields to be included. You can do this easily by clicking on the Fields tab in the Web Proxy Service Properties dialog box.

Here’s where the fun begins! Configuring the browser to be a Web Proxy client requires you to enter the ISA Server’s IP address in the Web proxy interface, as seen in the figure below:

The quick and dirty Web Proxy client configuration only requires you to check the Use a proxy server checkbox and then enter the Address and Port number. Of course, on a production network you would configure WPAD entries or assign the Autoconfiguration script using Group Policy or during the installation of the Firewall client.

Let’s have Bob connect to the Internet. When Bob opens his browser, he’ll see what’s in the figure below. The logon dialog box has the IP address of the ISA Server and the name of the ISA Server as the Realm (in spite of the fact that were using basic, not Kerberos authentication). We’ll enter Bob’s User Name and Password and click OK.

This brings us to the UPS Web site. What’s interesting about Bob being brought to the UPS Web site when he opens the browser is the fact that the UPS Web site is not the home page we set for Bob’s browser. The home page is set for www.msn.com. The Site and Content Rule that Bob has access to doesn’t allow access to www.msn.com and denies his request. However, not only does the Site and Content Rule deny access to www.msn.com, it also redirects the request to www.ups.com. Pretty convenient, eh?

Now for the moment of truth. I’m going to click on the LOG IN link. This takes us to an SSL page, which is confirmed by the URL in the Address bar showing https:// and the Lock icon on the status bar, which you can click and see the site certificate, as seen in the figure below.

You can see that we were able to prevent the client from access sites other than the www.ups.com site, and also access both HTTP and HTTPS sites on the www.ups.com server.

Reviewing the Web Proxy Logs

It’s completely possible that I’ve configured the rules incorrectly, or forgot about an anonymous access rule which is allowing the Web Proxy client access to sites that it shouldn’t be accessing. The best way to evaluate how the Web Proxy client was able to access the site is to look at the Web Proxy logs. Four lines from the Web Proxy log appears below:

These log entries tell me that bob was connecting from a Web Proxy client at IP address 10.0.0.3 and that he attempted to connect to www.ups.com:443 via an SSL-tunnel connection. Note that the ISA Server does not log what objects were accessed at the SSL site. The reason for this is that these objects are hidden inside the SSL tunnel at the point where the logging is takes place. This is also the reason why you can’t limit the type of object a user can access in an SSL site. If you try to limit the types of objects the user can access at an SSL site, the ISA Server will deny access to all objects, because it can’t determine what objects the user is accessing. This is a common cause for denials at sites where user otherwise has access.

Rule#1 is Bob Web, which is the Protocol Rule that allows Bob access to the HTTPS protocol. Rule#2 is Allow UPS, which is the Site and Content Rule that allows Bob access to the www.ups.com site. Now that I know the Protocol Rule and Site and Content Rule that allowed the connection, I can go back to those rules and double check them to make sure they are configured the way they’re supposed to be configured.

In this article I covered a procedure you can use to confirm that your Site and Content Rules work to limit user access to a selected number of sites, while denying access to all other sites. This procedure will also confirm that there aren’t any problems connecting to SSL sites within the list of allowed sites. It is important to keep in mind that you must allow the user access to all content types, because the ISA Server can’t determine what type of content is being accessed via the SSL link. If you limit the type of content the user can access, the ISA Server will block access to all content on the SSL site for security reasons.

I hope you enjoyed this article and found something in it that you can apply to your own network. 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=10;t=000416 and post a message. I’ll be informed of your post and will answer your questions ASAP. Thanks! –Tom