En esta página presentamos unas pocas maneras de mitigar ataques DoS. Se pueden combinar todos estos enfoques. Sin embargo, al presente no hay una única solución que satisfaga todas las condiciones para este problema. Defender un sitio atacado requiere creatividad y un abordaje a la medida.

He aquí algunos consejos:

Limitación de velocidad en los puntos de introducción

Desde que se implementó la Propuesta 305, se añadieron algunas opciones torrc para ayudar a mitigar los ataques DoS en los puntos de introducción:

  • HiddenServiceEnableIntroDoSDefense: Habilitar la defensa DoS a nivel de intropoint. Cuando esto esté habilitado, los parámetros de rate y burst se enviarán al punto de entrada que luego los utilizará para aplicar la tasa límite para la solicitud de introducción a este servicio.

  • HiddenServiceEnableIntroDoSBurstPerSec: La cantidad de introducción de clientes permitida por segundo en el punto de introducción. Si esta opción es 0, se considera infinita y por lo tanto si se fija HiddenServiceEnableIntroDoSDefense, entonces efectivamente deshabilita las defensas.

  • HiddenServiceEnableIntroDoSRatePerSec: La tasa de introducción del cliente permitido por segundo en el punto de introducción. Si esta opción es 0, se considera infinita y por lo tanto si se fija HiddenServiceEnableIntroDoSDefense, entonces efectivamente deshabilita las defensas.

Para obtener más información sobre cómo funcionan, mira la página del manual tor(1) y la sección [EST_INTRO_DOS_EXT] de la especificación de Onion Services v3.

Prueba de trabajo (PoW) antes de establecer Circuitos de Encuentro

Con la implementación de la Propuesta 327, se puede configurar un mecanismo de defensa de Prueba de Trabajo (PoW) para cada Servicio Onion con las siguientes opciones torrc:

  • HiddenServicePoWDefensesEnabled: Habilita la mitigación de DoS del servicio basado en prueba de trabajo. Cuando esté habilitado, Tor incluirá parámetros para un rompecabezas cliente opcional en la parte cifrada del descriptor de este servicio oculto. Las solicitudes de encuentro entrantes se priorizarán en función de la cantidad de esfuerzo que un cliente elija hacer al calcular una solución al rompecabezas. El servicio actualizará periódicamente una cantidad de esfuerzo sugerida, según la carga de ataque, y desactivará el confundir por completo cuando el servicio no esté sobrecargado.

  • HiddenServicePoWQueueRate: La tasa sostenida de solicitudes de cita para enviar por segundo desde la cola de prioridad.

  • HiddenServicePoWQueueBurst: El tamaño máximo de ráfaga para solicitudes de encuentro gestionadas desde la cola de prioridad a la vez.

La opción global que sigue se aplica tanto a los servicios cebolla como a sus clientes:

  • CompiledProofOfWorkHash: Cuando la mitigación DoS de prueba de trabajo está activa, tanto los propios servicios como los clientes que se conectan utilizarán una función hash generada dinámicamente como parte del cálculo del desconcierto.

PoW está habilitado de forma predeterminada en las versiones 0.4.8.1-alpha de C Tor en adelante (pero se puede deshabilitar si se compila con --disable-module-pow). La compatibilidad básica con PoW se puede comprobar ejecutando este comando:

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

Si tienes pow: yes, entonces tienes el mecanismo de defensa PoW integrado en C Tor.

Debido a requisitos de licencia, las bibliotecas clientes PoW v1 confunden (Equi-X y HashX por tevador, ambas bajo LGPL-3.0) están habilitadas solo si tor está compilado con --enable-gpl. Esto se puede confirmar ejecutando el siguiente comando:

tor --version
Tor versión 0.4.8.3-rc.
Esta versión de Tor está cubierta por la Licencia Pública General GNU (https://www.gnu.org/licenses/gpl-3.0.en.html)
Tor se ejecuta en Linux con Libevent 2.1.12-stable, OpenSSL 3.0.9, Zlib 1.2.13, Liblzma 5.4.1, Libzstd N/A y Glibc 2.36 como libc.
Tor compilado con GCC versión 12.2.0

Si tu C Tor instalado no tiene habilitado PoW o no está construido con soporte GNU GPL, entonces tendrás que buscar otros paquetes o compilarlo tú mismo.

Límites de transmisión en los Circuitos de Encuentros establecidos

Las siguientes opciones de configuración se pueden usar para limitar las conexiones en los circuitos de encuentro:

  • HiddenServiceMaxStreams: El número máximo de flujos (conexiones) simultáneos por circuito rendezvous. El valor máximo permitido es 65535. (Si se establece en 0, se permitirá un número ilimitado de flujos simultáneos.)

  • HiddenServiceMaxStreamsCloseCircuit: Si se fija en 1, entonces exceder HiddenServiceMaxStreams causará que el circuito rendezvous ofensivo se caiga, en lugar de ignorar silenciosamente las solicitudes de creación de flujos que superen el límite.

Onionbalance

Onionbalance permite a los operadores de servicios cebolla lograr gran disponibilidad usando varias máquinas para satisfacer consultas a un mismo servicio cebolla. Puedes usar Onionbalance para expandir horizontalmente. Cuanto más expandes, más difícil es para los atacantes sobrepasarte. Onionbalance está disponible para Servicios cebolla v3.

Limitación de la tasa de acceso al servidor web

Si los atacantes te acosan con circuitos agresivos que realizan demasiadas consultas, intenta detectar ese sobreuso y eliminarlos usando la opción HiddenServiceExportCircuitID en torrc. Puedes usar tu propia heurística o el módulo de limitación de tasa de tu servidor web.

Los consejos de arriba deberían ayudar a mantenerte a flote en tiempos turbulentos. Al mismo tiempo estamos trabajando en defensas más avanzadas, de manera que se necesite menos configuración manual y ajuste por parte de los operadores de servicios cebolla.

Almacenamiento en caché

Otra forma de reducir la carga de tu servicio es implementar el almacenamiento en caché de contenido, ya sea directamente en la aplicación backend o configurando una interfaz proxy de almacenamiento en caché.

Autorización de Cliente o múltiples direcciones cebolla para compartimentar a tus usuarios

Si tienes usuarios en los que confías, dales credenciales dedicadas del Servicio Cebolla y autorización de cliente para que siempre esté disponible. Para usuarios en los que no confías, divídelos en múltiples direcciones. Dicho sea eso, tener demasiadas direcciones onion es realmente malo para tu seguridad (debido al uso de muchos nodos guardianes), por lo que intenta usar autorización de cliente cuando sea posible.

Captchas y cookies

Si aún necesitas limitar la tasa de acceso a tus usuarios, divide tu infraestructura en capas, y pón Captchas cerca de la página de inicio de sesión. De esta manera, los atacantes tendrán que resolver Captchas antes de poder atacar más adentro de tu infraestructura.

Los Captchas son una manera de mitigar ataques DDoS. Cuando una solicitud viene desde un cliente, comprueba si el cliente contiene la cookie segura correcta o de lo contrario redirigirá a la página recaptcha. El cliente ingresa las letras captcha. Nginx envía estas letras ingresadas al servidor recaptcha para su verificación.

La respuesta correcta desde el servidor recaptcha comenzará con "true...", caso contrario comenzará con "false...". Agrega la cookie segura para el cliente verificado correcto, redirige al cliente a la página que desea ver.

Es posible implementar Captchas directamente en tu servidor web con Nginx y OpenResty usando Lua para generar y verificar las imágenes captcha. Esta implementación no es fácil de configurar.

Una alternativa podría ser implementar un desafío test-cookie. En tu servidor web, comprueba que los clientes puedan establecer cookies válidas, los clientes maliciosos a menudo no tienen esta funcionalidad. En Nginx, Cloudflare provee una biblioteca para interactuar con cookies.

Otros métodos incluyen asegurarse que los clientes que se conectan a tu .onion tengan un encabezado User-Agent válido, y que el encabezado Referer no esté establecido a un valor que puedas asociar con el ataque.