Dėkojame, kad skyrėte laiko šiam vertimui perskaityti! Nesame Tor tinklo ekspertai, bet žinome, kaip tai daryti.
Jei kas nors iš čia aprašyto jums atrodo prasminga ir (arba) įtariate, kas vyksta, bet koks atsiliepimas yra labai dėkingas!
1. Kas vyksta?
Mūsų paslauga ilgą laiką veikė gerai ir stabiliai. Staiga mūsų paslaugai atsirado iš pradžių lengvų, paskui sunkių našumo problemų, o vėliau ji tapo visiškai nepasiekiama.
Neatrodo, kad tai būtų "įprasta" DDoS ataka. Atrodo, kad tai DoS ataka, bet ne tokia, kaip kas nors žinoma, nes atrodo, kad tai ataka tik prieš "Tor" demoną. Visos iki šiol išbandytos atsakomosios priemonės buvo nesėkmingos. Nepastebėta jokios atakos prieš faktiškai veikiančias paslaugas (http, ssh, ftp, paštą ir t. t.), o tik prieš patį "Tor" ryšį.
Net ir sunkiai atlikome nuodugnų tyrimą ir tyrimą, atrodo, kad šis įvykis mums nesuprantamas. Dokumentų apie ankstesnes atakas prieš "Tor" paslėptąsias paslaugas galima rasti retai ir jie neturi prasmės tam, ką patiriame mes.
Atsisakome tikėti, kad egzistuoja nežinomas atakos scenarijus, kuriam neįmanoma pasipriešinti, nes dėl to kiekviena "Tor" paslėpta paslauga taptų pažeidžiama, o priešininkai galėtų per kelias minutes neribotam laikui savo nuožiūra išjungti bet kurią "Tor" paslėptą paslaugą. Poveikis "Tor" bendruomenei būtų neaprėpiamas.
Tikimės, kad kas nors, turintis reikiamų žinių ir patirties, gali mums bent užsiminti, kas tiksliai vyksta, ir nukreipti mus tinkama linkme, kad rastume sprendimą, kaip nutraukti šią ataką arba sumažinti jos poveikį mūsų sistemoms ir užkirsti kelią tokioms atakoms ateityje. Tai padėtų apsaugoti "Tor Hidden Services" visame pasaulyje nuo tokių atakų, kokią patyrėme dabar, ateityje.
2. Kokia yra sąranka?
- Sistema veikia dabartiniame ir visada atnaujintame "Linux" (amd64) serveryje
- Visas srautas nukreipiamas per "Tor" per "Tor Transport" 9040 prievadą, DNS užklausos taip pat sprendžiamos per "Tor".
- Paslėpta "Tor" paslauga yra v3
- Tor yra 0.4.7.8 versijos, veikianti su Libevent 2.1.12-stable, OpenSSL 1.1.1n, Zlib 1.2.11, Liblzma 5.2.5, Libzstd 1.4.8 ir Glibc 2.31 kaip libc
- Tor, sukompiliuotas naudojant GCC 10.2.1 versiją. Taip pat įdiegta Vanguards 0.3.1
- Tor veikia kaip systemd paslauga
- Vanguards veikia kaip systemd paslauga
Torrc konfigūracija:
CookieAuthentication 1
HashedControlPassword 16:<hash>
VirtualAddrNetworkIPv4 10.192.0.0.0/10
AutomapHostsOnResolve 1
TransPort 127.0.0.1:9040
DNSPort 127.0.0.1:53
HiddenServiceDir /var/lib/tor/hidden_service
HiddenServicePort 80 127.0.0.0.1:80
HiddenServiceVersion 3
HiddenServiceAllowUnknownPorts 0
3. Kokie yra simptomai?
- Praėjus mažiau nei minutei po "Tor" paleidimo su įjungta paslėpta paslauga, procesoriaus našumas pasiekia 100 %, atmintis atrodo nepaveikta.
- Naudojamas duomenų srauto pralaidumas padidėja apie 100 kb/s
- Paslėptosios paslaugos deskriptorius nepasiekiamas
- Sistema vis dar gali nustatyti "Clearnet" ir "Tor" adresus
- Sistema vis dar gali prisijungti prie išeinančių paslaugų (pvz., curl į svetainę)
- Sistema užtvindoma įeinančiais tcp paketais per kilpos sąsają
- Kai "Tor" paleidžiama iš naujo, užtvindymas kelioms sekundėms baigiasi, tada vėl prasideda
- Paleidus "Tor" be įjungtos paslėptos paslaugos, problemos nekyla
- Kai "Tor" paleidžiama su įjungta antrąja paslėpta paslauga, abu paslėptos paslaugos deskriptoriai lieka nepasiekiami:
Tor naršyklė pirminėje HS:
Tor: Tor: Tor: Tor: Onionsite Has Disconnected (Onionsite atsijungė)
Labiausiai tikėtina priežastis yra ta, kad onionsite yra atsijungusi. Kreipkitės į onionsite administratorių.
Išsami informacija: 0xF2 - Įvedimas nepavyko, o tai reiškia, kad deskriptorius buvo rastas, tačiau paslauga nebėra prijungta prie įvedimo taško. Tikėtina, kad paslauga pakeitė savo deskriptorių arba ji neveikia.
arba
Ryšys nutrūko
Serveris adresu (užpuolė paslėptas paslaugos deskriptorius).onion atsako per ilgai.
Gali būti, kad svetainė laikinai nepasiekiama arba yra per daug užimta. Pabandykite dar kartą po kelių akimirkų.
Tor naršyklė ant sekmadienio HS:
Nepavyksta prisijungti
Firefox negali užmegzti ryšio su serveriu adresu (Secondary hidden service descriptor).onion
Svetainė gali būti laikinai nepasiekiama arba per daug užimta. Pabandykite dar kartą po kelių akimirkų.
- Kai "Tor" paleidžiama su įjungta antrąja paslėpta paslauga, kuri yra apsaugota OnionAuthentication, pirminis paslėptos paslaugos deskriptorius lieka nepasiekiamas,
antrasis (apsaugotas) paslėptosios paslaugos deskriptorius yra pasiekiamas.
- Kai "Tor" paleidžiama tik su įjungta antrąja paslėpta paslauga (su OnionAuthentication arba be jos), atrodo, kad problemų nekyla.
- Kai "Tor" paleidžiama su pagrindine paslėpta paslauga, apsaugota "OnionAuthentication", paslėptos paslaugos deskriptorius yra pasiekiamas.
- Užpuolus Tor žurnalo faile atsiranda šie įrašai:
rugpjūčio 24 d. 19:42:18.000 [pranešimas] Įkrovimas atliktas 100% (baigta): Atlikta
Aug 24 19:42:34.000 [pranešimas] Panašu, kad pasikeitė jūsų tinklo ryšio greitis. Atstatomas timeout į 60000ms po 18 timeouts ir 388 buildtimes.
Aug 24 19:42:39.000 [pranešimas] Panašu, kad pasikeitė jūsų tinklo ryšio greitis. Iš naujo nustatomas 60000ms timeout po 18 timeouts ir 240 buildtimes.
Aug 24 19:42:53.000 [pranešimas] Panašu, kad pasikeitė jūsų tinklo ryšio greitis. Iš naujo nustatomas 60000ms timeout po 18 timeouts ir 489 buildtimes.
Aug 24 19:43:11.000 [pranešimas] Panašu, kad pasikeitė jūsų tinklo ryšio greitis. Iš naujo nustatomas 60000ms timeout po 18 timeouts ir 659 buildtimes.
...
Aug 24 19:46:09.000 [pranešimas] Itin didelė grandinės kūrimo laiko trukmės reikšmė: 122s. Darant prielaidą, kad laikrodžio šuolis. 14 tikslas (Matuoti grandinės trukmę)
Aug 24 19:46:09.000 [pranešimas] Itin didelė grandinės kūrimo laiko trukmės reikšmė: 122s. Daroma prielaida, kad laikrodžio šuolis. Tikslas 14 (Grandinės trukmės matavimas)
Aug 24 19:46:09.000 [pranešimas] Atrodo, kad pasikeitė jūsų tinklo ryšio greitis. Atstatomas timeout į 60000ms po 18 timeout ir 114 buildtimes.
Aug 24 19:46:15.000 [pranešimas] Panašu, kad pasikeitė jūsų tinklo ryšio greitis. Iš naujo nustatomas 60000ms timeout po 18 timeouts ir 125 buildtimes.
...
Aug 24 19:47:08.000 [pranešimas] Itin didelė grandinės kūrimo laiko trukmės reikšmė: 123s. Darant prielaidą, kad laikrodžio šuolis. 14 tikslas (Matuoti grandinės trukmę)
Aug 24 19:47:10.000 [pranešimas] Itin didelė grandinės kūrimo laiko trukmės reikšmė: 122s. Daroma prielaida, kad laikrodžio šuolis. Tikslas 14 (Grandinės trukmės matavimas)
Aug 24 19:47:10.000 [pranešimas] Itin didelė grandinės kūrimo laiko trukmės reikšmė: 123s. Daroma prielaida, kad laikrodžio šuolis. Tikslas 14 (Grandinės trukmės matavimas)
Aug 24 19:47:13.000 [pranešimas] Itin didelė grandinės kūrimo laiko reikšmė: 123s. Daroma prielaida, kad laikrodžio šuolis. Tikslas 14 (Grandinės trukmės matavimas)
Aug 24 19:47:14.000 [pranešimas] Atrodo, kad pasikeitė jūsų tinklo ryšio greitis. Atstatomas timeout į 60000ms po 18 timeout ir 495 buildtimes.
Aug 24 19:47:18.000 [pranešimas] Panašu, kad pasikeitė jūsų tinklo ryšio greitis. Iš naujo nustatomas 60000ms timeout po 18 timeouts ir 124 buildtimes.
Aug 24 19:47:21.000 [pranešimas] Itin didelė grandinės sukūrimo trukmės reikšmė: 122s. Daroma prielaida, kad laikrodžio šuolis. 14 tikslas (grandinės trukmės matavimas)
Aug 24 19:47:23.000 [pranešimas] Itin didelė grandinės kūrimo laiko trukmė: 123s. Daroma prielaida, kad laikrodžio šuolis. Tikslas 14 (Grandinės trukmės matavimas)
...
Aug 24 19:47:55.000 [pranešimas] Atrodo, kad pasikeitė jūsų tinklo ryšio greitis. Iš naujo nustatomas 60000ms timeout po 18 timeout ir 1000 buildtimes.
Aug 24 19:47:59.000 [pranešimas] Panašu, kad pasikeitė jūsų tinklo ryšio greitis. Iš naujo nustatomas 60000ms timeout po 18 timeouts ir 117 buildtimes.
...
Aug 24 19:52:43.000 [notice] Keista grandinės kūrimo laiko reikšmė: 121581msec. Darant prielaidą, kad laikrodžio šuolis. 14 paskirtis (grandinės trukmės matavimas)
Aug 24 19:52:43.000 [pranešimas] Panašu, kad pasikeitė jūsų tinklo ryšio greitis. Atstatoma laiko trukmė į 120000ms po 18 laiko trukmių ir 57 pastatymo laikų.
Aug 24 19:52:53.000 [pranešimas] Pertrauka: švarus išėjimas.
4. Kas buvo bandyta išspręsti problemą?
- Sukūrėme visiškai naują serverį nuo nulio, kuriame veikia tik bazinė OS, taip pat tor ir vanguards standartinės konfigūracijos, kad atmestume neteisingos konfigūracijos galimybę mūsų paveiktame serveryje. Vos tik paleidus tor su atakuojamu deskriptoriumi, vyksta lygiai tie patys dalykai.
- Šioje konfigūracijoje bandėme paskirstyti mūsų serverio apkrovą per "OnionBalance":
Serveris1: paleidžia Onionbalance pagrindiniam paslėptos paslaugos deskriptoriui
Serveris2/3/4: paleidžia paslėptąją paslaugą naujiems ir skirtingiems paslėptosios paslaugos deskriptoriams
- Dėl to pirminis paslėptosios paslaugos deskriptorius neatgaivinamas.
- Paslaugų deskriptoriai, esantys serveriuose 2/3/4, yra pasiekiami, kai atidaromi tiesiogiai, bet ne per dabar subalansuotą pagrindinį deskriptorių
- 2/3/4 serverių procesoriaus veikimas padidėja iki 100 %, kol vyksta ataka, o 1 serverio (balansavimo įrenginio) procesoriaus veikimas išlieka normalus
- Pridėjus daugiau pirminių serverių prie balansavimo įrenginio, tai taip pat nepadarė jokios įtakos
- Pridėjome šias direktyvas į paslėptų paslaugų bloką torrc ir išbandėme įvairius jų nustatymus:
HiddenServiceEnableIntroDoSDefense 1
HiddenServiceEnableIntroDoSBurstPerSec <išbandyta su įvairiomis reikšmėmis>
HiddenServiceEnableIntroDoSRatePerSec <išbandyta su įvairiomis reikšmėmis>
Tai gerokai sumažino procesoriaus apkrovą 2/3/4 serveriuose, tačiau subalansuotos paslaugos deskriptorius išlieka nepasiekiamas.
- Bandėme keisti įvairias vanguards.conf nuostatas, tačiau nesėkmingai.
- Bandėme identifikuoti atakuojančius tcp paketus ir juos blokuoti per "iptables", tačiau nesėkmingai.
Mūsų kompetencijos nepakanka, kad galėtume susidaryti minčių, kas tiksliai vyksta, apžiūrėdami minėtų tcp paketų, kurie atrodo taip, turinį:
19:45:27.839934 IP (tos 0x0, ttl 64, id 35746, offset 0, flags [DF], proto TCP (6), length 4100)
127.0.0.0.1.9051 > 127.0.0.0.1.46712: Flags [P.], cksum 0x0df9 (neteisingai -> 0xe713), seq 1543428574:1543432622, ack 1711981309, win 512, options [nop,nop,TS val 2971851406 ecr 2971851369], length 4048
E.....@[email protected]........#[.x[...f
.............
."...".i650 CIRC 9802 EXTENDED $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7B46F20449D6F25150E189428B62E1E3BA5848A9~galtlandeu,$BF93594384A02DE7689C4FD821E2638DA2CD4792~labaliseridicule BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19:45:22.060324
650 CIRC 9802 BUILT $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7B46F20449D6F25150E189428B62E1E3BA5848A9~galtlandeu,$BF93594384A02DE7689C4FD821E2638DA2CD4792~labaliseridicule BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19:45:22.060324
650 CIRC_MINOR 9802 PURPOSE_CHANGED $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7B46F20449D6F25150E189428B62E1E3BA5848A9~galtlandeu,$BF93594384A02DE7689C4FD821E2638DA2CD4792~labaliseridicule BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_JOINED REND_QUERY=|---------(užpuolė paslėptos paslaugos deskriptorių)---------| TIME_CREATED=2022-08-24T19:45:22.060324 OLD_PURPOSE=HS_SERVICE_REND OLD_HS_STATE=HSSR_CONNECTING
650 CIRC 9818 EXTENDED $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7A319C431F38CB30A0BC0C49144369A611920725~BahnhufPowah2,$8587A1B4CCD0700F164CCD588F79743C74FE8700~mev4PLicebeer16b BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19:45:22.493699
650 CIRC 9818 BUILT $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7A319C431F38CB30A0BC0C49144369A611920725~BahnhufPowah2,$8587A1B4CCD0700F164CCD588F79743C74FE8700~mev4PLicebeer16b BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19:45:22.493699
650 CIRC_MINOR 9818 PURPOSE_CHANGED $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7A319C431F38CB30A0BC0C49144369A611920725~BahnhufPowah2,$8587A1B4CCD0700F164CCD588F79743C74FE8700~mev4PLicebeer16b BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_JOINED REND_QUERY=|---------(užpuolė paslėptos paslaugos deskriptorių)---------| TIME_CREATED=2022-08-24T19:45:22.493699 OLD_PURPOSE=HS_SERVICE_REND OLD_HS_STATE=HSSR_CONNECTING
650 CIRC 9997 EXTENDED $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$8D896C8B367813030591A00DB7E7722EF6C4C23C~Luxembourg,$FF353F5D011E69ECDA10A57B46D06BC7B3FEB196~fuego,$347253D1D5246CB1C4CF8088C6982FE77CF7AB9C~ph3x,$E84F41FA1D1FA303FD7A99A35E50ACEF4269868C~Quetzalcoatl BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(užpuolė paslėptos paslaugos deskriptorių)---------| TIME_CREATED=2022-08-24T19:45:25.100429
650 CIRC 9997 BUILT $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$8D896C8B367813030591A00DB7E7722EF6C4C23C~Luxembourg,$FF353F5D011E69ECDA10A57B46D06BC7B3FEB196~fuego,$347253D1D5246CB1C4CF8088C6982FE77CF7AB9C~ph3x,$E84F41FA1D1FA303FD7A99A35E50ACEF4269868C~Quetzalcoatl BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(užpuolė paslėptos paslaugos deskriptorių)---------| TIME_CREATED=2022-08-24T19:45:25.10
Tai atliekama su "Tor", veikiančiu viename serveryje. Subalansavus |---------(atakavo paslėptos paslaugos deskriptorių)---------| pakeičiamas 2/3/4 serverio backendų paslaugų deskriptoriais.
Jei reikia, galime pateikti didesnę tcpdump ištrauką.
5. Išvados
Manome, kad priešininkas turi galimybę "nutraukti" paslėptos paslaugos deskriptorių (taigi ir pačią paslėptą paslaugą), užtvindydamas "Tor" demoną nesuskaičiuojamais tcp paketais, prašydamas sudaryti grandines. Būtent tai sukelia procesoriaus apkrovą ir galiausiai paverčia paslėptosios paslaugos aprašą netinkamu naudoti.
Ar kas nors gali tai patvirtinti?
Kadangi tokios direktyvos, kaip minėtos HiddenServiceEnableIntroDoSDefense, HiddenServiceEnableIntroDoSBurstPerSec ir HiddenServiceEnableIntroDoSRatePerSec, atrodo, skirtos apsisaugoti nuo tokio pobūdžio atakų, kaip turėtų apsisaugoti ir avangardai, negalime paaiškinti, kodėl jos lieka neveiksmingos. Galbūt reikia kokių nors labai specializuotų šių reikšmių nustatymų, kad jos būtų veiksmingos. Deja, šios direktyvos (kaip ir vanguards.config nustatymai) aprašytos tik aptakiai.
Ar kas nors žino, kaip jas reikia teisingai nustatyti, kad jos būtų veiksmingos?
Šiuo metu mes išnaudojome visas internete rastas nuorodas apie tor ir vanguards konfigūraciją.
Vėlgi, bet kokia pagalba ar informacija šiuo klausimu būtų labai dėkinga! Mes netikime, kad nėra jokio sprendimo.
Jei kas nors iš čia aprašyto jums atrodo prasminga ir (arba) įtariate, kas vyksta, bet koks atsiliepimas yra labai dėkingas!
1. Kas vyksta?
Mūsų paslauga ilgą laiką veikė gerai ir stabiliai. Staiga mūsų paslaugai atsirado iš pradžių lengvų, paskui sunkių našumo problemų, o vėliau ji tapo visiškai nepasiekiama.
Neatrodo, kad tai būtų "įprasta" DDoS ataka. Atrodo, kad tai DoS ataka, bet ne tokia, kaip kas nors žinoma, nes atrodo, kad tai ataka tik prieš "Tor" demoną. Visos iki šiol išbandytos atsakomosios priemonės buvo nesėkmingos. Nepastebėta jokios atakos prieš faktiškai veikiančias paslaugas (http, ssh, ftp, paštą ir t. t.), o tik prieš patį "Tor" ryšį.
Net ir sunkiai atlikome nuodugnų tyrimą ir tyrimą, atrodo, kad šis įvykis mums nesuprantamas. Dokumentų apie ankstesnes atakas prieš "Tor" paslėptąsias paslaugas galima rasti retai ir jie neturi prasmės tam, ką patiriame mes.
Atsisakome tikėti, kad egzistuoja nežinomas atakos scenarijus, kuriam neįmanoma pasipriešinti, nes dėl to kiekviena "Tor" paslėpta paslauga taptų pažeidžiama, o priešininkai galėtų per kelias minutes neribotam laikui savo nuožiūra išjungti bet kurią "Tor" paslėptą paslaugą. Poveikis "Tor" bendruomenei būtų neaprėpiamas.
Tikimės, kad kas nors, turintis reikiamų žinių ir patirties, gali mums bent užsiminti, kas tiksliai vyksta, ir nukreipti mus tinkama linkme, kad rastume sprendimą, kaip nutraukti šią ataką arba sumažinti jos poveikį mūsų sistemoms ir užkirsti kelią tokioms atakoms ateityje. Tai padėtų apsaugoti "Tor Hidden Services" visame pasaulyje nuo tokių atakų, kokią patyrėme dabar, ateityje.
2. Kokia yra sąranka?
- Sistema veikia dabartiniame ir visada atnaujintame "Linux" (amd64) serveryje
- Visas srautas nukreipiamas per "Tor" per "Tor Transport" 9040 prievadą, DNS užklausos taip pat sprendžiamos per "Tor".
- Paslėpta "Tor" paslauga yra v3
- Tor yra 0.4.7.8 versijos, veikianti su Libevent 2.1.12-stable, OpenSSL 1.1.1n, Zlib 1.2.11, Liblzma 5.2.5, Libzstd 1.4.8 ir Glibc 2.31 kaip libc
- Tor, sukompiliuotas naudojant GCC 10.2.1 versiją. Taip pat įdiegta Vanguards 0.3.1
- Tor veikia kaip systemd paslauga
- Vanguards veikia kaip systemd paslauga
Torrc konfigūracija:
CookieAuthentication 1
HashedControlPassword 16:<hash>
VirtualAddrNetworkIPv4 10.192.0.0.0/10
AutomapHostsOnResolve 1
TransPort 127.0.0.1:9040
DNSPort 127.0.0.1:53
HiddenServiceDir /var/lib/tor/hidden_service
HiddenServicePort 80 127.0.0.0.1:80
HiddenServiceVersion 3
HiddenServiceAllowUnknownPorts 0
3. Kokie yra simptomai?
- Praėjus mažiau nei minutei po "Tor" paleidimo su įjungta paslėpta paslauga, procesoriaus našumas pasiekia 100 %, atmintis atrodo nepaveikta.
- Naudojamas duomenų srauto pralaidumas padidėja apie 100 kb/s
- Paslėptosios paslaugos deskriptorius nepasiekiamas
- Sistema vis dar gali nustatyti "Clearnet" ir "Tor" adresus
- Sistema vis dar gali prisijungti prie išeinančių paslaugų (pvz., curl į svetainę)
- Sistema užtvindoma įeinančiais tcp paketais per kilpos sąsają
- Kai "Tor" paleidžiama iš naujo, užtvindymas kelioms sekundėms baigiasi, tada vėl prasideda
- Paleidus "Tor" be įjungtos paslėptos paslaugos, problemos nekyla
- Kai "Tor" paleidžiama su įjungta antrąja paslėpta paslauga, abu paslėptos paslaugos deskriptoriai lieka nepasiekiami:
Tor naršyklė pirminėje HS:
Tor: Tor: Tor: Tor: Onionsite Has Disconnected (Onionsite atsijungė)
Labiausiai tikėtina priežastis yra ta, kad onionsite yra atsijungusi. Kreipkitės į onionsite administratorių.
Išsami informacija: 0xF2 - Įvedimas nepavyko, o tai reiškia, kad deskriptorius buvo rastas, tačiau paslauga nebėra prijungta prie įvedimo taško. Tikėtina, kad paslauga pakeitė savo deskriptorių arba ji neveikia.
arba
Ryšys nutrūko
Serveris adresu (užpuolė paslėptas paslaugos deskriptorius).onion atsako per ilgai.
Gali būti, kad svetainė laikinai nepasiekiama arba yra per daug užimta. Pabandykite dar kartą po kelių akimirkų.
Tor naršyklė ant sekmadienio HS:
Nepavyksta prisijungti
Firefox negali užmegzti ryšio su serveriu adresu (Secondary hidden service descriptor).onion
Svetainė gali būti laikinai nepasiekiama arba per daug užimta. Pabandykite dar kartą po kelių akimirkų.
- Kai "Tor" paleidžiama su įjungta antrąja paslėpta paslauga, kuri yra apsaugota OnionAuthentication, pirminis paslėptos paslaugos deskriptorius lieka nepasiekiamas,
antrasis (apsaugotas) paslėptosios paslaugos deskriptorius yra pasiekiamas.
- Kai "Tor" paleidžiama tik su įjungta antrąja paslėpta paslauga (su OnionAuthentication arba be jos), atrodo, kad problemų nekyla.
- Kai "Tor" paleidžiama su pagrindine paslėpta paslauga, apsaugota "OnionAuthentication", paslėptos paslaugos deskriptorius yra pasiekiamas.
- Užpuolus Tor žurnalo faile atsiranda šie įrašai:
rugpjūčio 24 d. 19:42:18.000 [pranešimas] Įkrovimas atliktas 100% (baigta): Atlikta
Aug 24 19:42:34.000 [pranešimas] Panašu, kad pasikeitė jūsų tinklo ryšio greitis. Atstatomas timeout į 60000ms po 18 timeouts ir 388 buildtimes.
Aug 24 19:42:39.000 [pranešimas] Panašu, kad pasikeitė jūsų tinklo ryšio greitis. Iš naujo nustatomas 60000ms timeout po 18 timeouts ir 240 buildtimes.
Aug 24 19:42:53.000 [pranešimas] Panašu, kad pasikeitė jūsų tinklo ryšio greitis. Iš naujo nustatomas 60000ms timeout po 18 timeouts ir 489 buildtimes.
Aug 24 19:43:11.000 [pranešimas] Panašu, kad pasikeitė jūsų tinklo ryšio greitis. Iš naujo nustatomas 60000ms timeout po 18 timeouts ir 659 buildtimes.
...
Aug 24 19:46:09.000 [pranešimas] Itin didelė grandinės kūrimo laiko trukmės reikšmė: 122s. Darant prielaidą, kad laikrodžio šuolis. 14 tikslas (Matuoti grandinės trukmę)
Aug 24 19:46:09.000 [pranešimas] Itin didelė grandinės kūrimo laiko trukmės reikšmė: 122s. Daroma prielaida, kad laikrodžio šuolis. Tikslas 14 (Grandinės trukmės matavimas)
Aug 24 19:46:09.000 [pranešimas] Atrodo, kad pasikeitė jūsų tinklo ryšio greitis. Atstatomas timeout į 60000ms po 18 timeout ir 114 buildtimes.
Aug 24 19:46:15.000 [pranešimas] Panašu, kad pasikeitė jūsų tinklo ryšio greitis. Iš naujo nustatomas 60000ms timeout po 18 timeouts ir 125 buildtimes.
...
Aug 24 19:47:08.000 [pranešimas] Itin didelė grandinės kūrimo laiko trukmės reikšmė: 123s. Darant prielaidą, kad laikrodžio šuolis. 14 tikslas (Matuoti grandinės trukmę)
Aug 24 19:47:10.000 [pranešimas] Itin didelė grandinės kūrimo laiko trukmės reikšmė: 122s. Daroma prielaida, kad laikrodžio šuolis. Tikslas 14 (Grandinės trukmės matavimas)
Aug 24 19:47:10.000 [pranešimas] Itin didelė grandinės kūrimo laiko trukmės reikšmė: 123s. Daroma prielaida, kad laikrodžio šuolis. Tikslas 14 (Grandinės trukmės matavimas)
Aug 24 19:47:13.000 [pranešimas] Itin didelė grandinės kūrimo laiko reikšmė: 123s. Daroma prielaida, kad laikrodžio šuolis. Tikslas 14 (Grandinės trukmės matavimas)
Aug 24 19:47:14.000 [pranešimas] Atrodo, kad pasikeitė jūsų tinklo ryšio greitis. Atstatomas timeout į 60000ms po 18 timeout ir 495 buildtimes.
Aug 24 19:47:18.000 [pranešimas] Panašu, kad pasikeitė jūsų tinklo ryšio greitis. Iš naujo nustatomas 60000ms timeout po 18 timeouts ir 124 buildtimes.
Aug 24 19:47:21.000 [pranešimas] Itin didelė grandinės sukūrimo trukmės reikšmė: 122s. Daroma prielaida, kad laikrodžio šuolis. 14 tikslas (grandinės trukmės matavimas)
Aug 24 19:47:23.000 [pranešimas] Itin didelė grandinės kūrimo laiko trukmė: 123s. Daroma prielaida, kad laikrodžio šuolis. Tikslas 14 (Grandinės trukmės matavimas)
...
Aug 24 19:47:55.000 [pranešimas] Atrodo, kad pasikeitė jūsų tinklo ryšio greitis. Iš naujo nustatomas 60000ms timeout po 18 timeout ir 1000 buildtimes.
Aug 24 19:47:59.000 [pranešimas] Panašu, kad pasikeitė jūsų tinklo ryšio greitis. Iš naujo nustatomas 60000ms timeout po 18 timeouts ir 117 buildtimes.
...
Aug 24 19:52:43.000 [notice] Keista grandinės kūrimo laiko reikšmė: 121581msec. Darant prielaidą, kad laikrodžio šuolis. 14 paskirtis (grandinės trukmės matavimas)
Aug 24 19:52:43.000 [pranešimas] Panašu, kad pasikeitė jūsų tinklo ryšio greitis. Atstatoma laiko trukmė į 120000ms po 18 laiko trukmių ir 57 pastatymo laikų.
Aug 24 19:52:53.000 [pranešimas] Pertrauka: švarus išėjimas.
4. Kas buvo bandyta išspręsti problemą?
- Sukūrėme visiškai naują serverį nuo nulio, kuriame veikia tik bazinė OS, taip pat tor ir vanguards standartinės konfigūracijos, kad atmestume neteisingos konfigūracijos galimybę mūsų paveiktame serveryje. Vos tik paleidus tor su atakuojamu deskriptoriumi, vyksta lygiai tie patys dalykai.
- Šioje konfigūracijoje bandėme paskirstyti mūsų serverio apkrovą per "OnionBalance":
Serveris1: paleidžia Onionbalance pagrindiniam paslėptos paslaugos deskriptoriui
Serveris2/3/4: paleidžia paslėptąją paslaugą naujiems ir skirtingiems paslėptosios paslaugos deskriptoriams
- Dėl to pirminis paslėptosios paslaugos deskriptorius neatgaivinamas.
- Paslaugų deskriptoriai, esantys serveriuose 2/3/4, yra pasiekiami, kai atidaromi tiesiogiai, bet ne per dabar subalansuotą pagrindinį deskriptorių
- 2/3/4 serverių procesoriaus veikimas padidėja iki 100 %, kol vyksta ataka, o 1 serverio (balansavimo įrenginio) procesoriaus veikimas išlieka normalus
- Pridėjus daugiau pirminių serverių prie balansavimo įrenginio, tai taip pat nepadarė jokios įtakos
- Pridėjome šias direktyvas į paslėptų paslaugų bloką torrc ir išbandėme įvairius jų nustatymus:
HiddenServiceEnableIntroDoSDefense 1
HiddenServiceEnableIntroDoSBurstPerSec <išbandyta su įvairiomis reikšmėmis>
HiddenServiceEnableIntroDoSRatePerSec <išbandyta su įvairiomis reikšmėmis>
Tai gerokai sumažino procesoriaus apkrovą 2/3/4 serveriuose, tačiau subalansuotos paslaugos deskriptorius išlieka nepasiekiamas.
- Bandėme keisti įvairias vanguards.conf nuostatas, tačiau nesėkmingai.
- Bandėme identifikuoti atakuojančius tcp paketus ir juos blokuoti per "iptables", tačiau nesėkmingai.
Mūsų kompetencijos nepakanka, kad galėtume susidaryti minčių, kas tiksliai vyksta, apžiūrėdami minėtų tcp paketų, kurie atrodo taip, turinį:
19:45:27.839934 IP (tos 0x0, ttl 64, id 35746, offset 0, flags [DF], proto TCP (6), length 4100)
127.0.0.0.1.9051 > 127.0.0.0.1.46712: Flags [P.], cksum 0x0df9 (neteisingai -> 0xe713), seq 1543428574:1543432622, ack 1711981309, win 512, options [nop,nop,TS val 2971851406 ecr 2971851369], length 4048
E.....@[email protected]........#[.x[...f
.............
."...".i650 CIRC 9802 EXTENDED $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7B46F20449D6F25150E189428B62E1E3BA5848A9~galtlandeu,$BF93594384A02DE7689C4FD821E2638DA2CD4792~labaliseridicule BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19:45:22.060324
650 CIRC 9802 BUILT $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7B46F20449D6F25150E189428B62E1E3BA5848A9~galtlandeu,$BF93594384A02DE7689C4FD821E2638DA2CD4792~labaliseridicule BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19:45:22.060324
650 CIRC_MINOR 9802 PURPOSE_CHANGED $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7B46F20449D6F25150E189428B62E1E3BA5848A9~galtlandeu,$BF93594384A02DE7689C4FD821E2638DA2CD4792~labaliseridicule BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_JOINED REND_QUERY=|---------(užpuolė paslėptos paslaugos deskriptorių)---------| TIME_CREATED=2022-08-24T19:45:22.060324 OLD_PURPOSE=HS_SERVICE_REND OLD_HS_STATE=HSSR_CONNECTING
650 CIRC 9818 EXTENDED $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7A319C431F38CB30A0BC0C49144369A611920725~BahnhufPowah2,$8587A1B4CCD0700F164CCD588F79743C74FE8700~mev4PLicebeer16b BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19:45:22.493699
650 CIRC 9818 BUILT $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7A319C431F38CB30A0BC0C49144369A611920725~BahnhufPowah2,$8587A1B4CCD0700F164CCD588F79743C74FE8700~mev4PLicebeer16b BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19:45:22.493699
650 CIRC_MINOR 9818 PURPOSE_CHANGED $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7A319C431F38CB30A0BC0C49144369A611920725~BahnhufPowah2,$8587A1B4CCD0700F164CCD588F79743C74FE8700~mev4PLicebeer16b BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_JOINED REND_QUERY=|---------(užpuolė paslėptos paslaugos deskriptorių)---------| TIME_CREATED=2022-08-24T19:45:22.493699 OLD_PURPOSE=HS_SERVICE_REND OLD_HS_STATE=HSSR_CONNECTING
650 CIRC 9997 EXTENDED $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$8D896C8B367813030591A00DB7E7722EF6C4C23C~Luxembourg,$FF353F5D011E69ECDA10A57B46D06BC7B3FEB196~fuego,$347253D1D5246CB1C4CF8088C6982FE77CF7AB9C~ph3x,$E84F41FA1D1FA303FD7A99A35E50ACEF4269868C~Quetzalcoatl BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(užpuolė paslėptos paslaugos deskriptorių)---------| TIME_CREATED=2022-08-24T19:45:25.100429
650 CIRC 9997 BUILT $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$8D896C8B367813030591A00DB7E7722EF6C4C23C~Luxembourg,$FF353F5D011E69ECDA10A57B46D06BC7B3FEB196~fuego,$347253D1D5246CB1C4CF8088C6982FE77CF7AB9C~ph3x,$E84F41FA1D1FA303FD7A99A35E50ACEF4269868C~Quetzalcoatl BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(užpuolė paslėptos paslaugos deskriptorių)---------| TIME_CREATED=2022-08-24T19:45:25.10
Tai atliekama su "Tor", veikiančiu viename serveryje. Subalansavus |---------(atakavo paslėptos paslaugos deskriptorių)---------| pakeičiamas 2/3/4 serverio backendų paslaugų deskriptoriais.
Jei reikia, galime pateikti didesnę tcpdump ištrauką.
5. Išvados
Manome, kad priešininkas turi galimybę "nutraukti" paslėptos paslaugos deskriptorių (taigi ir pačią paslėptą paslaugą), užtvindydamas "Tor" demoną nesuskaičiuojamais tcp paketais, prašydamas sudaryti grandines. Būtent tai sukelia procesoriaus apkrovą ir galiausiai paverčia paslėptosios paslaugos aprašą netinkamu naudoti.
Ar kas nors gali tai patvirtinti?
Kadangi tokios direktyvos, kaip minėtos HiddenServiceEnableIntroDoSDefense, HiddenServiceEnableIntroDoSBurstPerSec ir HiddenServiceEnableIntroDoSRatePerSec, atrodo, skirtos apsisaugoti nuo tokio pobūdžio atakų, kaip turėtų apsisaugoti ir avangardai, negalime paaiškinti, kodėl jos lieka neveiksmingos. Galbūt reikia kokių nors labai specializuotų šių reikšmių nustatymų, kad jos būtų veiksmingos. Deja, šios direktyvos (kaip ir vanguards.config nustatymai) aprašytos tik aptakiai.
Ar kas nors žino, kaip jas reikia teisingai nustatyti, kad jos būtų veiksmingos?
Šiuo metu mes išnaudojome visas internete rastas nuorodas apie tor ir vanguards konfigūraciją.
Vėlgi, bet kokia pagalba ar informacija šiuo klausimu būtų labai dėkinga! Mes netikime, kad nėra jokio sprendimo.
Last edited:
