sql >> Base de Datos >  >> RDS >> MariaDB

Cómo proteger su base de datos MySQL y MariaDB contra ataques cibernéticos cuando está en una red pública

A veces es inevitable ejecutar servidores de bases de datos MySQL en una red pública o expuesta. Esta es una configuración común en un entorno de alojamiento compartido, donde un servidor está configurado con múltiples servicios y, a menudo, se ejecuta dentro del mismo servidor que el servidor de la base de datos. Para aquellos que tienen este tipo de configuración, siempre deben tener algún tipo de protección contra ataques cibernéticos como denegación de servicio, piratería, craqueo, violaciones de datos; todo lo cual puede resultar en la pérdida de datos. Estas son cosas que siempre queremos evitar para nuestro servidor de base de datos.

Estos son algunos de los consejos que podemos hacer para mejorar nuestra seguridad MySQL o MariaDB.

Escanee sus servidores de bases de datos con regularidad

La protección contra cualquier archivo malicioso en el servidor es muy importante. Escanee el servidor regularmente para buscar virus, spyware, malware o rootkits, especialmente si el servidor de la base de datos está ubicado junto con otros servicios como el servidor de correo, HTTP, FTP, DNS, WebDAV, telnet, etc. Por lo general, la mayoría de los problemas de piratería de la base de datos se originaron en el nivel de la aplicación que enfrenta la red pública. Por lo tanto, es importante escanear todos los archivos, especialmente los archivos web/de aplicaciones, ya que son uno de los puntos de entrada para ingresar al servidor. Si se ven comprometidos, el pirata informático 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.

ClamAV es una de las soluciones antivirus más conocidas y confiables para una variedad de sistemas operativos, incluido Linux. Es gratis y muy fácil de instalar y viene con un mecanismo de detección bastante bueno para buscar cosas no deseadas en su servidor. Programe exploraciones periódicas en el trabajo cron, por ejemplo:

0 3 * * * /bin/freshclam ; /bin/clamscan / --recursive=yes -i > /tmp/clamav.log ; mail -s clamav_log_`hostname` [email protected] < /tmp/clamav.log

Lo anterior actualizará la base de datos de virus de ClamAV, escaneará todos los directorios y archivos y le enviará un correo electrónico sobre el estado de la ejecución e informará todos los días a las 3 a. m.

Usar roles y privilegios de usuario más estrictos

Al crear un usuario MySQL, no permita que todos los hosts accedan al servidor MySQL con el host comodín (%). Debe escanear su host MySQL y buscar cualquier valor de host comodín, como se muestra en la siguiente declaración:

mysql> SELECT user,host FROM mysql.user WHERE host = '%';
+---------+------+
| user    | host |
+---------+------+
| myadmin | %    |
| sbtest  | %    |
| user1   | %    |
+---------+------+

De la salida anterior, restrinja o elimine todos los usuarios que solo tengan el valor '%' en la columna Host. Se puede obligar a los usuarios que necesitan acceder al servidor MySQL de forma remota a utilizar el método de tunelización SSH, que no requiere una configuración de host remoto para los usuarios de MySQL. La mayoría de los clientes de administración de MySQL, como MySQL Workbench y HeidiSQL, se pueden configurar para conectarse a un servidor MySQL a través de SSH, por lo que es posible eliminar por completo la conexión remota para los usuarios de MySQL.

Además, limite el privilegio SUPER solo a usuarios de localhost o que se conecten a través de un archivo de socket UNIX. Tenga más cuidado al asignar privilegios de ARCHIVO a usuarios que no sean root, ya que permite leer y escribir archivos en el servidor utilizando las declaraciones LOAD DATA INFILE y SELECT ... INTO OUTFILE. Cualquier usuario al que se le otorgue este privilegio también puede leer o escribir cualquier archivo que el servidor MySQL pueda leer o escribir.

Cambiar la configuración predeterminada de la base de datos

