Anécdota: ¡Out of Memory! ¡Sacrifiquen a los niños!

Esto puede ser una lección sobre como las copias de respaldo pueden salvar vidas.

Introducción

Debido a diversas circunstancias, actualmente tengo dos instancias VPS de idénticas características, cada una destinada a diferentes propósitos que en la practica resultan difusos; una para experimentos, otra para servicios web persistentes(paginas, blogs, herramientas)

CaracterísticaCantidad
CPU1 vCPU compartido
RAM1 GB
Disco Duro25 GB disco duro (no SSD)
Droplet ultra básico en Digital Ocean. Al momento de escribir este post, su precio es de $5 mensuales.

Yo no tengo experiencia administrando servidores de forma profesional, pero a medida que he ido aprendiendo cosas, he caído en cuenta de que es necesario tener tanto una IP publica, como un equipo permanentemente conectado a la red, para lograr algunas cosas así que he ido aprendiendo cosas nuevas vez tras vez. Algunas, a costa de todos mis datos almacenados.

La historia de hoy comienza con un error común, que he subestimado al pensar que no pasaría nada:

Sep 29 12:52:46 archvb systemd[1]: mariadb.service: Main process exited, code=exited, status=1/FAILURE
Sep 29 12:52:46 archvb systemd[1]: mariadb.service: Failed with result 'exit-code'.
Sep 29 12:52:46 archvb systemd[1]: Failed to start MariaDB 10.4.8 database server.

Este error se solucionaba simplemente reiniciando el servicio, pero esta vez, en lugar de encender el servicio, la respuesta fue esta:

Job for mariadb.service failed because the control process exited with error code.
See "systemctl status mariadb.service" and "journalctl -xe" for details.

Este error no me resultaba nuevo puesto que también es un error normal, pero resultaba inesperado debido a que al volver a intentar reiniciar el servidor, salía de nuevo el mismo error. Algo no estaba yendo bien.

Mi falta de experiencia me condujo a hacer lo mismo que incluso un profesional haría; buscar en Google.

Por supuesto, Google me respondió de la misma forma fatalista como lo haría con una persona preocupada por su salud, solo que en mi caso, todas las soluciones pasaban por borrar la base de datos por completo e iniciar de cero. Terror y depresión instantánea.

Dado que esa instancia la utilizo para hacer experimentos, no hay muchos datos que valgan la pena ahí. A lo mucho los Logs del sistema domótico y los del bot para descargar música, que en general solo es información estadística (que ya perdí en otro evento catastrófico anterior). El problema era que también cree una instancia de Nextcloud, especialmente complicada de mantener.

Entre practica y practica le había tomado cariño y agregando plugin, empecé a agregar datos que puedo rescatar sin problema alguno. Lo complicado era volver a configurar todo Nextcloud de cero.

Busque en los logs del sistema tratando de entender lo que sucedía, pero no he habilitado un log de archivo por parte del servicio. Por supuesto, la carpeta estaba vacía.

Echándole un ojo al dmesg, encontré este mensaje:

[11668880.114121] Out of memory: Kill process 25000 (mariadbd) score 96 or sacrifice child
[11668880.118537] Killed process 25000 (mariadbd) total-vm:1085072kB, anon-rss:97060kB, file-rss:0kB, shmem-rss:0kB

Esta información solo confirmaba mis sospechas, pero seguía sin dar con una solución. Decidí entonces apagar todos los servicios para empezar a borrar los archivos como decían las instrucciones. Hasta que se me ocurrió intentar por ultima vez levantar el servicio de mysqld. ¡Y se levantó!

A salvo. ¿Ahora que?

No es la primera vez en la que mi servidor cae. Pero si es la primera en la que lo hace tras optimizarlo y mimarlo tanto, por lo que pensé que lo mejor seria realizar un respaldo regular de las bases de datos para empezar. ¿Pero donde?

  • Es posible crear una tarea programada con CRON para extraer una copia de seguridad en el mismo servidor, pero ¿de que serviría si esta cae junto a el?
  • Para empezar, de todas formas, comenzare haciendo una copia de seguridad local regular.
  • Es posible, mediante SSH, crear una copia de seguridad en un equipo físico, también con CRON. Hacerlo de forma regular permite poder restaurar hasta algún punto en el que no haya arruinado algo al travesear con las configuraciones.
  • Debo investigar si es posible utilizar otros servicios en la nube para crear respaldos. Tal vez Google Drive o OneDrive, puesto que tampoco tengo algo tan valioso como para pagar un servicio en la nube.
  • Y por supuesto, Todos los respaldos deben ser automáticos. Hacerlo de forma manual es probablemente mas inseguro que no hacerlo.

Consideraciones

Por el momento estoy investigando como hacer respaldos regulares, Locales, pero regulares, utilizando el cliente de consola MySQL y el automatizado de procesos CRON. Y realmente me esta gustando CRON. No entiendo por que le tuve tanto miedo si ha sido tan fácil de usar. Aunque tengo que conceder que todo lo que se maneje por consola es aterrador y mas si es poco o nada intuitivo.

Revisando los logs de mi server: w00tw00t Scan

Últimamente he tenido problemas con mis servidores, en cuanto tuve que restaurar a los valores de fabrica mi VPS interlan.dev y ahora tuve que abandonar mi servicio de hosting para interlan.ec, así que mientras descubría como valerme por mi mismo sin depender de un hosting compartido, he visto con curiosidad algunos registros de mi log.

En adelante, seguiré revisando los logs, siempre tienen cosas curiosas puesto que prácticamente el estar en internet es una vulnerabilidad. Aunque no sea un ataque explicito hacia mi server, los escaneos de vulnerabilidades ya cuentan como ataques.

En este caso, me he encontrado con la siguiente línea:

[21/Jun/2016:06:35:55 -0400] “GET /w00tw00t.at.blackhats.romanian.anti-sec:) HTTP/1.1” 400 0 “-” “ZmEu”

En un principio me pareció algo extraño así que me dispuse a investigar. Realmente no hay mucha información en internet sobre esto, pero hay, así que di con el sitio Arnon on Technology donde se explica lo siguiente

Las entradas w00tw00t son creadas por los escáneres de vulnerabilidades “ZmEu” o “DFind” como parte de un intento de ataque “banner grabbing”. Este ataque es una técnica de enumeración y en este caso, el escáner estaba buscando información sobre mi server que pueda revelar posibles “exploits”. El proceso va algo como esto: Un bot, posiblemente una computadora infectada o un servidor proxy, envía una petición “HTTP GET” con una dirección falsificada con la esperanza de que el servidor objetivo, responda con algo de información sobre sus configuraciones. En mi caso, “Nginx” determino que la petición “HTTP” estaba malformada de alguna forma, así que la rechazo con un código de error “400 Bad Request”. Al parecer, la petición carecía del encabezado “Host”, con la esperanza de que mi servidor rellene esta información, o sirva alguna otra que revele mas datos.

Aron on Technology

Habiendo visto que mi servidor también respondió con un “400 Bad Request” pude respirar tranquilo, sabiendo que al menos esta vez, mis configuraciones me han mantenido a salvo.

Hace bastante tiempo que no oía de los escáneres de vulnerabilidad, así que he investigado un poco. En la Wikipedia he encontrado esto, aunque solo en inglés:

“ZmEu” es un escáner de vulnerabilidades que busca servidores web que estén abiertos a ataques a través de “phpMyAdmin”. También intenta adivinar contraseñas “ssh” a través de métodos de fuerza bruta y deja un “backdoor” persistente. Fue desarrollado en Romania y fue especialmente común en el año 2012

Wikipedia

No quisiera tener que estar cambiando las contraseñas a cada rato, así que el siguiente paso seria agregar un “fail2ban” o usar archivos de llaves para “ssh”.

Siempre me pareció raro que reciba tantos ataques siendo que mi servidor, aparte de nuevo, nunca ha sido publicitado en ningún lado, pero sabiendo que es un escáner (muchos escáneres), tiene sentido que hayan llegado. Aunque seria genial si me dejaran en paz, tendré que ir viendo como reforzar la seguridad.

A %d blogueros les gusta esto: