一、安全
微軟一次又一次地做著同樣一件事情——某個軟件產品出了問題,飽受人們詬病,于是趕緊發布新的版本將問題解決。例如,發布Windows NT 4.0之后,因穩定性問題而飽受批評;于是微軟發布了Windows 2000,新操作系統的穩定性頗受好評,但Win 2K服務器默認安裝的IIS 5.0卻成了巨大的安全隱患,需要下大力氣加以整治才能解決問題。IIS 6.0默認不安裝,如果按照缺省方式安裝,Web服務器只能提供靜態內容服務。因此,從這個角度看,即使以后IIS 6.0應用引擎和組件突然出現了問題,IIS 6.0還是極大地降低了安全風險。另外,Windows Server 2003還有一個新的組策略“禁止安裝IIS”,有了該組策略,我們就可以禁止Windows 2003在活動目錄(AD)森林中禁止不準備作Web服務器用的機器上安裝IIS 6.0,防止網絡上出現根本無用的、不安全的IIS 6.0服務器。不過,目前這個組策略只對Windows 2003服務器有效,不能防止Windows XP Pro和Win 2K的機器安裝IIS 5.0。
當然,由于剛剛安裝好的IIS 6.0不支持動態內容,所以出現了第二個人們經常會問的問題:“為什么我的服務器不能運行ASP?”(前文提到,第一個人們經常會問的問題是:“IIS 6.0可以在Win 2K服務器上運行嗎”?答案是“不”)。要想在IIS 6.0上運行程序,必須使用IIS 6.0的一種新特性,即Web服務擴展,或Web Service Extension(這個名字似乎意味著它與XML Web服務有某種關系,實際情況并非如此。)
如果要為某個程序啟用Web服務擴展,首先打開IIS管理器(在“控制面板”→“管理工具”中。以前叫做Internet服務管理器或ISM),如圖一,點擊“添加一個新的Web服務擴展”,啟動向導創建一個新的規則。為規則指定一個名字,然后找到想要啟用的執行文件。另外,system32inetsrv下有一個iisext.vbs腳本,它也能夠配置并管理運行帶有IIS 6.0的Windows Server 2003的Web服務擴展、應用程序和單獨的文件。管理員可以使用此腳本來啟用和列出應用程序;添加和刪除應用程序依賴性;啟用、禁用和列出 Web 服務擴展;添加、刪除、啟用、禁用和列出單獨文件。

圖一
在圖一中,注意“所有未知ISAPI擴展”和“所有未知CGI擴展”這兩種Web服務擴展。默認情況下,這兩種擴展是禁用的,意味著除非明確地允許一個應用在IIS 6.0上運行,否則它就不能運行。如果一個用戶請求了某個沒有啟用的文件,IIS 6.0將向用戶返回404錯誤——文件或目錄沒有找到,同時在W3SVC日志中記錄“
404.2文件或目錄無法找到:鎖定策略禁止該請求”。在IIS 6.0中,404.2和其他子狀態代碼是W3SVC日志文件的一項可選功能,用來幫助排解故障、疑難(IIS 5.0和IIS 4.0中也有子狀態代碼,不過不會在日志文件中記錄,但可以將它們轉到定制的錯誤頁面,便于根據子狀態代碼執行特殊的處理)。IIS 6.0的子狀態代碼很有用,它們提供了描述問題的詳細信息,例如:403.20,禁止訪問:Passport登錄失敗;403.18,禁止訪問:無法在當前應用程序池中執行請求的URL;404.3,文件或目錄無法找到:MIME映射策略禁止該請求;500.19,服務器錯誤:該文件的數據在配置數據庫中配置不正確。所有這些錯誤和其他錯誤都映射到定制的錯誤頁面,錯誤頁面不會把子狀態代碼發送給用戶,攻擊者無法獲知具體的錯誤信息。
另一個安全方面的改進之處是IIS 6.0允許指派一個加密服務提供者(Cryptographic Service Provider,CSP),能夠將基于硬件的安全套接字層(SSL)加速器集成到IIS 6.0,從而把加密任務從服務器的通用CPU轉移到了專門為加密操作而優化的專用設備,有利于提高性能和可靠性。
二、配置數據
在IIS 5.0和IIS 4.0中,配置數據庫采用二進制文件結構,但IIS 6.0放棄了這一做法。IIS 6.0的配置數據由兩個XML文件構成:一個是Metabase.xml,包含IIS 6.0服務器的配置信息;另一個是mbschema.xml,包含配置數據的模式定義。IIS管理器提供了一項新的功能,允許保存配置數據副本,只要右擊Web網站,然后選擇“所有任務”→“將配置保存到一個文件”,然后指定配置數據副本的文件名字和保存路徑即可。按照這種方式保存配置數據時,IIS 6.0利用系統的機器碼(Machine Key)加密配置數據的某些部分,因此,配置數據的副本只對創建該副本的機器有用。
不過,在“將配置保存到一個文件”對話框中,我們可以選中“用密碼對配置進行加密”選項,然后指定密碼,用密碼來保護導出的配置文件。如果提供了密碼,IIS 6.0將用密碼來替代機器碼,以后只要提供同一個密碼,就可以將配置數據導入到另一個服務器。另外,我們可以使用命令行腳本iisback.vbs(在systemrootSystem32中)創建和管理遠程或本地計算機的IIS配置的備份副本,管理員可以使用此腳本工具創建其IIS配置的備份副本,從備份副本還原IIS配置以及列出和刪除備份副本。
有些時候,我們只要保存某個應用程序池、Web網站或虛擬目錄的配置,而不是保存全部的配置信息,這時可以按照如下步驟操作:右擊要保持配置信息的對象,選擇菜單“所有任務”→“將配置保存到一個文件”,如圖二所示,如果準備將配置數據導入到另一個服務器,必須提供加密文件的密碼。

圖二
如果右擊一個應用程序池、Web網站組或單個網站,然后選擇“新建”→“應用程序池(來自文件)”,或者“新建”→“網站”→“來自文件”,或者“新建”→“虛擬目錄(來自文件)”,就可以從保存的配置文件創建新的應用程序池、Web網站或虛擬目錄。因此,必要的時候,我們可以只創建和配置一個對象,利用“將配置保存到一個文件”功能導出對象
的配置信息,然后利用“新建”→“虛擬目錄(來自文件)”等功能將配置信息導入到多個Web網站。這就是說,我們可以先精心配置一個模板,然后用它來創建和配置新的網站。當然,出現問題時,配置信息副本還可以用來恢復網站的設置。
由于IIS 6.0配置信息是可移植的,它還有另外一個好處,這就是方便了升級。假設我們升級時不能直接在Win 2K/IIS 5.0上安裝Windows 2003/IIS 6.0,必須換一臺機器,這時就要解決如何將IIS 5.0不可移植的配置數據轉移到新的IIS 6.0服務器的問題。利用IIS 6.0配置數據的可移植性,解決辦法是:首先安裝好新的Windows 2003服務器,為原來的Win 2K服務器做一個完整的備份,然后在Win 2K服務器上安裝第二個Windows 2003服務器將它升級,導出第二個Windows 2003服務器的配置數據(用密碼加密),然后將配置數據導入到新的Windows 2003服務器。新安裝的Windows 2003服務器必須作一些調整,例如允許IUSR帳戶等,但至少現在不必重新執行全部配置操作了。
IIS 6.0的配置數據是標準的文本文件(XML文件),所以可以用記事本之類的文本編輯器打開和編輯。如果修改了IIS 5.0或IIS 4.0的配置數據,有時必須重新啟動IIS,如果系統上網站的數量很多,可能需要不少時間,例如ISP的服務器就屬于這類情況。為了解決這個問題,IIS 6.0支持一種“運行時允許編輯”功能。“運行時允許編輯”功能按照如下方式啟用:在IIS管理器中,右擊服務器,選擇菜單“屬性”,然后選中“允許直接編輯配置數據庫”選項,如圖三所示。啟用了這個功能之后,如果我們用記事本打開配置數據文件,插入一個虛擬目錄的配置,然后保存并關閉配置文件,IIS 6.0幾乎立即就能根據配置文件的設置作相應的修改,根本無需重新啟動。

圖三
既然允許直接編輯配置文件,因配置文件不合法造成的服務器、應用程序故障也必然增多。為此,IIS 6.0提供了配置文件歷史版本目錄,即system32inetsrvhistory,每次修改配置數據或重新啟動IIS 6.0,IIS 6.0都會在該目錄中保存一份原有的配置數據。
三、IIS管理器
每次產品重大升級,人們都會試圖從用戶界面尋找令人激動的新功能。IIS 6.0的管理器確實有了變化,不過改動之處出乎意料地少。
其中一個改動之處雖小,但很實用。如果在IIS管理器中右擊一個文件夾,現在可以選擇“權限”菜單打開文件夾的“安全”對話框。在這個對話
框中可以設置文件夾的NTFS授權,不必再離開IIS管理器。雖然這是一個小小的改動,也許它今年會為全世界所有的IIS管理員總共節省數千小時的工作時間。
右擊一個Web網站,選擇“屬性”,轉到“目錄安全性”頁,點擊“安全通信”下面的“編輯”按鈕,在這里可以找到另一個重要的改動之處——安全通信屬性頁允許配置SSL、證書信任列表(CTL)、客戶證書。在IIS 5.0和IIS 4.0中,除非在Web網站上安裝一個證書,否則不能訪問該屬性頁,這一限制令人不快,因為從技術上看,配置CTL、客戶證書并不要求服務器上安裝了證書,換句話說,在IIS 5.0中我們安裝證書的唯一用途可能就是因為用戶界面需要它。IIS 6.0改正了這一多余的要求,現在我們不必在Web服務器上安裝證書也可以訪問和使用該屬性頁了。
四、通配符應用程序
如果你熟悉IIS 5.0和IIS 4.0的ISAPI篩選器,可能也熟悉它們的缺點。ISAPI篩選器不僅編寫困難,而且由于它們在Inetinfo進程內運行,如果編寫時不小心留下了一點錯誤,很容易導致災難性的后果,出錯的代碼可能造成整個IIS崩潰。另外,ISAPI篩選器不能擁有常規ISAPI DLL擁有的功能。當然,不管怎樣,在IIS 5.0和IIS 4.0中,ISAPI篩選器仍是一種非常有用的組件,是唯一可以針對所有進入Web服務器或Web網站的請求執行操作的代碼。
IIS 6.0提供了一種更加靈活的新型機制來提供通常由ISAPI篩選器提供的服務,它就是ISAPI截取器(Interceptor),或者稱為通配符應用程序(Wildcard Application)。通配符應用程序的配置方式是:在IIS管理器中右擊Web網站,選擇菜單“屬性”,轉到“主目錄”頁面,點擊“應用程序設置”下面的“配置”按鈕,出現“應用程序配置”對話框,如圖四所示。在對話框的“映射”頁中,我們可以將一個或多個ISAPI DLL配置成通配符應用程序。對于每一個接收到的請求,IIS 6.0將調用這里列出的各個通配符應用程序。除了針對所有網站配置通配符應用程序,還可以針對單個網站或在目錄層次上配置通配符應用程序。由于這些ISAPI截取器是標準的ISAPI應用程序,它們具有普通ISAPI應用程序具備的所有功能,包括訪問消息正文的能力,而不僅僅象ISAPI篩選器那樣訪問消息頭。

圖四
通配符應用程序可以做到開發者要做的任何事情,諸如URL定制、驗證身份、記錄特殊的日志信息、檢測攻擊企圖、創建內容,等等。通配符應用程序結束處理后,它把請求轉交給適當的處理引擎(例如處理ASP頁面的asp.dll),由處理引擎進一步處理請求。另外,通配符應用程序還可以通過調用為ISAPI應用程序新增的ExecuteURL功能
,將請求傳遞到同一個應用程序池中的任意頁面。
新增的ISAPI通配符應用程序為創造性的應用程序設計大開方便之門。例如,IIS 6.0的URL授權功能就是作為一個ISAPI通配符應用程序(urlauth.dll)實現。URL授權功能允許IIS 6.0根據一系列的規則授予對某個URL的訪問權,例如用戶是否為某個組的成員、地理位置,以及其他在數據庫或AD中與用戶有關的信息。有關ISAPI通配符應用程序和URL授權的更多信息,請參見IIS 6.0的幫助文檔。
五、日志功能
服務器的日志功能很少成為首要的關注對象,但卻是日復一日的服務器管理和監視工作不可或缺的助手。IIS 6.0在日志功能方面有許多重大的改進,但遺憾的是,W3SVC日志事件仍不能以本地時間記錄。
在IIS 6.0中,記錄日志的功能已經改為由http.sys實現,http.sys在內核模式下運行。這一改進加快了日志寫入速度,同時避免了多個工作進程爭用同一日志文件。某些特殊的情況下,http.sys會遇到錯誤,這時它應該但卻不能將日志信息寫入Web網站的日志,例如,工作進程正在被回收,禁止http.sys處理用戶請求,或者用戶試圖連接到服務器,但請求中只提供了IIS所需信息的一部分。如果出現這類情況,http.sys將把事件寫入一個新的日志文件httperr.log。
在排解故障、優化IIS 6.0的過程中,httperr.log日志文件是十分重要的。默認情況下,httperr.log文件保存在system32logfiles目錄,但可以修改,修改方法是找到HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesHTTPParameters注冊子鍵,在它下面添加一個名為ErrorLoggingDir的字符串值,在ErrorLoggingDir中設置保存日志文件的完整路徑。在httperr.log日志文件中可以找到的信息包括:所有的503(服務不可用)錯誤,空閑連接超時,解析URL時出現的各種錯誤,最后10個提交給失敗的應用程序池的請求。
IIS 6.0還擁有一種稱為二進制日志的功能,啟用這個功能后,IIS 6.0將把Web網站的所有日志信息寫入一個二進制格式的日志文件,日志文件的擴展名是.ibl。要啟用二進制日志功能,只要把配置文件的W3SVCC/CentralBinaryLoggingEnabled條目設置成ture(1)即可。對于ISP來說,這個功能應該非常有用。ISP的每臺機器上可能有1000甚至更多的Web網站,如果每個Web網站每天生成一個日志文件,日志文件的總數很快會達到一個天文數字。微軟最近發布的Log Parser 2.0工具能夠讀取二進制日志文件并生成報告,這個工具可以從http://download.microsoft.com/do ... 5xp/en-us/setup.exe下載。Log Parser 2.0還能夠讀取前面介紹的httperr.log文件并生成報告。
從很久以前開始,IIS就允許指定本地服務器上保存日志文件的目錄了。不過,雖然IIS 5.0和IIS 4.0的IIS管理器允許在指定日志文件路徑的時候輸入一個遠程服務器的通用命名規范(UNC)的路徑,但Web服務器實際上不會把日志保存到遠程服務器。只有IIS 6.0才真正支持日志文件路徑的UNC路徑名。
六、網站ID
對于IIS服務器來說,唯一標識一個網站的不是網站的名稱,而是網站的ID數值。當我們在IIS 5.0和IIS 4.0中創建一個新的網站,Web服務器將下一個可用的數字順序號指定給網站(即,Web服務器給默認站點指定的數字是1,下一個網站是2,接下來是2、3、4,等等),這個數
字就是網站的唯一ID。如果要訪問一個網站的日志文件,首先必須知道該網站的ID,因為日志文件保存在W3SVC<網站的ID編號>目錄。如果Web服務器上運行著一個以上的網站,僅僅依靠日志文件的路徑名稱根本無法判斷哪一個日志目錄屬于哪一個網站。另外,無論是在編寫管理腳本時,還是在修改配置數據文件時,網站ID都是必不可少的,例如,在IIS配置數據文件中指定ADSI(活動目錄服務接口,Active Directory Service Interface)路徑時往往要指定正確的網站ID。
盡管如此,在IIS 5.0和IIS 4.0中,從IIS管理器無法直接找到網站的ID編號。為此,IIS 6.0的管理器在網站清單中增加了一個新的“標識符”列,該列的內容就是網站的ID編號。不過,即使IIS 6.0 Web服務器上只有二三個網站,網站的ID也可能很大,例如387660891(因此該網站的日志文件路徑是W3SVC387660891),不必奇怪,IIS 6.0不再按照順序指定網站的ID了——它根據網站的名字計算出網站的ID。
如果你編寫了一些腳本程序輔助管理,這些腳本要求使用原有的網站ID順序生成方式,可以禁用IIS 6.0新式的ID生成方式,具體的操作步驟是:找到HKEY_LOCAL_MACHINESOFTWAREMicrosoftInetMgrParameters注冊子鍵,創建一個REG_DWORD值IncrementalSiteIDCreation,將它設置為2(注意,默認情況下,該鍵不存在)。
七、異步CGI處理
IIS 5.0和IIS 4.0以同步方式運行CGI(Common Gateway Interface,通用網關接口)進程,這實際上意味著每次只有一個線程能夠訪問一個CGI進程,所以IIS 5.0和IIS 4.0對CGI支持的可伸縮性不佳。IIS 6.0能夠異步運行CGI進程,所以如果一個線程調用了一個CGI應用程序,它不必再等待CGI進程處理完畢和返回信息。異步CGI改善了IIS服務器運行CGI Web應用程序的性能,使得IIS能夠運行更多執行關鍵任務的基于CGI的應用程序。
當Web服務器接收到包含CGI程序名和程序所需參數的URL時,CGI程序開始執行。如果將CGI程序編譯為可執行 (.exe)文件,則必須提供包含程序執行權限的目錄,以便用戶可以運行程序。如果CGI程序以腳本形式(例如Perl腳本)編寫,則既可為目錄提供執行權限,也可為其提供腳本權限。另外,如果要使用腳本權限,必須將腳本解釋程序標記為腳本引擎。
必須注意的是,默認情況下,IIS_WPG組不具備啟動CGI進程的權限。如果創建了新帳戶并將其添加到IIS_WPG組,還必須授予此帳戶兩種啟動CGI進程的用戶權限,即“調整進程的內存配額”和“替換進程級令牌”。
八、帶寬限制
在IIS 5.0和IIS 4.0中,Web網站屬性對話框的“性能”頁允許啟用帶寬限制功能,指定允許網站占用的最大帶寬。不過,這個功能不一定起作用,因為IIS 5.0和IIS 4.0不能直接操作服務器的網卡。
IIS 6.0則不同,第一次啟用帶寬限制功能時,Windows 2003自動安裝QoS數據包計劃程序供IIS服務器調用。QoS數據包計劃程序使得服務器能夠控制服務質量(即QoS),因此安裝期間Windows 2003將臨時地停止所有網絡服務。配置好QoS數據包計劃程序后,IIS才真正有了擔負起控制網站帶寬限制所需的驅動程序——對于ISP來說,這無疑是一個好消息。允許設置的最小帶寬限制值是1024 Byte/秒。不要忘了檢查一下網卡是否在Windows 2003硬件兼容清單(HCL)中,因為只有最新的網卡才支持QoS功能。
要配置QoS數據包計劃程序,首先必須創建一個組策略控制臺。點擊“開始”→“運行”,輸入“mmc”,然后點擊“確定”。在控制臺窗口中,選擇菜單“文件”→“添加/刪除管理單元”,點擊“添加”,在“添加獨立管理單元”對話框中,選擇“組策略對象編輯器”,然后依次點擊“添加”、“完成”、“關閉”、“確定”。現在依次擴展控制臺中的“本
地計算機策略”、“計算機配置”、“管理模板”、“網絡”,顯示出“QoS數據包計劃程序”,如圖五所示。

