Obrigado por dedicar seu tempo para ler isso! Não somos especialistas em redes Tor, mas sabemos o que fazer.
Se algo descrito aqui fizer sentido para você e/ou se você tiver alguma suspeita sobre o que está acontecendo, qualquer tipo de feedback será extremamente apreciado!
1. O que está acontecendo?
Nosso serviço estava funcionando bem e estável por um longo tempo. De repente, nosso serviço apresentou problemas de desempenho leves e graves no início e, depois, ficou completamente inacessível.
Isso 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 tentamos até agora não foram bem-sucedidas. Não há nenhum ataque perceptível nos serviços reais 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 profundas, o evento parece estar além de nossa compreensão. Documentações sobre ataques anteriores aos Tor Hidden Services são raras de encontrar e não fazem sentido para o que estamos vivenciando.
Nós nos recusamos a acreditar que existe um cenário de ataque que é desconhecido e não pode ser neutralizado, pois isso 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 na Comunidade Tor seria além do escopo.
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 a direção certa para encontrar uma solução para acabar com esse ataque ou reduzir seu impacto em nossos sistemas e evitar tais ataques no futuro. Isso ajudaria a proteger os serviços ocultos da Tor em todo o mundo de futuros ataques como o que estamos sofrendo.
2. Qual é a configuração?
- O sistema é executado em um servidor Linux (amd64) atual e sempre atualizado
- Todo o tráfego é roteado pelo Tor por meio do transporte Tor na porta 9040; as consultas de DNS também são resolvidas pelo Tor.
- O serviço oculto do Tor é v3
- O Tor é a versão 0.4.7.8 em execução 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 o GCC versão 10.2.1. O Vanguards 0.3.1 também está instalado
- O Tor está sendo executado como um serviço systemd
- O Vanguards está sendo executado 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 após iniciar o Tor com o Serviço Oculto habilitado, a CPU chega a 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 não pode ser acessado
- 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 depois começa novamente
- Quando o Tor é iniciado sem o Serviço Oculto ativado, parece não haver problema
- Quando o Tor é iniciado com um segundo serviço oculto ativado, ambos os descritores de serviço oculto permanecem inacessíveis:
Navegador Tor no HS primário:
Onionsite Has Disconnected
A causa mais provável é que o site da cebola esteja off-line. Entre em contato com o administrador do onionsite.
Detalhes: 0xF2 - Falha na introdução, 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 seu descritor ou que não esteja em execução.
ou
A conexão atingiu o tempo limite
O servidor em (attacked hidden service descriptor).onion está demorando muito para responder.
O site pode estar temporariamente indisponível ou muito ocupado. Tente novamente em alguns instantes.
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 muito ocupado. Tente novamente em alguns instantes.
- Quando o Tor é iniciado com um segundo Serviço Oculto ativado que é 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 habilitado (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, essas entradas aparecem no arquivo de registro do Tor:
Aug 24 19:42:18.000 [notice] Bootstrapped 100% (done): Done
Aug 24 19:42:34.000 [notice] Sua velocidade de conexão de rede parece ter mudado. Redefinindo o timeout para 60000ms após 18 timeouts e 388 buildtimes.
Aug 24 19:42:39.000 [notice] A velocidade de sua conexão de rede parece ter mudado. Redefinindo o tempo limite para 60000ms após 18 tempos limite e 240 tempos de compilação.
Aug 24 19:42:53.000 [notice] A velocidade de sua conexão de rede parece ter mudado. Redefinindo o tempo limite para 60000ms após 18 tempos limite e 489 tempos de compilação.
Aug 24 19:43:11.000 [notice] A velocidade de sua conexão de rede parece ter mudado. Redefinindo o tempo limite para 60000ms após 18 tempos limite e 659 tempos de compilação.
...
Aug 24 19:46:09.000 [notice] Valor extremamente grande para o tempo limite de construção do circuito: 122s. Supondo um salto no relógio. Objetivo 14 (Medir o tempo limite do circuito)
Aug 24 19:46:09.000 [notice] Valor extremamente alto para o tempo limite de construção do circuito: 122s. Supondo um salto no relógio. Propósito 14 (Medindo o tempo limite do circuito)
Aug 24 19:46:09.000 [notice] A velocidade da sua conexão de rede parece ter mudado. Redefinindo o tempo limite para 60000ms após 18 tempos limites e 114 tempos de construção.
Aug 24 19:46:15.000 [notice] A velocidade de sua conexão de rede parece ter mudado. Redefinindo o tempo limite para 60000ms após 18 tempos limite e 125 tempos de compilação.
...
Aug 24 19:47:08.000 [notice] Valor extremamente grande para o tempo limite de construção do circuito: 123s. Supondo um salto no relógio. Objetivo 14 (Medir o tempo limite do circuito)
Aug 24 19:47:10.000 [notice] Valor extremamente alto para o tempo limite de construção do circuito: 122s. Supondo um salto no relógio. Propósito 14 (Medindo o tempo limite do circuito)
Aug 24 19:47:10.000 [notice] Valor extremamente alto para o tempo limite de construção do circuito: 123s. Supondo um salto no relógio. Propósito 14 (Medindo o tempo limite do circuito)
Aug 24 19:47:13.000 [notice] Valor extremamente alto para o tempo limite de construção do circuito: 123s. Supondo um salto no relógio. Propósito 14 (Medindo o tempo limite do circuito)
Aug 24 19:47:14.000 [notice] A velocidade da sua conexão de rede parece ter mudado. Redefinindo o tempo limite para 60000ms após 18 tempos limites e 495 tempos de construção.
Aug 24 19:47:18.000 [notice] A velocidade de sua conexão de rede parece ter mudado. Redefinindo o tempo limite para 60000ms após 18 tempos limite e 124 tempos de compilação.
Aug 24 19:47:21.000 [notice] Valor extremamente grande para o tempo limite de construção do circuito: 122s. Supondo um salto no relógio. Objetivo 14 (Medir o tempo limite do circuito)
Aug 24 19:47:23.000 [notice] Valor extremamente alto para o tempo limite de construção do circuito: 123s. Supondo um salto no relógio. Propósito 14 (Medindo o tempo limite do circuito)
...
Aug 24 19:47:55.000 [notice] A velocidade da sua conexã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 de sua conexão de rede parece ter mudado. Redefinindo o tempo limite para 60000ms após 18 tempos limite e 117 tempos de compilação.
...
Aug 24 19:52:43.000 [notice] Valor estranho para o tempo de construção do circuito: 121581msec. Supondo um salto no relógio. Objetivo 14 (Medir o tempo limite do circuito)
Aug 24 19:52:43.000 [notice] A velocidade da sua conexã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 [notice] Interrupção: saindo de forma limpa.
4. O que foi tentado para resolver o problema?
- Configuramos um servidor completamente novo do zero executando apenas o sistema operacional básico, bem como o tor e o vanguards na configuração padrão para excluir a possibilidade de uma configuração incorreta em nosso servidor afetado. Assim que o tor foi iniciado com o descritor atacado, exatamente as mesmas coisas estavam acontecendo.
- Tentamos dividir a carga em nosso servidor por meio do OnionBalance nessa configuração:
Server1: 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 podem ser acessados quando abertos diretamente, mas não por meio do descritor primário agora equilibrado.
- A CPU dos servidores 2/3/4 vai para 100% enquanto o ataque ocorre, enquanto a CPU do servidor 1 (balanceador) permanece normal.
- A adição de 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 continua inacessível.
- Tentamos alterar várias configurações no vanguards.conf, sem sucesso.
- Tentamos identificar os pacotes tcp de ataque e bloqueá-los por meio do iptables, sem sucesso.
Nosso conhecimento não é suficiente para ter uma ideia do que exatamente está acontecendo ao inspecionar o conteúdo dos referidos pacotes tcp, que são assim:
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
Isso ocorre com o Tor em execução em um ú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 trecho maior do tcpdump, se necessário.
5. Conclusões
Acreditamos 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 do Tor com incontáveis pacotes tcp, solicitando a criação de circuitos. Isso é o que causa a carga da CPU e, por fim, torna o Descritor de Serviço Oculto inutilizável.
Alguém pode confirmar isso?
Como diretivas como as mencionadas HiddenServiceEnableIntroDoSDefense, HiddenServiceEnableIntroDoSBurstPerSec e HiddenServiceEnableIntroDoSRatePerSec parecem ter como objetivo a defesa contra esse tipo de ataque, assim como as vanguardas também deveriam fazer, não podemos explicar por que elas permanecem ineficazes. Talvez sejam necessárias algumas configurações muito especializadas desses valores para torná-los eficazes. Infelizmente, essas diretivas (bem como as configurações no vanguards.config) são descritas apenas de forma vaga.
Alguém sabe como elas devem ser definidas corretamente para serem eficazes?
Nesse ponto, esgotamos todas as referências sobre a configuração do tor e do vanguards que pudemos encontrar on-line.
Mais uma vez, qualquer ajuda ou informação sobre esse problema será muito bem-vinda! Não acreditamos que não haja uma solução para isso.
Se algo descrito aqui fizer sentido para você e/ou se você tiver alguma suspeita sobre o que está acontecendo, qualquer tipo de feedback será extremamente apreciado!
1. O que está acontecendo?
Nosso serviço estava funcionando bem e estável por um longo tempo. De repente, nosso serviço apresentou problemas de desempenho leves e graves no início e, depois, ficou completamente inacessível.
Isso 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 tentamos até agora não foram bem-sucedidas. Não há nenhum ataque perceptível nos serviços reais 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 profundas, o evento parece estar além de nossa compreensão. Documentações sobre ataques anteriores aos Tor Hidden Services são raras de encontrar e não fazem sentido para o que estamos vivenciando.
Nós nos recusamos a acreditar que existe um cenário de ataque que é desconhecido e não pode ser neutralizado, pois isso 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 na Comunidade Tor seria além do escopo.
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 a direção certa para encontrar uma solução para acabar com esse ataque ou reduzir seu impacto em nossos sistemas e evitar tais ataques no futuro. Isso ajudaria a proteger os serviços ocultos da Tor em todo o mundo de futuros ataques como o que estamos sofrendo.
2. Qual é a configuração?
- O sistema é executado em um servidor Linux (amd64) atual e sempre atualizado
- Todo o tráfego é roteado pelo Tor por meio do transporte Tor na porta 9040; as consultas de DNS também são resolvidas pelo Tor.
- O serviço oculto do Tor é v3
- O Tor é a versão 0.4.7.8 em execução 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 o GCC versão 10.2.1. O Vanguards 0.3.1 também está instalado
- O Tor está sendo executado como um serviço systemd
- O Vanguards está sendo executado 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 após iniciar o Tor com o Serviço Oculto habilitado, a CPU chega a 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 não pode ser acessado
- 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 depois começa novamente
- Quando o Tor é iniciado sem o Serviço Oculto ativado, parece não haver problema
- Quando o Tor é iniciado com um segundo serviço oculto ativado, ambos os descritores de serviço oculto permanecem inacessíveis:
Navegador Tor no HS primário:
Onionsite Has Disconnected
A causa mais provável é que o site da cebola esteja off-line. Entre em contato com o administrador do onionsite.
Detalhes: 0xF2 - Falha na introdução, 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 seu descritor ou que não esteja em execução.
ou
A conexão atingiu o tempo limite
O servidor em (attacked hidden service descriptor).onion está demorando muito para responder.
O site pode estar temporariamente indisponível ou muito ocupado. Tente novamente em alguns instantes.
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 muito ocupado. Tente novamente em alguns instantes.
- Quando o Tor é iniciado com um segundo Serviço Oculto ativado que é 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 habilitado (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, essas entradas aparecem no arquivo de registro do Tor:
Aug 24 19:42:18.000 [notice] Bootstrapped 100% (done): Done
Aug 24 19:42:34.000 [notice] Sua velocidade de conexão de rede parece ter mudado. Redefinindo o timeout para 60000ms após 18 timeouts e 388 buildtimes.
Aug 24 19:42:39.000 [notice] A velocidade de sua conexão de rede parece ter mudado. Redefinindo o tempo limite para 60000ms após 18 tempos limite e 240 tempos de compilação.
Aug 24 19:42:53.000 [notice] A velocidade de sua conexão de rede parece ter mudado. Redefinindo o tempo limite para 60000ms após 18 tempos limite e 489 tempos de compilação.
Aug 24 19:43:11.000 [notice] A velocidade de sua conexão de rede parece ter mudado. Redefinindo o tempo limite para 60000ms após 18 tempos limite e 659 tempos de compilação.
...
Aug 24 19:46:09.000 [notice] Valor extremamente grande para o tempo limite de construção do circuito: 122s. Supondo um salto no relógio. Objetivo 14 (Medir o tempo limite do circuito)
Aug 24 19:46:09.000 [notice] Valor extremamente alto para o tempo limite de construção do circuito: 122s. Supondo um salto no relógio. Propósito 14 (Medindo o tempo limite do circuito)
Aug 24 19:46:09.000 [notice] A velocidade da sua conexão de rede parece ter mudado. Redefinindo o tempo limite para 60000ms após 18 tempos limites e 114 tempos de construção.
Aug 24 19:46:15.000 [notice] A velocidade de sua conexão de rede parece ter mudado. Redefinindo o tempo limite para 60000ms após 18 tempos limite e 125 tempos de compilação.
...
Aug 24 19:47:08.000 [notice] Valor extremamente grande para o tempo limite de construção do circuito: 123s. Supondo um salto no relógio. Objetivo 14 (Medir o tempo limite do circuito)
Aug 24 19:47:10.000 [notice] Valor extremamente alto para o tempo limite de construção do circuito: 122s. Supondo um salto no relógio. Propósito 14 (Medindo o tempo limite do circuito)
Aug 24 19:47:10.000 [notice] Valor extremamente alto para o tempo limite de construção do circuito: 123s. Supondo um salto no relógio. Propósito 14 (Medindo o tempo limite do circuito)
Aug 24 19:47:13.000 [notice] Valor extremamente alto para o tempo limite de construção do circuito: 123s. Supondo um salto no relógio. Propósito 14 (Medindo o tempo limite do circuito)
Aug 24 19:47:14.000 [notice] A velocidade da sua conexão de rede parece ter mudado. Redefinindo o tempo limite para 60000ms após 18 tempos limites e 495 tempos de construção.
Aug 24 19:47:18.000 [notice] A velocidade de sua conexão de rede parece ter mudado. Redefinindo o tempo limite para 60000ms após 18 tempos limite e 124 tempos de compilação.
Aug 24 19:47:21.000 [notice] Valor extremamente grande para o tempo limite de construção do circuito: 122s. Supondo um salto no relógio. Objetivo 14 (Medir o tempo limite do circuito)
Aug 24 19:47:23.000 [notice] Valor extremamente alto para o tempo limite de construção do circuito: 123s. Supondo um salto no relógio. Propósito 14 (Medindo o tempo limite do circuito)
...
Aug 24 19:47:55.000 [notice] A velocidade da sua conexã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 de sua conexão de rede parece ter mudado. Redefinindo o tempo limite para 60000ms após 18 tempos limite e 117 tempos de compilação.
...
Aug 24 19:52:43.000 [notice] Valor estranho para o tempo de construção do circuito: 121581msec. Supondo um salto no relógio. Objetivo 14 (Medir o tempo limite do circuito)
Aug 24 19:52:43.000 [notice] A velocidade da sua conexã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 [notice] Interrupção: saindo de forma limpa.
4. O que foi tentado para resolver o problema?
- Configuramos um servidor completamente novo do zero executando apenas o sistema operacional básico, bem como o tor e o vanguards na configuração padrão para excluir a possibilidade de uma configuração incorreta em nosso servidor afetado. Assim que o tor foi iniciado com o descritor atacado, exatamente as mesmas coisas estavam acontecendo.
- Tentamos dividir a carga em nosso servidor por meio do OnionBalance nessa configuração:
Server1: 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 podem ser acessados quando abertos diretamente, mas não por meio do descritor primário agora equilibrado.
- A CPU dos servidores 2/3/4 vai para 100% enquanto o ataque ocorre, enquanto a CPU do servidor 1 (balanceador) permanece normal.
- A adição de 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 continua inacessível.
- Tentamos alterar várias configurações no vanguards.conf, sem sucesso.
- Tentamos identificar os pacotes tcp de ataque e bloqueá-los por meio do iptables, sem sucesso.
Nosso conhecimento não é suficiente para ter uma ideia do que exatamente está acontecendo ao inspecionar o conteúdo dos referidos pacotes tcp, que são assim:
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
Isso ocorre com o Tor em execução em um ú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 trecho maior do tcpdump, se necessário.
5. Conclusões
Acreditamos 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 do Tor com incontáveis pacotes tcp, solicitando a criação de circuitos. Isso é o que causa a carga da CPU e, por fim, torna o Descritor de Serviço Oculto inutilizável.
Alguém pode confirmar isso?
Como diretivas como as mencionadas HiddenServiceEnableIntroDoSDefense, HiddenServiceEnableIntroDoSBurstPerSec e HiddenServiceEnableIntroDoSRatePerSec parecem ter como objetivo a defesa contra esse tipo de ataque, assim como as vanguardas também deveriam fazer, não podemos explicar por que elas permanecem ineficazes. Talvez sejam necessárias algumas configurações muito especializadas desses valores para torná-los eficazes. Infelizmente, essas diretivas (bem como as configurações no vanguards.config) são descritas apenas de forma vaga.
Alguém sabe como elas devem ser definidas corretamente para serem eficazes?
Nesse ponto, esgotamos todas as referências sobre a configuração do tor e do vanguards que pudemos encontrar on-line.
Mais uma vez, qualquer ajuda ou informação sobre esse problema será muito bem-vinda! Não acreditamos que não haja uma solução para isso.
Last edited:
