Paldies, ka veltījāt laiku, lai to izlasītu! Mēs neesam Tor tīklu eksperti, taču zinām, kā rīkoties.
Ja kaut kas no šeit aprakstītā jums liekas nesaprotams un/vai jums ir aizdomas par notiekošo, jebkura veida atgriezeniskā saite ir ārkārtīgi pateicīga!
1. Kas notiek?
Mūsu pakalpojums ilgu laiku darbojās labi un stabili. Pēkšņi mūsu pakalpojumam sākumā radās vieglas, pēc tam smagas veiktspējas problēmas, pēc tam tas kļuva pilnīgi nepieejams.
Šķiet, ka tas nav "parasts" DDoS uzbrukums. Šķiet, ka tas ir DoS uzbrukums, bet ne tāds, kāds zināms, jo šķiet, ka tas ir uzbrukums tikai Tor dēmonam. Visi līdz šim izmēģinātie pretpasākumi nebija veiksmīgi. Uzbrukums nav pamanāms faktiskajiem pakalpojumiem (http, ssh, ftp, pasts u. c.), bet tikai pašam Tor savienojumam.
Šķiet, ka šis notikums ir nesaprotams pat tad, ja mēs veicām padziļinātu izpēti un izmeklēšanu. Dokumentācija par iepriekšējiem uzbrukumiem Tor slēptajiem pakalpojumiem ir reti atrodama, un tai nav jēgas tam, ko mēs piedzīvojam.
Mēs atsakāmies ticēt, ka pastāv uzbrukuma scenārijs, kas nav zināms un kuram nav iespējams pretdarboties, jo tas padarītu neaizsargātu ikvienu Tor Slēpto pakalpojumu, jo pretinieki varētu pēc vēlēšanās dažu minūšu laikā uz nenoteiktu laiku atslēgt jebkuru Tor Slēpto pakalpojumu. Ietekme uz Tor kopienu būtu neaptverama.
Mēs ceram, ka kāds, kam ir nepieciešamā izpratne un zināšanas, var mums vismaz ieteikt, kas tieši notiek, un norādīt mums pareizo virzienu, lai rastu risinājumu, kā izbeigt šo uzbrukumu vai samazināt tā ietekmi uz mūsu sistēmām un novērst šādus uzbrukumus nākotnē. Tas palīdzētu aizsargāt Tor Hidden Services visā pasaulē no turpmākiem uzbrukumiem, līdzīgiem tam, ko piedzīvojam mēs.
2. Kāda ir uzstādīšana?
- Sistēma darbojas uz aktuāla un vienmēr atjaunināta linux (amd64) servera.
- Visa datplūsma tiek novirzīta caur Tor, izmantojot Tor transportu Tor portā 9040, arī DNS pieprasījumi tiek atrisināti, izmantojot Tor.
- Tor slēptais pakalpojums ir v3
- Tor ir 0.4.7.8 versija, kas darbojas ar Libevent 2.1.12-stable, OpenSSL 1.1.1n, Zlib 1.2.11, Liblzma 5.2.5, Libzstd 1.4.8 un Glibc 2.31 kā libc.
- Tor kompilēts ar GCC 10.2.1 versiju. Ir instalēta arī Vanguards 0.3.1.
- Tor darbojas kā systemd pakalpojums
- Vanguards darbojas kā systemd pakalpojums
Torrc konfigurācija:
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. Kādi ir simptomi?
- Nepilnu minūti pēc Tor palaišanas ar ieslēgtu Slēpto pakalpojumu procesors sasniedz 100 %, atmiņa šķiet neietekmēta.
- Izmantotās joslas platums palielinās aptuveni par 100 kb/s.
- Slēptā pakalpojuma deskriptors nav sasniedzams.
- Sistēma joprojām spēj atrisināt Clearnet un Tor adreses.
- Sistēma joprojām var izveidot savienojumu ar izejošajiem pakalpojumiem (piemēram, curl uz tīmekļa vietni).
- Sistēma tiek pārpludināta ar ienākošajām tcp paketēm uz cilpas saskarni.
- Kad Tor tiek restartēts, plūsma uz dažām sekundēm beidzas, bet pēc tam atkal sākas.
- Ja Tor tiek palaists bez ieslēgta slēptā pakalpojuma, šķiet, ka problēmu nav.
- Ja Tor tiek palaists ar ieslēgtu otru slēpto pakalpojumu, abi slēptā pakalpojuma deskriptori paliek nesasniedzami:
Tor pārlūks primārajā HS:
Tor: Tor: Tor Tor: Onionsite ir atvienojies: Tor: Tor: Tor: Onionsite ir atvienojies
Visticamākais iemesls ir tas, ka sīpolu vietne ir atvienota. Sazinieties ar onionsite administratoru.
Sīkāka informācija: Tas nozīmē, ka deskriptors tika atrasts, bet pakalpojums vairs nav savienots ar ievietošanas punktu. Iespējams, ka pakalpojums ir mainījis savu deskriptoru vai arī tas nedarbojas.
vai
Savienojums ir beidzies.
Servera adrese (uzbruka slēptais pakalpojuma deskriptors).onion atbilde aizņem pārāk ilgu laiku.
Iespējams, vietne uz laiku nav pieejama vai ir pārāk aizņemta. Mēģiniet vēlreiz pēc dažiem mirkļiem.
Tor pārlūks vietnē Seconday HS:
Nav iespējams izveidot savienojumu
Firefox nevar izveidot savienojumu ar serveri vietnē (sekundārais slēpto pakalpojumu deskriptors).onion.
Vietne varētu būt īslaicīgi nepieejama vai pārāk aizņemta. Mēģiniet vēlreiz pēc dažiem mirkļiem.
- Ja Tor tiek palaists ar ieslēgtu otru slēpto pakalpojumu, kas ir aizsargāts ar OnionAuthentication, primārais slēptais pakalpojuma deskriptors paliek nesasniedzams,
sekundārais (aizsargātais) slēptā pakalpojuma deskriptors ir sasniedzams.
- Ja Tor tiek palaists tikai ar iespējotu otro slēpto pakalpojumu (ar vai bez OnionAuthentication), šķiet, ka problēmu nav.
- Ja Tor tiek palaists ar primāro slēpto pakalpojumu, kas aizsargāts ar OnionAuthentication, slēpto pakalpojumu deskriptors ir sasniedzams.
- Uzbrukuma gadījumā šie ieraksti parādās Tor log failā:
Aug 24 19:42:18.000 [paziņojums] Bootstrapped 100% (done): Gatavs (pabeigts)
Aug 24 19:42:34.000 [paziņojums] Tīkla savienojuma ātrums, šķiet, ir mainījies. Atiestatīts timeout uz 60000ms pēc 18 timeout un 388 buildtimes.
Aug 24 19:42:39.000 [paziņojums] Tīkla savienojuma ātrums, šķiet, ir mainījies. Atiestatīts timeout uz 60000ms pēc 18 timeout un 240 buildtimes.
Aug 24 19:42:53.000 [paziņojums] Tīkla savienojuma ātrums, šķiet, ir mainījies. Atiestatīts timeout uz 60000ms pēc 18 timeout un 489 buildtimes.
Aug 24 19:43:11.000 [paziņojums] Tīkla savienojuma ātrums, šķiet, ir mainījies. Atiestatīts timeout uz 60000ms pēc 18 timeout un 659 buildtimes.
...
Aug 24 19:46:09.000 [paziņojums] Ārkārtīgi liela ķēdes izveides timeout vērtība: 122s. Pieņemot, ka pulksteņa lēciens. Mērķis Nr. 14 (Mērīšanas shēmas timeout)
Aug 24 19:46:09.000 [paziņojums] Ārkārtīgi liela ķēdes izveides timeout vērtība: 122s. Pieļaujot pulksteņa lēcienu. Mērķis 14 (Mērīšanas ķēdes timeout)
Aug 24 19:46:09.000 [paziņojums] Tīkla savienojuma ātrums, šķiet, ir mainījies. Atiestatīts timeout uz 60000ms pēc 18 timeout un 114 buildtimes.
Aug 24 19:46:15.000 [paziņojums] Tīkla savienojuma ātrums, šķiet, ir mainījies. Atiestatīts timeout uz 60000ms pēc 18 timeout un 125 buildtimes.
...
Aug 24 19:47:08.000 [paziņojums] Ārkārtīgi liela ķēdes izveides laika ierobežojuma vērtība: 123s. Pieņemot, ka pulksteņa lēciens. Mērķis 14 (Mērīšanas ķēdes timeout)
Aug 24 19:47:10.000 [paziņojums] Ārkārtīgi liela ķēdes izveides laika ierobežojuma vērtība: 122s. Pieņemot pulksteņa lēcienu. Mērķis 14 (Mērīšanas ķēdes timeout)
Aug 24 19:47:10.000 [paziņojums] Ārkārtīgi liela ķēdes izveides laika ierobežojuma vērtība: 123s. Pieļaujot pulksteņa lēcienu. Mērķis 14 (Mērīšanas ķēdes timeout)
Aug 24 19:47:13.000 [paziņojums] Ārkārtīgi liela ķēdes izveides laika ierobežojuma vērtība: 123s. Pieļaujot pulksteņa lēcienu. Mērķis 14 (Mērīšanas ķēdes timeout)
Aug 24 19:47:14.000 [paziņojums] Tīkla savienojuma ātrums, šķiet, ir mainījies. Atiestatīts timeout uz 60000ms pēc 18 timeout un 495 buildtimes.
Aug 24 19:47:18.000 [paziņojums] Tīkla savienojuma ātrums, šķiet, ir mainījies. Atiestatīts timeout uz 60000ms pēc 18 timeout un 124 buildtimes.
Aug 24 19:47:21.000 [paziņojums] Ārkārtīgi liela ķēdes izveides laika ierobežojuma vērtība: 122s. Pieļaujot pulksteņa lēcienu. Mērķis 14 (Mērīšanas ķēdes timeout)
Aug 24 19:47:23.000 [paziņojums] Ārkārtīgi liela ķēdes izveides laika ierobežojuma vērtība: 123s. Pieļaujot pulksteņa lēcienu. Mērķis 14 (Mērīšanas ķēdes timeout)
...
Aug 24 19:47:55.000 [paziņojums] Tīkla savienojuma ātrums, šķiet, ir mainījies. Atiestatīts timeout uz 60000ms pēc 18 timeout un 1000 buildtimes.
Aug 24 19:47:59.000 [paziņojums] Tīkla savienojuma ātrums, šķiet, ir mainījies. Atiestatīts timeout uz 60000ms pēc 18 timeout un 117 buildtimes.
...
Aug 24 19:52:43.000 [paziņojums] Dīvaina ķēdes veidošanas laika vērtība: 121581msec. Pieļaujot pulksteņa lēcienu. Mērķis 14 (Mērīšanas ķēdes timeout)
Aug 24 19:52:43.000 [paziņojums] Tīkla savienojuma ātrums, šķiet, ir mainījies. Atiestatīts timeout uz 120000ms pēc 18 timeout un 57 buildtimes.
Aug 24 19:52:53.000 [paziņojums] Pārtraukums: tīrs pārtraukums.
4. Kas tika izmēģināts, lai atrisinātu problēmu?
- Mēs izveidojām pilnīgi jaunu serveri no nulles, kurā darbojas tikai pamata OS, kā arī tor un vanguards standarta konfigurācijā, lai izslēgtu nepareizas konfigurācijas iespēju mūsu skartajā serverī. Tiklīdz tor tika palaists ar uzbrukuma deskriptoru, notiek tieši tas pats.
- Šajā konfigurācijā mēs mēģinājām sadalīt slodzi uz mūsu serveri, izmantojot OnionBalance:
Server1: palaists Onionbalance primārajam slēpto pakalpojumu deskriptoram.
Serveris2/3/4: Slēptā pakalpojuma palaišana jauniem un dažādiem slēptā pakalpojuma deskriptoriem.
- Tas neatjauno sākotnējā slēptā pakalpojuma deskriptora darbību.
- Pakalpojumu deskriptori uz 2/3/4 serveriem ir sasniedzami, ja tos atver tieši, bet ne caur tagad sabalansēto primāro deskriptoru.
- Serveru 2/3/4 procesora darbības laiks pieaug līdz 100%, kamēr notiek uzbrukums, bet 1. servera (balansētāja) procesora darbības laiks paliek normāls.
- Ja balansētājam pievienoja vairāk pakārtoto serveru, tas arī neko nemainīja.
- Mēs pievienojām šīs direktīvas torrc slēpto pakalpojumu blokam un izmēģinājām dažādus to iestatījumus:
HiddenServiceEnableIntroDoSDefense 1
HiddenServiceEnableIntroDoSBurstPerSec <testēts ar dažādām vērtībām>
HiddenServiceEnableIntroDoSRatePerSec <testēts ar dažādām vērtībām>
Tas ievērojami samazināja CPU slodzi uz 2/3/4 serveriem, bet līdzsvarotais pakalpojuma deskriptors joprojām nav sasniedzams.
- Mēs mēģinājām mainīt dažādus iestatījumus vanguards.conf, bet bez panākumiem.
- Mēs mēģinājām identificēt uzbrūkošās tcp paketes un bloķēt tās, izmantojot iptables, taču bez panākumiem.
Mūsu zināšanas nav pietiekamas, lai, pārbaudot minēto tcp pakešu saturu, kas izskatās šādi, radītu priekšstatus par to, kas tieši notiek:
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 (nepareizi -> 0xe713), seq 1543428574:1543432622, ack 1711981309, win 512, options [nop,nop,TS val 2971851406 ecr 2971851369], garums 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=|---------(uzbruka slēpto servisa deskriptoram)---------| 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=|---------(uzbruka slēpto pakalpojumu deskriptoram)---------| 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=|---------(uzbruka slēpto pakalpojumu deskriptoram)---------| 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=|---------(uzbruka slēpto pakalpojumu deskriptoram)---------| TIME_CREATED=2022-08-24T19:45:25.10
Tas ir ar Tor, kas darbojas vienā serverī. Ja tas ir sabalansēts, |---------(uzbruka slēpto pakalpojumu deskriptors)---------| tiek aizstāts ar 2/3/4 servera backends pakalpojumu deskriptoriem.
Vajadzības gadījumā mēs varam nodrošināt lielāku tcpdump fragmentu.
5. Secinājumi
Mēs uzskatām, ka pretiniekam ir iespēja "pārtraukt" slēpto pakalpojumu deskriptoru (un līdz ar to arī pašu slēpto pakalpojumu), pārpludinot Tor dēmonu ar neskaitāmām tcp paketēm, pieprasot veidot shēmas. Tas izraisa procesora noslodzi un galu galā padara Slēpto pakalpojumu deskriptoru nelietojamu.
Vai kāds to var apstiprināt?
Tā kā tādas direktīvas kā minētās HiddenServiceEnableIntroDoSDefense, HiddenServiceEnableIntroDoSBurstPerSec un HiddenServiceEnableIntroDoSRatePerSec, šķiet, ir domātas aizsardzībai pret šāda veida uzbrukumiem, tāpat kā tas būtu jādara arī avangardiem, mēs nevaram izskaidrot, kāpēc tās paliek neefektīvas. Varbūt ir nepieciešami kādi ļoti specializēti šo vērtību iestatījumi, lai tās būtu efektīvas. Diemžēl šīs direktīvas (kā arī iestatījumi vanguards.config) ir aprakstītas tikai neskaidri.
Vai kāds zina, kā tās pareizi jāiestata, lai tās būtu efektīvas?
Šobrīd mēs izsmēlām visas atsauces uz tor un vanguards konfigurāciju, ko varējām atrast tiešsaistē.
Vēlreiz, jebkura palīdzība vai informācija par šo jautājumu būtu ļoti pateicīga! Mēs neuzskatām, ka šim jautājumam nav risinājuma.
Ja kaut kas no šeit aprakstītā jums liekas nesaprotams un/vai jums ir aizdomas par notiekošo, jebkura veida atgriezeniskā saite ir ārkārtīgi pateicīga!
1. Kas notiek?
Mūsu pakalpojums ilgu laiku darbojās labi un stabili. Pēkšņi mūsu pakalpojumam sākumā radās vieglas, pēc tam smagas veiktspējas problēmas, pēc tam tas kļuva pilnīgi nepieejams.
Šķiet, ka tas nav "parasts" DDoS uzbrukums. Šķiet, ka tas ir DoS uzbrukums, bet ne tāds, kāds zināms, jo šķiet, ka tas ir uzbrukums tikai Tor dēmonam. Visi līdz šim izmēģinātie pretpasākumi nebija veiksmīgi. Uzbrukums nav pamanāms faktiskajiem pakalpojumiem (http, ssh, ftp, pasts u. c.), bet tikai pašam Tor savienojumam.
Šķiet, ka šis notikums ir nesaprotams pat tad, ja mēs veicām padziļinātu izpēti un izmeklēšanu. Dokumentācija par iepriekšējiem uzbrukumiem Tor slēptajiem pakalpojumiem ir reti atrodama, un tai nav jēgas tam, ko mēs piedzīvojam.
Mēs atsakāmies ticēt, ka pastāv uzbrukuma scenārijs, kas nav zināms un kuram nav iespējams pretdarboties, jo tas padarītu neaizsargātu ikvienu Tor Slēpto pakalpojumu, jo pretinieki varētu pēc vēlēšanās dažu minūšu laikā uz nenoteiktu laiku atslēgt jebkuru Tor Slēpto pakalpojumu. Ietekme uz Tor kopienu būtu neaptverama.
Mēs ceram, ka kāds, kam ir nepieciešamā izpratne un zināšanas, var mums vismaz ieteikt, kas tieši notiek, un norādīt mums pareizo virzienu, lai rastu risinājumu, kā izbeigt šo uzbrukumu vai samazināt tā ietekmi uz mūsu sistēmām un novērst šādus uzbrukumus nākotnē. Tas palīdzētu aizsargāt Tor Hidden Services visā pasaulē no turpmākiem uzbrukumiem, līdzīgiem tam, ko piedzīvojam mēs.
2. Kāda ir uzstādīšana?
- Sistēma darbojas uz aktuāla un vienmēr atjaunināta linux (amd64) servera.
- Visa datplūsma tiek novirzīta caur Tor, izmantojot Tor transportu Tor portā 9040, arī DNS pieprasījumi tiek atrisināti, izmantojot Tor.
- Tor slēptais pakalpojums ir v3
- Tor ir 0.4.7.8 versija, kas darbojas ar Libevent 2.1.12-stable, OpenSSL 1.1.1n, Zlib 1.2.11, Liblzma 5.2.5, Libzstd 1.4.8 un Glibc 2.31 kā libc.
- Tor kompilēts ar GCC 10.2.1 versiju. Ir instalēta arī Vanguards 0.3.1.
- Tor darbojas kā systemd pakalpojums
- Vanguards darbojas kā systemd pakalpojums
Torrc konfigurācija:
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. Kādi ir simptomi?
- Nepilnu minūti pēc Tor palaišanas ar ieslēgtu Slēpto pakalpojumu procesors sasniedz 100 %, atmiņa šķiet neietekmēta.
- Izmantotās joslas platums palielinās aptuveni par 100 kb/s.
- Slēptā pakalpojuma deskriptors nav sasniedzams.
- Sistēma joprojām spēj atrisināt Clearnet un Tor adreses.
- Sistēma joprojām var izveidot savienojumu ar izejošajiem pakalpojumiem (piemēram, curl uz tīmekļa vietni).
- Sistēma tiek pārpludināta ar ienākošajām tcp paketēm uz cilpas saskarni.
- Kad Tor tiek restartēts, plūsma uz dažām sekundēm beidzas, bet pēc tam atkal sākas.
- Ja Tor tiek palaists bez ieslēgta slēptā pakalpojuma, šķiet, ka problēmu nav.
- Ja Tor tiek palaists ar ieslēgtu otru slēpto pakalpojumu, abi slēptā pakalpojuma deskriptori paliek nesasniedzami:
Tor pārlūks primārajā HS:
Tor: Tor: Tor Tor: Onionsite ir atvienojies: Tor: Tor: Tor: Onionsite ir atvienojies
Visticamākais iemesls ir tas, ka sīpolu vietne ir atvienota. Sazinieties ar onionsite administratoru.
Sīkāka informācija: Tas nozīmē, ka deskriptors tika atrasts, bet pakalpojums vairs nav savienots ar ievietošanas punktu. Iespējams, ka pakalpojums ir mainījis savu deskriptoru vai arī tas nedarbojas.
vai
Savienojums ir beidzies.
Servera adrese (uzbruka slēptais pakalpojuma deskriptors).onion atbilde aizņem pārāk ilgu laiku.
Iespējams, vietne uz laiku nav pieejama vai ir pārāk aizņemta. Mēģiniet vēlreiz pēc dažiem mirkļiem.
Tor pārlūks vietnē Seconday HS:
Nav iespējams izveidot savienojumu
Firefox nevar izveidot savienojumu ar serveri vietnē (sekundārais slēpto pakalpojumu deskriptors).onion.
Vietne varētu būt īslaicīgi nepieejama vai pārāk aizņemta. Mēģiniet vēlreiz pēc dažiem mirkļiem.
- Ja Tor tiek palaists ar ieslēgtu otru slēpto pakalpojumu, kas ir aizsargāts ar OnionAuthentication, primārais slēptais pakalpojuma deskriptors paliek nesasniedzams,
sekundārais (aizsargātais) slēptā pakalpojuma deskriptors ir sasniedzams.
- Ja Tor tiek palaists tikai ar iespējotu otro slēpto pakalpojumu (ar vai bez OnionAuthentication), šķiet, ka problēmu nav.
- Ja Tor tiek palaists ar primāro slēpto pakalpojumu, kas aizsargāts ar OnionAuthentication, slēpto pakalpojumu deskriptors ir sasniedzams.
- Uzbrukuma gadījumā šie ieraksti parādās Tor log failā:
Aug 24 19:42:18.000 [paziņojums] Bootstrapped 100% (done): Gatavs (pabeigts)
Aug 24 19:42:34.000 [paziņojums] Tīkla savienojuma ātrums, šķiet, ir mainījies. Atiestatīts timeout uz 60000ms pēc 18 timeout un 388 buildtimes.
Aug 24 19:42:39.000 [paziņojums] Tīkla savienojuma ātrums, šķiet, ir mainījies. Atiestatīts timeout uz 60000ms pēc 18 timeout un 240 buildtimes.
Aug 24 19:42:53.000 [paziņojums] Tīkla savienojuma ātrums, šķiet, ir mainījies. Atiestatīts timeout uz 60000ms pēc 18 timeout un 489 buildtimes.
Aug 24 19:43:11.000 [paziņojums] Tīkla savienojuma ātrums, šķiet, ir mainījies. Atiestatīts timeout uz 60000ms pēc 18 timeout un 659 buildtimes.
...
Aug 24 19:46:09.000 [paziņojums] Ārkārtīgi liela ķēdes izveides timeout vērtība: 122s. Pieņemot, ka pulksteņa lēciens. Mērķis Nr. 14 (Mērīšanas shēmas timeout)
Aug 24 19:46:09.000 [paziņojums] Ārkārtīgi liela ķēdes izveides timeout vērtība: 122s. Pieļaujot pulksteņa lēcienu. Mērķis 14 (Mērīšanas ķēdes timeout)
Aug 24 19:46:09.000 [paziņojums] Tīkla savienojuma ātrums, šķiet, ir mainījies. Atiestatīts timeout uz 60000ms pēc 18 timeout un 114 buildtimes.
Aug 24 19:46:15.000 [paziņojums] Tīkla savienojuma ātrums, šķiet, ir mainījies. Atiestatīts timeout uz 60000ms pēc 18 timeout un 125 buildtimes.
...
Aug 24 19:47:08.000 [paziņojums] Ārkārtīgi liela ķēdes izveides laika ierobežojuma vērtība: 123s. Pieņemot, ka pulksteņa lēciens. Mērķis 14 (Mērīšanas ķēdes timeout)
Aug 24 19:47:10.000 [paziņojums] Ārkārtīgi liela ķēdes izveides laika ierobežojuma vērtība: 122s. Pieņemot pulksteņa lēcienu. Mērķis 14 (Mērīšanas ķēdes timeout)
Aug 24 19:47:10.000 [paziņojums] Ārkārtīgi liela ķēdes izveides laika ierobežojuma vērtība: 123s. Pieļaujot pulksteņa lēcienu. Mērķis 14 (Mērīšanas ķēdes timeout)
Aug 24 19:47:13.000 [paziņojums] Ārkārtīgi liela ķēdes izveides laika ierobežojuma vērtība: 123s. Pieļaujot pulksteņa lēcienu. Mērķis 14 (Mērīšanas ķēdes timeout)
Aug 24 19:47:14.000 [paziņojums] Tīkla savienojuma ātrums, šķiet, ir mainījies. Atiestatīts timeout uz 60000ms pēc 18 timeout un 495 buildtimes.
Aug 24 19:47:18.000 [paziņojums] Tīkla savienojuma ātrums, šķiet, ir mainījies. Atiestatīts timeout uz 60000ms pēc 18 timeout un 124 buildtimes.
Aug 24 19:47:21.000 [paziņojums] Ārkārtīgi liela ķēdes izveides laika ierobežojuma vērtība: 122s. Pieļaujot pulksteņa lēcienu. Mērķis 14 (Mērīšanas ķēdes timeout)
Aug 24 19:47:23.000 [paziņojums] Ārkārtīgi liela ķēdes izveides laika ierobežojuma vērtība: 123s. Pieļaujot pulksteņa lēcienu. Mērķis 14 (Mērīšanas ķēdes timeout)
...
Aug 24 19:47:55.000 [paziņojums] Tīkla savienojuma ātrums, šķiet, ir mainījies. Atiestatīts timeout uz 60000ms pēc 18 timeout un 1000 buildtimes.
Aug 24 19:47:59.000 [paziņojums] Tīkla savienojuma ātrums, šķiet, ir mainījies. Atiestatīts timeout uz 60000ms pēc 18 timeout un 117 buildtimes.
...
Aug 24 19:52:43.000 [paziņojums] Dīvaina ķēdes veidošanas laika vērtība: 121581msec. Pieļaujot pulksteņa lēcienu. Mērķis 14 (Mērīšanas ķēdes timeout)
Aug 24 19:52:43.000 [paziņojums] Tīkla savienojuma ātrums, šķiet, ir mainījies. Atiestatīts timeout uz 120000ms pēc 18 timeout un 57 buildtimes.
Aug 24 19:52:53.000 [paziņojums] Pārtraukums: tīrs pārtraukums.
4. Kas tika izmēģināts, lai atrisinātu problēmu?
- Mēs izveidojām pilnīgi jaunu serveri no nulles, kurā darbojas tikai pamata OS, kā arī tor un vanguards standarta konfigurācijā, lai izslēgtu nepareizas konfigurācijas iespēju mūsu skartajā serverī. Tiklīdz tor tika palaists ar uzbrukuma deskriptoru, notiek tieši tas pats.
- Šajā konfigurācijā mēs mēģinājām sadalīt slodzi uz mūsu serveri, izmantojot OnionBalance:
Server1: palaists Onionbalance primārajam slēpto pakalpojumu deskriptoram.
Serveris2/3/4: Slēptā pakalpojuma palaišana jauniem un dažādiem slēptā pakalpojuma deskriptoriem.
- Tas neatjauno sākotnējā slēptā pakalpojuma deskriptora darbību.
- Pakalpojumu deskriptori uz 2/3/4 serveriem ir sasniedzami, ja tos atver tieši, bet ne caur tagad sabalansēto primāro deskriptoru.
- Serveru 2/3/4 procesora darbības laiks pieaug līdz 100%, kamēr notiek uzbrukums, bet 1. servera (balansētāja) procesora darbības laiks paliek normāls.
- Ja balansētājam pievienoja vairāk pakārtoto serveru, tas arī neko nemainīja.
- Mēs pievienojām šīs direktīvas torrc slēpto pakalpojumu blokam un izmēģinājām dažādus to iestatījumus:
HiddenServiceEnableIntroDoSDefense 1
HiddenServiceEnableIntroDoSBurstPerSec <testēts ar dažādām vērtībām>
HiddenServiceEnableIntroDoSRatePerSec <testēts ar dažādām vērtībām>
Tas ievērojami samazināja CPU slodzi uz 2/3/4 serveriem, bet līdzsvarotais pakalpojuma deskriptors joprojām nav sasniedzams.
- Mēs mēģinājām mainīt dažādus iestatījumus vanguards.conf, bet bez panākumiem.
- Mēs mēģinājām identificēt uzbrūkošās tcp paketes un bloķēt tās, izmantojot iptables, taču bez panākumiem.
Mūsu zināšanas nav pietiekamas, lai, pārbaudot minēto tcp pakešu saturu, kas izskatās šādi, radītu priekšstatus par to, kas tieši notiek:
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 (nepareizi -> 0xe713), seq 1543428574:1543432622, ack 1711981309, win 512, options [nop,nop,TS val 2971851406 ecr 2971851369], garums 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=|---------(uzbruka slēpto servisa deskriptoram)---------| 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=|---------(uzbruka slēpto pakalpojumu deskriptoram)---------| 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=|---------(uzbruka slēpto pakalpojumu deskriptoram)---------| 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=|---------(uzbruka slēpto pakalpojumu deskriptoram)---------| TIME_CREATED=2022-08-24T19:45:25.10
Tas ir ar Tor, kas darbojas vienā serverī. Ja tas ir sabalansēts, |---------(uzbruka slēpto pakalpojumu deskriptors)---------| tiek aizstāts ar 2/3/4 servera backends pakalpojumu deskriptoriem.
Vajadzības gadījumā mēs varam nodrošināt lielāku tcpdump fragmentu.
5. Secinājumi
Mēs uzskatām, ka pretiniekam ir iespēja "pārtraukt" slēpto pakalpojumu deskriptoru (un līdz ar to arī pašu slēpto pakalpojumu), pārpludinot Tor dēmonu ar neskaitāmām tcp paketēm, pieprasot veidot shēmas. Tas izraisa procesora noslodzi un galu galā padara Slēpto pakalpojumu deskriptoru nelietojamu.
Vai kāds to var apstiprināt?
Tā kā tādas direktīvas kā minētās HiddenServiceEnableIntroDoSDefense, HiddenServiceEnableIntroDoSBurstPerSec un HiddenServiceEnableIntroDoSRatePerSec, šķiet, ir domātas aizsardzībai pret šāda veida uzbrukumiem, tāpat kā tas būtu jādara arī avangardiem, mēs nevaram izskaidrot, kāpēc tās paliek neefektīvas. Varbūt ir nepieciešami kādi ļoti specializēti šo vērtību iestatījumi, lai tās būtu efektīvas. Diemžēl šīs direktīvas (kā arī iestatījumi vanguards.config) ir aprakstītas tikai neskaidri.
Vai kāds zina, kā tās pareizi jāiestata, lai tās būtu efektīvas?
Šobrīd mēs izsmēlām visas atsauces uz tor un vanguards konfigurāciju, ko varējām atrast tiešsaistē.
Vēlreiz, jebkura palīdzība vai informācija par šo jautājumu būtu ļoti pateicīga! Mēs neuzskatām, ka šim jautājumam nav risinājuma.
Last edited:
