在\LogFiles\HTTPERR的日誌中發現了大量Timer_MinBytesPerSecond,Timer_ConnectionIdle錯誤,
根據網上的介紹,做了如下更改:
1) 從 IIS 管理器按右鍵 本機電腦 選擇 屬性。勾選允許直接編輯設定資料庫。
2) 在記事本中開啟 C:\Windows\system32\inetsrv\MetaBase.xml 檔案,
搜尋MinFileBytesPerSec,將 MinFileBytesPerSec 設定從 240 更改為 0。
搜尋ConnectionTimeout,將 ConnectionTimeout 設定從 120 更改為 600。
MinFileBytesPerSec如果不在C:\Windows\system32\inetsrv\MetaBase.xml 檔案 就是在C:\Windows\system32\inetsrv\MBSchema.xml 檔案
3)重新啟動 IIS 。
在修改MBSchema尤其注意,停止IIS進程,第一步修改
MetaBase
•在“IIsComputer”節點中,將 EnableEditWhileRunning 的值從 0 (FALSE) 更改為 1 (TRUE)。所做更改應如下所示:
<IIsComputer Location ="/LM"
EnableEditWhileRunning="1"
EnableHistory="1"
MaxBandwidth="4294967295"
MaxHistoryFiles="10">
•將所做更改儲存到 MetaBase.xml 檔案中。
然後才能修改MBSchema檔案。。。
-------------------------------另一種見解
前些天發現自己的網站無法訪問,詢問機房這邊,說是機器最近常死機,我就把網站遷移到一個朋友的主機上, 結果沒過幾天機器又掛了,問朋友的機房那邊說是硬體防火牆被攻擊了而死掉了,詳細情況不知。看來不是硬體問題,多半是被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 : http://support.microsoft.com/kb/919797 http://support.microsoft.com/kb/919797/en-us )
所以說這些設定都是用來保護IIS伺服器的,可以一定程度上抵禦一些惡意的行為消耗伺服器的資源,所以我反而將IIS連線逾時從原來的600秒改到了30秒
不過經過我們解決問題發現時因為網站所在的應用程式集區中請求隊列限制,限制在1000,根據自己的網站流量,果斷設定為 5000-10000就解決了,預設的1000確實有點少了