Cómo frenamos a un bot que secuestraba el 20% de CPU

El misterio: la CPU que caía sola

En el mantenimiento de servidores críticos, a menudo nos enfrentamos a anomalías que no se resuelven con un simple reinicio. En uno de nuestros servidores principales observamos un patrón inusual: el consumo de CPU caía repentinamente del 40% al 20% sin una causa aparente relacionada con el tráfico de usuarios reales.

La caída en sí misma no era el problema —en otro contexto sería una buena noticia—. El problema era la asimetría: si la carga bajaba a la mitad sin que el tráfico legítimo se redujera, significaba que algo ajeno al negocio de nuestros clientes estaba consumiendo ese 20% de manera regular. Decidimos investigarlo a fondo.

1. El análisis: rastreando las huellas digitales

Utilizando estadísticas de CPU por intervalos con SAR (System Activity Reporter) cruzadas con un análisis profundo de los registros distribuidos del servidor, logramos identificar el momento exacto de cada caída de consumo. La correlación temporal fue perfecta: no se trataba de un error de software ni de un proceso de mantenimiento, sino de la finalización de un rastreo masivo periódico.

# Ver historial de CPU en intervalos de 5 minutos del día actual
sar -u 5 -f /var/log/sa/sa$(date +%d)

# Ejemplo de output que detectamos:
# 14:10:01  CPU  %user  %system  %iowait  %idle
# 14:15:01  all  38.42     1.84     0.21   59.53  ← carga normal
# 14:20:01  all  39.11     1.91     0.19   58.79  ← carga normal
# 14:25:01  all  19.87     1.02     0.08   79.03  ← caída súbita ~20%
# 14:30:01  all  20.14     0.98     0.07   78.81  ← se mantiene baja

Al cruzar esos intervalos con los logs de acceso de varios de los sitios alojados —entre ellos portales de ecommerce y webs de noticias de alto tráfico—, encontramos al culpable: Meta-webindexer. El bot de Facebook/Meta estaba realizando más de 110 peticiones por minuto de forma sostenida, recorriendo catálogos de productos y estructuras de enlaces de forma extremadamente agresiva durante varios períodos al día.

# Filtrar peticiones de Meta-webindexer en el log de acceso
grep "meta-webindexer" /var/log/httpd/access_log | \
  awk '{print $1}' | sort | uniq -c | sort -rn | head -10

# Output (peticiones por IP en el período analizado):
#   6842  66.220.149.32   ← IP primaria de Meta
#   5217  66.220.149.18
#   4991  173.252.74.112

# Calcular ratio de peticiones por minuto
grep "meta-webindexer" /var/log/httpd/access_log | \
  grep "14/Mar/2026:14" | wc -l
# Resultado: 6.720 peticiones en 60 minutos = 112 req/min

2. El dilema: seguridad vs. indexación

Ante este tipo de situaciones, el primer impulso es siempre el mismo: bloquear. Pero actuar sin pensar puede tener consecuencias no deseadas. El dilema en este caso era claro:

• Bloqueo total: Meta-webindexer no puede rastrear el sitio, lo que impide que las previsualizaciones de Open Graph funcionen cuando alguien comparte un enlace en Facebook, Instagram o WhatsApp. Impacto real en tráfico de redes sociales y en la visibilidad de campañas.
• Sin restricción: el servidor trabaja con un 20% de carga extra innecesaria en períodos de rastreo intensivo, lo que degrada la experiencia de los usuarios reales y reduce el margen ante picos de tráfico legítimo.

Además, teníamos sitios en el mismo servidor con necesidades especiales: portales de noticias que requieren una alta frecuencia de peticiones internas para regenerar cachés y lanzar tareas de mantenimiento programadas. Cualquier solución genérica de "bloquear todo lo que exceda X peticiones" se llevaría por delante esos procesos internos legítimos.

3. La solución: configurando el firewall CSF Juggernaut

Para resolver esto sin comprometer ningún servicio, implementamos una solución de capa 7 usando el firewall Juggernaut (CSF — ConfigServer Security & Firewall). La configuración se articula sobre tres pilares complementarios:

Pilar 1: Limitación de conexiones por IP (CT_LIMIT)

Establecimos un umbral de 300 conexiones por minuto por IP como límite máximo. Este valor está calibrado con precisión:

• Es lo suficientemente amplio para que la navegación humana más rápida —incluso con múltiples pestañas abiertas simultáneamente— jamás lo alcance.
• Permite que rastreadores "educados" como Googlebot o Bingbot trabajen con normalidad, ya que respetan las directrices de velocidad de rastreo.
• Frena en seco cualquier crawler que intente inundar el procesador con ráfagas de peticiones, como era el caso de Meta-webindexer.

# Número máximo de conexiones simultáneas por IP antes de aplicar acción
CT_LIMIT = "300"

# Intervalo de comprobación en segundos
CT_INTERVAL = "60"

# Tiempo de bloqueo en segundos (1800 = 30 minutos)
CT_BLOCK_TIME = "1800"

# Puertos monitorizados (HTTP y HTTPS)
CT_PORTS = "80,443"

# Acción: bloquear temporalmente con iptables
CT_BLOCK_ACTION = "1"

Pilar 2: Protección contra inundación (PORTFLOOD)

Además del límite sostenido, configuramos una segunda capa de protección contra floods de conexión: cualquier IP que intente abrir más de 30 conexiones nuevas en menos de 5 segundos sobre el puerto 80 o 443 recibe un bloqueo automático inmediato. Esta regla actúa sobre la velocidad de apertura de conexiones, no sobre el volumen total, lo que la hace especialmente eficaz contra picos súbitos.

# Formato: puerto;protocolo;hits;segundos
# Bloquear si > 30 conexiones nuevas en 5 segundos en puerto 80 (HTTP)
PORTFLOOD = "80;tcp;30;5,443;tcp;30;5"

# Tiempo de bloqueo tras flood (segundos)
PORTFLOOD_BLOCK_TIME = "1800"

# Reiniciar el contador de iptables al aplicar la regla
PORTFLOOD_ALERT = "1"

Pilar 3: Lista blanca de infraestructura (Whitelisting)

Para evitar que el servidor se bloquease a sí mismo —un problema real en entornos con muchos sitios y procesos internos—, añadimos la IP propia del servidor a la lista blanca de CSF. Esto permite que todos los procesos internos de mantenimiento, las tareas programadas de cron y las llamadas de API entre servicios del mismo servidor funcionen sin restricciones, ignorando completamente los umbrales de CT_LIMIT y PORTFLOOD.

# /etc/csf/csf.allow
# IP del propio servidor — vía rápida para procesos internos
192.168.x.x  # Sustituir por la IP real del servidor
127.0.0.1    # Loopback siempre en whitelist

# Aplicar cambios sin reiniciar el servidor
csf -r

4. Resultados y pruebas de carga

Para validar la configuración antes de darla por definitiva, realizamos pruebas de estrés controladas: ráfagas de 350 peticiones en menos de un minuto desde una IP externa de prueba, simulando el comportamiento de un bot agresivo. Los resultados fueron exactamente los esperados:

• Procesos internos: ignoraron el límite por completo gracias a la whitelist. Sin interrupciones, sin latencia adicional.
• Peticiones externas abusivas: monitorizadas en tiempo real. Al superar el umbral de CT_LIMIT, la IP quedó registrada para un bloqueo preventivo de 30 minutos si el patrón se mantuviese.
• Googlebot y rastreadores legítimos: ningún impacto. Su velocidad de rastreo natural está muy por debajo de los umbrales configurados.

Resumen del proceso de intervención

1. Diagnóstico con SAR: identificación del patrón de caída de CPU mediante análisis de estadísticas del sistema por intervalos de 5 minutos.
2. Cruce de logs de acceso: correlación temporal entre los picos de CPU y el User-Agent meta-webindexer en los registros del servidor web.
3. Evaluación del impacto SEO: análisis del riesgo de bloqueo total vs. limitación de velocidad, priorizando la solución de rate limiting.
4. Configuración de CT_LIMIT: umbral de 300 peticiones/minuto por IP con bloqueo temporal de 30 minutos al superarlo.
5. Configuración de PORTFLOOD: protección contra ráfagas súbitas de más de 30 conexiones nuevas en 5 segundos.
6. Whitelist de infraestructura: IP del propio servidor en lista blanca para garantizar que los procesos internos nunca sean bloqueados.
7. Pruebas de validación: stress test con 350 peticiones en <1 minuto para verificar el comportamiento real de todas las reglas.

Preguntas frecuentes sobre bots y rendimiento de servidor

← Volver al Blog