Proxies residenciales: por qué el bloqueo por IP falla

Alrededor de una cuarta parte de los nodos de salida de proxies residenciales que venden los principales proveedores funcionan en dispositivos cuyos dueños no tienen idea de que forman parte de la infraestructura de alguien. Esa estimación sale de años de trabajo académico midiendo estas redes, y explica bastante, incluido cómo una firma de seguridad detectó hace poco salidas de proxies residenciales dentro de un rango de IP asignado a la Oficina Ejecutiva del Presidente. Cuando los investigadores notaron ese tráfico, la mitad llegaba entre las 5 p. m. y la medianoche hora del Este, y en internet pasó lo que siempre pasa: bromas a granel. Pero bajo las bromas hay una lección real para el resto: los proxies residenciales son la forma más eficaz de vencer las defensas basadas en IP, y si tu modelo de amenazas sigue tratando la «IP residencial» como señal de confianza, vas una generación atrasado.

Pasé cuatro años dirigiendo la detección para una empresa SaaS de tamaño mediano, y el cambio se veía en nuestros paneles en tiempo real. Por la época en que las bandas de credential stuffing pasaron de proxies de centros de datos a salidas residenciales, nuestras listas de bloqueo por IP pasaron de detectar el 80 % del tráfico de ataque a casi nada. Mismos ataques, mismas herramientas, distinto último salto. Este artículo trata de por qué pasa eso y de qué funciona de verdad cuando la reputación de IP deja de servir.

Cómo funcionan realmente los proxies residenciales

Un proxy residencial no es más que un nodo de salida en un dispositivo de consumo: un teléfono, una smart TV, un decodificador, un router doméstico. El cliente de la red de proxies paga por el tráfico que sale de esos dispositivos, y el trabajo del proveedor es tener millones de ellos disponibles en cada geografía. El suministro sale de tres lugares, de más a menos respetable.

1. SDKs con consentimiento. Apps gratuitas (VPN, widgets del clima, juegos móviles, apps de «gana dinero compartiendo tu ancho de banda») incluyen un SDK de proxy. El consentimiento está enterrado en unos términos de servicio que nadie lee, pero técnicamente existe. Es el modelo al que apuntan los grandes proveedores cuando hablan de ética.
2. Firmware comprometido y malware. Las botnets llevan años monetizándose revendiendo proxies. Una caja de streaming Android barata con firmware dudoso de fábrica es un nodo de proxy en cuanto se conecta. El dueño cree que compró un reproductor multimedia.
3. Alquiler directo de botnets. La parte baja del mercado ni finge. Si un proveedor ofrece cincuenta millones de IP rotatorias sin una política de origen declarada, basta con hacer la cuenta.

Lo importante es cómo se ve esto desde el lado del defensor. El tráfico llega desde un ASN residencial de Comcast, BT o Deutsche Telekom. La IP geolocaliza a una ciudad plausible. El DNS inverso devuelve algo como pool-96-225-14-7.nycmny.fios.verizon.net. Todas las heurísticas que construimos en los 2010 dicen que es una persona en casa. No lo es. Es un relé a 3 dólares por gigabyte, y la persona en casa no tiene idea de que existe.

Ese último punto merece énfasis, porque es la parte de la historia que debería preocuparte aunque nunca compres ni combatas proxies. El mismo SDK que retransmite ancho de banda es software bajo el control remoto de otro, ejecutándose dentro del perímetro de tu red. Hoy vende ancho de banda. No hay nada en la arquitectura que impida al operador, o a quien comprometa al operador, usar esos nodos para algo peor. Un SDK de proxy en un dispositivo dentro de una red sensible no es un problema de ancho de banda. Es un punto de apoyo con departamento de facturación.

Por qué las defensas basadas en IP están muertas

La reputación de IP tenía sentido cuando el abuso venía de lugares que parecían abuso: alojamiento a prueba de balas, rangos de centros de datos secuestrados, proxies abiertos en VPS olvidados. Podías enumerar los barrios malos. Los proxies residenciales acabaron con esa era al mover el tráfico malo a los buenos barrios, una sala de estar comprometida a la vez.

La economía lo empeora. El espacio de IP de centros de datos es finito y está muy vigilado: quema un /24 y estará en todas las listas de bloqueo en un día. Los nodos de salida residenciales son prácticamente infinitos y se regeneran solos. Una sola campaña de credential stuffing puede rotar entre decenas de miles de IP domésticas distintas, cada una haciendo dos o tres peticiones, sin activar nunca los límites de tasa por IP. Tu WAF ve diez mil «usuarios» diferentes. Bloquear una IP individual no sirve de nada; bloquear todo el ASN significa bloquear a tus clientes reales.

Por eso «el tráfico vino de la Casa Blanca» necesita una aclaración, y los escépticos en cualquier discusión sobre esta historia tienen razón al plantearla. Tener un rango de IP no implica que cada anuncio de ese rango corresponda a una única ubicación física. Las grandes organizaciones anuncian rangos desde muchos sitios, operan redes de invitados, laboratorios y superposiciones de NAT de operador. Una IP de salida dentro del rango de una organización te dice a quién está registrado el espacio, no por qué escritorio pasaron los paquetes. Cuando hagas este análisis en tu propia red (y deberías hacerlo), trata la atribución como una hipótesis que hay que contrastar con los logs de flujo internos, no como una conclusión.

Las señales de detección que todavía funcionan

La reputación de IP está muerta, pero el tráfico no es invisible. Las salidas de proxy tienen huellas. Ninguna de estas señales basta por sí sola (todas tienen explicaciones legítimas), pero combinadas son sorprendentemente eficaces. Esta es la jugada estándar de la ingeniería de detección moderna: dejar de buscar una prueba definitiva y empezar a construir una puntuación a partir de señales débiles. La misma filosofía aparece en el fingerprinting de comportamiento de scripts ofuscados: no necesitas leer el código si puedes caracterizar cómo se comporta.

Análisis de ASN y de forma de conexión

Empieza por el ASN, pero no te quedes en «¿es residencial?». La pregunta útil es si el ASN encaja con el cliente que dice ser. Una petición que presenta un user agent de Chrome de escritorio llegando desde un rango de 5G de consumo de una operadora móvil es sospechosa. También lo es el tráfico desde un ASN de ISP de consumo golpeando tu API con una concurrencia típica de centro de datos. Los nodos de proxy individuales son hogares reales, y los hogares reales tienen límites reales: ancho de banda de subida de consumo, tablas NAT, compartición de direcciones por NAT de operador. Una IP de salida que sirve a cuarenta clientes de proxy distintos en una hora produce patrones de conexión que ningún hogar generaría.

Huellas TLS y TCP

Aquí es donde cazas a los operadores descuidados. La mayoría de clientes de proxy pasan su tráfico por el software cliente del proveedor o por librerías HTTP estándar: Python requests, net/http de Go, Node. Cada una tiene un ClientHello TLS distinto: orden de suites de cifrado, listas de extensiones, grupos soportados. Los hashes JA3 y JA4 te permiten comparar lo que dice el handshake TLS sobre el cliente con lo que dice el user agent. Un «Chrome 126 en Windows» que envía una huella TLS de Go es un bot con disfraz. Algunas redes de proxy sofisticadas hacen passthrough TLS completo desde la máquina del cliente, lo que conserva la mentira, pero muchas no, e incluso las buenas se delatan en la capa TCP. Un cliente Windows declarado detrás de un TTL y un tamaño de ventana que indican Linux es otro punto en la puntuación.

Latencia y patrones de tiempo

Cada proxy residencial añade un salto a través de hardware de consumo y enlaces de subida de consumo. Ese salto tiene un coste. Si tu servicio también ve la latencia real del cliente mediante WebRTC, una medición de borde de CDN o incluso la distribución temporal de las peticiones dentro de una sesión, puedes comparar el RTT de red con la geografía declarada. Un «usuario en Denver» con un RTT de 4 ms a tu centro de datos de Virginia no está en Denver. El tiempo dentro de las sesiones también importa: la navegación humana tiene pausas para leer, movimientos de ratón y cadencia irregular. El tráfico canalizado por un proxy desde un script de automatización tiene una cualidad de metrónomo: intervalos constantes entre peticiones, sin deriva en reposo, envíos de formularios instantáneos. Aunque los atacantes añadan jitter, es jitter extraído de una distribución que un humano nunca produciría.

Heurísticas de comportamiento

La señal más fuerte es lo que hace el cliente, no lo que es. Los usuarios reales divagan. Los bots ejecutan planes. Una sesión que inicia sesión, navega directamente a la página de ajustes por una URL a la que ninguna ruta de la interfaz conduce, cambia el email y envía una solicitud de pago en noventa segundos no es una persona, digan lo que digan su IP. Mide la entropía de las secuencias: ¿recorren las sesiones tu aplicación como la dirige realmente tu frontend, o golpean endpoints en un orden que solo elegiría alguien que lee tu documentación de API? La agregación entre sesiones es la función estrella aquí. Una IP residencial que hace tres peticiones parece inocente. Trescientas IP residenciales haciendo tres peticiones cada una, con huellas TLS idénticas, resoluciones de pantalla idénticas y la misma secuencia de endpoints, es una sola operación con trescientos disfraces.

Caza de amenazas: SDKs de proxy en tu propia red

El problema de entrada es el que recibe la atención, pero la historia que originó todo esto es realmente una historia de salida: un dispositivo en una red que debería saber más estaba retransmitiendo tráfico ajeno. Ese es el escenario sobre el que sí puedes hacer algo, porque controlas el perímetro. Asume que algún usuario acabará enchufando una caja de streaming comprometida o instalando una «VPN gratis» en un teléfono de trabajo. Tu trabajo es que ese evento haga ruido.

La lógica de detección es sencilla porque los SDKs de proxy tienen una postura característica. Un nodo existe para recibir instrucciones y retransmitir tráfico, lo que implica:

• Conexiones persistentes de canal de control. Sesiones TLS de larga duración a dominios o IP desconocidos, a menudo con pequeñas cargas periódicas. Establece una línea base de tus destinos de salida; un dispositivo cliente con una conexión de seis horas a un host en un país donde no opera ninguno de tus proveedores de software merece una revisión.
• Alto fan-out de conexiones desde un dispositivo cliente. Una estación de trabajo que hace conexiones salientes a cientos de IP externas distintas por hora se comporta como infraestructura, no como una persona. Los portátiles navegan; los relés retransmiten.
• Flujos iniciados desde fuera hacia subredes de clientes. Muchos frameworks de proxy abren túneles entrantes o usan atravesado de NAT estilo STUN. Si un dispositivo en tu VLAN de invitados o de IoT recibe conexiones desde internet, algo va muy mal con tu segmentación: encuéntralo.
• Patrones de subida asimétricos. Un teléfono o una caja de TV cuyo volumen de subida se acerca al de bajada está sirviendo contenido o retransmitiendo tráfico. Ninguna de las dos cosas es normal en dispositivos de consumo.
• Líneas base por hora del día. Los investigadores que detectaron las salidas en la red gubernamental se apoyaron exactamente en esto: la actividad concentrada en horas de la tarde-noche sugería un dispositivo en una red personal, no de invitados. Tu versión propia es más simple: alerta cuando el patrón de tráfico de un dispositivo cambie de carácter, no solo de volumen.

Nada de esto requiere inspección profunda de paquetes, lo cual importa si te interesa operar una red en la que la gente pueda confiar. Los metadatos de flujo (NetFlow, logs de conexión de Zeek, VPC flow logs) contienen todas las señales anteriores. Si todavía no retienes ni estableces líneas base de los datos de flujo de salida, esa es la brecha que hay que cerrar antes de comprar nada. Los puntos ciegos aquí riman con los del registro de autenticación en la nube: los datos existen, pero nadie los mira hasta que hay un incidente.

# Quick-and-dirty hunt: client devices acting like relays
# Feed this Zeek-style conn logs; flag RFC1918 sources with
# high distinct-destination fan-out and heavy upload ratios.
awk -F'\t' '
$3 ~ /^(10\.|192\.168\.|172\.(1[6-9]|2[0-9]|3[01]))/ {
src=$3; dst=$5
up[src]+=$10; down[src]+=$12
seen[src SUBSEP dst]=1
}
END {
for (k in seen) { split(k,a,SUBSEP); fanout[a[1]]++ }
for (s in fanout)
if (fanout[s] > 200 && up[s] > down[s] * 0.5)
printf "%s dsts=%d up=%d down=%d\n", s, fanout[s], up[s], down[s]
}' conn.log | sort -t= -k2 -nr | head -20

Es una primera pasada, no un producto terminado: ajusta el umbral de fan-out con tus propias líneas base, y espera falsos positivos de tus servidores multimedia y agentes de backup hasta que los incluyas en la lista blanca. La idea es que la caza es barata. Una tarde de análisis de logs encuentra lo que un equipo de seis cifras encontraría.

La verdadera solución es la segmentación

Mi opinión, firme y formada a las malas: nunca ganarás la carrera armamentística de detección contra dispositivos de consumo comprometidos. La oferta es demasiado grande y los proveedores que envían firmware inseguro no sufren consecuencias. Lo que sí puedes hacer es que un dispositivo comprometido resulte aburrido. Una caja de streaming infectada en una VLAN de IoT bien segmentada puede vender su ancho de banda a una red de proxy: molesto, quizá embarazoso si tu rango de IP es sensible, pero no puede alcanzar tus recursos compartidos, tus APIs internas ni nada que convierta una vergüenza en una brecha.

El patrón es siempre el mismo en las revisiones de incidentes. La organización tenía una red plana, o una red de «invitados» que podía alcanzar el DNS interno y las interfaces de gestión, o una política de traiga su propio dispositivo sostenida solo por un acuerdo de aceptación con un clic. Luego entró una caja Android barata o un teléfono con un SDK incluido, y la IP de salida de la organización empezó a aparecer en los inventarios de los proveedores de proxy. La solución a posteriori es la que debió ser antes: aislamiento de clientes en redes de invitados, dispositivos IoT en una VLAN con acceso solo de salida y destinos RFC1918 denegados, dispositivos personales lejos de las zonas de confianza de producción. La defensa en profundidad no es glamurosa, pero, como hemos defendido al hablar de defensas en capas frente a controles únicos y fuertes, son las capas las que te salvan cuando falla un control, y siempre falla uno.

También vale la pena una conversación de política interna. Las apps «gratuitas» son por donde llegan estos SDKs. Si tu personal puede instalar software arbitrario en dispositivos que tocan tu red, has delegado tu perímetro en empresas de ad-tech móvil. Algunas organizaciones responden con MDM y listas blancas de apps; para la mayoría, la segmentación de red logra la misma contención con menos coste político.

Lo que esta historia nos enseña de verdad

Quitando la especulación política, la historia es una demostración limpia de dos hechos. Primero, la detección de proxies residenciales se ha convertido en una categoría de producto: los investigadores ahora pueden enumerar nodos de salida a escala y relacionarlos con rangos de IP, lo cual es telemetría genuinamente útil. Segundo, y más incómodo, cada red está a una compra descuidada de dispositivo de distancia de ser infraestructura de otro. Las redes más protegidas del mundo siguen teniendo personas, y las personas enchufan cosas.

Si te llevas una sola idea: comprueba si las IP de salida de tu organización aparecen en los inventarios de proxies residenciales. Varios servicios te lo dirán, y tu feed de inteligencia de amenazas quizá ya lo incluya. Que tu rango aparezca listado no prueba un compromiso (el NAT de operador y el espacio de direcciones compartido enturbian el panorama), pero es un punto de partida barato y de alta señal para una caza. Luego revisa tu fan-out de salida, tus conexiones de larga duración y el diseño de tus VLAN.

Los atacantes se mudaron a los buenos barrios hace años. Los defensores que lo notaron son los que dejaron de revisar direcciones y empezaron a vigilar el comportamiento.