Modelado de tráfico usando iptables y tc

Resumen

El mes pasado recibí una alerta automática por uso excesivo de ancho de banda, que suele ser señal de problemas. Cuando pasa esto, hay que seguir un procedimiento estándar de incidentes e intentar aislar el origen del tráfico antes de cortarlo. Sin embargo, la causa de este incidente no era la que esperaba... y requería otro tipo de solución que un simple bloqueo.

Texto completo

Alerta por exceso de ancho de banda

Cuando gestionas servidores te das cuenta de que el tráfico de internet sigue patrones bastante predecibles. Igual que el tráfico de las carreteras, tiene horas punta y horas tranquilas.

Ese patrón predecible permite detectar anomalías de forma automática. Igual que un atasco en la autopista a una hora poco habitual puede deberse a un accidente, una variación inesperada en el tráfico de internet puede indicar un incidente en el ciberespacio.

Aislar el origen

Lo primero que debes hacer es encontrar el origen del problema. Para ello, analiza la anomalía así:

• Averigua si el tráfico extra es entrante o saliente (¿subida o bajada?)
• Averigua las direcciones IP de origen y de destino implicadas (¿qué servidor está afectado? ¿Adónde va el tráfico o de dónde viene?)
• Averigua qué tipo de tráfico es (¿correo, web u otra cosa?)

Para ello, mira los gráficos de tráfico, que normalmente distinguen entrada y salida. Después intenta encontrar las direcciones IP afectadas. Puede que tengas que mirar más gráficos (de cada servidor) y estadísticas de conmutadores, routers y servidores. A continuación, revisa el uso de CPU y los archivos de registro para saber qué aplicación está afectada, por ejemplo el correo o la web. Cuanto mayor es la anomalía, más fácil es encontrarla.

Puede que, en cuanto la encuentres, te tiente cortarla y detener enseguida el tráfico asociado. Pero conviene mantenerla activa (al menos un poco más) para aprender de ella todo lo que puedas.

Usa una herramienta como iftop para ver en tiempo real el uso de ancho de banda por cada dirección IP conectada. Es muy útil para hacerte una idea de lo que pasa, sobre todo combinada con los archivos de registro (que vinculan cada dirección IP con cuentas concretas).

Una causa inusual

El servidor que producía ese uso excesivo de ancho de banda era un servidor de correo. A menudo los hackers los atacan para convertirlos en servidores de retransmisión de spam. Puede ocurrir de varias maneras, normalmente porque los spammers se hacen con un inicio de sesión válido. El resultado es mucho tráfico saliente, porque los spammers envían muchísimos correos. Si en tu servidor hay una oleada de spam, probablemente lo verás en los registros, porque los mensajes de spam rebotan con frecuencia y las colas de correo se llenan enseguida. Se vuelve un caos rápidamente, pero en este servidor no había ningún caos: solo un uso de ancho de banda fuera de lo normal.

El correo (y el spam) se envía con el protocolo SMTP, pero el tráfico en el puerto SMTP de este servidor era completamente normal. Era muy raro, porque significaba que el tráfico excesivo venía de otra cosa. ¿De qué? Tras analizar varios archivos de registro del servidor de correo, determiné que el protocolo culpable era IMAP. De algún modo, un cliente conectado al servidor de correo por IMAP generaba cantidades excesivas de tráfico de red. IMAP es un protocolo que sirve para leer el correo, no para enviarlo, así que las anomalías relacionadas con IMAP son muy poco habituales.

Analizando el registro del servidor de correo, encontré al usuario concreto que causaba el tráfico. Me puse en contacto con el cliente para preguntarle si había notado algo raro por su lado. Como era de esperar, me dijo que su ordenador iba algo lento últimamente.

El bucle de sincronización de Microsoft Outlook

Tras probar y probar por teléfono, descubrimos que algo hacía que Microsoft Outlook sincronizara las carpetas IMAP en bucle. ¡Eso hacía que su ordenador descargara una y otra vez todo el contenido de su buzón! Como su buzón superaba los 40 gigabytes, el tráfico era enorme. Al parecer, lo provoca un fallo de Microsoft Outlook y, por desgracia, no hay una solución sencilla.

Mitigar con modelado de tráfico

Me encontré ante una decisión difícil: bloquear al cliente (normal, legítimo y de pago) o dejar que siguiera el tráfico excesivo (con un coste serio para el proveedor de red). Bloquear a usuarios legítimos que llevan su negocio por correo es una pésima idea, pero dejar que continúe el tráfico excesivo tampoco es bueno. Por suerte encontré otra manera de reducir ese tráfico sin quitarle al cliente el acceso a su correo (con su fiable, pero defectuoso, Outlook).

Modelado de tráfico

El modelado de tráfico es una técnica de gestión del ancho de banda que retrasa algunos paquetes de datos (o todos) para ajustarlos a un perfil de tráfico deseado. Al aplicarlo, estás literalmente dando forma a los gráficos de tráfico, de ahí su nombre.

Esta técnica no está exenta de polémica, porque es justo lo contrario del tan aclamado principio de la "neutralidad de la red". Con el modelado de tráfico puedes bloquear o ralentizar a propósito ciertos tipos de tráfico (o cobrar más por ellos). Por principio estoy en contra de todo lo que perjudique la neutralidad de la red, pero en este caso concreto no tenía ninguna alternativa viable. Necesitaba frenar en serio el tráfico de correo de este cliente en particular, reduciendo el ancho de banda sin dejar de darle acceso a su cuenta.

Implementar el modelado de tráfico

Para modelar el tráfico hay que hacer dos cosas:

• marcar el tráfico: solo quieres afectar a cierto tráfico de red, en este caso el acceso IMAP de un cliente concreto. El resto del tráfico no debe verse afectado. Se hace marcando los paquetes que cumplen ciertas características, como la IP del cliente o los números de puerto
• aplicar la política de modelado: con herramientas de control de tráfico como 'tc', aplicas después la política de modelado al tráfico marcado. Hay varias maneras de hacerlo, pero una habitual es trabajar con los llamados "Hierarchy Token Buckets" o HTB.

Hierarchy Token Buckets (HTB)

En principio, un token bucket funciona como si limitaras el número de pasajeros de un viaje en tren repartiendo solo un número fijo de fichas disponibles. Cuando los pasajeros (o los paquetes de datos) suben al tren (o a la red), cogen una ficha. Cuando se bajan (o llegan a su destino), la devuelven. Con el principio del token bucket puedes controlar la cantidad de tráfico simultáneo en un sistema.

Puedes poner este principio en práctica con las herramientas de red "tc" (de traffic control) en combinación con "iptables". Puedes usar un script para definir las reglas de marcado y de aplicación. Hay varios ejemplos en internet; yo usé este de Julien Vehent.

Conclusión

A veces las anomalías de red no son lo que esperas, así que ¡tómate siempre el tiempo de investigarlas! Bloquear el tráfico a ciegas es brusco; a veces hay que afinar los métodos para mitigar los problemas.

No me gusta aplicar técnicas de filtrado poco ortodoxas, pero a veces son el único medio para lograr el fin. ¡Saber lo que haces y por qué lo haces es muy importante!