在本頁我們展示一些方法來減緩當前的 DoS 攻擊。 所有這些方法都可以結合使用。 然而這個問題目前還沒有一步到位的解決方案。 防禦受攻擊的網站需要有創意與量身打造的方法。

Denial-of-service prevention mechanisms in Tor 規範的 Overview 部分給出了 Tor 守護程序實施防禦的概述,在這裡我們給出了一些實用的技巧。

引入點的速率限制

既然 Proposal 305已經執行,加入某些torrc 選項以減輕介紹點的 DoS 攻擊:

  • HiddenServiceEnableIntroDoSDefense: 在引入點層面啟用DoS防禦。 如果啟用,速率與暴裂參數將會送到引入點,以利用它們對服務請求進行速率限制。

  • HiddenServiceEnableIntroDoSBurstPerSec:在引入點每秒允許的突發性客戶端引入數量。 如果選項為 0則被視為無限大,如果已設 HiddenServiceEnableIntroDoSDefense 將大大地關閉防禦。

  • HiddenServiceEnableIntroDoSRatePerSec:介紹點上每秒可允許的客戶介紹速率。 如果選項為 0則被視為無限大,如果已設 HiddenServiceEnableIntroDoSDefense 將大大地關閉防禦。

有關它們如何運作的更多信息,請查看 tor(1) 線上說明頁和 Onion Services v3 specificationDenial-of-Service defense extension (DOS_PARAMS) 部分。

建立集合點電路之前的工作量證明 (PoW)

Proof of Work (PoW) 防禦機制在 PoW FAQ 中有詳盡說明,並可透過下列 torrc 選項為各 Onion 服務設定:

  • HiddenServicePoWDefensesEnabled:啟用基於工作量證明的服務 DoS 緩解。 啟用後,tor 會在此隱藏服務描述元加密部分納入選用客戶端謎題的參數。 傳入的 rendezvous 請求會依據用戶端在計算謎題解答時選擇投入的工作量來決定優先順序。 該服務將根據攻擊負載定期更新建議的工作量,並在服務未過載時完全停用拼圖。

  • HiddenServicePoWQueueRate:每秒從優先權佇列調度的集合點請求的持續速率。

  • HiddenServicePoWQueueBurst:一次從優先權佇列處理的集合點請求的最大突發大小。

以下全域選項適用於洋蔥服務及其客戶:

  • CompiledProofOfWorkHash:當工作量證明 DoS 緩解處於活動狀態時,服務本身和連線的用戶端都會使用動態產生的雜湊函數作為謎題計算的一部分。

PoW 在 C Tor 版本 0.4.8.1-alpha 及以上版本上預設為啟用(但如果使用 --disable-module-pow 編譯則可以停用)。 可以透過執行這個指令來檢查基本 PoW 支援:

tor --list-modules
relay: yes
dirauth: yes
dircache: yes
pow: yes

如果你有 pow: yes,那麼你就有了內建在 C Tor 中的 PoW 防禦機制。

由於授權需求,只有在使用 --enable-gpl 編譯 tor 時,才會啟用 PoW v1 用戶端謎題函式庫(tevador 的 Equi-XHashX,皆在 LGPL-3.0 下)。 這可以透過執行以下命令來確認:

tor --version
Tor 版本 0.4.8.3-rc。
Tor 的此版本包含在GNU通用公眾授權條款中 (https://www.gnu.org/licenses/gpl-3.0.en.html)
Tor 在 Linux 上運行,libc 為 Libevent 2.1.12-stable、OpenSSL 3.0.9、Zlib 1.2.13、Liblzma 5.4.1、Libzstd N/A 和 Glibc 2.36。
使用 GCC 12.2.0 版本編譯的 Tor

如果您安裝的 C Tor 沒有啟用 PoW 或不是使用 GNU GPL 支援建置的,那麼您必須尋找其他軟體包或自己編譯它。

已建立的集合點電路中的流限制

下方設置選項可用來限制會合迴路的連線:

  • HiddenServiceMaxStreams: 每個交會迴路最大的同步串流(連接)數量。 允許的最大值為 65535 (設為 0 則不限制同時串流量數量。)

  • HiddenServiceMaxStreamsCloseCircuit:如設置為 1,超過 HiddenServiceMaxStreams 將導致犯規的會合迴路被拆除,而不是超過限制的串流建立請求默默被忽略。

Onionbalance

Onionbalance 能讓洋蔥服務營運者透過多方機器處理服務請求,以達成高可用屬性。 您可使用 Onionbalance 橫向擴大。 規模越大,越不易讓攻擊者發動全面打擊。 Onionbalance 在 洋蔥服務第3版 可用。

網頁伺服器比例限制

如果攻擊者壓倒性地發動侵略迴路執行過多查詢,先試著利用 Tor 設定檔 torrcHiddenServiceExportCircuitID選項來檢測過度使用並加以阻斷。 您可以使用自己的啟發式方法或使用 Web 伺服器的速率限制模組

上述的技巧應有助您渡過動亂時代。 同時我們正努力加強更先進的防禦, 減少洋蔥營運者需手動設置與修補的地方。

快取

減少服務負載的另一種方法是實現內容緩存,可以直接在後端應用程式上實現,也可以透過設定快取代理前端來實現。

客戶授權或多重洋蔥地址來劃分使用者

如果您信任網站使用者,給予他們完整的洋蔥服務與客戶授權憑證讓服務隨時可用。 不信任的使用,將他們劃分到多重地址。 過多的洋蔥網實際上對安全不利(因為使用太多守衛節點),因此最好能使用客戶授權

Captchas 和 Cookies

如須進一步速率限制使用者,請將基礎設備劃分到各層並將驗證碼放在靠近前端位置。 這種方式駭客必須先解開驗證碼才能對基礎設備發動攻擊。

驗證碼可減緩 DDoS 攻擊。 當客戶請求時檢查客戶端是否包含正碓的安全 cookies,否則將導向至驗證頁面。 客戶端輸入驗證文字。 Nginx 發送輸入的文字到人機驗證伺服器以取得確認。

答案正確人機驗證伺服器會用"true" 開頭,否則則以"false"開頭。 為正確驗證過的客戶增添安全 cookie,將客戶重新導向所欲檢視的頁面。

也可以直接在網頁伺服器端 Ngnix OpenResty 利用 Lua 來產生與查核圖片驗證碼。 此執行不易設置。

另一種方式是執行 test-cookie 挑戰。 網頁伺服器檢查客戶端可設定有效 cookies, 惡意的用戶往往有沒這個功能。 針對 Nginx Cloudflare 提供可與 cookie 互動的程式庫

其他方式包括確認連接到 .onion 的客戶端具有有效的 User-Agent 標頭,且 Referer 標頭的值不與攻擊相關。