jesteś w clearnecie. adresy z tej listy otwierają się tylko wewnątrz sieci tor - pobierz przeglądarkę tor tutaj »
AlphaBay.Market
PL
ostatnie sprawdzenie: 1 min temu śledzone onion: 260
strona główna / wiadomości / Sieć tor
29 października 2026 Sieć tor 5 min czytania

Obrona proof-of-work w Torze: drogi DDoS na onion services

Onion service zalewany atakiem nie może zrobić tego, co robi zwykła strona: nie ma adresów IP do limitowania, bo ani odwiedzający, ani atakujący nie ujawniają żadnego. Odpowiedź Tora, dostarczona w Torze 0.4.8 i ogłoszona na blogu projektu w sierpniu 2023, to wycena etapu introdukcji w czasie procesora. Projekt wywodzi się z proposal 327, spisanej w kwietniu 2020 przez George'a Kadianakisa, Mike'a Perry'ego, Davida Gouleta i tevadora, który nazwał sedno wprost: budowanie obwodów rendezvous jest drogie dla usługi i dla sieci, a samo limitowanie szybkości nigdy tego nie zmieniło.

Zagadka, która pojawia się tylko pod obciążeniem

Schemat jest przezroczysty w sensie protokołu: nie ma dodatkowej rundy wyzwania. Parametry zagadki leżą wewnątrz deskryptora onion service, który klienci i tak pobierają - znacznik wersji, 32-bajtowy seed, sugerowany poziom wysiłku i termin ważności. Dopóki sugerowany wysiłek wynosi zero, obrona śpi, a introdukcje przebiegają dokładnie jak wcześniej. Gdy usługa wykryje przeciążenie, podnosi sugerowany wysiłek. Klienci rozwiązują wtedy Equi-X - funkcję zagadki określoną w propozycji - nad wyzwaniem zbudowanym z ciągu personalizacji, zaślepionego ID usługi, seeda, losowego 16-bajtowego nonce i wybranego wysiłku. Rozwiązanie, około 43 bajty, jedzie w komórce INTRODUCE1 jako rozszerzenie. Według bloga Tora pierwsze rozwiązanie kosztuje około 5 milisekund na szybkiej maszynie i do około 30 na wolniejszym sprzęcie; przy utrzymującym się ataku wymagana praca może piąć się w stronę minuty obliczeń.

Kolejka płaci wysiłkiem

Sprawdzenie rozwiązania jest celowo tanie; droga część - zbudowanie obwodu rendezvous - jest odkładana. Zweryfikowane żądania trafiają do kolejki priorytetowej uporządkowanej po zadeklarowanym wysiłku, starsze wpisy wygrywają remisy, a harmonogram opróżnia ją w kontrolowanym tempie. Trudność podąża cyklem add-increase/multiply-decrease w oknach 300-sekundowych: dopóki kolejka jest nasycona, usługa podnosi wysiłek do poprzedniej wartości plus jeden albo do średniego wysiłku obsłużonych introdukcji - co jest większe; gdy presja spada, wysiłek maleje o około jedną trzecią. Klienci ponawiają z rosnącym wysiłkiem - podwajając poniżej 1000, potem mnożąc przez 1,5 - w granicach, które specyfikacja ustawia na 8 i 10 000. Seedy rotują około co dwie godziny, poprzedni seed pozostaje przez chwilę ważny, by uniknąć wyścigów.

Dlaczego zwykli użytkownicy prawie tego nie zauważają

Ponieważ zagadka istnieje tylko dopóki usługa jest pod presją, zwykły ruch przy niskim obciążeniu nie płaci nic. Człowiek klikający kilka stron w trakcie ataku wydaje milisekundy - doświadczenie, które blog porównuje do czekania na wolne połączenie - podczas gdy atakujący zalewający usługę milionami introdukcji płaci za każdą z nich. Podsumowanie Tor Project:
"Blocks attackers while giving real users a chance to reach their destination" - blog Tor Project, sierpień 2023

Jak usługi włączają obronę

Operatorzy sterują obroną przez torrc. Przełączniki udokumentowane w przewodniku projektu po DoS dla onion services:
  • HiddenServicePoWDefensesEnabled - publikuje zagadkę w deskryptorze i włącza kolejkę sortowaną po wysiłku
  • HiddenServicePoWQueueRate i HiddenServicePoWQueueBurst - jak szybko zweryfikowane żądania opuszczają kolejkę
  • CompiledProofOfWorkHash - opcja globalna wybierająca funkcję skrótu używaną w zagadkach
Moduł proof-of-work jest kompilowany i włączony domyślnie od C tor 0.4.8.1-alpha, chyba że kompilacja użyła --disable-module-pow; można to sprawdzić przez tor --list-modules, a kompilacja GPL (--enable-gpl) jest wymagana, bo biblioteki Equi-X i HashX mają licencję LGPL-3.0. Obrona układa się ze starszymi warstwami: limitowaniem szybkości na punktach introdukcji, limitami strumieni rendezvous i skalowaniem poziomym przez Onionbalance.

Problem zamożnych atakujących

Propozycja mówi wprost: schemat odstrasza script kiddies i małe botnety, nie duże. Z około tysiącem maszyn rozwiązujących każdą po jednej zagadce na sekundę atakujący przewyższa każdego pojedynczego klienta desktopowego; zalewanie staje się kwestią budżetu, nie techniki, a proposal wprost wyłącza botnety dziesiątek tysięcy maszyn ze swojego zakresu. Udokumentowano też strategie hybrydowe: ponieważ ważne żądanie o wysokim wysiłku kosztuje około 0,3 milisekundy rozwiązania, a nieważne około 5,5 milisekundy weryfikacji, atakujący mieszający około 91 ważnych i 1 520 fałszywych introdukcji na sekundę potrafi nasycić główną pętlę usługi. Rozwiązania można nawet wyliczać z wyprzedzeniem w granicach około czterech godzin życia seeda. Potem przyszła niezależna ocena. Grupa z KAIST na USENIX Security 2025 przedstawiła rodzinę ataków OnionFlation, która popycha usługę do zawyżania trudności zagadki dla wszystkich bez widocznego przeciążenia - po koszcie, który autorzy szacują na kilka dolarów za godzinę. Ich wniosek: obecny projekt wymienia odporność na inflację na odporność na przeciążenie i nie potrafi w pełni dać obu; wyniki zgłoszono Tor Projectowi, który je uznał. Adopcja to już nie hipoteza: artykuł odnotowuje, że mechanizm przyjęły duże onion services, i pozostaje on częścią aktualnych wersji tora. Proof-of-work nie kończy denial of service na Torze; wycenia na nowo jeden wąski etap, by tanie zalewy przestały być tanie. Czy to wytrzyma dobrze finansowanego przeciwnika, to pytanie o zasoby, nie o protokół. O dłuższym łuku - wojnach DDoS między marketplace'ami, które zmusiły te obrony do powstania - zobacz naszą historię DDoS na Torze.

więcej notatek

wszystkie wiadomości ›