The Mystery of the Zip File that Won’t Block
By Thomas W Shinder
I’ve noticed that we get a lot of quesitons related to problems blocking file types using Site and Content Rules. I’ve not had problems with this, so I decided to hit the lab and get a bunch of my students together to put together Site and Content Rules to block .zip files. I figured they would do things a bit differently than me, and it would give me a better idea of what all of you who are having problems with block file types are doing.
The lab setup was pretty basic:
- I set my computer up as a Web, FTP, NNTP, and mail server.
- The students set up an ISA Server in a VMware virtual machine, and configured their host operating systems to be SecureNAT and Web Proxy clients to their VMware virtual machine. The only way the host operating system could contact the Server is through the ISA Server in the VM.
I told the students to set up Site and Content Rules to block access to a .zip file on my server. Below are the observations I made
The Scenarios
Consider this scenario:
- Client is configured as Web Proxy and SecureNAT client.
- Client is NOT a member of a Win2k/NT domain, but uses an account that’s valid on the ISA Server SAM.
- Default Site and Content Rule in place
- Another Site and Content Rules that applies to everyone, at all times, for all sites — but it blocks access to the compressed files content group
OK, what do you think will happen if a SecureNAT/Web Proxy client tries to access a .zip file from the browser? That client WILL be able to access the file!
Why? Content Control depends on a request going through the Web Proxy service. Since the machine is configured as both a SecureNAT and Web Proxy client, the request could be denied by the Web Proxy service and then allowed through the Firewall service. The SecureNAT/Firewall service connect has no concept of HTTP MIME type or FTP file extensions, so the requests goes through and the file downloads.
But maybe that’s no the entire story. Why? Try this:
Change the configuration on the client so that its no longer just a SecureNAT client. Now the client is only a Web Proxy client. Now the client can only access the Internet via the Web Proxy service, since Web Proxy clients always communicate directly with the Web Proxy service and never use the Firewall service.
What happens? You can STILL download the .zip file! What’s going on here?
It seems that the default site and content rule is overriding our Deny .zip files Site and Content Rule. The questions is why? Both the Default Site and Content Rule and the Deny .Zip files Rule allow anonymous access to the rule, so its not an issue of anonymous access requests being processed first. Both the default and Deny .zip Rules are anonymous, and Anonymous DENY rules should be processed *before* anonymous Allow rules. But there seems to be something “special” about the configureation of the Default Site and Content Rule.
To fix this, you can disable the default Site and Content Rule and create another Site and Content Rule that allows access to the Site that contains the .zip file you want to download. This rule allows access to the Site. Now try to download the .zip file. Bingo! You can’t!
That limited Site access rule isn’t very useful. But try this: Create a new Site and Content Rule that matches the default Site and Content Rule. Now try to download the .zip file through the Web Proxy service. Bingo! You can’t. So what’s going on here? Is there some sort of magic imbued in the Default Site and Content Rule that just overrides all other requests?
Conclusion
I don’t have an answer to this question. But if someone does, I’d be glad to hear it and post it as an addendum to this article. Its an interesting question and one that does come up frequently. So, if you have an answer, let me know! Write to me at [email protected] and lets get this situation resolved. Thanks!
