我管理的一台伺服器似乎正在參與針對 WordPress 安裝的暴力攻擊。
我已經多次遇到這種情況，所以我非常熟悉可以採取哪些步驟來防止這種情況發生。然而，我正在努力解決的是偵測傳出的攻擊。該伺服器是一台典型的 Apache 伺服器，上面有許多虛擬主機 - 這當然是複雜的地方 - 如果那裡只有一個，那就不會那麼困難了！
我目前正在使用 tcpflow 來記錄從該伺服器上的任何連接埠到任何其他電腦上的連接埠 80 的流量，使用以下命令：
tcpflow -i eth0 dst port 80 and src host <my_servers_ip> and port not 22
我發現這比 tcpdump 更好。一段時間後查看它的輸出可能會有點令人費解:) tcpflow 將每個請求放入一個單獨的檔案中。
以下是我認為可疑活動的文件的一些輸出：
POST /wp-login.php HTTP/1.1
User-Agent: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
Host: somedomain.com
Accept: */*
Cookie: wordpress_test_cookie=WP+Cookie+check
Content-Length: 97
Content-Type: application/x-www-form-urlencoded
log=jacklyn&pwd=london&wp-submit=Log+In&redirect_to=http://somedomain.com/wp-admin/tes1a0&testcookie=1
請注意，我混淆了上面的“主機：”，我相信這是被攻擊的主機（這是正確的嗎？）。
所以我的問題是，我該如何偵測產生此惡意流量的虛擬主機？如果我能做到這一點，我可以讓我的客戶知道，他可以採取措施調查網站並進行必要的更改以阻止它。
非常感謝收到任何解決方案:)
答案1
根據您的說法，我假設您處於無法使用allow_url_fopen 限制用戶端下載url 的設定。
在這種情況下，實際上很難回到原始 php 腳本，因為您顯示的 tcpflow 日誌實際上並未嵌入該資訊。
一個可以考慮的簡單選擇是強制任何傳出請求都有一個可顯示的用戶代理，您可以使用它來識別發出該請求的實際客戶端。
例如，您可以為 client1 網站的 vhost 定義新增指令
php_admin_value user_agent client1
這將強制該網站發出的任何 http 請求使用用戶代理“client1”，該請求將顯示在您的 tcpflow 日誌中，從而讓您知道是誰發起的。
請注意，如果您擔心隱私，您可能需要使用只有您可以對應到實際客戶端的 user_agent（例如客戶端名稱的加密）。
然而，它可能會損害可用性，因為某些網站將根據提供的 user_agent 顯示不同，而此設定有意阻止您的用戶端進行更改它的任何嘗試。