- Tor 0.4.8 introduce una defensa que prioriza el tráfico de red verificado cuando los servicios onion sufren ataques DoS
- En la arquitectura de los servicios onion, que oculta las direcciones IP, la limitación de velocidad basada en IP es incompleta, por lo que se necesitaba un método de rompecabezas para clientes que no afecte la privacidad
- Cuando el servicio está bajo presión, los clientes demuestran su trabajo mediante cálculos de rompecabezas cada vez más difíciles, y la prioridad de conexión cambia según ese nivel
- Para usuarios comunes, el tiempo inicial de resolución es de unos 5 ms en computadoras rápidas y de hasta 30 ms en hardware lento, por lo que es manejable en la mayoría de los dispositivos
- Si aumenta el tráfico de ataque, el trabajo requerido sube hasta aproximadamente 1 minuto, encareciendo los intentos masivos de conexión y dando a los usuarios legítimos una oportunidad de acceso incluso en situaciones de congestión
Defensa PoW para servicios onion en Tor 0.4.8
- Con el lanzamiento de Tor 0.4.8, Tor introduce oficialmente una defensa de prueba de trabajo (PoW) para servicios onion
- El objetivo es contener los ataques DoS y, al mismo tiempo, priorizar el tráfico verificado
- Se recomienda a los operadores de servicios onion actualizar a la versión 0.4.8
- Como los servicios onion ocultan las direcciones IP para proteger la privacidad de los usuarios, pueden ser vulnerables a ataques DoS, y la protección solo con la limitación de velocidad tradicional basada en IP resulta incompleta
Rompecabezas para clientes y procesamiento por prioridad
- PoW funciona como un sistema de tickets que está desactivado por defecto, pero crea una cola de prioridad cuando hay estrés en la red
- Antes de acceder a un servicio onion, el cliente debe resolver un pequeño rompecabezas para demostrar que realizó una cierta cantidad de trabajo
- Cuanto más difícil es el rompecabezas, más trabajo realizado representa
- El servicio onion define la prioridad de conexión según el nivel de esfuerzo que muestra el cliente
- Si un atacante inunda un servicio onion con muchas solicitudes, aumenta el esfuerzo computacional necesario para acceder al sitio .onion
- Los intentos masivos de conexión requieren más recursos de cómputo
- La estructura hace que, a medida que aumenta el trabajo requerido, disminuya la rentabilidad del atacante
Impacto visible para los usuarios comunes
- Como los usuarios comunes suelen enviar pocas solicitudes a la vez, la carga de resolver el rompecabezas es manejable en la mayoría de los dispositivos
- El tiempo inicial de resolución es de unos 5 ms en computadoras rápidas
- En hardware lento, hasta 30 ms
- Si aumenta el tráfico de ataque, el trabajo puede subir aproximadamente hasta 1 minuto
- Este proceso no es visible para el usuario, y la experiencia de esperar una respuesta PoW es similar a esperar una conexión de red lenta
- Si los principales sitios adoptan este método, los ataques dirigidos podrían tener menos impacto negativo en la velocidad de la red, y el balanceo de carga ante picos repentinos de tráfico podría ayudar a que el acceso a los servicios onion sea más consistente y confiable
1 comentarios
Opiniones en Hacker News
Interesante. Al ver la propuesta, las expectativas quedan claras: no busca detener botnets grandes, sino defender contra script kiddies y botnets pequeñas
Durante un ataque DoS, los usuarios que realmente quieran conectarse podrán pasar, aunque quizá tengan que hacer cierto esfuerzo
También es interesante que hayan elegido https://github.com/tevador/equix como algoritmo de prueba de trabajo
No funciona como Bitcoin, donde se tiene éxito al quedar por debajo de un objetivo estático; más bien, el cliente “oferta” con esfuerzo de prueba de trabajo y, cuanto más esfuerzo invierte, mayor prioridad recibe. Lo describen como algo parecido a la prueba de participación, en el sentido de que se deposita trabajo en vez de depositar monedas
[1] https://gitlab.torproject.org/tpo/core/torspec/-/raw/main/pr...
Esta versión está bien, pero creo que sería mejor si se agregara transferencia de valor
Además, la prueba de trabajo no es más que cálculo innecesario y desperdiciado. El cómputo no es gratis, y cada watt usado en prueba de trabajo empeora la crisis climática actual
Como alguien que vive en una zona donde en pocos días se llegará a una sensación térmica de 120 grados y 109 grados reales, con todo respeto, quisiera mandar al diablo a cualquiera que sugiera que la prueba de trabajo es una buena idea para algo
No es interesante; es el caso más descarado de consumo ostentoso del planeta
Un mejor texto, es decir, con los detalles técnicos reales, es https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/p...
La función de prueba de trabajo elegida parece ser equi-X
Me sorprende que algo así no se haya incorporado antes, y como no leí la propuesta [0] con suficiente detalle, todavía no sé si aumentará la cantidad de datos que afectan el anonimato del usuario. Aun así, si queda agrupado por usuario-servicio y no se almacena en ningún lado, parece aceptable
También me intriga cuánto reducirá la carga del servicio proxy y la del propio nodo, respectivamente. Como el acceso se distribuye entre varios nodos, parece que el mayor beneficio será para el lado del servicio
[0]: https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/p...
Bien. Quizá pronto ya no haga falta un CDN para defensa contra DDoS. Basta con ofrecer la API como un servicio Onion
Este enfoque ya se había propuesto antes para prevenir el spam por email
Cloudflare también puede hacerlo. Cada vez que entres a un sitio ocupado, te haría ejecutar cálculos inútiles durante unos segundos o unos minutos. El efecto total probablemente sería drenar baterías en todo el mundo
http://www.hashcash.org/
Curiosamente, sirvió de inspiración para la minería con prueba de trabajo de Bitcoin
Porque también emitirá gases de efecto invernadero a la atmósfera
Me pregunto qué impide que, cuando la prueba de trabajo empiece a funcionar, un abusador obtenga una nueva identidad y continúe con el DDoS
Edición: parece que la prueba de trabajo se configura por “servicio” atacado, no por cliente
Debido al anonimato y a la posibilidad de crear nuevas identidades libremente, un atacante puede agotar la capacidad mediante un ataque Sybil y provocar una denegación de servicio
Me pregunto si hay una forma más elegante de resolver aquí los ataques Sybil. Por ejemplo, muchas CPU tienen un par de claves único por procesador, que puede verificarse con certificados raíz de CA del emisor, como Intel, AMD, etc. Si se combina la prueba de trabajo con firmas en serie y se permite la verificación en paralelo, todas las pruebas de trabajo se vuelven únicas por CPU, de modo que no pueden paralelizarse con una botnet
Parece que están apuntando a la memoria para elevar el costo de las botnets. También parecen existir muchas otras formas de reducir este escenario de ataque. Creo que la misma lógica podría aplicarse a teléfonos con eSIM. Como la autenticación de redes móviles usa criptografía de clave pública, también debería ser posible una prueba única
Es solo una idea que se me ocurrió, así que es muy probable que esté pasando por alto problemas obvios de este enfoque
La razón para elegir un algoritmo que use mucha memoria es evitar el uso de hardware específico, es decir, ASIC
En una línea parecida, me pregunto qué tal sería que el servidor tuviera varios pools de IP y que el cliente devolviera una prueba de port knocking. Por ejemplo, darle un token, decirle que lo envíe a esta IP:puerto y esperar una respuesta única que yo pueda verificar. A eso se le podría llamar prueba de latencia. El uso de CPU es bajo y la carga puede distribuirse entre varias máquinas y puertos. La desventaja, obviamente, es que requiere varias IP y potencialmente varios servidores. También podría implementarse en la misma máquina, pero entonces la carga de CPU simplemente se trasladaría a las conexiones de puertos
Tengo una idea para reducir el tráfico de la red Tor o hacerla más rápida. La red debería poder usarse como una CDN. Si quieres publicar un archivo, deberías poder enviar fragmentos del archivo a nodos autorizados y, cuando llegue una solicitud del archivo, apuntar a esos nodos
Por supuesto, habría que tener cuidado de que la red Tor no se convierta en un “sustituto anónimo de torrents” y termine perjudicando su propósito
La propuesta actual habla de “priorización del tráfico de red verificado”. Como en realidad ayuda a la red, sería interesante si compartir “fragmentos de archivos” pudiera aumentar la prioridad del tráfico. Sería una prueba de contribución de ancho de banda en lugar de una “prueba de trabajo”
Aun así, no termino de ver cómo esto reduce el tráfico de red. De todos modos hay que comunicarse con los nodos de la CDN
Viendo los objetivos y límites que plantea esta propuesta, parece razonable, y probablemente logre esos objetivos. Como se dijo, funcionará contra botnets pequeñas, pero una botnet grande todavía puede superar los recursos disponibles de los clientes individuales
Personalmente no me gusta la prueba de trabajo. Aquí se parece más a una externalidad como mecanismo de defensa, puede volver obsoleto rápidamente el hardware viejo y, considerando todos los dispositivos afectados, probablemente consuma bastante energía. Si se aplica a gran escala, supone una carga ambiental considerable
Desde el punto de vista del atacante, lograr que la dificultad sea tan alta ya puede considerarse un éxito. Si el usuario tiene que esperar 1 minuto con su dispositivo al 100%, en muchos casos simplemente se irá
Aun así, es una forma bastante buena de mitigar ataques DoS sin perjudicar el anonimato del usuario, así que desde ese punto de vista es una buena solución pese a sus desventajas. Mientras exista en Tor no hay gran problema, pero si se aplicara a la web general me parecería un desastre total
El artículo dice que la diferencia de tiempo de resolución entre un servidor de gama alta y un teléfono de baja gama es de solo 6 veces. No entiendo cómo es posible. Un servidor tiene mucha más RAM y muchos más CPU que un teléfono, bastante más de 6 veces, y además es probable que sus CPU sean más rápidas
Además, si se trata de un DDoS, el trabajo del servidor se paraleliza de forma casi incómodamente buena, mientras que el trabajo del cliente no necesariamente puede paralelizarse
Incluso si la diferencia fuera de 6 veces, o apenas de 1 vez, dicen que cuando se detecta un DDoS el tiempo de resolución es de 1 minuto. ¿Para ese punto el servicio no está básicamente caído?
Lo central de que el tiempo de resolución sea de 1 minuto cuando se detecta un DDoS es convertir un ataque DoS fácil existente, el introduction flooding, en una falla parcial o una degradación de velocidad. Es una mejora gradual ante un problema difícil