Monit y yo

Bueno, luego de un largo parón en mi blog, hoy me pongo a escribir…

Como siempre, cada vez que escribo es para narrar un problema y una solución.

En este caso, administro un servidor de hosting, que compartía (ya no lo comparte) espacio con otras tantas páginas web de mis clientes. El problema que mi «niña bonita» el proyecto it-docs, llegó hasta la posición 1.000.000 en Alexa dentro de las páginas más vistas del mundo.

Si tenemos en cuenta la web de Netcraf, en donde dice » March 2014 survey we received responses from 919,533,715 sites » entonces entenderán que tener una web que esté dentro del 1.000.000 de sitios más visitados en el mundo. No es un mal resultado. Una página así implica una media de 6000 a 7000 visitantes diarios al día.

Pero como en esta vida nada es gratis, todo tiene un precio. Cuanto más conocida es tu página, mas ataques recibe y más mérito tiene en el mundo undeground hacerle un deface, aunque algo me dice que es mi competencia la que quiere que mi it-docs, sin ánimo de lucro no siga creciendo. Sea como sea, hay gente empeñada en que la web no prospere.

En diciembre de 2013, para ser más exactos el 31 atacaron el servidor. Para ese entonces mi pilló en Austria sin conexión a Internet la casa dónde me alojaba, en medio de las montañas del Tirol, así que desde el balcón tuve que «acceder» a pedir una wifi prestada de un hotel cercano, para poder conectarme al servidor de Alemania.

 

 

El ataque fue profundo, y el MYSQL, no era capaz de arrancar, al parecer lograron conseguir shell desde php de una web de uno de mis clientes mal configurada y lograron comprometer todo el servidor.

Pues sí lo habían hecho muy bien. Mi principal preocupación no era el estado del servidor y las más de 100 horas de trabajo que iba a requerir migrar ese servidor. Tampoco el cómo ponerlo a funcionar antes de que me llovieran las llamadas desde España. Mi principal preocupación era a quién se le ocurre un 31 de Diciembre, ponerse a atacar un servidor.

Tuve que volver a reinstalar el MYSQL, y ya por fin logre arrancar todos los servicios. Di de baja la web atacada, me guardé los logs para su posterior estudio. Mire las IP atacantes para bloquearlas, aunque eso no sirve para nada, porque las IPS atacantes eran cientos y venían de todo el mundo.

Total, dejé el servidor tocado funcionando en 30 minutos, al menos para poder festejar fin de año tranquilo.

El problema es que a los dos días, el apache empezó a caerse, y hasta el día de hoy, no fui capaz de detectar como lo hacían. Seamos sinceros, invierto más en las forenses de mis clientes que en los de mi propio servidor. Ese es el problema de vender o alquilar mi tiempo como consultor, me queda poco para mis cosas o ninguno.

Después de varios cortes y quejas de mis clientes, decidí migrar IT-DOCS a un servidor solo para él. Automáticamente los cortes y ataques del servidor se acabaron. Una de las razones que me llevaron a cambiar a IT-DOCS de servidor fue el tráfico tan alto que genera, una media de 5GB a 6 GB de descargas al día con un una media de 5000 a 7000 visitas distintas diarias y ya tenía la duda, si lo estaban atacando o recibía demasiadas peticiones simultáneamente.

Para el nuevo servidor lo fortifiqué totalmente instalando algunos módulos adicionales a mi esquema de instalación de apache que hasta la fecha nunca habían sido necesarios. Ejemplo de ellos el mod_evasive de Apache2 y el mod_security entre otros.

Con eso me quité cientos de ataques diarios y normales, el clásico tonto que intenta hacer un brute force por SSH. El mod_evasive lo bloque al momento.

El apache dejó de caerse. Y cuando pensé que había logrado superar el bache.

Mysql empieza a dejar de funcionar, una media de 2 o 3 veces al día. Así que tuve que buscar una forma de chequear el proceso de MYSQL y si estaba caído levantarlo.

Eso no es la solución, pero al menos le da disponibilidad a la web.

La solución implica saber el «cómo» para poner el parche. Y eso son unas 40 horas de trabajo repartidas en varios días. Cosa que ahora mismo, es un lujo para mi.

Lo primero que se me ocurrió fue una tarea sencilla del cron que se ejecutara cada 5 minutos y en caso de estar caído levantara el servicio.

Bien, pues me encontré con esto.

Al parecer se soluciona escribiendo  al añadir el comando del cron el camino absoluto es decir

De todas formas, el CRON ya no era del todo mi agrado, ya que no quería estar reiniciando un servicio que estaba corriendo y si lo tiraban, tenía que esperar a que el CRON programado cada x tiempo levantara el mysql.
Necesitaba algo mejor; un script que chequeara que mi MYSQL estaba caído y en ese caso solo en ese caso, lo levantara. Así que me ingenié este pequeño script.

La variable EMAIL estaba pensada para que me enviara un email cada vez que lo iniciara, pero al final pasé de eso, bastantes emails recibo ya del sistema, así que quité la línea del correo.

De alguna forma era lo que quería. Pero buscando, buscando me topé con MONIT, acordemos que es un perro muy feo, pero pronto se convirtió en mi mejor amigo.

¿Qué puede hacer MONIT por mi?

De acuerdo con su propia definición, Monit es una utilidad gratuita y Open Source para administrar y monitorear procesos, archivos, directorios y filesystems en un sistema Unix. Realiza tareas automáticas de mantenimiento y reparación y puede ejecutar acciones significativas durante situaciones de error.

Está desarrollado en C (pueden ver el código fuente en Google Code) y su demonio corre de manera casi imperceptible para el sistema, es decir, consume muy pocos recursos.

Para más información, se puede consultar el sitio oficial de Monit y su manual online (ambos en inglés).

Resumiendo:

Monit capaz de monitorizar cualquier tipo de servicio o demonio, archivos de disco o sistema, vigilar espacios de discos, identificadores de proceso PID, realizar checksum, su forma de configurar es tan potente que configurarlo requiere un poco de trabajo. Para mi, lo mejor de todo, además de monitorizar, Monit, toma acciones.

 

Vamos a ver un poco como se instala en Ubuntu:

Esto me genera una carpeta en /etc llamada monit y su archivo de configuración se llama monitrc
Lo editamos:

Ahora configuramos los servicios:

Ahora vemos la configuración de mysql

Configuración de apache

Reiniciamos el servicio de monit con

Para ver el estado basta con escribir

Al mismo tipo de información podremos acceder por vía web si accedemos a http://localhost:2812. También, si queremos acceder desde afuera, podemos configurar Monit para que escuche en otra IP (por ejemplo, 0.0.0.0) y definir un método de autenticación (para que no pueda acceder cualquiera). El usario por defecto es «admin» y el pass «monit» Mi recomendación es filtrar ip o verlo en localhost, en mi caso me instalé el lynx.

Por último si es como en  mi caso, que tengo varios servidores funcionando en todo el mundo, lo mejor es cruzar la monitorización de forma que Monit lleve la monitorización de servicios fuera de esa máquina y advierta con un email cuando no funciona un servicio.

La verdad que Monit, a pesar de ser un «perro feo» se ha convertido en mi mejor amigo para la monitorización de mis servidores. Ya que a diferencia de otros servicios externos que se limitan a enviar una notificación por email, en plan, oye tu servidor web está caído. Monit toma cartas en el asunto y lo reinicia. Y eso es más que suficiente para que sea mi amigo.

Por hoy esto es todo amigos!!!!