- Tor 0.4.8 führt einen Schutz ein, der bei DoS-Angriffen auf Onion Services verifizierten Netzwerkverkehr bevorzugt verarbeitet
- Da Onion Services zur Wahrung der Privatsphäre IP-Adressen verbergen, ist IP-basiertes Rate Limiting unvollständig; daher war ein Client-Puzzle-Ansatz nötig, der die Privatsphäre nicht beeinträchtigt
- Wenn ein Service unter Druck gerät, müssen Clients durch zunehmend schwierigere Puzzle-Berechnungen ihre Arbeitsleistung nachweisen; davon hängt dann die Priorität der Verbindung ab
- Die anfängliche Lösungszeit für normale Nutzer liegt bei schnellen Computern bei etwa 5 ms, auf langsamer Hardware bei maximal 30 ms und ist damit für die meisten Geräte tragbar
- Nimmt der Angriffsverkehr zu, steigt die geforderte Arbeitsmenge auf bis zu 1 Minute, was massenhafte Verbindungsversuche teuer macht, während legitime Nutzer auch unter Last eine Chance auf Zugriff behalten
PoW-Schutz für Onion Services in Tor 0.4.8
- Mit der Veröffentlichung von Tor 0.4.8 führt Tor offiziell einen Proof-of-Work-(PoW)-Schutz für Onion Services ein
- Ziel ist es, DoS-Angriffe einzudämmen und dabei verifizierten Traffic bevorzugt zu behandeln
- Betreibern von Onion Services wird empfohlen, auf Version 0.4.8 zu aktualisieren
- Da Onion Services zum Schutz der Privatsphäre IP-Adressen verbergen, können sie anfällig für DoS-Angriffe sein; mit herkömmlichem IP-basiertem Rate Limiting allein ist der Schutz unvollständig
Client-Puzzles und Priorisierung
- PoW funktioniert im Grunde wie ein standardmäßig deaktiviertes Ticket-System und erstellt bei Netzwerkauslastung eine Prioritätswarteschlange
- Bevor Clients auf einen Onion Service zugreifen, müssen sie ein kleines Puzzle lösen, um eine bestimmte Arbeitsleistung nachzuweisen
- Je schwieriger das Puzzle ist, desto mehr Arbeit wurde geleistet
- Der Onion Service legt die Priorität einer Verbindung anhand des nachgewiesenen Aufwands des Clients fest
- Wenn Angreifer einen Onion Service mit vielen Anfragen fluten, steigt der Rechenaufwand für den Zugriff auf die .onion-Seite
- Massenhafte Verbindungsversuche erfordern mehr Rechenressourcen
- Mit zunehmender Arbeitsmenge sinkt die Wirtschaftlichkeit für Angreifer
Auswirkungen für normale Nutzer
- Normale Nutzer senden in der Regel nur wenige Anfragen auf einmal, daher bleibt der Aufwand für das Lösen der Puzzles auf den meisten Geräten beherrschbar
- Die anfängliche Lösungszeit beträgt auf schnellen Computern etwa 5 ms
- Auf langsamer Hardware maximal 30 ms
- Wenn der Angriffsverkehr zunimmt, kann die Arbeitsmenge auf ungefähr 1 Minute steigen
- Dieser Prozess bleibt für Nutzer unsichtbar; das Warten auf eine PoW-Lösung ähnelt dem Warten auf eine langsame Netzwerkverbindung
- Wenn wichtige Websites diesen Ansatz übernehmen, kann das die negativen Auswirkungen gezielter Angriffe auf die Netzwerkgeschwindigkeit verringern, beim Lastenausgleich bei plötzlichen Traffic-Spitzen helfen und den Zugang zu Onion Services konsistenter und zuverlässiger machen
1 Kommentare
Hacker-News-Kommentare
Interessant. Wenn man sich den Vorschlag ansieht, sind die Erwartungen klar: Er soll keine großen Botnets aufhalten, sondern Script Kiddies und kleine Botnets abwehren.
Nutzer, die während eines DoS-Angriffs wirklich eine Verbindung herstellen wollen, können durchkommen, müssen dafür aber unter Umständen einen gewissen Aufwand betreiben.
Interessant ist auch, dass als Proof-of-Work-Algorithmus https://github.com/tevador/equix ausgewählt wurde.
Anders als bei Bitcoin, wo man erfolgreich ist, wenn man unter einen statischen Zielwert kommt, „bieten“ Clients mit ihrem Proof-of-Work-Aufwand; je mehr Aufwand sie investieren, desto höher ihre Priorität. Die Erklärung lautet, dass es Proof of Stake ähnelt, nur dass man statt Coins Arbeit hinterlegt.
[1] https://gitlab.torproject.org/tpo/core/torspec/-/raw/main/pr...
Diese Version ist auch gut, aber mit zusätzlicher Wertübertragung wäre sie meiner Meinung nach besser.
Außerdem ist Proof of Work nur verschwendete, unnötige Berechnung. Rechnen ist nicht kostenlos, und jedes Watt, das für Proof of Work eingesetzt wird, verschärft die aktuelle Klimakrise.
Aus der Perspektive von jemandem, der in einer Region lebt, in der es in ein paar Tagen gefühlt 120 Grad und tatsächlich 109 Grad heiß werden soll: Höflich gesagt möchte ich jedem, der vorschlägt, Proof of Work sei für irgendetwas eine gute Idee, sagen, er solle sich zum Teufel scheren.
Das ist nicht interessant, sondern das offenkundigste Beispiel für demonstrativen Konsum auf diesem Planeten.
Der bessere Text, also die tatsächlichen technischen Details, ist https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/p....
Die gewählte Proof-of-Work-Funktion scheint equi-X zu sein.
Ich bin überrascht, dass so etwas nicht früher eingeführt wurde, und da ich den Vorschlag [0] noch nicht detailliert genug gelesen habe, weiß ich noch nicht, ob dadurch mehr Daten entstehen, die die Anonymität der Nutzer beeinflussen. Wenn sie aber pro Nutzer-Service-Einheit gebunden und nirgendwo gespeichert werden, wirkt es in Ordnung.
Mich interessiert auch, wie stark das die Last des proxied Dienstes und die Last des Knotens selbst jeweils senken wird. Da die Zugriffe über mehrere Nodes verteilt werden, dürfte der Dienst selbst stärker profitieren.
[0]: https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/p...
Gut. Vielleicht braucht man bald kein CDN für DDoS-Abwehr mehr. Man stellt die API einfach als Onion Service bereit.
Dieser Ansatz wurde früher auch schon zur Bekämpfung von E-Mail-Spam vorgeschlagen.
Cloudflare könnte das ebenfalls tun. Jedes Mal, wenn man auf eine stark ausgelastete Website zugreift, müsste man für einige Sekunden bis Minuten nutzlose Berechnungen laufen lassen. Der Gesamteffekt wäre wohl, die Akkus der ganzen Welt leerzusaugen.
http://www.hashcash.org/
Interessanterweise war es die Inspiration für das Proof-of-Work-Mining von Bitcoin.
Schließlich werden dabei auch Treibhausgase in die Atmosphäre geblasen.
Ich frage mich, was Missbraucher daran hindert, sich eine neue Identität zu verschaffen und den DDoS fortzusetzen, sobald Proof of Work greift.
Edit: Es scheint, als würde Proof of Work nicht pro Client, sondern pro angegriffenem „Service“ konfiguriert.
Aufgrund der Anonymität bzw. der Möglichkeit, frei neue Identitäten zu erstellen, kann ein Angreifer mit einem Sybil-Angriff die Kapazität erschöpfen und so eine Dienstverweigerung verursachen.
Ich frage mich, ob es hier eine elegantere Möglichkeit gibt, Sybil-Angriffe zu lösen. Zum Beispiel enthalten viele CPUs pro Prozessor ein eindeutiges Schlüsselpaar, das sich über die CA-Root-Zertifikate der Aussteller Intel, AMD usw. verifizieren lässt. Wenn man den Proof-of-Work mit fortlaufenden Signaturen verknüpft und parallele Verifikation erlaubt, würde jeder Proof-of-Work CPU-spezifisch eindeutig, sodass er sich nicht per Botnet parallelisieren ließe
Sie scheinen hier auf Speicher abzuzielen, um die Kosten für Botnets zu erhöhen. Es sieht so aus, als gäbe es viele andere Wege, dieses Angriffsszenario zu reduzieren. Dieselbe Logik ließe sich wohl auch auf Mobiltelefone mit eSIM anwenden. Da die Authentifizierung in Mobilfunknetzen inzwischen Public-Key-Kryptografie nutzt, dürfte auch ein eindeutiger Nachweis möglich sein
Das ist nur ein Gedanke aus dem Stegreif, daher übersehe ich wahrscheinlich offensichtliche Probleme dieses Ansatzes
Der Grund für die Wahl eines speicherintensiven Algorithmus ist, bestimmte Hardware, nämlich ASICs, zu verhindern
In eine ähnliche Richtung: Wie wäre es, wenn der Server mehrere IP-Pools vorhält und der Client einen Port-Knocking-Nachweis zurückgibt? Zum Beispiel erhält er ein Token, schickt es an diese IP:Port-Kombination, und ich warte auf eine eindeutige Antwort, die ich verifizieren kann. Man könnte das Latenznachweis nennen. Die CPU-Nutzung wäre gering, und die Last ließe sich auf mehrere Maschinen und Ports verteilen. Der Nachteil ist natürlich, dass mehrere IPs und potenziell mehrere Server nötig sind. Man könnte es auch auf derselben Maschine umsetzen, aber dann würde sich die CPU-Last nur auf Port-Verbindungen verlagern
Ich habe eine Idee, wie man den Traffic im Tor-Netzwerk reduzieren oder es schneller machen könnte. Man müsste das Netzwerk wie ein CDN nutzen können. Wenn man eine Datei veröffentlichen möchte, sollte man Dateifragmente an erlaubte Nodes schicken können und bei einer Dateianfrage auf diese Nodes verweisen können
Natürlich muss man darauf achten, dass das Tor-Netzwerk nicht zu einem „anonymen Torrent-Ersatz“ wird und damit seinen Zweck untergräbt
Der aktuelle Vorschlag spricht von „Priorisierung verifizierten Netzwerk-Traffics“. Da es dem Netzwerk tatsächlich hilft, wäre es interessant, wenn das Teilen von „Dateifragmenten“ die Traffic-Priorität erhöhen könnte. Es wäre also statt eines „Proof-of-Work“ ein Nachweis geleisteter Bandbreite
Trotzdem sehe ich nicht recht, wie das den Netzwerk-Traffic reduzieren soll. Man muss ja trotzdem mit den CDN-Nodes kommunizieren
Angesichts der Ziele und Grenzen dieses Vorschlags wirkt er vernünftig, und er wird diese Ziele vermutlich erreichen. Wie gesagt dürfte er gegen kleine Botnets funktionieren, aber große Botnets können die verfügbaren Ressourcen einzelner Clients weiterhin überrollen
Persönlich mag ich Proof-of-Work nicht. Hier ist es eher eine Nicht-Eskalation als Verteidigungsmechanismus; es kann alte Hardware schnell veralten lassen und über alle betroffenen Geräte hinweg ziemlich viel Strom verbrauchen. Wenn es in großem Maßstab eingesetzt wird, ist das eine erhebliche Umweltbelastung
Aus Sicht des Angreifers kann schon die Erhöhung der Schwierigkeit auf dieses Niveau als Erfolg gelten. Wenn Nutzer ihr Gerät eine Minute lang bei 100 % laufen lassen und warten müssen, werden sie in vielen Fällen einfach abspringen
Trotzdem ist es ein ziemlich guter Weg, DoS-Angriffe zu entschärfen, ohne die Anonymität der Nutzer zu beeinträchtigen; aus dieser Sicht ist es trotz der Nachteile eine gute Lösung. Solange es bei Tor bleibt, ist das kein großes Problem, aber wenn es im normalen Web eingesetzt würde, hielte ich es für eine komplette Katastrophe
Im Artikel heißt es, der Unterschied bei der Lösungszeit zwischen einem High-End-Server und einem Low-End-Smartphone betrage nur das 6-Fache. Ich verstehe nicht, wie das möglich sein soll. Ein Server hat weit mehr als sechsmal so viel RAM und so viele CPUs wie ein Smartphone, und die CPUs sind wahrscheinlich auch schneller
Außerdem lässt sich bei einem DDoS die Arbeit auf Serverseite geradezu peinlich gut parallelisieren, während Client-Arbeit nicht unbedingt parallelisierbar ist
Selbst wenn der Unterschied nur 6-fach oder sogar 1-fach wäre: Sobald ein DDoS erkannt wird, soll die Lösungszeit 1 Minute betragen. Ist der Dienst zu diesem Zeitpunkt nicht faktisch offline?
Der Kern der Aussage, dass die Lösungszeit bei erkanntem DDoS 1 Minute beträgt, ist, den bisherigen einfachen DoS-Angriff namens Introduction Flooding in einen Teilausfall oder eine Verlangsamung umzuwandeln. Es ist eine schrittweise Verbesserung bei einem schwierigen Problem