Obrigado por dedicar algum tempo a ler isto! Não somos especialistas em redes Tor, mas sabemos o que fazer.
Se alguma coisa aqui descrita faz sentido para ti e/ou tens alguma suspeita sobre o que se está a passar, qualquer tipo de feedback é extremamente apreciado!
1. O que está a acontecer?
O nosso serviço estava a funcionar bem e estável durante muito tempo. De repente, o nosso serviço começou a ter problemas de desempenho ligeiros, depois graves, e depois ficou completamente inacessível.
Isto não parece ser um ataque DDoS "normal". Parece ser um ataque DoS, mas não como qualquer coisa conhecida, pois parece ser um ataque apenas ao daemon Tor. Todas as contramedidas que tentámos até agora não foram bem sucedidas. Não há nenhum ataque percetível nos serviços atuais em execução (http, ssh, ftp, mail, etc.), mas apenas na própria conexão Tor.
Mesmo que tenhamos feito uma pesquisa e investigação profunda, o evento parece estar para além da nossa compreensão. Documentações sobre ataques anteriores ao Tor Hidden Services são raras de encontrar e não fazem sentido para o que estamos a experimentar.
Recusamo-nos a acreditar que existe um cenário de ataque que é desconhecido e não pode ser neutralizado, pois tornaria cada Serviço Oculto Tor vulnerável a ele, com adversários sendo capazes de colocar qualquer Serviço Oculto Tor offline à vontade em minutos por um tempo indefinido. O impacto sobre a Comunidade Tor seria inconcebível.
Esperamos que alguém com o conhecimento e a experiência necessários possa pelo menos nos dar uma dica sobre o que exatamente está acontecendo e nos apontar na direção certa para encontrar uma solução para acabar com esse ataque ou reduzir seu impacto em nossos sistemas e prevenir tais ataques no futuro. Isto ajudaria a proteger os Serviços Ocultos Tor em todo o mundo de futuros ataques como o que estamos a sofrer.
2. Qual é a configuração?
- O sistema corre num servidor linux (amd64) atual e sempre atualizado
- Todo o tráfego é encaminhado através do Tor via Tor transport na porta 9040, consultas DNS são resolvidas via Tor também
- O serviço Tor Hidden é v3
- Tor é a versão 0.4.7.8 rodando com 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 como libc
- Tor compilado com GCC versão 10.2.1. O Vanguards 0.3.1 também está instalado
- Tor está rodando como um serviço systemd
- O Vanguards está a correr como serviço systemd
configuração do 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. Quais são os sintomas?
- Menos de um minuto depois de iniciar o Tor com o Serviço Oculto ativado a CPU atinge os 100%, a memória parece não ser afetada
- A largura de banda usada aumenta em torno de 100kb/s
- O descritor do Serviço Oculto está inacessível
- O sistema ainda pode resolver endereços da clearnet e do Tor
- O sistema ainda pode se conectar a serviços de saída (ex.: curl para um site)
- O sistema é inundado com pacotes tcp de entrada na interface de loopback
- Quando o Tor é reiniciado, a inundação termina por alguns segundos, e então começa novamente
- Quando o Tor é iniciado sem o Serviço Oculto habilitado, parece não haver problema
- Quando o Tor é iniciado com um segundo Serviço Oculto habilitado, ambos os Descritores de Serviço Oculto permanecem inalcançáveis:
Navegador Tor no HS primário:
Onionsite desconectou
A causa mais provável é que o onionsite está offline. Contacte o administrador do onionsite.
Detalhes: 0xF2 - A introdução falhou, o que significa que o descritor foi encontrado, mas o serviço não está mais conectado ao ponto de introdução. É provável que o serviço tenha alterado o seu descritor ou que não esteja a funcionar.
ou
O tempo de ligação expirou
O servidor em (attacked hidden service descriptor).onion está a demorar demasiado tempo a responder.
O sítio pode estar temporariamente indisponível ou demasiado ocupado. Tente novamente em alguns momentos.
Navegador Tor no Seconday HS:
Não é possível conectar
O Firefox não consegue estabelecer uma conexão com o servidor em (secondary hidden service descriptor).onion
O site pode estar temporariamente indisponível ou demasiado ocupado. Tente novamente em alguns momentos.
- Quando o Tor é iniciado com um segundo Serviço Oculto ativado que está protegido por OnionAuthentication, o Descritor do Serviço Oculto primário permanece inacessível,
o Descritor do Serviço Oculto secundário (protegido) é acessível.
- Quando o Tor é iniciado apenas com o segundo Serviço Oculto ativado (com ou sem OnionAuthentication) parece não haver problema
- Quando o Tor é iniciado com o Serviço Oculto primário protegido por OnionAuthentication, o Descritor do Serviço Oculto é acessível
- Quando atacado, estas entradas aparecem no ficheiro de registo do Tor:
Aug 24 19:42:18.000 [notice] Bootstrapped 100% (done): Done
Aug 24 19:42:34.000 [notice] Your network connection speed appears to have changed. Redefinindo o timeout para 60000ms após 18 timeouts e 388 buildtimes.
Aug 24 19:42:39.000 [notice] A velocidade da sua conexão de rede parece ter mudado. Redefinindo o timeout para 60000ms após 18 timeouts e 240 tempos de construção.
Aug 24 19:42:53.000 [notice] A velocidade da sua conexão de rede parece ter mudado. Redefinindo o timeout para 60000ms após 18 timeouts e 489 buildtimes.
Aug 24 19:43:11.000 [aviso] A velocidade da sua conexão de rede parece ter mudado. Redefinindo o timeout para 60000ms após 18 timeouts e 659 buildtimes.
...
Aug 24 19:46:09.000 [notice] Valor extremamente grande para o tempo limite de construção do circuito: 122s. Assumindo salto de relógio. Objetivo 14 (Medir o tempo limite do circuito)
Aug 24 19:46:09.000 [notice] Extremely large value for circuit build timeout: 122s. Assumindo salto de relógio. Objetivo 14 (Medir o tempo limite do circuito)
Aug 24 19:46:09.000 [aviso] A velocidade da sua ligação de rede parece ter mudado. Redefinindo o timeout para 60000ms após 18 timeouts e 114 buildtimes.
Aug 24 19:46:15.000 [notice] A velocidade da sua ligação de rede parece ter mudado. Redefinindo o timeout para 60000ms após 18 timeouts e 125 buildtimes.
...
Aug 24 19:47:08.000 [notice] Valor extremamente grande para o tempo limite de construção do circuito: 123s. Assumindo um salto no relógio. Objetivo 14 (Medir o tempo limite do circuito)
Aug 24 19:47:10.000 [notice] Valor extremamente grande para o tempo limite de construção do circuito: 122s. Assumindo salto de relógio. Objetivo 14 (Medir o tempo limite do circuito)
Aug 24 19:47:10.000 [aviso] Valor extremamente grande para o tempo limite de construção do circuito: 123s. Assumindo salto de relógio. Objetivo 14 (Medir o tempo limite do circuito)
Aug 24 19:47:13.000 [aviso] Valor extremamente grande para o tempo limite de construção do circuito: 123s. Assumindo salto de relógio. Objetivo 14 (Medir o tempo limite do circuito)
Aug 24 19:47:14.000 [aviso] A velocidade da sua ligação de rede parece ter mudado. Redefinindo o timeout para 60000ms após 18 timeouts e 495 tempos de construção.
Aug 24 19:47:18.000 [notice] A velocidade da sua ligação de rede parece ter mudado. Redefinindo o timeout para 60000ms após 18 timeouts e 124 buildtimes.
Aug 24 19:47:21.000 [notice] Valor extremamente grande para o tempo limite de construção do circuito: 122s. Assumindo salto no relógio. Objetivo 14 (Medir o tempo limite do circuito)
Aug 24 19:47:23.000 [aviso] Valor extremamente grande para o tempo limite de construção do circuito: 123s. Assumindo salto de relógio. Objetivo 14 (Medir o tempo limite do circuito)
...
Aug 24 19:47:55.000 [aviso] A velocidade da sua ligação de rede parece ter mudado. Redefinindo o timeout para 60000ms após 18 timeouts e 1000 buildtimes.
Aug 24 19:47:59.000 [notice] A velocidade da sua conexão de rede parece ter mudado. Redefinindo o timeout para 60000ms após 18 timeouts e 117 buildtimes.
...
Aug 24 19:52:43.000 [notice] Valor estranho para o tempo de construção do circuito: 121581msec. Assumindo um salto no relógio. Objetivo 14 (Medir o tempo limite do circuito)
Aug 24 19:52:43.000 [aviso] A velocidade da sua ligação de rede parece ter mudado. Redefinindo o tempo limite para 120000ms após 18 tempos limite e 57 tempos de construção.
Aug 24 19:52:53.000 [aviso] Interrupção: saindo de forma limpa.
4. O que foi tentado para resolver o problema?
- Nós configuramos um servidor completamente novo do zero rodando apenas o sistema operacional básico assim como o tor e o vanguards na configuração padrão para excluir a possibilidade de um erro de configuração no nosso servidor afetado. Assim que o tor foi iniciado com o descritor atacado, estão a acontecer exatamente as mesmas coisas.
- Tentámos dividir a carga no nosso servidor através do OnionBalance nesta configuração:
Servidor1: Executa o Onionbalance para o descritor de serviço oculto primário
Servidor2/3/4: Executa o Serviço Oculto em descritores de Serviço Oculto novos e diferentes
- Isso não traz o Descritor de Serviço Oculto original de volta à vida
- Os descritores de serviço nos servidores 2/3/4 são acessíveis quando abertos diretamente, mas não através do descritor primário agora equilibrado
- A CPU nos servidores 2/3/4 vai para 100% enquanto o ataque ocorre, enquanto a CPU no servidor 1 (balanceador) permanece normal
- Adicionar mais servidores backend ao balanceador também não fez diferença
- Adicionamos essas diretivas ao bloco de serviço oculto no torrc e tentamos várias configurações nelas:
HiddenServiceEnableIntroDoSDefense 1
HiddenServiceEnableIntroDoSBurstPerSec <testado com vários valores>
HiddenServiceEnableIntroDoSRatePerSec <testado com vários valores>
Isso reduziu significativamente a carga da CPU nos servidores 2/3/4, mas o descritor de serviço balanceado permanece inacessível.
- Tentamos alterar várias configurações no vanguards.conf, sem sucesso.
- Tentámos identificar os pacotes tcp de ataque e bloqueá-los através do iptables, sem sucesso.
A nossa perícia não é suficiente para tirar ideias do que está exatamente a acontecer, inspeccionando o conteúdo dos ditos pacotes tcp que se parecem com isto:
19:45:27.839934 IP (tos 0x0, ttl 64, id 35746, offset 0, flags [DF], proto TCP (6), length 4100)
127.0.0.1.9051 > 127.0.0.1.46712: Flags [P.], cksum 0x0df9 (incorreto -> 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=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19:45:22.060324 OLD_PURPOSE=HS_SERVICE_REND OLD_HS_STATE=HSSR_CONNECTING
650 CIRC 9818 EXTENDED $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7A319C431F38CB30A0BC0C49144369A611920725~BahnhufPowah2,$8587A1B4CCD0700F164CCD588F79743C74FE8700~mev4PLicebeer16b BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19:45:22.493699
650 CIRC 9818 BUILT $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7A319C431F38CB30A0BC0C49144369A611920725~BahnhufPowah2,$8587A1B4CCD0700F164CCD588F79743C74FE8700~mev4PLicebeer16b BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19:45:22.493699
650 CIRC_MINOR 9818 PURPOSE_CHANGED $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7A319C431F38CB30A0BC0C49144369A611920725~BahnhufPowah2,$8587A1B4CCD0700F164CCD588F79743C74FE8700~mev4PLicebeer16b BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_JOINED REND_QUERY=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19:45:22.493699 OLD_PURPOSE=HS_SERVICE_REND OLD_HS_STATE=HSSR_CONNECTING
650 CIRC 9997 EXTENDED $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$8D896C8B367813030591A00DB7E7722EF6C4C23C~Luxembourg,$FF353F5D011E69ECDA10A57B46D06BC7B3FEB196~fuego,$347253D1D5246CB1C4CF8088C6982FE77CF7AB9C~ph3x,$E84F41FA1D1FA303FD7A99A35E50ACEF4269868C~Quetzalcoatl BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(attacked hidden service descriptor)---------| 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=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19:45:25.10
Isto é com o Tor a correr num único servidor. Quando balanceado, o |---------(attacked hidden service descriptor)---------| é substituído pelos descritores de serviço dos backends do servidor 2/3/4.
Podemos disponibilizar um snipplet maior do tcpdump, se necessário.
5. Conclusões
Pensamos que um adversário tem a capacidade de "interromper" um Descritor de Serviço Oculto (e portanto o próprio Serviço Oculto) inundando o daemon Tor com inúmeros pacotes tcp, pedindo para construir circuitos. Isso é o que causa a carga da CPU e, finalmente, torna o Descritor de Serviço Oculto inutilizável.
Alguém pode confirmar isso?
Uma vez que directivas como as ditas HiddenServiceEnableIntroDoSDefense, HiddenServiceEnableIntroDoSBurstPerSec e HiddenServiceEnableIntroDoSRatePerSec parecem ter como objetivo a defesa contra este tipo de ataques, tal como as vanguardas também o deveriam fazer, não podemos explicar porque é que estas continuam ineficazes. Talvez algumas configurações muito especializadas desses valores sejam necessárias para torná-los eficazes. Infelizmente estas directivas (assim como as definições em vanguards.config) são apenas descritas de uma forma vaga.
Alguém sabe como é que estas têm de ser definidas corretamente para serem eficazes?
Nesta altura, esgotámos todas as referências sobre a configuração do tor e do vanguards que conseguimos encontrar online.
Mais uma vez, qualquer ajuda ou informação sobre este assunto seria muito apreciada! Não acreditamos que não exista uma solução para este problema.
Se alguma coisa aqui descrita faz sentido para ti e/ou tens alguma suspeita sobre o que se está a passar, qualquer tipo de feedback é extremamente apreciado!
1. O que está a acontecer?
O nosso serviço estava a funcionar bem e estável durante muito tempo. De repente, o nosso serviço começou a ter problemas de desempenho ligeiros, depois graves, e depois ficou completamente inacessível.
Isto não parece ser um ataque DDoS "normal". Parece ser um ataque DoS, mas não como qualquer coisa conhecida, pois parece ser um ataque apenas ao daemon Tor. Todas as contramedidas que tentámos até agora não foram bem sucedidas. Não há nenhum ataque percetível nos serviços atuais em execução (http, ssh, ftp, mail, etc.), mas apenas na própria conexão Tor.
Mesmo que tenhamos feito uma pesquisa e investigação profunda, o evento parece estar para além da nossa compreensão. Documentações sobre ataques anteriores ao Tor Hidden Services são raras de encontrar e não fazem sentido para o que estamos a experimentar.
Recusamo-nos a acreditar que existe um cenário de ataque que é desconhecido e não pode ser neutralizado, pois tornaria cada Serviço Oculto Tor vulnerável a ele, com adversários sendo capazes de colocar qualquer Serviço Oculto Tor offline à vontade em minutos por um tempo indefinido. O impacto sobre a Comunidade Tor seria inconcebível.
Esperamos que alguém com o conhecimento e a experiência necessários possa pelo menos nos dar uma dica sobre o que exatamente está acontecendo e nos apontar na direção certa para encontrar uma solução para acabar com esse ataque ou reduzir seu impacto em nossos sistemas e prevenir tais ataques no futuro. Isto ajudaria a proteger os Serviços Ocultos Tor em todo o mundo de futuros ataques como o que estamos a sofrer.
2. Qual é a configuração?
- O sistema corre num servidor linux (amd64) atual e sempre atualizado
- Todo o tráfego é encaminhado através do Tor via Tor transport na porta 9040, consultas DNS são resolvidas via Tor também
- O serviço Tor Hidden é v3
- Tor é a versão 0.4.7.8 rodando com 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 como libc
- Tor compilado com GCC versão 10.2.1. O Vanguards 0.3.1 também está instalado
- Tor está rodando como um serviço systemd
- O Vanguards está a correr como serviço systemd
configuração do 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. Quais são os sintomas?
- Menos de um minuto depois de iniciar o Tor com o Serviço Oculto ativado a CPU atinge os 100%, a memória parece não ser afetada
- A largura de banda usada aumenta em torno de 100kb/s
- O descritor do Serviço Oculto está inacessível
- O sistema ainda pode resolver endereços da clearnet e do Tor
- O sistema ainda pode se conectar a serviços de saída (ex.: curl para um site)
- O sistema é inundado com pacotes tcp de entrada na interface de loopback
- Quando o Tor é reiniciado, a inundação termina por alguns segundos, e então começa novamente
- Quando o Tor é iniciado sem o Serviço Oculto habilitado, parece não haver problema
- Quando o Tor é iniciado com um segundo Serviço Oculto habilitado, ambos os Descritores de Serviço Oculto permanecem inalcançáveis:
Navegador Tor no HS primário:
Onionsite desconectou
A causa mais provável é que o onionsite está offline. Contacte o administrador do onionsite.
Detalhes: 0xF2 - A introdução falhou, o que significa que o descritor foi encontrado, mas o serviço não está mais conectado ao ponto de introdução. É provável que o serviço tenha alterado o seu descritor ou que não esteja a funcionar.
ou
O tempo de ligação expirou
O servidor em (attacked hidden service descriptor).onion está a demorar demasiado tempo a responder.
O sítio pode estar temporariamente indisponível ou demasiado ocupado. Tente novamente em alguns momentos.
Navegador Tor no Seconday HS:
Não é possível conectar
O Firefox não consegue estabelecer uma conexão com o servidor em (secondary hidden service descriptor).onion
O site pode estar temporariamente indisponível ou demasiado ocupado. Tente novamente em alguns momentos.
- Quando o Tor é iniciado com um segundo Serviço Oculto ativado que está protegido por OnionAuthentication, o Descritor do Serviço Oculto primário permanece inacessível,
o Descritor do Serviço Oculto secundário (protegido) é acessível.
- Quando o Tor é iniciado apenas com o segundo Serviço Oculto ativado (com ou sem OnionAuthentication) parece não haver problema
- Quando o Tor é iniciado com o Serviço Oculto primário protegido por OnionAuthentication, o Descritor do Serviço Oculto é acessível
- Quando atacado, estas entradas aparecem no ficheiro de registo do Tor:
Aug 24 19:42:18.000 [notice] Bootstrapped 100% (done): Done
Aug 24 19:42:34.000 [notice] Your network connection speed appears to have changed. Redefinindo o timeout para 60000ms após 18 timeouts e 388 buildtimes.
Aug 24 19:42:39.000 [notice] A velocidade da sua conexão de rede parece ter mudado. Redefinindo o timeout para 60000ms após 18 timeouts e 240 tempos de construção.
Aug 24 19:42:53.000 [notice] A velocidade da sua conexão de rede parece ter mudado. Redefinindo o timeout para 60000ms após 18 timeouts e 489 buildtimes.
Aug 24 19:43:11.000 [aviso] A velocidade da sua conexão de rede parece ter mudado. Redefinindo o timeout para 60000ms após 18 timeouts e 659 buildtimes.
...
Aug 24 19:46:09.000 [notice] Valor extremamente grande para o tempo limite de construção do circuito: 122s. Assumindo salto de relógio. Objetivo 14 (Medir o tempo limite do circuito)
Aug 24 19:46:09.000 [notice] Extremely large value for circuit build timeout: 122s. Assumindo salto de relógio. Objetivo 14 (Medir o tempo limite do circuito)
Aug 24 19:46:09.000 [aviso] A velocidade da sua ligação de rede parece ter mudado. Redefinindo o timeout para 60000ms após 18 timeouts e 114 buildtimes.
Aug 24 19:46:15.000 [notice] A velocidade da sua ligação de rede parece ter mudado. Redefinindo o timeout para 60000ms após 18 timeouts e 125 buildtimes.
...
Aug 24 19:47:08.000 [notice] Valor extremamente grande para o tempo limite de construção do circuito: 123s. Assumindo um salto no relógio. Objetivo 14 (Medir o tempo limite do circuito)
Aug 24 19:47:10.000 [notice] Valor extremamente grande para o tempo limite de construção do circuito: 122s. Assumindo salto de relógio. Objetivo 14 (Medir o tempo limite do circuito)
Aug 24 19:47:10.000 [aviso] Valor extremamente grande para o tempo limite de construção do circuito: 123s. Assumindo salto de relógio. Objetivo 14 (Medir o tempo limite do circuito)
Aug 24 19:47:13.000 [aviso] Valor extremamente grande para o tempo limite de construção do circuito: 123s. Assumindo salto de relógio. Objetivo 14 (Medir o tempo limite do circuito)
Aug 24 19:47:14.000 [aviso] A velocidade da sua ligação de rede parece ter mudado. Redefinindo o timeout para 60000ms após 18 timeouts e 495 tempos de construção.
Aug 24 19:47:18.000 [notice] A velocidade da sua ligação de rede parece ter mudado. Redefinindo o timeout para 60000ms após 18 timeouts e 124 buildtimes.
Aug 24 19:47:21.000 [notice] Valor extremamente grande para o tempo limite de construção do circuito: 122s. Assumindo salto no relógio. Objetivo 14 (Medir o tempo limite do circuito)
Aug 24 19:47:23.000 [aviso] Valor extremamente grande para o tempo limite de construção do circuito: 123s. Assumindo salto de relógio. Objetivo 14 (Medir o tempo limite do circuito)
...
Aug 24 19:47:55.000 [aviso] A velocidade da sua ligação de rede parece ter mudado. Redefinindo o timeout para 60000ms após 18 timeouts e 1000 buildtimes.
Aug 24 19:47:59.000 [notice] A velocidade da sua conexão de rede parece ter mudado. Redefinindo o timeout para 60000ms após 18 timeouts e 117 buildtimes.
...
Aug 24 19:52:43.000 [notice] Valor estranho para o tempo de construção do circuito: 121581msec. Assumindo um salto no relógio. Objetivo 14 (Medir o tempo limite do circuito)
Aug 24 19:52:43.000 [aviso] A velocidade da sua ligação de rede parece ter mudado. Redefinindo o tempo limite para 120000ms após 18 tempos limite e 57 tempos de construção.
Aug 24 19:52:53.000 [aviso] Interrupção: saindo de forma limpa.
4. O que foi tentado para resolver o problema?
- Nós configuramos um servidor completamente novo do zero rodando apenas o sistema operacional básico assim como o tor e o vanguards na configuração padrão para excluir a possibilidade de um erro de configuração no nosso servidor afetado. Assim que o tor foi iniciado com o descritor atacado, estão a acontecer exatamente as mesmas coisas.
- Tentámos dividir a carga no nosso servidor através do OnionBalance nesta configuração:
Servidor1: Executa o Onionbalance para o descritor de serviço oculto primário
Servidor2/3/4: Executa o Serviço Oculto em descritores de Serviço Oculto novos e diferentes
- Isso não traz o Descritor de Serviço Oculto original de volta à vida
- Os descritores de serviço nos servidores 2/3/4 são acessíveis quando abertos diretamente, mas não através do descritor primário agora equilibrado
- A CPU nos servidores 2/3/4 vai para 100% enquanto o ataque ocorre, enquanto a CPU no servidor 1 (balanceador) permanece normal
- Adicionar mais servidores backend ao balanceador também não fez diferença
- Adicionamos essas diretivas ao bloco de serviço oculto no torrc e tentamos várias configurações nelas:
HiddenServiceEnableIntroDoSDefense 1
HiddenServiceEnableIntroDoSBurstPerSec <testado com vários valores>
HiddenServiceEnableIntroDoSRatePerSec <testado com vários valores>
Isso reduziu significativamente a carga da CPU nos servidores 2/3/4, mas o descritor de serviço balanceado permanece inacessível.
- Tentamos alterar várias configurações no vanguards.conf, sem sucesso.
- Tentámos identificar os pacotes tcp de ataque e bloqueá-los através do iptables, sem sucesso.
A nossa perícia não é suficiente para tirar ideias do que está exatamente a acontecer, inspeccionando o conteúdo dos ditos pacotes tcp que se parecem com isto:
19:45:27.839934 IP (tos 0x0, ttl 64, id 35746, offset 0, flags [DF], proto TCP (6), length 4100)
127.0.0.1.9051 > 127.0.0.1.46712: Flags [P.], cksum 0x0df9 (incorreto -> 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=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19:45:22.060324 OLD_PURPOSE=HS_SERVICE_REND OLD_HS_STATE=HSSR_CONNECTING
650 CIRC 9818 EXTENDED $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7A319C431F38CB30A0BC0C49144369A611920725~BahnhufPowah2,$8587A1B4CCD0700F164CCD588F79743C74FE8700~mev4PLicebeer16b BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19:45:22.493699
650 CIRC 9818 BUILT $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7A319C431F38CB30A0BC0C49144369A611920725~BahnhufPowah2,$8587A1B4CCD0700F164CCD588F79743C74FE8700~mev4PLicebeer16b BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19:45:22.493699
650 CIRC_MINOR 9818 PURPOSE_CHANGED $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$CED577F091DCB15AD8C87FBD452A51EA9E60BFC2~strayWires,$CC8B218ED3615827A5DCF008FC62598DEF533B4F~mikrogravitation02,$7A319C431F38CB30A0BC0C49144369A611920725~BahnhufPowah2,$8587A1B4CCD0700F164CCD588F79743C74FE8700~mev4PLicebeer16b BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_JOINED REND_QUERY=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19:45:22.493699 OLD_PURPOSE=HS_SERVICE_REND OLD_HS_STATE=HSSR_CONNECTING
650 CIRC 9997 EXTENDED $2BCA0A8B5759DBD764BF9FA5D1B3AEE9D74D2B68~Waeswynn,$8D896C8B367813030591A00DB7E7722EF6C4C23C~Luxembourg,$FF353F5D011E69ECDA10A57B46D06BC7B3FEB196~fuego,$347253D1D5246CB1C4CF8088C6982FE77CF7AB9C~ph3x,$E84F41FA1D1FA303FD7A99A35E50ACEF4269868C~Quetzalcoatl BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY PURPOSE=HS_SERVICE_REND HS_STATE=HSSR_CONNECTING REND_QUERY=|---------(attacked hidden service descriptor)---------| 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=|---------(attacked hidden service descriptor)---------| TIME_CREATED=2022-08-24T19:45:25.10
Isto é com o Tor a correr num único servidor. Quando balanceado, o |---------(attacked hidden service descriptor)---------| é substituído pelos descritores de serviço dos backends do servidor 2/3/4.
Podemos disponibilizar um snipplet maior do tcpdump, se necessário.
5. Conclusões
Pensamos que um adversário tem a capacidade de "interromper" um Descritor de Serviço Oculto (e portanto o próprio Serviço Oculto) inundando o daemon Tor com inúmeros pacotes tcp, pedindo para construir circuitos. Isso é o que causa a carga da CPU e, finalmente, torna o Descritor de Serviço Oculto inutilizável.
Alguém pode confirmar isso?
Uma vez que directivas como as ditas HiddenServiceEnableIntroDoSDefense, HiddenServiceEnableIntroDoSBurstPerSec e HiddenServiceEnableIntroDoSRatePerSec parecem ter como objetivo a defesa contra este tipo de ataques, tal como as vanguardas também o deveriam fazer, não podemos explicar porque é que estas continuam ineficazes. Talvez algumas configurações muito especializadas desses valores sejam necessárias para torná-los eficazes. Infelizmente estas directivas (assim como as definições em vanguards.config) são apenas descritas de uma forma vaga.
Alguém sabe como é que estas têm de ser definidas corretamente para serem eficazes?
Nesta altura, esgotámos todas as referências sobre a configuração do tor e do vanguards que conseguimos encontrar online.
Mais uma vez, qualquer ajuda ou informação sobre este assunto seria muito apreciada! Não acreditamos que não exista uma solução para este problema.
Last edited:
