1027
Timer_MinBytesPerSecond與Timer_ConnectionIdle的IIS錯誤日誌分析（轉）
在看httperr日誌的時候，同時也發現了Timer_MinBytesPerSecond 錯誤或 Timer_ConnectionIdle 錯誤 ，並且，這些錯誤出的時候，也是很連貫的，非常多，因此，這也屬不正常現象；C:\Windows\system32\LogFiles\HTTPERR\httperr*.log 中看到 Timer_MinBytesPerSecond 錯誤或 Timer_ConnectionIdle 錯誤。 這些是由IIS 默認設置, 定義用於連接到保持活動小通信流速率和最大空閑時間之前連接中斷允許。
1) 從 IIS 管理器右鍵單擊 Internet Information Server (IIS) 管理器級別根目錄上並轉到屬性。 選中要啟用直接編輯元數據庫框。 單擊確定。
2) 在記事本中打開 C:\Windows\system32\inetsrv\MetaBase.xml 文件，搜索有關 ” MinFileBytesPerSec “。 將用於 MinFileBytesPerSec 設置從 240 更改為 0。 執行其他搜索, 該時間將 600 ” ConnectionTimeout “。 保存更改並退出。
3） 重新啟動 IISAdmin 服務以更改生效。
另外，在誰是黑客(1): 關於IIS LOG的MinFileBytesPerSec和Timer_ConnectionIdle錯誤也發現了一些不錯的言論，很獨到，在理論上，他分析得還是很有見地的，隻是很遺憾，沒有下文。
以下內容引用：
前些天發現自己的網站無法訪問，詢問機房這邊，說是機器最近常死機，我就把網站遷移到一個朋友的主機上， 結果沒過幾天機器又掛了，問朋友的機房那邊說是硬件防火牆被攻擊了而死掉了，詳細情況不知。看來不是硬件問題，多半是被SYN FLOOD或者CC攻擊了。恰好原來的機房說最近購買了新的防火牆，我又放了回去。
既然不是硬件問題而可能是攻擊，我就開始檢查IIS log了，發現 IIS 裏麵很多Timer_ConnectionIdle和Timer_MinBytesPerSecond的錯誤，到網絡上google了一下，常見說法是說錯誤是因為IIS的設置不當引起的，是因為連接超時時間設置太小，解決方法是設置連接超時為600秒，把MinFileBytesPerSec的設置從240修改到0（相當於關掉該設置)。覺得這些解決方法都有問題，假如車輛防盜警報經常響，正確的解決方法是看看有誰常來打你車子的主意，或者把車子放在更安全的地方，而絕對不是關掉警報。
因為HTTP服務需要占用TCP連接，而TCP連接時是需要占用係統資源的，而且IIS為每個連接也需要分配相應的資源。目前的主機能夠處理上萬的連接就可以說是軟硬件設計都很不錯了(可以參見C10K )。假如惡意人員通過一台或者多台機器發起大量的連接，而不請求內容(這樣不需要消耗多少攻擊機器的帶寬)，就可以大量消耗服務器資源而達到拒絕服務的目的。
所以 IIS 需要關閉長時間非活動的連接，這個就是Timer_ConnectionIdle 的錯誤由來。
既然盾牌改進了，當然矛也要發展一下，攻擊者可以給服務器故意緩慢的發送和接收內容而消耗服務器的資源，這樣可以避免服務器對於Timer_ConnectionIdle 的保護，相應的IIS的防範就是 MinFileBytesPerSec 設置，MinFileBytesPerSec 屬性通過以最小的數據量保持連接，來禁止惡意的或軟件工作不正常的客戶端消耗資源。如果吞吐量低於 MinFileBytesPerSec 設置的值，則終止連接。LOG裏麵就會顯示Timer_MinBytesPerSecond錯誤（一些Timer_MinBytesPerSecond錯誤是因為 windows 2003 的http.sys錯誤引起的，解決方式是打上最新 ServicePack ： https://support.microsoft.com/kb/919797 https://support.microsoft.com/kb/919797/en-us ）
所以說這些設置都是用來保護IIS服務器的，可以一定程度上抵禦一些惡意的行為消耗服務器的資源，所以我反而將IIS連接超時從原來的600秒改到了30秒
最後更新：2017-01-04 22:34:54