Cómo detectar bots que se hacen pasar por usuarios reales en tu sitio | Drokio Blog | Drokio
Identidadbotsbot detectionfraude
🤖Cómo detectar bots que se hacen pasar por usuarios reales en tu sitio
Los bots modernos ya no son scripts simples. Usan navegadores headless con stealth, residenciales proxies, y hasta LLMs para simular conversación humana. Cómo diferenciarlos del usuario real en 2026 combinando device fingerprinting, análisis de comportamiento y señales de red.
Drokio··10 min de lectura
Hace diez años, un bot era un script en Python con requests y beautifulsoup. Detectarlo era fácil: ausencia de JavaScript, user-agent genérico, patrón de request uniforme. Hoy el juego es distinto. Los bots modernos corren navegadores Chrome headless con plugins de stealth, rotan por proxies residenciales (IPs de usuarios reales con conexión comprometida), y usan LLMs para simular conversación humana en formularios. Distinguirlos del usuario real requiere combinar capas que ningún control individual resuelve.
El problema escala. Según reportes de la industria, en 2026 aproximadamente el 40-50% del tráfico total de internet es bot, y de ese, la mitad es malicioso (scraping agresivo, credential stuffing, inventory hoarding, ad fraud, spam). Cualquier sitio con algo que proteger — login, carrito, formulario, API — recibe tráfico bot significativo.
Este artículo explica cómo son los bots modernos realmente, qué señales los delatan, y cómo armar un stack de detección efectivo sin romper la experiencia del usuario legítimo ni el SEO.
Lo que vas a aprender
La evolución del bot: de scripts Python a Chrome headless con stealth y LLMs.
Los 4 tipos principales de bot por motivación y qué los diferencia.
Las 8 señales técnicas que delatan automation moderna.
Device fingerprinting vs behavior analysis: por qué necesitás ambos.
Cómo verificar crawlers legítimos para no romper SEO.
Política escalonada: desde rate limiting hasta bloqueo definitivo.
La evolución del bot
Entender contra qué estás peleando ayuda a elegir defensas. La trayectoria:
Generación 1: scripts simples (pre-2015)
Python + requests + beautifulsoup. Sin JavaScript, sin cookies, sin estado. Fácil de detectar por ausencia de browser features. Todavía existen — mayoría del scraping de bajo volumen.
Selenium + Chromedriver. Corre navegador real pero con marcadores de automation evidentes (navigator.webdriver = true, etc). Detección trivial con fingerprint básico.
Generación 3: headless con stealth (2020-presente)
Puppeteer o Playwright con plugins de stealth (puppeteer-extra-plugin-stealth) que remueven marcadores de automation. Usan proxies datacenter rotativos. Detectables con fingerprint avanzado y análisis de comportamiento, pero requiere esfuerzo.
Headless Chrome con stealth custom (no solo plugins públicos).
Proxies residenciales (IPs de usuarios reales vendidas/alquiladas, típicamente a través de SDKs en apps móviles baratas).
LLM para generar respuestas contextuales en formularios, CAPTCHAs de texto, conversaciones con humanos.
Simulación de movimiento de mouse con modelos entrenados en datos humanos reales.
Rotación de fingerprints para evadir tracking.
Esta generación es cara (USD 0.50-5 por request vs centavos por las anteriores), pero es la que se usa para ataques de alto valor: credential stuffing contra targets específicos, inventory hoarding de productos caros, fraud sofisticado.
Generación 5 (emergente 2026): agentes autónomos
LLMs con capacidad de navegar por objetivo (AutoGPT-like). Menos deterministas, más adaptables. Todavía en etapa temprana pero apuntan a romper defensas basadas en patrones rígidos.
Los 4 tipos por motivación
Los bots no son todos iguales. Su comportamiento y señales cambian según objetivo:
Tipo 1: scrapers
Extraen contenido del sitio (precios, catálogo, posts, datos). Pueden ser legítimos (comparadores de precio autorizados, indexadores) o maliciosos (competencia copiando catálogo, agregadores sin permiso).
Señales típicas: requests GET masivos, patrón sistemático (recorren todas las URLs), baja interacción con forms.
Impacto: consumo de bandwidth, contenido copiado, daño a SEO.
Tipo 2: credential attackers
Ejecutan credential stuffing (probar listas grandes de credenciales) o brute force contra endpoints de login.
Señales típicas: POSTs masivos a endpoints de login, errores 401/403 en volumen, IPs rotativas, patrones de temporización automatizados.
Impacto: cuentas comprometidas, daño reputacional si se ejecuta ATO exitoso.
Tipo 3: inventory / commerce abusers
Bots que acaparan stock limitado (sneakers, entradas, productos calientes) para revender. Ejecutan add-to-cart + checkout automatizado. Los más sofisticados de la categoría.
Señales típicas: pico súbito al drop de producto, patrón de checkout velocísimo, direcciones IP premium residenciales, cuentas nuevas con comportamiento limpio (muchas veces "aged accounts" compradas).
Impacto: pérdida directa de ingresos (cliente real no pudo comprar), daño a marca (experiencia frustrante), mercado secundario rentable sobre tu producto.
Tipo 4: fraud / ad abuse
Clics automáticos en ads (propios o de terceros), vistas artificiales, registros falsos para aprovechar promociones.
Señales típicas: patrón de interacción repetitivo, engagement sin conversión real, IPs de datacenters específicos, consistencia sospechosa.
Impacto: distorsión de métricas, gasto en ads desperdiciado, promociones agotadas por cuentas ficticias.
Las 8 señales técnicas que delatan automation
Ninguna sola es definitiva — el combo es lo que detecta:
Señal 1: user-agent y headers
UA que no coincide con comportamiento (dice "Chrome Windows" pero falta header sec-ch-ua).
Headers faltantes o inconsistentes.
Accept-Language genérico (en-US,en) en sitios de mercado no inglés.
Señal 2: IP reputation
Datacenter IPs (AWS, Azure, GCP) cuando debería ser residencial.
Cada cliente TCP/TLS tiene "firma" por cómo negocia la conexión. Browsers reales tienen firmas conocidas. Herramientas como Python requests, Go http.Client, curl tienen firmas distintas — un UA "Chrome" con firma de Python libraria es bot casi seguro.
Señal 4: navigator properties
Del lado cliente con JS:
navigator.webdriver === true → Selenium/Chromedriver sin stealth.
navigator.plugins.length === 0 → sospechoso (browsers reales tienen plugins).
navigator.languages vacío o inconsistente con Accept-Language.
Timezone del browser inconsistente con IP geo.
Señal 5: canvas / WebGL fingerprint
Browsers reales generan canvas fingerprints consistentes con hardware real. Headless con virtualización genera fingerprints anómalos (GPU software, ausencia de extensions específicas de hardware).
Señal 6: comportamiento de mouse y teclado
Humanos generan movimientos con curvas naturales, pausas, corrections. Bots generan movimientos rectos o con patrones repetitivos. Modelos modernos distinguen con alta precisión.
Teclado: humanos tienen distribución de timing entre keypresses variable y característica; bots típicamente uniforme.
Señal 7: velocidad e temporización
Tiempo entre page load y primera acción (humanos: 2-10 segundos; bots: menos de 500ms).
Velocidad de fill de formularios (humanos: 2-30 segundos; bots: menos de 100ms).
Consistencia de temporización (humanos variables; bots a menudo uniformes).
Señal 8: session behavior
Sesión corta con acción única (bot con objetivo específico).
Navegación sin exploración (va directo al target).
Ausencia de errores humanos (misclicks, backtrack, pausas).
Patrón de navegación sistemático (recorre URLs en orden alfabético/numérico).
¿Querés proteger tu sitio ahora?
Drako es el plugin de seguridad con IA para WordPress. Instalación en 2 minutos, desde $9/mes.
Qué mide: patrones de interacción durante la sesión (mouse, teclado, navegación, temporización).
Ventajas: detecta bots incluso con fingerprint perfecto porque el comportamiento es más difícil de imitar.
Límites: requiere sesión activa (no detecta en primera request), vulnerable a LLMs avanzados que generan comportamiento realista.
Técnicas: modelos ML sobre mouse trajectories, keystroke dynamics, navigation patterns.
Lo óptimo 2026: combinación. Device fingerprint asigna score inicial en primera request. Behavior analysis refina el score durante la sesión. Decisión compuesta final.
Verificación de crawlers legítimos (no rompas SEO)
Este es error costoso: bloquear Googlebot por confundirlo con bot malicioso. Tu sitio desaparece de resultados por semanas. Evitarlo requiere proceso explícito.
Método: reverse DNS verification
Los crawlers legítimos publican rangos IP y métodos de verificación. El proceso estándar:
Recibís request con UA "Googlebot".
Haces reverse DNS lookup sobre la IP origen.
Verificás que el hostname termina en dominio del crawler (.googlebot.com, .bing.com, .applebot.apple.com, etc).
Haces forward DNS lookup sobre el hostname obtenido.
Verificás que la IP resultante coincide con la IP origen.
Si pasan los 5 pasos, es crawler legítimo. Si solo coincide el user-agent pero no el DNS, es bot mintiendo.
Whitelisting explícito
Lista estándar a pasar sin fricción:
Google (Googlebot, Googlebot-Image, AdsBot, etc).
Bing (Bingbot, MSNBot).
DuckDuckGo, Yandex, Baidu, Naver.
Applebot, Apple-PubSub.
Facebook External, Twitter, LinkedIn (para link previews).
Ahrefs, Moz, Semrush si usás sus servicios y los autorizaste.
Mantener la lista actualizada. Los proveedores cambian rangos de tanto en tanto.
Crawl rate limits
Incluso crawlers legítimos pueden abrumar tu infraestructura si están mal configurados del otro lado. Aplicar rate limit específico para crawlers (más laxo que bots maliciosos, pero no ilimitado) evita problemas.
Política escalonada de respuesta
Binario "bloquear o permitir" no funciona. La política efectiva es gradiente:
Si patrón es masivo desde múltiples IPs: investigación dedicada.
Consideraciones por tipo de endpoint
Thresholds varían por sensibilidad del endpoint:
Home/lectura pública: muy laxos, solo bloquear obvio.
Login: estrictos, rate limit bajo, 2FA obligatorio en sospecha.
Checkout: estrictos, verificación adicional ante score medio.
API autenticada: moderados, con focus en patrón vs request individual.
API pública: muy estrictos, con tokens y quotas.
Integración con el resto del stack
Bot detection aislado es silo — integrado multiplica valor:
Con WAF: bloqueo efectivo al nivel de red antes de tocar aplicación.
Con rate limiter: reglas diferenciadas por tipo de tráfico detectado.
Con UBA: score bot influye en score UBA de sesión.
Con fraud engine: bot detection es input de modelos de scoring de transacciones.
Con SIEM: eventos bot estructurados para correlación con otros events.
Con business logic: ciertas acciones (checkout de stock limitado, bulk operations) pueden requerir score humano alto sin importar autenticación.
Errores frecuentes
Bloquear por user-agent solo: UA es mentible. Nunca confiar solo en eso.
No whitelistear crawlers: daño SEO garantizado.
Confiar en CAPTCHA como control único: resoluble por servicios automáticos.
Thresholds iguales en todos los endpoints: ignora diferencia de sensibilidad.
No tener whitelisting de usuarios legítimos edge-case: empresas con VPN propia que todas comparten IP, usuarios con ad-blocker agresivo, accessibility users — se bloquean por error.
Respuesta solo binaria: elimina gradación, maximiza falsos positivos.
No revisar periódicamente: bots evolucionan, tu detección tiene que evolucionar.
Cierre
El juego del bot vs detección es carrera permanente. En 2026 los bots usan Chrome headless con stealth premium, proxies residenciales y LLM para simular humanos — y esa capacidad sigue mejorando. Ningún control individual es suficiente. La defensa realista es combinar device fingerprinting, análisis de comportamiento, IP reputation, verificación de crawlers legítimos, y política escalonada de respuesta. Ese stack bien calibrado bloquea el 95%+ de bots maliciosos sin romper SEO ni experiencia del usuario real. Sin stack, tu sitio es parte de la superficie que mantiene el ecosistema de bots rentable.
Preguntas frecuentes
¿Captcha sigue siendo efectivo contra bots?
Parcialmente. reCAPTCHA v2 (el clásico de imágenes) es resoluble por servicios automáticos con precisión alta desde 2023. reCAPTCHA v3 (invisible, score-based) es mejor pero dependiente del ecosistema Google y tiene falsos positivos molestos. Cloudflare Turnstile y hCaptcha son alternativas modernas, pero ninguna es definitiva contra bots sofisticados. La detección real en 2026 no depende de captcha como control único — es capa entre varias.
¿Cómo distingo un bot 'bueno' (Google, Bing) de uno malicioso?
Por tres señales: (1) user-agent declarado vs comportamiento real — bots legítimos declaran honestamente y mantienen consistencia, (2) IP en rango oficial publicado del proveedor (Googlebot tiene rangos conocidos verificables por reverse DNS), (3) respeto a robots.txt y crawl rate. Bot malicioso típicamente miente en user-agent, usa IPs residenciales proxy para evadir bloqueo, y no respeta robots.txt ni crawl rate sensato. Verificación de identidad del bot bueno es trivial con reverse DNS + IP range check.
Los bots modernos usan navegadores reales (headless Chrome con stealth). ¿Cómo los detecto?
Headless Chrome con stealth plugins deja aún señales: inconsistencias en canvas fingerprint, falta de hardware acceleration genuino, patrones TCP/TLS distintos, ausencia de movimientos de mouse orgánicos, velocidad de interacción no humana. La detección de Headless moderna combina device fingerprint con análisis de comportamiento — ninguna señal sola basta, pero el combo tiene tasa de detección alta incluso contra stealth profesional.
¿Vale la pena detectar bots en un sitio chico sin problema obvio de scraping?
Depende de qué te importa. Si sos e-commerce, sí — los bots compran stock limitado para revender, scrape de precios por competencia, generan checkout spam. Si sos blog sin comercio, probablemente no es prioridad. Si tenés login, sí — la mayoría de intentos contra /wp-login.php son bots. Lo importante es identificar el vector específico: scraping, credential stuffing, spam, inventory abuse, ad fraud — y medir si tu sitio tiene el problema antes de invertir en detección.
¿Bloquear bots no me va a afectar SEO si también bloqueo a Google por error?
Sí, es riesgo real y pasa seguido. Por eso bot detection debe tener whitelisting explícito de crawlers legítimos verificados por reverse DNS, no por user-agent (que es mentible). Google, Bing, DuckDuckGo, los SEO tools comunes — todos publican rangos IP y métodos de verificación. Un sistema bien configurado pasa el 100% de crawlers legítimos y bloquea el 95%+ de bots maliciosos. La configuración incorrecta puede matarte el SEO por semanas — siempre testear en staging antes de producción.
¿Puedo detectar bots solo del lado servidor o necesito JavaScript del lado cliente?
Ambos son complementarios. Del lado servidor: user-agent, IP reputation, headers, TCP/TLS fingerprint, rate patterns. Del lado cliente con JS: device fingerprint, canvas, WebGL, hardware, comportamiento de mouse/teclado, detección de automation frameworks (Puppeteer, Playwright, Selenium tienen marcadores). Los bots más básicos se atrapan solo con señales server-side; los sofisticados requieren combinación. Un sistema serio usa los dos, con el cliente generando señal y el server tomando decisión.
Producto mencionado
🛡️
Guardián de Sesión
El score de riesgo de secuestro de tus sesiones, vía API
Riesgo de secuestro de tus sesiones autenticadas: geo-velocidad, cambio de huella de dispositivo, sesiones concurrentes, escalada de privilegios e inactivo-luego-ráfaga — un score 0-100 de hijacking con banda, counts-only, vía señales por API, identity-free. $12/mes.
2FA para WordPress: por qué no es opcional en 2026
El login de WordPress es el endpoint más atacado del sitio. Sin 2FA, una contraseña comprometida es acceso total. Con 2FA bien elegido, los ataques masivos por credencial se vuelven económicamente inviables. Qué tipo de 2FA elegir, cómo imponerlo sin perder usuarios, y los errores que anulan su valor.
