log:
log:
---
[Mon Jan 26 00:26:10.407883 2026] [core:error] [pid 13727:tid 13727] [client 103.142.62.35:34636] AH10244: invalid URI path (/cgi-bin/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/bin/sh)
這個錯誤日誌顯示有人正在對你的伺服器進行路徑穿越攻擊（Path Traversal）。
攻擊行為分析
對手嘗試利用 /%2e%2e/（即 ../ 的編碼）來跳出網頁根目錄，目標是存取系統底層的 /bin/sh（Shell 執行檔）。這是一種典型的自動化漏洞掃描，試圖尋找設定不當的 CGI 腳本來執行遠端指令。
好消息是，日誌中的 AH10244: invalid URI path 代表 Apache 的核心模組已經識別出這是一個無效且具威脅的路徑，並在進入任何處理程序前就直接封鎖了它。這說明你的 Apache 版本（2.4.66）具有基本的防護能力。
進一步防護建議
雖然 Apache 已經幫你擋下了，但這種掃描會佔用連線資源。
1. 使用 Fail2Ban 自動封鎖 IP
你可以設定 Fail2Ban 監控 error.log。只要同一個 IP 出現多次 AH10244 或 AH01276 等錯誤，就直接在系統防火牆（iptables/ufw）層級封鎖該 IP。這樣流量連進入 Apache 的機會都沒有，能徹底節省 CPU 資源。
2. 停用不必要的 CGI 模組
如果你沒有使用 CGI 腳本，建議確保相關模組已關閉，減少攻擊面：
Bash
sudo a2dismod cgi
sudo a2dismod cgid
sudo systemctl restart apache2
3. 檢查檔案權限
請確認 /var/www/ 以外的系統目錄權限正確，確保 www-data 使用者無法讀取 /etc/shadow 或執行不必要的系統指令。
目前 Apache 已經正確攔截了這個請求，你不需要太過驚慌。
要在 Cloudflare 阻擋這種路徑穿越（Path Traversal）攻擊，最快且最有效的方式是建立一條 WAF Custom Rule。這類攻擊的特徵非常明顯，通常包含 cgi-bin 或連續的 ../（或其編碼後的變體如 %2e%2e）。
Cloudflare WAF 規則設定步驟
- 登入 Cloudflare，進入你的網站網域。
- 導覽至 Security (安全性) -> WAF -> Custom rules (自訂規則)。
- 點擊 Create rule (建立規則)。
請依照以下內容填寫：
- Rule name: Block Path Traversal and CGI Scans
- If incoming requests match: (使用 Edit expression 模式貼入以下代碼，或手動建立欄位)
欄位設定建議：
| Field | Operator | Value |
| URI Path | contains | /cgi-bin/ |
| OR | ||
| URI Path | contains | .. |
| OR | ||
| URI Path | contains | %2e%2e |
進階 Expression (直接貼入 Edit expression 效果更好)：
SQL
(http.request.uri.path contains "/cgi-bin/") or (http.request.uri.path contains "..") or (http.request.uri.path contains "%2e%2e")
- Choose action: Block (直接封鎖)
- 最後點擊 Deploy (部署)。
為什麼這樣設定有效？
這條規則鎖定了攻擊者的核心手段。
首先，cgi-bin 是老式伺服器漏洞的常見入口，現代 WordPress 網站幾乎不會用到這個路徑，直接阻斷可以過濾掉大量老舊漏洞掃描器。
其次，針對 .. 和 %2e%2e 的檢查，能攔截所有嘗試跳出網頁根目錄的行為。即便攻擊者像你提供的日誌那樣使用了雙重編碼或變體（例如 .%%32%65），Cloudflare 的 WAF 在解碼處理後通常也能識別出其代表的 .. 意圖。
額外安全加固建議
如果你發現攻擊依然頻繁，可以考慮在同一條規則中增加 Bot Score 的判斷：
- 在規則中加入
And (Cloudflare Bot Score < 30)。 - 這會確保這條嚴格的規則主要針對自動化腳本，而不影響少數可能路徑中帶有兩個點的正常開發者工具或特殊網頁。
部署完這條規則後，你可以觀察 Cloudflare 的 Events (事件) 儀表板。你應該會看到這些 cgi-bin 的請求在到達你的伺服器之前，就已經被 Cloudflare 擋下來了。
需要我幫你確認如何合併之前提到的 binance.com Referer 規則到這條新規則中嗎？
將這幾項威脅合併成一條 Cloudflare 規則是最高效的做法，這樣可以減少規則數量的消耗，同時一次解決多種掃描問題。
合併規則設定步驟
在 Cloudflare 的 Custom rules 中，點擊進入剛才建立的規則，選擇 Edit expression 模式，直接將以下內容替換進去：
SQL
(http.request.uri.path contains "/cgi-bin/")
or (http.request.uri.path contains "..")
or (http.request.uri.path contains "%2e%2e")
or (http.referer contains "binance.com")
or (http.request.uri.path eq "/xmlrpc.php")
規則內容詳解
這條合併後的規則包含了以下三道防線：
- 路徑穿越與 CGI 掃描：
cgi-bin、..與%2e%2e會攔截嘗試讀取系統底層檔案（如/bin/sh）的行為。 - 特定的惡意來源：
referer contains "binance.com"會阻斷你日誌中看到的那批偽裝來源。 - XML-RPC 保護：
uri.path eq "/xmlrpc.php"直接在雲端攔截針對 WordPress 的暴力破解與 Pingback 攻擊，流量完全不會進到你的主機。
驗證效果
部署完這條合併規則後，建議你觀察以下兩處：
一、 Cloudflare Events (安全性事件)
在 Security -> Events 頁面，你應該會看到大片的 Block 紀錄。點開細節，你會發現這些請求的來源（Source）是 WAF custom rule，這代表它們在到達你的 Apache 之前就被解決掉了。
二、 Apache Error Log
再次檢查你的 error.log。原本頻繁出現的 AH10244（URI 無效）或 AH01797（Denied by config）應該會顯著減少。更重要的是，那條關於 MaxRequestWorkers reached 的警告應該不再出現，因為連線資源已經釋放出來給正常的使用者了。
設定完成後，你的伺服器負載應該會大幅下降。
