Auf dieser Seite stellen wir einige Möglichkeiten vor, um DoS-Angriffe zu verringern. Alle diese Ansätze können kombiniert werden. Allerdings gibt es derzeit keine Patent-Lösung für dieses Problem. Die Verteidigung eines angegriffenen Standorts erfordert Kreativität und einen maßgeschneiderten Ansatz.

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.

Ratenbegrenzung an den Einleitungspunkten

Seit Proposal 305 implementiert wurde, wurden einige torrc Optionen hinzugefügt um dabei zu helfen, DoS-Attacken am Einstiegspunkt abzumildern:

  • HiddenServiceEnableIntroDoSDefense: Aktiviert Verteidigung gegen DoS-Attacken am Einstiegspunkt. Wenn dies aktiviert ist werden die rate und burst Parameter an den Einstiegspunkt gesendet, welcher diese nutzt um die Rate der Bekanntmachungsanfragen zu begrenzen.

  • HiddenServiceEnableIntroDoSBurstPerSec: Die maximal erlaubte Anzahl der Bekanntmachungen am Einstiegspunkt pro Sekunde. Wenn diese Option 0 ist, dann wird sie als unendlich angenommen und setzt damit effektiv die Verteidigungen von HiddenServiceEnableIntroDoSDefense außer Kraft, falls sie aktiviert sind.

  • HiddenServiceEnableIntroDoSRatePerSec: Die erlaubte durchschnittliche Anzahl der Bekanntmachungen pro Sekunde am Einstiegspunkt. Wenn diese Option 0 ist, dann wird sie als unendlich angenommen und setzt damit effektiv die Verteidigungen von HiddenServiceEnableIntroDoSDefense außer Kraft, falls sie aktiviert sind.

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.

Ausführungsnachweis vor der Erstellung von Rendezvous-Kanälen

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: Aktiviere die DoS-Abwehr auf Basis von Proof-of-Work. Wenn aktiviert, fügt tor Parameter für ein optionales Client-Puzzle in den verschlüsselten Teil des Deskriptors dieses versteckten Dienstes ein. Eingehende Rendezvous-Anfragen werden nach dem Aufwand, den ein Klient bei der Berechnung der Lösung des Rätsels betreiben will, priorisiert. Der Dienst aktualisiert in regelmäßigen Abständen den vorgeschlagenen Aufwand auf der Grundlage der Angriffslast und schaltet das Puzzle vollständig ab, wenn der Dienst nicht überlastet ist.

  • HiddenServicePoWQueueRate: Die anhaltende Rate der Rendezvous-Anfragen, die pro Sekunde von der Prioritätswarteschlange abgefertigt werden.

  • HiddenServicePoWQueueBurst: Die maximale Burst-Größe für Rendezvous-Anfragen, die von der Prioritätswarteschlange auf einmal bearbeitet werden.

Die folgende globale Option gilt sowohl für Onion-Dienste als auch für deren Kunden:

  • CompiledProofOfWorkHash: Wenn die DoS-Abwehr durch Proof-of-Work aktiv ist, verwenden sowohl die Dienste selbst als auch die Clients, die eine Verbindung herstellen, eine dynamisch generierte Hash-Funktion als Teil der Puzzle-Berechnung verwenden.

PoW ist standardmäßig in C Tor ab Version 0.4.8.1-alpha aktiviert (kann aber deaktiviert werden, wenn es mit --disable-module-pow kompiliert wurde). Die grundlegende PoW-Unterstützung kann durch Ausführen dieses Befehls überprüft werden:

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

Wenn du pow: yes hast, dann hast du den PoW-Verteidigungsmechanismus in C Tor eingebaut.

Aufgrund von Lizenzanforderungen werden die PoW v1 Client-Puzzle-Bibliotheken (Equi-X und HashX von tevador, beide unter der LGPL-3.0) nur aktiviert, wenn tor mit --enable-gpl kompiliert wird. Dies kann durch das Ausführen des folgenden Befehls bestätigt werden:

tor --version
Tor version 0.4.8.3-rc.
Diese Version von Tor unterliegt der GNU General Public License (https://www.gnu.org/licenses/gpl-3.0.en.html)
Tor läuft auf Linux mit Libevent 2.1.12-stable, OpenSSL 3.0.9, Zlib 1.2.13, Liblzma 5.4.1, Libzstd N/A und Glibc 2.36 als libc.
Tor kompiliert mit GCC version 12.2.0

Wenn dein installiertes C Tor PoW nicht aktiviert hat oder nicht mit GNU GPL-Unterstützung gebaut wurde, dann musst du nach anderen Paketen suchen oder es selbst kompilieren.

Datenstromgrenzen in den festgelegten Rendezvous-Kanälen

Die folgenden Konfigurationsoptionen können genutzt werden, um die Zahl der Verbindungen im Rendezvous-Kanal zu begrenzen:

  • HiddenServiceMaxStreams: Die maximale Anzahl gleichzeitiger streams (Verbindungen) pro Rendezvous-Kanal. Der maximal erlaubte Wert ist 65535. (Wenn dieser Wert auf 0 gesetzt wird, wird eine unbegrenzte Zahl gleichzeitiger Verbindungen erlaubt.)

  • HiddenServiceMaxStreamsCloseCircuit: Wenn diese Option auf 1 gesetzt wird, werden Rendezvous-Kanäle, die HiddenServiceMaxStreams überschreiten, geschlossen anstatt Verbindungsanfragen, die das Limit überschreiten, leise zu ignorieren.

Onionbalance

Onionbalance ermöglicht es Betreibern von Onion-Diensten, die Eigenschaft der Hochverfügbarkeit zu erreichen, indem sie es mehreren Maschinen erlauben, Anfragen für einen Onion-Dienst zu bearbeiten. Du kannst Onionbalance zur horizontalen Skalierung verwenden. Je mehr du skalierst, desto schwieriger ist es für Angreifer, dich zu überwältigen. Onionbalance ist verfügbar für v3 Onion-Dienste.

Webserver-Ratenbegrenzung

Wenn Angreifer dich mit aggressiven Kanälen überwältigen, die zu viele Abfragen durchführen, versuche, diese Überlastung zu erkennen und sie mit der torrc-Option HiddenServiceExportCircuitID zu unterbinden. Du kannst deine eigenen Heuristiken verwenden oder das Ratenbegrenzungsmodul deines Webservers nutzen.

Die oben genannten Tipps sollten dir helfen, dich in turbulenten Zeiten über Wasser zu halten. Gleichzeitig arbeiten wir an fortschrittlicheren Verteidigungsmaßnahmen, so dass weniger manuelle Konfigurationen und Eingriffe durch die Onion-Betreiber erforderlich sind.

Zwischenspeicherung

Eine weitere Möglichkeit, die Belastung deines Dienstes zu verringern, ist die Implementierung von Content-Caching, entweder direkt in der Backend-Anwendung oder durch Einrichtung eines Caching-Proxy-Frontends.

Client-Autorisierung oder mehrere Onion-Adressen zur Abgrenzung deiner Benutzer

Wenn du Benutzer hast, denen du vertraust, gib ihnen spezielle Anmeldedaten für den Onlion-Dienst und die Client-Autorisierung, damit er immer verfügbar ist. Bei Benutzern, denen du nicht vertraust, kannst du sie auf mehrere Adressen aufteilen. Das heißt, zu viele Onion-Adressen sind schlecht für deine Sicherheit (wegen der Verwendung von vielen Schutz-Knoten), also versuche, wenn möglich, Client Authorization zu verwenden.

Captchas und Cookies

Wenn du die Nutzerzahlen weiter einschränken musst, solltest du deine Infrastruktur in mehrere Ebenen teilen und Captchas in der Nähe des Frontends einsetzen. Auf diese Weise müssen Angreifer Captchas lösen, bevor sie in der Lage sind, tiefer in deine Infrastruktur einzudringen.

Captchas sind eine Möglichkeit, DDoS-Angriffe zu verringern. Wenn eine Anfrage von einem Client kommt, wird geprüft, ob der Client das korrekte Sicherheits-Cookie enthält, andernfalls wird er auf die Recaptcha-Seite umgeleitet. Der Client gibt die Captcha-Zeichen ein. Nginx sendet diese Eingabezeichen zur Überprüfung an den Recaptcha-Server.

Die korrekte Antwort vom Recaptcha-Server beginnt mit "true...", ansonsten beginnt sie mit "false...". Füge das sichere Cookie für den richtigen verifizierten Client hinzu und leite den Client zu der Seite um, die er sehen möchte.

Es ist möglich, Captchas direkt auf deinem Webserver mit Nginx und OpenResty zu implementieren, indem du Lua zum Generieren und Verifizieren der Captcha-Bilder verwendest. Diese Implementierung ist nicht einfach zu konfigurieren.

Eine Alternative könnte darin bestehen, eine Test-Cookie-Herausforderung zu implementieren. Prüfe auf deinem Webserver, ob die Clients gültige Cookies setzen können; bösartige Clients haben diese Funktion oft nicht. In Nginx bietet Cloudflare eine Bibliothek zur Interaktion mit Cookies.

Andere Methoden beinhalten die Sicherstellung, dass Clients, die sich mit deiner .onion verbinden, einen gültigen User-Agent-Header haben und der Referer-Header nicht auf einen Wert gesetzt ist, den du mit dem Angriff in Verbindung bringen kannst.