Vă mulțumim pentru că v-ați făcut timp să citiți acest text! Nu suntem experți în rețele Tor, dar știm să ne descurcăm.
Dacă ceva din ceea ce este descris aici are sens pentru dumneavoastră și/sau aveți o suspiciune cu privire la ceea ce se întâmplă, orice fel de feedback este extrem de apreciat!
1. Ce se întâmplă?
Serviciul nostru a funcționat bine și stabil pentru o lungă perioadă de timp. Dintr-o dată, serviciul nostru a întâmpinat probleme de performanță ușoare, apoi severe la început, apoi a devenit complet inaccesibil.
Acesta nu pare a fi un atac DDoS "obișnuit". Pare a fi un atac DoS, dar nu ca nimic cunoscut, deoarece pare a fi un atac doar asupra daemonului Tor. Toate contramăsurile pe care le-am încercat până acum nu au avut succes. Nu se observă niciun atac asupra serviciilor reale care rulează (http, ssh, ftp, mail etc.), ci doar asupra conexiunii Tor în sine.
Chiar dacă am făcut cercetări și investigații aprofundate, evenimentul pare să fie dincolo de înțelegerea noastră. Documentațiile privind atacurile anterioare asupra serviciilor ascunse Tor sunt rare și nu au sens în raport cu ceea ce experimentăm noi.
Refuzăm să credem că există un scenariu de atac care este necunoscut și care nu poate fi contracarat, deoarece ar face ca fiecare serviciu ascuns Tor să fie vulnerabil, adversarii fiind capabili să scoată orice serviciu ascuns Tor din funcțiune în câteva minute, pentru o perioadă nedeterminată. Impactul asupra comunității Tor ar fi fără margini.
Sperăm că cineva cu cunoștințele și expertiza necesare ne poate da măcar un indiciu despre ceea ce se întâmplă exact și ne poate îndruma în direcția corectă spre găsirea unei soluții pentru a pune capăt acestui atac sau pentru a reduce impactul acestuia asupra sistemelor noastre și pentru a preveni astfel de atacuri în viitor. Acest lucru ar ajuta la protejarea serviciilor ascunse Tor din întreaga lume de viitoare atacuri precum cel cu care ne confruntăm.
2. Care este configurația?
- Sistemul rulează pe un server linux (amd64) actual și mereu actualizat
- Tot traficul este direcționat prin Tor prin intermediul transportului Tor pe portul 9040, interogările DNS sunt rezolvate tot prin Tor
- Serviciul ascuns Tor este v3
- Tor este versiunea 0.4.7.8 care rulează cu Libevent 2.1.12-stable, OpenSSL 1.1.1n, Zlib 1.2.11, Liblzma 5.2.5, Libzstd 1.4.8 și Glibc 2.31 ca libc
- Tor compilat cu GCC versiunea 10.2.1. Vanguards 0.3.1 este de asemenea instalat
- Tor rulează ca serviciu systemd
- Vanguards rulează ca serviciu systemd
configurare torrc:
CookieAuthentication 1
HashedControlPassword 16:<hash>
VirtualAddrNetworkIPv4 10.192.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.1:80
HiddenServiceVersion 3
HiddenServiceAllowUnknownPorts 0
3. Care sunt simptomele?
- La mai puțin de un minut după pornirea Tor cu serviciul ascuns activat, CPU ajunge la 100%, memoria nu pare afectată
- Lățimea de bandă utilizată crește cu aproximativ 100kb/s
- Descriptorul serviciului ascuns este inaccesibil
- Sistemul poate rezolva în continuare adresele clearnet și Tor
- Sistemul se poate conecta în continuare la servicii de ieșire (de exemplu, curl la un site web)
- Sistemul este inundat cu pachete tcp de intrare pe interfața loopback
- Când Tor este repornit, fluxul se oprește pentru câteva secunde, apoi reîncepe
- Atunci când Tor este pornit fără serviciul ascuns activat, nu pare să existe nicio problemă
- Atunci când Tor este pornit cu un al doilea serviciu ascuns activat, ambii descriptori de servicii ascunse rămân inaccesibili:
Browser Tor pe HS primar:
Onionsite s-a deconectat
Cea mai probabilă cauză este că onionsite este offline. Contactați administratorul onionsite.
Detalii: 0xF2 - Introducerea a eșuat, ceea ce înseamnă că a fost găsit descriptorul, dar serviciul nu mai este conectat la punctul de introducere. Este probabil ca serviciul să își fi schimbat descriptorul sau să nu funcționeze.
sau
Conexiunea a expirat
Serverului de la (atacat descriptorul serviciului ascuns).onion îi ia prea mult timp să răspundă.
Site-ul ar putea fi temporar indisponibil sau prea ocupat. Încercați din nou în câteva momente.
Browser Tor pe Seconday HS:
Imposibilitatea de a se conecta
Firefox nu poate stabili o conexiune la serverul de la (descriptor de serviciu ascuns secundar).onion
Site-ul ar putea fi temporar indisponibil sau prea ocupat. Încercați din nou în câteva momente.
- Atunci când Tor este pornit cu un al doilea serviciu ascuns activat care este protejat de OnionAuthentication, Descriptorul serviciului ascuns principal rămâne inaccesibil,
Descriptorul serviciului ascuns secundar (protejat) este accesibil.
- Atunci când Tor este pornit doar cu al doilea serviciu ascuns activat (cu sau fără OnionAuthentication), nu pare să existe nicio problemă
- Atunci când Tor este pornit cu serviciul ascuns principal protejat de OnionAuthentication, Descriptorul serviciului ascuns este accesibil
- Atunci când este atacat, aceste intrări apar în fișierul jurnal tor:
Aug 24 19:42:18.000 [notice] Bootstrapped 100% (realizat): Done
Aug 24 19:42:34.000 [notice] Viteza conexiunii dvs. la rețea pare să se fi schimbat. Resetarea timeout-ului la 60000ms după 18 timeout-uri și 388 buildtimes.
Aug 24 19:42:39.000 [notice] Viteza conexiunii la rețea pare să se fi schimbat. Resetarea timeout-ului la 60000ms după 18 timeout-uri și 240 buildtimes.
Aug 24 19:42:53.000 [notice] Viteza conexiunii la rețea pare să se fi schimbat. Resetarea timeout-ului la 60000ms după 18 timeout-uri și 489 buildtimes.
Aug 24 19:43:11.000 [notice] Viteza conexiunii dvs. de rețea pare să se fi schimbat. Resetarea timeout-ului la 60000ms după 18 timeout-uri și 659 buildtimes.
...
Aug 24 19:46:09.000 [notice] Valoare extrem de mare pentru timeout-ul de construcție a circuitului: 122s. Presupunând un salt de ceas. Scopul 14 (Măsurarea timpului de expirare a circuitului)
Aug 24 19:46:09.000 [notice] Valoare extrem de mare pentru timeout-ul de construcție a circuitului: 122s. Presupunând salt de ceas. Scopul 14 (Măsurarea timeout-ului circuitului)
Aug 24 19:46:09.000 [notice] Viteza conexiunii dvs. de rețea pare să se fi schimbat. Resetarea timeout-ului la 60000ms după 18 timeout-uri și 114 buildtimes.
Aug 24 19:46:15.000 [notice] Viteza conexiunii la rețea pare să se fi schimbat. Resetarea timeout-ului la 60000ms după 18 timeout-uri și 125 buildtimes.
...
Aug 24 19:47:08.000 [notice] Valoare extrem de mare pentru timeout-ul de construcție a circuitului: 123s. Presupunând un salt de ceas. Scopul 14 (Măsurarea timpului de expirare a circuitului)
Aug 24 19:47:10.000 [notice] Valoare extrem de mare pentru timeout-ul de construcție a circuitului: 122s. Presupunând salt de ceas. Scopul 14 (Măsurarea timeout-ului circuitului)
Aug 24 19:47:10.000 [notice] Valoare extrem de mare pentru timeout-ul de construcție a circuitului: 123s. Presupunând salt de ceas. Scopul 14 (Măsurarea timeout-ului circuitului)
Aug 24 19:47:13.000 [notice] Valoare extrem de mare pentru timeout-ul de construcție a circuitului: 123s. Presupunând salt de ceas. Scopul 14 (Măsurarea timeout-ului circuitului)
Aug 24 19:47:14.000 [notice] Viteza conexiunii dvs. de rețea pare să se fi schimbat. Resetarea timeout-ului la 60000ms după 18 timeout-uri și 495 buildtimes.
Aug 24 19:47:18.000 [notice] Viteza conexiunii la rețea pare să se fi schimbat. Resetarea timeout-ului la 60000ms după 18 timeout-uri și 124 buildtimes.
Aug 24 19:47:21.000 [notice] Valoare extrem de mare pentru timeout-ul de construcție a circuitului: 122s. Presupunând un salt de ceas. Scopul 14 (Măsurarea timpului de expirare a circuitului)
Aug 24 19:47:23.000 [notice] Valoare extrem de mare pentru timeout-ul de construcție a circuitului: 123s. Presupunând salt de ceas. Scopul 14 (Măsurarea timeout-ului circuitului)
...
Aug 24 19:47:55.000 [notice] Viteza conexiunii dvs. de rețea pare să se fi schimbat. Resetarea timeout-ului la 60000ms după 18 timeout-uri și 1000 buildtimes.
Aug 24 19:47:59.000 [notice] Viteza conexiunii dvs. de rețea pare să se fi schimbat. Resetarea timeout-ului la 60000ms după 18 timeout-uri și 117 buildtimes.
...
Aug 24 19:52:43.000 [notice] Valoare ciudată pentru timpul de construcție al circuitului: 121581msec. Presupunând un salt de ceas. Scopul 14 (Măsurarea timpului de expirare a circuitului)
Aug 24 19:52:43.000 [notice] Viteza conexiunii dvs. de rețea pare să se fi schimbat. Resetarea timeout-ului la 120000ms după 18 timeout-uri și 57 buildtimes.
Aug 24 19:52:53.000 [notice] Întrerupere: ieșire curată.
4. Ce s-a încercat pentru a rezolva problema?
- Am configurat un server complet nou de la zero care rulează doar sistemul de operare de bază, precum și tor și vanguards în configurație standard pentru a exclude posibilitatea unei configurări greșite pe serverul nostru afectat. De îndată ce tor a fost pornit cu descriptorul atacat, se întâmplă exact aceleași lucruri.
- Am încercat să împărțim sarcina pe serverul nostru prin OnionBalance în această configurație:
Server1: Rulează Onionbalance pentru descriptorul principal al serviciului ascuns
Server2/3/4: Rulează serviciul ascuns pe descriptori de servicii ascunse noi și diferiți
- Acest lucru nu readuce la viață descriptorul original al serviciului ascuns
- Descriptorii de servicii de pe serverele 2/3/4 pot fi accesați atunci când sunt deschiși direct, dar nu prin intermediul descriptorului primar echilibrat în prezent
- CPU de pe serverele 2/3/4 ajunge la 100% atâta timp cât atacul are loc, în timp ce CPU de pe serverul 1 (balancer) rămâne normală
- Adăugarea mai multor servere backend la balancer nu a făcut nici o diferență
- Am adăugat aceste directive la blocul de servicii ascunse din torrc și am încercat diverse setări asupra lor:
HiddenServiceEnableIntroDoSDefense 1
HiddenServiceEnableIntroDoSBurstPerSec <testat cu diferite valori>
HiddenServiceEnableIntroDoSRatePerSec <testat cu diferite valori>
Acest lucru a redus semnificativ sarcina CPU pe serverele 2/3/4, dar descriptorul de serviciu echilibrat rămâne inaccesibil.
- Am încercat să schimbăm diverse setări în vanguards.conf, fără succes.
- Am încercat să identificăm pachetele tcp atacante și să le blocăm prin iptables, fără succes.
Expertiza noastră nu este suficientă pentru a trage idei despre ce se întâmplă exctely prin inspectarea conținutului pachetelor tcp menționate, care arată astfel:
19:45:27.839934 IP (tos 0x0, ttl 64, id 35746, offset 0, flags [DF], proto TCP (6), length 4100)
127.0.0.1.9051 > 127.0.0.1.46712: Flags [P.], cksum 0x0df9 (incorrect -> 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=|---------(atacat descriptorul serviciului ascuns)---------| 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=|---------(atacat descriptorul serviciului ascuns)---------| 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=|---------(atacat descriptorul serviciului ascuns)---------| 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=|---------(atacat descriptorul serviciului ascuns)---------| TIME_CREATED=2022-08-24T19:45:25.10
Acest lucru se întâmplă cu Tor care rulează pe un singur server. Atunci când este echilibrat, |---------(attacked hidden service descriptor)---------| este înlocuit de descriptorii de servicii backend ai serverelor 2/3/4.
Putem pune la dispoziție un fragment de tcpdump mai mare, dacă este necesar.
5. Concluzii
Credem că un adversar are capacitatea de a "întrerupe" un descriptor de serviciu ascuns (și, prin urmare, serviciul ascuns în sine) prin inundarea daemonului Tor cu nenumărate pachete tcp, solicitând construirea de circuite. Aceasta este ceea ce cauzează încărcarea CPU și, în cele din urmă, face ca Descriptorul serviciului ascuns să devină inutilizabil.
Poate cineva să confirme acest lucru?
Deoarece directivele precum HiddenServiceEnableIntroDoSDefense, HiddenServiceEnableIntroDoSBurstPerSec și HiddenServiceEnableIntroDoSRatePerSec par să fie menite să apere împotriva acestui tip de atacuri, la fel cum ar trebui să facă și avangardele, nu ne putem explica de ce acestea rămân ineficiente. Poate că sunt necesare unele setări foarte specializate ale acestor valori pentru a le face eficiente. Din păcate, aceste directive (precum și setările din vanguards.config) sunt descrise doar într-un mod vag.
Știe cineva, cum trebuie acestea să fie setate corect pentru a fi eficiente?
În acest moment am epuizat toate referințele privind tor și configurația vanguards pe care le-am putut găsi online.
Din nou, orice ajutor sau informații cu privire la această problemă ar fi foarte apreciat! Nu credem că nu există nicio soluție la această problemă.
Dacă ceva din ceea ce este descris aici are sens pentru dumneavoastră și/sau aveți o suspiciune cu privire la ceea ce se întâmplă, orice fel de feedback este extrem de apreciat!
1. Ce se întâmplă?
Serviciul nostru a funcționat bine și stabil pentru o lungă perioadă de timp. Dintr-o dată, serviciul nostru a întâmpinat probleme de performanță ușoare, apoi severe la început, apoi a devenit complet inaccesibil.
Acesta nu pare a fi un atac DDoS "obișnuit". Pare a fi un atac DoS, dar nu ca nimic cunoscut, deoarece pare a fi un atac doar asupra daemonului Tor. Toate contramăsurile pe care le-am încercat până acum nu au avut succes. Nu se observă niciun atac asupra serviciilor reale care rulează (http, ssh, ftp, mail etc.), ci doar asupra conexiunii Tor în sine.
Chiar dacă am făcut cercetări și investigații aprofundate, evenimentul pare să fie dincolo de înțelegerea noastră. Documentațiile privind atacurile anterioare asupra serviciilor ascunse Tor sunt rare și nu au sens în raport cu ceea ce experimentăm noi.
Refuzăm să credem că există un scenariu de atac care este necunoscut și care nu poate fi contracarat, deoarece ar face ca fiecare serviciu ascuns Tor să fie vulnerabil, adversarii fiind capabili să scoată orice serviciu ascuns Tor din funcțiune în câteva minute, pentru o perioadă nedeterminată. Impactul asupra comunității Tor ar fi fără margini.
Sperăm că cineva cu cunoștințele și expertiza necesare ne poate da măcar un indiciu despre ceea ce se întâmplă exact și ne poate îndruma în direcția corectă spre găsirea unei soluții pentru a pune capăt acestui atac sau pentru a reduce impactul acestuia asupra sistemelor noastre și pentru a preveni astfel de atacuri în viitor. Acest lucru ar ajuta la protejarea serviciilor ascunse Tor din întreaga lume de viitoare atacuri precum cel cu care ne confruntăm.
2. Care este configurația?
- Sistemul rulează pe un server linux (amd64) actual și mereu actualizat
- Tot traficul este direcționat prin Tor prin intermediul transportului Tor pe portul 9040, interogările DNS sunt rezolvate tot prin Tor
- Serviciul ascuns Tor este v3
- Tor este versiunea 0.4.7.8 care rulează cu Libevent 2.1.12-stable, OpenSSL 1.1.1n, Zlib 1.2.11, Liblzma 5.2.5, Libzstd 1.4.8 și Glibc 2.31 ca libc
- Tor compilat cu GCC versiunea 10.2.1. Vanguards 0.3.1 este de asemenea instalat
- Tor rulează ca serviciu systemd
- Vanguards rulează ca serviciu systemd
configurare torrc:
CookieAuthentication 1
HashedControlPassword 16:<hash>
VirtualAddrNetworkIPv4 10.192.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.1:80
HiddenServiceVersion 3
HiddenServiceAllowUnknownPorts 0
3. Care sunt simptomele?
- La mai puțin de un minut după pornirea Tor cu serviciul ascuns activat, CPU ajunge la 100%, memoria nu pare afectată
- Lățimea de bandă utilizată crește cu aproximativ 100kb/s
- Descriptorul serviciului ascuns este inaccesibil
- Sistemul poate rezolva în continuare adresele clearnet și Tor
- Sistemul se poate conecta în continuare la servicii de ieșire (de exemplu, curl la un site web)
- Sistemul este inundat cu pachete tcp de intrare pe interfața loopback
- Când Tor este repornit, fluxul se oprește pentru câteva secunde, apoi reîncepe
- Atunci când Tor este pornit fără serviciul ascuns activat, nu pare să existe nicio problemă
- Atunci când Tor este pornit cu un al doilea serviciu ascuns activat, ambii descriptori de servicii ascunse rămân inaccesibili:
Browser Tor pe HS primar:
Onionsite s-a deconectat
Cea mai probabilă cauză este că onionsite este offline. Contactați administratorul onionsite.
Detalii: 0xF2 - Introducerea a eșuat, ceea ce înseamnă că a fost găsit descriptorul, dar serviciul nu mai este conectat la punctul de introducere. Este probabil ca serviciul să își fi schimbat descriptorul sau să nu funcționeze.
sau
Conexiunea a expirat
Serverului de la (atacat descriptorul serviciului ascuns).onion îi ia prea mult timp să răspundă.
Site-ul ar putea fi temporar indisponibil sau prea ocupat. Încercați din nou în câteva momente.
Browser Tor pe Seconday HS:
Imposibilitatea de a se conecta
Firefox nu poate stabili o conexiune la serverul de la (descriptor de serviciu ascuns secundar).onion
Site-ul ar putea fi temporar indisponibil sau prea ocupat. Încercați din nou în câteva momente.
- Atunci când Tor este pornit cu un al doilea serviciu ascuns activat care este protejat de OnionAuthentication, Descriptorul serviciului ascuns principal rămâne inaccesibil,
Descriptorul serviciului ascuns secundar (protejat) este accesibil.
- Atunci când Tor este pornit doar cu al doilea serviciu ascuns activat (cu sau fără OnionAuthentication), nu pare să existe nicio problemă
- Atunci când Tor este pornit cu serviciul ascuns principal protejat de OnionAuthentication, Descriptorul serviciului ascuns este accesibil
- Atunci când este atacat, aceste intrări apar în fișierul jurnal tor:
Aug 24 19:42:18.000 [notice] Bootstrapped 100% (realizat): Done
Aug 24 19:42:34.000 [notice] Viteza conexiunii dvs. la rețea pare să se fi schimbat. Resetarea timeout-ului la 60000ms după 18 timeout-uri și 388 buildtimes.
Aug 24 19:42:39.000 [notice] Viteza conexiunii la rețea pare să se fi schimbat. Resetarea timeout-ului la 60000ms după 18 timeout-uri și 240 buildtimes.
Aug 24 19:42:53.000 [notice] Viteza conexiunii la rețea pare să se fi schimbat. Resetarea timeout-ului la 60000ms după 18 timeout-uri și 489 buildtimes.
Aug 24 19:43:11.000 [notice] Viteza conexiunii dvs. de rețea pare să se fi schimbat. Resetarea timeout-ului la 60000ms după 18 timeout-uri și 659 buildtimes.
...
Aug 24 19:46:09.000 [notice] Valoare extrem de mare pentru timeout-ul de construcție a circuitului: 122s. Presupunând un salt de ceas. Scopul 14 (Măsurarea timpului de expirare a circuitului)
Aug 24 19:46:09.000 [notice] Valoare extrem de mare pentru timeout-ul de construcție a circuitului: 122s. Presupunând salt de ceas. Scopul 14 (Măsurarea timeout-ului circuitului)
Aug 24 19:46:09.000 [notice] Viteza conexiunii dvs. de rețea pare să se fi schimbat. Resetarea timeout-ului la 60000ms după 18 timeout-uri și 114 buildtimes.
Aug 24 19:46:15.000 [notice] Viteza conexiunii la rețea pare să se fi schimbat. Resetarea timeout-ului la 60000ms după 18 timeout-uri și 125 buildtimes.
...
Aug 24 19:47:08.000 [notice] Valoare extrem de mare pentru timeout-ul de construcție a circuitului: 123s. Presupunând un salt de ceas. Scopul 14 (Măsurarea timpului de expirare a circuitului)
Aug 24 19:47:10.000 [notice] Valoare extrem de mare pentru timeout-ul de construcție a circuitului: 122s. Presupunând salt de ceas. Scopul 14 (Măsurarea timeout-ului circuitului)
Aug 24 19:47:10.000 [notice] Valoare extrem de mare pentru timeout-ul de construcție a circuitului: 123s. Presupunând salt de ceas. Scopul 14 (Măsurarea timeout-ului circuitului)
Aug 24 19:47:13.000 [notice] Valoare extrem de mare pentru timeout-ul de construcție a circuitului: 123s. Presupunând salt de ceas. Scopul 14 (Măsurarea timeout-ului circuitului)
Aug 24 19:47:14.000 [notice] Viteza conexiunii dvs. de rețea pare să se fi schimbat. Resetarea timeout-ului la 60000ms după 18 timeout-uri și 495 buildtimes.
Aug 24 19:47:18.000 [notice] Viteza conexiunii la rețea pare să se fi schimbat. Resetarea timeout-ului la 60000ms după 18 timeout-uri și 124 buildtimes.
Aug 24 19:47:21.000 [notice] Valoare extrem de mare pentru timeout-ul de construcție a circuitului: 122s. Presupunând un salt de ceas. Scopul 14 (Măsurarea timpului de expirare a circuitului)
Aug 24 19:47:23.000 [notice] Valoare extrem de mare pentru timeout-ul de construcție a circuitului: 123s. Presupunând salt de ceas. Scopul 14 (Măsurarea timeout-ului circuitului)
...
Aug 24 19:47:55.000 [notice] Viteza conexiunii dvs. de rețea pare să se fi schimbat. Resetarea timeout-ului la 60000ms după 18 timeout-uri și 1000 buildtimes.
Aug 24 19:47:59.000 [notice] Viteza conexiunii dvs. de rețea pare să se fi schimbat. Resetarea timeout-ului la 60000ms după 18 timeout-uri și 117 buildtimes.
...
Aug 24 19:52:43.000 [notice] Valoare ciudată pentru timpul de construcție al circuitului: 121581msec. Presupunând un salt de ceas. Scopul 14 (Măsurarea timpului de expirare a circuitului)
Aug 24 19:52:43.000 [notice] Viteza conexiunii dvs. de rețea pare să se fi schimbat. Resetarea timeout-ului la 120000ms după 18 timeout-uri și 57 buildtimes.
Aug 24 19:52:53.000 [notice] Întrerupere: ieșire curată.
4. Ce s-a încercat pentru a rezolva problema?
- Am configurat un server complet nou de la zero care rulează doar sistemul de operare de bază, precum și tor și vanguards în configurație standard pentru a exclude posibilitatea unei configurări greșite pe serverul nostru afectat. De îndată ce tor a fost pornit cu descriptorul atacat, se întâmplă exact aceleași lucruri.
- Am încercat să împărțim sarcina pe serverul nostru prin OnionBalance în această configurație:
Server1: Rulează Onionbalance pentru descriptorul principal al serviciului ascuns
Server2/3/4: Rulează serviciul ascuns pe descriptori de servicii ascunse noi și diferiți
- Acest lucru nu readuce la viață descriptorul original al serviciului ascuns
- Descriptorii de servicii de pe serverele 2/3/4 pot fi accesați atunci când sunt deschiși direct, dar nu prin intermediul descriptorului primar echilibrat în prezent
- CPU de pe serverele 2/3/4 ajunge la 100% atâta timp cât atacul are loc, în timp ce CPU de pe serverul 1 (balancer) rămâne normală
- Adăugarea mai multor servere backend la balancer nu a făcut nici o diferență
- Am adăugat aceste directive la blocul de servicii ascunse din torrc și am încercat diverse setări asupra lor:
HiddenServiceEnableIntroDoSDefense 1
HiddenServiceEnableIntroDoSBurstPerSec <testat cu diferite valori>
HiddenServiceEnableIntroDoSRatePerSec <testat cu diferite valori>
Acest lucru a redus semnificativ sarcina CPU pe serverele 2/3/4, dar descriptorul de serviciu echilibrat rămâne inaccesibil.
- Am încercat să schimbăm diverse setări în vanguards.conf, fără succes.
- Am încercat să identificăm pachetele tcp atacante și să le blocăm prin iptables, fără succes.
Expertiza noastră nu este suficientă pentru a trage idei despre ce se întâmplă exctely prin inspectarea conținutului pachetelor tcp menționate, care arată astfel:
19:45:27.839934 IP (tos 0x0, ttl 64, id 35746, offset 0, flags [DF], proto TCP (6), length 4100)
127.0.0.1.9051 > 127.0.0.1.46712: Flags [P.], cksum 0x0df9 (incorrect -> 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=|---------(atacat descriptorul serviciului ascuns)---------| 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=|---------(atacat descriptorul serviciului ascuns)---------| 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=|---------(atacat descriptorul serviciului ascuns)---------| 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=|---------(atacat descriptorul serviciului ascuns)---------| TIME_CREATED=2022-08-24T19:45:25.10
Acest lucru se întâmplă cu Tor care rulează pe un singur server. Atunci când este echilibrat, |---------(attacked hidden service descriptor)---------| este înlocuit de descriptorii de servicii backend ai serverelor 2/3/4.
Putem pune la dispoziție un fragment de tcpdump mai mare, dacă este necesar.
5. Concluzii
Credem că un adversar are capacitatea de a "întrerupe" un descriptor de serviciu ascuns (și, prin urmare, serviciul ascuns în sine) prin inundarea daemonului Tor cu nenumărate pachete tcp, solicitând construirea de circuite. Aceasta este ceea ce cauzează încărcarea CPU și, în cele din urmă, face ca Descriptorul serviciului ascuns să devină inutilizabil.
Poate cineva să confirme acest lucru?
Deoarece directivele precum HiddenServiceEnableIntroDoSDefense, HiddenServiceEnableIntroDoSBurstPerSec și HiddenServiceEnableIntroDoSRatePerSec par să fie menite să apere împotriva acestui tip de atacuri, la fel cum ar trebui să facă și avangardele, nu ne putem explica de ce acestea rămân ineficiente. Poate că sunt necesare unele setări foarte specializate ale acestor valori pentru a le face eficiente. Din păcate, aceste directive (precum și setările din vanguards.config) sunt descrise doar într-un mod vag.
Știe cineva, cum trebuie acestea să fie setate corect pentru a fi eficiente?
În acest moment am epuizat toate referințele privind tor și configurația vanguards pe care le-am putut găsi online.
Din nou, orice ajutor sau informații cu privire la această problemă ar fi foarte apreciat! Nu credem că nu există nicio soluție la această problemă.
Last edited:
