Cómo asegurar servidores MySQL/MariaDB

Después de los ataques a las bases de datos MongoDB, recientemente también hemos visto que los servidores MySQL están siendo atacados por ransomware. Esto no debería sorprender, dada la creciente adopción de nubes públicas y privadas. Ejecutar una base de datos mal configurada en la nube puede convertirse en una gran responsabilidad.

En esta publicación de blog, compartiremos con usted una serie de consejos sobre cómo proteger y asegurar sus servidores MySQL o MariaDB.

Comprender el vector de ataque

Citando a SCMagazine:
“El ataque comienza con la fuerza bruta de la contraseña raíz para la base de datos MySQL. Una vez iniciada la sesión, se recuperan las bases de datos y las tablas de MySQL. Luego, el atacante crea una nueva tabla llamada "ADVERTENCIA" que incluye una dirección de correo electrónico de contacto, una dirección de bitcoin y una solicitud de pago. ”

Según el artículo, el vector de ataque comienza adivinando la contraseña raíz de MySQL a través del método de fuerza bruta. El ataque de fuerza bruta consiste en que un atacante prueba muchas contraseñas o frases de contraseña con la esperanza de finalmente adivinar correctamente. Esto significa que, por lo general, las contraseñas cortas se pueden descubrir con bastante rapidez, pero las contraseñas más largas pueden tardar días o meses.

La fuerza bruta es un ataque común que le ocurriría a cualquier servicio. Desafortunadamente para MySQL (y muchos otros DBMS), no existe una función lista para usar que detecte y bloquee los ataques de fuerza bruta desde direcciones específicas durante la autenticación del usuario. Sin embargo, MySQL captura fallas de autenticación en el registro de errores.

Revise su política de contraseñas

Revisar la política de contraseñas de MySQL es siempre el primer paso para proteger su servidor. La contraseña de root de MySQL debe ser lo suficientemente fuerte con una combinación de letras, números y símbolos (lo que hace que sea más difícil de recordar) y almacenarse en un lugar seguro. Cambie la contraseña periódicamente, al menos cada trimestre natural. Según el vector de ataque, este es el punto más débil al que se dirigen los piratas informáticos. Si valoras tus datos, no pases por alto esta parte.

Las implementaciones de MySQL realizadas por ClusterControl siempre seguirán las mejores prácticas de seguridad del proveedor, por ejemplo, no habrá un host comodín definido durante GRANT y las credenciales de inicio de sesión confidenciales almacenadas en el archivo de configuración solo se permiten al usuario raíz del sistema operativo. Recomendamos enfáticamente a nuestros usuarios que especifiquen una contraseña segura durante la etapa de implementación.

En un entorno de producción estándar, los servidores de bases de datos suelen estar ubicados en un nivel inferior. Esta capa debe estar protegida y solo se puede acceder a ella desde el nivel superior, como la aplicación o el equilibrador de carga. Si la base de datos se ubica junto con la aplicación, incluso puede bloquear direcciones no locales y usar el archivo de socket MySQL en su lugar (menos sobrecarga y más seguro).

Configurar el parámetro "bind-address" es vital aquí. Tenga en cuenta que el enlace de MySQL está limitado a ninguna, una o todas las direcciones IP (0.0.0.0) en el servidor. Si no tiene otra opción y necesita MySQL para escuchar todas las interfaces de red, restrinja el acceso al servicio MySQL desde buenas fuentes conocidas. Use una aplicación de firewall o un grupo de seguridad para incluir en la lista blanca el acceso solo desde los hosts que necesitan acceder a la base de datos directamente.

A veces, el servidor MySQL debe estar expuesto a una red pública para fines de integración (por ejemplo, monitoreo, auditoría, respaldo, etc.). Eso está bien siempre y cuando dibujes un borde alrededor. No permita que fuentes no deseadas "vean" el servidor MySQL. Puede apostar cuántas personas en el mundo saben que 3306 es el puerto predeterminado para el servicio MySQL, y simplemente realizando un escaneo de puerto contra una dirección de red, un atacante puede crear una lista de servidores MySQL expuestos en la subred en menos de un minuto. Se recomienda utilizar un puerto MySQL personalizado configurando el parámetro "puerto" en el archivo de configuración de MySQL para minimizar el riesgo de exposición.

Revisar la Política de Usuario

Limite ciertos usuarios para tener los derechos de administración críticos, especialmente GRANT, SUPER y PROCESS. También puede habilitar super_read_only si el servidor es un esclavo, solo disponible en MySQL 5.7.8 y Percona Server 5.6.21 y posteriores (lamentablemente no con MariaDB). Cuando está habilitado, el servidor no permitirá ninguna actualización, además de actualizar los repositorios de replicación si los registros de estado del esclavo son tablas, incluso para los usuarios que tienen privilegios SUPER. Elimine la base de datos de prueba predeterminada y cualquier usuario con contraseñas vacías para reducir el alcance de la penetración. Este es uno de los controles de seguridad realizados por ClusterControl, implementado como un asesor de base de datos.

También es una buena idea restringir la cantidad de conexiones permitidas a una sola cuenta. Puede hacerlo configurando la variable max_user_connections en mysqld (el valor predeterminado es 0, igual a ilimitado) o use las opciones de control de recursos en las instrucciones GRANT/CREATE USER/ALTER USER. La instrucción GRANT admite la limitación del número de conexiones simultáneas al servidor por cuenta, por ejemplo:

mysql> GRANT ALL PRIVILEGES ON db.* TO 'db_user'@'localhost' WITH MAX_USER_CONNECTIONS 2;

El nombre de usuario de administrador predeterminado en el servidor MySQL es "root". Los piratas informáticos a menudo intentan obtener acceso a sus permisos. Para hacer esta tarea mucho más difícil, cambie el nombre de "raíz" a otra cosa. Los nombres de usuario de MySQL pueden tener hasta 32 caracteres (16 caracteres antes de MySQL 5.7.8). Es posible usar un nombre de usuario más largo para el usuario superadministrador usando la instrucción RENAME como se muestra a continuación:

mysql> RENAME USER root TO new_super_administrator_username;

Una nota al margen para los usuarios de ClusterControl, ClusterControl necesita conocer el usuario raíz y la contraseña de MySQL para automatizar y administrar el servidor de la base de datos por usted. Por defecto, buscará 'root'. Si cambia el nombre del usuario raíz por otro, especifique “monitored_mysql_root_user={new_user}” dentro de cmon_X.cnf (donde X es el ID del clúster) y reinicie el servicio CMON para aplicar el cambio.

Política de copia de seguridad

A pesar de que los piratas informáticos afirmaron que recuperaría sus datos una vez que se pagara el rescate, este no suele ser el caso. Aumentar la frecuencia de las copias de seguridad aumentaría la posibilidad de restaurar los datos eliminados. Por ejemplo, en lugar de una copia de seguridad completa una vez a la semana con una copia de seguridad incremental diaria, puede programar una copia de seguridad completa una vez al día con una copia de seguridad incremental cada hora. Puede hacerlo fácilmente con la función de gestión de copias de seguridad de ClusterControl y restaurar sus datos si algo sale mal.

Si tiene registros binarios (binlogs) habilitados, eso es aún mejor. Puede crear una copia de seguridad completa todos los días y hacer una copia de seguridad de los registros binarios. Los binlogs son importantes para la recuperación de un momento dado y deben respaldarse regularmente como parte de su procedimiento de respaldo. Los DBA tienden a pasar por alto este método simple, que vale cada centavo. En caso de que lo pirateen, siempre puede recuperarse hasta el último punto antes de que sucediera, siempre que los piratas informáticos no hayan purgado los registros binarios. Tenga en cuenta que la depuración de registros binarios solo es posible cuando el atacante tiene privilegio SUPER.

Una cosa más importante es que los archivos de copia de seguridad deben ser restaurables. Verifique las copias de seguridad de vez en cuando y evite sorpresas desagradables cuando necesite restaurar.

Proteja su servidor web/de aplicaciones

Bueno, si ha aislado sus servidores MySQL, todavía hay posibilidades de que los atacantes accedan a ellos a través de la web o del servidor de aplicaciones. Al inyectar un script malicioso (por ejemplo, Cross-Site Scripting, SQL injection) contra el sitio web de destino, uno puede ingresar al directorio de la aplicación y tener la capacidad de leer los archivos de la aplicación. Estos pueden contener información confidencial, por ejemplo, las credenciales de inicio de sesión de la base de datos. Al mirar esto, un atacante puede simplemente iniciar sesión en la base de datos, eliminar todas las tablas y dejar una tabla de "rescate" dentro. No necesariamente tiene que ser un usuario raíz de MySQL para rescatar a una víctima.

Hay miles de formas de comprometer un servidor web y realmente no puede cerrar el puerto de entrada 80 o 443 para este propósito. Se requiere otra capa de protección para salvaguardar su servidor web de inyecciones basadas en HTTP. Puede usar Web Application Firewall (WAF) como Apache ModSecurity, NAXSI (WAF para nginx), WebKnight (WAF para IIS) o simplemente ejecutar sus servidores web en una red de entrega de contenido (CDN) segura como CloudFlare, Akamai o Amazon CloudFront.

Manténgase siempre actualizado

Probablemente haya oído hablar del exploit MySQL crítico de día cero, en el que un usuario sin privilegios puede convertirse en superusuario. Suena aterrador. Afortunadamente, todos los proveedores conocidos han actualizado su repositorio para incluir una corrección de errores para este problema.

Para uso en producción, se recomienda enfáticamente que instale los paquetes MySQL/MariaDB del repositorio del proveedor. No confíe en el repositorio del sistema operativo predeterminado, donde los paquetes suelen estar desactualizados. Si está ejecutando en un entorno de clúster como Galera Cluster, o incluso MySQL Replication, siempre tiene la opción de parchear el sistema con un tiempo de inactividad mínimo. Convierta esto en una rutina e intente automatizar el procedimiento de actualización tanto como sea posible.

ClusterControl admite la actualización continua de versiones secundarias (un nodo a la vez) para MySQL/MariaDB con un solo clic. La actualización de versiones principales (por ejemplo, de MySQL 5.6 a MySQL 5.7) comúnmente requiere la desinstalación de los paquetes existentes y es una tarea riesgosa de automatizar. Es necesaria una planificación y pruebas cuidadosas para este tipo de actualización.

Conclusión

El ransomware es una olla de oro fácil de hacer dinero. Probablemente veremos más brechas de seguridad en el futuro, y es mejor tomar medidas antes de que suceda algo. Los piratas informáticos tienen como objetivo muchos servidores vulnerables y es muy probable que este ataque también se propague a otras tecnologías de bases de datos. Proteger sus datos es un desafío constante para los administradores de bases de datos. El verdadero enemigo no es el infractor, sino nuestra actitud hacia la protección de nuestros activos críticos.