Dziękujemy za poświęcenie czasu na przeczytanie tego tekstu! Nie jesteśmy ekspertami w dziedzinie sieci Tor, ale znamy się na rzeczy.
Jeśli cokolwiek opisanego tutaj ma dla Ciebie sens i / lub masz podejrzenia co do tego, co się dzieje, każdy rodzaj opinii jest niezwykle cenny!
1. Co się dzieje?
Nasza usługa działała dobrze i stabilnie przez długi czas. Nagle nasza usługa doświadczyła lekkich, a następnie poważnych problemów z wydajnością, a następnie stała się całkowicie nieosiągalna.
Nie wygląda to na "zwykły" atak DDoS. Wydaje się, że jest to atak DoS, ale nie podobny do niczego znanego, ponieważ wydaje się, że jest to atak na samego demona Tor. Wszystkie środki zaradcze, których próbowaliśmy do tej pory, nie powiodły się. Nie ma zauważalnego ataku na rzeczywiste uruchomione usługi (http, ssh, ftp, poczta itp.), ale tylko na samo połączenie Tor.
Nawet jeśli przeprowadziliśmy dogłębne badania i śledztwo, zdarzenie wydaje się być poza naszym zrozumieniem. Dokumentacje dotyczące wcześniejszych ataków na Tor Hidden Services są rzadkie do znalezienia i nie mają sensu dla tego, czego doświadczamy.
Nie wierzymy, że istnieje scenariusz ataku, który jest nieznany i któremu nie można przeciwdziałać, ponieważ spowodowałoby to, że każda pojedyncza usługa ukryta w sieci Tor byłaby na niego podatna, a przeciwnicy mogliby dowolnie wyłączyć dowolną usługę ukrytą w sieci Tor w ciągu kilku minut na czas nieokreślony. Wpływ na społeczność Tor byłby nie do ogarnięcia.
Mamy nadzieję, że ktoś z niezbędnym wglądem i doświadczeniem może przynajmniej podpowiedzieć nam, co dokładnie się dzieje i wskazać nam właściwy kierunek w celu znalezienia rozwiązania, które zakończy ten atak lub zmniejszy jego wpływ na nasze systemy i zapobiegnie takim atakom w przyszłości. Pomogłoby to chronić usługi Tor Hidden na całym świecie przed przyszłymi atakami, takimi jak ten, którego doświadczamy.
2. Jaka jest konfiguracja?
- System działa na aktualnym i zawsze aktualnym serwerze linux (amd64).
- Cały ruch jest kierowany przez Tora za pośrednictwem transportu Tora na porcie 9040, zapytania DNS są również rozwiązywane przez Tora.
- Ukryta usługa Tor jest w wersji 3
- Tor to wersja 0.4.7.8 działająca z 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 jako libc.
- Tor skompilowany z GCC w wersji 10.2.1. Vanguards 0.3.1 jest również zainstalowany
- Tor działa jako usługa systemd
- Vanguards działa jako usługa systemd
konfiguracja 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. Jakie są objawy?
- Mniej niż minutę po uruchomieniu Tora z włączoną Ukrytą Usługą CPU osiąga 100%, pamięć wydaje się być nienaruszona.
- Używana przepustowość wzrasta o około 100kb/s
- Deskryptor usługi ukrytej jest nieosiągalny.
- System może nadal rozpoznawać adresy clearnet i Tor.
- System nadal może łączyć się z usługami wychodzącymi (np. curl do strony internetowej)
- System zostaje zalany przychodzącymi pakietami tcp na interfejsie loopback.
- Po ponownym uruchomieniu Tora, zalew kończy się na kilka sekund, a następnie zaczyna się od nowa.
- Gdy Tor jest uruchamiany bez włączonej usługi Hidden Service, wydaje się, że nie ma problemu.
- Gdy Tor jest uruchomiony z włączoną drugą ukrytą usługą, oba deskryptory ukrytej usługi pozostają nieosiągalne:
Przeglądarka Tor na głównym HS:
Onionsite Has Disconnected
Najbardziej prawdopodobną przyczyną jest to, że onionsite jest offline. Skontaktuj się z administratorem onionsite.
Szczegóły: 0xF2 - Wprowadzenie nie powiodło się, co oznacza, że znaleziono deskryptor, ale usługa nie jest już połączona z punktem wprowadzenia. Prawdopodobnie usługa zmieniła swój deskryptor lub nie jest uruchomiona.
lub
Połączenie przekroczyło limit czasu
Serwer pod adresem (zaatakowany ukryty deskryptor usługi).onion odpowiada zbyt długo.
Witryna może być tymczasowo niedostępna lub zbyt zajęta. Spróbuj ponownie za kilka chwil.
Przeglądarka Tor na Seconday HS:
Nie można nawiązać połączenia
Firefox nie może nawiązać połączenia z serwerem pod adresem (drugorzędny ukryty deskryptor usługi).onion
Strona może być tymczasowo niedostępna lub zbyt zajęta. Spróbuj ponownie za kilka chwil.
- Gdy Tor jest uruchomiony z włączoną drugą ukrytą usługą, która jest chroniona przez OnionAuthentication, główny deskryptor ukrytej usługi pozostaje nieosiągalny,
drugi (chroniony) deskryptor usługi ukrytej jest osiągalny.
- Gdy Tor jest uruchamiany z włączoną tylko drugą ukrytą usługą (z lub bez OnionAuthentication), wydaje się, że nie ma problemu
- Gdy Tor jest uruchamiany z podstawową usługą ukrytą chronioną przez OnionAuthentication, deskryptor usługi ukrytej jest osiągalny.
- W przypadku ataku, w pliku dziennika tor pojawiają się następujące wpisy:
Aug 24 19:42:18.000 [notice] Bootstrapped 100% (done): Gotowe
Aug 24 19:42:34.000 [notice] Wygląda na to, że prędkość połączenia sieciowego uległa zmianie. Resetowanie limitu czasu do 60000 ms po 18 limitach czasu i 388 czasach kompilacji.
Aug 24 19:42:39.000 [notice] Wygląda na to, że prędkość połączenia sieciowego uległa zmianie. Resetowanie limitu czasu do 60000 ms po 18 limitach czasu i 240 czasach kompilacji.
Aug 24 19:42:53.000 [notice] Wygląda na to, że prędkość połączenia sieciowego uległa zmianie. Resetowanie limitu czasu do 60000 ms po 18 limitach czasu i 489 czasach kompilacji.
Aug 24 19:43:11.000 [notice] Wygląda na to, że prędkość połączenia sieciowego uległa zmianie. Resetowanie limitu czasu do 60000 ms po 18 limitach czasu i 659 czasach kompilacji.
...
Aug 24 19:46:09.000 [notice] Niezwykle duża wartość limitu czasu kompilacji obwodu: 122s. Zakładając skok zegara. Cel 14 (Pomiar limitu czasu obwodu)
Aug 24 19:46:09.000 [notice] Niezwykle duża wartość limitu czasu budowania obwodu: 122s. Zakładając skok zegara. Cel 14 (Pomiar limitu czasu obwodu)
Aug 24 19:46:09.000 [notice] Wygląda na to, że prędkość połączenia sieciowego uległa zmianie. Resetowanie limitu czasu do 60000 ms po 18 limitach czasu i 114 czasach kompilacji.
Aug 24 19:46:15.000 [notice] Wygląda na to, że prędkość połączenia sieciowego uległa zmianie. Resetowanie limitu czasu do 60000 ms po 18 limitach czasu i 125 czasach kompilacji.
...
Aug 24 19:47:08.000 [notice] Niezwykle duża wartość limitu czasu kompilacji obwodu: 123s. Zakładając skok zegara. Cel 14 (Pomiar limitu czasu obwodu)
Aug 24 19:47:10.000 [notice] Niezwykle duża wartość limitu czasu budowania obwodu: 122s. Zakładając skok zegara. Cel 14 (Pomiar limitu czasu obwodu)
Aug 24 19:47:10.000 [notice] Niezwykle duża wartość limitu czasu budowania obwodu: 123s. Zakładając skok zegara. Cel 14 (Pomiar limitu czasu obwodu)
Aug 24 19:47:13.000 [notice] Niezwykle duża wartość limitu czasu budowania obwodu: 123s. Zakładając skok zegara. Cel 14 (Pomiar limitu czasu obwodu)
Aug 24 19:47:14.000 [notice] Wygląda na to, że prędkość połączenia sieciowego uległa zmianie. Resetowanie limitu czasu do 60000 ms po 18 limitach czasu i 495 czasach kompilacji.
Aug 24 19:47:18.000 [notice] Wygląda na to, że prędkość połączenia sieciowego uległa zmianie. Resetowanie limitu czasu do 60000 ms po 18 limitach czasu i 124 czasach kompilacji.
Aug 24 19:47:21.000 [notice] Niezwykle duża wartość limitu czasu kompilacji obwodu: 122s. Zakładając skok zegara. Cel 14 (Pomiar limitu czasu obwodu)
Aug 24 19:47:23.000 [notice] Niezwykle duża wartość limitu czasu kompilacji obwodu: 123s. Zakładając skok zegara. Cel 14 (Pomiar limitu czasu obwodu)
...
Aug 24 19:47:55.000 [notice] Wygląda na to, że prędkość połączenia sieciowego uległa zmianie. Resetowanie limitu czasu do 60000 ms po 18 limitach czasu i 1000 czasach budowania.
Aug 24 19:47:59.000 [notice] Wygląda na to, że prędkość połączenia sieciowego uległa zmianie. Resetowanie limitu czasu do 60000 ms po 18 limitach czasu i 117 czasach kompilacji.
...
Aug 24 19:52:43.000 [notice] Dziwna wartość czasu kompilacji obwodu: 121581msec. Zakładając skok zegara. Cel 14 (Pomiar limitu czasu obwodu)
Aug 24 19:52:43.000 [notice] Wygląda na to, że prędkość połączenia sieciowego uległa zmianie. Resetowanie limitu czasu do 120000 ms po 18 limitach czasu i 57 czasach kompilacji.
Aug 24 19:52:53.000 [notice] Przerwanie: czyste wyjście.
4. Co próbowano zrobić, aby rozwiązać problem?
- Skonfigurowaliśmy całkowicie nowy serwer od zera, uruchamiając tylko podstawowy system operacyjny, a także tor i vanguards w standardowej konfiguracji, aby wykluczyć możliwość błędnej konfiguracji na naszym dotkniętym serwerze. Gdy tylko tor został uruchomiony z zaatakowanym deskryptorem, dzieje się dokładnie to samo.
- Próbowaliśmy podzielić obciążenie naszego serwera za pomocą OnionBalance w tej konfiguracji:
Serwer1: Uruchamia Onionbalance dla głównego deskryptora usługi ukrytej.
Server2/3/4: Uruchamia Ukrytą Usługę na nowych i różnych Deskryptorach Ukrytej Usługi.
- Nie przywraca to do życia oryginalnego deskryptora usługi ukrytej.
- Deskryptory usług na serwerach 2/3/4 są osiągalne, gdy są otwierane bezpośrednio, ale nie przez zbalansowany deskryptor podstawowy.
- Procesor na serwerach 2/3/4 osiąga 100% tak długo, jak trwa atak, podczas gdy procesor na serwerze 1 (balanserze) pozostaje normalny.
- Dodanie większej liczby serwerów zaplecza do balancera również nie przyniosło różnicy.
- Dodaliśmy te dyrektywy do bloku ukrytych usług w torrc i wypróbowaliśmy na nich różne ustawienia:
HiddenServiceEnableIntroDoSDefense 1
HiddenServiceEnableIntroDoSBurstPerSec <testowane z różnymi wartościami>
HiddenServiceEnableIntroDoSRatePerSec <testowane z różnymi wartościami>.
To znacznie zmniejszyło obciążenie procesora na serwerach 2/3/4, ale zrównoważony deskryptor usługi pozostaje nieosiągalny.
- Próbowaliśmy zmienić różne ustawienia w pliku vanguards.conf, ale bez powodzenia.
- Próbowaliśmy zidentyfikować atakujące pakiety tcp i zablokować je przez iptables, bez powodzenia.
Nasza wiedza nie jest wystarczająca, aby określić, co dokładnie się dzieje, sprawdzając zawartość wspomnianych pakietów tcp, które wyglądają następująco:
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: Flagi [P.], cksum 0x0df9 (nieprawidłowe -> 0xe713), seq 1543428574:1543432622, ack 1711981309, win 512, opcje [nop,nop,TS val 2971851406 ecr 2971851369], długość 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=|---------(zaatakowany ukryty deskryptor usługi)---------| 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=|---------(zaatakowany ukryty deskryptor usługi)---------| 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=|---------(zaatakowany ukryty deskryptor usługi)---------| 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=|---------(zaatakowany ukryty deskryptor usługi)---------| TIME_CREATED=2022-08-24T19:45:25.10
Dzieje się tak, gdy Tor działa na jednym serwerze. Po zrównoważeniu, |---------(zaatakowany ukryty deskryptor usługi)---------| jest zastępowany przez deskryptory usług backendów serwera 2/3/4.
W razie potrzeby możemy udostępnić większy fragment tcpdump.
5. Wnioski
Uważamy, że przeciwnik ma możliwość "przerwania" deskryptora usługi ukrytej (a tym samym samej usługi ukrytej) poprzez zalewanie demona Tor niezliczonymi pakietami tcp z żądaniem utworzenia obwodów. To właśnie powoduje obciążenie procesora i ostatecznie czyni deskryptor usługi ukrytej bezużytecznym.
Czy ktoś może to potwierdzić?
Ponieważ dyrektywy takie jak wspomniane HiddenServiceEnableIntroDoSDefense, HiddenServiceEnableIntroDoSBurstPerSec i HiddenServiceEnableIntroDoSRatePerSec wydają się być przeznaczone do obrony przed tego rodzaju atakami, tak jak powinny to robić vanguardy, nie możemy wyjaśnić, dlaczego pozostają one nieskuteczne. Być może niektóre bardzo wyspecjalizowane ustawienia tych wartości są konieczne, aby były skuteczne. Niestety te dyrektywy (jak również ustawienia w vanguards.config) są opisane tylko w niejasny sposób.
Czy ktoś wie, jak należy je poprawnie ustawić, aby były skuteczne?
W tym momencie wyczerpaliśmy wszystkie odniesienia do konfiguracji tor i vanguards, jakie mogliśmy znaleźć w Internecie.
Ponownie, każda pomoc lub informacja na ten temat byłaby bardzo mile widziana! Nie wierzymy, że nie ma na to rozwiązania.
Jeśli cokolwiek opisanego tutaj ma dla Ciebie sens i / lub masz podejrzenia co do tego, co się dzieje, każdy rodzaj opinii jest niezwykle cenny!
1. Co się dzieje?
Nasza usługa działała dobrze i stabilnie przez długi czas. Nagle nasza usługa doświadczyła lekkich, a następnie poważnych problemów z wydajnością, a następnie stała się całkowicie nieosiągalna.
Nie wygląda to na "zwykły" atak DDoS. Wydaje się, że jest to atak DoS, ale nie podobny do niczego znanego, ponieważ wydaje się, że jest to atak na samego demona Tor. Wszystkie środki zaradcze, których próbowaliśmy do tej pory, nie powiodły się. Nie ma zauważalnego ataku na rzeczywiste uruchomione usługi (http, ssh, ftp, poczta itp.), ale tylko na samo połączenie Tor.
Nawet jeśli przeprowadziliśmy dogłębne badania i śledztwo, zdarzenie wydaje się być poza naszym zrozumieniem. Dokumentacje dotyczące wcześniejszych ataków na Tor Hidden Services są rzadkie do znalezienia i nie mają sensu dla tego, czego doświadczamy.
Nie wierzymy, że istnieje scenariusz ataku, który jest nieznany i któremu nie można przeciwdziałać, ponieważ spowodowałoby to, że każda pojedyncza usługa ukryta w sieci Tor byłaby na niego podatna, a przeciwnicy mogliby dowolnie wyłączyć dowolną usługę ukrytą w sieci Tor w ciągu kilku minut na czas nieokreślony. Wpływ na społeczność Tor byłby nie do ogarnięcia.
Mamy nadzieję, że ktoś z niezbędnym wglądem i doświadczeniem może przynajmniej podpowiedzieć nam, co dokładnie się dzieje i wskazać nam właściwy kierunek w celu znalezienia rozwiązania, które zakończy ten atak lub zmniejszy jego wpływ na nasze systemy i zapobiegnie takim atakom w przyszłości. Pomogłoby to chronić usługi Tor Hidden na całym świecie przed przyszłymi atakami, takimi jak ten, którego doświadczamy.
2. Jaka jest konfiguracja?
- System działa na aktualnym i zawsze aktualnym serwerze linux (amd64).
- Cały ruch jest kierowany przez Tora za pośrednictwem transportu Tora na porcie 9040, zapytania DNS są również rozwiązywane przez Tora.
- Ukryta usługa Tor jest w wersji 3
- Tor to wersja 0.4.7.8 działająca z 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 jako libc.
- Tor skompilowany z GCC w wersji 10.2.1. Vanguards 0.3.1 jest również zainstalowany
- Tor działa jako usługa systemd
- Vanguards działa jako usługa systemd
konfiguracja 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. Jakie są objawy?
- Mniej niż minutę po uruchomieniu Tora z włączoną Ukrytą Usługą CPU osiąga 100%, pamięć wydaje się być nienaruszona.
- Używana przepustowość wzrasta o około 100kb/s
- Deskryptor usługi ukrytej jest nieosiągalny.
- System może nadal rozpoznawać adresy clearnet i Tor.
- System nadal może łączyć się z usługami wychodzącymi (np. curl do strony internetowej)
- System zostaje zalany przychodzącymi pakietami tcp na interfejsie loopback.
- Po ponownym uruchomieniu Tora, zalew kończy się na kilka sekund, a następnie zaczyna się od nowa.
- Gdy Tor jest uruchamiany bez włączonej usługi Hidden Service, wydaje się, że nie ma problemu.
- Gdy Tor jest uruchomiony z włączoną drugą ukrytą usługą, oba deskryptory ukrytej usługi pozostają nieosiągalne:
Przeglądarka Tor na głównym HS:
Onionsite Has Disconnected
Najbardziej prawdopodobną przyczyną jest to, że onionsite jest offline. Skontaktuj się z administratorem onionsite.
Szczegóły: 0xF2 - Wprowadzenie nie powiodło się, co oznacza, że znaleziono deskryptor, ale usługa nie jest już połączona z punktem wprowadzenia. Prawdopodobnie usługa zmieniła swój deskryptor lub nie jest uruchomiona.
lub
Połączenie przekroczyło limit czasu
Serwer pod adresem (zaatakowany ukryty deskryptor usługi).onion odpowiada zbyt długo.
Witryna może być tymczasowo niedostępna lub zbyt zajęta. Spróbuj ponownie za kilka chwil.
Przeglądarka Tor na Seconday HS:
Nie można nawiązać połączenia
Firefox nie może nawiązać połączenia z serwerem pod adresem (drugorzędny ukryty deskryptor usługi).onion
Strona może być tymczasowo niedostępna lub zbyt zajęta. Spróbuj ponownie za kilka chwil.
- Gdy Tor jest uruchomiony z włączoną drugą ukrytą usługą, która jest chroniona przez OnionAuthentication, główny deskryptor ukrytej usługi pozostaje nieosiągalny,
drugi (chroniony) deskryptor usługi ukrytej jest osiągalny.
- Gdy Tor jest uruchamiany z włączoną tylko drugą ukrytą usługą (z lub bez OnionAuthentication), wydaje się, że nie ma problemu
- Gdy Tor jest uruchamiany z podstawową usługą ukrytą chronioną przez OnionAuthentication, deskryptor usługi ukrytej jest osiągalny.
- W przypadku ataku, w pliku dziennika tor pojawiają się następujące wpisy:
Aug 24 19:42:18.000 [notice] Bootstrapped 100% (done): Gotowe
Aug 24 19:42:34.000 [notice] Wygląda na to, że prędkość połączenia sieciowego uległa zmianie. Resetowanie limitu czasu do 60000 ms po 18 limitach czasu i 388 czasach kompilacji.
Aug 24 19:42:39.000 [notice] Wygląda na to, że prędkość połączenia sieciowego uległa zmianie. Resetowanie limitu czasu do 60000 ms po 18 limitach czasu i 240 czasach kompilacji.
Aug 24 19:42:53.000 [notice] Wygląda na to, że prędkość połączenia sieciowego uległa zmianie. Resetowanie limitu czasu do 60000 ms po 18 limitach czasu i 489 czasach kompilacji.
Aug 24 19:43:11.000 [notice] Wygląda na to, że prędkość połączenia sieciowego uległa zmianie. Resetowanie limitu czasu do 60000 ms po 18 limitach czasu i 659 czasach kompilacji.
...
Aug 24 19:46:09.000 [notice] Niezwykle duża wartość limitu czasu kompilacji obwodu: 122s. Zakładając skok zegara. Cel 14 (Pomiar limitu czasu obwodu)
Aug 24 19:46:09.000 [notice] Niezwykle duża wartość limitu czasu budowania obwodu: 122s. Zakładając skok zegara. Cel 14 (Pomiar limitu czasu obwodu)
Aug 24 19:46:09.000 [notice] Wygląda na to, że prędkość połączenia sieciowego uległa zmianie. Resetowanie limitu czasu do 60000 ms po 18 limitach czasu i 114 czasach kompilacji.
Aug 24 19:46:15.000 [notice] Wygląda na to, że prędkość połączenia sieciowego uległa zmianie. Resetowanie limitu czasu do 60000 ms po 18 limitach czasu i 125 czasach kompilacji.
...
Aug 24 19:47:08.000 [notice] Niezwykle duża wartość limitu czasu kompilacji obwodu: 123s. Zakładając skok zegara. Cel 14 (Pomiar limitu czasu obwodu)
Aug 24 19:47:10.000 [notice] Niezwykle duża wartość limitu czasu budowania obwodu: 122s. Zakładając skok zegara. Cel 14 (Pomiar limitu czasu obwodu)
Aug 24 19:47:10.000 [notice] Niezwykle duża wartość limitu czasu budowania obwodu: 123s. Zakładając skok zegara. Cel 14 (Pomiar limitu czasu obwodu)
Aug 24 19:47:13.000 [notice] Niezwykle duża wartość limitu czasu budowania obwodu: 123s. Zakładając skok zegara. Cel 14 (Pomiar limitu czasu obwodu)
Aug 24 19:47:14.000 [notice] Wygląda na to, że prędkość połączenia sieciowego uległa zmianie. Resetowanie limitu czasu do 60000 ms po 18 limitach czasu i 495 czasach kompilacji.
Aug 24 19:47:18.000 [notice] Wygląda na to, że prędkość połączenia sieciowego uległa zmianie. Resetowanie limitu czasu do 60000 ms po 18 limitach czasu i 124 czasach kompilacji.
Aug 24 19:47:21.000 [notice] Niezwykle duża wartość limitu czasu kompilacji obwodu: 122s. Zakładając skok zegara. Cel 14 (Pomiar limitu czasu obwodu)
Aug 24 19:47:23.000 [notice] Niezwykle duża wartość limitu czasu kompilacji obwodu: 123s. Zakładając skok zegara. Cel 14 (Pomiar limitu czasu obwodu)
...
Aug 24 19:47:55.000 [notice] Wygląda na to, że prędkość połączenia sieciowego uległa zmianie. Resetowanie limitu czasu do 60000 ms po 18 limitach czasu i 1000 czasach budowania.
Aug 24 19:47:59.000 [notice] Wygląda na to, że prędkość połączenia sieciowego uległa zmianie. Resetowanie limitu czasu do 60000 ms po 18 limitach czasu i 117 czasach kompilacji.
...
Aug 24 19:52:43.000 [notice] Dziwna wartość czasu kompilacji obwodu: 121581msec. Zakładając skok zegara. Cel 14 (Pomiar limitu czasu obwodu)
Aug 24 19:52:43.000 [notice] Wygląda na to, że prędkość połączenia sieciowego uległa zmianie. Resetowanie limitu czasu do 120000 ms po 18 limitach czasu i 57 czasach kompilacji.
Aug 24 19:52:53.000 [notice] Przerwanie: czyste wyjście.
4. Co próbowano zrobić, aby rozwiązać problem?
- Skonfigurowaliśmy całkowicie nowy serwer od zera, uruchamiając tylko podstawowy system operacyjny, a także tor i vanguards w standardowej konfiguracji, aby wykluczyć możliwość błędnej konfiguracji na naszym dotkniętym serwerze. Gdy tylko tor został uruchomiony z zaatakowanym deskryptorem, dzieje się dokładnie to samo.
- Próbowaliśmy podzielić obciążenie naszego serwera za pomocą OnionBalance w tej konfiguracji:
Serwer1: Uruchamia Onionbalance dla głównego deskryptora usługi ukrytej.
Server2/3/4: Uruchamia Ukrytą Usługę na nowych i różnych Deskryptorach Ukrytej Usługi.
- Nie przywraca to do życia oryginalnego deskryptora usługi ukrytej.
- Deskryptory usług na serwerach 2/3/4 są osiągalne, gdy są otwierane bezpośrednio, ale nie przez zbalansowany deskryptor podstawowy.
- Procesor na serwerach 2/3/4 osiąga 100% tak długo, jak trwa atak, podczas gdy procesor na serwerze 1 (balanserze) pozostaje normalny.
- Dodanie większej liczby serwerów zaplecza do balancera również nie przyniosło różnicy.
- Dodaliśmy te dyrektywy do bloku ukrytych usług w torrc i wypróbowaliśmy na nich różne ustawienia:
HiddenServiceEnableIntroDoSDefense 1
HiddenServiceEnableIntroDoSBurstPerSec <testowane z różnymi wartościami>
HiddenServiceEnableIntroDoSRatePerSec <testowane z różnymi wartościami>.
To znacznie zmniejszyło obciążenie procesora na serwerach 2/3/4, ale zrównoważony deskryptor usługi pozostaje nieosiągalny.
- Próbowaliśmy zmienić różne ustawienia w pliku vanguards.conf, ale bez powodzenia.
- Próbowaliśmy zidentyfikować atakujące pakiety tcp i zablokować je przez iptables, bez powodzenia.
Nasza wiedza nie jest wystarczająca, aby określić, co dokładnie się dzieje, sprawdzając zawartość wspomnianych pakietów tcp, które wyglądają następująco:
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: Flagi [P.], cksum 0x0df9 (nieprawidłowe -> 0xe713), seq 1543428574:1543432622, ack 1711981309, win 512, opcje [nop,nop,TS val 2971851406 ecr 2971851369], długość 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=|---------(zaatakowany ukryty deskryptor usługi)---------| 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=|---------(zaatakowany ukryty deskryptor usługi)---------| 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=|---------(zaatakowany ukryty deskryptor usługi)---------| 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=|---------(zaatakowany ukryty deskryptor usługi)---------| TIME_CREATED=2022-08-24T19:45:25.10
Dzieje się tak, gdy Tor działa na jednym serwerze. Po zrównoważeniu, |---------(zaatakowany ukryty deskryptor usługi)---------| jest zastępowany przez deskryptory usług backendów serwera 2/3/4.
W razie potrzeby możemy udostępnić większy fragment tcpdump.
5. Wnioski
Uważamy, że przeciwnik ma możliwość "przerwania" deskryptora usługi ukrytej (a tym samym samej usługi ukrytej) poprzez zalewanie demona Tor niezliczonymi pakietami tcp z żądaniem utworzenia obwodów. To właśnie powoduje obciążenie procesora i ostatecznie czyni deskryptor usługi ukrytej bezużytecznym.
Czy ktoś może to potwierdzić?
Ponieważ dyrektywy takie jak wspomniane HiddenServiceEnableIntroDoSDefense, HiddenServiceEnableIntroDoSBurstPerSec i HiddenServiceEnableIntroDoSRatePerSec wydają się być przeznaczone do obrony przed tego rodzaju atakami, tak jak powinny to robić vanguardy, nie możemy wyjaśnić, dlaczego pozostają one nieskuteczne. Być może niektóre bardzo wyspecjalizowane ustawienia tych wartości są konieczne, aby były skuteczne. Niestety te dyrektywy (jak również ustawienia w vanguards.config) są opisane tylko w niejasny sposób.
Czy ktoś wie, jak należy je poprawnie ustawić, aby były skuteczne?
W tym momencie wyczerpaliśmy wszystkie odniesienia do konfiguracji tor i vanguards, jakie mogliśmy znaleźć w Internecie.
Ponownie, każda pomoc lub informacja na ten temat byłaby bardzo mile widziana! Nie wierzymy, że nie ma na to rozwiązania.
Last edited:
