IIS進階管理與應用

作者：李忠憲

---

一、前言

IIS 伺服器由於其易用的特性，廣為各界所喜愛，然而也因為這樣使得 IIS 常被誤認為是陽春的WEB伺服器，一般技術較好的網管師大多選擇 Apache 而不是 IIS，如果著眼於執行效能，當然是 Apache 優秀，但是如果比較功能，IIS 則有較大的應用空間和價值，這不單是因為 IIS 與 Windows 網域整合容易，也由於 FrontPage 在網頁製作上的強大優勢，使得 IIS 的發展能夠令人充滿期待。

雖然大家都同意 IIS 很好用，但是一台安裝完成而未經過適當調整的 IIS，卻潛藏非常多的危機，使得 IIS 成為最容易被破解的攻擊對象，由於一般採用 IIS 的網管師，多半是初學者或技術未臻成熟，因而常忽略這個事實！本文除了探討 IIS 在應用上的各種可能性，也就安全管理提出一些看法，希望能對 IIS 的使用者有所幫助！

　

二、這些套件作什麼用？

在進行討論之前，我們先來了解一下 IIS 有哪些功能，IIS 是由數個套件構成，每個套件提供一些服務項目，在安裝時可以進行選擇。

 IIS 最重要的套件，就是 ASP ，因此從 IIS 4.0 以後 ASP 就與 IIS 難分難捨，由於 ASP 牽涉廣泛所以另文討論。其他套件中，應用比較廣泛值得一裝的還包括：Index 伺服器、FTP 伺服器、SMTP伺服元件、NNTP伺服元件、Site Server Express、FrontPage 延伸套件、Office 延伸套件等，分別概述如下：

Index 伺服器：剛出現時是為了提供網頁搜尋功能，後來也運用在檔案總管中的快速尋找服務，在 Windows 2000 裡面，被整合為作業系統的一部份，而不再是 IIS 的附加套件。

FTP：這是常見的檔案傳輸伺服器，為了製作網頁方便，也為了輔助 IIS 的網路資源交換機制（特別是匿名存取時），這是必裝的套件。

SMTP：發展互動網站免不了要透過電子郵件來傳送訊息，以這個套件而言，不但可以用來發展單向傳遞的電子報，也可以用來發展成 Web-Base 郵件伺服器，缺點是無法支援 POP 收信。

NNTP：是一個陽春的 News 伺服器，可以接受餵信，也可以提供信件給別台 News 伺服器，但是由於 News 須向上層註冊以取得信件來源，作業上比較麻煩，所以一般都拿來當獨立伺服器使用。

Site Server Express：可以用來統計和分析 IIS 的 log，並且輸出成為網頁，可惜這個過程無法自動化，因此大部分的網管師仍然採用 Webaziler 來進行分析。除此之外，安裝此套件可以取得 Active Pointer （網頁 upload）元件，所以這也是必裝的套件。（從 IIS 5.0 以後，Site Server Express 就不見了。但是 Active Pointer 元件則內建在 IIS 裡面，不需額外安裝）

FrontPage 延伸套件：提供 HTTP 1.1 通訊協定，以便進行遠端網頁製作。由於 FTP 很多人不會用，所以對學校來說，裝這個套件是必須的。

Office 延伸套件：這個套件並沒有與 IIS 一起發行，而是附在 Office 2000 裡面，和 Photo Draw 裝在同一片光碟上。這個套件可以將整個網站的每一個網頁當成討論區來討論，當然參觀者必須使用 IE 5.0 以後的版本才行。如果你需要的是一個方便好用的獨立討論伺服器，那麼就用這個套件來取代 NNTP 吧！（Office 延伸套件安裝後，會成為 FrontPage 延伸套件的一部份，也就是說，設定 FrontPage 擴充程式會自動建立 Office 討論功能，移除 FrontPage 擴充程式會一併移除 Office 討論功能 ）

　

三、Microsoft 附送的大漏洞

一裝好 IIS 就上線運作，會讓 IIS 暴露在駭客的攻擊之中。因為 Microsoft 所附送的一支叫做 code.asp 的程式，會把你硬碟上任何一個檔案的內容一五一十顯示出來，使得駭客可以輕易取得系統資訊，進行安全破解。除此之外，Microsoft 所附送的 Script 、IISAdmin 裡面，也有許多強大的功能，足以使站台讓人予取予求。

所以第一件要做的事，就是把用不到的東西從預設 WEB 站台移除，其中務必要移除的有三個虛擬目錄，分別是 Script、MSDAC 和 IISAdmin。如果您是使用 IIS 5.0 ，則會多出一個  printer 目錄，這是用來存放 IPP 相關程式，由於出現了一些安全漏洞，因此也建議一併移除不要使用。如果已經設定 FrontPage 擴充程式，會多一個 _vti_bin 的虛擬目錄，那是用來與客戶端的 FrontPage 進行認證與修改網頁用的，所以不可以移除。

　

四、權限設定

為了加強 IIS 的安全性，特別要注意權限設定。網頁的存取權限是由「 IIS主目錄權限」與「檔案權限」進行交集運算（兩者取其嚴），與 Apache 不同的是，由於檔案權限無法從遠端設定，所以一般使用者享受不到這種嚴謹的安全機制，只能由網管師根據幾個大目標來作設定（通常設定在資料夾上）。「 IIS主目錄權限」可以設定多種權限，由於 IIS 4.0 與 IIS 5.0 有版本上的差異，分別討論如下：

IIS 4.0

1. 讀取：允許傳送網頁檔案內容給瀏覽器。 
2. 寫入：允許匿名使用者對網頁資料夾進行寫入動作，包括：建立新檔案和修改舊檔案，通常是透過 ASP 程式來操作。 
3. 執行：允許匿名使用者執行檔案，並傳送執行結果給瀏覽器。該檔案若是屬於指令檔，例如：ASP、CGI、PHP等，需配合 ISAPI 應用程式對應的設定才能正確執行。若是程式檔，例如：EXE、COM，因為程式破壞力太大，如非必要不應該允許執行。 
4. 瀏覽目錄：當找不到預設文件（例如：index.htm、default.htm、default.asp）時，IIS 會將該資料夾編製成目錄網頁，傳送給瀏覽器。 
5. 日誌：會把參觀者的操作紀錄到系統日誌中，以便進行事後分析或來源追蹤。 
6. 編製索引：將網頁內容編製到索引伺服器（Index Server）內，以便參觀者搜尋，特別要注意的是，如果該目錄含有 ASP 程式，則參觀者透過網頁搜尋可以看到原始程式碼，這是一個相當嚴重的漏洞，必須要透過 Index Server 管理員進行目錄排除（Exclude）設定。 

   

   上圖是索引伺服器排除目錄的畫面 

    

    

7. FrontPage Web：允許使用者以 FrontPage 開啟網頁，並進行刪除或修改。通常需要配合「檔案權限」的設定，來強迫使用者進行身分認證，以免讓匿名使用者隨意存取。

IIS 5.0

1. 指令檔來源存取：在 IIS 5.0 中執行權限的設定，被此權限取代了。原因是，IIS 5.0 已經不再區分靜態網頁（HTML）和動態網頁（ASP），而把執行看成是必然的（當然還是可以透過應用程式設定，把這個功能關閉）。指令檔來源存取，可以看成是 4.0 版 FrontPage Web 權限的加強版，它可以用來限制 ASP 原始程式內容的讀取和修改。 
2. 寫入：與 4.0 版稍有不同，特別是指可以透過 FrontPage 來新增或修改網頁，至於透過 ASP 程式所進行的檔案操作，則由「檔案權限」來決定。因此他相當於 4.0 版 FrontPage Web 權限。 
3. 讀取、瀏覽目錄、日誌、編製索引：與 4.0 版相同。

各種使用時機的設定方式

為了保護 ASP 程式不受 IIS 的漏洞影響導致原始內容洩密，我們可以將 ASP 程式集中放置於同一目錄，並將該目錄的所有權限全部關閉，連最基本的「讀取」權限也不要保留，僅留下應用程式設定裡的「執行」權限。這樣 ASP 程式就可以獲得周密的保護，相對的要付出一些不方便的代價，例如：網頁連結或程式呼叫不能使用相對路徑，該目錄不能擺放HTML 檔案等。

如果你的目錄裡是擺放共享檔案，而且沒有製作主文件（例如：index.html），這時就必須開放「讀取」和「瀏覽目錄」權限，參觀者才能看到該目錄的內容。目錄裡擺放的文件，必須是一般文件或壓縮檔， ASP 程式或可執行檔絕對不可以擺在這種目錄裡以免遭人下載。如果您的主要目的是要提供程式下載，那麼有必要將此類檔案先行壓縮成 zip 或其他格式壓縮檔，或是將應用程式設定裡的「執行」權限設定為「無」，以避免被人在站台上執行程式。

在許多網站上經常可以見到上下傳檔案的功能，為了存放這些上傳的文件，常需要在網站上建立一個允許 everyone 存取的目錄，而這會造成很大的安全漏洞。因為有些參觀者可能會上傳一些程式到站台上，然後從遠端執行來取得系統管理權限，所以這種需要開放「寫入」權限的目錄，必須同時將應用程式設定裡的「執行」權限設定為「無」，以避免遭人入侵。

五、應用程式設定

如果不想讓使用者自行設計 ASP 程式，只要將該使用者的「主目錄」內容中的應用程式「移除」就可以了，這就像是在 Apache 中，不允許使用者執行自己設計的 CGI 程式一樣，具有比較嚴謹的安全性考量。其實在適當的規劃下，讓使用者自己開發 ASP 程式並不是那麼可怕，例如：我們可以限制讓使用者在不同的記憶體區段執行，以避免波及主要網頁的運作。這個功能可以透過修改應用程式「啟動點」來達成。另外限制使用者的 ASP 僅能讀取和執行自己目錄下的檔案，也事關重大，這可以避免使用者很輕易取得 Administrator 的管理權限。要做到這個功能，只要在「應用程式選項」中將「啟用上層路徑」關閉就可以了。

使用「指令引擎」，可以讓 IIS 不去理會該類檔案的執行權限設定，所以無論檔案權限怎麼設，都還是可以執行。這個選項存在的目的是為了提高程式直譯器的效能，然而卻也潛藏著危機。對於 EXE 或 COM 或 DLL 來說，開啟「指令引擎」等於是自殺，因為如果使用者開啟一個帶有 的網頁，那麼這台電腦也不需要什麼系統管理員了，匿名使用者就可以幫你管理了。

「檢查該檔案是否存在」，則與「指令引擎」剛好顛倒，可以要求 IIS 檢查該檔案的權限設定，根據設定來要求參觀者登入，同時可以避免因檔案不存在而使得瀏覽器失去回應。但是啟用此功能，將會使得程式執行效能變差。

目前有兩個指令引擎有大漏洞，會導致站台不安全，建議將該兩個引擎關閉以免站台遭駭客入侵，這兩個引擎為 ism.dll 以及 idq.dll ，相關檔案類型為 .htr .ida .idq 等三種。

應用程式設定常為人所忽略的，就是忘記要修改指令錯誤訊息，因為如果沒有把此選項去除，將會在程式錯誤發生時，看到詳細的原始程式碼，難免有時候就會讓瀏覽網頁的人有意外的大發現，例如：意外得知 MsSQL 資料庫的管理員密碼。

除非該網站是用於企業內部並且不對外服務，否則最好還是選用「將文字錯誤訊息傳送給用戶端」。

　

六、目錄安全設定

IIS針對目錄安全提供三種控制機制，分別是：驗證存取、IP及網址過濾、SSL安全通訊。其中的驗證存取功能，可以讓不同使用者對同一個網頁目錄擁有不同的存取權限。以下說明各種驗證方式的用途：

基本驗證用來傳送純文字密碼，由於封包在傳遞過程中有被擷取的危險性，所以安全性不夠。而IIS 4.0裡的Windows回應與挑戰驗證方式，則可以自動把用來登入 Windows 網域的帳號密碼，傳送給 IIS 判斷，傳遞前並且會先以 MD4 編密。雖然此種驗證方式較為安全，但是當瀏覽器端的平台不是 Windows 平台，或瀏覽器無法支援網域選擇功能時，將會造成簽入失敗。所謂網域選擇是指在帳號前面加上網域名稱，例如：spps\shane。有些瀏覽器將這種帳號視為輸入錯誤，而加以攔截。

如果我只使用微軟公司的產品，那麼回應與挑戰驗證方式應該能百分之百成功囉！很遺憾，當你在多個 Windows 網域環境裡使用 Win 98，悲劇就發生了。Win 98 並不認識網域而只認識工作群組，因此 Win 98 會直接傳送使用中的帳號密碼給 IIS ，當認證通不過時，Win 98 並不會給你變更帳號與密碼的機會，因為它壓根兒不知道一個人可以在不同網域擁有不同密碼。所以當 john 登入 Win 98 時使用密碼 123，但在 IIS 伺服器上 john 的密碼是 abc ，則 john 將永遠無法成功通過 Web 密碼驗證。在這種情形下，我們只好無奈的使用基本驗證了。

在 IIS 5.0 裡驗證方法多了一個摘要式驗證，其實摘要式驗證根本就是回應與挑戰的延續。微軟公司的官方文件說摘要式驗證是基本驗證的加強版，能夠將純文字密碼編成 MD5 後再傳送回伺服端解碼，聽起來好像不賴。而事實是，只有在 Windows 網域下使用非 98 平台，才能享受此便利性，這個限制令人不免想起 4.0 裡的回應與挑戰，唯一不同點只是 MD4 和 MD5 而已，然而微軟公司的宣傳部門，竟認為這是重大變革，並說它可以取代純文字驗證，真是令人啼笑皆非。

若要說 IIS 5.0 的重大變革，應該是整合的 Windows 驗證才對，這種驗證方式主要是因應 Active Directory 而生，AD 能夠將使用者用過的各種密碼，紀錄在個人帳戶資訊裡，使用單一的 AD 密碼，即可在不同場合由 AD 替你找出適當密碼來簽入不同的服務。雖然這是真正好用的功能，但是如果網域裡沒有使用 AD，那麼還是白搭。

我們可以把 IIS 驗證控制整理如下：

• 有 AD 的時候使用整合驗證。 
• 使用 NT workstation 或在單一網域內使用 Win 98 時，可以利用摘要式驗證。 
• 在多個網域環境使用 Win 98（回家以後使用撥接上網，即屬於此種情形），只能利用基本驗證。

IP與網址限制，可以用來放行或阻擋某特定網路或單機存取 IIS 網頁目錄，例如：可以針對來自企業內部的 IP 賦予修改網頁的權限，其餘 IP 則加以阻擋。

SSL安全通訊在使用前必須先從 CA 伺服器取得認證，雖然向微軟取得 CA 認證不用花錢，但是提出認證申請也是有許多手續上的困難。所以我們可以自己架構一台 Win 2000 並安裝 CA 伺服器，自己來發放認證給公司內部的伺服器，因為美國對加密演算法採取輸出限制，台灣地區只能使用 64 位元加密。（在 Option Pack 裡所附的 CA 伺服器可以安裝在 NT 4.0 上面，但是裝好後一樣要先向 CA 機構取得認證才能讓它運轉，所以還是用 Win 2000 吧！）

上圖為驗證伺服器管理員

　

七、FTP 與 WEB 的結合

FTP 與 WEB 的結合可以分為三種形式：1. 設定 WEB 虛擬目錄，連接到已經存在的 FTP 目錄。 2. 設定 FTP 虛擬目錄，連接到已存在的 WEB 目錄。 3. 在硬碟建立新目錄，並分別設定成為 FTP 和 WEB 的虛擬目錄。

因為在 IIS 裡目錄與虛擬目錄是由不同的程序來進行處理，所以上述三種結合形式都稍有差異。以第一種結合型式來說，該目錄對 FTP 來說是普通目錄，但對 WEB 來說是虛擬目錄﹔第二種結合形式則剛好顛倒，對 WEB 來說是普通目錄，但對 FTP 卻是虛擬目錄﹔第三種情形則對兩者都是虛擬目錄，由於這種差異性會造成一些操作上的不便，因而也限制了應用的場合。

以第一種情形來說，參觀者以 FTP 連接站台時，在根目錄下可以看到該目錄的存在，這是因為對 FTP 來說，它只是普通目錄。但是，當網頁製作者以 FrontPage 連結上來編輯的時候，在資料夾清單裡就會找不到該目錄，並且因而無法編修其內容。事實上，該目錄的內容將只能透過 FTP 來改變。

因此這種結合形式，主要用來提供 FTP 下載資源給 WEB 參觀者也能下載，屬於公開的目錄，並不適合拿來編輯網頁用。

使用第二種結合型式，當網頁根目錄的製作者以 FrontPage 連結上來編輯時，在資料夾清單裡可以找到該目錄並且進行編輯，這對於該目錄網頁的作者，實在是一件很諷刺的事。另一方面，對 FTP 的匿名參觀者來說，將無法在根目錄看到它，而必須在連線之前就指定要開啟的目錄，當然匿名參觀者通常是無法得知該目錄的名稱，所以就無從存取。即使成功連線了，參觀者將會看到一大堆 _vti_bin 之類的目錄，這些目錄是 Front- Page 延伸套件所產生的，以 FTP 連接時會通通顯示出來不隱藏，造成參觀者很大的困擾。

所以第二種結合形式，適合給系統管理員或 ASP 程式設計師來使用，特別是當使用 Upload 元件來進行應用程式設計時，非常的好用。這並不適合給網頁製作者來使用，也不適合開放給一般參觀者存取。

使用第三種結合型式，安全性比較高。必須在建立連線時指定資料夾名稱，否則將會無法進行使用者認證，無論是使用 FTP 或 FrontPage 來存取該目錄都是如此。這可以說是專為網頁製作者量身打造的結合形式。

無論是使用哪一種結合形式，特別要注意的是，由於「檔案權限」設定只能設一組，並不能針對不同服務設定不同權限，所以當「檔案權限」設為某使用者可以寫入時，那麼該使用者無論是透過 FTP 或 WEB 都可以對它做寫入動作，如果想要作一些限制，該怎麼辦呢？前面說過真正的存取權限是由「檔案權限」與「主目錄權限」交集運算的結果，對於 FTP 和 WEB 都是如此，所以當 FTP 與 WEB 作結合時，假如「檔案權限」無法設得太嚴格，那麼就必須適度的修改 FTP 或 WEB 的「主目錄權限」，來達到我們的要求。

無論是 FTP 或 WEB 的虛擬目錄，我們都可以將它設定為共享資料夾，如此一來，就可以讓網域內的使用者，直接打開「網路上的芳鄰」以拖曳方式來共享檔案以及將檔案公佈於網站，對於工作上需要將資料上網，但是卻沒有能力製作以及維護網頁的辦公人員，這是一個絕佳的點子。

除此之外，虛擬目錄常常也拿來作為資料保全的手段，這主要是透過將虛擬目錄關聯到區域網路上的共享資料夾來達成。當駭客攻擊 WEB 伺服器時，即使破壞了該台主機的網頁內容，但因為此虛擬目錄位於外界無法得知的主機上，所以該虛擬目錄裡的資料能夠倖免於難。虛擬目錄關聯到別台電腦，還有一種管理上的好處，如果有個單位需要自行維護網頁內容，但是該單位卻不放心將資料存放在別台電腦上，那麼我們只要將該資料夾設為虛擬目錄，就可以解決這個煩人的問題，而不需要為了該單位額外再架設一台 IIS 伺服器。

　

