處理 HTTP w00tw00t 攻擊

我有一個帶有 apache 的伺服器，我最近安裝了 mod_security2，因為我受到了很多攻擊：

我的 apache 版本是 apache v2.2.3，我使用 mod_security2.c

這是錯誤日誌中的條目：

[Wed Mar 24 02:35:41 2010] [error] 
[client 88.191.109.38] client sent HTTP/1.1 request without hostname 
(see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)

[Wed Mar 24 02:47:31 2010] [error] 
[client 202.75.211.90] client sent HTTP/1.1 request without hostname 
(see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)

[Wed Mar 24 02:47:49 2010] [error]
[client 95.228.153.177] client sent HTTP/1.1 request without hostname
(see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)

[Wed Mar 24 02:48:03 2010] [error] 
[client 88.191.109.38] client sent HTTP/1.1 request without hostname
(see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)

以下是 access_log 中的錯誤：

202.75.211.90 - - 
[29/Mar/2010:10:43:15 +0200] 
"GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1" 400 392 "-" "-"
211.155.228.169 - - 
[29/Mar/2010:11:40:41 +0200] 
"GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1" 400 392 "-" "-"
211.155.228.169 - - 
[29/Mar/2010:12:37:19 +0200] 
"GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1" 400 392 "-" "-" 

我嘗試像這樣配置 mod_security2：

SecFilterSelective REQUEST_URI "w00tw00t\.at\.ISC\.SANS\.DFind"
SecFilterSelective REQUEST_URI "\w00tw00t\.at\.ISC\.SANS"
SecFilterSelective REQUEST_URI "w00tw00t\.at\.ISC\.SANS"
SecFilterSelective REQUEST_URI "w00tw00t\.at\.ISC\.SANS\.DFind:"
SecFilterSelective REQUEST_URI "w00tw00t\.at\.ISC\.SANS\.DFind:\)"

mod_security2 中的東西是 SecFilterSelective 不能使用，它給了我錯誤。相反，我使用這樣的規則：

SecRule REQUEST_URI "w00tw00t\.at\.ISC\.SANS\.DFind"
SecRule REQUEST_URI "\w00tw00t\.at\.ISC\.SANS"
SecRule REQUEST_URI "w00tw00t\.at\.ISC\.SANS"
SecRule REQUEST_URI "w00tw00t\.at\.ISC\.SANS\.DFind:"
SecRule REQUEST_URI "w00tw00t\.at\.ISC\.SANS\.DFind:\)"

即使這樣也行不通。我不知道該怎麼辦了。有人有什麼建議嗎？

更新 1

我看到沒有人可以使用 mod_security 解決這個問題。到目前為止，使用 ip-tables 似乎是最好的選擇，但我認為文件會變得非常大，因為 ip 每天會更改幾次。

我想出了另外兩個解決方案，有人可以評論他們的好壞。

1. 我想到的第一個解決方案是從我的 apache 錯誤日誌中排除這些攻擊。這將使我更容易在其他緊急錯誤發生時發現它們，並且不必在長日誌中吐槽。
2. 我認為第二種選擇更好，那就是阻止未以正確方式發送的主機。在這個例子中，w00tw00t 攻擊是在沒有主機名的情況下發送的，所以我認為我可以阻止不正確形式的主機。

更新 2

在仔細閱讀答案後，我得出了以下結論。

1. 為 apache 進行自定義日誌記錄會消耗一些不必要的資源，如果確實存在問題，您可能希望查看完整日誌而不會失去任何內容。
2. 最好忽略命中並專注於分析錯誤日誌的更好方法。為您的日誌使用過濾器是一個很好的方法。

關於這個主題的最後想法

如果你至少有一個最新的系統，上面提到的攻擊不會到達你的機器，所以基本上不用擔心。

一段時間後，很難從真實攻擊中過濾掉所有虛假攻擊，因為錯誤日誌和訪問日誌都變得非常大。

以任何方式防止這種情況發生都會消耗您的資源，最好不要將資源浪費在不重要的事情上。

我現在使用的解決方案是Linux logwatch。它會向我發送日誌摘要，並對其進行過濾和分組。通過這種方式，您可以輕鬆地將重要的與不重要的分開。

謝謝大家的幫助，我希望這篇文章也能對其他人有所幫助。

從您的錯誤日誌中，他們發送的 HTTP/1.1 請求沒有 Host: 請求的一部分。根據我的閱讀，Apache 在移交給 mod_security 之前對此請求回復了 400（錯誤請求）錯誤。因此，您的規則似乎不會被處理。（Apache 在要求移交給 mod_security 之前處理它）

自己試試：

遠端登錄主機名 80
GET /blahblahblah.html HTTP/1.1（輸入）
（進入）

您應該收到 400 錯誤並在日誌中看到相同的錯誤。這是一個錯誤的請求，apache 給出了正確的答案。

正確的請求應如下所示：

獲取 /blahblahblah.html HTTP/1.1
主辦方：blah.com

解決此問題的方法可能是修補 mod_uniqueid，即使對於失敗的請求也生成唯一 ID，以便 apache 將請求傳遞給其請求處理程序。以下 URL 是有關此解決方法的討論，其中包含您可以使用的 mod_uniqueid 更新檔： http ://marc.info/?l=mod-security-users&m=123300133603876&w=2

找不到任何其他解決方案，想知道是否真的需要解決方案。

引用自：https://serverfault.com/questions/125607