今天會接續上篇，但和上篇沒有直接關係，總之也是分享其它的 IIS Best Practice，今天切入的角度包含 Security、 Performance 以及其他剩下的零總。

Security Microsoft 自己就有完整寫一篇了，不過我這部分就是會就我的理解描述(也會以我有使用經驗的為主)，也會整合多個資料來源比較的設置，簡單的說，你可以都看看，選擇你覺得合理合適的去做套用。對我的理解或官方文檔的設置有疑問也歡迎討論，也許會有更多不同的面相與觀點。官方的文檔我指的是這篇 : Security Best Practices for IIS 8，儘管標題寫 IIS 8，大多對於 7+ 版本功能都只多不少，所以基本都能套用的。事不宜遲，我們開始正文吧。

Security

• 按自己需求設置 Request Filtering 的功能
  詳細內容請見 Day18 的內容，會有這個建議是因為其實預設的允許範圍蠻寬鬆的，很多設定都是不 Deny 就是 Allow。實際上你對自己網站會使用的情境應該有足夠的了解，可以只允許特定的 Http Verb、能被瀏覽的副檔名，設置合適的 Query string 長度限制等等，如果網站只有你允許的行為，那要防禦攻擊的面積就會小的多，或者說更在預期內。
• 省視 Header 中挾帶的參數是否需要
  如之前在也是 Request Filtering 的那篇提到，removeServerHeader 就是一個可以移除的 Header，不必要的資訊暴露的越少，越能減少他人想攻擊的線索。還有如 HTTP Response Headers Module 中也可以查找看看，那邊也有關係到 Response Header 的設定。

• 避免在 Configuration file 中明文顯示敏感資訊
  設定檔是能夠加密的，明文顯示畢竟有風險在，可以的話盡量讓如密碼相關敏感資訊是加密過的，這個我好像前面也沒特別提到，這裡留下參考的文章 Encrypting and Decrypting Configuration Sections
• 只安裝需要的模組、Handler，只開啟需要的功能
  這句很像廢話，但人總有懶惰的時候，一如本系列文一開始會告訴大家測試方便把全功能打開，在 Production Server 上可不要貪圖這種方便，老話，越少不必要的東西，越減小被攻擊面積
• 注意匿名權限的控管
  在網站認證中，預設會用匿名驗證來做最優先的存取，如匿名和 Windows Authentication 同時開著，但匿名可以通過的場合，則永遠會用匿名去執行行為。避免讓匿名的服務帳號能擁有寫入權限、減少能存取的資源範圍，畢竟驗證使用者身分就是安全性重要的一環
• 開啟備份功能，定期備份 IIS Server 的 Config 相關檔案
  不怕一萬，只怕萬一，確保設定定時備份，無論是復原或追朔舊版本狀態都會派上用場

Performance

• ASP.NET Application 是以 Release mode 被 built 的，且 production 上的 web.config 的 debug 標籤應為 false
  為效能著想，debug mode 儘管利於除錯，但在 production 上應該要被關掉，想知道 debug mode 的具體差異，請見這篇文章 : Debug mode in ASP.NET applications - ASP.NET
• FREB 之類的 Tracing module，先裝好/設置好，但不要開啟紀錄
  IIS Log 當然是常時保持開啟，畢竟是基本的 Log
• 盡可能的設低 Request Time-out
  這條可能有些過於理想，你會需要對你的服務穩定有足夠信心，才能夠有一個比較明確的數值去下壓，或是有足夠的錯誤/重試機制保護使用者體驗。這樣做的主要好處是讓意外發生時，造成的影響盡量減小，也盡快被處理，不會因為單一的 Request 塞住後面進來的流量、Request queue 也更不容易被塞滿，可以讀讀這篇作為參考 Chapter 6 - Improving ASP.NET Performance 。連結已經連結到 Request Time-out 的段落了，整篇其實也講了很多對 ASP.NET 的效能優化設置，如果你的 App 是該語言，可以順便參考一下
• Default Document 裡把沒用到的項目移除
  Day19 有提過，放效能這應該也還算合適，雖然可能影響不大，但確實它會逐一從上而下嘗試讀取，根本不存在的項目也不用留著，真的需要再新增就好
• 處理高併發場景的時候，考量邏輯 CPU 數量，調整合適的 Thread 相關設定來加快處理
  細節官方文章有篇寫到，Performance issues when you call web services - ASP.NET，跟 ASP.NET 本身起 worker thread 的方式有關
• 可以考慮限制 Application Pool 中 Advance Setting 對 CPU 的使用率
  避免衝到 100%，對 Server 來說比較健康，不容易觸發一些 Server Level 的異常，比如可以設置為最高只能使用到 85%
• 允許 HTTP Compression
  可以透過 IIS 上的模組設定，或是像 ASP.NET 裡也可以手動寫扣指定壓縮方式或更多細節，注意接收端要能夠解壓，主要好處是讓傳送的 response 會更小、發送上更快。

Others

• 注意重要網站相關的資料夾應該要被加到防毒白名單
  防毒重要，可別讓它拿自己人開刀，網站、使用資源、暫存資料夾等等應被加入白名單，避免防毒因為運行邏輯移除或封鎖了重要的檔案
• 確保你有監測效能的手段
  最可怕的事情莫過於由使用者端告訴你錯誤，一個穩定或合格的服務，應該都要能在使用者主動回報前，就應該掌握問題徵兆，設有對應的 gate value 去警戒可能發生的問題、有相關的應變處置等等

大致上就是上面這些，關於 Log 要不要記這點其實大家眾說紛紜，但我個人的經驗是，IIS Log 這種通用的 Log，記的好處(能夠廣泛的概觀去察看問題或狀態)跟相對小的效能差異，我是會選擇記的；像是 FREB 比較複雜詳細的 Log，我就會選擇必要時才開啟。讀者也可以在 Server 上做開啟與關閉的測試確認差異，再決定是否要開啟各個 Log 機制。

最後，寫在 Best Practice 兩篇文章的文末：IIS 畢竟還是只是 Web Hosting 的載體，主體還是 Web，也就是網站，更多更多的效能問題或是運行，還要靠網站端去注意與處理，並不是 IIS 設定完了就萬事大吉了。IIS 能夠為網站的基本行為做到一定保障、合適的 Process 設置，更後面的實際運行，就要靠網站本身了。