Fortalecimiento de MySQL para su sitio de WordPress

Publicado: 2023-01-18

WordPress, el CMS más popular, se ejecuta en MySQL, la base de datos más popular que existe. Dedicar algo de tiempo a asegurarse de que la instalación de MySQL y la instalación de la configuración de la base de datos de WordPress estén adecuadamente reforzadas contra los vectores de ataque comunes puede ayudarlo a reducir los riesgos. Esto es especialmente cierto si usted mismo administra su servidor MySQL.

Vale la pena señalar que muchas instalaciones de WordPress usan MariaDB, que es una bifurcación de MySQL. Como ambos funcionan de manera muy similar, usaremos MySQL para referirnos tanto a MySQL como a MariaDB. Independientemente del tipo de RDMS que esté ejecutando, fortalecer su MySQL puede ayudarlo a minimizar los riesgos de ataques de piratas informáticos. Sin embargo, esto no reemplaza otras medidas de seguridad, como instalar un firewall de aplicaciones web, asegurarse de tener la última versión de complementos, temas y WordPress, y fortalecer WordPress.

Atención , este artículo está dirigido a MySQL 8.0 que se ejecuta en Linux (Ubuntu). Si bien los conceptos se traducirán a otros sistemas operativos y versiones de MySQL/MariaDB, los comandos y las rutas de archivo utilizados en estos ejemplos pueden diferir. Antes de realizar cualquier cambio en un sistema de producción, se recomienda encarecidamente probar cualquier cambio en un entorno de prueba o preproducción.

En este artículo, que está dirigido principalmente a aquellos que administran su propio MYSQL, ofrecemos varios consejos y tutoriales sobre cómo asegurar MySQL. Aun así, vale la pena leer la extensa lista de mejores prácticas presentadas en este artículo para cualquiera que administre sitios web de WordPress. Asegurar su servidor MySQL es un paso crítico para mantener un WordPress seguro y protegerse de diferentes tipos de ataques de fuerza bruta, inyección de malware y otros tipos de ataques.

Tabla de contenido

  • Considere usar una base de datos como servicio (DBaaS
  • Mantenga MySQL actualizado
  • Ejecute MySQL en una máquina dedicada
  • Vincular MySQL a una dirección IP
  • Limite el uso de herramientas GUI basadas en la web
  • Ejecute el demonio MySQL usando un usuario dedicado
  • Use el script mysql_secure_installation
  • Crear un usuario de base de datos de WordPress dedicado
  • Asegúrese de que local_infile esté deshabilitado
  • Deshabilitar el historial de comandos de MySQL
  • Asegúrese de que mysqld no se inicie con el argumento –skip-grant-tables
  • Haz una copia de seguridad de tu base de datos
    • Realice copias de seguridad frecuentes
    • Verifique la integridad de sus copias de seguridad con frecuencia
    • Almacene sus copias de seguridad de forma segura
  • Habilitar y hacer cumplir las conexiones TLS
    • Cambiar el prefijo de la tabla
    • Cómo implementar cambios
    • Mantener tu WordPress seguro

Considere usar una base de datos como servicio (DBaaS)

Vale la pena considerar la base de datos como servicio si no está alojando WordPress en un plan administrado. Reemplaza el modelo tradicional de instalar MySQL localmente con un servicio al que te conectas. Esto podría adaptarse a su caso de uso si está ejecutando su sitio de WordPress con un proveedor de alojamiento que ofrece servicios de base de datos administrados. Las opciones disponibles generalmente incluyen Amazon RDS, MySQL administrado por DigitalOcean y MySQL administrado por Linode). A primera vista, estos servicios pueden ser más costosos que ejecutar MySQL usted mismo. Sin embargo, hacen todo el trabajo pesado de ejecutar bases de datos de nivel de producción. La mayoría de los servicios incluyen ajustes preestablecidos de mejores prácticas de seguridad, mantenimiento y parches de seguridad continuos, y copias de seguridad.

Usar una Base de Datos como Servicio (DBaaS) es una de las mejores opciones en términos de seguridad y confiabilidad. Si bien esto no es obligatorio, sigue siendo bueno tenerlo. Sin embargo, si está buscando administrar MySQL usted mismo, la siguiente es una colección de consejos de fortalecimiento para tener en cuenta.

Mantenga MySQL actualizado

Así como es importante asegurarse de que está ejecutando la última versión de WordPress, es importante mantener MySQL actualizado. Como la mayoría del software, las actualizaciones del servidor MySQL se publican periódicamente. Estas actualizaciones corrigen errores, mitigan vulnerabilidades y brindan nuevas funciones. Debe mantener MySQL actualizado con los últimos parches de seguridad para reducir los riesgos de ejecutar software con vulnerabilidades conocidas. Tenga en cuenta que una vez actualizado, deberá reiniciar el 'daemon mysql'. Este es un proceso que puede generar algún tiempo de inactividad. Como siempre, planifique con anticipación.

Ejecute MySQL en una máquina dedicada

Muchas instalaciones de WordPress ejecutan MySQL, PHP y un servidor web (como Nginx o Apache HTTP Server) en la misma máquina. Esto no es óptimo, tanto en términos de rendimiento como de seguridad. Idealmente, MySQL debería ejecutarse en un servidor dedicado para reducir el radio de explosión de un ataque. Si un atacante logra comprometer y aumentar los privilegios en el servidor web, sería mucho más difícil para ese atacante moverse lateralmente y también comprometer el servidor MySQL.

Vincular MySQL a una dirección IP

Puede configurar MySQL para que solo acepte conexiones TCP/IP desde una interfaz IPv4 o IPv6 específica. Todo lo que necesita hacer es establecer la opción de configuración de dirección de enlace en una dirección IP específica. Esto proporciona controles y restricciones adicionales sobre cómo las aplicaciones cliente (en nuestro caso, WordPress) pueden conectarse a MySQL. De forma predeterminada, esta configuración se establece en *, lo que significa que MySQL listo para usar escuchará en todas las interfaces.

Si no está configurado para escuchar una IP específica, todas las IP se pueden usar para conectarse a MySQL. Esta configuración es especialmente importante si está ejecutando MySQL en la misma máquina que un servidor web que está exponiendo a Internet (en este caso, debe configurar la dirección de enlace en 127.0.0.1 para que MySQL solo escuche en localhost) .

Por ejemplo, si desea que el servidor MySQL solo acepte conexiones en una dirección IPv4 específica, puede agregar una entrada similar al ejemplo a continuación. Debe ingresar esto en el grupo de opciones [mysqld] en el archivo de configuración /etc/mysql/mysql.conf.d/mysqld.cnf de su servidor.

dirección de enlace = 192.168.0.24

Tenga en cuenta que una vez que configure esto, deberá volver a configurar WordPress para conectarse a la base de datos utilizando esta dirección IP (a menos que ya lo esté haciendo), ya que no se permitirán las conexiones en otras direcciones de host del servidor.

Limite el uso de herramientas GUI basadas en la web

Muchas instalaciones de WordPress incluyen herramientas de gestión gráfica front-end basadas en la web. Los ejemplos comunes incluyen Cpanel, phpMyAdmin o Adminer. Estas herramientas facilitan la gestión de MySQL y otros aspectos de la infraestructura subyacente. Si bien una interfaz gráfica basada en web puede ayudarlo a administrar sus bases de datos MySQL, estas interfaces pueden aumentar la superficie de ataque al agregar otro vector. Además, existe el riesgo de que los atacantes los descubran y abusen de ellos para ejecutar consultas SQL destructivas o maliciosas en su base de datos. Los ataques pueden incluso resultar en una toma de control total de su sitio web de WordPress.

El único servidor seguro es el que está apagado y desenchufado; sin embargo, el riesgo se puede gestionar. Desinstalar sistemas no críticos es una opción; sin embargo, estos también se pueden bloquear y restringir para minimizar el riesgo.

Es posible restringir el acceso a estas herramientas de varias formas. Puede instalar phpMyAdmin para WordPress de forma remota, minimizando así el riesgo para el servidor web. Alternativamente, también puede considerar usar herramientas como MySQL Workbench o Beekeeper Studio en su máquina local y conectarse a su servidor de base de datos a través de un túnel SSH.

Ejecute el demonio MySQL usando un usuario dedicado

Al igual que con otros servicios que se ejecutan en un servidor, puede ejecutar el demonio MySQL con un usuario dedicado. Cuando ejecuta MySQL con un usuario dedicado, puede definir con precisión qué permisos se otorgan a ese usuario dentro del sistema. La ejecución de MySQL con un usuario dedicado también sigue el principio de privilegio mínimo, ya que esto reduce el radio de explosión de una vulnerabilidad de MySQL. También disminuye la posibilidad de que se aproveche una configuración incorrecta, ya que un usuario restringido no podrá acceder a recursos no relacionados con MySQL (como configuraciones y secretos del sistema operativo).

La buena noticia es que las instalaciones a través de administradores de paquetes (como apt o yum) se encargan de este paso automáticamente al instalar MySQL. Una forma rápida de verificar si MySQL se está ejecutando con un usuario dedicado es ejecutar lo siguiente en la máquina que ejecuta el demonio MySQL.

ps-ef | egrep “^mysql.*$”

Si MySQL se ejecuta con un usuario dedicado, debe esperar ver al menos una línea de salida de ps.

Use el script mysql_secure_installation

El paquete mysql-server viene con una utilidad de script de shell llamada mysql_secure_installation. Puede usar este script para configurar un punto de partida seguro para el servidor MySQL. Como tal, debe ejecutarlo después de una nueva instalación de MySQL. Esta utilidad te ayuda a:

  • Establecer una contraseña para las cuentas raíz
  • Eliminar cuentas raíz a las que se puede acceder desde fuera de localhost
  • Eliminar cuentas de usuario anónimo
  • Eliminar la base de datos de prueba (a la que, de forma predeterminada, pueden acceder usuarios anónimos)

Para invocar mysql_secure_installation, ejecute el siguiente comando:

sudo mysql_secure_installation

Una vez que comience el proceso de configuración, se le presentarán varias indicaciones que le preguntarán si desea habilitar el complemento de validación de contraseña , que se utiliza para probar la seguridad de las contraseñas que elige para los usuarios de MySQL. Se recomienda que habilite este complemento.

Después de habilitar el complemento de validación de contraseña, el script le pedirá que especifique una política de validación de contraseña. Aquí, debe elegir una política de contraseña segura. Posteriormente, se le pedirá que restablezca la contraseña del usuario raíz.

A continuación, el script le pedirá que elimine a los usuarios anónimos de MySQL. Esto es importante para reducir cualquier posibilidad de que los atacantes obtengan acceso al servidor de la base de datos aprovechando un usuario anónimo de MySQL.

El siguiente mensaje le preguntará si desea deshabilitar los inicios de sesión con el usuario raíz al autenticarse de forma remota en el servidor MySQL. La autenticación remota con el usuario raíz es peligrosa y rara vez se requiere. En su lugar, debe usar SSH en MySQL y usar el cliente MySQL en el servidor para autenticarse como usuario raíz o, preferiblemente, usar un túnel SSH para reenviar el puerto MySQL remoto a su máquina local y conectarse usando un cliente local.

A continuación, se le pedirá que elimine las bases de datos predeterminadas (si existen) con las que se envía MySQL. Esta es la práctica recomendada para servidores MySQL de producción.

Eliminar base de datos predeterminada

Finalmente, se le preguntará si desea volver a cargar las tablas de privilegios para que todos los cambios que se hayan aplicado surtan efecto.

Crear un usuario de base de datos de WordPress dedicado

Las mejores prácticas de seguridad dictan la segregación de usuarios y privilegios por funciones o funciones. Esto significa que cada aplicación que haga uso de la base de datos debe tener su propio usuario dedicado con la cantidad mínima de permisos de base de datos MySQL necesarios para realizar su trabajo. Como tal, se asegurará de que los privilegios de usuario no excedan lo requerido.

Esta práctica debe extenderse a las implementaciones que ejecutan múltiples sitios web de WordPress: cada sitio web de WordPress debe tener su propia base de datos dedicada y usuario de MySQL. Esto garantiza que, en cualquier momento, solo un usuario tenga acceso a una base de datos a la vez y que los usuarios no puedan acceder a otras bases de datos, lo que evita el acceso no autorizado y las filtraciones de datos.

La siguiente instrucción SQL (sustituya <host> y <contraseña> y <base de datos> para satisfacer sus necesidades) puede usarse para crear un usuario dedicado para su sitio web de WordPress y otorgar privilegios para uso regular. Tenga en cuenta que algunos complementos, temas y actualizaciones de WordPress pueden necesitar ocasionalmente privilegios adicionales para funcionar correctamente (consulte la guía oficial de WordPress sobre esto para obtener más información)

Asegúrese de que local_infile esté deshabilitado

La instrucción LOAD DATA le permite cargar archivos de datos en las tablas de la base de datos. En condiciones específicas, se puede abusar de esto para leer archivos del servidor MySQL. Como tal, a menos que tenga un caso de uso específico para esto en su sitio de WordPress, debe deshabilitar esta función.

Si MySQL y el servidor web se ejecutan en la misma máquina, puede permitir que un atacante use la declaración LOAD DATA LOCAL para leer archivos arbitrarios a los que el proceso del servidor web tiene acceso de lectura. Esto supone que un atacante tiene la capacidad de ejecutar sentencias SQL arbitrarias contra MySQL. Tal puede ser el caso de una vulnerabilidad de inyección SQL o mediante la instalación de un complemento malicioso de WordPress. Esta es otra razón más para mantener su servidor web y los servidores de bases de datos separados.

De manera predeterminada, local_infile está deshabilitado en MySQL 8.0 (solía estar habilitado de manera predeterminada en versiones anteriores de MySQL). Para evitar que el servidor MySQL acepte declaraciones LOAD DATA LOCAL, asegúrese de que el demonio mysqld se inicie con local_infile deshabilitado.

Deshabilitar el historial de comandos de MySQL

En Linux, las declaraciones de registros del cliente MySQL ejecutadas de forma interactiva se guardan en un archivo de historial (normalmente ubicado en $HOME/.mysql_history). Idealmente, el historial de comandos de MySQL debería estar deshabilitado, ya que esto reduce la probabilidad de exponer información confidencial, como contraseñas, claves de cifrado u otros secretos.

Para verificar que los archivos .mysql_history no existen en el sistema, ejecute los siguientes comandos:

encontrar /home -nombre “.mysql_history”
encontrar /root -nombre “.mysql_history”

Si los comandos anteriores devuelven algún resultado, elimine los archivos .mysql_history. Además, puede configurar $HOME/.mysql_history como un enlace simbólico a /dev/null de la siguiente manera:

ln -s /dev/null $HOME/.mysql_history

Asegúrese de que mysqld no se inicie con el argumento –skip-grant-tables

Si la contraseña raíz de MySQL se extravía, aunque no sea el método preferido, algunos administradores de MySQL pueden recurrir a configurar MySQL para que comience con el argumento –skip-grant-tables. Al iniciar MySQL con este parámetro, evitará verificar sus tablas de concesión cuando un cliente se conecta o ejecuta una consulta, lo que permite que cualquier persona, en cualquier lugar (siempre que pueda acceder a la base de datos a través de la red), pueda hacer cualquier cosa en el servidor de la base de datos.

Para asegurarse de que –skip-grant-tables no esté habilitado, abra el archivo de configuración /etc/mysql/mysql.conf.d/mysqld.cnf de su servidor y busque skip-grant-tables. El valor no debe establecerse o establecerse en skip-grant-tables = FALSE.

Haz una copia de seguridad de tu base de datos

Hacer una copia de seguridad de su base de datos de WordPress es absolutamente crucial para poder recuperarse rápidamente de un desastre o un ataque. Si bien hay una gran variedad de formas de hacer una copia de seguridad de su base de datos de WordPress, desde los complementos y servicios de copia de seguridad de WordPress hasta los scripts creados en casa que realizan un volcado de la base de datos periódicamente, los siguientes son algunos consejos destacados a tener en cuenta.

Realice copias de seguridad frecuentes

Realizar copias de seguridad periódicas es bastante obvio y se explica por sí mismo: cuanto más frecuentemente realice copias de seguridad de la base de datos, más fácil será recuperarse de un incidente de pérdida de datos. Si bien la frecuencia de las copias de seguridad dependerá del tipo de sitio de WordPress que esté ejecutando, como regla general, realizar una copia de seguridad diariamente sirve bien en la mayoría de los casos de uso.

Verifique la integridad de sus copias de seguridad con frecuencia

Sus copias de seguridad solo son útiles si funcionan. y probablemente prefiera no enterarse mientras está en medio de un incidente tratando de recuperar datos. La solución simple a esto es verificar con frecuencia que sus copias de seguridad realmente funcionen haciendo restauraciones de prueba de vez en cuando. Una buena manera de hacer esto es establecer un evento de calendario cada pocos meses para pasar por un procedimiento de restauración para asegurarse de que sus copias de seguridad sigan funcionando como se esperaba. Además, documentar los pasos de restauración de la base de datos también es una buena idea: cuanto menos conjeturas al responder a un incidente, mejor.

Almacene sus copias de seguridad de forma segura

Nunca guarde copias de seguridad de su sitio de WordPress en su servidor web o de base de datos (especialmente en su servidor web). Las copias de seguridad son un excelente lugar para que los atacantes se zambullan en la basura. Es muy recomendable almacenar sus copias de seguridad en una ubicación segura fuera del sitio. Si está realizando volcados de base de datos periódicos, considere almacenar sus volcados de base de datos en un servicio de almacenamiento de objetos. Estos pueden incluir Amazon S3, Cloudflare R2, DigitalOcean Spaces, Linode Object Storage, etc. Tomar esta ruta puede ser una forma excelente y rentable de almacenar las copias de seguridad de su base de datos. Sin embargo, tenga mucho cuidado de no hacer que el depósito de almacenamiento que está utilizando sea de acceso público.

Habilitar y hacer cumplir las conexiones TLS

A menos que esté ejecutando MySQL en la misma máquina que su servidor web (que, como ya mencionamos anteriormente, no es una práctica de seguridad ideal), se recomienda cifrar los datos entre WordPress y MySQL utilizando Transport Layer Security (certificado TLS), anteriormente conocido como Secure Socket Layer (certificado SSL).

De manera predeterminada, cuando instala MySQL, generará automáticamente un certificado autofirmado. Puede verificar esto ejecutando lo siguiente (alternativamente, puede usar el script mysql_ssl_rsa_setup para generar nuevos certificados).

Deberá copiar ca.pem de la lista anterior (por ejemplo, a través de SCP) al servidor que ejecuta su sitio web de WordPress. Una vez que cargue el archivo ca.pem en su servidor de WordPress, deberá mover el certificado al almacén de confianza de certificados del sistema operativo y actualizar el almacén de confianza de certificados de la siguiente manera.

Atención, el nombre de archivo del certificado de CA debe terminar con una extensión de archivo .crt (por ejemplo, mysql-ca.crt es válido, pero mysql-ca.pem.crt o mysql-ca.pem no son válidos).

sudo mv ca.pem /usr/local/share/ca-certificates/mysql-ca.crt
sudo actualizar-ca-certificados

A continuación, debe configurar WordPress para usar TLS cuando se conecte a MySQL agregando lo siguiente a su archivo wp-config.php de su instalación de WordPress.

define('MYSQL_CLIENT_FLAGS', MYSQLI_CLIENT_SSL);

Una vez que actualice wp-config.php, WordPress iniciará las conexiones a su servidor MySQL usando TLS.

A continuación, se recomienda que haga cumplir las conexiones TLS a su servidor MySQL usando la variable de sistema require_secure_transport agregando lo siguiente a su archivo /etc/mysql/mysql.conf.d/mysqld.cnf.

require_secure_transport = ACTIVADO

Finalmente, reinicie MySQL para que los cambios surtan efecto.

systemctl reiniciar mysql

Cambiar el prefijo de la tabla

De forma predeterminada, todas las tablas de WordPress se crean con el prefijo 'wp_'. Esto puede facilitar que los atacantes tengan éxito en ciertos ataques, como la inyección de SQL, ya que conocerían los nombres de las tablas de la base de datos. Si bien esto por sí solo no lo protegerá, es un ejercicio sencillo, recomendado por muchos como la mejor práctica de seguridad de WordPress.

Puede cambiar el prefijo de la base de datos durante el proceso de instalación o en cualquier momento posterior, aunque este último es un poco más complejo. De cualquier manera, puede encontrar tutoriales en línea sobre cómo cambiar el prefijo de la base de datos de WordPress.

Cómo implementar cambios

Con suerte, este artículo le ha brindado una descripción general del fortalecimiento de la seguridad de MySQL en el contexto de ejecutar un sitio web de WordPress. Si bien no hay balas de plata en la seguridad del sitio web, con un poco de esfuerzo, adoptar un enfoque de seguridad en capas y de defensa en profundidad hará que atacar su sitio web sea significativamente más difícil para los atacantes.
Si bien esta guía presenta una serie de técnicas de fortalecimiento para MySQL, MySQL es solo un componente del ecosistema de WordPress. Como tal, también debe considerar otros aspectos de la seguridad de WordPress cubiertos en nuestra guía de fortalecimiento de la seguridad de WordPress. Esto, junto con medidas de seguridad comprobadas, como la autenticación de dos factores de WordPress, lo ayudará a garantizar que esté lo más seguro posible.

Si parece mucho para asimilar, recuerde que puede (y probablemente debería) aplicar gradualmente las diversas técnicas de endurecimiento cubiertas en esta guía.

Mantener tu WordPress seguro

Tenga en cuenta que los atacantes a menudo buscan objetivos fáciles, ya que no necesitan esforzarse tanto para explotar sitios web poco seguros. Estar un paso por delante de la postura de seguridad del próximo sitio web de WordPress lo convierte en un objetivo menos atractivo.