概要
本文对Microsoft 的Internet信息服务器(IIS) 4.0中一些安全功能的错误理解进行了详细的解释，包括客户证明映射、IP地址限制、加密套接字协议层（SSL）服务器捆绑以及Web
许可。你不但能发现这些功能是如何工作的，也能知道如何优化它们的配置。
在阅读本文之前你应该对IIS和Microsoft Windows NT?4.0的安全性有一个基本的了解，其中包括公用关键字结构、SSL协议、安全信用以及鉴定。
为了更好地理解这些定义，请在http://localhost/iisHelp/iis/misc/default.asp上阅读你的服务器的IIS文档。我们将从讨论Windows
NT和 IIS安全性的关系开始，然后再转到IIS的特殊问题上，例如鉴定、IP限制、SSL以及Web 许可。在文章结尾处，对重要的安全术语进行了一个简短的总结，并且列出了参考资源表，你可以进行深入的参考。
Windows NT和IIS
IIS 4.0是在Windows NT上运行的服务。因此，它在很大程度上依赖Windows NT用户帐号及Windows NT文件系统。
用户帐号
Windows NT 安全的核心是用户帐号及它的逻辑扩展用户群。IIS安装后，它创建两个用户帐号，给它们分配指定的用户权限，将它们放在特定的用户群中。这两个帐号是IUSR_computername和
IWAM_computername。IIS用USR_computername帐号授权对Web 资源的匿名访问。IWAM_computername则是Microsoft处理服务器(MTS)
和其它IIS实体用来提供程序和处理函数的帐号。由于本文的意图，我只介绍第一个帐号IUSR_computername。
IUSR_computername帐号需要正确地设置本地登录信息。这是因为它是在IIS内部作用的，是一个本地作用的服务，就好象它是一个物理登录到服务器上的用户。如果你在匿名登录时使用IUSR_computername以外的帐号，就要仔细选择分配给它的权限。因为你的站点的每一个匿名访问者都被授予了IUSR_computername
帐号的权限。
当IIS提供Basic和Windows要求/反应鉴定时也依靠用户帐号。为了成功地完成，这两种方法都要求有有效的用户帐号。这是必要的，因为IIS虽然创建并配置了IUSR_computername
帐号用于匿名的鉴定，它却并不为Basic 鉴定创建任何帐号。IIS假定你已经或准备创建Windows NT 帐号用于Basic和要求/反应。
注意：当用于Basic 和要求/反应鉴定时必须要有有效的Windows NT 帐号。Windows NT 或IIS都不会为你创建这些帐号。没有这样的帐号，
这些鉴定方法就不能工作。
Windows NT文件系统
虽然IIS在一个文件分配表(FAT) 硬盘驱动器上也能很好地发挥作用，你还是应该考虑将格式转化为Windows NT文件系统(NTFS)。因为：
不象FAT, NTFS对DOS是不可视的。这使你的资源可以面对来自DOS指令的攻击更加安全。
NTFS允许你配置访问控制列表(ACL) ，给用户和用户组帐号授予或拒绝授予不同形式的访问权限。
NTFS 文件系统在硬盘空间上效率更高。
在第二点，我提到了访问控制列表(ACL）。一个ACL是用户帐号、用户组、关系到某特定资源（如目录或文件）的权限的列表。例如，MyISAPI.dll
文件应该有一个列表的用户帐号和用户组可以访问它，以及他们被授予哪个级别的对文件的访问权，是读、写或是执行。ACL是Windows NT 安全模式的另一个核心功能，它允许对硬盘上的资源进行灵活准确的访问控制。每个目录和文件都有它自己的ACL，规定谁可以在哪里做什么。每个ACL甚至也有一个ACL，用来指定谁可以看和修改ACL本身。
NTFS 和ACL 为你提供了保护服务器资源的基础。要把一个分区或硬盘驱动器转化成NTFS，在指令提示符后键入以下内容：
CONVERT : /FS:NTFS
注意：一旦分区或硬盘驱动器已经用CONVERT 命令行功能转化为NTFS，就不能再用这个功能转化回来。有第三种功能可以将其转化回来。
IIS安全深入讨论
这一部分将深入讨论Web 许可、鉴定、客户证明映射、IP地址及域名限制、加密套接字协议层（SSL）加密法等。
Web许可与NTFS许可
IIS有诸如读和写这样的Web 许可。NTFS也有它自己的许可，例如读或写。不要惊讶，这有时候让人糊涂。理解两者之间区别的关键在于：Web 许可实际上控制哪些HTTP动词被允许在HTTP资源上执行。NTFS许可控制哪个用户帐号对硬盘上的资源有哪种类型的访问许可。
HTTP动词是从浏览器的头文件发送的指令，向资源发出请求。例如，一个用户也许说：“我想要读（获取）这个页面。”那么发送的头文件就会指定这个资源，以及它在电脑空间中的位置。另外它还要发送GET动词。这个动词告诉IIS请求者想要读资源。FTP动词对向服务器写入更熟悉，但是通过HTTP连接也可以作到。
这就是IIS中的Web 站点标签的读写检验框的内容。它们控制资源允许什么HTTP动词。它们不控制资源的NTFS 文件系统许可。
如果你将Web 许可设置成只读，那么在NTFS 中是否也设置成只读了呢？答案是否定的。这是因为Web许可只是控制哪些HTTP动词可以用在HTTP请求中。如果我在NTFS中设置了只读，那么我是否在IIS中也设置了只读呢？这次的答案是个响亮的“是”。即使Web许可设置为读和写，而NTFS是只读，那么HTTP的写请求也会失败。
如果Web和NTFS许可不统一，那么这两者中限制程度更高的那个将被用在HTTP请求中。例如，你设置了"SiteB"作为一个Web 站点，指向一个NTFS驱动器的"Site_B"
文件夹。然后你将Web许可设置为读写，将NTFS许可设置为只读。
当一个用户试图向http://www.SiteB.com写入时，请求会失败。即使IIS说可以向站点SiteB中，也就是说文件夹"Site_B"中写入，NTFS也会说不可以。如果有人在SiteB
网络上试图向Site_B中粘贴一个文件，同样不可以。
现在试试将许可调换过来。NTFS是读写，而Web许可是只读。结果是由于许可被拒绝，Web用户还是不能向Web站点写入。但是网络客户可以很容易地粘贴文件，因为NTFS并不在意IIS说什么。IIS只能对HTTP请求发表意见，而不能对文件系统请求发表意见。
许可mantra: 如果Web和NTFS 许可不统一，那么限制性更高的将被用于HTTP许可。
选择正确的鉴定方法
匿名鉴定适合于一个公共Web 站点，因为任何人都允许访问站点上的资源。对于那些包含机密信息的站点，你就需要更加小心地控制访问。这时有4种鉴定方法供你选择：Windows
NT 要求/反应鉴定、Basic鉴定、客户证明映射或是一个客户鉴定应用程序，如ISAPI过滤器。
Windows NT 要求/反应
Windows NT 要求/反应鉴定直接使用Windows NT用户帐户，不通过网络传输诸如用户名和口令等登录信息。如果你想保护客户的用户名和口令的话，这一点很重要。另外，由于这类鉴定使用单独的用户帐号，在那些客户的访问级别上就可以有较大的灵活性。
Windows NT 要求/反应鉴定使用散列技术来传输信用的技术。在散列过程中，一个普通文本信息的副本通过一个数学操作而形成了一个128--160位长的杂乱信号。这个杂乱信号被称为是单程的，就是说，想从中再得出原始信息从算法上是不可行的。Windows
NT 要求/反应鉴定在客户和服务器之间进行一系列的这些杂乱信号的交换，由此在给用户授与访问资源的权限之前，建立起用户的识别身份。
以下是杂乱信号能很好地应用于安全性的原因：
所有从同一个算法中得出的杂乱信号值长度都相同。这就是说，你取一个5个词的信息和一整套百科全书通过同样的杂乱信号算法，其结果长度是相同的。
非常相似的信息的杂乱信号值很不相同。比如说你取一整套百科全书，然后运行杂乱算法。然后你在其中的一册中增加一个字符，再运行同样的算法。从中得出的两个值，除了长度一样外，其它内容看起来一点也不象。
一个杂乱信号可能是从无穷多的信息中演变出来的。这就是为什么从一个杂乱信号中重新得到原始信息在算法上不可行的原因。
因为在整个密码交换过程中，客户和服务器都要进行鉴定，没有人能够插手并模仿服务器--用户知道他们正在对付谁。尽管这个过程很有效，但是有两点局限：
要求/反应在一个安全extranet 上不能工作，因为它不能在代理服务器或其它防火墙应用程序上运行。也就是，要求/反应在intranet环境下工作最好。
唯一支持要求/反应的浏览器是Internet Explorer 2.0 及以上版本。如果这是你使用的唯一一种鉴定，这就会极大地限制你在Internet
上服务的客户。
Basic 验证：基本验证
Basic鉴定用Base64 编码方法在线路上传输用户名和口令。如果你想要使用Basic 鉴定，就必须记住以下几点：
已经有对Base64 编码信息包进行解码的功能。这就意味着在Internet 上截取这些信息包相当容易。一旦IP信息包被截获并解码，所使用的帐号口令就清晰可见了。IP信息包是信息在网络上传递的单位，就象信封中的一封信。
无论什么时候，用户也不能确定他们向正确的服务器发送了他们的口令信息。也就是说，Basic鉴定中没有服务器鉴定。
要创建一个能“哄骗”Basic 登录对话并获取用户登录信息（如他们的帐号口令）的程序是有可能的。
Basic 鉴定因其易于实现而在Internet上广泛应用；大部分浏览器都支持它；更高级别的安全性是不需要的。实际上，除非你的站点被黑客注意上了，不会有很多人等着截获你的IP信息包的。
让Basic鉴定更安全
现在你可能正在疑惑，如何才能实现一个大部分浏览器都支持的安全鉴定方法呢？答案是使用SSL加密的Basic 鉴定。这种组合将允许你对你的敏感信息实现严密的访问控制，而不用害怕登录信息被截获和恶意使用。它还允许对服务器进行鉴定，这样用户就能对你的身份有信心了。这方面的细节可以参考
"SSL Mysteries"。
要建立有SSL的Basic 鉴定：
1、获得一个服务器证明（我将在后面谈到服务器证明）。
2、当访问一个资源时，要求这个资源的安全频道（这个也将在后面谈到）。
3、只使用Basic 鉴定，就是说要关闭匿名和要求/反应鉴定。
4、告诉那些访问你的站点上已经被保护的区域的人，使用HTTP的URL格式。
使用"https://"告诉IIS打开一个SSL加密的session。安全连接结束后，IIS使用Basic鉴定。现在用户信息就安全了。
注意加密的页面比普通的Web 内容使用的服务器资源要多，而且加密的传输要花掉更长的时间。要使加密的Web 页面保持简单--不要包括大的图形和多媒体的应用。
如果你真的需要监控是谁访问你的站点时，有SSL的Basic 鉴定可以很好地满足要求。如果你觉得这些都不够理想，那么有另一种安全鉴定的方法你可以考虑：客户证明映射。
客户证明映射
一个客户证明是访问你的站点的用户的数字识别号。它包含用户信息，并用一个来自发放证明的证明机构（CA）的数字签名来签署。一个数字签名基本上就是一个杂乱信息，如果是证明的话，就是用发送者的私用关键字进行加密的。在这种情况下，发送者就是CA。有关私用关键字的信息可以参考
"What is a key pair?" 部分。
IIS可以被配置成忽略、接受或要求客户证明。要理解每个设置是如何改变IIS对客户证明的反应的，这非常重要。
忽略鉴定：IIS不会注意到用户请求时发送他们的证明；IIS只是用另一种方法如要求/反应来鉴定用户；
接受证明：如果发送了一个客户证明，IIS就利用这个证明信息来鉴定他们。如果没有发送客户证明，IIS就用其它的方法；
要求证明：IIS只满足提供了有效证明的用户的请求。
IIS客户证明映射将客户证明信息与Windows NT 用户帐号相联系或映射。这种鉴定方法非常安全和灵活，而且大部分新的浏览器都支持客户证明。
IIS使用两种方法来将客户证明映射到这些帐号：多对一和一对一。两者的区别在于一对一使用实际的证明，而多对一使用证明中包含的某些信息，如证明的发布者是谁。使用一对一映射时，如果用户得到了一个新的证明，旧的映射就会失效而必须为新的证明建立起新的映射。而使用多对一映射时，如果用户得到了一个使用同样信息的新证明，映射就会象接受旧映射一样接受新映射。
举例说明，Bob用Microsoft 为公司得到了一个新的客户证明，单位的证明是MyUnit，城市的证明是Mycity,州的证明是MyState。当他从CA那里得到证明时，其中就包含着他提供的所有信息，外加一些特殊的信息(请看
"What is in a certificate?"部分)。 Bob的证明要用一对一和多对一两种方法映射到他的用户帐号，这两种方法效果都很好。
过了一段时间，Bob又用与上面列出的信息同样的内容得到了一个新的证明。他所得到的证明中包含着与第一个完全相同的信息（如Microsoft等），但是特殊信息有一点不同。原来的多对一映射还是有效，因为它并不关心特殊信息，它只关心Bob
所输入的信息(如 Microsoft）。而一对一映射就失败了，因为在鉴定过程中它使用了特殊信息。
在多对一映射看来，新的证明与旧的完全相同。而在一对一映射看来，新的证明是一个全新的证明，因此就是无效的。必须为Bob的新证明建立一个新的一对一映射。
在证明中有什么？
一个证明是一个特殊的文本文件，它包含两部分：一个明码电文（人们是可以读的）部分，包含着所有者、发行者等的信息，还有一个加密部分（不可读）部分，包含数字签名和证明鉴定的公用关键字。
文本文件被给予了.cer 扩展名，这样当你打开它时，操作系统就使用它所拥有的鉴定功能来看这个文件。 如果你在Notepad 中打开这些文件中的一个，就会看到：
-----BEGIN CERTIFICATE-----
CBHcm91cCBDQS5jcmwwRqBEoEKGQGZpbGU6Ly9cXENFUlRTUlZcQ2VydFNydlxDZXJ0RW5yb2xsXE1TIENl
cnRTcnYgVGVzdCBHcm91cCBDQS5jcmwwCQYDVR0TBAIwADBiBggrBgEFBQcBAQRWMFQwUgYIKwYBBQUHMAK
GRmh0dHA6Ly9DRVJUU1JWL0NlcnRTcnYvQ2VydEVucm9sbC9DRVJUU1JWX01TIENlcnRTcnYgVGVzdCBHcm
91cCBDQS5jcnQwDQYJKoZIhvcNAQEEBQADQQAhq70nRlse0ulPstU+IWdjeNj5p
-----END CERTIFICATE-----
多对一映射
多对一映射只使用证明中包含的一些文件，例如证明是谁发布的以及是发给谁的。你可以设置通配符规则，例如“接受从某某证明机构中发出的所有证明”。规则多特殊或多普遍都可以。通过这种方法，你可以又容易又快地将许多证明映射到单一的用户帐号。而且在服务器上不需要有客户证明的副本。如果用户取得了一个与以前相同信息的新证明，旧的映射也一样有效。
一对一映射
因为一对一映射使用的信息对于每个证明都是唯一的，你可以对用户的身份有信心。因为一对一映射使用密码交换，这一点很象要求/反应鉴定，其中包含着客户证明的关键字对。在交换的过程中，服务器要将用户浏览器发送的信息与服务器上客户证明的副本相比较。因此，一对一映射要求服务器上必须要有每个客户证明的副本。
因为服务器要使用客户证明的一个实际的副本来进行这个比较，因此如果客户取得了一个新证明的话，就必须获得这个证明的一个副本，然后建立一个新映射。即使生成这个新证明的用户信息是完全相同，也必须这样做。这是因为每个证明的关键字对都是绝对唯一的。
什么是关键字对？
加密法和其它安全方法包含了一个称为关键字的唯一值的使用。最广泛使用的加密方案是使用关键字对。正如它的名字所表示的，一个关键字对包含两个关键字。一个称为公用关键字，是由许多人共享的。另外一个是私用关键字，只有证明的主人才知道，不管它是服务器证明还是客户证明。私用关键字和公用关键字形成了一个不对称的关键字对，在密码传输的两端这两个关键字都彼此不同。如果你用私用关键字加密了一个信息，那么只有用公用关键字才能解密。如果你用公用关键字加密了一个信息，那么只有用私用关键字才能解密。
用这些关键字，你可以为向你发送信息的一方建立识别。假设你从Alice 那里接收了用她的私用关键字加密的信息。因为你知道她的公用关键字，你就可以破译这个信息并且可以确认Alice
就是发送者。如果Alice 的公用关键字不能破译这个信息，你就知道这个信息是别人发送的。如果你向Alice 发送一个信息并用她的公用关键字来加密，那么就只有她能够破译并阅读。
获取并存储客户证明
有一个明显的问题：我如何才能准确地在服务器上获取客户证明的副本？
你可以用一个脚本从http://localhost/iishelp/iis/htm/core/iicrtsc.htm 处的Windows NT选项包装文档中提取出所需要的证明信息。你可以在你的Default.asp
中使用这个脚本将客户证明信息复制到服务器上的一个文本文件中。
通过将信息拷贝到Notepad中并保存为验证文件类型（.cer），这些证明文件本身能够从文本文件中释放。拷贝文本的每一节，包括“----BEGIN
CERTIFICATE----- to the -----END CERTIFICATE-----”这些行内容。现在你可以很具需要执行以下的修改了。
这些证明文件必须是用Base64 编码的 X.509 格式才能被用在IIS客户证明映射中。也许它们已经是正确的格式了，但是为了保险，现在最好就来转化它们。如果你已经安装了Service
Pack 4，那么就可以这样来转化：
1、在证明文件上点击右键，然后打开它。
2、点击详细资料标签，并点击输出。
3、这样就引出了证明输出向导。跟随向导中的指示，选择Base64 Encoded X.509 (*.Cer) 输出文件选项。
注意：这个脚本对发送到你的站点的每个单一客户的证明的每一个例示进行复制。因此，举例来说，如果Bob 在一天中向你发送了100次他的证明，那么脚本就创建100个Bob 的证明的副本。这就是说，脚本所创建的文本文件在很短的时间内就能变得很大。为了纠正这个问题，你可以编写一个脚本或一个ISAPI过滤器，将每个证明储存在单独的文本文件中。
|