Al alejarnos de la configuración, los nombres y las configuraciones predeterminados, podemos reducir el vector de ataque a varios pliegues. Las siguientes acciones son algunos ejemplos de configuraciones predeterminadas que los DBA podrían cambiar fácilmente pero que comúnmente se pasan por alto en relación con MySQL:

  • Cambiar el puerto predeterminado de MySQL a otro que no sea 3306.
  • Cambie el nombre del nombre de usuario root de MySQL a otro que no sea "root".
  • Haga cumplir la caducidad de la contraseña y reduzca la vigencia de la contraseña para todos los usuarios.
  • Si MySQL comparte ubicación con los servidores de aplicaciones, imponga la conexión solo a través del archivo de socket UNIX y deje de escuchar en el puerto 3306 para todas las direcciones IP.
  • Haga cumplir el cifrado cliente-servidor y el cifrado de replicación servidor-servidor.

De hecho, hemos cubierto esto en detalle en esta publicación de blog, Cómo asegurar servidores MySQL/MariaDB.

Configurar un esclavo retrasado

Un esclavo retrasado es solo un esclavo típico, sin embargo, el servidor esclavo ejecuta transacciones intencionalmente más tarde que el maestro por al menos una cantidad de tiempo específica, disponible en MySQL 5.6. Básicamente, un evento recibido del maestro no se ejecuta hasta al menos N segundos después de su ejecución en el maestro. El resultado es que el esclavo reflejará el estado del maestro en algún momento del pasado.

Se puede usar un esclavo retrasado para recuperar datos, lo que sería útil cuando el problema se encuentra de inmediato, dentro del período de retraso. Supongamos que configuramos un esclavo con un retraso de 6 horas desde el maestro. Si nuestra base de datos fue modificada o eliminada (accidentalmente por un desarrollador o deliberadamente por un pirata informático) dentro de este rango de tiempo, existe la posibilidad de que volvamos al momento justo antes de que sucediera deteniendo el maestro actual y luego activando el servidor esclavo. hasta cierto punto con el siguiente comando:

# on delayed slave
mysql> STOP SLAVE;
mysql> START SLAVE UNTIL MASTER_LOG_FILE='xxxxx', MASTER_LOG_POS=yyyyyy;

Donde 'xxxxx' es el archivo de registro binario y 'yyyyy' es la posición justo antes de que ocurra el desastre (utilice la herramienta mysqlbinlog para examinar esos eventos). Finalmente, promueva el esclavo para que se convierta en el nuevo maestro y su servicio MySQL ahora vuelve a estar operativo como de costumbre. Este método es probablemente la forma más rápida de recuperar su base de datos MySQL en un entorno de producción sin tener que volver a cargar una copia de seguridad. Tener una cantidad de esclavos retrasados ​​con diferentes duraciones, como se muestra en este blog, Múltiples esclavos de replicación retrasada para recuperación ante desastres con RTO bajo sobre cómo configurar servidores de replicación retrasada rentables sobre contenedores Docker.

Habilitar registro binario

Por lo general, se recomienda habilitar el registro binario aunque se esté ejecutando en un servidor MySQL/MariaDB independiente. El registro binario contiene información sobre sentencias SQL que modifican el contenido de la base de datos. La información se almacena en forma de "eventos" que describen las modificaciones. A pesar del impacto en el rendimiento, tener un registro binario le permite tener la posibilidad de reproducir su servidor de base de datos en el punto exacto en el que desea que se restaure, también conocido como recuperación puntual (PITR). El registro binario también es obligatorio para la replicación.

Con el registro binario habilitado, se debe incluir el archivo de registro binario y la información de posición al realizar una copia de seguridad completa. Para mysqldump, usar el indicador --master-data con el valor 1 o 2 imprimirá la información necesaria que podemos usar como punto de partida para hacer avanzar la base de datos al reproducir los registros binarios más adelante.

Con el registro binario habilitado, puede usar otra función de recuperación genial llamada flashback, que se describe en la siguiente sección.

Habilitar retroceso

La función de flashback está disponible en MariaDB, donde puede restaurar los datos a la instantánea anterior en una base de datos MySQL o en una tabla. Flashback usa mysqlbinlog para crear declaraciones de reversión y necesita una imagen de fila de registro binario COMPLETA para eso. Por lo tanto, para usar esta función, el servidor MySQL/MariaDB debe configurarse con lo siguiente:

[mysqld]
...
binlog_format = ROW
binlog_row_image = FULL

El siguiente diagrama de arquitectura ilustra cómo se configura flashback en uno de los esclavos:

Para realizar la operación de flashback, primero debe determinar la fecha y la hora cuando desee "ver" los datos, o el archivo de registro binario y la posición. Luego, use el indicador --flashback con la utilidad mysqlbinlog para generar declaraciones SQL para revertir los datos a ese punto. En el archivo SQL generado, notará que los eventos DELETE se convierten en INSERT y viceversa, y también intercambia partes WHERE y SET de los eventos UPDATE.

La siguiente línea de comando debe ejecutarse en el esclavo2 (configurado con binlog_row_image=FULL):

$ mysqlbinlog --flashback --start-datetime="2020-02-17 01:30:00"  /var/lib/mysql/mysql-bin.000028 -v --database=shop --table=products > flashback_to_2020-02-17_013000.sql

Luego, separe el esclavo2 de la cadena de replicación porque la vamos a romper y usar el servidor para revertir nuestros datos:

mysql> STOP SLAVE;
mysql> RESET MASTER;
mysql> RESET SLAVE ALL;

Finalmente, importe el archivo SQL generado en el servidor MariaDB para la base de datos de la tienda en Slave2:

$ mysql -u root -p shop < flashback_to_2020-02-17_013000.sql

Cuando se aplica lo anterior, la tabla "productos" estará en el estado de 2020-02-17 01:30:00. Técnicamente, el archivo SQL generado se puede aplicar a los servidores MariaDB y MySQL. También puede transferir el binario mysqlbinlog desde el servidor MariaDB para poder usar la función de flashback en un servidor MySQL. Sin embargo, la implementación de MySQL GTID es diferente a la de MariaDB, por lo que la restauración del archivo SQL requiere que desactive MySQL GTID.

Un par de ventajas al usar flashback es que no necesita detener el servidor MySQL/MariaDB para llevar a cabo esta operación. Cuando la cantidad de datos para revertir es pequeña, el proceso de flashback es mucho más rápido que recuperar los datos de una copia de seguridad completa.

Registrar todas las consultas de la base de datos

El registro general básicamente captura cada instrucción SQL que ejecuta el cliente en el servidor MySQL. Sin embargo, esta podría no ser una decisión popular en un servidor de producción ocupado debido al impacto en el rendimiento y al consumo de espacio. Si el rendimiento es importante, el registro binario tiene la mayor prioridad para habilitarse. El registro general se puede habilitar durante el tiempo de ejecución ejecutando los siguientes comandos:

mysql> SET global general_log_file='/tmp/mysql.log'; 
mysql> SET global log_output = 'file';
mysql> SET global general_log = ON;

También puede establecer la salida de registro general en una tabla:

mysql> SET global log_output = 'table';

Luego puede usar la instrucción SELECT estándar contra la tabla mysql.general_log para recuperar consultas. Espere un poco más de impacto en el rendimiento cuando se ejecuta con esta configuración, como se muestra en esta publicación de blog.

De lo contrario, puede usar herramientas de monitoreo externas que pueden realizar muestreo y monitoreo de consultas para que pueda filtrar y auditar las consultas que ingresan al servidor. ClusterControl se puede utilizar para recopilar y resumir todas sus consultas, como se muestra en las siguientes capturas de pantalla donde filtramos todas las consultas que contienen la cadena DELETE:

Información similar también está disponible en la página de consultas principales de ProxySQL (si su aplicación es conectándose a través de ProxySQL):

Esto se puede utilizar para realizar un seguimiento de los cambios recientes que se han producido en el servidor de la base de datos y también se puede utilizar con fines de auditoría.

Conclusión

Sus servidores MySQL y MariaDB deben estar bien protegidos en todo momento, ya que generalmente contienen datos confidenciales que los atacantes están buscando. También puede usar ClusterControl para administrar los aspectos de seguridad de sus servidores de bases de datos, como se muestra en esta publicación de blog, Cómo proteger sus bases de datos de código abierto con ClusterControl.