در این صفحه چندین راه برای کاهش حملات DoS ارائه می‌دهیم. All these approaches can be combined. بااین‌حال هیچ راه حل واحدی برای این مشکل وجود ندارد. دفاع از یک سایت تحت حمله نیاز به خلاقیت و رویکردی ویژه دارد.

An overview of implemented defenses at the tor daemon is given in the Overview section from the Denial-of-service prevention mechanisms in Tor specification, and here we give some practical tips.

Rate limiting at the Introduction Points

از زمانی که طرح پیشنهادی 305 اجرا شد، برخی از گزینه‌های torrc برای کمک به کاهش حملات DoS در نقاط معرفی اضافه شدند:

  • HiddenServiceEnableIntroDoSDefense: دفاع DoS را در سطح intropoint فعال کنید. هنگامی که این مورد به‌کار می‌افتد، پارامتر Rate و Burst به نقطه معرفی ارسال می‌شود که سپس از آن‌ها برای اعمال محدودیت نرخ (Rate) درخواست برای درخواست معرفی به این سرویس استفاده می‌کند.

  • HiddenServiceEnableIntroDoSBurstPerSec: تعداد سرویس‌گیرنده مجاز در نقطه معرفی که در هر ثانیه burst می‌شود. اگر این گزینه 0 باشد، بی‌نهایت در نظر گرفته می‌شود و بنابراین اگر HiddenServiceEnableIntroDoSDefense تنظیم شود، به‌طور مؤثر دفاع‌ها را از کار می‌اندازد.

  • HiddenServiceEnableIntroDoSRatePerSec: تعداد سرویس‌گیرنده مجاز در نقطه معرفی که در هر ثانیه rate می‌شود. اگر این گزینه 0 باشد، بی‌نهایت در نظر گرفته می‌شود و بنابراین اگر HiddenServiceEnableIntroDoSDefense تنظیم شود، به‌طور مؤثر دفاع‌ها را از کار می‌اندازد.

For more information on how they work, check the tor(1) manpage and the Denial-of-Service defense extension (DOS_PARAMS) section of the Onion Services v3 specification.

Proof of Work (PoW) before establishing Rendezvous Circuits

A Proof of Work (PoW) defense mechanism is explained in length at the PoW FAQ, and can be configured for each Onion Service with the following torrc options:

  • HiddenServicePoWDefensesEnabled: Enable proof-of-work based service DoS mitigation. When enabled, tor will include parameters for an optional client puzzle in the encrypted portion of this hidden service's descriptor. Incoming rendezvous requests will be prioritized based on the amount of effort a client chooses to make when computing a solution to the puzzle. The service will periodically update a suggested amount of effort, based on attack load, and disable the puzzle entirely when the service is not overloaded.

  • HiddenServicePoWQueueRate: The sustained rate of rendezvous requests to dispatch per second from the priority queue.

  • HiddenServicePoWQueueBurst: The maximum burst size for rendezvous requests handled from the priority queue at once.

The following global option is applicable to both onion services and their clients:

  • CompiledProofOfWorkHash: When proof-of-work DoS mitigation is active, both the services themselves and the clients which connect will use a dynamically generated hash function as part of the puzzle computation.

PoW is enabled by default on C Tor versions 0.4.8.1-alpha onwards (but can be disabled if compiled with --disable-module-pow). Basic PoW support can be checked by running this command:

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

If you have pow: yes, then you have the PoW defense mechanism built into C Tor.

Due to license requirements, the PoW v1 client puzzle libraries (Equi-X and HashX by tevador, both under the LGPL-3.0) are enabled only if tor is compiled with --enable-gpl. This can be confirmed by running the following command:

tor --version
Tor version 0.4.8.3-rc.
This build of Tor is covered by the GNU General Public License (https://www.gnu.org/licenses/gpl-3.0.en.html)
Tor is running on Linux with Libevent 2.1.12-stable, OpenSSL 3.0.9, Zlib 1.2.13, Liblzma 5.4.1, Libzstd N/A and Glibc 2.36 as libc.
Tor compiled with GCC version 12.2.0

If your installed C Tor does not have PoW enabled or is not built with GNU GPL support, then you'll have to look for other packages or compile it yourself.

Stream limits in the established Rendezvous Circuits

برای محدود‌کردن اتصالات در مدارهای ملاقات (rendezvous) می‌توان از گزینه‌های پیکربندی زیر استفاده کرد:

  • HiddenServiceMaxStreams: حداکثر تعداد جریان‌های (اتصالات) همزمان در مدار ملاقات (rendezvous). حداکثر مقدار مجاز ۶۵۵۳۵ است. (تنظیم آن روی ۰ تعداد نامحدودی از جریان‌های همزمان را امکان‌پذیر می‌کند.)

  • HiddenServiceMaxStreamsCloseCircuit: اگر روی 1 تنظیم شود، فراتر‌رفتن از مقدار HiddenServiceMaxStreams باعث می‌شود که مدار ملاقات متخلف از بین برود، برخلاف درخواست‌های ایجاد جریان‌های بیش از حد مجاز که در خفا نادیده گرفته می‌شوند.

Onionbalance

Onionbalance به اپراتورهای سرویس Onion اجازه می‌دهد تا با دادن اجازه رسیدگی به درخواست‌های سرویس Onion به چندین ماشین به ویژگی دسترسی بالا دست یابند. می‌توانید از Onionbalance برای مقیاس افقی استفاده کنید. هر چه مقیاس بزرگتر شود، غلبه مهاجمان بر شما سخت‌تر می‌شود. Onionbalance برای خدمات Onion v3 در دسترس است.

محدودیت نرخ درخواست سرور وب

اگر مهاجمان توسط مدارهای تهاجمی شما را غرق در انجام پرسمان‌های بسیار می‌کنند، سعی کنید استفادهٔ بیش از حد را شناسایی کرده و با استفاده از گزینه ‏‏‎‏‏HiddenServiceExportCircuitID ‏torrc آن‌ها را نابود کنید. می‌توانید از ابتکارات خود یا از ماژول محدودیت نرخ درخواست سرور وب خود استفاده کنید.

نکات فوق باید به شما کمک کند تا زمان‌های آشفته را پشت سر بگذارید. در عین حال، ما درحال کار روی دفاع‌های پیشرفته‌تر هستیم، به‌طوری که پیکربندی دستی و سرهم بندی کمتری توسط اپراتورهای Onion مورد نیاز باشد.

Caching

Another way to reduce the load on your service is to implement content caching, either directly at the backend application or by setting up a caching proxy frontend.

صدور مجوز سرویس‌گیرنده یا چندین نشانی Onion برای حیطه‌بندی‌کردن کاربران

اگر کاربرانی دارید که به آن‌ها اعتماد دارید، به آن‌ها اعتبارنامه اختصاصی سرویس Onion و صدور مجوز سرویس‌گیرنده بدهید تا همیشه در دسترس باشد. برای کاربرانی که به آن‌ها اعتماد ندارید، آن‌ها را به چند نشانی تقسیم کنید. بااین‌حال، داشتن نشانی‌های Onion بیش از حد (به دلیل استفاده از گره‌های محافظ بسیار) برای امنیت شما مضر است، بنابراین سعی کنید در صورت امکان از صدور مجوز سرویس‌گیرنده‏ استفاده کنید.

کپچاها و کوکی‌ها

اگر نیاز به اعمال محدودیت نرخ درخواست روی کاربران دارید، زیرساخت‌های خود را به لایه‌هایی تقسیم کرده و کپچاها را نزدیک لایهٔ جلویی قرار دهید. به‌این‌ترتیب مهاجمان قبل از اینکه بتوانند به عمق زیرساخت‌های شما حمله کنند باید کپچاها را حل کنند.

کپچاها راهی برای کاهش حملات DDoS هستند. هنگامی که درخواستی از یک سرویس‌گیرنده می‌آید، بررسی می‌کند که آیا سرویس‌گیرنده حاوی کوکی امن صحیح است یا خیر. در غیر این صورت به صفحه ری‌کپچا هدایت می‌شود. سرویس‌گیرنده حروف کپچا را وارد می‌کند. Nginx این حروف ورودی را برای تأیید به سرور ری‌کپچا ارسال می‌کند.

پاسخ صحیح از سرور ری‌کپچا با «true...» شروع، در غیر این صورت با «false...» شروع می‌شود. با اضافه‌کردن کوکی امن برای سرویس‌گیرنده تأییدشده صحیح، سرویس‌گیرنده را به بازدید از صفحه‌ی مورد نظر هدایت می‌کند.

این امکان وجود دارد که کپچاها را به‌طور مستقیم در وب‌سرور خود با Nginx و OpenResty با استفاده از Lua برای تولید و تأیید تصاویر کپچا پیاده‌سازی کنید. پیکربندی این پیاده‌سازی آسان نیست.

یک (روش) جانشین ممکن است صرفاً اجرای یک چالش کوکی آزمایشی باشد. در وب‌سرور خود بررسی کنید که سرویس‌گ‍یرنده بتواند کوکی‌هایی معتبر تنظیم کند، سرویس‌گیرنده‌های مخرب اغلب این ویژگی را ندارند. در Nginx، ‏Cloudflare یک کتابخانه برای تعامل با کوکی‌ها فراهم می‌کند.

روش‌های دیگر شامل حصول اطمینان از اینکه سرویس‌گ‍یرنده‌هایی که به .onion شما متصل می‌شوند دارای سرآیند User-Agent معتبر باشند و همچنین سرآیند Referer روی مقداری تنظیم نشده باشد که بتوانید آن را با حمله مرتبط کنید.