ISA 2000中网站过滤问题的分析及解决
如果你在ISA2000中发现明明禁止了访问某个网站客户端却依然能够访问,那么此文将告诉你为什么,注意,此文不适合ISA2004。
我们公司使用的防火墙是微软的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配置相关的目标地址集。