În această pagină vă prezentăm câteva modalități de atenuare a atacurilor DoS în prezent. All these approaches can be combined. Cu toate acestea, nu există o singură soluție universală pentru această problemă în acest moment. Apărarea unui site atacat necesită creativitate și o abordare personalizată.

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

Deoarece propunerea 305 a fost pusă în aplicare, au fost adăugate unele opțiuni torrc pentru a ajuta la atenuarea atacurilor dos la punctele de introducere:

  • HiddenServiceEnableIntroDoSDefense: Activați apărarea DoS la nivelul de intropoint. Atunci când acest lucru este activat, parametrul rate și izbucni va fi trimis la punctul de introducere, care le va utiliza apoi pentru a aplica limitarea ratei pentru cererea de introducere la acest serviciu.

  • HiddenServiceEnableIntroDoSBurstPerSec: Introducerea permisă a clientului se sparge pe secundă la punctul de introducere. Dacă această opțiune este 0, este considerată infinită și, prin urmare, dacă este setată HiddenServiceEnableIntroDoSDefense, atunci dezactivează efectiv apărarea.

  • HiddenServiceEnableIntroDoSRatePerSec: Rata de introducere a clientului permisă pe secundă la punctul de introducere. Dacă această opțiune este 0, este considerată infinită și, prin urmare, dacă este setată HiddenServiceEnableIntroDoSDefense, atunci dezactivează efectiv apărarea.

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

Următoarele opțiuni de configurare pot fi utilizate pentru a limita conexiunile în circuitele de întâlnire:

  • HiddenServiceMaxStreams: Numărul maxim de fluxuri simultane (conexiuni) per circuit de întâlnire. Valoarea maximă permisă este 65535. (Setarea acestui la 0 va permite un număr nelimitat de fluxuri simultane.)

  • HiddenServiceMaxStreamsCloseCircuit: Dacă este setat la 1, atunci depășirea HiddenServiceMaxStreams va determina ca circuitul de întâlnire ofensator să fie distrus, spre deosebire de cererile de creare a fluxului care depășesc limita fiind ignorate în tăcere.

Onionbalance

Onionbalance permite operatorilor serviciilor Onion să atingă proprietatea de înaltă disponibilitate, permițând mai multor calculatoare să gestioneze cererile pentru un serviciu Onion. Puteți utiliza Onionbalance pentru a scala orizontal. Cu cât scalați mai mult, cu atât este mai greu pentru atacatori să vă copleșească. Onionbalance este disponibil pentru serviciile Onion v3.

Rata de limitare a serverului web

Dacă atacatorii vă copleșesc cu circuite agresive care efectuează prea multe interogări, încercați să detectați această utilizare excesivă și să le ucideți folosind opțiunea torrc HiddenServiceExportCircuitID. Puteți utiliza propria euristică sau puteți utiliza modulul de limitare a ratei al serverului dumneavoastră web.

Sfaturile de mai sus ar trebui să vă ajute să vă mențineți pe linia de plutire în vremuri tulburi. În același timp lucrăm la sisteme de apărare mai avansate, astfel încât operatorii onion au nevoie de mai puține configurații și reparații manuale.

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.

Autorizare client sau mai multe adrese onion pentru a vă compartimenta utilizatorii

Dacă aveți utilizatori în care aveți încredere, oferiți-le servicii Onion dedicate și acreditări de autorizare a clienților, astfel încât să poată fi întotdeauna disponibile. Pentru utilizatorii în care nu aveți încredere, împărțiți-le în mai multe adrese. Acestea fiind spuse, având prea multe adrese de ceapă este de fapt rău pentru securitatea dumneavoastră (din cauza utilizării multor noduri de pază), așa că încercați să utilizați autorizația clientului atunci când este posibil.

Captchas și cookies

Dacă aveți nevoie pentru a continua rata-limită de utilizatori, împărțiți infrastructura în straturi și a pus Captchas lângă frontend. În acest fel, atacatorii vor trebui să rezolve Captcha-uri înainte de a putea ataca mai adânc în infrastructura dumneavoastră.

Captchas sunt o modalitate de a atenua atacurile de tip DDoS. Atunci când o cerere vine de la un client verifică dacă clientul conține cookie-ul securizat corect altfel redirecționează către pagina recaptcha. Clientul introduce literele captcha. Nginx trimite aceste litere de intrare la serverul recaptcha pentru verificare.

Răspunsul corect de la serverul recaptcha cu începutul "adevărat...", altfel începe cu "fals...". Adăugați cookie-ul securizat pentru clientul verificat corect, redirecționați clientul către pagina pe care dorește să o vizualizeze.

Este posibil să implementați Captchas direct pe serverul dvs. Web cu Nginx și OpenResty folosind Lua pentru a genera și a verifica imaginile captcha. Această implementare nu este ușor de configurat.

O alternativă ar putea fi implementarea unei provocări de testare a cookie-urilor. La serverul dumneavoastră web verificați dacă clienții pot seta cookie-uri valide, clienții rău intenționați adesea nu au această caracteristică. În Nginx, Cloudflare oferă o bibliotecă pentru a interacționa cu cookie-urile.

Alte metode includ asigurarea faptului că clienții care se conectează la .onion au antetul User-Agent valid, iar antetul Referer nu este setat la o valoare pe care o puteți asocia cu atacul.