網路公開服務基本上沒有從根本上防禦攻擊者的方法

你好，我是無能。

最近攻擊大幅增加，我姑且憑著感覺隨手寫寫。

不存在從 HTTP 用戶端發起攻擊的根本防禦方法

首先，來看看各種防禦方式。

IP 位址

如果是 IPv6 位址就還好，但在 CGNAT 環境下會分配到共用的 IPv4 位址，攻擊目標以外的受害者也會被牽連。
此外，IP 輪替本身很容易，近來也越來越常見從全球持有大量 IP、常被用於攻擊的美國低價 VPS，或中國系雲端環境準備數千個 IP 位址來發動 DDoS。即使以 AS Number 為單位封鎖，若有服務在中國營運，封鎖中國系雲端的 IP 位址終究不是根本解決之道，而且也有點對不起中國使用者。
基本上，中國的雲端環境本身經常遭其他國家濫用，因此我不認為可以一概將它們列為封鎖對象。

我本來的想法是，只要服務屬於全球資訊網，即使只有一個人會使用這項服務，我就不想一概封鎖。
我自己也偶爾會看 BiliBili 的影片，也會瀏覽美國的服務。

User-Agent

基本上這根本不值得一提，或者說，我認為幾乎沒有意義將請求標頭評估本身作為存取限制，因此沒什麼好寫的。
由於可以任意偽造，不能只根據簡單評估的 UA 作為封鎖標準。
若要實施，或許可以像我目前在這個網站上做的那樣，若自稱是 googlebot 的 UA，而反向查詢主機名稱不是 *.googlebot.com 或 *.google.com，就完全封鎖。不過，這需要自行實作，或確認 CDN 端是否已經有類似功能。此外，雖然 Google 官方是這麼說，但實際上也有不少正規 bot 是由反向查詢主機名稱不在上述範圍內的主機送出的，因此也不能只靠這項評估就完全判定。

順帶一提，就連這種破爛網站，也有這麼多傢伙自稱是 Googlebot
fail2ban report - fake-googlebot

封鎖國家

發生攻擊時，或許可以作為暫時措施，但作為永久對策並沒有意義，原因和以 IP 位址為單位相同，這裡就不贅述了。
不過，如果服務只在國內營運，應該還是有其效用。

TLS Fingerprint

TLS 指紋本身也很容易偽造。
原因是，只要在 HTTP 用戶端中加入與瀏覽器所建置的相同加密函式庫等，就能偽造瀏覽器指紋。
若說完全沒有用，倒也不盡然；但例如使用相同加密函式庫等的正常 bot 發出請求時，就會造成誤封鎖。
由於與大量 HTTP 用戶端重複的風險很高，因此不能只用這項標準來判定。
因此，它可以作為判斷標準之一；與其單獨作為唯一條件，不如和其他規則複合考量，這樣多少還是有用的。

Cloudlfare Challenge / PoW Challenge

Cloudflare Challenge 本身不用無頭瀏覽器也能輕易繞過。
Anubis 我不確定如何，但從使用者體驗來看不太理想，而且需要用戶端進行運算，頁面切換時會造成相當大的負擔。
某種程度上，它可以與 JS Challenge 結合，形成複合式防護。實際上，近來越來越多外洩論壇也開始採用自訂的 PoW Challenge，因此，在哪裡使用 PoW Challenge，或者說，若要用於 DoS 防護，是否該在這種接近應用層的部分透過 PoW Challenge 進行保護，這點還有些微妙。如果將使用情境大幅限縮後再實作，或許能盡可能不損及使用者體驗，同時在前端建立相對有防護性的措施。

付費牆

想採用付費牆的服務有限，這裡就略過。

HTTP 快取

我有點猶豫這項目是否該放進本文，但還是加進來了。
若從 CDN 快取到達 Origin 的連通性來看，對 GET 等請求應該有幫助，但我的感覺是現在應該大家都已經導入了吧？
與其把它視為防護，不如將它用於改善使用者體驗；另外，作為回應錯誤時的洪水攻擊對策也很有用，因此我認為最好把它視為不影響應用程式的效能提升措施。

速率限制

不同服務的 key 本身差異很大，因此似乎應該先確認清楚實作規則。以 Nginx 為例，可以依整體流量、各 URI、IP 位址等設定，也能複合運用，因此從 DoS 防護的角度來說應該很有用。

那該怎麼做？

我認為只能分成幾個層級，並以複合條件來應對。
目前想到的是，將三家可信度高的雲端供應商以 AS Number 為單位列入信任名單，再將各家社群平台等的爬蟲列入允許清單，對其他來源則採取較嚴格的措施。
常見攻擊者模式中，明顯異常的請求模式包括：

掃描 .env 等檔案的 IP 位址
自稱是 googlebot、明顯有問題的傢伙
透過 POST/PUT 等方法送來不可能成立的請求
對 /login 之類的路徑，或能建立工作階段的路徑，送出亂七八糟的請求

之類的情況，直接封鎖一次也無妨吧？坦白說，低價 VPS 被濫用的情況相當多，所以我也很想一律封鎖，但我自己也常在低價 VPS 上架設 VPN 伺服器，然後從它的出口 IP 瀏覽網站，因此又覺得這樣可能做得太過頭；不過依服務而定，或許也可以這麼做。

此外，近來以音訊裝置偵測進行指紋識別受到批評，但我認為實際上確實有用，因此在偵測不到時封鎖，應該也不錯。雖然遲早會有人找到偽裝的方法就是了……
或許未來會採用 GPU Fingerprint、Audio Fingerprint 等方式，複合偵測使用者裝置。