让Web站点固若金汤(下)

--- (文/青苹果工作室)

客户鉴定应用程序
  如果你有一个现存的用户信息数据库,你想将它用于鉴定,就应该考虑创建一个应用程序。客户鉴定应用程序可以是一个ASP 应用程序、 ISAPI过滤器、 Java applets、Microsoft ActiveX?控件或 COM对象。你可以创建一个客户鉴定应用程序来执行许多与安全有关的功能,比如鉴定、IP地址限制或访问控制。
  比如说,它可以使用客户证明来鉴定用户, 提示用户输入他们的用户名和口令,或者相对一个用户信息数据库来鉴定用户。实际上应用程序的创建已经超出了本文的范围。有关创建ISAPI过滤器的信息,可以在Microsoft的 MSDN Online Web Workshop 站点上阅读Building ISAPI Filters and the CVTDOC Sample。
IP地址和域名限制
  IP地址是在网络上识别计算机的唯一的数字。用户从中提出请求的计算机的IP地址通常与请求一起发送。所以基于请求方的IP地址,你可以授予或者拒绝其对服务器资源的访问权。通过在Internet 服务管理器中选择授予访问权,你表示“除了以下列出的IP地址,我授予所有人访问权。”通过选择拒绝访问,你表示“除了以下列出的IP地址,我拒绝所有人访问。”
  通过使用网络ID和子网的屏蔽值,你可以指定单个的IP地址或成组地指定。你还可以指定一个域名或域名系统(DNS)名。使用一个域名,比如MyCompetitor.com,虽然非常方便,但是每次调用鉴定时,都会引起DNS的反向查找。这样会影响服务器的性能。
DNS查找
  DNS服务器调用一个DNS查找来识别提供的域名并为它提供IP地址。IP地址被返回到IIS,IIS就用它来进行IP地址排除。这样就有一个性能的问题。
  有两个因素影响性能。第一个是DNS访问权的物理位置。如果它是在地球的另一端,那么IIS要获得IP地址的往返路程都要花掉一段时间。如果DNS服务器就在运行IIS的计算机上,那么往返路程的时间就能省下了,但是查找IP地址还是要耗费CPU和内存资源。第二个因素是网络的纯粹规模。如果在你的网络上有DNS名,问题并不大。但是如果在网络上有450,000 个DNS名,那么反向查找就会用掉很长一段时间。
网络ID及子网屏蔽值
  网络ID是一个基础IP地址,用来与引入的IP地址进行比较。子网屏蔽值是一个数字,它指定网络ID中的哪一位用来与引入的IP地址进行逐位的AND 操作。
  通常,网络ID是一个特定的IP路由器的IP地址。一个IP路由器是一个计算机或其它设备,它知道它服务或发送的是哪个IP地址。当网络ID接收了一个请求,它或者将请求传递给它的节点,或者说“不,这里没有谁是那个名字”。这里通常是一个操作字。通常,公司的网络ID结构是那些网络管理员管理领域内“工作安全”条目中的一个,如果你需要知道使用的是哪种网络ID,或许可以问你的网络管理员。如果想看看你的计算机的IP地址、网络ID以及子网屏蔽值,在命令行中键入"ipconfig /all" 。
  网络ID和子网屏蔽值应该是这样的:假设在你的帐号单元中有一组IP地址,你不想让它们访问你的读写站点。那么你应该用授予访问选项给每个人授予访问权,除了你特别规定的那些IP地址。
  比如说帐号单元的网络ID是172.21.13.45。为了限制那个单元中的每个IP地址,你应该使用子网屏蔽值255.255.255.0。这有点象是使用通配符157.112.189,*这样所有以172.21.13 开头的IP地址都被排除在外了。这个问题的另一种思考方式是:“排除172.21.13.0到172.21.13.255的IP地址”。如果你要使用子网屏蔽值255.255.0.0,那么每个以172.21 开头的IP地址都被排除在外。注意子网屏蔽值并不是一个IP地址。
  网络ID和子网屏蔽值是如何工作的?
  IP地址包含四组8位数。因此,IP地址172.21.13.45 应该是这样的:
  172.21.13.45 10101100.00010101.00001101.00101101
  一个子网屏蔽值用来屏蔽逐位的比较,也就是一个AND 操作。子网屏蔽值的位模式就象屏幕一样,或者允许或者拒绝位的比较。例如,你想用子网屏蔽值255.255.255.0 来比较上面的网络ID,是这样的:
Network ID 10101100.00010101.00001101.00101101
Subnet mask yyyyyyyy.yyyyyyyy.yyyyyyyy.nnnnnnnn
Matching pattern 10101100.00010101.00001101.xxxxxxxx
  只要是有"n"的那一位,引入的IP地址就不被比较。有"y"的就进行比较。结果是任何有匹配位模式的IP地址都会被排除。匹配位模式中的"x" 意思就是“忽略这一位”。通过使用神奇的子网屏蔽255.107.0.0,你可以排除(或包括)你想要的范围内的IP地址。
  使用子网屏蔽要小心
  如果我使用了子网屏蔽值0.0.0.255, 那么所有以00101101 (45) 结尾的IP地址都要被排除。这包含4,294,967,296 个IP地址。知道使用什么样的子网屏蔽值非常重要,这样才不会将访问权授予你本来想拒绝授予访问权的IP地址。
SSL的秘密
  加密套接字协议层(SSL)是目前在Web 上创建安全处理使用最广泛的方法。基本上这种方法使用公用关键字加密来安全地生成和交换一个公共持有的关键字,这个关键字称为session 关键字,它用于对称加密法中。除非已经获取了一个服务器证明并捆绑在Web 站点范围内,IIS中的SSL功能就不能使用。
  捆绑的意思是IIS将证明与一特定的IP地址相联系,形成端口数组合。这个组合可以是“任何未分配的”:“任何未分配的”函盖了你的服务器可能包含的所有可能的Web 站点,或具体的特定Web 站点,如 172.21.13.45:80。
  跟所有的安全性问题相比,SSL看起来是比较复杂的。例如,如何将服务器证明与各个站点的证明捆绑,或是给所有的站点捆绑相同的证明?是否需要加密?你使用什么样的位强度?如何备份服务器证明?
服务器捆绑及你的服务器证明
  默认状态下,IIS使用端口443作为SSL端口。但是你也可以根据需要使用任意端口。你可以有很多站点,每个站点有一个非SSL端口数字和一个SSL端口数字。例如,你可以有一个称为ExampleSite的站点,可以把90作为非SSL端口,445作为SSL端口。用户输入http://www.ExampleSite.com 来访问非SSL版本。要访问其SSL版本,就要输入https://www.ExampleSite.com。他们也可以使用IP:端口数,比如 https://www.Example.com:445。
https:// 中的"s"非常重要,因为它告诉用户浏览器使用SSL端口。如果你使用了http://www.Example.com:445,那么什么也不会发生,浏览器只是等待,但是什么也不显示出来。如果你给一个非SSL端口使用https ,例如https://www.ExampleSite.com:90,会出现同样的情形。
  当你选择“任何未分配的”作为IP地址分配时,证明就会被捆绑到所有以前没有被捆绑一个服务器证明的Web 站点,甚至一些有分配端口的站点,例如由IIS安装的默认Web 站点和管理Web 站点。如果你的站点都没有被分配证明,那么证明就会被有效地捆绑到WWW服务上。这样也可以,服务器的功能也会很好发挥。
位长及其它
  当你用关键字管理器创建一个证明请求和关键字对时,它会问你使用什么样的关键字位长,这指的是服务器证明的私用关键字的位长。这个关键字是只有服务器知道的。不同的证明机构(CA)有不同的关键字长度容量。查看一下CA可用的关键字长度。选择你的CA可用的最大长度并进行出口限制是可行的。通常,这个长度的国内版是1024,出口版是512。
  出口限制下的关键字长度是用于加密和解密信息的实际关键字。在SSL中,这是session 关键字,在IIS的出口版本中被限制在40位长度。因此,如果你使用了IIS的一个出口版本,你就不能使用128位的session关键字。但是你仍然可以使用512位的服务器私用关键字。关键字长度可以在安全通讯对话框中设置。
请求一个安全连接
  关于安全连接,有两个问题被问得最频繁:“如何为一个虚拟路径开启SSL,而为另一个关闭SSL?”和“如果我没有激活‘当访问这个资源时请求安全频道’,SSL工作吗?”
  要解答这些问题,让我创造两个术语:激活的SSL和请求的SSL。
  激活的SSL:意味着用户可以在你的服务器上这样请求资源https:// format。也就是说,他们可以与你的服务器建立一个安全SSL连接,但他们并不是必须这样做。他们还可以使用http:// format 在未加密的连接上请求资源。一旦你将一个服务器证明捆绑到站点或你的WWW服务,SSL即被激活。
  请求的SSL:意味着只有SSL连接才能用于资源--http:// 是无效的。只有在安全通讯对话框中选择了当访问这个资源时请求安全频道这个选项,才会发生这种情况。
  当访问这个资源时请求安全频道选项只有在Master 、站点、虚拟路径或文件级才能选择。但是,一旦你给站点捆绑了一个服务器证明,那么包含在这个站点中的所有资源,也就是说所有的虚拟路径和文件,都是SSL激活的,即使你没有选择当访问这个资源时请求安全频道选项。请求设置所做的就是迫使用户建立一个SSL连接。
“一个证明”窍门
  在Master 属性级使用"任何未分配的IP地址"和 "任何未分配的站点" 捆绑一个服务器可以有效地将证明捆绑到以前没有捆绑证明的任何Web 站点。如果这是你的第一个服务器证明,就意味着它已经被捆绑到整个Web 服务。你还可以单独地将相同的服务器证明捆绑到每个站点。
使你的站点完全不能达到的最简单方法
  现在,你可能在想,是否能在Master 属性级设置访问这个资源时请求安全频道这个选项。答案是肯定的。但是这样做好吗?也许不。当你在Master 属性级设置访问这个资源时请求安全频道这个选项时,你就是在为整个站点设置,即使是那些没有捆绑服务器证明因此也就没有激活SSL的站点。这就意味着现在用户是不能到达你的站点的。如果他们使用http:// format,就会被告知资源要求SSL。随后他们使用https:// format,就会被告知页面不能装载,因为这个站点没有捆绑服务器证明。基本上所发生的情况是:你应该使用https://…,哎呀,https://…也不行。
  没有一个服务器证明,你就不能在Master 属性级设置SSL。IIS足够灵敏,可以让你在设置任何SSL之前得到一个。但是一旦你有了一个服务器证明,你就可以在Master 属性级设置访问这个资源时请求安全频道这个选项,即使是对于那些没有捆绑证明的站点。
  这里的窍门是当你在Master 属性级设置访问这个资源时请求安全频道这个选项时,会出现遗留代理对话框,你要注意这个对话框。它将列出你的所有的站点。只选择捆绑了证明的那些站点。
  注意:在Master 属性级进行任何设置都要小心,因为结果有可能会传播到每个站点、虚拟路径及WWW服务的文件。SSL也不例外。我强烈建议只在站点和虚拟路径级设置SSL,而不在Master 属性级。因为在Master 属性级设置很容易意外地使你的整个Web 服务器都不能被用户到达。而且,在Master 属性级设置意味着每个https 都会被加密。这样对服务器性能造成的影响很明显。
结束语
  我希望这些信息能帮助你更好地理解Web 安全问题和IIS的一些安全功能。停留在MSDN Online Web Workshop 上可以获得关于服务器技术的更多信息。


本文相关术语列表
访问控制列表(ACL): 一个用户帐号和用户组的列表,以及他们对于特定资源的权限。
不对称加密:一个关键字用于加密,另一个用户解密。
捆绑一个IP 地址: IIS与一个服务器证明相联系的端口数组合。
证明机构(CA):一个互相信任的发布证明的第三方机构,例如 VeriSign。
客户证明:一个访问你的站点的用户的数字ID。它包含用户的信息,并且用发布这个证明的证明机构(CA)的数字签名来签署。
默认站点:任何捆绑到端口80的Web站点。
数字签名:一个用发送者的私用关键字加密的信息的杂乱信号。
散列程序:将一个普通文本信息进行一个算法操作,形成一个160位长的杂乱值。从杂乱值中还原原始信息是不可行的。
HTTP动词:HTTP动词由用户浏览器发送,告诉IIS用户想要对他们所请求的文件进行什么操作。他们可以读 (获取) 文件或写(投递)到文件。
IP信息包:在网络上发送信息的单位。
IP路由器:一个计算机或其它设备,它知道它所服务或发送的是哪个IP地址。
ISAPI过滤器:一个应用程序,通常是一个DLL, 位于IIS的前面,作为进入IIS的请求的过滤器。
关键字位长(或位strength):关键字的二进制位的长度。用较长的关键字加密的信息比较短关键字加密的信息更难破译。
关键字对:用来建立一个SSL连接、加密传输的数据,或二者兼容的一对唯一值。在公用关键字密码系统中有一个私用关键字和一个公用关键字。用私用关键字加密的信息只能用公用关键字来解密,反之亦然。
网络ID:一个基础IP地址,作为与引入请求的IP地址相比较的起点。
公用关键字加密:一个常用的加密方法,用一个不对称关键字对来加密和解密信息。
服务器证明:你的服务器的一条数字ID。包含服务器的信息,并用发布证明的证明机构的数字签名来签署。它包含形成一个SSL连接时使用的一个关键字。为了使用SSL,你必须将一个服务器证明捆绑到你的服务器。
Session关键字:在SSL连接建立的过程中创建的一个加密关键字。只有用户和服务器知道这个关键字,并且只用于对称加密方法。
子网屏蔽值:一个数字,规定网络ID中的哪一位将被用于与跟随请求的IP地址进行逐位的AND运算中。
对称加密法:用同样的关键字加密和解密信息的方法。

参考资料
有关Web安全问题这方面的信息资料好象非常多-- 要把它们都读完是不可能的。以下所列的是适合初学者的。
The IIS online documentation(IIS在线文档)是有关IIS信息的一个完整资料,其中包括安全问题。如果你的计算机安装了IIS并且服务器正在运行,可以使用本地URL http://localhost/iishelp 来阅读这个文档。
Microsoft Internet Information Server Resource Kit (Microsoft Internet信息服务器资源工具箱)一书是另一个很好的信息来源。有关安全的那一章讨论了一些你的站点可能遭遇到攻击,以及针对它们的对策。
Microsoft Windows NT Server 4.0 Resource Kit(Microsoft Windows NT服务器 4.0资源工具箱)一书包含很多关于Windows NT安全问题的概念、信息以及建议。我强烈推荐你将它作为安全问题的参考资料。
The Microsoft Security (Microsoft 安全)站点是最新的及文档化信息的最好来源。这个站点提供了多种Microsoft产品的安全信息。
How to Troubleshoot Permissions in IIS 4.0(如何排除IIS 4.0中的许可故障)一文是有关IIS故障问题的最好资料。
Microsoft TechNet 有一些关于 Web安全的文章,是针对IT专业人士的。它还有一些讨论组。
The Trusted Systems Web(可信赖的系统Web站点)包含一些详细的资料,这些资料是从国家安全局(NSA)进行了一年的研究项目中提炼出来的。
The SANS Organization (SANS组织)是另一个大量资料的来源。有技术论文、有关安全空洞和攻击的贴子、软件工具、到其它大量资源的链界等等。
The Windows NT Security (Windows NT安全)站点有许多Windows NT及其它安全问题的最新信息。
The RSA 站点是Web 安全这一概念发源的站点之一。如果你需要加密方法的信息,这是一个查找的好去处。这个站点包含一些有关加密的非常专业的信息,以及一整套常用的加密方法标准。