Nesta página, apresentamos algumas maneiras de mitigar ataques de negação de serviço (DoS). Todas essas abordagens podem ser combinadas. No entanto, no momento não há solução única para esse problema. Defender um site sob ataque requer criatividade e uma abordagem personalizada.

Uma visão geral das defesas implementadas no daemon Tor é fornecida na seção Visão geral da especificação Mecanismos de prevenção de negação de serviço no Tor, e aqui damos algumas dicas práticas.

Limitação de taxa nos pontos de introdução

Desde que a Proposta 305 foi implementada, algumas opções torrc foram adicionadas para ajudar a mitigar ataques DoS nos pontos de introdução:

  • HiddenServiceEnableIntroDoSDefense: Habilita a defesa DoS no nível do intropoint. Quando isso estiver habilitado, os parâmetros de taxa e burst serão enviados ao ponto de introdução, que os utilizará para aplicar a limitação de taxa para a solicitação de introdução a este serviço.

  • HiddenServiceEnableIntroDoSBurstPerSec: O pico de introdução de cliente permitido por segundo no ponto de introdução. Se esta opção for 0, ela será considerada infinita e, portanto, se HiddenServiceEnableIntroDoSDefense estiver definido, ela desabilitará efetivamente as defesas.

  • HiddenServiceEnableIntroDoSRatePerSec: A taxa de introdução de cliente permitida por segundo no ponto de introdução. Se esta opção for 0, ela será considerada infinita e, portanto, se HiddenServiceEnableIntroDoSDefense estiver definido, ela desabilitará efetivamente as defesas.

Para mais informações sobre como eles funcionam, verifique a página de manual tor(1) e a seção Extensão de defesa contra negação de serviço (DOS_PARAMS) da Especificação do Onion Services v3.

Prova de Trabalho (PoW) antes de estabelecer circuitos de encontro

Um mecanismo de defesa Prova de Trabalho (PoW) é explicado detalhadamente nas Perguntas Frequentes sobre PoW e pode ser configurado para cada Serviço Onion com as seguintes opções torrc:

  • HiddenServicePoWDefensesEnabled: Habilita a mitigação de DoS de serviço baseada em prova de trabalho. Quando ativado, o tor incluirá parâmetros para um quebra-cabeça de cliente opcional na parte criptografada do descritor deste serviço oculto. As solicitações de encontro recebidas serão priorizadas com base na quantidade de esforço que o cliente decidir fazer ao calcular uma solução para o quebra-cabeça. O serviço atualizará periodicamente uma quantidade sugerida de esforço, com base na carga de ataque, e desabilitará o quebra-cabeça completamente quando o serviço não estiver sobrecarregado.

  • HiddenServicePoWQueueRate: A taxa sustentada de solicitações de encontro para despachar por segundo da fila de prioridade.

  • HiddenServicePoWQueueBurst: O tamanho máximo de burst para solicitações de encontro tratadas da fila de prioridade de uma só vez.

A seguinte opção global é aplicável tanto aos serviços onion quanto aos seus clientes:

  • CompiledProofOfWorkHash: Quando a mitigação de negação de serviço de prova de trabalho estiver ativa, tanto os serviços em si quanto os clientes que se conectam usarão uma função de hash gerada dinamicamente como parte do cálculo do quebra-cabeça.

O PoW é habilitado por padrão nas versões 0.4.8.1-alpha do C Tor em diante (mas pode ser desabilitado se compilado com --disable-module-pow). O suporte básico ao PoW pode ser verificado executando este comando:

tor --list-modules
relay: yes
dirauth: yes
dircache: yes
pow: yes

Se você tiver pow: yes, então você tem o mecanismo de defesa PoW incorporado ao C Tor.

Devido aos requisitos de licença, as bibliotecas de quebra-cabeça do cliente PoW v1 (Equi-X e HashX da tevador, ambas sob a LGPL-3.0) são habilitadas somente se o tor for compilado com --enable-gpl. Isso pode ser confirmado executando o seguinte comando:

tor --version
Tor versão 0.4.8.3-rc.
Esta versão do Tor é coberta pela GNU General Public License (https://www.gnu.org/licenses/gpl-3.0.en.html)
O Tor está sendo executado no Linux com Libevent 2.1.12-stable, OpenSSL 3.0.9, Zlib 1.2.13, Liblzma 5.4.1, Libzstd N/A e Glibc 2.36 como libc.
Tor compilado com GCC versão 12.2.0

Se o seu C Tor instalado não tiver o PoW habilitado ou não tiver sido criado com suporte à GNU GPL, você terá que procurar outros pacotes ou compilá-lo você mesmo.

Limites de fluxo nos circuitos de encontro estabelecidos

As seguintes opções de configuração podem ser usadas para limitar conexões nos circuitos de encontro:

  • HiddenServiceMaxStreams: O número máximo de fluxos simultâneos (conexões) por circuito de encontro. O valor máximo permitido é 65535. (Definir como 0 permitirá um número ilimitado de transmissões simultâneas.)

  • HiddenServiceMaxStreamsCloseCircuit: Se definido como 1, exceder HiddenServiceMaxStreams fará com que o circuito de encontro ofensivo seja interrompido, ao contrário das solicitações de criação de fluxo que excedem o limite serem silenciosamente ignoradas.

Equilíbrio de cebola

Onionbalance permite que os operadores do Onion Service alcancem a propriedade de alta disponibilidade permitindo que várias máquinas lidem com solicitações para um Onion Service. Você pode usar o Onionbalance para dimensionar horizontalmente. Quanto mais você escala, mais difícil fica para os invasores dominá-lo. Onionbalance está disponível para v3 Onion Services.

Limitação de taxa do servidor web

Se os invasores estiverem sobrecarregando você com circuitos agressivos que realizam muitas consultas, tente detectar esse uso excessivo e eliminá-los usando a opção torrc HiddenServiceExportCircuitID. Você pode usar sua própria heurística ou usar o módulo de limitação de taxa do seu servidor web.

As dicas acima devem ajudar você a se manter à tona em tempos turbulentos. Ao mesmo tempo, estamos trabalhando em defesas mais avançadas, para que os operadores do onion precisem de menos configuração manual e ajustes.

Cache

Outra maneira de reduzir a carga no seu serviço é implementar o cache de conteúdo, seja diretamente no aplicativo de backend ou configurando um frontend de proxy de cache.

Autorização do cliente ou vários endereços onion para compartimentar seus usuários

Se você tiver usuários confiáveis, forneça a eles credenciais dedicadas de autorização do Onion Service e do cliente para que ele esteja sempre disponível. Para usuários em que você não confia, divida-os em vários endereços. Dito isto, ter muitos endereços onion é realmente ruim para sua segurança (por causa do uso de muitos nós de guarda), então tente usar autorização do cliente quando possível.

Captchas e cookies

Se você precisar limitar ainda mais a taxa de usuários, divida sua infraestrutura em camadas e coloque Captchas perto do frontend. Dessa forma, os invasores terão que resolver Captchas antes de conseguirem atacar mais profundamente sua infraestrutura.

Captchas são uma forma de mitigar ataques DDoS. Quando uma solicitação vem de um cliente, verifica se o cliente contém o cookie seguro correto, caso contrário, redireciona para a página do recaptcha. O cliente insere as letras do captcha. O Nginx envia essas letras de entrada para o servidor recaptcha para verificação.

A resposta correta do servidor recaptcha começa com "true...", caso contrário começa com "false...". Adicione o cookie seguro para o cliente verificado correto e redirecione o cliente para a página que ele deseja visualizar.

É possível implementar Captchas diretamente no seu servidor web com Nginx e OpenResty usando Lua para gerar e verificar as imagens de captcha. Esta implementação não é fácil de configurar.

Uma alternativa pode ser simplesmente implementar um desafio de teste de cookie. No seu servidor web, verifique se os clientes podem definir cookies válidos. Clientes maliciosos geralmente não têm esse recurso. No Nginx, o Cloudflare fornece uma biblioteca para interagir com cookies.

Outros métodos incluem garantir que os clientes que se conectam ao seu .onion tenham um cabeçalho User-Agent válido e que o cabeçalho Referer não esteja definido como um valor que você possa associar ao ataque.