Grazie per aver dedicato del tempo alla lettura! Non siamo esperti di reti Tor, ma sappiamo come muoverci.
Se qualcosa di quanto descritto ha senso per voi e/o avete un sospetto su ciò che sta accadendo, qualsiasi tipo di feedback è estremamente apprezzato!
1. Cosa sta succedendo?
Il nostro servizio funzionava bene e in modo stabile per molto tempo. Improvvisamente il nostro servizio ha riscontrato problemi di prestazioni dapprima lievi e poi gravi, fino a diventare completamente irraggiungibile.
Non sembra trattarsi di un "normale" attacco DDoS. Sembra essere un attacco DoS, ma non come qualcosa di conosciuto, in quanto sembra essere un attacco al solo demone Tor. Tutte le contromisure provate finora non hanno avuto successo. Non si nota alcun attacco ai servizi in esecuzione (http, ssh, ftp, posta, ecc.) ma solo alla connessione Tor stessa.
Anche se abbiamo fatto ricerche e indagini approfondite, l'evento sembra essere al di là della nostra comprensione. Le documentazioni su precedenti attacchi ai servizi nascosti Tor sono rare da trovare e non hanno senso per quello che stiamo vivendo.
Ci rifiutiamo di credere che esista uno scenario di attacco sconosciuto e che non possa essere contrastato, in quanto renderebbe ogni singolo servizio nascosto Tor vulnerabile, con gli avversari in grado di mettere offline a piacimento qualsiasi servizio nascosto Tor in pochi minuti e per un tempo indefinito. L'impatto sulla comunità Tor sarebbe oltre ogni limite.
Ci auguriamo che qualcuno con l'intuizione e l'esperienza necessarie possa almeno darci un indizio su cosa sta succedendo esattamente e indicarci la giusta direzione per trovare una soluzione per porre fine a questo attacco o per ridurne l'impatto sui nostri sistemi e per prevenire tali attacchi in futuro. Questo aiuterebbe a proteggere i servizi Tor Hidden di tutto il mondo da futuri attacchi come quello che stiamo subendo.
2. Qual è la configurazione?
- Il sistema funziona su un server Linux (amd64) attuale e sempre aggiornato.
- Tutto il traffico viene instradato attraverso Tor tramite il trasporto Tor sulla porta 9040, anche le query DNS vengono risolte tramite Tor.
- Il servizio Tor Hidden è v3
- Tor è la versione 0.4.7.8 che gira con Libevent 2.1.12-stable, OpenSSL 1.1.1n, Zlib 1.2.11, Liblzma 5.2.5, Libzstd 1.4.8 e Glibc 2.31 come libc
- Tor compilato con GCC versione 10.2.1. È installato anche Vanguards 0.3.1.
- Tor è in esecuzione come servizio systemd
- Vanguards è in esecuzione come servizio systemd
configurazione 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. Quali sono i sintomi?
- Dopo meno di un minuto dall'avvio di Tor con il servizio nascosto abilitato, la CPU raggiunge il 100%, mentre la memoria sembra inalterata.
- La larghezza di banda utilizzata aumenta di circa 100kb/s
- Il descrittore del servizio nascosto è irraggiungibile.
- Il sistema è ancora in grado di risolvere gli indirizzi clearnet e Tor
- Il sistema può ancora connettersi a servizi in uscita (es. curl a un sito web).
- Il sistema viene inondato di pacchetti tcp in entrata sull'interfaccia di loopback
- Quando Tor viene riavviato, l'inondazione termina per alcuni secondi e poi ricomincia.
- Quando Tor viene avviato senza il servizio Hidden abilitato, non sembra esserci alcun problema.
- Quando Tor viene avviato con un secondo servizio nascosto abilitato, entrambi i descrittori del servizio nascosto rimangono irraggiungibili:
Browser Tor su HS primario:
Onionsite si è disconnesso
La causa più probabile è che l'onionsite sia offline. Contattare l'amministratore di onionsite.
Dettagli: 0xF2 - Introduzione fallita, il che significa che il descrittore è stato trovato ma il servizio non è più connesso al punto di introduzione. È probabile che il servizio abbia cambiato descrittore o che non sia in esecuzione.
oppure
La connessione è scaduta
Il server all'indirizzo (descrittore di servizio nascosto attaccato).onion sta impiegando troppo tempo per rispondere.
Il sito potrebbe essere temporaneamente non disponibile o troppo occupato. Riprovare tra qualche istante.
Browser Tor su Seconday HS:
Impossibile connettersi
Firefox non riesce a stabilire una connessione al server (descrittore di servizio secondario nascosto).onion
Il sito potrebbe essere temporaneamente non disponibile o troppo occupato. Riprovare tra qualche istante.
- Quando Tor viene avviato con un secondo servizio nascosto abilitato, protetto da OnionAuthentication, il descrittore del servizio nascosto primario rimane irraggiungibile,
il descrittore del servizio nascosto secondario (protetto) è raggiungibile.
- Quando Tor viene avviato solo con il secondo servizio nascosto abilitato (con o senza OnionAuthentication) non sembra esserci alcun problema.
- Quando Tor viene avviato con il servizio nascosto primario protetto da OnionAuthentication, il descrittore del servizio nascosto è raggiungibile.
- Quando viene attaccato, nel file di log di Tor appaiono queste voci:
Aug 24 19:42:18.000 [notice] Bootstrapped 100% (done): Fatto
Aug 24 19:42:34.000 [notice] La velocità di connessione alla rete sembra essere cambiata. Ripristino del timeout a 60000ms dopo 18 timeout e 388 buildtime.
Aug 24 19:42:39.000 [notice] La velocità di connessione alla rete sembra essere cambiata. Ripristino del timeout a 60000ms dopo 18 timeout e 240 buildtime.
Aug 24 19:42:53.000 [notice] La velocità di connessione alla rete sembra essere cambiata. Ripristino del timeout a 60000ms dopo 18 timeout e 489 buildtime.
Aug 24 19:43:11.000 [notice] La velocità di connessione alla rete sembra essere cambiata. Ripristino del timeout a 60000ms dopo 18 timeout e 659 buildtime.
...
Aug 24 19:46:09.000 [notice] Valore estremamente grande per il timeout di costruzione del circuito: 122s. Si ipotizza un salto di orologio. Scopo 14 (Misurazione del timeout del circuito)
Aug 24 19:46:09.000 [notice] Valore estremamente grande per il timeout di costruzione del circuito: 122s. Si ipotizza un salto di clock. Scopo 14 (Misurazione del timeout del circuito)
Aug 24 19:46:09.000 [notice] La velocità di connessione alla rete sembra essere cambiata. Ripristino del timeout a 60000ms dopo 18 timeout e 114 buildtime.
Aug 24 19:46:15.000 [notice] La velocità della connessione di rete sembra essere cambiata. Ripristino del timeout a 60000ms dopo 18 timeout e 125 buildtime.
...
Aug 24 19:47:08.000 [notice] Valore estremamente grande per il timeout di costruzione del circuito: 123s. Si ipotizza un salto di orologio. Scopo 14 (Misurazione del timeout del circuito)
Aug 24 19:47:10.000 [notice] Valore estremamente grande per il timeout di costruzione del circuito: 122s. Si ipotizza un salto di clock. Scopo 14 (Misurazione del timeout del circuito)
Aug 24 19:47:10.000 [notice] Valore estremamente grande per il timeout di costruzione del circuito: 123s. Si ipotizza un salto di clock. Scopo 14 (Misurazione del timeout del circuito)
Aug 24 19:47:13.000 [notice] Valore estremamente grande per il timeout di costruzione del circuito: 123s. Si ipotizza un salto di clock. Scopo 14 (Misurazione del timeout del circuito)
Aug 24 19:47:14.000 [notice] La velocità di connessione alla rete sembra essere cambiata. Ripristino del timeout a 60000ms dopo 18 timeout e 495 buildtime.
Aug 24 19:47:18.000 [notice] La velocità della connessione di rete sembra essere cambiata. Ripristino del timeout a 60000ms dopo 18 timeout e 124 buildtime.
Aug 24 19:47:21.000 [notice] Valore estremamente grande per il timeout di costruzione del circuito: 122s. Si ipotizza un salto di orologio. Scopo 14 (Misurazione del timeout del circuito)
Aug 24 19:47:23.000 [notice] Valore estremamente grande per il timeout di costruzione del circuito: 123s. Si ipotizza un salto di clock. Scopo 14 (Misurazione del timeout del circuito)
...
Aug 24 19:47:55.000 [notice] La velocità di connessione alla rete sembra essere cambiata. Ripristino del timeout a 60000ms dopo 18 timeout e 1000 buildtime.
Aug 24 19:47:59.000 [notice] La velocità della connessione di rete sembra essere cambiata. Ripristino del timeout a 60000ms dopo 18 timeout e 117 buildtime.
...
Aug 24 19:52:43.000 [notice] Strano valore per il tempo di costruzione del circuito: 121581msec. Si ipotizza un salto di orologio. Scopo 14 (Misurazione del timeout del circuito)
Aug 24 19:52:43.000 [notice] La velocità di connessione alla rete sembra essere cambiata. Ripristino del timeout a 120000ms dopo 18 timeout e 57 buildtime.
Aug 24 19:52:53.000 [notice] Interruzione: uscita pulita.
4. Cosa è stato fatto per risolvere il problema?
- Abbiamo configurato un server completamente nuovo da zero con solo il sistema operativo di base e tor e vanguard in configurazione standard per escludere la possibilità di una configurazione errata sul nostro server interessato. Non appena tor è stato avviato con il descrittore attaccato, si sono verificate le stesse identiche cose.
- Abbiamo provato a dividere il carico sul nostro server tramite OnionBalance in questa configurazione:
Server1: Esegue Onionbalance per il descrittore primario del servizio nascosto.
Server2/3/4: esegue il servizio nascosto su nuovi e diversi descrittori di servizi nascosti.
- Questo non riporta in vita il descrittore del servizio nascosto originale.
- I descrittori di servizio sui server 2/3/4 sono raggiungibili se aperti direttamente, ma non tramite il descrittore primario ora bilanciato
- La CPU dei server 2/3/4 arriva al 100% finché l'attacco ha luogo, mentre la CPU del server 1 (bilanciatore) rimane normale.
- Anche l'aggiunta di altri server backend al bilanciatore non ha fatto la differenza.
- Abbiamo aggiunto queste direttive al blocco dei servizi nascosti in torrc e abbiamo provato diverse impostazioni:
HiddenServiceEnableIntroDoSDefense 1
HiddenServiceEnableIntroDoSBurstPerSec <testato con vari valori
HiddenServiceEnableIntroDoSRatePerSec <testato con vari valori>
Questo ha ridotto significativamente il carico della CPU sui server 2/3/4, ma il descrittore del servizio bilanciato rimane irraggiungibile.
- Abbiamo provato a modificare varie impostazioni in vanguards.conf, senza successo.
- Abbiamo provato a identificare i pacchetti tcp attaccanti e a bloccarli tramite iptables, senza successo.
Le nostre competenze non sono sufficienti per capire cosa stia accadendo esattamente ispezionando il contenuto di tali pacchetti tcp, che hanno questo aspetto:
19:45:27.839934 IP (tos 0x0, ttl 64, id 35746, offset 0, flags [DF], proto TCP (6), lunghezza 4100)
127.0.0.1.9051 > 127.0.0.1.46712: Flags [P.], cksum 0x0df9 (errato -> 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=|---------(attaccato descrittore di servizio nascosto)---------| 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=|---------(attaccato descrittore di servizio nascosto)---------| 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=|---------(attaccato descrittore di servizio nascosto)---------| 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=|---------(attaccato descrittore di servizio nascosto)---------| TIME_CREATED=2022-08-24T19:45:25.10
Questo avviene con Tor in esecuzione su un singolo server. Quando è bilanciato, il |---------(descrittore di servizio nascosto attaccato)---------| è sostituito dai descrittori di servizio dei backend di 2/3/4 server.
Se necessario, possiamo mettere a disposizione un frammento di tcpdump più grande.
5. Conclusioni
Riteniamo che un avversario sia in grado di "interrompere" un descrittore di servizio nascosto (e quindi il servizio nascosto stesso) inondando il demone Tor con innumerevoli pacchetti tcp, con la richiesta di costruire circuiti. Questo è ciò che causa il carico della CPU e che alla fine rende inutilizzabile il descrittore del servizio nascosto.
Qualcuno può confermarlo?
Poiché direttive come HiddenServiceEnableIntroDoSDefense, HiddenServiceEnableIntroDoSBurstPerSec e HiddenServiceEnableIntroDoSRatePerSec sembrano destinate a difendere da questo tipo di attacchi, proprio come dovrebbero fare anche le avanguardie, non riusciamo a spiegarci perché rimangano inefficaci. Forse sono necessarie alcune impostazioni molto specializzate di questi valori per renderli efficaci. Purtroppo queste direttive (così come le impostazioni in vanguards.config) sono descritte solo in modo vago.
Qualcuno sa come devono essere impostate correttamente per essere efficaci?
A questo punto abbiamo esaurito tutti i riferimenti a tor e alla configurazione di vanguards che abbiamo trovato online.
Ancora una volta, qualsiasi aiuto o informazione su questo problema sarebbe molto apprezzato! Non crediamo che non ci sia una soluzione a questo problema.
Se qualcosa di quanto descritto ha senso per voi e/o avete un sospetto su ciò che sta accadendo, qualsiasi tipo di feedback è estremamente apprezzato!
1. Cosa sta succedendo?
Il nostro servizio funzionava bene e in modo stabile per molto tempo. Improvvisamente il nostro servizio ha riscontrato problemi di prestazioni dapprima lievi e poi gravi, fino a diventare completamente irraggiungibile.
Non sembra trattarsi di un "normale" attacco DDoS. Sembra essere un attacco DoS, ma non come qualcosa di conosciuto, in quanto sembra essere un attacco al solo demone Tor. Tutte le contromisure provate finora non hanno avuto successo. Non si nota alcun attacco ai servizi in esecuzione (http, ssh, ftp, posta, ecc.) ma solo alla connessione Tor stessa.
Anche se abbiamo fatto ricerche e indagini approfondite, l'evento sembra essere al di là della nostra comprensione. Le documentazioni su precedenti attacchi ai servizi nascosti Tor sono rare da trovare e non hanno senso per quello che stiamo vivendo.
Ci rifiutiamo di credere che esista uno scenario di attacco sconosciuto e che non possa essere contrastato, in quanto renderebbe ogni singolo servizio nascosto Tor vulnerabile, con gli avversari in grado di mettere offline a piacimento qualsiasi servizio nascosto Tor in pochi minuti e per un tempo indefinito. L'impatto sulla comunità Tor sarebbe oltre ogni limite.
Ci auguriamo che qualcuno con l'intuizione e l'esperienza necessarie possa almeno darci un indizio su cosa sta succedendo esattamente e indicarci la giusta direzione per trovare una soluzione per porre fine a questo attacco o per ridurne l'impatto sui nostri sistemi e per prevenire tali attacchi in futuro. Questo aiuterebbe a proteggere i servizi Tor Hidden di tutto il mondo da futuri attacchi come quello che stiamo subendo.
2. Qual è la configurazione?
- Il sistema funziona su un server Linux (amd64) attuale e sempre aggiornato.
- Tutto il traffico viene instradato attraverso Tor tramite il trasporto Tor sulla porta 9040, anche le query DNS vengono risolte tramite Tor.
- Il servizio Tor Hidden è v3
- Tor è la versione 0.4.7.8 che gira con Libevent 2.1.12-stable, OpenSSL 1.1.1n, Zlib 1.2.11, Liblzma 5.2.5, Libzstd 1.4.8 e Glibc 2.31 come libc
- Tor compilato con GCC versione 10.2.1. È installato anche Vanguards 0.3.1.
- Tor è in esecuzione come servizio systemd
- Vanguards è in esecuzione come servizio systemd
configurazione 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. Quali sono i sintomi?
- Dopo meno di un minuto dall'avvio di Tor con il servizio nascosto abilitato, la CPU raggiunge il 100%, mentre la memoria sembra inalterata.
- La larghezza di banda utilizzata aumenta di circa 100kb/s
- Il descrittore del servizio nascosto è irraggiungibile.
- Il sistema è ancora in grado di risolvere gli indirizzi clearnet e Tor
- Il sistema può ancora connettersi a servizi in uscita (es. curl a un sito web).
- Il sistema viene inondato di pacchetti tcp in entrata sull'interfaccia di loopback
- Quando Tor viene riavviato, l'inondazione termina per alcuni secondi e poi ricomincia.
- Quando Tor viene avviato senza il servizio Hidden abilitato, non sembra esserci alcun problema.
- Quando Tor viene avviato con un secondo servizio nascosto abilitato, entrambi i descrittori del servizio nascosto rimangono irraggiungibili:
Browser Tor su HS primario:
Onionsite si è disconnesso
La causa più probabile è che l'onionsite sia offline. Contattare l'amministratore di onionsite.
Dettagli: 0xF2 - Introduzione fallita, il che significa che il descrittore è stato trovato ma il servizio non è più connesso al punto di introduzione. È probabile che il servizio abbia cambiato descrittore o che non sia in esecuzione.
oppure
La connessione è scaduta
Il server all'indirizzo (descrittore di servizio nascosto attaccato).onion sta impiegando troppo tempo per rispondere.
Il sito potrebbe essere temporaneamente non disponibile o troppo occupato. Riprovare tra qualche istante.
Browser Tor su Seconday HS:
Impossibile connettersi
Firefox non riesce a stabilire una connessione al server (descrittore di servizio secondario nascosto).onion
Il sito potrebbe essere temporaneamente non disponibile o troppo occupato. Riprovare tra qualche istante.
- Quando Tor viene avviato con un secondo servizio nascosto abilitato, protetto da OnionAuthentication, il descrittore del servizio nascosto primario rimane irraggiungibile,
il descrittore del servizio nascosto secondario (protetto) è raggiungibile.
- Quando Tor viene avviato solo con il secondo servizio nascosto abilitato (con o senza OnionAuthentication) non sembra esserci alcun problema.
- Quando Tor viene avviato con il servizio nascosto primario protetto da OnionAuthentication, il descrittore del servizio nascosto è raggiungibile.
- Quando viene attaccato, nel file di log di Tor appaiono queste voci:
Aug 24 19:42:18.000 [notice] Bootstrapped 100% (done): Fatto
Aug 24 19:42:34.000 [notice] La velocità di connessione alla rete sembra essere cambiata. Ripristino del timeout a 60000ms dopo 18 timeout e 388 buildtime.
Aug 24 19:42:39.000 [notice] La velocità di connessione alla rete sembra essere cambiata. Ripristino del timeout a 60000ms dopo 18 timeout e 240 buildtime.
Aug 24 19:42:53.000 [notice] La velocità di connessione alla rete sembra essere cambiata. Ripristino del timeout a 60000ms dopo 18 timeout e 489 buildtime.
Aug 24 19:43:11.000 [notice] La velocità di connessione alla rete sembra essere cambiata. Ripristino del timeout a 60000ms dopo 18 timeout e 659 buildtime.
...
Aug 24 19:46:09.000 [notice] Valore estremamente grande per il timeout di costruzione del circuito: 122s. Si ipotizza un salto di orologio. Scopo 14 (Misurazione del timeout del circuito)
Aug 24 19:46:09.000 [notice] Valore estremamente grande per il timeout di costruzione del circuito: 122s. Si ipotizza un salto di clock. Scopo 14 (Misurazione del timeout del circuito)
Aug 24 19:46:09.000 [notice] La velocità di connessione alla rete sembra essere cambiata. Ripristino del timeout a 60000ms dopo 18 timeout e 114 buildtime.
Aug 24 19:46:15.000 [notice] La velocità della connessione di rete sembra essere cambiata. Ripristino del timeout a 60000ms dopo 18 timeout e 125 buildtime.
...
Aug 24 19:47:08.000 [notice] Valore estremamente grande per il timeout di costruzione del circuito: 123s. Si ipotizza un salto di orologio. Scopo 14 (Misurazione del timeout del circuito)
Aug 24 19:47:10.000 [notice] Valore estremamente grande per il timeout di costruzione del circuito: 122s. Si ipotizza un salto di clock. Scopo 14 (Misurazione del timeout del circuito)
Aug 24 19:47:10.000 [notice] Valore estremamente grande per il timeout di costruzione del circuito: 123s. Si ipotizza un salto di clock. Scopo 14 (Misurazione del timeout del circuito)
Aug 24 19:47:13.000 [notice] Valore estremamente grande per il timeout di costruzione del circuito: 123s. Si ipotizza un salto di clock. Scopo 14 (Misurazione del timeout del circuito)
Aug 24 19:47:14.000 [notice] La velocità di connessione alla rete sembra essere cambiata. Ripristino del timeout a 60000ms dopo 18 timeout e 495 buildtime.
Aug 24 19:47:18.000 [notice] La velocità della connessione di rete sembra essere cambiata. Ripristino del timeout a 60000ms dopo 18 timeout e 124 buildtime.
Aug 24 19:47:21.000 [notice] Valore estremamente grande per il timeout di costruzione del circuito: 122s. Si ipotizza un salto di orologio. Scopo 14 (Misurazione del timeout del circuito)
Aug 24 19:47:23.000 [notice] Valore estremamente grande per il timeout di costruzione del circuito: 123s. Si ipotizza un salto di clock. Scopo 14 (Misurazione del timeout del circuito)
...
Aug 24 19:47:55.000 [notice] La velocità di connessione alla rete sembra essere cambiata. Ripristino del timeout a 60000ms dopo 18 timeout e 1000 buildtime.
Aug 24 19:47:59.000 [notice] La velocità della connessione di rete sembra essere cambiata. Ripristino del timeout a 60000ms dopo 18 timeout e 117 buildtime.
...
Aug 24 19:52:43.000 [notice] Strano valore per il tempo di costruzione del circuito: 121581msec. Si ipotizza un salto di orologio. Scopo 14 (Misurazione del timeout del circuito)
Aug 24 19:52:43.000 [notice] La velocità di connessione alla rete sembra essere cambiata. Ripristino del timeout a 120000ms dopo 18 timeout e 57 buildtime.
Aug 24 19:52:53.000 [notice] Interruzione: uscita pulita.
4. Cosa è stato fatto per risolvere il problema?
- Abbiamo configurato un server completamente nuovo da zero con solo il sistema operativo di base e tor e vanguard in configurazione standard per escludere la possibilità di una configurazione errata sul nostro server interessato. Non appena tor è stato avviato con il descrittore attaccato, si sono verificate le stesse identiche cose.
- Abbiamo provato a dividere il carico sul nostro server tramite OnionBalance in questa configurazione:
Server1: Esegue Onionbalance per il descrittore primario del servizio nascosto.
Server2/3/4: esegue il servizio nascosto su nuovi e diversi descrittori di servizi nascosti.
- Questo non riporta in vita il descrittore del servizio nascosto originale.
- I descrittori di servizio sui server 2/3/4 sono raggiungibili se aperti direttamente, ma non tramite il descrittore primario ora bilanciato
- La CPU dei server 2/3/4 arriva al 100% finché l'attacco ha luogo, mentre la CPU del server 1 (bilanciatore) rimane normale.
- Anche l'aggiunta di altri server backend al bilanciatore non ha fatto la differenza.
- Abbiamo aggiunto queste direttive al blocco dei servizi nascosti in torrc e abbiamo provato diverse impostazioni:
HiddenServiceEnableIntroDoSDefense 1
HiddenServiceEnableIntroDoSBurstPerSec <testato con vari valori
HiddenServiceEnableIntroDoSRatePerSec <testato con vari valori>
Questo ha ridotto significativamente il carico della CPU sui server 2/3/4, ma il descrittore del servizio bilanciato rimane irraggiungibile.
- Abbiamo provato a modificare varie impostazioni in vanguards.conf, senza successo.
- Abbiamo provato a identificare i pacchetti tcp attaccanti e a bloccarli tramite iptables, senza successo.
Le nostre competenze non sono sufficienti per capire cosa stia accadendo esattamente ispezionando il contenuto di tali pacchetti tcp, che hanno questo aspetto:
19:45:27.839934 IP (tos 0x0, ttl 64, id 35746, offset 0, flags [DF], proto TCP (6), lunghezza 4100)
127.0.0.1.9051 > 127.0.0.1.46712: Flags [P.], cksum 0x0df9 (errato -> 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=|---------(attaccato descrittore di servizio nascosto)---------| 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=|---------(attaccato descrittore di servizio nascosto)---------| 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=|---------(attaccato descrittore di servizio nascosto)---------| 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=|---------(attaccato descrittore di servizio nascosto)---------| TIME_CREATED=2022-08-24T19:45:25.10
Questo avviene con Tor in esecuzione su un singolo server. Quando è bilanciato, il |---------(descrittore di servizio nascosto attaccato)---------| è sostituito dai descrittori di servizio dei backend di 2/3/4 server.
Se necessario, possiamo mettere a disposizione un frammento di tcpdump più grande.
5. Conclusioni
Riteniamo che un avversario sia in grado di "interrompere" un descrittore di servizio nascosto (e quindi il servizio nascosto stesso) inondando il demone Tor con innumerevoli pacchetti tcp, con la richiesta di costruire circuiti. Questo è ciò che causa il carico della CPU e che alla fine rende inutilizzabile il descrittore del servizio nascosto.
Qualcuno può confermarlo?
Poiché direttive come HiddenServiceEnableIntroDoSDefense, HiddenServiceEnableIntroDoSBurstPerSec e HiddenServiceEnableIntroDoSRatePerSec sembrano destinate a difendere da questo tipo di attacchi, proprio come dovrebbero fare anche le avanguardie, non riusciamo a spiegarci perché rimangano inefficaci. Forse sono necessarie alcune impostazioni molto specializzate di questi valori per renderli efficaci. Purtroppo queste direttive (così come le impostazioni in vanguards.config) sono descritte solo in modo vago.
Qualcuno sa come devono essere impostate correttamente per essere efficaci?
A questo punto abbiamo esaurito tutti i riferimenti a tor e alla configurazione di vanguards che abbiamo trovato online.
Ancora una volta, qualsiasi aiuto o informazione su questo problema sarebbe molto apprezzato! Non crediamo che non ci sia una soluzione a questo problema.
Last edited:
