Si hay un problema, bloquéenlo a nivel de IP
(boston.conman.org)- Durante un análisis reciente del tráfico web, se descubrió que un web bot llamado Thinkbot era el que más tráfico generaba
- Ese bot ignora
robots.txt, y su texto de presentación también es muy poco serio: básicamente dice “si hay un problema, bloqueen la IP” - Durante un mes usó 74 IP distintas, distribuidas en 41 bloques de red
- La investigación mostró que todos esos bloques de red eran propiedad de Tencent, lo que despertó sospechas sobre si esto está relacionado con una posible transferencia de costos del Great Firewall
- Al final, se agregó una enorme regla de bloqueo que cubre más de 470 mil IP
La aparición de Thinkbot
- Mientras analizaba el tráfico web, se detectó que un web bot llamado Thinkbot ocupaba una de las posiciones más altas
- La cadena de User-Agent era igual de descuidada
“Mozilla/5.0 (compatible; Thinkbot/0.5.8; +In_the_test_phase,_if_the_Thinkbot_brings_you_trouble,_please_block_its_IP_address._Thank_you.)”.
- Aparte de la frase “si causa problemas durante la fase de prueba, por favor bloqueen su IP”, ni siquiera incluye una URL de referencia
- Tampoco respeta en absoluto el archivo
robots.txty siguió haciendo crawling - Incluso intentando bloquearlo como operador del sitio web, no usaba una sola IP sino 74 direcciones IP
- Al rastrearlas y consultar sus ASN, se vio que provenían de 41 bloques de red
- Esto significa que no es posible defenderse con un simple bloqueo de una sola IP
Relación con Tencent
- Esos 41 bloques de red eran todos propiedad de Tencent
- El autor sospecha que el gobierno chino podría estar tolerándolo o incluso fomentándolo, y que puede interpretarse como un intento de trasladar al mundo exterior el costo del Great Firewall
- Dentro de China, la recolección de contenido está permitida, y aunque se bloquee desde fuera, para el CCP eso no representa un problema; en cambio, sí impone una carga a otros países y sitios que intentan bloquearlo
Medidas de bloqueo en el firewall
- El autor añadió directamente los bloques de red de Tencent a las reglas de firewall de badbots
- Ejemplos:
43.130.0.0/18,101.32.0.0/20,150.109.96.0/19 - En total se añadieron más de 40 bloques de red, y aunque esto no cubre todas las IP propiedad de Tencent, sí incluye más de 476,590 IP únicas
Conclusión y metáfora
- El autor describe esta situación como la realidad de que en internet “ya no se puede tener nada bueno”
- Más allá del simple bloqueo de tráfico de bots, este caso muestra la erosión de la confianza en todo el ecosistema de internet y la respuesta defensiva inevitable
6 comentarios
De hecho, la teoría de la amenaza china ya se convirtió en realidad desde hace mucho en otros ámbitos, y ahora parece que China incluso está empezando a amenazar la propia supervivencia general del ecosistema de internet.
Creo que mucha gente debería darse cuenta de que esto no es algo que se diga simplemente por sentimientos de odio o sesgos políticos, sino que de verdad se está volviendo una realidad.
¿Por qué cada vez que pasan incidentes así, cuando escarbas resulta ser el PCCh..
Wow... de verdad está buenísimo...
Genial..
Otra vez China.
Opinión de Hacker News
Mientras desarrollaba un web crawler, intenté hacerlo lo más amigable posible. Revisaba estrictamente
robots.txt, rastreaba lentamente, me identificaba claramente en la cadena de User Agent y usaba una sola dirección IP. Pero terminé encontrándome con varios trucos anti-bots aplicados al propio archivorobots.txt. Últimamente, por ejemplo,robots.txtse descargaba tan lento como en un ataque slow loris, así que por error lo trataba como 404 y seguía rastreando. Después de esa experiencia, cambié el código para que, si hay timeout, se trate comoDisallow /. Irónicamente, incluso si uno quiere respetar bien las reglas, termina escribiendo código para detectar herramientas anti-botMe parece como esconder el timbre para evitar a los ladrones
Igual que en las aplicaciones de servidor, en el cliente también corto silenciosamente la conexión TCP si la otra parte actúa de forma maliciosa o incorrecta. La idea es que desperdicie recursos un rato y luego se dé cuenta por sí sola de lo que está pasando
Creo que es muy probable que esto no sea intencional. Los bots maliciosos que no respetan las reglas de
robots.txtni siquiera descargan el archivo en primer lugar, así que más que malicia, podría ser un error o incompetenciaMe parece que castigar solo a quienes intentan seguir las reglas termina siendo contraproducente
Valoro mucho que intentes respetar bien las reglas. Limitar
robots.txtpodría ser un error, pero como algunos crawlers encuentran páginas más interesantes a partir derobots.txt, retrasarlo puede ayudar a evitar problemas rápidamente. Al final, este tipo de método bloquea información del bot y lo ralentiza, y desde la perspectiva del operador del sitio, como ya sufrió daños por bots maliciosos, no le queda más que no preocuparse demasiado por distinguir entre bots honestos y deshonestosMe da curiosidad qué tienen en común los sitios web que sufren daños serios por bots. Yo he operado durante años un servidor web casero bajo un TLD
.com, con buen posicionamiento en Google para palabras clave relacionadas, y sin configuraciones especiales de bloqueo de bots en el router o el servidor. Por curiosidad alguna vez conté solo las solicitudes de bots, pero la mayoría eran escaneos de puertos o accesos a la página de índice, y casi nunca seguían enlaces cargados dinámicamente. Tanto en la época de Apache 2 como ahora operando varios sitios con Axum, no he visto un impacto notable por bots. Me pregunto si será por los listados de directorios y agradecería una explicaciónSiento que mucha gente inteligente se obsesiona de más con el tema del web scraping. A menos que la actividad de bots realmente esté causando una carga enorme o problemas graves en el sitio —claro, habrá excepciones—, la mayoría de las veces no deja de ser un juego inútil de “captura la bandera”. La diferencia aquí es que nadie encuentra la bandera del otro y lo único que se pierde es tiempo. Creo que la mejor respuesta es construir productos web rápidos y bien diseñados que sigan funcionando aunque haya participantes dispersos y difíciles de identificar generando carga. En la práctica, este enfoque también mejora muchísimo la satisfacción de los usuarios reales
Creo que tal vez no conoces la gravedad de este problema. En mi trabajo anterior yo estaba a cargo del rendimiento de la aplicación de una web app, y algunos usuarios la veían rapidísima, pero para la mayoría era lenta. Al analizar los logs de rendimiento vimos que el 60% de todas las solicitudes provenía de bots conocidos, sin contar los raros. Incluso algunas empresas llegaron a hacerle ataques DoS al servicio, y en ocasiones el sitio se cayó por eso. El problema es que los bots siempre consumen respuestas cacheadas, así que las conversaciones reales de usuarios terminan saliendo continuamente del caché LRU. Algunos bots vuelven a scrapear cada pocos minutos todas las páginas que visitaron, y otros aumentan el throughput hasta que el servicio empieza a ponerse lento. A veces incluso intentan ejecutar JavaScript y enviar formularios. Googlebot era el único que se comportaba con cortesía. Encima, el 40% del tráfico entrante real se concentraba en una sola URL, así que casi no había beneficio alguno por los bots. Fue después que entendí que muchos de ellos existían para recolectar datos para empresas de IA de primera generación
Un amigo opera una instancia pequeña y pública de gitea que solo usan sus amigos. Aun así, recibe miles de solicitudes de bots cada hora. Aunque no afecten directamente al servicio, como mínimo se siente como acoso
Yo pago un premium por los datos para poder construir productos web rápidos. Por eso, cuando bloqueo a estas entidades, no estoy perdiendo el tiempo: realmente ahorro ancho de banda y costos de servidor. Además, los clientes reales siguen recibiendo el mismo beneficio sin ninguna desventaja por que el contenido no sea scrapeado. No entiendo la lógica de pensar que uno está explotando a alguien
Más que “captura la bandera”, yo diría que se parece a un juego de golpear topos. Por experiencia personal, en los foros donde se intenta identificar y bloquear “bots malos”, siempre aparecen más y no se acaba nunca
Entre nosotros hay mucha gente inteligente, pero también una tendencia a obsesionarse demasiado con los problemas técnicos. Si no haces nada, te sigue molestando; si al menos bloqueas algo, te irrita un poco menos
Siempre me sorprende que en Hacker News haya más gente de la que esperaba que se toma
robots.txten serio. Impresiona lo buena intención que tiene mucha gente. Perorobots.txtno es una solución real. La gente tiene que saber que existerobots.txt, y además hay que agregar al crawler código para revisarlo, así que introduce complejidad. Me pregunto si habrá otra solución práctica. Se habla desde hace años de cosas como “micropagos” o “grandes árboles de Merkle para verificación de identidad”, pero nunca se ha implementado nada de esoDudo que haya muchos desarrolladores de bots que no sepan qué es
robots.txt. Más bien hay gente que se convence de que su proyecto es una excepción especial que puede ignorar las reglas de todosrobots.txtno tiene fuerza legalEn nuestros logs también vemos ese patrón de bots. Es bastante molesto, aunque al menos se identifican como bots y el tráfico real no es mucho. La mayor parte del tráfico viene de bots que fingen ser navegadores reales o llegan desde varias IP de Brasil y Asia. Llevo una semana probando de todo para bloquear bots, así que comparto algunas experiencias por si sirven.
Llegan solicitudes unas pocas veces al día desde cientos de IP, pero todas fingen ser UA reales
Casi nunca envían URL de referrer, aunque el bot de Huawei Cloud sí las manda a veces (pero su tráfico es bajo)
El intento principal fue limitar el ancho de banda de las URL que contienen
id=a1Kb/s, esperando que abandonaran al volverse lentas, pero a los bots no les importó y siguieron solicitándolasTambién se adaptaron a las conexiones keep-alive, así que en
/cgit/desactivé keep-alive por completo, pero aun así terminan ocupando todas las conexionesEl método actual es permitir las URL con
id=solo si tienen la cadena de consultanotbot; si no hay referrer, les muestro un mensaje 403 indicando que, si son usuarios legítimos, agreguen el parámetronotbot. Esto redujo la carga y mejoró las conexiones de usuarios legítimos, pero los bots siguen haciendo solicitudes y solo reciben 403 una y otra vezEn conclusión, parece que solo hay dos caminos: usar métodos ad hoc especializados para cada sitio o delegarlo a alguien con suficientes recursos, como Cloudflare. Las soluciones estándar de bloqueo de bots tienen límites, porque quien tiene suficientes recursos puede evadirlas o absorber el costo
También se puede bloquear preventivamente con 403 algunos substrings raros de UA, como
MSIE 3.0oHP-UX. Luego juntas los logs de 403 y vuelves a jugar al topo bloqueando aparte los ASN problemáticosYo uso software de la familia
publicfilede Bernstein, de los djbwares. También agregué herramientas static GEMINI UCSPI-SSL, y tomé de la especificación GEMINI la idea de prohibir tanto fragments como parámetros de consulta en la URL solicitada. La razón es la misma por la que GEMINI los prohíbe, y también aplica a los servicios HTTP estáticos. En la configuración del servidor, para procesar bien parámetros de consulta tendrías que crear por separado varios nombres de archivo extraños, lo cual no es realista. Gracias a esta idea, los intentos de explotar vulnerabilidades CGI o PHP ni siquiera llegan al sistema de archivos, sino que quedan bloqueados en la etapa de descomposición de la solicitud. A quienes operan sitios estáticos les recomendaría bloquear también los parámetros de consulta al estilo GEMINI. Claro, salvo que realmente quieran usarlos dentro de la categoría de sitio estáticoDesde hace un tiempo me pregunto si un enfoque de whitelist por rangos de IP podría ser realmente viable. También imagino algo mantenido por la comunidad, como las listas de adblock
Por desgracia, cuanto mejor se comporta un bot, más probable es que use IP estables, mientras que los actores maliciosos siempre pueden usar proxies residenciales. Si bloqueas IP de proxies residenciales, terminas perjudicando a usuarios reales, y el actor malicioso simplemente cambia a otra. Por mi experiencia lidiando con miles de IP, es difícil juzgar solo con información basada en IP; hace falta información adicional
La empresa de Pokémon Go también intentó esto justo después del lanzamiento para frenar el scraping. Dividieron las IP en tres categorías: blacklist (
Google Cloud,AWS, etc.), IP no confiables (residenciales) y whitelist (IPv4 normales, etc.). Al principio lograron frenar a los scrapers principales, pero el scraper más grande lo evadió operando una granja de módems terminales. Entonces los usuarios normales abandonaron el juego por no tener mapa, mientras que los jugadores hardcore aumentaron pagando aún más el uso del scraper. Al final, la carga sobre los servidores fue mayor. Lo veo como una de las muchas malas decisiones que tomó Pokémon GoMuchas empresas estadounidenses ya hacen esto. Pero cuando estás en el extranjero y aun así no te ofrecen una forma de cancelar el servicio mientras siguen cobrándote, eso es algo bastante absurdo
No hace falta elegir whitelist o blacklist de forma binaria. La mayoría del tráfico ocurre en una zona gris. Si pusiste una IP específica en la whitelist y luego detectas señales extrañas, tienes que quitarla, anunciarlo, avisar, recibir la notificación correspondiente y coordinar mutuamente la resolución; en la práctica eso es muy complicado. La whitelist solo funciona entre socios que tienen una relación de confianza. La blacklist es útil para bloquear direcciones problemáticas o también la CIA, Rusia, China o proveedores cloud. Un enfoque realista es usar whitelist solo para hosts internos de empresa y otros entornos con mecanismos robustos contra abuso
Estoy creando una whitelist positiva de bots a través del proyecto open source GoodBots. Los PR son más que bienvenidos
Uso un método que consiste en agregar un header personalizado a todas las solicitudes y bloquear todas las demás
Hacia afuera usamos el proxy de Cloudflare y, internamente, ponemos Crowdsec y Modsecurity CRS delante de Traefik. Después de ajustarlo para reducir falsos positivos, ha sido muy estable. Las IP bloqueadas temporalmente y las IP reportadas se envían a Crowdsec y luego se registran en un canal de Discord. En promedio bloqueamos decenas de IP distintas por día. Por sensación, los intentos de acceder a recursos privados o explotar CVE vienen mucho más de IP de EE. UU. que de IP chinas. No me preocupa el rastreo del contenido público; todo lo demás solo es accesible por SSO o intranet. Más que bloquear países específicos, resulta más efectivo bloquear directamente los intentos de exploit o flooding
Enfoques como Crowdsec son atractivos, pero creo que entregar todo el tráfico del servidor a una empresa con fines de lucro es un riesgo grande
Los intentos de ataque realmente serios al final ya los bloqueará algo como Cloudflare WAF
Muchos edificios de apartamentos solo pueden salir al exterior con unas pocas direcciones IP (ver Carrier-grade NAT)
Más de la mitad de mi tráfico viene de los bots de Bing, Claude y Facebook. No son grandes contribuyentes de tráfico, pero sí consumen recursos del servidor y son una causa principal de que el sitio se ponga lento (IA, Microsoft y Facebook a veces ignoran hasta el sentido común). China y similares son solo una parte del tráfico malicioso; el verdadero problema son las empresas estadounidenses que ignoran
robots.txto los límites de tasa en DNS