Balanceador, caché y WAF por Sarenet (1ª parte)

Recientemente hemos actualizado/modernizado/mejorado uno de nuestros servicios de 1clic, el balanceador/caché/WAF desarrollado en casa, Frontalpro. Aprovechando la ocasión voy a escribir en un par de posts la función de los balanceadores y su historia en Sarenet, para pasar a comentar las características de la nueva versión y sus mejoras en una segunda entrada.

¿Qué es un balanceador?

Existen tres estrategias básicas a la hora de ampliar recursos en el desarrollo web: aumentar los recursos de un único servidor, invertir recursos en mejorar el desarrollo de la aplicación, y la que nos ocupa en este caso, la de «divide y vencerás». Es decir, separar en distintos servidores los diferentes servicios de una web, o incluso multiplicar alguno de ellos. Adicionalmente otra de las estrategias es la de cachear contenido para no tener que gastar memoria y CPU en servir una y otra vez las mismas fotos de portada, por ejemplo.

A nivel de funcionamiento de Internet significa que hasta ahora, www.sarenet.es apuntaba a un único servidor, pero ahora tenemos dos, tres, ¡veinte! ¿Qué hacemos? ¿Creamos 20 entradas en la DNS? Pero, ¿qué pasa cuando se cae uno de esos servidores? ¿Y el tema de las sesiones?

Para solucionar esto existe hardware/software que se conoce como Balanceador de carga (Load Balancer, en inglés) y que básicamente es el punto de entrada, relevando al servidor web de ese trabajo.

Balanceadores físicos y sus problemas

Antes de que el Cloud revolucionase nuestra forma de trabajar, todo era «hierro» en en el CPD. Nuestros balanceadores eran distintos modelos de Foundry ServerIron (aunque Foundry sería comprada por Brocade en 2008).

Estos equipos funcionaban bastante bien hasta que los servidores empezaron a necesitar más ancho de banda, puertos gigabit, SSL… Llegados a ese punto no tenía mucho sentido seguir invirtiendo en «hierro» cuando la mitad de los equipos ya eran virtuales y no iban a estar conectados a ese equipo. Además se entraba en problemas de licenciamiento por temas como el SSL, por puertos extra, se empezaba a escuchar el tema de firewalls de aplicaciones… Por lo que empezamos a investigar otras opciones.

Software ruso

Sobre 2009 algo empezó a cambiar en el mundo de los servidores web. Hasta entonces el servidor preferido y más utilizado era Apache, sobre todo por el auge del «stack LAMP» (Linux, Apache, MySQL y PHP), pero apareció un nuevo contendiente: Nginx. Se trataba de un servidor web con raíces rusas (otros ejemplos de software ruso: Tetris, ergo es confiable) con el rendimiento como prioridad que machacaba a Apache en todos los benchmarks.  Una de las cosas que más me gustó fue que la configuración era muy directa, nada de comandos o estructuras raras como en Apache, si no que era algo más parecido al código fuente de un programa.

Una de las opciones de Nginx (aunque Apache también lo tenía, todo hay que decirlo) era la posibilidad de trabajar como proxy inverso: recibe una petición http y la replica contra el servidor final donde se encuentra el contenido y devuelve la información de vuelta. Es decir, que puede actuar de balanceador web, ¡sin límites de sesiones, módulos, etc.. limitados por licencias! Y además lo puedo instalar en cualquier máquina virtual o servidor con pocos recursos en 5 minutos: No tardamos en aplicar Nginx como frontal de entrada a nuestros albergues compartidos.

Seguridad y WAFs

También en los últimos años  se ha popularizado WordPress como gestor de contenidos. Esto ha hecho que el desarrollo web sea accesible a mucha gente pero también ha hecho que hayan cambiado los vectores de ataque a las webs: cuando antes lo normal era que alguien te robase la contraseña del FTP para conectarse y realizar cambios (o subir la última película de «A todo gas») ahora la norma es realizar ataques contra plugins mal programados que permiten un acceso similar .

Si bien la forma de cortar los primeros ataques es sencilla y se puede realizar simplemente limitando el acceso a las IPs de gestión mediante un firewall (nosotros cerramos el acceso FTP a IPs de los Pirineos para arriba en el servicio de albergue web compartido y prácticamente erradicamos ese problema) la forma de hacerlo con los ataques webs es más complicado y es donde entra en juego un WAF o Web Application Firewall.

Este tipo de aplicaciones analiza la información que va y viene de un servidor web y revisa, contra archivos de firmas y expresiones regulares, posibles ataques a una web. La mayoría de este software se rige por las metodologías y ataques de OWASP y por lo general  (como en cualquier antivirus) no son licencias baratas. Por suerte existen varias alternativas Open Source como es Mod Security.

Mod Security es un WAF que empezó siendo un plugin para Apache, que mediante una serie de reglas (tanto libres como de pago) era capaz de plantar cara a soluciones físicas de miles de euros.

Nace Frontalpro

Teniendo ya todas las piezas del puzzle y además todo software Open Source:

• Cloud: para dar de alta servidores de forma rápida y en cualquier sitio/red.
• Nginx: para hacer de balanceador
• Mod Security: para poder hacer de WAF y proteger las webs

Con todo esto sólo faltaba algo para poder configurarlo de una forma fácil y sencilla, poder consultar logs, informes, etc. De este modo, aprovechando que estaba empezando a utilizar Django para el desarrollo de aplicaciones, me puse a ello.

El sistema correría en equipos virtuales con FreeBSD9 como sistema operativo, y tendría la administración separada de la parte de cara a cliente mediante el sistema de jails de BSD.

Todo parecía ir bien y teníamos unos cuantos clientes utilizando el sistema cuando apareció el bug #582 de Mod Security.

Problemas en Mod Security

Básicamente este bug hace que las peticiones de tipo post (es decir, mandar información al servidor, por ejemplo un formulario) fallen y no se procesen, con lo que devuelven un error 500 y no ofrecen servicio.

Aparecieron varios «workarounds» y parches mientras esperábamos que en la siguiente versión de Mod Security se arreglase, o en la siguiente de Nginx… pero no ocurrió. Tanto las versiones 2.8 y 2.9 de Mod Security seguían fallando con cualquier combinación de versión de Nginx (0.8, 1.X…). Parece que en la versión 3.0 que saldrá como librería extra estará solucionado.

Conseguimos dejarlo medianamente estable y funcionar con una versión parcheada de modsecurity 2.9 y una de nginx 1.4 pero veíamos que no podíamos ofrecer un buen servicio con este sistema, seguíamos teniendo ocasionalmente problemas de procesos colgados, fallos de memoria y CPU… por lo que nos pusimos manos a la obra en la nueva versión, que veremos en la siguiente entrada sobre el tema.

Contacta con Sarenet