Tack för att du tog dig tid att läsa det här! Vi är inga experter på Tor-nätverk, men vi känner till hur det fungerar.
Om något av det som beskrivs här verkar vettigt för dig och/eller om du har en misstanke om vad som pågår, är all form av feedback mycket uppskattad!
1. Vad är det som har hänt?
Vår tjänst har fungerat bra och stabilt under en längre tid. Plötsligt upplevde vår tjänst först lätta, sedan allvarliga prestandaproblem och blev sedan helt oåtkomlig.
Detta verkar inte vara en "vanlig" DDoS-attack. Det verkar vara en DoS-attack, men inte som något annat känt, eftersom det verkar vara en attack enbart mot Tor-daemon. Alla motåtgärder som vi har försökt hittills har inte lyckats. Det finns ingen attack märkbar på de faktiska tjänster som körs (http, ssh, ftp, mail, etc.) utan bara på själva Tor-anslutningen.
Även om vi gjorde en djupgående forskning och undersökning verkar händelsen vara bortom vår förståelse. Dokumentationer om tidigare attacker mot Tor Hidden Services är sällsynta att hitta och stämmer inte överens med det vi upplever.
Vi vägrar att tro att det finns ett angreppsscenario som är okänt och inte kan motverkas eftersom det skulle göra varje enskild dold Tor-tjänst sårbar för det med motståndare som kan ta vilken dold Tor-tjänst som helst offline efter behag inom några minuter på obestämd tid. Konsekvenserna för Tor-communityn skulle vara oöverskådliga.
Vi hoppas att någon med nödvändig insikt och expertis åtminstone kan ge oss en ledtråd om vad som exakt händer och peka oss i rätt riktning mot att hitta en lösning för att avsluta denna attack eller minska dess inverkan på våra system och för att förhindra sådana attacker i framtiden. Detta skulle bidra till att skydda Tor Hidden Services runt om i världen från framtida attacker som den vi upplever.
2. Vad är installationen?
- Systemet körs på en aktuell och alltid uppdaterad linuxserver (amd64)
- All trafik dirigeras genom Tor via Tor-transport på port 9040, DNS-förfrågningar löses också via Tor
- Den dolda Tor-tjänsten är v3
- Tor är version 0.4.7.8 och körs med Libevent 2.1.12-stable, OpenSSL 1.1.1n, Zlib 1.2.11, Liblzma 5.2.5, Libzstd 1.4.8 och Glibc 2.31 som libc
- Tor kompilerad med GCC version 10.2.1. Vanguards 0.3.1 är också installerat
- Tor körs som en systemd-tjänst
- Vanguards körs som systemd-tjänst
torrc konfiguration:
CookieAutentication 1
HashedControlPassword 16:<hash>
VirtuellAddrNätverkIPv4 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. Vilka är symptomen?
- Mindre än en minut efter att Tor startats med den dolda tjänsten aktiverad går CPU till 100%, minnet verkar opåverkat
- Använd bandbredd ökar med cirka 100 kb/s
- Deskriptorn för den dolda tjänsten är inte åtkomlig
- Systemet kan fortfarande lösa clearnet- och Tor-adresser
- Systemet kan fortfarande ansluta till utgående tjänster (t.ex. curl till en webbplats)
- Systemet översvämmas av inkommande tcp-paket på loopback-gränssnittet
- När Tor startas om upphör översvämningen under några sekunder och börjar sedan igen
- När Tor startas utan att den dolda tjänsten är aktiverad verkar det inte vara något problem
- När Tor startas med en andra dold tjänst aktiverad förblir båda beskrivningarna av dolda tjänster oåtkomliga:
Tor-webbläsare på primär HS:
Onionsite har kopplats bort
Den mest troliga orsaken är att onionsite är offline. Kontakta administratören för onionsite.
Detaljerad information: 0xF2 - Introduktionen misslyckades, vilket innebär att deskriptorn hittades men att tjänsten inte längre är ansluten till introduktionspunkten. Det är troligt att tjänsten har ändrat sin deskriptor eller att den inte körs.
eller
Anslutningen har tidsinställts
Servern på (attacked hidden service descriptor).onion tar för lång tid på sig att svara.
Webbplatsen kan vara tillfälligt otillgänglig eller för upptagen. Försök igen om några ögonblick.
Tor Browser på Seconday HS:
Det går inte att ansluta
Firefox kan inte upprätta en anslutning till servern på (secondary hidden service descriptor).onion
Webbplatsen kan vara tillfälligt otillgänglig eller för upptagen. Försök igen om en liten stund.
- När Tor startas med en andra dold tjänst aktiverad som skyddas av OnionAuthentication, förblir den primära dolda tjänstebeskrivaren oåtkomlig,
den sekundära (skyddade) Hidden Service Descriptor är nåbar.
- När Tor startas med endast den andra dolda tjänsten aktiverad (med eller utan OnionAuthentication) verkar det inte vara något problem
- När Tor startas med den primära dolda tjänsten skyddad av OnionAuthentication är den dolda tjänstens deskriptor nåbar
- När den attackeras visas dessa poster i loggfilen för tor:
Aug 24 19:42:18.000 [notice] Bootstrapped 100% (klar): Klar
Aug 24 19:42:34.000 [notice] Din nätverksanslutningshastighet verkar ha ändrats. Återställer timeout till 60000 ms efter 18 timeouts och 388 buildtimes.
Aug 24 19:42:39.000 [notice] Hastigheten för din nätverksanslutning verkar ha ändrats. Återställer timeout till 60000ms efter 18 timeouts och 240 buildtimes.
Aug 24 19:42:53.000 [notice] Hastigheten för din nätverksanslutning verkar ha ändrats. Återställer timeout till 60000ms efter 18 timeouts och 489 buildtimes.
Aug 24 19:43:11.000 [notice] Hastigheten för din nätverksanslutning verkar ha ändrats. Återställer timeout till 60000ms efter 18 timeouts och 659 buildtimes.
...
Aug 24 19:46:09.000 [notice] Extremt stort värde för timeout för kretsbyggnad: 122s. Antar att klockan hoppar. Syfte 14 (Mätning av kretsens timeout)
Aug 24 19:46:09.000 [notice] Extremt stort värde för timeout för kretsuppbyggnad: 122s. Antar att klockan hoppar. Syfte 14 (Mätning av timeout för krets)
Aug 24 19:46:09.000 [notice] Hastigheten på din nätverksanslutning verkar ha ändrats. Återställer timeout till 60000ms efter 18 timeouts och 114 buildtimes.
Aug 24 19:46:15.000 [notice] Hastigheten på din nätverksanslutning verkar ha ändrats. Återställer timeout till 60000ms efter 18 timeouts och 125 buildtimes.
...
Aug 24 19:47:08.000 [notice] Extremt stort värde för timeout för kretsbyggnad: 123s. Antar att klockan hoppar. Syfte 14 (Mätning av kretsens timeout)
Aug 24 19:47:10.000 [notice] Extremt stort värde för timeout för kretsuppbyggnad: 122s. Antar att klockan hoppar. Syfte 14 (Mätning av timeout för krets)
Aug 24 19:47:10.000 [notice] Extremt stort värde för timeout för kretsuppbyggnad: 123s. Antar att klockan hoppar. Syfte 14 (Mätning av timeout för krets)
Aug 24 19:47:13.000 [notice] Extremt stort värde för timeout för kretsuppbyggnad: 123s. Antar att klockan hoppar. Syfte 14 (Mätning av timeout för krets)
Aug 24 19:47:14.000 [notice] Hastigheten på din nätverksanslutning verkar ha ändrats. Återställer timeout till 60000ms efter 18 timeouts och 495 buildtimes.
Aug 24 19:47:18.000 [notice] Hastigheten på din nätverksanslutning verkar ha ändrats. Återställer timeout till 60000ms efter 18 timeouts och 124 buildtimes.
Aug 24 19:47:21.000 [notice] Extremt stort värde för timeout för kretsbyggnad: 122s. Antar att klockan hoppar. Syfte 14 (Mätning av kretsens timeout)
Aug 24 19:47:23.000 [notice] Extremt stort värde för timeout för kretsuppbyggnad: 123s. Antar att klockan hoppar. Syfte 14 (Mätning av kretsens timeout)
...
Aug 24 19:47:55.000 [notice] Hastigheten på din nätverksanslutning verkar ha ändrats. Återställer timeout till 60000ms efter 18 timeouts och 1000 buildtimes.
Aug 24 19:47:59.000 [notice] Hastigheten för din nätverksanslutning verkar ha ändrats. Återställer timeout till 60000ms efter 18 timeouts och 117 buildtimes.
...
Aug 24 19:52:43.000 [notice] Konstigt värde för kretsens byggtid: 121581msec. Antar att klockan hoppar. Syfte 14 (Mätning av kretsens timeout)
Aug 24 19:52:43.000 [notice] Hastigheten på din nätverksanslutning verkar ha ändrats. Återställer timeout till 120000ms efter 18 timeouts och 57 buildtimes.
Aug 24 19:52:53.000 [notice] Avbrott: Avslutar på ett snyggt sätt.
4. Vad försökte vi göra för att lösa problemet?
- Vi satte upp en helt ny server från grunden som bara körde grundläggande operativsystem samt tor och vanguards i standardkonfiguration för att utesluta möjligheten av en felkonfiguration på vår drabbade server. Så snart tor startades med den attackerade deskriptorn händer exakt samma saker.
- Vi försökte dela upp belastningen på vår server via OnionBalance i den här konfigurationen:
Server1: Kör Onionbalance för primär Hidden Service Descriptor
Server2/3/4: Kör den dolda tjänsten på nya och olika beskrivningar av dolda tjänster
- Detta väcker inte den ursprungliga dolda tjänstebeskrivaren till liv igen
- Tjänstedeskriptorerna på servrarna 2/3/4 är nåbara när de öppnas direkt, men inte via den nu balanserade primära deskriptorn
- CPU på servrarna 2/3/4 går upp till 100 % så länge attacken pågår, medan CPU på server 1 (balanseraren) förblir normal
- Att lägga till fler backend-servrar till balanseraren gjorde inte heller någon skillnad
- Vi lade till dessa direktiv i det dolda serviceblocket i torrc och provade olika inställningar på dem:
DoldServiceAktiveraIntroDoSDefense 1
HiddenServiceEnableIntroDoSBurstPerSec <testat med olika värden>
HiddenServiceEnableIntroDoSRatePerSec <testad med olika värden> HiddenServiceEnableIntroDoSRatePerSec <testad med olika värden>
Detta minskade CPU-belastningen avsevärt på servrarna 2/3/4, men den balanserade servicedeskriptorn förblir oåtkomlig.
- Vi försökte ändra olika inställningar i vanguards.conf, utan framgång.
- Vi försökte identifiera de attackerande tcp-paketen och få dem blockerade via iptables, utan framgång.
Vår expertis är inte tillräcklig för att dra idéer om vad som exakt händer genom att inspektera innehållet i nämnda tcp-paket som ser ut så här:
19:45:27.839934 IP (tos 0x0, ttl 64, id 35746, offset 0, flaggor [DF], proto TCP (6), längd 4100)
127.0.0.1.9051 > 127.0.0.1.46712: Flaggor [P.], cksum 0x0df9 (felaktigt -> 0xe713), seq 1543428574:1543432622, ack 1711981309, win 512, options [nop,nop,TS val 2971851406 ecr 2971851369], längd 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=|---------(attackerad dold servicedescriptor)---------| 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=|---------(attackerad dold servicedescriptor)---------| TIME_CREATED=2022-08-24T19:45:25.10
Detta är med Tor som körs på en enda server. Vid balansering ersätts |---------(attacked hidden service descriptor)---------| av backend-tjänstens deskriptorer för server 2/3/4.
Vi kan göra en större tcpdump-snutt tillgänglig vid behov.
5. Slutsatser
Vi tror att en motståndare har möjlighet att "avbryta" en Hidden Service Descriptor (och därmed själva Hidden Service) genom att översvämma Tor-daemon med oräkneliga tcp-paket som begär att få bygga kretsar. Det är detta som orsakar CPU-belastningen och i slutändan gör den dolda servicebeskrivaren oanvändbar.
Kan någon bekräfta detta?
Eftersom direktiv som de nämnda HiddenServiceEnableIntroDoSDefense, HiddenServiceEnableIntroDoSBurstPerSec och HiddenServiceEnableIntroDoSRatePerSec verkar vara avsedda att försvara sig mot denna typ av attacker, precis som vanguards också borde, kan vi inte förklara varför de förblir ineffektiva. Kanske krävs det några mycket specialiserade inställningar av dessa värden för att göra dem effektiva. Tyvärr beskrivs dessa direktiv (liksom inställningarna i vanguards.config) endast på ett vagt sätt.
Är det någon som vet hur dessa måste ställas in korrekt för att vara effektiva?
Vid denna tidpunkt har vi uttömt alla referenser om tor och vanguards-konfigurationen som vi kunde hitta på nätet.
Återigen skulle all hjälp eller information om denna fråga vara mycket uppskattad! Vi tror inte att det inte finns någon lösning på detta.
Om något av det som beskrivs här verkar vettigt för dig och/eller om du har en misstanke om vad som pågår, är all form av feedback mycket uppskattad!
1. Vad är det som har hänt?
Vår tjänst har fungerat bra och stabilt under en längre tid. Plötsligt upplevde vår tjänst först lätta, sedan allvarliga prestandaproblem och blev sedan helt oåtkomlig.
Detta verkar inte vara en "vanlig" DDoS-attack. Det verkar vara en DoS-attack, men inte som något annat känt, eftersom det verkar vara en attack enbart mot Tor-daemon. Alla motåtgärder som vi har försökt hittills har inte lyckats. Det finns ingen attack märkbar på de faktiska tjänster som körs (http, ssh, ftp, mail, etc.) utan bara på själva Tor-anslutningen.
Även om vi gjorde en djupgående forskning och undersökning verkar händelsen vara bortom vår förståelse. Dokumentationer om tidigare attacker mot Tor Hidden Services är sällsynta att hitta och stämmer inte överens med det vi upplever.
Vi vägrar att tro att det finns ett angreppsscenario som är okänt och inte kan motverkas eftersom det skulle göra varje enskild dold Tor-tjänst sårbar för det med motståndare som kan ta vilken dold Tor-tjänst som helst offline efter behag inom några minuter på obestämd tid. Konsekvenserna för Tor-communityn skulle vara oöverskådliga.
Vi hoppas att någon med nödvändig insikt och expertis åtminstone kan ge oss en ledtråd om vad som exakt händer och peka oss i rätt riktning mot att hitta en lösning för att avsluta denna attack eller minska dess inverkan på våra system och för att förhindra sådana attacker i framtiden. Detta skulle bidra till att skydda Tor Hidden Services runt om i världen från framtida attacker som den vi upplever.
2. Vad är installationen?
- Systemet körs på en aktuell och alltid uppdaterad linuxserver (amd64)
- All trafik dirigeras genom Tor via Tor-transport på port 9040, DNS-förfrågningar löses också via Tor
- Den dolda Tor-tjänsten är v3
- Tor är version 0.4.7.8 och körs med Libevent 2.1.12-stable, OpenSSL 1.1.1n, Zlib 1.2.11, Liblzma 5.2.5, Libzstd 1.4.8 och Glibc 2.31 som libc
- Tor kompilerad med GCC version 10.2.1. Vanguards 0.3.1 är också installerat
- Tor körs som en systemd-tjänst
- Vanguards körs som systemd-tjänst
torrc konfiguration:
CookieAutentication 1
HashedControlPassword 16:<hash>
VirtuellAddrNätverkIPv4 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. Vilka är symptomen?
- Mindre än en minut efter att Tor startats med den dolda tjänsten aktiverad går CPU till 100%, minnet verkar opåverkat
- Använd bandbredd ökar med cirka 100 kb/s
- Deskriptorn för den dolda tjänsten är inte åtkomlig
- Systemet kan fortfarande lösa clearnet- och Tor-adresser
- Systemet kan fortfarande ansluta till utgående tjänster (t.ex. curl till en webbplats)
- Systemet översvämmas av inkommande tcp-paket på loopback-gränssnittet
- När Tor startas om upphör översvämningen under några sekunder och börjar sedan igen
- När Tor startas utan att den dolda tjänsten är aktiverad verkar det inte vara något problem
- När Tor startas med en andra dold tjänst aktiverad förblir båda beskrivningarna av dolda tjänster oåtkomliga:
Tor-webbläsare på primär HS:
Onionsite har kopplats bort
Den mest troliga orsaken är att onionsite är offline. Kontakta administratören för onionsite.
Detaljerad information: 0xF2 - Introduktionen misslyckades, vilket innebär att deskriptorn hittades men att tjänsten inte längre är ansluten till introduktionspunkten. Det är troligt att tjänsten har ändrat sin deskriptor eller att den inte körs.
eller
Anslutningen har tidsinställts
Servern på (attacked hidden service descriptor).onion tar för lång tid på sig att svara.
Webbplatsen kan vara tillfälligt otillgänglig eller för upptagen. Försök igen om några ögonblick.
Tor Browser på Seconday HS:
Det går inte att ansluta
Firefox kan inte upprätta en anslutning till servern på (secondary hidden service descriptor).onion
Webbplatsen kan vara tillfälligt otillgänglig eller för upptagen. Försök igen om en liten stund.
- När Tor startas med en andra dold tjänst aktiverad som skyddas av OnionAuthentication, förblir den primära dolda tjänstebeskrivaren oåtkomlig,
den sekundära (skyddade) Hidden Service Descriptor är nåbar.
- När Tor startas med endast den andra dolda tjänsten aktiverad (med eller utan OnionAuthentication) verkar det inte vara något problem
- När Tor startas med den primära dolda tjänsten skyddad av OnionAuthentication är den dolda tjänstens deskriptor nåbar
- När den attackeras visas dessa poster i loggfilen för tor:
Aug 24 19:42:18.000 [notice] Bootstrapped 100% (klar): Klar
Aug 24 19:42:34.000 [notice] Din nätverksanslutningshastighet verkar ha ändrats. Återställer timeout till 60000 ms efter 18 timeouts och 388 buildtimes.
Aug 24 19:42:39.000 [notice] Hastigheten för din nätverksanslutning verkar ha ändrats. Återställer timeout till 60000ms efter 18 timeouts och 240 buildtimes.
Aug 24 19:42:53.000 [notice] Hastigheten för din nätverksanslutning verkar ha ändrats. Återställer timeout till 60000ms efter 18 timeouts och 489 buildtimes.
Aug 24 19:43:11.000 [notice] Hastigheten för din nätverksanslutning verkar ha ändrats. Återställer timeout till 60000ms efter 18 timeouts och 659 buildtimes.
...
Aug 24 19:46:09.000 [notice] Extremt stort värde för timeout för kretsbyggnad: 122s. Antar att klockan hoppar. Syfte 14 (Mätning av kretsens timeout)
Aug 24 19:46:09.000 [notice] Extremt stort värde för timeout för kretsuppbyggnad: 122s. Antar att klockan hoppar. Syfte 14 (Mätning av timeout för krets)
Aug 24 19:46:09.000 [notice] Hastigheten på din nätverksanslutning verkar ha ändrats. Återställer timeout till 60000ms efter 18 timeouts och 114 buildtimes.
Aug 24 19:46:15.000 [notice] Hastigheten på din nätverksanslutning verkar ha ändrats. Återställer timeout till 60000ms efter 18 timeouts och 125 buildtimes.
...
Aug 24 19:47:08.000 [notice] Extremt stort värde för timeout för kretsbyggnad: 123s. Antar att klockan hoppar. Syfte 14 (Mätning av kretsens timeout)
Aug 24 19:47:10.000 [notice] Extremt stort värde för timeout för kretsuppbyggnad: 122s. Antar att klockan hoppar. Syfte 14 (Mätning av timeout för krets)
Aug 24 19:47:10.000 [notice] Extremt stort värde för timeout för kretsuppbyggnad: 123s. Antar att klockan hoppar. Syfte 14 (Mätning av timeout för krets)
Aug 24 19:47:13.000 [notice] Extremt stort värde för timeout för kretsuppbyggnad: 123s. Antar att klockan hoppar. Syfte 14 (Mätning av timeout för krets)
Aug 24 19:47:14.000 [notice] Hastigheten på din nätverksanslutning verkar ha ändrats. Återställer timeout till 60000ms efter 18 timeouts och 495 buildtimes.
Aug 24 19:47:18.000 [notice] Hastigheten på din nätverksanslutning verkar ha ändrats. Återställer timeout till 60000ms efter 18 timeouts och 124 buildtimes.
Aug 24 19:47:21.000 [notice] Extremt stort värde för timeout för kretsbyggnad: 122s. Antar att klockan hoppar. Syfte 14 (Mätning av kretsens timeout)
Aug 24 19:47:23.000 [notice] Extremt stort värde för timeout för kretsuppbyggnad: 123s. Antar att klockan hoppar. Syfte 14 (Mätning av kretsens timeout)
...
Aug 24 19:47:55.000 [notice] Hastigheten på din nätverksanslutning verkar ha ändrats. Återställer timeout till 60000ms efter 18 timeouts och 1000 buildtimes.
Aug 24 19:47:59.000 [notice] Hastigheten för din nätverksanslutning verkar ha ändrats. Återställer timeout till 60000ms efter 18 timeouts och 117 buildtimes.
...
Aug 24 19:52:43.000 [notice] Konstigt värde för kretsens byggtid: 121581msec. Antar att klockan hoppar. Syfte 14 (Mätning av kretsens timeout)
Aug 24 19:52:43.000 [notice] Hastigheten på din nätverksanslutning verkar ha ändrats. Återställer timeout till 120000ms efter 18 timeouts och 57 buildtimes.
Aug 24 19:52:53.000 [notice] Avbrott: Avslutar på ett snyggt sätt.
4. Vad försökte vi göra för att lösa problemet?
- Vi satte upp en helt ny server från grunden som bara körde grundläggande operativsystem samt tor och vanguards i standardkonfiguration för att utesluta möjligheten av en felkonfiguration på vår drabbade server. Så snart tor startades med den attackerade deskriptorn händer exakt samma saker.
- Vi försökte dela upp belastningen på vår server via OnionBalance i den här konfigurationen:
Server1: Kör Onionbalance för primär Hidden Service Descriptor
Server2/3/4: Kör den dolda tjänsten på nya och olika beskrivningar av dolda tjänster
- Detta väcker inte den ursprungliga dolda tjänstebeskrivaren till liv igen
- Tjänstedeskriptorerna på servrarna 2/3/4 är nåbara när de öppnas direkt, men inte via den nu balanserade primära deskriptorn
- CPU på servrarna 2/3/4 går upp till 100 % så länge attacken pågår, medan CPU på server 1 (balanseraren) förblir normal
- Att lägga till fler backend-servrar till balanseraren gjorde inte heller någon skillnad
- Vi lade till dessa direktiv i det dolda serviceblocket i torrc och provade olika inställningar på dem:
DoldServiceAktiveraIntroDoSDefense 1
HiddenServiceEnableIntroDoSBurstPerSec <testat med olika värden>
HiddenServiceEnableIntroDoSRatePerSec <testad med olika värden> HiddenServiceEnableIntroDoSRatePerSec <testad med olika värden>
Detta minskade CPU-belastningen avsevärt på servrarna 2/3/4, men den balanserade servicedeskriptorn förblir oåtkomlig.
- Vi försökte ändra olika inställningar i vanguards.conf, utan framgång.
- Vi försökte identifiera de attackerande tcp-paketen och få dem blockerade via iptables, utan framgång.
Vår expertis är inte tillräcklig för att dra idéer om vad som exakt händer genom att inspektera innehållet i nämnda tcp-paket som ser ut så här:
19:45:27.839934 IP (tos 0x0, ttl 64, id 35746, offset 0, flaggor [DF], proto TCP (6), längd 4100)
127.0.0.1.9051 > 127.0.0.1.46712: Flaggor [P.], cksum 0x0df9 (felaktigt -> 0xe713), seq 1543428574:1543432622, ack 1711981309, win 512, options [nop,nop,TS val 2971851406 ecr 2971851369], längd 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=|---------(attackerad dold servicedescriptor)---------| 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=|---------(attackerad dold servicedescriptor)---------| TIME_CREATED=2022-08-24T19:45:25.10
Detta är med Tor som körs på en enda server. Vid balansering ersätts |---------(attacked hidden service descriptor)---------| av backend-tjänstens deskriptorer för server 2/3/4.
Vi kan göra en större tcpdump-snutt tillgänglig vid behov.
5. Slutsatser
Vi tror att en motståndare har möjlighet att "avbryta" en Hidden Service Descriptor (och därmed själva Hidden Service) genom att översvämma Tor-daemon med oräkneliga tcp-paket som begär att få bygga kretsar. Det är detta som orsakar CPU-belastningen och i slutändan gör den dolda servicebeskrivaren oanvändbar.
Kan någon bekräfta detta?
Eftersom direktiv som de nämnda HiddenServiceEnableIntroDoSDefense, HiddenServiceEnableIntroDoSBurstPerSec och HiddenServiceEnableIntroDoSRatePerSec verkar vara avsedda att försvara sig mot denna typ av attacker, precis som vanguards också borde, kan vi inte förklara varför de förblir ineffektiva. Kanske krävs det några mycket specialiserade inställningar av dessa värden för att göra dem effektiva. Tyvärr beskrivs dessa direktiv (liksom inställningarna i vanguards.config) endast på ett vagt sätt.
Är det någon som vet hur dessa måste ställas in korrekt för att vara effektiva?
Vid denna tidpunkt har vi uttömt alla referenser om tor och vanguards-konfigurationen som vi kunde hitta på nätet.
Återigen skulle all hjälp eller information om denna fråga vara mycket uppskattad! Vi tror inte att det inte finns någon lösning på detta.
Last edited:
