Gracias por tomarse la molestia de leer esto. No somos expertos en redes Tor, pero sabemos cómo manejarnos.
Si algo de lo descrito aquí tiene sentido para usted y/o tiene alguna sospecha sobre lo que está pasando, ¡cualquier tipo de comentario es extremadamente apreciado!
1. 1. ¿Qué está ocurriendo?
Nuestro servicio ha funcionado bien y estable durante mucho tiempo. De repente, nuestro servicio experimentó ligeros y luego graves problemas de rendimiento al principio, y luego se volvió completamente inaccesible.
Esto no parece ser un ataque DDoS "regular". Parece ser un ataque DoS, pero no como cualquier cosa conocida, ya que parece ser un ataque sólo al demonio Tor. Todas las contramedidas que hemos probado hasta ahora no han tenido éxito. No hay ataque perceptible en los servicios reales que se ejecutan (http, ssh, ftp, correo, etc.), sino sólo en la propia conexión Tor.
A pesar de que hicimos una profunda búsqueda e investigación, el evento parece estar más allá de nuestra comprensión. Las documentaciones sobre ataques anteriores a los Servicios Ocultos Tor son raras de encontrar y no tienen sentido para lo que estamos experimentando.
Nos negamos a creer que hay un escenario de ataque que es desconocido y no puede ser contrarrestado ya que haría a cada Servicio Oculto Tor vulnerable a él con adversarios capaces de desconectar cualquier Servicio Oculto Tor a voluntad en minutos por tiempo indefinido. El impacto en la Comunidad Tor estaría más allá del alcance.
Esperamos que alguien con el conocimiento y la experiencia necesarios pueda al menos darnos una pista de lo que está pasando exactamente e indicarnos la dirección correcta para encontrar una solución que acabe con este ataque o reduzca su impacto en nuestros sistemas y prevenga tales ataques en el futuro. Esto ayudaría a proteger los Servicios Ocultos de Tor en todo el mundo de futuros ataques como el que estamos experimentando.
2. ¿Cuál es la configuración?
- El sistema se ejecuta en un servidor linux (amd64) actual y siempre actualizado
- Todo el tráfico se enruta a través de Tor mediante el transporte Tor en el puerto 9040, las consultas DNS se resuelven a través de Tor también
- El Servicio Oculto Tor es v3
- Tor es la versión 0.4.7.8 corriendo con Libevent 2.1.12-stable, OpenSSL 1.1.1n, Zlib 1.2.11, Liblzma 5.2.5, Libzstd 1.4.8 y Glibc 2.31 como libc
- Tor compilado con GCC versión 10.2.1. Vanguards 0.3.1 también está instalado
- Tor se ejecuta como un servicio systemd
- Vanguards se ejecuta como servicio systemd
Configuración de torrc:
CookieAutenticación 1
HashedControlPassword 16:<hash>
VirtualAddrNetworkIPv4 10.192.0.0/10
AutomapHostsOnResolve 1
TransPort 127.0.0.1:9040
DNSPuerto 127.0.0.1:53
HiddenServiceDir /var/lib/tor/hidden_service
HiddenServicePort 80 127.0.0.1:80
HiddenServiceVersion 3
HiddenServiceAllowUnknownPorts 0
3. ¿Cuáles son los síntomas?
- Menos de un minuto después de iniciar Tor con el Servicio Oculto activado la CPU llega al 100%, la memoria parece no estar afectada
- El ancho de banda usado aumenta alrededor de 100kb/s
- El descriptor del Servicio Oculto es inalcanzable
- El sistema aún puede resolver direcciones clearnet y Tor
- El sistema aún puede conectarse a servicios salientes (ej. curl a un sitio web)
- El sistema se inunda con paquetes tcp entrantes en la interfaz loopback
- Cuando se reinicia Tor, la inundación termina durante unos segundos, luego comienza de nuevo
- Cuando se inicia Tor sin el Servicio Oculto habilitado no parece haber problema
- Cuando se inicia Tor con un segundo Servicio Oculto habilitado, ambos Descriptores de Servicio Oculto permanecen inalcanzables:
Navegador Tor en HS Primario:
Onionsite Se Ha Desconectado
La causa más probable es que el onionsite esté desconectado. Contacte con el administrador de onionsite.
Detalles: 0xF2 - Introducción fallida, lo que significa que el descriptor fue encontrado pero el servicio ya no está conectado al punto de introducción. Es probable que el servicio haya cambiado su descriptor o que no se esté ejecutando.
o
La conexión ha expirado
El servidor en (descriptor de servicio oculto atacado).onion está tardando demasiado en responder.
El sitio podría no estar disponible temporalmente o estar demasiado ocupado. Inténtelo de nuevo en unos momentos.
Navegador Tor en Seconday HS:
No se puede conectar
Firefox no puede establecer una conexión con el servidor en (descriptor de servicio oculto secundario).onion
El sitio podría estar temporalmente no disponible o demasiado ocupado. Inténtelo de nuevo en unos momentos.
- Cuando Tor se inicia con un segundo Servicio Oculto habilitado que está protegido por OnionAuthentication, el Descriptor de Servicio Oculto primario permanece inalcanzable,
el Descriptor de Servicio Oculto secundario (protegido) es accesible.
- Cuando Tor se inicia sólo con el segundo Servicio Oculto habilitado (con o sin OnionAuthentication) no parece haber problema.
- Cuando Tor se inicia con el Servicio Oculto primario protegido por OnionAuthentication, el Descriptor de Servicio Oculto es accesible.
- Cuando se ataca, aparecen estas entradas en el fichero de registro de Tor:
Aug 24 19:42:18.000 [notice] Arrancado al 100% (hecho): Hecho
Ago 24 19:42:34.000 [notice] La velocidad de su conexión de red parece haber cambiado. Restableciendo timeout a 60000ms después de 18 timeouts y 388 buildtimes.
24 ago 19:42:39.000 [aviso] Parece que la velocidad de conexión a la red ha cambiado. Restableciendo el tiempo de espera a 60000ms después de 18 tiempos de espera y 240 tiempos de compilación.
24 ago 19:42:53.000 [aviso] Parece que la velocidad de su conexión de red ha cambiado. Restableciendo el tiempo de espera a 60000ms después de 18 tiempos de espera y 489 tiempos de compilación.
24 ago 19:43:11.000 [aviso] Parece que la velocidad de su conexión de red ha cambiado. Restableciendo timeout a 60000ms después de 18 timeouts y 659 buildtimes.
...
24 ago 19:46:09.000 [aviso] Valor extremadamente grande para el tiempo de espera de construcción del circuito: 122s. Suponiendo salto de reloj. Propósito 14 (Medir el tiempo de espera del circuito)
24 ago 19:46:09.000 [aviso] Valor extremadamente alto para el tiempo de espera de construcción del circuito: 122s. Suponiendo salto de reloj. Propósito 14 (Medición del tiempo de espera del circuito)
24 ago 19:46:09.000 [aviso] Parece que la velocidad de tu conexión de red ha cambiado. Restableciendo tiempo de espera a 60000ms después de 18 tiempos de espera y 114 tiempos de construcción.
24 ago 19:46:15.000 [aviso] Parece que la velocidad de su conexión de red ha cambiado. Restableciendo timeout a 60000ms después de 18 timeouts y 125 buildtimes.
...
24 ago 19:47:08.000 [aviso] Valor extremadamente grande para el tiempo de espera de construcción del circuito: 123s. Suponiendo salto de reloj. Propósito 14 (Medir el tiempo de espera del circuito)
24 ago 19:47:10.000 [aviso] Valor extremadamente alto para el tiempo de espera de construcción del circuito: 122s. Suponiendo salto de reloj. Propósito 14 (Medición del tiempo de espera del circuito)
24 ago 19:47:10.000 [aviso] Valor extremadamente alto para el tiempo de espera de construcción del circuito: 123s. Suponiendo salto de reloj. Propósito 14 (Medición del tiempo de espera del circuito)
24 ago 19:47:13.000 [aviso] Valor extremadamente alto para el tiempo de espera de construcción del circuito: 123s. Suponiendo salto de reloj. Propósito 14 (Medición del tiempo de espera del circuito)
24 ago 19:47:14.000 [aviso] Parece que la velocidad de conexión a la red ha cambiado. Restableciendo tiempo de espera a 60000ms después de 18 tiempos de espera y 495 tiempos de construcción.
24 ago 19:47:18.000 [aviso] Parece que la velocidad de su conexión de red ha cambiado. Restableciendo timeout a 60000ms después de 18 timeouts y 124 buildtimes.
24 ago 19:47:21.000 [aviso] Valor extremadamente grande para el tiempo de espera de construcción del circuito: 122s. Suponiendo salto de reloj. Propósito 14 (Medir el tiempo de espera del circuito)
24 ago 19:47:23.000 [aviso] Valor extremadamente alto para el tiempo de espera de construcción del circuito: 123s. Suponiendo salto de reloj. Propósito 14 (Medir el tiempo de espera del circuito)
...
24 ago 19:47:55.000 [aviso] Parece que la velocidad de tu conexión de red ha cambiado. Restableciendo timeout a 60000ms después de 18 timeouts y 1000 buildtimes.
24 ago 19:47:59.000 [aviso] La velocidad de su conexión de red parece haber cambiado. Restableciendo timeout a 60000ms después de 18 timeouts y 117 buildtimes.
...
24 ago 19:52:43.000 [aviso] Valor extraño para el tiempo de compilación del circuito: 121581mseg. Suponiendo salto de reloj. Propósito 14 (Medir el tiempo de espera del circuito)
24 ago 19:52:43.000 [aviso] Parece que la velocidad de tu conexión de red ha cambiado. Restableciendo timeout a 120000ms después de 18 timeouts y 57 buildtimes.
24 ago 19:52:53.000 [aviso] Interrupción: saliendo limpiamente.
4. ¿Qué se intentó para resolver el problema?
- Configuramos un servidor completamente nuevo desde cero ejecutando sólo el SO básico así como tor y vanguards en configuración estándar para excluir la posibilidad de un error de configuración en nuestro servidor afectado. Tan pronto como tor se inició con el descriptor atacado exactamente las mismas cosas están sucediendo.
- Tratamos de dividir la carga en nuestro servidor a través de OnionBalance en esta configuración:
Servidor1: Ejecuta Onionbalance para el Descriptor de Servicio Oculto primario
Servidor2/3/4: Ejecuta el Servicio Oculto en nuevos y diferentes Descriptores de Servicio Oculto
- Esto no resucita el Descriptor de Servicio Oculto original.
- Los descriptores de servicio de los servidores 2/3/4 son accesibles cuando se abren directamente, pero no a través del descriptor primario ahora equilibrado.
- La CPU de los servidores 2/3/4 se pone al 100% mientras se produce el ataque, mientras que la CPU del servidor 1 (balanceador) permanece normal
- Añadir más servidores backend al equilibrador tampoco supuso ninguna diferencia.
- Agregamos estas directivas al bloque de servicio oculto en torrc y probamos varias configuraciones en ellas:
HiddenServiceEnableIntroDoSDefense 1
HiddenServiceEnableIntroDoSBurstPerSec <probado con varios valores>
HiddenServiceEnableIntroDoSRatePerSec <probado con varios valores>.
Esto redujo significativamente la carga de la CPU en los servidores 2/3/4, pero el descriptor de servicio equilibrado sigue siendo inalcanzable.
- Intentamos cambiar varias configuraciones en vanguards.conf, sin éxito.
- Intentamos identificar los paquetes tcp atacantes y bloquearlos mediante iptables, sin éxito.
Nuestros conocimientos no son suficientes para hacernos una idea de lo que está ocurriendo exactamente inspeccionando el contenido de dichos paquetes tcp, que tienen este aspecto:
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 (incorrecto -> 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=|---------(atacó descriptor de servicio oculto)---------| 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=|---------(atacó descriptor de servicio oculto)---------| TIME_CREATED=2022-08-24T19:45:25.10
Esto es con Tor ejecutándose en un único servidor. Cuando está equilibrado, el |---------(descriptor de servicio oculto atacado)---------| es reemplazado por los descriptores de servicio backends del servidor 2/3/4.
Podemos poner a su disposición un fragmento de tcpdump más grande, si lo necesita.
5. Conclusiones
Creemos que un adversario tiene la capacidad de "interrumpir" un Descriptor de Servicio Oculto (y por tanto el propio Servicio Oculto) inundando el demonio Tor con incontables paquetes tcp, solicitando construir circuitos. Esto es lo que causa la carga de CPU y finalmente inutiliza el Descriptor de Servicio Oculto.
¿Puede alguien confirmar esto?
Dado que las directivas HiddenServiceEnableIntroDoSDefense, HiddenServiceEnableIntroDoSBurstPerSec y HiddenServiceEnableIntroDoSRatePerSec parecen estar pensadas para defenderse de este tipo de ataques, al igual que las vanguardias, no podemos explicar por qué siguen siendo ineficaces. Tal vez sean necesarias algunas configuraciones muy especializadas de esos valores para que sean eficaces. Desafortunadamente, estas directivas (así como los ajustes en vanguards.config) sólo se describen de forma vaga.
¿Alguien sabe cómo deben configurarse correctamente para que sean efectivas?
En este punto hemos agotado todas las referencias sobre tor y la configuración de vanguards que hemos podido encontrar online.
De nuevo, cualquier ayuda o información sobre este tema será muy apreciada. No creemos que no hay solución a esto.
Si algo de lo descrito aquí tiene sentido para usted y/o tiene alguna sospecha sobre lo que está pasando, ¡cualquier tipo de comentario es extremadamente apreciado!
1. 1. ¿Qué está ocurriendo?
Nuestro servicio ha funcionado bien y estable durante mucho tiempo. De repente, nuestro servicio experimentó ligeros y luego graves problemas de rendimiento al principio, y luego se volvió completamente inaccesible.
Esto no parece ser un ataque DDoS "regular". Parece ser un ataque DoS, pero no como cualquier cosa conocida, ya que parece ser un ataque sólo al demonio Tor. Todas las contramedidas que hemos probado hasta ahora no han tenido éxito. No hay ataque perceptible en los servicios reales que se ejecutan (http, ssh, ftp, correo, etc.), sino sólo en la propia conexión Tor.
A pesar de que hicimos una profunda búsqueda e investigación, el evento parece estar más allá de nuestra comprensión. Las documentaciones sobre ataques anteriores a los Servicios Ocultos Tor son raras de encontrar y no tienen sentido para lo que estamos experimentando.
Nos negamos a creer que hay un escenario de ataque que es desconocido y no puede ser contrarrestado ya que haría a cada Servicio Oculto Tor vulnerable a él con adversarios capaces de desconectar cualquier Servicio Oculto Tor a voluntad en minutos por tiempo indefinido. El impacto en la Comunidad Tor estaría más allá del alcance.
Esperamos que alguien con el conocimiento y la experiencia necesarios pueda al menos darnos una pista de lo que está pasando exactamente e indicarnos la dirección correcta para encontrar una solución que acabe con este ataque o reduzca su impacto en nuestros sistemas y prevenga tales ataques en el futuro. Esto ayudaría a proteger los Servicios Ocultos de Tor en todo el mundo de futuros ataques como el que estamos experimentando.
2. ¿Cuál es la configuración?
- El sistema se ejecuta en un servidor linux (amd64) actual y siempre actualizado
- Todo el tráfico se enruta a través de Tor mediante el transporte Tor en el puerto 9040, las consultas DNS se resuelven a través de Tor también
- El Servicio Oculto Tor es v3
- Tor es la versión 0.4.7.8 corriendo con Libevent 2.1.12-stable, OpenSSL 1.1.1n, Zlib 1.2.11, Liblzma 5.2.5, Libzstd 1.4.8 y Glibc 2.31 como libc
- Tor compilado con GCC versión 10.2.1. Vanguards 0.3.1 también está instalado
- Tor se ejecuta como un servicio systemd
- Vanguards se ejecuta como servicio systemd
Configuración de torrc:
CookieAutenticación 1
HashedControlPassword 16:<hash>
VirtualAddrNetworkIPv4 10.192.0.0/10
AutomapHostsOnResolve 1
TransPort 127.0.0.1:9040
DNSPuerto 127.0.0.1:53
HiddenServiceDir /var/lib/tor/hidden_service
HiddenServicePort 80 127.0.0.1:80
HiddenServiceVersion 3
HiddenServiceAllowUnknownPorts 0
3. ¿Cuáles son los síntomas?
- Menos de un minuto después de iniciar Tor con el Servicio Oculto activado la CPU llega al 100%, la memoria parece no estar afectada
- El ancho de banda usado aumenta alrededor de 100kb/s
- El descriptor del Servicio Oculto es inalcanzable
- El sistema aún puede resolver direcciones clearnet y Tor
- El sistema aún puede conectarse a servicios salientes (ej. curl a un sitio web)
- El sistema se inunda con paquetes tcp entrantes en la interfaz loopback
- Cuando se reinicia Tor, la inundación termina durante unos segundos, luego comienza de nuevo
- Cuando se inicia Tor sin el Servicio Oculto habilitado no parece haber problema
- Cuando se inicia Tor con un segundo Servicio Oculto habilitado, ambos Descriptores de Servicio Oculto permanecen inalcanzables:
Navegador Tor en HS Primario:
Onionsite Se Ha Desconectado
La causa más probable es que el onionsite esté desconectado. Contacte con el administrador de onionsite.
Detalles: 0xF2 - Introducción fallida, lo que significa que el descriptor fue encontrado pero el servicio ya no está conectado al punto de introducción. Es probable que el servicio haya cambiado su descriptor o que no se esté ejecutando.
o
La conexión ha expirado
El servidor en (descriptor de servicio oculto atacado).onion está tardando demasiado en responder.
El sitio podría no estar disponible temporalmente o estar demasiado ocupado. Inténtelo de nuevo en unos momentos.
Navegador Tor en Seconday HS:
No se puede conectar
Firefox no puede establecer una conexión con el servidor en (descriptor de servicio oculto secundario).onion
El sitio podría estar temporalmente no disponible o demasiado ocupado. Inténtelo de nuevo en unos momentos.
- Cuando Tor se inicia con un segundo Servicio Oculto habilitado que está protegido por OnionAuthentication, el Descriptor de Servicio Oculto primario permanece inalcanzable,
el Descriptor de Servicio Oculto secundario (protegido) es accesible.
- Cuando Tor se inicia sólo con el segundo Servicio Oculto habilitado (con o sin OnionAuthentication) no parece haber problema.
- Cuando Tor se inicia con el Servicio Oculto primario protegido por OnionAuthentication, el Descriptor de Servicio Oculto es accesible.
- Cuando se ataca, aparecen estas entradas en el fichero de registro de Tor:
Aug 24 19:42:18.000 [notice] Arrancado al 100% (hecho): Hecho
Ago 24 19:42:34.000 [notice] La velocidad de su conexión de red parece haber cambiado. Restableciendo timeout a 60000ms después de 18 timeouts y 388 buildtimes.
24 ago 19:42:39.000 [aviso] Parece que la velocidad de conexión a la red ha cambiado. Restableciendo el tiempo de espera a 60000ms después de 18 tiempos de espera y 240 tiempos de compilación.
24 ago 19:42:53.000 [aviso] Parece que la velocidad de su conexión de red ha cambiado. Restableciendo el tiempo de espera a 60000ms después de 18 tiempos de espera y 489 tiempos de compilación.
24 ago 19:43:11.000 [aviso] Parece que la velocidad de su conexión de red ha cambiado. Restableciendo timeout a 60000ms después de 18 timeouts y 659 buildtimes.
...
24 ago 19:46:09.000 [aviso] Valor extremadamente grande para el tiempo de espera de construcción del circuito: 122s. Suponiendo salto de reloj. Propósito 14 (Medir el tiempo de espera del circuito)
24 ago 19:46:09.000 [aviso] Valor extremadamente alto para el tiempo de espera de construcción del circuito: 122s. Suponiendo salto de reloj. Propósito 14 (Medición del tiempo de espera del circuito)
24 ago 19:46:09.000 [aviso] Parece que la velocidad de tu conexión de red ha cambiado. Restableciendo tiempo de espera a 60000ms después de 18 tiempos de espera y 114 tiempos de construcción.
24 ago 19:46:15.000 [aviso] Parece que la velocidad de su conexión de red ha cambiado. Restableciendo timeout a 60000ms después de 18 timeouts y 125 buildtimes.
...
24 ago 19:47:08.000 [aviso] Valor extremadamente grande para el tiempo de espera de construcción del circuito: 123s. Suponiendo salto de reloj. Propósito 14 (Medir el tiempo de espera del circuito)
24 ago 19:47:10.000 [aviso] Valor extremadamente alto para el tiempo de espera de construcción del circuito: 122s. Suponiendo salto de reloj. Propósito 14 (Medición del tiempo de espera del circuito)
24 ago 19:47:10.000 [aviso] Valor extremadamente alto para el tiempo de espera de construcción del circuito: 123s. Suponiendo salto de reloj. Propósito 14 (Medición del tiempo de espera del circuito)
24 ago 19:47:13.000 [aviso] Valor extremadamente alto para el tiempo de espera de construcción del circuito: 123s. Suponiendo salto de reloj. Propósito 14 (Medición del tiempo de espera del circuito)
24 ago 19:47:14.000 [aviso] Parece que la velocidad de conexión a la red ha cambiado. Restableciendo tiempo de espera a 60000ms después de 18 tiempos de espera y 495 tiempos de construcción.
24 ago 19:47:18.000 [aviso] Parece que la velocidad de su conexión de red ha cambiado. Restableciendo timeout a 60000ms después de 18 timeouts y 124 buildtimes.
24 ago 19:47:21.000 [aviso] Valor extremadamente grande para el tiempo de espera de construcción del circuito: 122s. Suponiendo salto de reloj. Propósito 14 (Medir el tiempo de espera del circuito)
24 ago 19:47:23.000 [aviso] Valor extremadamente alto para el tiempo de espera de construcción del circuito: 123s. Suponiendo salto de reloj. Propósito 14 (Medir el tiempo de espera del circuito)
...
24 ago 19:47:55.000 [aviso] Parece que la velocidad de tu conexión de red ha cambiado. Restableciendo timeout a 60000ms después de 18 timeouts y 1000 buildtimes.
24 ago 19:47:59.000 [aviso] La velocidad de su conexión de red parece haber cambiado. Restableciendo timeout a 60000ms después de 18 timeouts y 117 buildtimes.
...
24 ago 19:52:43.000 [aviso] Valor extraño para el tiempo de compilación del circuito: 121581mseg. Suponiendo salto de reloj. Propósito 14 (Medir el tiempo de espera del circuito)
24 ago 19:52:43.000 [aviso] Parece que la velocidad de tu conexión de red ha cambiado. Restableciendo timeout a 120000ms después de 18 timeouts y 57 buildtimes.
24 ago 19:52:53.000 [aviso] Interrupción: saliendo limpiamente.
4. ¿Qué se intentó para resolver el problema?
- Configuramos un servidor completamente nuevo desde cero ejecutando sólo el SO básico así como tor y vanguards en configuración estándar para excluir la posibilidad de un error de configuración en nuestro servidor afectado. Tan pronto como tor se inició con el descriptor atacado exactamente las mismas cosas están sucediendo.
- Tratamos de dividir la carga en nuestro servidor a través de OnionBalance en esta configuración:
Servidor1: Ejecuta Onionbalance para el Descriptor de Servicio Oculto primario
Servidor2/3/4: Ejecuta el Servicio Oculto en nuevos y diferentes Descriptores de Servicio Oculto
- Esto no resucita el Descriptor de Servicio Oculto original.
- Los descriptores de servicio de los servidores 2/3/4 son accesibles cuando se abren directamente, pero no a través del descriptor primario ahora equilibrado.
- La CPU de los servidores 2/3/4 se pone al 100% mientras se produce el ataque, mientras que la CPU del servidor 1 (balanceador) permanece normal
- Añadir más servidores backend al equilibrador tampoco supuso ninguna diferencia.
- Agregamos estas directivas al bloque de servicio oculto en torrc y probamos varias configuraciones en ellas:
HiddenServiceEnableIntroDoSDefense 1
HiddenServiceEnableIntroDoSBurstPerSec <probado con varios valores>
HiddenServiceEnableIntroDoSRatePerSec <probado con varios valores>.
Esto redujo significativamente la carga de la CPU en los servidores 2/3/4, pero el descriptor de servicio equilibrado sigue siendo inalcanzable.
- Intentamos cambiar varias configuraciones en vanguards.conf, sin éxito.
- Intentamos identificar los paquetes tcp atacantes y bloquearlos mediante iptables, sin éxito.
Nuestros conocimientos no son suficientes para hacernos una idea de lo que está ocurriendo exactamente inspeccionando el contenido de dichos paquetes tcp, que tienen este aspecto:
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 (incorrecto -> 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=|---------(atacó descriptor de servicio oculto)---------| 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=|---------(atacó descriptor de servicio oculto)---------| TIME_CREATED=2022-08-24T19:45:25.10
Esto es con Tor ejecutándose en un único servidor. Cuando está equilibrado, el |---------(descriptor de servicio oculto atacado)---------| es reemplazado por los descriptores de servicio backends del servidor 2/3/4.
Podemos poner a su disposición un fragmento de tcpdump más grande, si lo necesita.
5. Conclusiones
Creemos que un adversario tiene la capacidad de "interrumpir" un Descriptor de Servicio Oculto (y por tanto el propio Servicio Oculto) inundando el demonio Tor con incontables paquetes tcp, solicitando construir circuitos. Esto es lo que causa la carga de CPU y finalmente inutiliza el Descriptor de Servicio Oculto.
¿Puede alguien confirmar esto?
Dado que las directivas HiddenServiceEnableIntroDoSDefense, HiddenServiceEnableIntroDoSBurstPerSec y HiddenServiceEnableIntroDoSRatePerSec parecen estar pensadas para defenderse de este tipo de ataques, al igual que las vanguardias, no podemos explicar por qué siguen siendo ineficaces. Tal vez sean necesarias algunas configuraciones muy especializadas de esos valores para que sean eficaces. Desafortunadamente, estas directivas (así como los ajustes en vanguards.config) sólo se describen de forma vaga.
¿Alguien sabe cómo deben configurarse correctamente para que sean efectivas?
En este punto hemos agotado todas las referencias sobre tor y la configuración de vanguards que hemos podido encontrar online.
De nuevo, cualquier ayuda o información sobre este tema será muy apreciada. No creemos que no hay solución a esto.
Last edited:
