Cómo las huellas digitales TCP exponen tu scraper

¿Te gustaría probar Octo Browser con descuento?
Usa el código promocional OCTOSCRAPER para obtener un 30% de descuento en cualquier suscripción. Esta oferta solo es válida para nuevos usuarios.

Por qué incluso un navegador antidetección perfecto sigue sin ser suficiente

Para comprender la verdadera magnitud del problema, primero recordemos cómo funciona una configuración antibloqueo estándar.

Históricamente, el scraping evolucionó como una carrera armamentista a nivel de HTTP y JavaScript. Cuando los servidores empezaron a bloquear las cabeceras predeterminadas como python-requests, los desarrolladores empezaron a utilizar cadenas de User-Agent de navegadores reales. Cuando los sistemas antifraude empezaron a comprobar las propiedades del navegador, pasamos a navegadores headless modificados mediante el protocolo Chrome DevTools (CDP) o a soluciones listas para usar de navegador antidetección.

Nos hemos acostumbrado a controlar la capa de aplicación (Capa 7). Esta es la capa en la que opera el HTTP, se transmiten las cookies y las cabeceras, y se ejecuta JavaScript.

El problema es que una solicitud HTTP no se envía sola. Se encapsula dentro de un protocolo de transporte (TCP—Capa 4), que luego se encapsula dentro de un protocolo de red (IP—Capa 3). Aquí es donde reside la principal trampa arquitectónica:

• La L7 (capa de aplicación) está totalmente controlada por su aplicación: su script, Puppeteer o su navegador antidetección.

• La L3 y L4 (capas de red y transporte) están controladas por el núcleo del sistema operativo en el que se ejecuta físicamente el código (o a través del cual se enruta el tráfico). Una llamada de socket connect() simplemente cede el control a la pila de red de Linux o Windows, y a partir de ese punto el SO construye paquetes de acuerdo con sus propias reglas internas codificadas de forma rígida.

Los sistemas antifraude modernos lo saben y utilizan técnicas de análisis pasivo de huellas digitales para analizar exactamente cómo se establece una conexión TCP antes de que se envíe la primera solicitud HTTP.

Si su User-Agent en L7 afirma ser Chrome en Windows, pero el servidor ve una estructura de paquetes TCP SYN característica de Linux en L4, el sistema antifraude considera esto una anomalía obvia. Desde la perspectiva del servidor, una máquina real con Windows físicamente no puede generar un paquete de red de ese tipo. Por lo tanto, se trata de un bot que se ejecuta en un servidor Linux mientras finge ser un usuario común. El sistema antifraude actúa entonces de acuerdo con sus propias políticas: Google Maps, por ejemplo, puede devolver una página simplificada, requerir autenticación y mostrarle un CAPTCHA.

La anatomía de un paquete TCP SYN: cómo identifican los servidores su sistema operativo real

Toda conexión HTTP(S) comienza con el establecimiento de una conexión TCP: el llamado protocolo de acuerdo de tres vías. El primerísimo paquete enviado al recurso de destino es un paquete de red con el indicador SYN activado. Este diminuto paquete contiene todo lo necesario para el análisis pasivo de la huella digital del sistema operativo. Los sistemas de seguridad ni siquiera necesitan esperar a sus cabeceras HTTP. Inspeccionan los campos de servicio dentro del paquete SYN y determinan con notable precisión qué núcleo de sistema operativo lo creó.

Existen tres marcadores principales:

1. Time To Live (TTL)

El TTL es un contador que disminuye en uno cada vez que un paquete pasa a través de un enrutador en su camino hacia el servidor. Diferentes sistemas operativos utilizan diferentes valores iniciales predeterminados:

• Linux y macOS: el TTL predeterminado es 64.

• Windows: el TTL predeterminado es 128.

Si el sistema antifraude de Google recibe un paquete con un TTL de 54, puede concluir con seguridad que el origen es Linux o macOS. Si recibe un valor de 115, lo más probable es que sea Windows.

2. Tamaño de la ventana TCP (TCP Window Size)

Éste es esencialmente el tamaño del búfer de recepción. Indica cuántos datos está preparado para aceptar un dispositivo a la vez.

Dado que los datos se transmiten en fragmentos de aproximadamente 1460 bytes, los sistemas operativos suelen asignar memoria en múltiplos de ese tamaño. Sin embargo, cada SO lo hace de forma diferente.

Linux suele asignar la ventana inicial basándose en un número fijo de paquetes:

• 5840 = 4 paquetes × 1460

• 14600 = 10 paquetes × 1460

• 29200 = 20 paquetes × 1460

Cuando los sistemas antifraude ven 29200, reconocen un patrón típico del núcleo de Linux.

Windows tiende a utilizar potencias de dos o valores máximos:

• 8192 = 8 KB

• 65535 = el valor máximo que cabe en un campo Window Size de 16 bits

• 64240 = un enfoque híbrido utilizado por las versiones modernas de Windows (44 paquetes × 1460)

Los sistemas antifraude comunican estos valores con su User-Agent. Si afirma ser Chrome en Windows pero el tamaño de su ventana es 29200, la discrepancia es obvia.

3. Orden de las opciones de TCP

Éste es el mecanismo de análisis de huella digital más potente.

Los paquetes SYN incluyen parámetros adicionales como MSS, Window Scaling, SACK Permitted, Timestamps, entre otros. Los valores en sí pueden variar, pero el orden en que aparecen está codificado de forma rígida en el núcleo del sistema operativo.

Por ejemplo:

• Huella digital típica de Windows:

MSS → NOP → Window Scaling → NOP → NOP → SACK Permitted

• Huella digital típica de Linux:

MSS → SACK Permitted → Timestamps → NOP → Window Scaling

Estos detalles pueden parecer insignificantes, pero cualquier sistema antifraude avanzado identificará estas inconsistencias, restringirá las sesiones y evitará un scraping estable.

La trampa del proxy de centro de datos: por qué su sistema operativo local ya no importa

Si el análisis de la huella digital TCP/IP es el problema, una solución lógica podría parecer ejecutar el scraper en un servidor Windows Server.

Supongamos que lanza su scraper en una máquina limpia con Windows. El sistema operativo genera paquetes TCP SYN con TTL=128, tamaños de ventana adecuados y el orden de opciones correcto. Sin embargo, siguen apareciendo CAPTCHAs e interrupciones de sesión. La razón radica en cómo funcionan los servidores proxy.

Las operaciones serias de scraping casi siempre dependen de proxies. En la mayoría de las configuraciones de automatización, se utilizan proxies de centro de datos porque son económicos, rápidos y estables. El inconveniente es que la gran mayoría de estos servidores proxy ejecutan distribuciones de Linux como Ubuntu, Debian o CentOS.

Cuando utiliza un proxy, no hay una conexión de red directa entre su dispositivo y los servidores de Google. El proceso se divide en dos conexiones independientes:

1. Conexión A (Su computadora → Servidor proxy)

Su máquina Windows establece una conexión TCP con el proxy.

2. Conexión B (Servidor proxy → Google)

Tras recibir su solicitud, el proxy crea una conexión TCP completamente nueva con el servidor de destino en su nombre.

Dado que el servidor proxy ejecuta Linux, la pila de red de Linux genera el paquete SYN enviado a Google.

Como resultado, el sistema antifraude de Google ve una conexión TCP que claramente fue creada por Linux (TTL 64, tamaños de ventana estilo Linux, orden de opciones TCP de Linux). Sin embargo, dentro de esa conexión (nivel L7), ve cabeceras HTTP que afirman ser Chrome en Windows.

Los proxies de centro de datos exponen su huella digital de la capa de transporte local. Aunque opere una costosa granja de máquinas Windows reales, enrutar el tráfico a través de proxies de centro de datos estándar basados en Linux hace que todo su tráfico aparezca como Linux ante el servidor de destino.

Esta es una de las razones por las que los proxies residenciales son mejores para el scraping.

Cómo comprobar su huella digital

Pruebe siempre sus scripts en condiciones del mundo real. Intente evaluar su scraper desde la perspectiva del sistema antifraude.

Enrute el tráfico de su scraper a través de BrowserLeaks y desplácese hacia abajo hasta la sección TCP/IP Fingerprint. Si su configuración de Puppeteer utiliza un User-Agent de Windows pero el servicio informa OS Fingerprint: Linux/Android, se enfrenta exactamente a la discrepancia analizada en este artículo.

Posibles soluciones: cómo camuflar Linux

Entonces, ¿cómo hacer que su scraper supere una protección antifraude seria?

Opción 1. Cambiar el tipo de proxy

Dado que los proxies de centro de datos pueden estropear su huella digital con sus núcleos Linux, la solución más confiable es dejar de usarlos y cambiar a proxies residenciales.

Los proxies residenciales enrutan el tráfico a través de dispositivos de usuarios reales (computadoras domésticas con Windows o macOS, enrutadores domésticos). El extremo que establece la conexión TCP con los servidores de Google ya no es un servidor Linux en un centro de datos, sino una computadora real.

Cuando el tráfico pasa a través de estos dispositivos, el servidor de destino ve una huella digital TCP legítima de un dispositivo de consumo real que coincide perfectamente con su huella digital de L7. El problema de la discrepancia desaparece por sí solo.

Si adquiere proxies móviles (que funcionan a través de granjas de teléfonos inteligentes 4G reales), el extremo pasa a ser un dispositivo Android o iOS. Android se basa en el núcleo de Linux. Si ejecuta un scraper de escritorio con un User-Agent de Windows 11 a través de proxies móviles, el sistema antifraude recibirá paquetes de Android y detectará la inconsistencia.

El tipo de su perfil L7 en el navegador antidetección debe coincidir estrictamente con el tipo de extremo del proxy. Con proxies móviles, active la emulación de Chrome para móviles. Con proxies residenciales, busque grupos que proporcionen IP de Windows de escritorio.

Opción 2. Ajustar el núcleo de Linux

Si ejecuta scripts directamente desde un servidor Linux sin proxies (o gestiona sus propios proxies que puede controlar por completo), deberá camuflar la pila de red del sistema operativo.

Nivel 1. Ajustes básicos (TTL)

Puede cambiar el TTL predeterminado para que coincida con Windows con un único comando iptables. El núcleo reescribirá el valor de TTL del paquete inmediatamente antes de la transmisión:

iptables -t mangle -A POSTROUTING -j TTL --ttl-set 128

Nivel 2. Modificación profunda (Tamaño de ventana y Opciones de TCP)

Suplantar el tamaño de la ventana inicial y el orden de las opciones de TCP es mucho más difícil. Los ajustes básicos de sysctl no son suficientes porque la estructura del paquete está codificada de forma rígida en el código fuente del núcleo de Linux.

Para camuflar Linux como Windows en el nivel de Opciones de TCP, puede utilizar el mecanismo NFQueue. Así es como funciona:

1. Los paquetes salientes son interceptados por el núcleo y reenviados al espacio de usuario.

2. Una utilidad especial (escrita en C o Python utilizando la biblioteca Scapy) los captura.

3. El programa analiza la cabecera TCP, cambia el tamaño de la ventana a 65535 o 64240, reorganiza las opciones (MSS, NOP, Window Scale, etc.) en el orden deseado, recalcula la suma de comprobación y devuelve el paquete al núcleo para su transmisión.

Existen utilidades listas para usar (como p0f-obfuscator y módulos de proyectos de evasión de DPI) que pueden realizar estas modificaciones sobre la marcha. La configuración es compleja y puede reducir el rendimiento de la red, pero hace que su servidor Linux sea invisible para las técnicas de análisis pasivo de huellas digitales.

Opción 3. Pasar a infraestructura de Windows

El enfoque más sencillo es no ocultar Linux en absoluto, sino ejecutar toda su infraestructura de scraping en Windows Server.

Puede migrar su código a una máquina Windows y enviar el tráfico directamente. En este caso, la pila de red nativa de Microsoft genera paquetes naturales con:

• TTL 128,

• tamaños de ventana apropiados,

• y el orden canónico de opciones de TCP de Windows.

Sin embargo, este enfoque tiene inconvenientes:

Costo. El alquiler de los servidores Windows siempre es más caro.

Consumo de recursos. El propio sistema operativo requiere una cantidad significativa de recursos de RAM y CPU para procesos en segundo plano.

Escalabilidad. Implementar, actualizar y escalar una flota de scrapers en Windows es mucho más difícil que crear docenas de contenedores Docker ligeros en Ubuntu.

Conclusión

La simple suplantación de User-Agent, Canvas, WebGL y navigator.platform ya no es suficiente para garantizar el éxito, especialmente cuando se trata de plataformas fuertemente protegidas como Google, Cloudflare, Akamai o DataDome. Los sistemas modernos antifraude han aprendido a analizar no solo qué datos envía, sino también cómo los entrega en el nivel de red fundamental.

Si experimenta problemas de scraping y no puede determinar la causa, es hora de analizar la coherencia de todas las capas del modelo OSI. Si su capa de aplicación no coincide lógica o matemáticamente con las capas de transporte y red (L3/L4), el problema puede estar ahí.

Si su configuración cuidadosamente establecida (con un navegador antidetección de alta calidad y proxies costosos) comienza a recibir errores 403 inexplicables, ofrece versiones simplificadas de las páginas o activa CAPTCHAs, deje de cambiar constantemente las huellas digitales de JavaScript. Intente mirar una capa más profunda.