八、FrontPage 延伸套件

當 IIS 裝好 FrontPage 延伸套件後，我們就可以利用 FrontPage 從遠端直接來存取製作網頁。Front- Page 是使用 HTTP 1.1 版通訊協定，傳送 GET、PUT、DELETE.....等指令來存取網頁，目前 Apache 也已經支援這個通訊協定，並且也可以安裝 FrontPage 延伸套件來支援網頁製作，這對於年紀較小的網頁製作者來說，真是一項福音。

打開 FrontPage 後，從檔案選單選擇開啟 Web 選項，這時候只要直接輸入伺服器所在的 IP 或網址，就可以連接 IIS ，連線成功後會出現身分認證對話方塊（如果伺服器端有選用摘要式或整合驗證，而且使用者的帳號與密碼，正好與開機時登入的帳號密碼相同，那麼將不會出現對話方塊）。

在對話方塊裡鍵入帳號密碼，假如您是來自信任網域的使用者，則可以使用選擇網域的方式來輸入帳號，如果您是同網域的使用者，或是使用 Win 98 並且在該 IIS 已經註冊帳號密碼，那就可以直接輸入帳號密碼，開始進行編輯網頁的作業。

在 IIS 伺服器裡，有一些與 FrontPage 相關的設定，可以用來輔助網頁製作。這些功能包括：版本控制、執行效能、傳送電郵以及安全性設定。

版本控制用於群組合作的情況下，當有人正在編輯網頁時，該網頁會變成唯讀狀態，必須等待作者將網頁存回後，才可以給第二個人修改。當網頁作者只有一個人時，就不需要去啟用該選項，否則在操作上會比較繁雜。

執行效能用來改變 FrontPage 上傳網頁的緩衝區大小，當網頁數量少時調降緩衝區的記憶體配置，能夠有效提昇效率。反過來說，當網頁數量多時，如果緩衝區太小就會造成頻繁的 IO 存取動作，而造成效率不彰。因此緩衝區的大小設定應略高於網頁的數量，如果覺得 IIS 提供的選項不適用，想要自己進行微調，則可以選擇「使用者自訂」然後按「設定」按鈕進行調整。

其實這裡的設定與 IIS 內容裡的效能設定差不多，只不過 IIS 的效能是以每天的存取量來當基準，而 FrontPage 效能則是以網頁總量當基準。

如果想要在 FrontPage 設計表單時，將表單內容以電子郵件方式傳送給自己，就必須先在 Front- Page 擴充程式裡設定電子郵件傳送方式。當然，想要使用此項功能必須先在 IIS 伺服器上安裝 SMTP 元件，才有辦法與郵件伺服器取得聯繫。在此設定畫面中的 Web 伺服器的郵件地址，會顯示在寄出的信件上，成為該信件的寄件人。而收件人則可以使用 FrontPage 編輯器在製作網頁表單的同時加以指定。

上面兩張圖片顯示以 FrontPage 製作電子郵件表單的情形

在預設情況，安裝成 FrontPage Web 的主目錄權限，會繼承 IIS 的主目錄權限設定。然而，如果系統管理師希望對 FrontPage Web 做更嚴格的規範，就可以選擇「不繼承安全性設定」。一但選用此選項，則系統管理師可以針對該 Web 目錄及所有子目錄，設定更詳細的權限控制，包括：記錄製作動作、手動管理權限、使用 SSL 製作以及允許製作者上傳程式。

記錄製作動作將會在網頁製作者，以 FrontPage 連上伺服器後，自動記錄製作者執行動作的時間、製作者的使用者名稱、Web 名稱、遠端主機和每個運算的資料，這些紀錄將會存放在_vti_log 目錄下的 author.log 檔案中。

設定手動管理權限，則可以將此網頁目錄的權限設定鎖住，而無法再透過 IIS 來更改，也就是說該目錄無法自動繼承上層目錄的設定，一切要自己手動改變。

勾選「使用 SSL 製作」可以讓 IIS 在收到 FrontPage 連線要求時，要求以 SSL 來認證 Web 作者身份，這樣網頁製作者所傳送的帳號密碼都會經過編密，而不怕被半路劫獲。想要使用此項功能，與設定「安全通訊」一樣，必須先把驗證伺服器安裝好，並透過驗證伺服器發放身分憑證給網頁製作者，這個選項常用於「安全通訊」未開啟的情況，雖然身分資訊是以 SSL 傳送，但是編輯網頁的動作仍然透過 HTTP ，所以安全性比不上使用「安全通訊」的站台。話說回來，一般公共資訊站台很少使用 SSL。

「允許製作者上傳程式」選項在 IIS 5.0 中已經併入 IIS 「主目錄權限」中，請參考第四節的說明。開啟此項功能，會有許多安全疑慮，例如：中毒、站台遭到破解或資訊被盜取......等各種可能性。

　

九、Index Service 的安全性

Index Service 主要是提供網站的索引服務，事實上遠在 win98 的時代，就將檔案尋找功能發展得很類似網站索引服務了，我們可以在 win98 內按「開始」->「尋找」，然後選取「進階」選項，輸入特定字串來進行檔案內容的搜尋，這種內文搜尋也就是 Index Service 的基礎機制。但在 win2000 裡面，則將檔案搜尋與網站索引功能合而為一，並且改變了許多 NT 時代的做法，所以接下來談的安全性問題，主要是針對 NT（IIS 4.0）平台上的網站索引服務。

Index Service 最初是隨著 Option Pack 和 IIS 一同發行，多半在安裝 IIS 時已經一併裝好了，不過系統預設不會啟動它，請你在設定好 Index Service 後，自己透過「控制台」->「服務」來啟動。

Index Service 會自動搜尋網站所在目錄裡的所有檔案，萃取關鍵字建立屬性快取，如果沒有特別的限制，搜尋時將會包含所有的子目錄及檔案。當然，有一些檔案是屬於二進位檔，這類檔案將會使用檔案屬性來索引，其餘文字檔案則會搜尋內文中的關鍵字詞作為索引。微軟公司把這種不同索引方式，稱為篩選器，系統預設有純文字檔、Word、Excel、PowerPoint、HTML和二進位檔等五種篩選器，但也允許使用者自行開發篩選器。篩選器的進一步說明請參考Microsoft Index Server- Filter DLLs一文。

由於預設篩選器只有兩種，因此對於特殊的檔案，例如：PDF 文件，並無法進行索引，這不能不說是一種遺憾，不過也因為這樣造成許多商業站台去購買別家專業的索引系統，引發索引系統軟體的蓬勃發展。

這種篩選器的不足，連帶造成 ASP 程式的大漏洞，ASP 程式被視為純文字檔，程式內容被擷取製成索引，導致使用者只要在鍵入 ASP 當關鍵字來索引，就可以看到原始程式碼，而造成很大的系統安全危害。在這個漏洞還沒被補起來前，較注重安全性的人寧可不要使用 Index Service 或乾脆採購別家更專業的索引軟體。

有兩個方法可以稍稍防止這個大漏洞，一是將儲存 ASP 的目錄，排除在索引範圍之外，另一個方法是修改系統登錄，將 ASP 視為二進位檔，以防止程式內容被萃取。

第一個方法較簡單，打開 Index Service 管理員，新增 ASP 所在的目錄，在新增目錄視窗裡，將「要包含索引？」設定為「否」。記得把引入檔的所在目錄（ include）也排除在外。 

有時候為了便於程式開發，我們會將不同用途的 ASP 擺放在不同目錄，這時候要一一把眾多的目錄排除掉，實在是一件吃力的工作。如果是這樣，那就試試第二種方法。

打開 Regedit ，找到  HKEY_LOCAL_MACHINE\Software\CLASSES\CLSID\{eec97550-47a9-11cf-b952-00aa0051fe20}\PersistentAddinsRegistered\{C3278E90-BEA7-11CD-B579-08002B30BFEB} 機碼，將它的值改為{C3278E90-BEA7-11CD-B579-08002B30BFEB}。這樣就可以將 ASP 視為二進位檔，而不再剖析其內文，詳細設定原理請參考Microsoft Index Server- Modifying Filter Registration一文。

　

十、使用 SMTP 伺服元件

一個完整的郵件伺服器必須包含內收與外送兩種伺服功能，而 SMTP 元件只具有外送郵件功能，無法讓使用者從工作站收信，它的功能相當於 UNIX 裡面的 Sendmail 程式。此元件可以當成獨立伺服器使用，也可以將信件傳送給另一台全功能的郵件伺服器處理，類似於 Sendmail 的 mail routing 功能。底下以圖解說明 IIS + SMTP 與一般郵件伺服器的差異：

看過上圖之後，你應該也發現 SMTP 伺服元件與 IIS 的結合，可以用來設計 Web-base 郵件主機。沒錯，但是設計 Web-base 郵件主機牽涉到 ASP 程式設計技巧，所以在本文中，我們就不加以討論，有興趣的人，可以查看 SMTP 管理員裡面的輔助說明，裡面有相關的程式範例。

底下說明 SMTP 元件運作方式，當 SMTP 元件安裝完成之後，它就會開始監聽 TCP 25 port，以便提供寄信服務（當然包括接受其它郵件伺服器送信進來）。如果有郵件要寄出，信件會暫存於硬碟裡面的 mailroot/queue 目錄，準備排程寄出。如果收到其它伺服器寄來的信，則信件將儲存於 mailroot/Mailbox 目錄裡面，等待 ASP 程式的讀取。

有時候我們不想撰寫 ASP 程式來讀信，或是說我們架設 SMTP 元件目的只是讓網頁能結合郵件做自動回應，並不想去發展 Web-base 郵件主機，那麼也可以設定讓 SMTP 元件不要接受外來信件。

通常在此種情形下，我們會設定一台 Smart Host，這台 Smart Host 必須是具備 POP 功能的郵件伺服器，同時我們在上面設定一個網管用的郵件帳號（給網頁程式用而不分配給一般 User），當 SMTP 元件要寄信時，就交由 Smart Host 處理，如果收件人回信給此網管信箱，則會由 Smart Host 接收並進行分信處理，稍後系管師並可以用 Outlook 連到 Smart Host 來取信。這個方式不但可以減輕 Web 的負擔，也可以讓管理者不需設計 Mail Client ASP 程式，而直接以 POP 來取得回信。

設定 Smart Host 必須先在 SMTP 上建立遠端網域，並將「路由網域」設為 Smart Host 的網址。接著必須設定「傳出安全性」，如果該 Smart Host 支援 TLS 加密也可以一併勾選，如果該 Smart Host 不是 Microsoft Exchange Server，也不支援 TLS 加密，那就只能使用純文字密碼（也就是基本驗證啦！），如果 Web 與 Smart Host 位於同一網段，那麼這樣的設定還算安全。

設定好 SMTP 元件之後，我們就可以使用在第八節所介紹的方法，直接以 Front Page 來設計郵件表單（一行程式也不用寫），或是自己撰寫如下的 ASP 程式碼，來進行寄信的動作。

Set mail1 = Server.CreateObject("CDONTS.NewMail") mail1.To = "會員或參觀者輸入的郵件地址" mail1.From = "網管信箱" mail1.Subject = "郵件標頭" mail1.Body = "信件內容" mail1.Send

　

十一、NNTP伺服元件與 Office 延伸套件

NNTP 伺服元件主要用來提供新聞論壇服務，這個套件設計的非常陽春，所以僅能當成最底層的 News 伺服器來使用，而無法成為新聞來源提供者，這主要是因為它欠缺主動餵信的能力。由於 一台能主動餵信的 News 伺服器，同時需具備主動拉取其它 News 站台信件的能力，而這麼大量的信件處理以及條件判斷，不但耗費 IO 也耗費 CPU 和 RAM，因此並無法由 WEB 伺服器來兼任，相信這也不是 NNTP 伺服元件設計的目的。

由於 News 自由開放的特性，News 裡總是有太多的資訊不適合在校園流通，而如果想對新聞群組內容進行過濾，這也不是一般個人電腦有辦法負荷的，所以即使是在 BBS 的使用蔚為風氣的大專院校，有許多學校也只開放屬於學校自行建立的討論群組供學生訂閱。而在這種應用上，使用 NNTP 伺服元件其實是相當合適，一來因為它很陽春所以效能很高，二來我們不需要的功能剛好它也不具備，所以也不用擔心資訊流通會被轉為地下化。

IIS 裡的 Office 延伸套件，是另一個用來作為群組討論的伺服器。與 NNTP 伺服元件不同的是，前者僅只是靠 HTTP 通訊協定以及 MsSQL 來實作，而未牽涉到 NNTP 通訊協定，也因此，它是無法與其它伺服器交換討論內容的。在 IE 5.0 版以後，已經將 Office 延伸套件的討論功能，直接內建在瀏覽器上，讓它不需要額外程式的輔助，直接可以在網頁上運作，這一點也與 NNTP 伺服元件有很大的不同。

當然 Office 延伸套件既然名字裡有 Office 這個字，當然就與 Microsoft Office 有關。當我們使用 Office 時，隨時可以按「工具」選單上的「共同作業」來進行小組討論，所討論的內容會回存至 IIS 伺服器，而非儲存於 Office 文件內，這不但可以讓文件的修訂或相關討論，達到即時互動的境界，也可以不用儲存一堆過時或過期的討論訊息於文件上。這對於 Office 來說當然是一項重大改革，不過因為這個做法太新穎，並沒有被廣大的使用族群接受。

要在瀏覽器上使用討論功能，只需要在瀏覽網頁時按工具列上面的「討論」按鈕就行了。Office 延伸套件提供兩種模式來進行討論，第一種模式可以將討論內容內嵌在網頁裡，看起來就像是 ASP 程式所產生的效果，但事實上只要有 Office 延伸套件任何一個網頁都做得到。第二個模式是將討論內容獨立顯示於瀏覽器下方窗格，這樣就可以保持網頁的原始風貌，而不會受到討論內容的影響。

透過 Office 延伸套件進行討論，還可以讓使用者訂閱，只要有新的討論發表出來，就立刻以電子郵件告知訂閱者，這相當於 Maillist 的功能。對於需要在網頁上進行互動討論，但是又不想撰寫複雜 ASP 程式的系管師來說，實在是太方便了！

　

十二、以 MsSQL 當後端資料庫

後 PC 時代最大的特徵在於電腦與資料是分離的，資料可以透過網路在遠端存取，而不再是電腦硬體的附屬品。WEB 資料庫應用程式的發展，正是後 PC 時代之所以成真的主因。在 WEB 資料庫應用程式的發展過程中，資料的安全性一直受到很大的關注，於是三層架構的構想就被提出來，所謂三層架構是指人機介面、應用程式和資料實體三者分開來設計，讓這三者可以獨立在不同的機器上運作，透過層層轉向的網路機制來讓資料隱形，達到資料安全的目的。

人機介面當然就是網頁，它是在參觀者的瀏覽器裡執行，以避免耗費 WEB 伺服器寶貴的運算資源。應用程式則是用來進行資料的運算，由於應用程式位於公開的 WEB 伺服器上，所以容易被駭客侵入破壞。如果資料實體也存放於 WEB 伺服器上，駭客當然不會放過它。

隔離是讓資料隱形，以便保護資料安全的重要方法之一。我們可以將資料庫安裝在區域網路內，透過防火牆來保護，或是讓資料庫伺服器使用無法跨越路由器的通訊協定，以避免讓外界接觸。為了達到這個目的，請不要將資料庫伺服器登錄於公開的 DNS 上面，以避免被查出 IP，同時不要在 NAT 路由器上設定資料庫伺服器的一對一對應，這也是為了避免外界得知該伺服器的真實 IP。另外我們可以設定資料庫不使用 TCP/IP 來傳送資料，以避免傳輸過程中被監聽。其他可選擇的通訊方式有：具名管道、IPX/SPX、AppleTalk、Banyan VINES等，後面兩種方式是為了與非 Windows 平台溝通，由於 IIS 是安裝在 Windows 平台，所以我們只能有額外兩種選擇。

底下以具名管道為例來說明：由於具名管道是以 NetBios 名稱來進行電腦辨識，雖然 NetBios 名稱也是以 TCP 通訊協定來包裝，但是如果沒有 WINS 伺服器的協助，僅祇能以 IP 廣播方式在同一個網段內使用。由外界連進來的電腦，與我們內部網路不在同一網段，所以即使駭客經由破解 WEB 伺服器的內容，得知了資料庫所在的電腦名稱（具名管道名稱），但仍然無法對該主機進行資料的擷取，而且也偵測不出該主機的 IP。雖然仍然有破解的方法，但使用具名管道其安全性已經相當值得信賴。

首先開啟「Server Network Utility」程式，將所有設定好的通訊介面通通移除，然後新增一個新的通訊介面，選用「Named Pipes」，直接按確定即設定完成。

安裝好資料庫伺服器後，我們接著來了解一下在 WEB 伺服器上，如何來連接資料庫。很多 ASP 的初學者，都直接引用書上範例，將開資料庫的動作設計在個別的程式裡，由於 ASP 程式若未做過編密，很容易被破解而看到原始程式碼，因此將開資料庫的動作寫在 ASP 程式裡面，可以說是一種自殺行為。

其實為了解決此一問題，Miscrosoft 在作業系統「控制台」中的「 ODBC 設定」項目裡，提供了較為安全的「資料來源名稱」（DSN）連接方法。我們可以設定一個連接到資料庫伺服器的「系統資料來源名稱」，然後在 ASP 裡面直接指定想存取的 DSN 即可，以這個方式存取資料庫，只要駭客找不到 DSN，就無法得知資料庫在哪裡。比起直接將程式碼寫在 ASP 程式裡，可以說安全許多。

另外一個可以同時採用的安全機制，是使用 global.asa。此程式是在 WEB 啟動時就會讀取執行，由於系統對此檔案採取比較嚴格的安全管制，如果沒有取得 Administrator 的權限，就看不到內容，比起人人都可觀看執行的 ASP 程式，當然安全許多。我們可以將連接資料庫的程式碼，放在 global.asa 裡面，不但安全性較高，執行效能也較快。

舉目前台北市小學所使用的校務行政為例，我們可以在 global.asa 加入下面的程式片斷，就可以直接取用校務行政主機的資料庫，而不需要在該主機安裝 IIS，也不需要在防火牆將該主機放行，以免影響資料安全。

Sub Application_OnStart      Set jsdb=Server.CreateObject("ADODB.Connection")     mydsn = "Driver={SQL Server};Server=xxps1;database=JSDB;uid=****;pwd=****"     jsdb.open mydsn END SUB

目前負責開發此套軟體的廠商，也寫了一些 WEB 的應用程式，但因為考慮不夠周延，運作方式影響安全與效能甚鉅，建議各校不要採用，以免害了自己。

由於負責規劃校務行政的台北市資訊教育輔導團，專業能力不足，又太過信任廠商，導致該方案窒礙難行，雖推動六年但成效有限。期間筆者雖多次建言，但都未被採納，所以只好以一人之力來自行開發，目前的成果可以在 http://www.spps.tp.edu.tw 看到，其實，校務行政主機不應該負責帳號管理工作，也不應該提供 WEB 服務，唯一工作是當一個專職的後端資料庫，如此規劃才能真正符合學校未來的發展需求。