圖五
啟用帶寬限制之前,請使用系統監視器檢查“網絡接口”對象中的總字節數/秒或當前帶寬計數器。如果希望比較傳入和傳出流量,請檢查發送的字節數/秒和接收的字節數/秒,再比較“網絡接口”對象的值和網絡連接的總帶寬。對于“正常”的負載,服務器使用的帶寬不應超過其全部可用帶寬的50%。如果服務器有較大的高峰負載,請將正常負載保持在50%以下,剩下的帶寬可在高峰期使用。
帶寬限制可以是針對全局WWW服務的(即對所有網站都有效),也可以是針對單個網站的。設置全局WWW服務最大帶寬不會替代已為服務器上的單個網站設定的最大帶寬。單個站點根據已設置的最大值來限制帶寬,而全局設置限制所有其他未限制帶寬的網站。另外,全局WWW服務帶寬限制設置不會影響FTP站點或FTP服務。
九、默認設置的變化
在IIS 6.0中,許多配置項目的默認值已經與IIS 5.0或IIS 4.0的不同。例如,默認的連接超時時間已經從900秒減少到120秒,另外,EnableParentPaths設置默認關閉。還有其他一些新的設置項目也會影響服務器的性能和行為,包括:
⑴ 如果某種文件類型沒有在MimeMap配置屬性中映射,所有對該類文件的請求將被拒絕。
⑵ 默認情況下,所有工作進程會在1740分鐘后自動回收,回收期間會話信息可能丟失。
⑶ 運行CGI應用程序的用戶上下文必須是一個IIS_WPG組的成員。
⑷ Windows 2003不安裝Collaboration Data Objects for Windows NT Server(CDONTS)。微軟建議開發者改用CDO for Windows 2000(CDOSYS)對象。
⑸ ASP請求默認限制在204800字節之下,每一個域限制在100 KB之下。IIS 5.0和IIS 4.0沒有這方面的限制。
⑹ 默認情況下,http.sys僅接受標題小于16 KB的請求。
本文關于IIS 6.0的介紹就到這里結束,雖然文章很長,但還是不可能做到面面俱到,例如,還沒有提及受到廣泛關注的Passport驗證和摘要驗證方面的改進,本文的重點放在一些具有突破性意義的IIS 6.0新特性以及幾種較少有人提及的功能,以此證明IIS 6.0改進的廣泛性、深入性。從許多方面來看,IIS 6.0的風頭甚至蓋過了Windows 2003——而且許多人認為,IIS 6.0確實有資格占據舞臺的中央。