我们公司使用的防火墙是微软的ISA Server 2000，为了禁止内网访问某些不良网站，于是就在ISA Server 2000上为这些网站创建了目标地址集，并创建了拒绝内网访问这些目标地址集的站点和内容规则，但在实践中却发现，除了web proxy客户端外，SecureNAT和Firewall客户端仍能访问这些被禁止的网站，在开始，这个问题真的让人摸不着头脑，甚至怀疑这是ISA Server 2000的BUG，不过经过一系列的分析及测试后，才发现真正的原因，如果你有兴趣，就跟着我一起来揭开这个谜。

ISA Server 2000相关环境设置

在分析及解决这个问题之前，先简要地列出我ISA Server 2000上的相关设置：
1， 为了免于安装客户端的麻烦，内网用户大部分都是SecureNAT，只有很少几个Firewall客户端；
2， 由于内网用户不多，直接把HTTP Redirector配置为了send to requested web server，即SecureNAT和Firewall客户端不使用web proxy 服务；
3， 创建了一条允许内网所有外出请求的协议规则，在站点和内容规则中创建了相关的拒绝访问某些网站地址集的规则，比如拒绝对*.sex.com的访问。
这些规则设置后，照说内网就不能访问比如*.sex.com了，但实际上，除了明确配置为web proxy客户端的不能访问外，SecureNAT和Firewall客户端仍能进行访问。

原因分析

由于web proxy客户端不能访问拒绝的网站，说明使用web proxy服务的客户端成功应用了相关规则，那么把SecureNAT和Firewall客户端配置为使用web proxy服务就应该可以拒绝内网访问相关的网站了，于是就把HTTP Redirector配置为redirect to local web proxy service，结果表明上面所有规则都起作用了，也即SecureNAT和Firewall客户端此时也不能访问www.sex.com之类的网站了，因为所有来自这两类客户端的web请求都被HTTP Redirector重定向到了web proxy服务，虽然到这里，问题就可以解决了，但实际上并没有了解到深层的原因，为什么HTTP Redirector配置为send to requested web server这些规则就不起作用了呢？虽然这样没使用web proxy服务了，但firewall服务应该应用相关规则啊？照理是这样，但实际上，这里的“send to requested web server”选项不但使来自SecureNAT和Firewall客户端的web请求直接送到了所请求的网站，而且连站点和内容规则也绕过了，即让站点和内容规则失效了，这一切都是HTTP Redirector造成的，如果禁用掉这个过滤器结果会怎样呢？SecureNAT和Firewall客户端会不会正常应用上面的拒绝规则呢？应该说会的，因为此时它不起作用了，所有请求都直接由firewall服务进行处理了，但到底会怎样，还是先试试再说。于是就在ISA中禁用了HTTP Redirector，等了一会，在SecureNAT和Firewall客户端上一试，结果真不能对www.sex.com进行访问了，看来成功了，于是又添加了一个测试目标集，随便选一个就*.tom.com吧，不过“怪事”又出现了，因为www.tom.com可以得到正常访问，于是又添加了一个测试集*.yahoo.com，结果不能访问，这下就真的让人奇怪，刚才的好心情又郁闷起来了，看来是还有原因吧，经过深入分析ISA Server 2000的处理过程才发现原因是：
当SecureNAT客户端要访问某个网站时，比如www.yahoo.com，首先客户端自己就要把www.yahoo.com解析成IP地址，这样当SecureNAT客户端的web请求到达ISA Server 2000时，ISA收到的参数就是目标IP而不是www.yahoo.com，同理Firewall客户端一样（虽然ISA Server 2000可能代理Firewall客户端进行DNS查询，但查询后它会把结果返回客户端，而客户端提供给它的仍然只有目标IP参数），当ISA Server 2000接受到这些目标IP参数后，它就会查看目标地址集的设置，如果目标地址集是由IP地址构成，那么它就会把目标IP与这些地址集中的IP进行比较，从而很快执行允许或拒绝的行为，但如果这些地址集是由域名形式构成的，由于不能直接比较，所以ISA Server 2000需要先把客户端提供的目标IP转换成DNS名字再行比较，也即先要进行反向DNS查询，再把结果进行比较，在这里www.sex.com的IP是209.81.7.93，用nslookup工具对它进行反向查询结果是www.sex.com，相关命令及输出结果如下：
> set domain=.
> 209.81.7.93
Server: fzserver.fzz.com
Address: 192.168.0.88

Name: www.sex.com
Address: 209.81.7.93
显然输出结果表明它属于*.sex.com，所以被拒绝访问，而www.tom.com对应的IP很多，但对这些IP进行反向解析都不能得到结果，命令及输出结果如下：
> www.tom.com
Server: fzserver.fzz.com
Address: 192.168.0.88

Non-authoritative answer:
Name: pool1.tom.com
Addresses: 61.135.158.91, 61.135.158.92, 61.135.158.93, 61.135.158.94
61.135.158.95, 61.135.158.96, 61.135.158.97, 61.135.158.98, 61.135.158
.99
61.135.158.79, 61.135.158.80, 61.135.158.81, 61.135.158.82, 61.135.158
.83
61.135.158.84, 61.135.158.85, 61.135.158.86, 61.135.158.87, 61.135.158
.88
61.135.158.89, 61.135.158.90
Aliases: www.tom.com

> 61.135.158.91
Server: fzserver.fzz.com
Address: 192.168.0.88

*** fzserver.fzz.com can't find 61.135.158.91: Non-existent domain

> 61.135.158.92
Server: fzserver.fzz.com
Address: 192.168.0.88

*** fzserver.fzz.com can't find 61.135.158.92: Non-existent domain
在这里我们可以把这个失败的解析结果想象成数据库的null值，显然null不属于*.tom.com地址集，所以ISA Server 2000不会拒绝内网对它的访问（注意对国内网站的反向查询大多不会成功，这是由于偷懒的管理员未进行配置或没有获得反向域的授权），到这里，也许你要问了，那为什么web proxy客户端能够被拒绝对那些网站的访问呢？这是因为web proxy服务知道原始的URL，所以它可以直接与*.sex.com之类的地址集进行比较，如果URL有IP，默认情况下仍然会进行上面的反向查询，过程就与上面一样了。

解决方法

知道了上面所讲的原因，一个较好禁止访问此类网站的方案就慢慢浮出水面了，由于反向查询没有结果的网站仍能被访问，所以禁止HTTP Redirector的方法也不能收到好的效果，最好的方法就是把它配置为redirect to local web proxy service，为了防止别人用IP进行直接访问，最好还要为那些不能反向解析的IP配置相关的目标地址集。