Usar un arsenal de pequeñas herramientas para bloquear bots

(lambdacreate.com)

4 puntos por GN⁺ 2025-06-02 | Aún no hay comentarios. | Compartir por WhatsApp

Gitea y el blog de un servidor personal quedaron abrumados por tráfico de scraping, con alertas continuas de disco, CPU y memoria, y el operador salió a defenderlos combinando análisis de logs, Nginx y Fail2Ban
Según Zabbix, el tráfico subió muy por encima de lo normal; el promedio mensual de Nginx fue de 8 solicitudes por segundo, y en el peor tramo llegó a más de 20 solicitudes por segundo
La causa no fue un pico único de tráfico desde Reddit o Hacker News, sino algo más cercano a scraping distribuido, con varios bloques de IP rastreando URLs de www.lambdacreate.com y krei.lambdacreate.com
Nginx devolvió 403 a user agents maliciosos conocidos y aplicó límites de solicitudes por IP; los clientes que generaban demasiados 403 fueron bloqueados con Fail2Ban durante 24 horas
Al momento de escribir, la lista de bloqueos había crecido hasta un total de 735 bans, y en particular las solicitudes que intentaban generar tarballs para todos los commits de los repositorios públicos de Gitea aumentaban la carga del servidor

Tráfico de scraping que presionó a un servidor personal

Tráfico de bots no deseado llegó de golpe a un espacio personal en internet, afectando incluso servicios a los que deberían acceder lectores reales
Servicios como Archive.org, que indexan sitios con fines de preservación, entran en la lista de permitidos, pero Amazon, Facebook, OpenAI y varios bots aleatorios se distinguen como actores que consumen contenido para sus propios fines
Se considera que la recolección masiva de datos de internet por parte de grandes empresas y la demanda de datos para entrenar modelos de IA incrementaron aún más la presión del scraping
Este tráfico se trata no como consumidores reales de Lambdacreate, sino como un obstáculo que reduce la accesibilidad para lectores humanos

El primero en alertar del problema fue Zabbix, con una advertencia de que el disco para contenedores se había llenado
En un entorno basado en LXD, se amplió un sparse file de ZFS y el sitio se bajó por un momento y luego se volvió a levantar, pero la causa raíz seguía ahí
Después, la instancia de Gitea empezó a consumir todo el disco a diario, generando 20 a 30 GB de datos por día
Al principio se interpretó como un problema de que Gitea no habilita por defecto la limpieza de archivos de repositorios, y se configuró una tarea de limpieza agresiva
Pronto siguieron alertas de CPU y memoria, se volvió difícil hacer git pull y git push en Gitea, y el cliente weechat tampoco podía mantener la conexión

Gracias a contar con monitoreo out-of-band para comparar métricas históricas con el estado actual, se pudo confirmar el patrón anómalo
En el panel de Zabbix, las métricas clave eran el número de solicitudes de Nginx y el gráfico de throughput de red
El promedio mensual de solicitudes a Nginx era de unas 8 solicitudes por segundo
En el peor momento llegaron más de 20 solicitudes por segundo; aunque para un servicio grande sería poco, para un servidor personal era alrededor de 10 veces lo habitual, por lo que el impacto fue fuerte
Más que el simple volumen de solicitudes, el aumento simultáneo del uso de disco y CPU relacionado con Gitea incrementó la carga operativa del servidor

Para mantener el servidor vivo el tiempo suficiente como para revisar los logs, se apagaron brevemente los contenedores y Nginx y se inició el análisis
Las herramientas usadas fueron lnav y goaccess
lnav muestra archivos de log en una TUI coloreada y ofrece una capa de abstracción sobre formatos de log comunes, permitiendo consultar logs con queries SQL
En access.log, la revisión se centró en estas preguntas
- Cuántas IP de visitantes había en total
- Si había patrones en las direcciones IP
- Si el tráfico venía de algún referrer específico
- Qué user agents se estaban usando
- Qué IP se asociaba con qué user agent
El análisis mostró que no era un “hug of death” proveniente de un único referrer, sino que varios bloques de IP estaban raspando URLs de todo el sitio

La primera respuesta fue listar en Nginx los user agents problemáticos y devolverles 403
La configuración de ejemplo usa map $http_user_agent $badagent para marcar agents como AdsBot-Google, Amazonbot y Amazonbot/0.1
En la configuración base de Nginx se incluyen las reglas de user agent y también se establece rate limiting por IP
La configuración del virtual host incluye estos comportamientos
- Aplicar límites de solicitudes con limit_req zone=krei burst=20 nodelay;
- Si $badagent es verdadero, bloquear el acceso al contenido con return 403;
Este enfoque ayuda a reducir el procesamiento del backend, pero como el servidor todavía tiene que recibir la solicitud HTTP y procesar el 403, sigue quedando carga cuando hay muchas solicitudes simultáneas

Una vez acumulados los logs 403, se pueden revisar con lnav las IP únicas que recibieron 403
goaccess se usa para analizar logs antiguos y actuales en conjunto y comprobar cuántas solicitudes entraron al servidor y cuáles fueron los endpoints más atacados
Para proteger realmente el servidor, se agregó Fail2Ban
La regla de Fail2Ban es una forma simple de detectar, en el access log de Nginx, IP que generan demasiadas respuestas 403
El tiempo de bloqueo se configuró en 86400 segundos, es decir, 24 horas
Al momento de escribir, el resultado de fail2ban-client status nginx-forbidden era el siguiente
- Fallos actuales: 13
- Fallos totales: 57135
- Bloqueos actuales: 38
- Bloqueos totales: 735

Finalmente, los lectores pudieron volver a acceder al blog y a otros servicios de Lambdacreate
Cuando hay que bloquear tráfico de robots, se vuelve difícil incluso escribir una entrada de blog
El tráfico problemático no estaba raspando el blog, sino apuntando a la generación de tarballs de todos los commits de cada repositorio público de la instancia de Gitea
A largo plazo, se planea considerar ampliar la lista de bloqueos o crear excepciones para servicios legítimos como Archive.org
La postura es que no se quiere que el contenido desaparezca de los motores de búsqueda, pero tampoco dejarlo como combustible para el deterioro de internet causado por la IA