Köszönjük, hogy időt szánt az elolvasásra! Nem vagyunk a Tor-hálózat szakértői, de ismerjük magunkat.
Ha bármi, amit itt leírtunk, értelmet nyer az Ön számára és/vagy van valami gyanúja azzal kapcsolatban, hogy mi folyik itt, bármilyen visszajelzést rendkívül nagyra értékelünk!
1. Mi történik?
A szolgáltatásunk sokáig jól és stabilan működött. Hirtelen szolgáltatásunk először enyhe, majd súlyos teljesítményproblémákat tapasztalt, majd teljesen elérhetetlenné vált.
Úgy tűnik, hogy ez nem egy "szokásos" DDoS támadás. Úgy tűnik, hogy ez egy DoS-támadás, de nem olyan, mint bármi más ismert, mivel úgy tűnik, hogy ez egy támadás csak a Tor démon ellen. Minden eddig próbált ellenintézkedés sikertelen volt. Nem észlelhető támadás a ténylegesen futó szolgáltatások (http, ssh, ftp, mail, stb.) ellen, hanem csak maga a Tor kapcsolat ellen.
Hiába végeztünk mélyreható kutatást és vizsgálatot, úgy tűnik, az esemény meghaladja a felfogóképességünket. A Tor Hidden Services elleni korábbi támadásokról szóló dokumentációkat ritkán találni, és nem áll össze azzal, amit mi tapasztalunk.
Nem vagyunk hajlandóak elhinni, hogy létezik egy olyan támadási forgatókönyv, amely ismeretlen és nem lehet ellene védekezni, mivel ez minden egyes Tor Rejtett Szolgáltatást sebezhetővé tenne, mivel az ellenfelek képesek lennének bármelyik Tor Rejtett Szolgáltatást tetszés szerint perceken belül, határozatlan időre offline állapotba hozni. A Tor közösségre gyakorolt hatás meghaladná a határokat.
Reméljük, hogy valaki, aki rendelkezik a szükséges rálátással és szakértelemmel, legalább egy tippet tud adni nekünk arról, hogy pontosan mi is történik, és a megfelelő irányba mutat, hogy találjunk egy megoldást a támadás befejezésére vagy a rendszerünkre gyakorolt hatásának csökkentésére, és az ilyen támadások megelőzésére a jövőben. Ez segítene megvédeni a Tor Rejtett Szolgáltatásokat világszerte a jövőbeni támadásoktól, mint amilyet most tapasztalunk.
2. Mi a beállítás?
- A rendszer egy aktuális és mindig naprakész linux (amd64) szerveren fut.
- Minden adatforgalom a Toron keresztül a Tor transporton keresztül a 9040-es porton keresztül történik, a DNS lekérdezések is a Toron keresztül oldódnak meg.
- A Tor Hidden Service v3-as verziója
- A Tor 0.4.7.8-as verziója Libevent 2.1.12-stable, OpenSSL 1.1.1.1n, Zlib 1.2.11, Liblzma 5.2.5, Libzstd 1.4.8 és Glibc 2.31 libc-ként fut.
- Tor a GCC 10.2.1-es verziójával fordított Tor. A Vanguards 0.3.1 is telepítve van.
- A Tor systemd szolgáltatásként fut
- A Vanguards systemd szolgáltatásként fut
torrc konfiguráció:
CookieAuthentication 1
HashedControlPassword 16:<hash>
VirtualAddrNetworkIPv4 10.192.0.0.0/10
AutomapHostsOnResolve 1
TransPort 127.0.0.0.1:9040
DNSPort 127.0.0.0.1:53
HiddenServiceDir /var/lib/tor/hidden_service
HiddenServicePort 80 127.0.0.0.1:80
HiddenServiceVersion 3
HiddenServiceAllowUnknownPorts 0
3. Mik a tünetek?
- Kevesebb mint egy perccel a Tor indítása után, amikor a Hidden Service be van kapcsolva, a CPU 100%-ra emelkedik, a memória nem tűnik érintettnek.
- A használt sávszélesség 100kb/s körül növekszik.
- A rejtett szolgáltatás leírója elérhetetlen.
- A rendszer továbbra is fel tudja oldani a clearnet és a Tor címeket.
- A rendszer továbbra is képes csatlakozni a kimenő szolgáltatásokhoz (pl. curl egy weboldalhoz).
- A rendszert elárasztják a bejövő tcp csomagok a loopback interfészen.
- A Tor újraindításakor az áradás néhány másodpercre megszűnik, majd újraindul.
- Ha a Tor-t a rejtett szolgáltatás engedélyezése nélkül indítjuk el, úgy tűnik, nincs probléma.
- Ha a Tor-t egy másik rejtett szolgáltatással indítjuk, mindkét rejtett szolgáltatás leírója elérhetetlen marad:
Tor böngésző az elsődleges HS-en:
Onionsite Has Disconnected
A legvalószínűbb ok, hogy az onionsite offline. Lépjen kapcsolatba az onionsite rendszergazdájával.
Részletek: 0xF2 - A bevezetés sikertelen, ami azt jelenti, hogy a leírót megtalálták, de a szolgáltatás már nem kapcsolódik a bevezetési ponthoz. Valószínű, hogy a szolgáltatás megváltoztatta a leíróját, vagy nem fut.
vagy
A kapcsolat megszűnt.
A (megtámadott rejtett szolgáltatásleíró).onion szerver túl sokáig tart a válaszadás.
Lehet, hogy a webhely átmenetileg nem elérhető vagy túlságosan elfoglalt. Próbálja meg újra néhány pillanat múlva.
Tor Browser a Seconday HS-en:
Nem sikerült csatlakozni
A Firefox nem tud kapcsolatot létesíteni a (másodlagos rejtett szolgáltatásleíró).onion alatti szerverrel.
Az oldal átmenetileg nem elérhető vagy túl elfoglalt lehet. Próbálja meg újra néhány pillanat múlva.
- Ha a Tor egy második rejtett szolgáltatás engedélyezésével indul, amelyet az OnionAuthentication véd, az elsődleges rejtett szolgáltatás leírója elérhetetlen marad,
a másodlagos (védett) rejtett szolgáltatás leírója elérhető.
- Ha a Tor-t csak a második rejtett szolgáltatással indítjuk (OnionAuthentication-nel vagy anélkül), úgy tűnik, nincs probléma.
- Ha a Tor-t az OnionAuthentication által védett elsődleges rejtett szolgáltatással indítjuk, a rejtett szolgáltatás leírója elérhető.
- Támadás esetén ezek a bejegyzések jelennek meg a tor naplófájlban:
Aug 24 19:42:18.000 [notice] Bootstrapped 100% (done): Kész
Aug 24 19:42:34.000 [notice] A hálózati kapcsolat sebessége megváltozott. A timeout visszaállítása 60000ms-ra 18 timeout és 388 buildtime után.
Aug 24 19:42:39.000 [notice] A hálózati kapcsolat sebessége megváltozott. Az időkorlát visszaállítása 60000ms-ra 18 időkorlát és 240 építési idő után.
Aug 24 19:42:53.000 [notice] A hálózati kapcsolat sebessége megváltozott. Az időkorlát visszaállítása 60000ms-ra 18 időkorlát és 489 építési idő után.
Aug 24 19:43:11.000 [notice] A hálózati kapcsolat sebessége megváltozott. Az időkorlát visszaállítása 60000ms-ra 18 időkorlát és 659 építési idő után.
...
Aug 24 19:46:09.000 [notice] Rendkívül nagy érték az áramkör építési időkorláthoz: 122s. Feltételezve az óraugrás. 14. cél (Az áramköri időkorlát mérése)
Aug 24 19:46:09.000 [notice] Extremely large value for circuit build timeout: 122s. Feltételezve óraugrás. 14. cél (Az áramköri időkorlát mérése)
Aug 24 19:46:09.000 [notice] Úgy tűnik, hogy a hálózati kapcsolat sebessége megváltozott. Az időkorlát visszaállítása 60000ms-ra 18 időkorlát és 114 építési idő után.
Aug 24 19:46:15.000 [notice] Úgy tűnik, hogy a hálózati kapcsolat sebessége megváltozott. Az időkorlát visszaállítása 60000ms-ra 18 időkorlát és 125 építési idő után.
...
Aug 24 19:47:08.000 [notice] Rendkívül nagy érték az áramkör építési időkorláthoz: 123s. Feltételezve az óraugrás. 14. cél (Az áramköri időkorlát mérése)
Aug 24 19:47:10.000 [notice] Extremely large value for circuit build timeout: 122s. Feltételezve óraugrás. 14. cél (Az áramköri időkorlát mérése)
Aug 24 19:47:10.000 [notice] Extremely large value for circuit build timeout: 123s. Feltételezve óraugrás. 14. cél (Az áramköri időkorlát mérése)
Aug 24 19:47:13.000 [notice] Rendkívül nagy érték az áramkör építési időkorlátnál: 123s. Feltételezve óraugrás. 14. cél (Az áramköri időkorlát mérése)
Aug 24 19:47:14.000 [notice] A hálózati kapcsolat sebessége megváltozott. Az időkorlát visszaállítása 60000ms-ra 18 időkorlát és 495 építési idő után.
Aug 24 19:47:18.000 [notice] Úgy tűnik, hogy a hálózati kapcsolat sebessége megváltozott. Az időkorlát visszaállítása 60000ms-ra 18 időkorlát és 124 építési idő után.
Aug 24 19:47:21.000 [notice] Az áramkör építési időkorlátjának rendkívül nagy értéke: 122s. Feltételezhetően óraugrás. 14. cél (Az áramköri időkorlát mérése)
Aug 24 19:47:23.000 [notice] Rendkívül nagy érték az áramkör építési időkorlátnál: 123s. Feltételezve óraugrás. 14. cél (Az áramköri időkorlát mérése)
...
Aug 24 19:47:55.000 [notice] Úgy tűnik, hogy a hálózati kapcsolat sebessége megváltozott. Az időkorlát visszaállítása 60000ms-ra 18 időkorlát és 1000 felépítési idő után.
Aug 24 19:47:59.000 [notice] A hálózati kapcsolat sebessége megváltozott. A timeout visszaállítása 60000ms-ra 18 timeout és 117 buildtime után.
...
Aug 24 19:52:43.000 [notice] Furcsa érték az áramkör építési idejére: 121581msec. Feltételezhetően óraugrás. 14. cél (Az áramköri időkorlát mérése)
Aug 24 19:52:43.000 [notice] Úgy tűnik, hogy a hálózati kapcsolat sebessége megváltozott. Az időkorlát visszaállítása 120000ms-ra 18 időkorlát és 57 építési idő után.
Aug 24 19:52:53.000 [notice] Interrupt: tiszta kilépés.
4. Mivel próbálták megoldani a problémát?
- Teljesen új szervert állítottunk fel a semmiből, melyen csak alap OS, valamint tor és vanguards fut alapkonfigurációban, hogy kizárjuk a hibás konfiguráció lehetőségét az érintett szerverünkön. Amint a megtámadott descriptorral elindítottuk a tor-t, pontosan ugyanazok a dolgok történtek.
- Megpróbáltuk a szerverünk terhelését OnionBalance segítségével megosztani ebben a beállításban:
Server1: Onionbalance futtatása az elsődleges rejtett szolgáltatásleíróhoz.
Server2/3/4: Futtatja a rejtett szolgáltatást új és más rejtett szolgáltatás leírókon.
- Ez nem kelti életre az eredeti rejtett szolgáltatás leíróját.
- A 2/3/4 szervereken lévő szolgáltatásleírók közvetlenül megnyitva elérhetők, de a most kiegyensúlyozott elsődleges leírón keresztül nem.
- A 2/3/4 szerver CPU-ja 100%-ra megy fel, amíg a támadás zajlik, míg az 1. szerver (balancer) CPU-ja normális marad.
- További backend-kiszolgálók hozzáadása a balancerhez szintén nem hozott változást.
- Hozzáadtuk ezeket az irányelveket a torrc rejtett szolgáltatási blokkjához, és különböző beállításokat próbáltunk ki rajtuk:
HiddenServiceEnableIntroDoSDefense 1
HiddenServiceEnableIntroDoSBurstPerSec <különböző értékekkel tesztelve>.
HiddenServiceEnableIntroDoSRatePerSec <különböző értékekkel tesztelve>
Ez jelentősen csökkentette a CPU-terhelést a 2/3/4 szervereken, de a kiegyensúlyozott szolgáltatásleíró továbbra sem érhető el.
- Próbáltuk megváltoztatni a vanguards.conf különböző beállításait, sikertelenül.
- Megpróbáltuk azonosítani a támadó tcp csomagokat és blokkolni őket az iptables segítségével, sikertelenül.
Szakértelmünk nem elegendő ahhoz, hogy az említett tcp-csomagok tartalmát megvizsgálva, amelyek így néznek ki, ötleteket merítsünk arról, hogy pontosan mi történik:
19:45:27.839934 IP (tos 0x0, ttl 64, id 35746, offset 0, flags [DF], proto TCP (6), length 4100)
127.0.0.0.1.9051 > 127.0.0.0.1.46712: Flags [P.], cksum 0x0df9 (hibás -> 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=|---------(támadott rejtett szolgáltatásleíró)---------| 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=|---------(támadott rejtett szolgáltatásleíró)---------| 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=|---------(támadott rejtett szolgáltatásleíró)---------| 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=|---------(támadott rejtett szolgáltatásleíró)---------| TIME_CREATED=2022-08-24T19:45:25.10
Ez a Tor egyetlen szerveren futó Torral történik. Kiegyenlítéskor a |---------(megtámadott rejtett szolgáltatásleíró)---------| helyébe a 2/3/4 szerver backend szolgáltatásleírói lépnek.
Szükség esetén egy nagyobb tcpdump részletet is rendelkezésre tudunk bocsátani.
5. Következtetések
Úgy gondoljuk, hogy egy ellenfél képes "megszakítani" egy rejtett szolgáltatásleírót (és így magát a rejtett szolgáltatást is) azzal, hogy megszámlálhatatlan tcp csomaggal árasztja el a Tor démont, kérve áramkörök építését. Ez okozza a CPU-terhelést, és végül használhatatlanná teszi a Rejtett szolgáltatás leíróját.
Meg tudja ezt valaki erősíteni?
Mivel az olyan direktívák, mint az említett HiddenServiceEnableIntroDoSDoSDefense, HiddenServiceEnableIntroDoSBurstPerSec és HiddenServiceEnableIntroDoSRatePerSec úgy tűnik, hogy az ilyen jellegű támadások ellen védekeznek, ahogyan az előőrsöknek is kellene, nem tudjuk megmagyarázni, hogy ezek miért maradnak hatástalanok. Talán ezeknek az értékeknek néhány nagyon speciális beállítása szükséges ahhoz, hogy ezek az értékek hatékonyak legyenek. Sajnos ezek az irányelvek (csakúgy, mint a vanguards.config beállításai) csak homályosan vannak leírva.
Tudja valaki, hogy ezeket hogyan kell helyesen beállítani ahhoz, hogy hatékonyak legyenek?
Ezen a ponton minden hivatkozást kihúztunk a tor és a vanguards konfigurációról, amit az interneten találtunk.
Ismétlem, bármilyen segítséget vagy információt ezzel kapcsolatban nagyra értékelnénk! Nem hisszük, hogy erre nincs megoldás.
Ha bármi, amit itt leírtunk, értelmet nyer az Ön számára és/vagy van valami gyanúja azzal kapcsolatban, hogy mi folyik itt, bármilyen visszajelzést rendkívül nagyra értékelünk!
1. Mi történik?
A szolgáltatásunk sokáig jól és stabilan működött. Hirtelen szolgáltatásunk először enyhe, majd súlyos teljesítményproblémákat tapasztalt, majd teljesen elérhetetlenné vált.
Úgy tűnik, hogy ez nem egy "szokásos" DDoS támadás. Úgy tűnik, hogy ez egy DoS-támadás, de nem olyan, mint bármi más ismert, mivel úgy tűnik, hogy ez egy támadás csak a Tor démon ellen. Minden eddig próbált ellenintézkedés sikertelen volt. Nem észlelhető támadás a ténylegesen futó szolgáltatások (http, ssh, ftp, mail, stb.) ellen, hanem csak maga a Tor kapcsolat ellen.
Hiába végeztünk mélyreható kutatást és vizsgálatot, úgy tűnik, az esemény meghaladja a felfogóképességünket. A Tor Hidden Services elleni korábbi támadásokról szóló dokumentációkat ritkán találni, és nem áll össze azzal, amit mi tapasztalunk.
Nem vagyunk hajlandóak elhinni, hogy létezik egy olyan támadási forgatókönyv, amely ismeretlen és nem lehet ellene védekezni, mivel ez minden egyes Tor Rejtett Szolgáltatást sebezhetővé tenne, mivel az ellenfelek képesek lennének bármelyik Tor Rejtett Szolgáltatást tetszés szerint perceken belül, határozatlan időre offline állapotba hozni. A Tor közösségre gyakorolt hatás meghaladná a határokat.
Reméljük, hogy valaki, aki rendelkezik a szükséges rálátással és szakértelemmel, legalább egy tippet tud adni nekünk arról, hogy pontosan mi is történik, és a megfelelő irányba mutat, hogy találjunk egy megoldást a támadás befejezésére vagy a rendszerünkre gyakorolt hatásának csökkentésére, és az ilyen támadások megelőzésére a jövőben. Ez segítene megvédeni a Tor Rejtett Szolgáltatásokat világszerte a jövőbeni támadásoktól, mint amilyet most tapasztalunk.
2. Mi a beállítás?
- A rendszer egy aktuális és mindig naprakész linux (amd64) szerveren fut.
- Minden adatforgalom a Toron keresztül a Tor transporton keresztül a 9040-es porton keresztül történik, a DNS lekérdezések is a Toron keresztül oldódnak meg.
- A Tor Hidden Service v3-as verziója
- A Tor 0.4.7.8-as verziója Libevent 2.1.12-stable, OpenSSL 1.1.1.1n, Zlib 1.2.11, Liblzma 5.2.5, Libzstd 1.4.8 és Glibc 2.31 libc-ként fut.
- Tor a GCC 10.2.1-es verziójával fordított Tor. A Vanguards 0.3.1 is telepítve van.
- A Tor systemd szolgáltatásként fut
- A Vanguards systemd szolgáltatásként fut
torrc konfiguráció:
CookieAuthentication 1
HashedControlPassword 16:<hash>
VirtualAddrNetworkIPv4 10.192.0.0.0/10
AutomapHostsOnResolve 1
TransPort 127.0.0.0.1:9040
DNSPort 127.0.0.0.1:53
HiddenServiceDir /var/lib/tor/hidden_service
HiddenServicePort 80 127.0.0.0.1:80
HiddenServiceVersion 3
HiddenServiceAllowUnknownPorts 0
3. Mik a tünetek?
- Kevesebb mint egy perccel a Tor indítása után, amikor a Hidden Service be van kapcsolva, a CPU 100%-ra emelkedik, a memória nem tűnik érintettnek.
- A használt sávszélesség 100kb/s körül növekszik.
- A rejtett szolgáltatás leírója elérhetetlen.
- A rendszer továbbra is fel tudja oldani a clearnet és a Tor címeket.
- A rendszer továbbra is képes csatlakozni a kimenő szolgáltatásokhoz (pl. curl egy weboldalhoz).
- A rendszert elárasztják a bejövő tcp csomagok a loopback interfészen.
- A Tor újraindításakor az áradás néhány másodpercre megszűnik, majd újraindul.
- Ha a Tor-t a rejtett szolgáltatás engedélyezése nélkül indítjuk el, úgy tűnik, nincs probléma.
- Ha a Tor-t egy másik rejtett szolgáltatással indítjuk, mindkét rejtett szolgáltatás leírója elérhetetlen marad:
Tor böngésző az elsődleges HS-en:
Onionsite Has Disconnected
A legvalószínűbb ok, hogy az onionsite offline. Lépjen kapcsolatba az onionsite rendszergazdájával.
Részletek: 0xF2 - A bevezetés sikertelen, ami azt jelenti, hogy a leírót megtalálták, de a szolgáltatás már nem kapcsolódik a bevezetési ponthoz. Valószínű, hogy a szolgáltatás megváltoztatta a leíróját, vagy nem fut.
vagy
A kapcsolat megszűnt.
A (megtámadott rejtett szolgáltatásleíró).onion szerver túl sokáig tart a válaszadás.
Lehet, hogy a webhely átmenetileg nem elérhető vagy túlságosan elfoglalt. Próbálja meg újra néhány pillanat múlva.
Tor Browser a Seconday HS-en:
Nem sikerült csatlakozni
A Firefox nem tud kapcsolatot létesíteni a (másodlagos rejtett szolgáltatásleíró).onion alatti szerverrel.
Az oldal átmenetileg nem elérhető vagy túl elfoglalt lehet. Próbálja meg újra néhány pillanat múlva.
- Ha a Tor egy második rejtett szolgáltatás engedélyezésével indul, amelyet az OnionAuthentication véd, az elsődleges rejtett szolgáltatás leírója elérhetetlen marad,
a másodlagos (védett) rejtett szolgáltatás leírója elérhető.
- Ha a Tor-t csak a második rejtett szolgáltatással indítjuk (OnionAuthentication-nel vagy anélkül), úgy tűnik, nincs probléma.
- Ha a Tor-t az OnionAuthentication által védett elsődleges rejtett szolgáltatással indítjuk, a rejtett szolgáltatás leírója elérhető.
- Támadás esetén ezek a bejegyzések jelennek meg a tor naplófájlban:
Aug 24 19:42:18.000 [notice] Bootstrapped 100% (done): Kész
Aug 24 19:42:34.000 [notice] A hálózati kapcsolat sebessége megváltozott. A timeout visszaállítása 60000ms-ra 18 timeout és 388 buildtime után.
Aug 24 19:42:39.000 [notice] A hálózati kapcsolat sebessége megváltozott. Az időkorlát visszaállítása 60000ms-ra 18 időkorlát és 240 építési idő után.
Aug 24 19:42:53.000 [notice] A hálózati kapcsolat sebessége megváltozott. Az időkorlát visszaállítása 60000ms-ra 18 időkorlát és 489 építési idő után.
Aug 24 19:43:11.000 [notice] A hálózati kapcsolat sebessége megváltozott. Az időkorlát visszaállítása 60000ms-ra 18 időkorlát és 659 építési idő után.
...
Aug 24 19:46:09.000 [notice] Rendkívül nagy érték az áramkör építési időkorláthoz: 122s. Feltételezve az óraugrás. 14. cél (Az áramköri időkorlát mérése)
Aug 24 19:46:09.000 [notice] Extremely large value for circuit build timeout: 122s. Feltételezve óraugrás. 14. cél (Az áramköri időkorlát mérése)
Aug 24 19:46:09.000 [notice] Úgy tűnik, hogy a hálózati kapcsolat sebessége megváltozott. Az időkorlát visszaállítása 60000ms-ra 18 időkorlát és 114 építési idő után.
Aug 24 19:46:15.000 [notice] Úgy tűnik, hogy a hálózati kapcsolat sebessége megváltozott. Az időkorlát visszaállítása 60000ms-ra 18 időkorlát és 125 építési idő után.
...
Aug 24 19:47:08.000 [notice] Rendkívül nagy érték az áramkör építési időkorláthoz: 123s. Feltételezve az óraugrás. 14. cél (Az áramköri időkorlát mérése)
Aug 24 19:47:10.000 [notice] Extremely large value for circuit build timeout: 122s. Feltételezve óraugrás. 14. cél (Az áramköri időkorlát mérése)
Aug 24 19:47:10.000 [notice] Extremely large value for circuit build timeout: 123s. Feltételezve óraugrás. 14. cél (Az áramköri időkorlát mérése)
Aug 24 19:47:13.000 [notice] Rendkívül nagy érték az áramkör építési időkorlátnál: 123s. Feltételezve óraugrás. 14. cél (Az áramköri időkorlát mérése)
Aug 24 19:47:14.000 [notice] A hálózati kapcsolat sebessége megváltozott. Az időkorlát visszaállítása 60000ms-ra 18 időkorlát és 495 építési idő után.
Aug 24 19:47:18.000 [notice] Úgy tűnik, hogy a hálózati kapcsolat sebessége megváltozott. Az időkorlát visszaállítása 60000ms-ra 18 időkorlát és 124 építési idő után.
Aug 24 19:47:21.000 [notice] Az áramkör építési időkorlátjának rendkívül nagy értéke: 122s. Feltételezhetően óraugrás. 14. cél (Az áramköri időkorlát mérése)
Aug 24 19:47:23.000 [notice] Rendkívül nagy érték az áramkör építési időkorlátnál: 123s. Feltételezve óraugrás. 14. cél (Az áramköri időkorlát mérése)
...
Aug 24 19:47:55.000 [notice] Úgy tűnik, hogy a hálózati kapcsolat sebessége megváltozott. Az időkorlát visszaállítása 60000ms-ra 18 időkorlát és 1000 felépítési idő után.
Aug 24 19:47:59.000 [notice] A hálózati kapcsolat sebessége megváltozott. A timeout visszaállítása 60000ms-ra 18 timeout és 117 buildtime után.
...
Aug 24 19:52:43.000 [notice] Furcsa érték az áramkör építési idejére: 121581msec. Feltételezhetően óraugrás. 14. cél (Az áramköri időkorlát mérése)
Aug 24 19:52:43.000 [notice] Úgy tűnik, hogy a hálózati kapcsolat sebessége megváltozott. Az időkorlát visszaállítása 120000ms-ra 18 időkorlát és 57 építési idő után.
Aug 24 19:52:53.000 [notice] Interrupt: tiszta kilépés.
4. Mivel próbálták megoldani a problémát?
- Teljesen új szervert állítottunk fel a semmiből, melyen csak alap OS, valamint tor és vanguards fut alapkonfigurációban, hogy kizárjuk a hibás konfiguráció lehetőségét az érintett szerverünkön. Amint a megtámadott descriptorral elindítottuk a tor-t, pontosan ugyanazok a dolgok történtek.
- Megpróbáltuk a szerverünk terhelését OnionBalance segítségével megosztani ebben a beállításban:
Server1: Onionbalance futtatása az elsődleges rejtett szolgáltatásleíróhoz.
Server2/3/4: Futtatja a rejtett szolgáltatást új és más rejtett szolgáltatás leírókon.
- Ez nem kelti életre az eredeti rejtett szolgáltatás leíróját.
- A 2/3/4 szervereken lévő szolgáltatásleírók közvetlenül megnyitva elérhetők, de a most kiegyensúlyozott elsődleges leírón keresztül nem.
- A 2/3/4 szerver CPU-ja 100%-ra megy fel, amíg a támadás zajlik, míg az 1. szerver (balancer) CPU-ja normális marad.
- További backend-kiszolgálók hozzáadása a balancerhez szintén nem hozott változást.
- Hozzáadtuk ezeket az irányelveket a torrc rejtett szolgáltatási blokkjához, és különböző beállításokat próbáltunk ki rajtuk:
HiddenServiceEnableIntroDoSDefense 1
HiddenServiceEnableIntroDoSBurstPerSec <különböző értékekkel tesztelve>.
HiddenServiceEnableIntroDoSRatePerSec <különböző értékekkel tesztelve>
Ez jelentősen csökkentette a CPU-terhelést a 2/3/4 szervereken, de a kiegyensúlyozott szolgáltatásleíró továbbra sem érhető el.
- Próbáltuk megváltoztatni a vanguards.conf különböző beállításait, sikertelenül.
- Megpróbáltuk azonosítani a támadó tcp csomagokat és blokkolni őket az iptables segítségével, sikertelenül.
Szakértelmünk nem elegendő ahhoz, hogy az említett tcp-csomagok tartalmát megvizsgálva, amelyek így néznek ki, ötleteket merítsünk arról, hogy pontosan mi történik:
19:45:27.839934 IP (tos 0x0, ttl 64, id 35746, offset 0, flags [DF], proto TCP (6), length 4100)
127.0.0.0.1.9051 > 127.0.0.0.1.46712: Flags [P.], cksum 0x0df9 (hibás -> 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=|---------(támadott rejtett szolgáltatásleíró)---------| 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=|---------(támadott rejtett szolgáltatásleíró)---------| 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=|---------(támadott rejtett szolgáltatásleíró)---------| 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=|---------(támadott rejtett szolgáltatásleíró)---------| TIME_CREATED=2022-08-24T19:45:25.10
Ez a Tor egyetlen szerveren futó Torral történik. Kiegyenlítéskor a |---------(megtámadott rejtett szolgáltatásleíró)---------| helyébe a 2/3/4 szerver backend szolgáltatásleírói lépnek.
Szükség esetén egy nagyobb tcpdump részletet is rendelkezésre tudunk bocsátani.
5. Következtetések
Úgy gondoljuk, hogy egy ellenfél képes "megszakítani" egy rejtett szolgáltatásleírót (és így magát a rejtett szolgáltatást is) azzal, hogy megszámlálhatatlan tcp csomaggal árasztja el a Tor démont, kérve áramkörök építését. Ez okozza a CPU-terhelést, és végül használhatatlanná teszi a Rejtett szolgáltatás leíróját.
Meg tudja ezt valaki erősíteni?
Mivel az olyan direktívák, mint az említett HiddenServiceEnableIntroDoSDoSDefense, HiddenServiceEnableIntroDoSBurstPerSec és HiddenServiceEnableIntroDoSRatePerSec úgy tűnik, hogy az ilyen jellegű támadások ellen védekeznek, ahogyan az előőrsöknek is kellene, nem tudjuk megmagyarázni, hogy ezek miért maradnak hatástalanok. Talán ezeknek az értékeknek néhány nagyon speciális beállítása szükséges ahhoz, hogy ezek az értékek hatékonyak legyenek. Sajnos ezek az irányelvek (csakúgy, mint a vanguards.config beállításai) csak homályosan vannak leírva.
Tudja valaki, hogy ezeket hogyan kell helyesen beállítani ahhoz, hogy hatékonyak legyenek?
Ezen a ponton minden hivatkozást kihúztunk a tor és a vanguards konfigurációról, amit az interneten találtunk.
Ismétlem, bármilyen segítséget vagy információt ezzel kapcsolatban nagyra értékelnénk! Nem hisszük, hogy erre nincs megoldás.
Last edited:
