HTTPERR的日志中出現(xiàn)大量Timer_MinBytesPerSecond，Timer_ConnectionIdle錯誤

2024-09-01 13:44:50

字體：大中小

供稿：網(wǎng)友

在/LogFiles/HTTPERR的日志中發(fā)現(xiàn)了大量Timer_MinBytesPerSecond，Timer_ConnectionIdle錯誤，
根據(jù)網(wǎng)上的介紹，做了如下更改：

1) 從 IIS 管理器右鍵單擊本地計算機選擇屬性。勾選允許直接編輯配置數(shù)據(jù)庫。
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”節(jié)點中，將 EnableEditWhileRunning 的值從 0 (FALSE) 更改為 1 (TRUE)。所做更改應如下所示：

<IIsComputer Location ="/LM"

EnableEditWhileRunning="1"

EnableHistory="1"

MaxBandwidth="4294967295"

MaxHistoryFiles="10">

•將所做更改保存到 MetaBase.xml 文件中。
然后才能修改MBSchema文件。。。

-------------------------------另一種見解

前些天發(fā)現(xiàn)自己的網(wǎng)站無法訪問，詢問機房這邊，說是機器最近常死機，我就把網(wǎng)站遷移到一個朋友的主機上，結(jié)果沒過幾天機器又掛了，問朋友的機房那邊說是硬件防火墻被攻擊了而死掉了，詳細情況不知。看來不是硬件問題，多半是被SYN FLOOD或者CC攻擊了。恰好原來的機房說最近購買了新的防火墻，我又放了回去。

既然不是硬件問題而可能是攻擊，我就開始檢查IIS log了，發(fā)現(xiàn) IIS 里面很多Timer_ConnectionIdle和Timer_MinBytesPerSecond的錯誤，到網(wǎng)絡上google了一下，常見說法是說錯誤是因為IIS的設置不當引起的，是因為連接超時時間設置太小，解決方法是設置連接超時為600秒，把MinFileBytesPerSec的設置從240修改到0（相當于關掉該設置)。覺得這些解決方法都有問題，假如車輛防盜警報經(jīng)常響，正確的解決方法是看看有誰常來打你車子的主意，或者把車子放在更安全的地方，而絕對不是關掉警報。

因為HTTP服務需要占用TCP連接，而TCP連接時是需要占用系統(tǒng)資源的，而且IIS為每個連接也需要分配相應的資源。目前的主機能夠處理上萬的連接就可以說是軟硬件設計都很不錯了(可以參見C10K )。假如惡意人員通過一臺或者多臺機器發(fā)起大量的連接，而不請求內(nèi)容(這樣不需要消耗多少攻擊機器的帶寬)，就可以大量消耗服務器資源而達到拒絕服務的目的。

所以 IIS 需要關閉長時間非活動的連接，這個就是Timer_ConnectionIdle 的錯誤由來。

既然盾牌改進了，當然矛也要發(fā)展一下，攻擊者可以給服務器故意緩慢的發(fā)送和接收內(nèi)容而消耗服務器的資源，這樣可以避免服務器對于Timer_ConnectionIdle 的保護，相應的IIS的防范就是 MinFileBytesPerSec 設置，MinFileBytesPerSec 屬性通過以最小的數(shù)據(jù)量保持連接，來禁止惡意的或軟件工作不正常的客戶端消耗資源。如果吞吐量低于 MinFileBytesPerSec 設置的值，則終止連接。LOG里面就會顯示Timer_MinBytesPerSecond錯誤（一些Timer_MinBytesPerSecond錯誤是因為 windows 2003 的http.sys錯誤引起的，解決方式是打上最新 ServicePack ： http://support.microsoft.com/kb/919797/en-us ）

所以說這些設置都是用來保護IIS服務器的，可以一定程度上抵御一些惡意的行為消耗服務器的資源，所以我反而將IIS連接超時從原來的600秒改到了30秒

不過經(jīng)過我們解決問題發(fā)現(xiàn)時因為網(wǎng)站所在的應用程序池中請求隊列限制，限制在1000，根據(jù)自己的網(wǎng)站流量，果斷設置為 5000-10000就解決了，默認的1000確實有點少了

HTTPERR的日志中出現(xiàn)大量Timer_MinBytesPerSecond，Timer_ConnectionIdle錯誤