¿Quién no ha tenido caídas de un servidor web de Apache por saturación de conexiones en una campaña de publicidad masiva sin previo aviso?

Cuando esto pasa suelen empezar las preguntas al olvidado equipo de sistemas, sobre todo de la dirección de la empresa, ¡siempre tan atenta!

• ¿Tenemos recursos hardware suficientes?
• ¿Se están aprovechando los recursos disponibles en el servidor web?
• ¿Puedes estimar cuántas peticiones se pueden atender de forma concurrente con dichos recursos?
• ¿Qué direcciones IP son las que más peticiones hacen?
• ¿Qué puedes hacer para que no vuelva a ocurrir en la siguiente campaña?
• ¿Qué ha ocurrido? (esta es la mejor, es del personal de marketing :-) )

Para dar respuesta a todo esto y mantener nuestro puesto de trabajo y prestigio, (sobre todo lo primero), vamos a seguir los siguientes pasos, para que añadas datos a tus conclusiones propias, (en esto último no te puedo ayudar, es demasiado particular).

Por simplificar usaré como ejemplo un servidor web Apache 2.4 en Debian con formato de log combined estándar,

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\
" \"%{User-agent}i\"" combined

 y con configuración de módulo prefork.

Conocer el consumo de memoria máximo por proceso de Apache

Lo primero es conocer cuál es el consumo de memoria RAM de los procesos de Apache del servidor en un funcionamiento normal y estable para poder hacer estimaciones válidas.

Con este comando se obtienen ordenados ascendentemente los procesos de Apache por memoria ocupada.

ps -ylC Apache2 --sort:rss

El resultado es algo parecido a esto en la última línea

S    33  9825 13821  5  80   0 89572 187752 inet_c ? \
      00:00:06 Apache2

y nos quedamos con el dato del octavo campo (89572) que es la memoria en bytes ocupada por el proceso de Apache.

Un cálculo de servilleta nos da el resultado de la memoria en megabytes ocupada por el proceso.

89572 bytes / 1024 = 87,47 MBytes por proceso

Dimensionar el número máximo de conexiones

Con este dato y dando por hecho que toda la memoria RAM del servidor es dedicada al servidor web, es decir, que no comparte servidor con otros servicios, puedes dimensionar el número de conexiones máximas concurrentes que puede atender el servidor web.

Por ejemplo, con 8GB de RAM, nos reservamos un 75% de dedicación al servicio de Apache (6GB). Así evitamos el acceso del sistema a memoria SWAP. El cálculo máximo es trivial obtenerlo. ¡Saca de nuevo la servilleta!

6GB * 1024 = 6144 MB

6144MB / 87,47 MB = 70,24 procesos ~ 70 procesos concurrentes

Fijamos la directiva de MaxRequestWorkers y ServerLimit de Apache en 70.

Ya no se satura, por número de procesos. No pongas la mano en el fuego, ya que un leak de memoria puede hacer consumir más RAM a los procesos y el cálculo puede variar.

Top 10 de IPs con conexiones al servidor web por número de conexiones (tiempo real)

Durante un incremento importante de tráfico detectado por la monitorización de los servidores, puedes comprobar el top 10 de las IPs que están accediendo a nuestro servidor web, con este comando:

netstat -anp | grep apache2 | grep ESTABLISHED |\
awk -F " " '{print $5}' | awk -F ":" '{print $1}' |\
sort | uniq -c | sort -nr | head -10

Lo que vas a hacer con estas IPs ya es cosa tuya, pero te recomiendo que revises el país, proveedor, etc. A partir de ahí, si no es legítimo, analiza si debes bloquear este tráfico, notificar un abuso, ataque, etc.

NOTA: hay que tener en cuenta que si estamos detrás de un balanceador, este método no nos sirve, ya que sólo detectaremos conexiones desde las IPs del mismo. Tendremos por tanto que realizar esta operativa en los propios balanceadores (si es que tenemos acceso y no son servicios cloud como ALB de AWS, que entraremos en detalle otro día).

Top 10 de IPs por número de peticiones al servidor web (histórico)

No siempre estamos disponibles para ver en tiempo real el comportamiento del servidor en pleno pico de carga, pero aún queda esperanza. ¡Tenemos registro de todas las peticiones en los ficheros de access.log! A partir de estos ficheros puedes obtener fácilmente un top 10 de las IPs ordenadas por número de peticiones, filtrando por rutas específicas, user-agent, etc. que creamos conveniente.

grep “patrondebúsqueda” access.log | awk -F " " '{print $1}' |\
sort| uniq -c | sort -nr | head -10

o no filtrar nada.

cat access.log | awk -F " " '{print $1}' | sort| uniq -c |\
 sort -nr | head -10

Puedes comparar los resultados de los logs de accesos registrados durante la saturación del servidor respecto a otros días sin incidencias. Suele ser bastante útil.

Filtrar IPs sospechosas con mayor número de accesos

Con las IPs obtenidas del listado anterior, puedes generar reglas de iptables para bloquear el tráfico. Si partes de un fichero de texto con una IP/rango por cada línea, lo puedes transformar con vim fácilmente con este comando:

:1,$s/\d\{1,3}\.\d\{1,3}\.\d\{1,3}\.\d\{1,3}/\
iptables -A INPUT -s & \-j DROP/g

Puedes utilizar la misma expresión con el comando sed si lo prefieres.

Aplica las reglas de iptables obtenidas anteriormente (no olvides añadir la cabecera #!/bin/bash al principio del fichero y darle permisos de ejecución).

Todo esto está siendo sustituido por sistemas automáticos que detectan y actúan en consecuencia. Dependiendo de la infraestructura utilizada, las posibles soluciones son variadas y más o menos complejas. 

Con la llegada de los sistemas cloud, servidores web en autoscaling, logs centralizados, contenedores que se crean o desaparecen en cuestión de minutos, los sistemas de detección de intrusos (IDS), etc. las cosas se complican un poco más. 

El análisis por parte del equipo de sistemas es esencial para mantener los servidores estables y orientar a los equipos de desarrollo de producto.

Ya puedes contestar a la dirección de la empresa y al departamento de marketing que TODO ESTÁ BAJO CONTROL.

Si te quedan dudas, siempre puedes preguntarnos antes ;-)