Tak, fordi du tog dig tid til at læse dette! Vi er ikke eksperter i Tor-netværk, men vi ved, hvad vi taler om.
Hvis noget af det, der er beskrevet her, giver mening for dig, og/eller du har en mistanke om, hvad der foregår, er enhver form for feedback yderst værdsat!
1. Hvad er det, der sker?
Vores tjeneste kørte fint og stabilt i lang tid. Pludselig oplevede vores tjeneste først lette, så alvorlige problemer med ydeevnen og blev derefter helt utilgængelig.
Det ser ikke ud til at være et "almindeligt" DDoS-angreb. Det ser ud til at være et DoS-angreb, men ikke som noget kendt, da det ser ud til at være et angreb på Tor-dæmonen alene. Alle modforanstaltninger, vi har prøvet indtil nu, har ikke virket. Der kan ikke ses noget angreb på de faktiske tjenester, der kører (http, ssh, ftp, mail osv.), men kun på selve Tor-forbindelsen.
Selv om vi har foretaget en grundig research og undersøgelse, synes hændelsen at ligge uden for vores fatteevne. Dokumentationer om tidligere angreb på Tor Hidden Services er sjældne at finde og giver ikke mening i forhold til det, vi oplever.
Vi nægter at tro, at der er et angrebsscenarie, som er ukendt og ikke kan modvirkes, da det ville gøre hver eneste skjulte Tor-tjeneste sårbar over for det, og modstandere ville kunne tage enhver skjult Tor-tjeneste offline efter ønske inden for få minutter og på ubestemt tid. Indvirkningen på Tor-fællesskabet ville være uoverskuelig.
Vi håber, at nogen med den nødvendige indsigt og ekspertise i det mindste kan give os et hint om, hvad der præcist foregår, og pege os i den rigtige retning mod at finde en løsning til at af*****te dette angreb eller reducere dets indvirkning på vores systemer og for at forhindre sådanne angreb i fremtiden. Det vil hjælpe med at beskytte Tor Hidden Services over hele verden mod fremtidige angreb som det, vi oplever.
2. Hvad er opsætningen?
- Systemet kører på en aktuel og altid opdateret linux (amd64)-server
- Al trafik dirigeres gennem Tor via Tor-transport på port 9040, og DNS-forespørgsler løses også via Tor.
- Den skjulte Tor-tjeneste er v3
- Tor er version 0.4.7.8, der kører med Libevent 2.1.12-stable, OpenSSL 1.1.1n, Zlib 1.2.11, Liblzma 5.2.5, Libzstd 1.4.8 og Glibc 2.31 som libc.
- Tor kompileret med GCC version 10.2.1. Vanguards 0.3.1 er også installeret.
- Tor kører som en systemd-tjeneste
- Vanguards kører som systemd-tjeneste
torrc-konfiguration:
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. Hvad er symptomerne?
- Mindre end et minut efter start af Tor med Hidden Service aktiveret når *****U'en op på 100 %, hukommelsen virker upåvirket.
- Brugt båndbredde stiger til omkring 100 kb/s
- Deskriptoren for den skjulte tjeneste er utilgængelig
- Systemet kan stadig løse clearnet- og Tor-adresser
- Systemet kan stadig oprette forbindelse til udgående tjenester (f.eks. curl til en hjemmeside)
- Systemet bliver oversvømmet med indgående t*****-pakker på loopback-grænsefladen
- Når Tor genstartes, stopper oversvømmelsen i et par sekunder og starter derefter igen.
- Når Tor startes uden den skjulte tjeneste aktiveret, ser der ikke ud til at være noget problem
- Når Tor startes med en anden Hidden Service aktiveret, forbliver begge Hidden Service Descriptors utilgængelige:
Tor-browser på primær HS:
Onionsite har afbrudt forbindelsen
Den mest sandsynlige årsag er, at onionsite er offline. Kontakt onionsite-administratoren.
Detaljerede oplysninger: 0xF2 - Introduktionen mislykkedes, hvilket betyder, at deskriptoren blev fundet, men at tjenesten ikke længere er forbundet til introduktionspunktet. Det er sandsynligt, at tjenesten har ændret sin deskriptor, eller at den ikke kører.
eller
Forbindelsen er gået i stå
Serveren på (attacked hidden service descriptor).torify.net er for længe om at svare.
Webstedet kan være midlertidigt utilgængeligt eller for travlt. Prøv igen om et øjeblik.
Tor Browser på Seconday HS:
Kan ikke oprette forbindelse
Firefox kan ikke etablere en forbindelse til serveren på (secondary hidden service descriptor).torify.net
Webstedet kan være midlertidigt utilgængeligt eller for travlt. Prøv igen om et øjeblik.
- Når Tor startes med en anden skjult tjeneste aktiveret, som er beskyttet af OnionAuthentication, forbliver den primære skjulte tjenestebeskriver utilgængelig,
den sekundære (beskyttede) Hidden Service Descriptor kan nås.
- Når Tor startes med kun den anden skjulte tjeneste aktiveret (med eller uden OnionAuthentication), ser der ikke ud til at være noget problem.
- Når Tor startes med den primære skjulte tjeneste beskyttet af OnionAuthentication, kan den skjulte tjenestebeskrivelser nås.
- Når den angribes, vises disse poster i tor-logfilen:
Aug 24 19:42:18.000 [notice] Bootstrapped 100% (done): Færdig
Aug 24 19:42:34.000 [notice] Hastigheden på din netværksforbindelse ser ud til at have ændret sig. Nulstiller timeout til 60000 ms efter 18 timeouts og 388 buildtimes.
Aug 24 19:42:39.000 [notice] Hastigheden på din netværksforbindelse ser ud til at have ændret sig. Nulstiller timeout til 60000 ms efter 18 timeouts og 240 buildtimes.
Aug 24 19:42:53.000 [notice] Hastigheden på din netværksforbindelse ser ud til at have ændret sig. Nulstiller timeout til 60000ms efter 18 timeouts og 489 buildtimes.
Aug 24 19:43:11.000 [notice] Hastigheden på din netværksforbindelse ser ud til at have ændret sig. Nulstiller timeout til 60000 ms efter 18 timeouts og 659 buildtimes.
...
Aug 24 19:46:09.000 [notice] Ekstremt stor værdi for timeout for kredsløbsopbygning: 122s. Antager, at uret springer. Formål 14 (Måling af kredsløbstimeout)
Aug 24 19:46:09.000 [notice] Ekstremt stor værdi for timeout for kredsløbsopbygning: 122s. Antager, at uret springer. Formål 14 (Måling af timeout for kredsløb)
Aug 24 19:46:09.000 [notice] Hastigheden på din netværksforbindelse ser ud til at have ændret sig. Nulstiller timeout til 60000 ms efter 18 timeouts og 114 buildtimes.
Aug 24 19:46:15.000 [notice] Hastigheden på din netværksforbindelse ser ud til at have ændret sig. Nulstiller timeout til 60000 ms efter 18 timeouts og 125 buildtimes.
...
Aug 24 19:47:08.000 [notice] Ekstremt stor værdi for timeout for kredsløbsopbygning: 123s. Antager, at uret springer. Formål 14 (Måling af kredsløbstimeout)
Aug 24 19:47:10.000 [notice] Ekstremt stor værdi for timeout for kredsløbsopbygning: 122s. Antager, at uret springer. Formål 14 (Måling af timeout for kredsløb)
Aug 24 19:47:10.000 [notice] Ekstremt stor værdi for timeout for kredsløbsopbygning: 123s. Antager, at uret springer. Formål 14 (Måling af timeout for kredsløb)
Aug 24 19:47:13.000 [notice] Ekstremt stor værdi for timeout for kredsløbsopbygning: 123s. Antager, at uret springer. Formål 14 (Måling af timeout for kredsløb)
Aug 24 19:47:14.000 [notice] Hastigheden på din netværksforbindelse ser ud til at have ændret sig. Nulstiller timeout til 60000 ms efter 18 timeouts og 495 buildtimes.
Aug 24 19:47:18.000 [notice] Hastigheden på din netværksforbindelse ser ud til at have ændret sig. Nulstiller timeout til 60000 ms efter 18 timeouts og 124 buildtimes.
Aug 24 19:47:21.000 [notice] Ekstremt stor værdi for timeout for kredsløbsopbygning: 122s. Antager, at uret springer. Formål 14 (Måling af kredsløbstimeout)
Aug 24 19:47:23.000 [notice] Ekstremt stor værdi for timeout for kredsløbsopbygning: 123s. Antager, at uret springer. Formål 14 (Måling af timeout for kredsløb)
...
Aug 24 19:47:55.000 [notice] Hastigheden på din netværksforbindelse ser ud til at have ændret sig. Nulstiller timeout til 60000 ms efter 18 timeouts og 1000 buildtimes.
Aug 24 19:47:59.000 [notice] Hastigheden på din netværksforbindelse ser ud til at have ændret sig. Nulstiller timeout til 60000 ms efter 18 timeouts og 117 buildtimes.
...
Aug 24 19:52:43.000 [notice] Mærkelig værdi for kredsløbets opbygningstid: 121581msec. Antager, at uret springer. Formål 14 (Måling af kredsløbstimeout)
Aug 24 19:52:43.000 [notice] Hastigheden på din netværksforbindelse ser ud til at have ændret sig. Nulstiller timeout til 120000 ms efter 18 timeouts og 57 buildtimes.
Aug 24 19:52:53.000 [notice] Afbrydelse: af*****ter rent.
4. Hvad blev forsøgt for at løse problemet?
- Vi satte en helt ny server op fra bunden, der kun kørte basic OS samt tor og vanguards i standardkonfiguration for at udelukke muligheden for en fejlkonfiguration på vores berørte server. Så snart tor blev startet med den angrebne descriptor, skete præcis de samme ting.
- Vi forsøgte at opdele belastningen på vores server via OnionBalance i denne opsætning:
Server1: Kører Onionbalance for den primære Hidden Service Descriptor
Server2/3/4: Kører den skjulte tjeneste på nye og forskellige skjulte tjenestebeskrivelser
- Dette bringer ikke den oprindelige Hidden Service Descriptor til live igen
- Servicebeskrivelserne på serverne 2/3/4 kan nås, når de åbnes direkte, men ikke via den nu afbalancerede primære beskrivelse
- *****U'en på server 2/3/4 går til 100 %, så længe angrebet finder sted, mens *****U'en på server 1 (balanceren) forbliver normal.
- At tilføje flere backend-servere til balanceren gjorde heller ikke nogen forskel
- Vi tilføjede disse direktiver til den skjulte serviceblok i torrc og prøvede forskellige indstillinger på dem:
HiddenServiceEnableIntroDoSDefense 1
HiddenServiceEnableIntroDoSBurstPerSec <testet med forskellige værdier>
HiddenServiceEnableIntroDoSRatePerSec <testet med forskellige værdier>.
Dette reducerede *****U-belastningen betydeligt på server 2/3/4, men den afbalancerede servicebeskrivelse er fortsat utilgængelig.
- Vi forsøgte at ændre forskellige indstillinger i vanguards.conf, men uden held.
- Vi forsøgte at identificere de angribende t*****-pakker og få dem blokeret via iptables, men uden held.
Vores ekspertise er ikke tilstrækkelig til at få ideer om, hvad der præcist sker, ved at inspicere indholdet af de nævnte t*****-pakker, som ser sådan her ud:
19:45:27.839934 IP (tos 0x0, ttl 64, id 35746, offset 0, flags [DF], proto T***** (6), length 4100)
127.0.0.1.9051 > 127.0.0.1.46712: Flags [P.], cksum 0x0df9 (forkert -> 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=|---------(attacked hidden service descriptor)---------| 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=|---------(attacked hidden service descriptor)---------| 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=|---------(attacked hidden service descriptor)---------| 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=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19:45:25.10
Dette er med Tor kørende på en enkelt server. Når det er afbalanceret, erstattes |---------(attacked hidden service descriptor)---------| af backends servicebeskrivelser på server 2/3/4.
Vi kan stille et større t*****dump-uddrag til rådighed, hvis det er nødvendigt.
5. Konklusioner
Vi tror, at en modstander har mulighed for at "afbryde" en Hidden Service Descriptor (og dermed selve Hidden Service) ved at oversvømme Tor-dæmonen med utallige t*****-pakker, der anmoder om at bygge kredsløb. Det er det, der forårsager *****U-belastningen og i sidste ende gør Hidden Service Descriptor ubrugelig.
Kan nogen bekræfte dette?
Da direktiver som de nævnte HiddenServiceEnableIntroDoSDefense, HiddenServiceEnableIntroDoSBurstPerSec og HiddenServiceEnableIntroDoSRatePerSec ser ud til at være beregnet til at forsvare sig mod denne slags angreb, ligesom vanguards også burde, kan vi ikke forklare, hvorfor de forbliver ineffektive. Måske er det nødvendigt med nogle meget specialiserede indstillinger af disse værdier for at gøre dem effektive. Desværre er disse direktiver (såvel som indstillingerne i vanguards.config) kun beskrevet på en vag måde.
Er der nogen, der ved, hvordan de skal indstilles korrekt for at være effektive?
På dette tidspunkt har vi udtømt alle henvisninger til tor og vanguards-konfiguration, som vi kunne finde på nettet.
Igen, enhver hjælp eller information om dette problem vil blive meget værdsat! Vi tror ikke, at der er nogen løsning på dette.
Hvis noget af det, der er beskrevet her, giver mening for dig, og/eller du har en mistanke om, hvad der foregår, er enhver form for feedback yderst værdsat!
1. Hvad er det, der sker?
Vores tjeneste kørte fint og stabilt i lang tid. Pludselig oplevede vores tjeneste først lette, så alvorlige problemer med ydeevnen og blev derefter helt utilgængelig.
Det ser ikke ud til at være et "almindeligt" DDoS-angreb. Det ser ud til at være et DoS-angreb, men ikke som noget kendt, da det ser ud til at være et angreb på Tor-dæmonen alene. Alle modforanstaltninger, vi har prøvet indtil nu, har ikke virket. Der kan ikke ses noget angreb på de faktiske tjenester, der kører (http, ssh, ftp, mail osv.), men kun på selve Tor-forbindelsen.
Selv om vi har foretaget en grundig research og undersøgelse, synes hændelsen at ligge uden for vores fatteevne. Dokumentationer om tidligere angreb på Tor Hidden Services er sjældne at finde og giver ikke mening i forhold til det, vi oplever.
Vi nægter at tro, at der er et angrebsscenarie, som er ukendt og ikke kan modvirkes, da det ville gøre hver eneste skjulte Tor-tjeneste sårbar over for det, og modstandere ville kunne tage enhver skjult Tor-tjeneste offline efter ønske inden for få minutter og på ubestemt tid. Indvirkningen på Tor-fællesskabet ville være uoverskuelig.
Vi håber, at nogen med den nødvendige indsigt og ekspertise i det mindste kan give os et hint om, hvad der præcist foregår, og pege os i den rigtige retning mod at finde en løsning til at af*****te dette angreb eller reducere dets indvirkning på vores systemer og for at forhindre sådanne angreb i fremtiden. Det vil hjælpe med at beskytte Tor Hidden Services over hele verden mod fremtidige angreb som det, vi oplever.
2. Hvad er opsætningen?
- Systemet kører på en aktuel og altid opdateret linux (amd64)-server
- Al trafik dirigeres gennem Tor via Tor-transport på port 9040, og DNS-forespørgsler løses også via Tor.
- Den skjulte Tor-tjeneste er v3
- Tor er version 0.4.7.8, der kører med Libevent 2.1.12-stable, OpenSSL 1.1.1n, Zlib 1.2.11, Liblzma 5.2.5, Libzstd 1.4.8 og Glibc 2.31 som libc.
- Tor kompileret med GCC version 10.2.1. Vanguards 0.3.1 er også installeret.
- Tor kører som en systemd-tjeneste
- Vanguards kører som systemd-tjeneste
torrc-konfiguration:
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. Hvad er symptomerne?
- Mindre end et minut efter start af Tor med Hidden Service aktiveret når *****U'en op på 100 %, hukommelsen virker upåvirket.
- Brugt båndbredde stiger til omkring 100 kb/s
- Deskriptoren for den skjulte tjeneste er utilgængelig
- Systemet kan stadig løse clearnet- og Tor-adresser
- Systemet kan stadig oprette forbindelse til udgående tjenester (f.eks. curl til en hjemmeside)
- Systemet bliver oversvømmet med indgående t*****-pakker på loopback-grænsefladen
- Når Tor genstartes, stopper oversvømmelsen i et par sekunder og starter derefter igen.
- Når Tor startes uden den skjulte tjeneste aktiveret, ser der ikke ud til at være noget problem
- Når Tor startes med en anden Hidden Service aktiveret, forbliver begge Hidden Service Descriptors utilgængelige:
Tor-browser på primær HS:
Onionsite har afbrudt forbindelsen
Den mest sandsynlige årsag er, at onionsite er offline. Kontakt onionsite-administratoren.
Detaljerede oplysninger: 0xF2 - Introduktionen mislykkedes, hvilket betyder, at deskriptoren blev fundet, men at tjenesten ikke længere er forbundet til introduktionspunktet. Det er sandsynligt, at tjenesten har ændret sin deskriptor, eller at den ikke kører.
eller
Forbindelsen er gået i stå
Serveren på (attacked hidden service descriptor).torify.net er for længe om at svare.
Webstedet kan være midlertidigt utilgængeligt eller for travlt. Prøv igen om et øjeblik.
Tor Browser på Seconday HS:
Kan ikke oprette forbindelse
Firefox kan ikke etablere en forbindelse til serveren på (secondary hidden service descriptor).torify.net
Webstedet kan være midlertidigt utilgængeligt eller for travlt. Prøv igen om et øjeblik.
- Når Tor startes med en anden skjult tjeneste aktiveret, som er beskyttet af OnionAuthentication, forbliver den primære skjulte tjenestebeskriver utilgængelig,
den sekundære (beskyttede) Hidden Service Descriptor kan nås.
- Når Tor startes med kun den anden skjulte tjeneste aktiveret (med eller uden OnionAuthentication), ser der ikke ud til at være noget problem.
- Når Tor startes med den primære skjulte tjeneste beskyttet af OnionAuthentication, kan den skjulte tjenestebeskrivelser nås.
- Når den angribes, vises disse poster i tor-logfilen:
Aug 24 19:42:18.000 [notice] Bootstrapped 100% (done): Færdig
Aug 24 19:42:34.000 [notice] Hastigheden på din netværksforbindelse ser ud til at have ændret sig. Nulstiller timeout til 60000 ms efter 18 timeouts og 388 buildtimes.
Aug 24 19:42:39.000 [notice] Hastigheden på din netværksforbindelse ser ud til at have ændret sig. Nulstiller timeout til 60000 ms efter 18 timeouts og 240 buildtimes.
Aug 24 19:42:53.000 [notice] Hastigheden på din netværksforbindelse ser ud til at have ændret sig. Nulstiller timeout til 60000ms efter 18 timeouts og 489 buildtimes.
Aug 24 19:43:11.000 [notice] Hastigheden på din netværksforbindelse ser ud til at have ændret sig. Nulstiller timeout til 60000 ms efter 18 timeouts og 659 buildtimes.
...
Aug 24 19:46:09.000 [notice] Ekstremt stor værdi for timeout for kredsløbsopbygning: 122s. Antager, at uret springer. Formål 14 (Måling af kredsløbstimeout)
Aug 24 19:46:09.000 [notice] Ekstremt stor værdi for timeout for kredsløbsopbygning: 122s. Antager, at uret springer. Formål 14 (Måling af timeout for kredsløb)
Aug 24 19:46:09.000 [notice] Hastigheden på din netværksforbindelse ser ud til at have ændret sig. Nulstiller timeout til 60000 ms efter 18 timeouts og 114 buildtimes.
Aug 24 19:46:15.000 [notice] Hastigheden på din netværksforbindelse ser ud til at have ændret sig. Nulstiller timeout til 60000 ms efter 18 timeouts og 125 buildtimes.
...
Aug 24 19:47:08.000 [notice] Ekstremt stor værdi for timeout for kredsløbsopbygning: 123s. Antager, at uret springer. Formål 14 (Måling af kredsløbstimeout)
Aug 24 19:47:10.000 [notice] Ekstremt stor værdi for timeout for kredsløbsopbygning: 122s. Antager, at uret springer. Formål 14 (Måling af timeout for kredsløb)
Aug 24 19:47:10.000 [notice] Ekstremt stor værdi for timeout for kredsløbsopbygning: 123s. Antager, at uret springer. Formål 14 (Måling af timeout for kredsløb)
Aug 24 19:47:13.000 [notice] Ekstremt stor værdi for timeout for kredsløbsopbygning: 123s. Antager, at uret springer. Formål 14 (Måling af timeout for kredsløb)
Aug 24 19:47:14.000 [notice] Hastigheden på din netværksforbindelse ser ud til at have ændret sig. Nulstiller timeout til 60000 ms efter 18 timeouts og 495 buildtimes.
Aug 24 19:47:18.000 [notice] Hastigheden på din netværksforbindelse ser ud til at have ændret sig. Nulstiller timeout til 60000 ms efter 18 timeouts og 124 buildtimes.
Aug 24 19:47:21.000 [notice] Ekstremt stor værdi for timeout for kredsløbsopbygning: 122s. Antager, at uret springer. Formål 14 (Måling af kredsløbstimeout)
Aug 24 19:47:23.000 [notice] Ekstremt stor værdi for timeout for kredsløbsopbygning: 123s. Antager, at uret springer. Formål 14 (Måling af timeout for kredsløb)
...
Aug 24 19:47:55.000 [notice] Hastigheden på din netværksforbindelse ser ud til at have ændret sig. Nulstiller timeout til 60000 ms efter 18 timeouts og 1000 buildtimes.
Aug 24 19:47:59.000 [notice] Hastigheden på din netværksforbindelse ser ud til at have ændret sig. Nulstiller timeout til 60000 ms efter 18 timeouts og 117 buildtimes.
...
Aug 24 19:52:43.000 [notice] Mærkelig værdi for kredsløbets opbygningstid: 121581msec. Antager, at uret springer. Formål 14 (Måling af kredsløbstimeout)
Aug 24 19:52:43.000 [notice] Hastigheden på din netværksforbindelse ser ud til at have ændret sig. Nulstiller timeout til 120000 ms efter 18 timeouts og 57 buildtimes.
Aug 24 19:52:53.000 [notice] Afbrydelse: af*****ter rent.
4. Hvad blev forsøgt for at løse problemet?
- Vi satte en helt ny server op fra bunden, der kun kørte basic OS samt tor og vanguards i standardkonfiguration for at udelukke muligheden for en fejlkonfiguration på vores berørte server. Så snart tor blev startet med den angrebne descriptor, skete præcis de samme ting.
- Vi forsøgte at opdele belastningen på vores server via OnionBalance i denne opsætning:
Server1: Kører Onionbalance for den primære Hidden Service Descriptor
Server2/3/4: Kører den skjulte tjeneste på nye og forskellige skjulte tjenestebeskrivelser
- Dette bringer ikke den oprindelige Hidden Service Descriptor til live igen
- Servicebeskrivelserne på serverne 2/3/4 kan nås, når de åbnes direkte, men ikke via den nu afbalancerede primære beskrivelse
- *****U'en på server 2/3/4 går til 100 %, så længe angrebet finder sted, mens *****U'en på server 1 (balanceren) forbliver normal.
- At tilføje flere backend-servere til balanceren gjorde heller ikke nogen forskel
- Vi tilføjede disse direktiver til den skjulte serviceblok i torrc og prøvede forskellige indstillinger på dem:
HiddenServiceEnableIntroDoSDefense 1
HiddenServiceEnableIntroDoSBurstPerSec <testet med forskellige værdier>
HiddenServiceEnableIntroDoSRatePerSec <testet med forskellige værdier>.
Dette reducerede *****U-belastningen betydeligt på server 2/3/4, men den afbalancerede servicebeskrivelse er fortsat utilgængelig.
- Vi forsøgte at ændre forskellige indstillinger i vanguards.conf, men uden held.
- Vi forsøgte at identificere de angribende t*****-pakker og få dem blokeret via iptables, men uden held.
Vores ekspertise er ikke tilstrækkelig til at få ideer om, hvad der præcist sker, ved at inspicere indholdet af de nævnte t*****-pakker, som ser sådan her ud:
19:45:27.839934 IP (tos 0x0, ttl 64, id 35746, offset 0, flags [DF], proto T***** (6), length 4100)
127.0.0.1.9051 > 127.0.0.1.46712: Flags [P.], cksum 0x0df9 (forkert -> 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=|---------(attacked hidden service descriptor)---------| 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=|---------(attacked hidden service descriptor)---------| 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=|---------(attacked hidden service descriptor)---------| 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=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19:45:25.10
Dette er med Tor kørende på en enkelt server. Når det er afbalanceret, erstattes |---------(attacked hidden service descriptor)---------| af backends servicebeskrivelser på server 2/3/4.
Vi kan stille et større t*****dump-uddrag til rådighed, hvis det er nødvendigt.
5. Konklusioner
Vi tror, at en modstander har mulighed for at "afbryde" en Hidden Service Descriptor (og dermed selve Hidden Service) ved at oversvømme Tor-dæmonen med utallige t*****-pakker, der anmoder om at bygge kredsløb. Det er det, der forårsager *****U-belastningen og i sidste ende gør Hidden Service Descriptor ubrugelig.
Kan nogen bekræfte dette?
Da direktiver som de nævnte HiddenServiceEnableIntroDoSDefense, HiddenServiceEnableIntroDoSBurstPerSec og HiddenServiceEnableIntroDoSRatePerSec ser ud til at være beregnet til at forsvare sig mod denne slags angreb, ligesom vanguards også burde, kan vi ikke forklare, hvorfor de forbliver ineffektive. Måske er det nødvendigt med nogle meget specialiserede indstillinger af disse værdier for at gøre dem effektive. Desværre er disse direktiver (såvel som indstillingerne i vanguards.config) kun beskrevet på en vag måde.
Er der nogen, der ved, hvordan de skal indstilles korrekt for at være effektive?
På dette tidspunkt har vi udtømt alle henvisninger til tor og vanguards-konfiguration, som vi kunne finde på nettet.
Igen, enhver hjælp eller information om dette problem vil blive meget værdsat! Vi tror ikke, at der er nogen løsning på dette.
Last edited:
