Ataque de spoofing de IP que hace que todo el mundo envíe reportes de abuso a un amigo
(delroth.net)- Hetzner remitió un reporte de abuso indicando que se habían producido escaneos al puerto SSH desde
195.201.9.37, pero dentro del servidor no aparecieron evidencias de procesos maliciosos, cambios de archivos ni tráfico anómalo - El flujo real verificado con
tcpdumpmostraba que el servidor no se estaba conectando hacia22/tcpexterno, sino que múltiples hosts de Internet devolvían TCP RST al servidor, algo más cercano a backscatter - La causa principal es que, a través de redes que no aplican filtrado BCP38, se pueden enviar paquetes con una IP de origen arbitraria; en TCP, QUIC y TLS, que requieren respuestas de ida y vuelta, el atacante no puede ver directamente esas respuestas
- El mismo patrón apareció también en otros 2 Tor relays del autor, y en la lista de correo
tor-relaysy en un issue del Tor Project ya se habían reportado fenómenos similares desde días antes, incluyendo casos en los que algunos nodos quedaron temporalmente fuera de servicio - El atacante puede falsificar la IP de la víctima como origen y enviar intentos de conexión a múltiples objetivos SSH, provocando reportes de abuso automáticos, inclusión en listas de bloqueo y acciones por parte del proveedor de hosting
Reporte de abuso de Hetzner e inspección del servidor
- Hetzner envió un correo de AbuseInfo sobre la IP
195.201.9.37- El denunciante era
abuse@watchdogcyberdefense.com - En los logs se incluían varias entradas
DENIEDdirigidas al22/tcpde destinos202.91.16x.x
- El denunciante era
- A simple vista parecía que el servidor había empezado a enviar conexiones SSH a Internet, una situación que normalmente haría sospechar de una infección de malware
- Tras 1 o 2 horas de revisión, el estado del servidor seguía siendo prácticamente normal
- Sin procesos anómalos
- Sin cambios en el sistema de archivos
- Sin tráfico de red anómalo desde la perspectiva del hipervisor
- En ese servidor corrían varios servicios distribuidos y federados
- Syncthing relay
- Instancia de Mastodon
- Tor relay
- Matrix homeserver
- El Tor relay sí se conecta a algunos relays por
22/tcp, pero no coincidía con la red del reporte; tampoco había rastros de solicitudes a IP o puertos aleatorios en los logs de Matrix, Mastodon ni en la cola Sidekiq de Mastodon
El flujo real de paquetes que mostró tcpdump
- Al principio se intentó verificar tráfico saliente desde el servidor hacia
22/tcpexterno con el filtrodst port 22 - Al cambiar el filtro a
not src host 195.201.9.37, aparecieron paquetes TCP RST desde varios22/tcpde IP externas hacia puertos efímeros del servidor del autor - En realidad, el servidor no había enviado conexiones al
22/tcpde hosts aleatorios; más bien, hosts aleatorios de Internet estaban enviando paquetes reset al servidor - Este patrón coincide con backscatter, donde los paquetes de respuesta regresan a la IP falsificada debido al spoofing de IP de origen
Spoofing de IP de origen y el vacío de BCP38
- En Internet, la IP de destino debe ser correcta, pero sí es posible enviar paquetes a múltiples destinos usando una IP de origen falsa
- BCP38 es la práctica recomendada actual que indica permitir a las redes pares usar como origen solo las direcciones IP esperadas
- Este filtrado debe aplicarse al inicio de la ruta del paquete para que sea efectivo
- En la capa de grandes transit providers, el filtrado útil es difícil porque los pares esperan que ese proveedor transporte tráfico hacia todo Internet
- Basta con encontrar un solo transit provider sin BCP38 para poder enviar paquetes con cualquier IP de origen
- APNIC publicó en 2023 un artículo sobre por qué la validación de direcciones de origen sigue siendo un problema
- TCP, QUIC y la familia TLS requieren comunicación de ida y vuelta, por lo que al falsificar la IP de origen el atacante no puede ver la respuesta
- No sirve bien para comprobar resultados de un escaneo de puertos convencional
- Sí existen formas conocidas de abuso, como el DDoS por reflexión
Por qué este spoofing sí causa daño
- El flujo más plausible es que alguien esté usando la IP del autor como origen para enviar intentos de conexión al
22/tcpde múltiples hosts en Internet - Si el objetivo fuera simplemente explorar puertos abiertos, no tendría mucho sentido porque quien falsifica no puede ver las respuestas
- En el pasado existió una técnica llamada Idle Scanning, pero dependía de servidores poco ocupados y de contadores predecibles en la pila de red, y dejó de ser práctica hace décadas
- El volumen de tráfico es demasiado bajo y su duración demasiado larga, así que también parece poco convincente que se trate solo de una IP de origen mal configurada en un escáner
- El daño real aparece por la automatización de reportes de abuso
- Los intentos de conexión falsificados llegan a redes con honeypots o sistemas de detección de intrusiones
- Algunos sistemas envían reportes de abuso automáticamente
- El proveedor de hosting puede interpretar erróneamente que el servidor víctima fue comprometido o es malicioso
El mismo patrón repetido en otros Tor relays
- El autor volvió a confirmar que su servidor funcionaba como Tor relay
- Un Tor relay es un nodo interno de la red Tor y, si no es un exit node, no se comunica directamente con la Internet pública
- El relay transporta tráfico anónimo cifrado entre nodos participantes de la red Tor
- Algunos relays actúan como Guard Node y pueden servir como punto de entrada a la red Tor
- También ejecutó
tcpdumpen otros 2 relays ubicados en distintos países y con distintos ISP- Un relay en una conexión residencial
- Un relay en un VPS de Linode en Japón
- En ambos relays apareció el mismo patrón de respuestas TCP falsificadas desde
22/tcpexternos hacia la IP del relay - El autor envió un correo a la lista de correo
tor-relays, y ya existía un issue del Tor Project donde se diagnosticaba el mismo fenómeno desde días antes - Este ataque de spoofing había comenzado antes en otros tipos de nodos distintos de los relays, y hubo casos en los que algunos nodos quedaron temporalmente fuera de servicio debido a conexiones falsificadas a mayor escala
Un flujo de ataque que puede apuntar a cualquiera
- El posible flujo del ataque es el siguiente
- El atacante obtiene acceso a una red sin filtrado BCP38
- Envía solicitudes de conexión TCP al
22/tcpde múltiples hosts aleatorios en Internet - La IP de origen se falsifica con la IP de la víctima
- Los hosts objetivo o sus sistemas de seguridad interpretan que la víctima intentó conectarse y envían reportes de abuso
- Si la escala es suficiente, la IP víctima puede terminar en múltiples listas de bloqueo y el proveedor de hosting podría suspender el servidor
- Este ataque no tiene nada específico de Tor
- No parece una técnica especialmente difícil de ejecutar para un atacante con una motivación clara
- La víctima no es el atacante real, sino el propietario de la IP de origen falsificada, pero puede sufrir daños operativos por los reportes de abuso automatizados y la respuesta del proveedor de hosting
Un problema de operación de Internet que sigue vigente en 2024
- Que las IP de origen falsificadas sigan siendo un problema en 2024 es casi un fracaso operativo de Internet
- Además de BCP38, RPKI ha sufrido un problema similar en cuanto a despliegue, y solo empezó a expandirse cuando grandes empresas de Internet comenzaron a imponer requisitos directamente a sus pares
- No está claro cuál sería el siguiente paso frente a este ataque
- Ya está ocurriendo en la práctica
- El autor no sabe si se trata de un ataque documentado previamente
- Tampoco conoce una forma de rastrear a posteriori el origen real de los paquetes con IP falsificada
- Los operadores que reciban reportes de abuso similares deben verificar que su servidor podría no ser el agresor sino la víctima, y reunir evidencia para explicárselo a su proveedor de hosting
1 comentarios
Opiniones de Hacker News
Este tipo de problema es realmente molesto de manejar. Porque la respuesta legítima a un reporte de abuso —“alguien suplantó mi IP, no fui yo y mi equipo no está comprometido”— es exactamente la misma excusa que daría un actor malicioso.
Al final, como en el texto, tienes que demostrar una ausencia ante alguien a quien en realidad no le importa mucho, y eso en la práctica es casi imposible.
Un reporte de abuso automatizado sobre algo que se puede suplantar fácilmente no necesariamente justifica el reporte en sí, pero sí puede ser una razón para verificar rápido que mi servidor esté funcionando bien y no haya sido tomado.
Como mínimo haría falta una base sobre la identidad y la jurisdicción, y quizá incluso algo como una videollamada. No alcanza con decir de forma anónima en internet “soy una buena persona” y pedir que te crean.
Lo mismo pasa con direcciones MAC suplantadas, direcciones de correo, mensajes ARP, Neighbor Discovery y certificados TLS de intermediario.
Aun así, es sorprendente que algo todavía funcione.
Si se hubiera intentado diseñarla y operarla de forma perfecta, probablemente se rompería gravemente con bastante frecuencia. Su capacidad de tolerar cierta imperfección ha contribuido mucho a la robustez y utilidad de internet.
Eso no significa que no haya que mejorarla; es más bien una advertencia de que perseguir el perfeccionismo facilita cometer grandes errores que arruinan todo.
Antes se escaneaban servidores de reflexión DrDoS de una forma similar. Como ningún proveedor de hosting quiere recibir reportes por escaneo de puertos, si ponías como dirección de origen del escaneo la IP de un proveedor cloud inocente y con buena reputación, los servidores de reflexión enviaban sus respuestas UDP hacia allá sin problema.
El proveedor cloud, por supuesto, recibía una cantidad enorme de reportes, pero si les decías que desde tu servidor no se estaba haciendo ningún escaneo, lo verificaban y no apagaban el servicio. Como el servidor que enviaba los paquetes de escaneo suplantados no era detectado, podías escanear internet entero una y otra vez sin los problemas habituales de reportes de abuso.
No sé con qué frecuencia ocurre realmente, pero si se coopera con los carriers y se retroceden los saltos, es posible rastrear el origen de los paquetes suplantados. Una vez JPMorgan trabajó con Cogent y me avisó que dejara de enviar paquetes con sus direcciones IP. Como referencia, Cogent es bastante permisivo con el spoofing incluso entre los carriers de nivel 1 de internet.
Es la primera vez que escucho que este método se haya usado específicamente contra Tor, y me parece algo contraintuitivo. Pensaría que quien envía paquetes suplantados sería partidario de Tor. Probablemente sea solo un troll y, por suerte, no creo que a los proveedores que alojan Tor les preocupe mucho este tipo de cosas.
Puede que sea simplemente un troll, pero también podría ser alguien que quiere que Tor sea tratado como residuo radiactivo porque interfiere con tareas de vigilancia.
Esto no es algo nuevo. Hace unos años hice una regla de firewall muy básica: si entraba un paquete TCP hacia el puerto de destino 22 con SYN=1 y ACK=0, bloqueaba la IP de origen durante un día.
Pero empezaron las quejas de que ciertos sitios y servicios no funcionaban y resultó que, cada pocos días, llegaban paquetes así desde IPs de servidores populares como 8.8.8.8, 1.1.1.1, Steam, Roblox, Microsoft, Facebook, Instagram y varios servicios de chat. Por supuesto, todos eran paquetes suplantados, así que terminé agregando un poco más de verificación a la regla del firewall.
Por eso estoy bastante seguro de que esto es común. Personalmente sé que mi caso es excepcional, porque opero varias direcciones IP, pero necesito la flexibilidad de poder usar cualquiera de mis direcciones de origen para enviar paquetes por cualquier ISP. Para mí es importante, y si un ISP filtra por origen, es motivo para cortar la relación comercial y moverme a otro ISP.
Si es lo segundo, entra más bien en la categoría de “volver a activar la calefacción con la barra espaciadora”, y espero que los ISP arreglen sus redes rotas.
En una empresa alojaban algunos activos web on-premise en una sucursal, donde tenían un enlace de 1 Gbps. En la oficina central tenían varias líneas de 10G y un centro de datos bastante decente, así que movieron la VM web a la sede central pero conservaron la dirección IP asignada, es decir, la IP pública fija del ISP-A. Enrutaron por VPN hasta la sede central, y el servidor usaba la puerta de enlace predeterminada para enviar las respuestas con IP de origen del ISP-A por la línea de 10G del ISP-B.
Así, aunque la recepción quedaba limitada a 1G, la transmisión podía aprovechar 10G. Al fin y al cabo eran solo solicitudes GET. No era una configuración óptima y al final cambiaron la IP, pero me parece un caso de uso válido.
Segundo, tenían dos enlaces de ISP distintos, su propio ASN y su propio bloque /23. Para balancear parte del tráfico, enviaban la mitad de las IP por el ISP-A y la otra mitad por el ISP-B. Funcionaba bien, pero cuando quisieron mezclar un poco el balance aparecieron problemas interesantes. Anunciaban el primer /24 al ISP-A y el segundo /24 al ISP-B, pero el ISP-A tenía filtrado RP. Por eso tuvieron que anunciar también todas las IP por ese lado.
Por cómo funciona el filtro RP, no se puede hacer algo como prepending: todo el tráfico tiene que entrar por ellos. Si ven una mejor ruta para ese prefijo, lo filtran. Durante meses se negaron a arreglarlo alegando seguridad. Como lo justificaban diciendo que era una buena práctica de seguridad, creo que puedo decir el nombre del ISP: era Virgin Media.
Como referencia, el enlace de internet con rp_filter no costaba 20 dólares al mes, sino más de 5.000 dólares mensuales. No pudieron cambiarse porque no había alternativas en esa zona, pero si las hubiera habido, habría quedado claro quién perdía el contrato.
La hipótesis de que “a alguien no le gustan los relays de Tor” no parece muy convincente en relación con el esfuerzo invertido.
Podría ser que quienes operan relays maliciosos estén intentando bajar de forma poco ética a relays legítimos para aumentar la proporción de la red que controlan.
Con unas cuantas descargas de BitTorrent podría bastar.
¿Qué haría falta para que un número suficiente de operadores de red rechace el tráfico de todos los AS que no implementen BCP38, de modo que el spoofing ya no sea posible?
Como ya controla suficiente tráfico entrante, “comprobando la seguridad de la conexión” podría tener un significado real.
Dicho eso, es mucho más fácil reducir el factor de amplificación por reflexión. En IPv4 se pueden escanear vectores de reflexión y reclamarles a quienes responden con 10 veces los bytes de entrada.
Es un problema parecido al swatting. Depende de que una entidad con autoridad tome medidas fuertes basándose en reportes de problemas no verificados.
La diferencia sería que, en vez de contactar directamente a la autoridad, se usa a terceros no relacionados para que envíen el reporte.
Para solicitudes que son un solo paquete y ni siquiera tienen ida y vuelta, creo que un sistema no debería enviar automáticamente reportes de abuso a menos que se trate de tráfico a nivel de denegación de servicio.
Especialmente si es SSH, antes de que ocurra cualquier tipo de handshake no hay forma de considerarlo un intento de conexión válido.
Mi servidor principal también fue dado de baja una vez por un reporte de abuso falso. Afirmaban que desde mi IP habían recibido un ataque DoS de más de 1 Gbps, pero la conexión de mi servidor estaba limitada a 400 Mbps. Si una persona hubiera leído el reporte, habría sabido que era imposible, y yo no habría tenido que pelear dos días con el soporte telefónico mientras estaba de vacaciones.
Esto es como una versión IP del swatting, el acoso con patentes, incriminar a inocentes o las solicitudes de baja por DMCA para eliminar competidores.
En esencia, es una forma de convertir los mecanismos antiabuso en armas para atacar a objetivos que no gustan. Es interesante que una entidad con autoridad pueda convertirse en el eslabón débil y ser usada activamente para lograr los objetivos de actores sin escrúpulos, pero no es un fenómeno completamente nuevo.
Al ver los gráficos de cantidad de relays y de “advertised bandwidth” en metrics.torproject.org, no parece que haya producido una gran diferencia, pero igual es interesante.
Lo peor es que lugares que imitan a extorsionadores como “Watchdog Cyber Defense”, Spamhaus, Shadowserver o UCEPROTECT pueden enviar millones de reportes automáticos, y los hosts, en la práctica, tienen que hacerles caso si no quieren que sus rangos de IP terminen en listas de bloqueo.
No hay una solución dentro de banda para este problema, pero podría haber soluciones fuera de banda.
Por ejemplo: (1) avisarle al ISP de destino que se está recibiendo tráfico de retorno, (2) que ese ISP verifique de dónde vienen los paquetes y avise al ISP correspondiente, (3) repetir el paso 2 hasta encontrar el origen, (4) aislar esa parte de la red hasta que funcione correctamente.
Al final, internet está hecha de personas.