Cómo proteger una base de datos de WordPress: endurecimiento, cifrado y protección continua

Cada sitio de WordPress se ejecuta en una base de datos. Contiene tus publicaciones, tus usuarios, sus contraseñas, la configuración de tus plugins y los pedidos de tus clientes.

Los archivos en el servidor contienen tu tema y tus imágenes. La base de datos contiene todo lo demás.

Por eso es lo primero que ataca un atacante serio.

La inyección SQL sigue siendo un vector de ataque común en WordPress. Los atacantes envían entradas manipuladas a través de formularios de inicio de sesión, cuadros de búsqueda o campos de plugins vulnerables que engañan a la base de datos para que ejecute comandos que no debería.

Una inyección exitosa puede crear nuevas cuentas de administrador, redirigir a tus visitantes a sitios de spam, inyectar código malicioso en tu contenido o borrar la base de datos por completo.

La mayoría de estos ataques no hacen ningún ruido. El código inyectado y las cuentas de administrador no autorizadas pueden permanecer ocultos en una base de datos durante semanas antes de que algo visible salga mal.

He trabajado con sitios que tenían todos los plugins actualizados, autenticación de dos factores habilitada y contraseñas seguras en todos los ámbitos. Aun así, fueron atacados a través de una conexión a la base de datos que nadie había asegurado.

De eso trata este tutorial.

Trabajarás en 13 pasos para asegurar tu base de datos: los primeros ocho refuerzan la base de datos en sí y cierran las rutas de ataque más comunes, y los últimos cinco configuran la capa de copia de seguridad, monitoreo y recuperación que te protege cuando el refuerzo por sí solo no es suficiente.

Al final, tendrás una protección de base de datos proactiva y continua en funcionamiento.

Aquí están los puntos clave:

• Los 13 pasos cubren dos capas: refuerzo de la base de datos (Pasos 1-8) y configuración de copia de seguridad, monitoreo y recuperación (Pasos 9-13). Necesitas ambas, porque el refuerzo por sí solo no te protege después de que una brecha logra pasar.
• Algunas brechas en la base de datos no muestran síntomas visibles durante días o semanas, por lo que el monitoreo a través del plugin Activity Log es tan importante como el refuerzo de seguridad.
• Un archivo de copia de seguridad sin cifrar en el almacenamiento en la nube es una segunda copia de tu base de datos completa. Cualquiera que obtenga acceso a esa cuenta de almacenamiento puede leerla sin tocar tu sitio en vivo; el cifrado en el Paso 9 cierra esa brecha.
• Realiza una copia de seguridad completa del sitio antes de comenzar el Paso 1. Varios pasos realizan cambios directos en la base de datos que son difíciles de deshacer sin una.
• Guarda tu URL de recuperación de desastres de Duplicator en algún lugar fuera de WordPress durante el Paso 11. Es la única herramienta que te permite volver a entrar cuando tu panel de control está completamente bloqueado, pero solo si la guardaste antes de que las cosas salieran mal.
• La sección de solución de problemas cubre seis escenarios de fallo, incluyendo una ruta de recuperación completa para cuando tu sitio no responde y tu panel de control de WordPress no carga.

Tabla de Contenidos

¿Qué es una base de datos de WordPress?

WordPress almacena todo el contenido dinámico de tu sitio en una base de datos. Cuando alguien visita tu sitio, WordPress consulta la base de datos, extrae el contenido relevante y ensambla la página sobre la marcha. Si cambias una configuración, publicas una entrada o añades un usuario, se guarda en la base de datos.

Una instalación nueva de WordPress crea 12 tablas principales. Esto es lo que contienen las más importantes:

• wp_posts: cada entrada, página, revisión y tipo de entrada personalizada de tu sitio
• wp_users: todas las cuentas de usuario, nombres de usuario y contraseñas cifradas
• wp_usermeta: roles de usuario, capacidades y preferencias de cuenta
• wp_options: configuraciones de todo el sitio, configuraciones de plugins y datos del tema activo
• wp_comments: todos los comentarios de los visitantes y sus metadatos

Los plugins y temas añaden sus propias tablas además de las predeterminadas de WordPress. Una tienda WooCommerce añade tablas para pedidos, productos y datos de clientes. Un plugin de formularios añade tablas para cada envío.

Cuanto más construyas en WordPress, más crecerá tu base de datos.

Por qué necesitas asegurar tu base de datos de WordPress

La base de datos es un punto de fallo al que apuntan todos los atacantes serios. Todo lo que vale la pena robar o destruir vive allí.

La inyección SQL sigue siendo un método de ataque común. Un hacker envía entradas cuidadosamente elaboradas a través de un formulario de inicio de sesión, un cuadro de búsqueda o un campo de plugin vulnerable. Si la entrada no se sanea adecuadamente, la base de datos la trata como un comando y la ejecuta.

Desde allí, el atacante puede leer y exportar toda tu base de datos, crear nuevas cuentas de administrador, inyectar contenido malicioso en tus entradas o eliminarlo todo a la vez.

Tu archivo wp-config.php es el otro objetivo principal. Contiene el nombre de tu base de datos, nombre de usuario y contraseña en texto plano. Un atacante que obtenga ese archivo no necesita tu inicio de sesión de WordPress. Se conecta directamente a la base de datos y evita WordPress por completo.

Lo que sorprende a la mayoría de los propietarios de sitios es lo silenciosas que son estas brechas. Las cuentas de administrador maliciosas y el código inyectado no suelen romper nada visible de inmediato. Para cuando notes las redirecciones de spam o el contenido alterado, el atacante ya ha tenido acceso durante semanas.

Es por eso que el endurecimiento de la seguridad por sí solo no es suficiente. También necesitas una forma de detectar cambios y recuperarte de una copia de seguridad limpia cuando algo se cuela.

Lo que necesitas antes de empezar

Antes de hacer cualquier cambio, asegúrate de tener todo lo siguiente preparado. Omitir el paso de copia de seguridad en particular ha perjudicado a mucha gente en pasos como el cambio del prefijo de la tabla. No vale la pena el riesgo.

• Acceso al panel de control de hosting. Necesitarás iniciar sesión en cPanel, MyKinsta, el panel de WP Engine o el panel que tu host proporcione. Varios pasos implican phpMyAdmin, que normalmente se encuentra en la sección Bases de datos de tu panel de control.
• Acceso FTP o Gestor de Archivos. Necesitarás una forma de ver y editar archivos en tu servidor, específicamente wp-config.php. La mayoría de los hosts proporcionan un gestor de archivos directamente en el panel de control.
• Sus credenciales de base de datos actuales. Abra wp-config.php y localice los valores DB_NAME, DB_USER, DB_PASSWORD y DB_HOST. Los consultará en los pasos 3 a 5.
• Una copia de seguridad completa del sitio realizada antes de empezar. Utilice un plugin de copias de seguridad como Duplicator o cree una copia de seguridad manual. Asegúrese de tener copias de los archivos y la base de datos de su sitio. Algunos de estos pasos realizan cambios directos en su base de datos y necesita un punto de restauración limpio si algo sale mal.
• Acceso de administrador de WordPress. Necesitará iniciar sesión como administrador para varios pasos en este tutorial.

Cómo proteger su base de datos de WordPress

Le daré 13 pasos sencillos para proteger su base de datos de WordPress antes de que ocurra un ataque.

Las primeras ocho medidas refuerzan la base de datos en sí y cierran las rutas de ataque más comunes. Los pasos 9 a 13 configuran la capa de copia de seguridad, monitorización y recuperación que le protege cuando el refuerzo por sí solo no es suficiente.

Aquí tiene un resumen de lo que hará:

• Paso 1: Cambie el nombre de usuario y el ID de administrador predeterminados. Elimine las dos credenciales más atacadas en los ataques automatizados de WordPress.
• Paso 2: Cambie el prefijo de tabla de base de datos predeterminado. Reemplace el prefijo predecible wp_ que los scripts de inyección SQL están diseñados para atacar.
• Paso 3: Cree un usuario de base de datos dedicado con privilegios limitados. Reduzca los permisos de su usuario de base de datos solo a los cuatro permisos que WordPress realmente necesita.
• Paso 4: Deshabilite las conexiones remotas a la base de datos. Cierre el acceso externo a su base de datos a nivel de configuración de MySQL.
• Paso 5: Proteja su archivo wp-config.php. Bloquee el archivo que almacena sus credenciales de base de datos en texto plano.
• Paso 6: Habilite SSL para las conexiones de base de datos. Encripta los datos en tránsito entre WordPress y MySQL si se ejecutan en servidores separados.
• Paso 7: Añada un cortafuegos de aplicaciones web. Filtre los intentos de inyección SQL antes de que lleguen a su base de datos.
• Paso 8: Limpie las tablas de plugins abandonados. Elimine las tablas huérfanas dejadas por plugins desinstalados que hinchan su base de datos y portan vulnerabilidades sin parches.
• Paso 9: Configure copias de seguridad encriptadas. Active la encriptación AES-256 para que sus archivos de copia de seguridad no puedan leerse sin su clave, incluso si alguien los descarga directamente.
• Paso 10: Programe copias de seguridad automáticas de la base de datos. Elimine el error humano de su rutina de copias de seguridad para que siempre tenga un punto de restauración reciente, independientemente de lo ocupado que esté.
• Paso 11: Almacene las copias de seguridad fuera del sitio. Saque copias de su servidor para que una brecha a nivel de host no pueda eliminar sus opciones de recuperación.
• Paso 12: Supervise los cambios en la base de datos. Detecte la creación de cuentas de administrador no autorizadas y cambios no autorizados en tiempo real.
• Paso 13: Pruebe una restauración de la base de datos. Confirme que su plan de recuperación funciona antes de que lo necesite.

Paso 1: Cambiar el nombre de usuario y el ID de administrador predeterminados

WordPress crea un usuario con el nombre de usuario “admin” y un ID de 1 durante la instalación. Estos dos valores están integrados en casi todos los scripts automatizados de fuerza bruta y de inyección SQL que se dirigen a WordPress. Cambiarlos elimina dos de los objetivos más predecibles en tu base de datos.

Aquí tienes un método sencillo para cambiar tu nombre de usuario de administrador sin tocar la base de datos:

1. Crea una nueva cuenta de administrador directamente en WordPress
2. Inicia sesión como ese nuevo usuario
3. Elimina la cuenta de administrador original
4. Reasigna su contenido a la nueva cuenta

Si necesitas hacer el cambio directamente en la base de datos, aquí te explicamos cómo hacerlo a través de phpMyAdmin.

Inicia sesión en phpMyAdmin desde tu panel de control de hosting, selecciona tu base de datos de WordPress en la barra lateral izquierda y haz clic en la pestaña SQL. Ejecuta las siguientes consultas una a una:

UPDATE wp_users SET user_login = 'yournewname' WHERE user_login = 'admin';

UPDATE wp_users SET ID = 101 WHERE ID = 1;

UPDATE wp_posts SET post_author = 101 WHERE post_author = 1;

UPDATE wp_usermeta SET user_id = 101 WHERE user_id = 1;

Las cuatro consultas son necesarias. Tu ID de usuario aparece en wp_users, wp_posts y wp_usermeta, por lo que actualizar solo la primera tabla deja referencias rotas en las otras dos.

Una advertencia antes de ejecutar nada: haz una copia de seguridad completa primero. Un error tipográfico en una consulta SQL directa puede dañar tu sitio de formas que son difíciles de deshacer sin una.

Me gusta usar Duplicator para esto. Tiene ajustes preestablecidos de copia de seguridad fáciles de usar para principiantes que te dan copias rápidas de tu base de datos o de todo el sitio.

Duplicator tiene las mejores herramientas de restauración de todos los plugins de copia de seguridad que he probado. ¡Verás cómo funcionan más adelante en este tutorial!

Para confirmar que el cambio funcionó, cierra sesión en WordPress y vuelve a iniciarla con tu nuevo nombre de usuario. Tu panel de control debería cargarse exactamente como antes.

Paso 2: Cambiar el prefijo de tabla de base de datos predeterminado

WordPress nombra cada tabla de base de datos con un prefijo wp_ por defecto. Los scripts de inyección SQL que se dirigen a WordPress se basan en esto.

Cambiar el prefijo a algo impredecible no detendrá a un atacante sofisticado por sí solo, pero elimina tu sitio del grupo de objetivos que las herramientas automatizadas atacan en el primer intento.

Hay dos formas de hacerlo: usando un plugin de seguridad (recomendado para la mayoría de los usuarios) o haciendo los cambios manualmente a través de phpMyAdmin.

Método del plugin (recomendado)

El método del plugin es la opción más segura para principiantes porque maneja los datos serializados automáticamente. Algunas tablas de opciones de plugins almacenan el prefijo dentro de datos PHP serializados, y una búsqueda y reemplazo SQL en bruto puede dañar esos datos si no se maneja con cuidado.

All-In-One Security incluye una herramienta de prefijo de base de datos con salvaguardas integradas.

Instala el plugin elegido, navega a su sección de herramientas de base de datos y ejecuta el cambio de prefijo desde allí. El plugin actualizará wp-config.php, renombrará todas las tablas y manejará las referencias de datos serializados en un solo paso.

Método manual

Si prefieres cambiar tu prefijo de tabla de base de datos manualmente, sigue estos pasos.

Primero, abre wp-config.php a través de FTP o Administrador de Archivos y actualiza la línea $table_prefix a tu nuevo prefijo. Usa solo letras, números y guiones bajos:

$table_prefix = 'site82_';

Segundo, inicia sesión en phpMyAdmin, selecciona tu base de datos de WordPress y abre la pestaña SQL. Ejecuta una consulta RENAME TABLE para cada tabla de tu base de datos:

RENAME TABLE wp_posts TO site82_posts;

RENAME TABLE wp_users TO site82_users;

Repeat this for all 12 core tables and any tables added by plugins.

A continuación, actualiza la tabla wp_options, que contiene filas que todavía hacen referencia al prefijo antiguo en la columna option_name:

UPDATE site82_options SET option_name = REPLACE(option_name, 'wp_', 'site82_') WHERE option_name LIKE 'wp_%';

Finalmente, actualiza la tabla wp_usermeta por la misma razón:

UPDATE site82_usermeta SET meta_key = REPLACE(meta_key, 'wp_', 'site82_') WHERE meta_key LIKE 'wp_%';

Comprueba tus plugins activos después de ejecutar estas consultas. Algunos plugins almacenan el prefijo en sus propias filas de datos y necesitan que esas también se actualicen. Si algo parece roto, tu copia de seguridad previa al cambio es la forma más rápida de volver a un estado funcional.

Para confirmar que todo funcionó, visita la página de inicio de tu sitio y luego cierra sesión y vuelve a iniciar sesión en tu panel de WordPress. Ambos deberían funcionar exactamente como antes.

Paso 3: Crea un Usuario de Base de Datos Dedicado con Privilegios Limitados

Cuando se instala WordPress, la mayoría de las configuraciones de alojamiento crean un usuario de base de datos con acceso administrativo completo a toda la base de datos. WordPress normalmente solo necesita cuatro permisos básicos para funcionar: SELECT, INSERT, UPDATE y DELETE. Cada permiso adicional podría crear un riesgo extra.

Si un atacante explota una vulnerabilidad de un plugin y obtiene acceso a las credenciales de tu base de datos, los privilegios limitados marcan la diferencia entre que lean tus datos y que eliminen toda tu base de datos.

Hay dos formas de abordar esto: restringir los privilegios del usuario de base de datos existente o crear un nuevo usuario dedicado con solo los permisos que WordPress necesita.

Restringir privilegios a través de phpMyAdmin

Inicia sesión en phpMyAdmin, haz clic en Cuentas de usuario en la parte superior, busca tu usuario de base de datos de WordPress en la lista y haz clic en Editar privilegios. Desmarca todo excepto SELECT, INSERT, UPDATE y DELETE. Desplázate hacia abajo y haz clic en Ir para guardar.

Crear un nuevo usuario dedicado a través de SQL

Si prefieres una configuración limpia, ejecuta estas consultas en la pestaña SQL de phpMyAdmin:

CREATE USER 'wpuser_secure'@'localhost' IDENTIFIED BY 'StrongPasswordHere';

GRANT SELECT, INSERT, UPDATE, DELETE ON your_database_name.* TO 'wpuser_secure'@'localhost';

FLUSH PRIVILEGES;

If you create a new user, update your wp-config.php file with the new credentials:

define('DB_USER', 'wpuser_secure');

define('DB_PASSWORD', 'StrongPasswordHere');

Una nota importante: algunos plugins y las actualizaciones importantes del núcleo de WordPress necesitan permisos CREATE o ALTER para agregar o modificar tablas de bases de datos durante la instalación. Si la instalación de un plugin falla después de este paso, vuelve a otorgar temporalmente esos permisos, completa la instalación y luego revócalos de nuevo.

Si ejecutas varios sitios de WordPress en el mismo servidor, utiliza una base de datos completamente separada y un usuario de base de datos separado para cada uno. Si un sitio se ve comprometido, esa contención evita que el atacante llegue a los demás.

Para confirmar que los permisos están configurados correctamente, crea una entrada de borrador en WordPress, guárdala y elimínala. Si las tres acciones se completan con éxito, tu usuario de base de datos tiene lo que necesita y nada más.

Paso 4: Desactivar Conexiones Remotas a la Base de Datos

En la mayoría de las configuraciones de WordPress, WordPress y MySQL se ejecutan en el mismo servidor. No hay razón para permitir que IPs externas se conecten directamente a tu base de datos. Dejar el acceso remoto abierto significa que un atacante puede intentar autenticarse contra MySQL desde cualquier lugar de Internet, eludiendo WordPress por completo.

Hay dos lugares para cerrar esto, y deberías revisar ambos.

Configuración de MySQL

Si administras tu propio servidor (VPS o alojamiento en la nube), localiza tu archivo de configuración de MySQL. Normalmente se encuentra en /etc/mysql/mysql.conf.d/mysqld.cnf. Busca la línea bind-address y confirma que está configurada como 127.0.0.1:

bind-address = 127.0.0.1

Si está configurada como 0.0.0.0, cámbiala a 127.0.0.1 y reinicia MySQL para aplicar el cambio:

sudo systemctl restart mysql

Nombre de host del usuario de la base de datos

Incluso si MySQL está vinculado a localhost, vale la pena confirmar que tu usuario de base de datos de WordPress también esté restringido a conexiones locales a nivel de usuario.

En phpMyAdmin, haz clic en Cuentas de usuario y busca tu usuario de base de datos de WordPress. La columna Host debería mostrar localhost o 127.0.0.1. Si ves un comodín %, ese usuario puede conectarse desde cualquier dirección IP.

Elimina cualquier usuario configurado como % y vuelve a crearlos con localhost como host:

DROP USER 'wpuser'@'%';

CREATE USER 'wpuser'@'localhost' IDENTIFIED BY 'YourPassword';

GRANT SELECT, INSERT, UPDATE, DELETE ON your_database_name.* TO 'wpuser'@'localhost';

FLUSH PRIVILEGES;

Usuarios de alojamiento compartido

Si estás en un alojamiento compartido y no tienes acceso al archivo de configuración de MySQL, consulta tu panel de control en su lugar. En cPanel, busca MySQL remoto en la sección Bases de datos.

Elimina cualquier dirección IP que aparezca allí. Ese es el equivalente a cerrar el acceso remoto a nivel de alojamiento.

Para confirmar que el acceso remoto está deshabilitado, tu usuario de base de datos de WordPress debería mostrar localhost como el único host permitido en la pantalla Cuentas de usuario de phpMyAdmin.

Paso 5: Protege tu archivo wp-config.php

Tu archivo wp-config.php contiene el nombre de tu base de datos, nombre de usuario, contraseña y claves de autenticación en texto plano. Si un atacante puede leer este archivo, tiene todo lo que necesita para conectarse directamente a tu base de datos. Es uno de los primeros archivos que se atacan en cualquier ataque a WordPress.

Aplica las tres protecciones siguientes juntas. Cada una cierra una exposición diferente.

1. Mueve el archivo por encima de la raíz web

WordPress busca automáticamente un directorio por encima de la raíz si no puede encontrar wp-config.php en su lugar, por lo que puedes mover el archivo sin cambiar ninguna configuración. Si la raíz de tu sitio es /public_html, mueve wp-config.php a /home/username/. Usa FTP o el Administrador de archivos de tu host para hacer esto.

Esto funciona en la mayoría de las configuraciones de alojamiento estándar, pero algunos proveedores de alojamiento administrado no lo permiten. Si tu host restringe el acceso por encima de la raíz web, salta a las dos protecciones siguientes.

2. Bloquea el acceso web a través de .htaccess

Añade la siguiente regla a tu archivo .htaccess, que se encuentra en el directorio raíz de tu WordPress. Esto le dice a Apache que deniegue todas las solicitudes del navegador para el archivo directamente, incluso si alguien conoce la ruta:

<Files wp-config.php>

order allow,deny

deny from all

</Files>

Si tu host utiliza una configuración de Apache más reciente, usa esta versión en su lugar:

<Files "wp-config.php">

Require all denied

</Files>

3. Establece los permisos del archivo a 400 o 440

Los permisos de archivo controlan qué usuarios en el servidor pueden leer, escribir o ejecutar un archivo. Establecer wp-config.php a 400 significa que solo el propietario del archivo puede leerlo. Establecerlo a 440 extiende el acceso de lectura al grupo del servidor también, lo cual requieren algunas configuraciones de alojamiento.

En el Administrador de archivos de tu host, haz clic derecho en wp-config.php, selecciona Cambiar permisos e introduce 400. A través de FTP, la mayoría de los clientes te permiten hacer clic derecho en el archivo y establecer los permisos directamente.

Para confirmar que las tres protecciones están activas, intente acceder a su-dominio.com/wp-config.php en un navegador. Debería obtener un error 403 Forbidden.

Paso 6: Habilitar SSL para conexiones de base de datos

Cuando WordPress y MySQL se ejecutan en el mismo servidor, los datos entre ellos permanecen locales y nunca cruzan una red. Pero si su base de datos se ejecuta en un servidor separado (común en configuraciones VPS, alojamiento en la nube o entornos administrados), esos datos viajan a través de una conexión de red. Sin SSL, viajan en texto plano, incluidas las credenciales de inicio de sesión y los tokens de sesión.

Si está en un alojamiento compartido estándar con WordPress y MySQL en el mismo servidor, puede omitir este paso. Si está en una arquitectura multiserver o una configuración en la nube donde su base de datos se ejecuta por separado, no lo haga.

Consulte primero con su proveedor de alojamiento

Muchos proveedores de alojamiento administrado manejan SSL para conexiones de base de datos automáticamente. Kinsta, WP Engine y Cloudways aplican conexiones de base de datos cifradas a nivel de infraestructura. Consulte la documentación de su proveedor antes de realizar cualquier cambio manual; es posible que ya esté cubierto.

Habilitar SSL en el servidor MySQL

Si administra su propio servidor, agregue lo siguiente a su archivo mysqld.cnf para configurar certificados SSL y requerir conexiones cifradas:

[mysqld]

ssl-ca = /path/to/ca.pem

ssl-cert = /path/to/server-cert.pem

ssl-key = /path/to/server-key.pem

require_secure_transport = ON

Reinicie MySQL después de guardar el archivo.

Indicar a WordPress que use SSL

Agregue la siguiente línea a su archivo wp-config.php, encima de la línea que dice /* ¡Eso es todo, deja de editar! */:

define('MYSQL_CLIENT_FLAGS', MYSQLI_CLIENT_SSL);

Esto indica a la conexión de base de datos de WordPress que requiera SSL al conectarse a MySQL.

Para confirmar que SSL está activo, revise el registro de errores de su servidor MySQL después de que WordPress realice su próxima conexión a la base de datos. Debería ver SSL listado como activo para el usuario de la aplicación.

Paso 7: Añadir un cortafuegos de aplicaciones web

El endurecimiento de la base de datos en los pasos anteriores reduce significativamente su superficie de ataque. Pero no elimina el riesgo de que un plugin vulnerable se convierta en un punto de entrada para la inyección SQL.

Un Firewall de Aplicaciones Web (WAF) se sitúa delante de su sitio y filtra las solicitudes maliciosas antes de que lleguen a WordPress o a su base de datos.

Para la seguridad de la base de datos, el trabajo más importante de un WAF es reconocer los patrones de inyección SQL en las entradas de formularios, los parámetros de URL y los encabezados de solicitud, y bloquearlos antes de que se ejecuten. También bloquea IPs y bots maliciosos, reduce los intentos de inicio de sesión por fuerza bruta y mantiene un registro de las solicitudes bloqueadas que puede revisar si algo parece sospechoso.

Tres opciones de WAF funcionan bien para la mayoría de los sitios de WordPress:

• Wordfence: Se instala directamente como un plugin de WordPress. El nivel gratuito incluye un WAF con protección básica contra inyección SQL. El nivel premium agrega inteligencia de amenazas en tiempo real y actualizaciones de reglas más rápidas.
• Sucuri: Ofrece un escáner basado en plugins y un WAF a nivel de DNS. La opción a nivel de DNS enruta todo el tráfico a través de la red de Sucuri antes de que llegue a su servidor, lo que proporciona una protección más sólida pero requiere un plan de pago.
• Cloudflare: Un WAF a nivel de DNS con un nivel gratuito que cubre el filtrado básico de ataques. Los planes de pago agregan reglas más granulares y una mejor cobertura para ataques de capa de aplicación.

Si necesita ajustar las reglas del firewall después de la configuración, pruebe cualquier cambio en una copia provisional de su sitio antes de aplicarlos a producción. Una regla mal configurada puede bloquear el tráfico legítimo: los formularios de contacto, los flujos de pago y las acciones administrativas son víctimas comunes.

Un WAF es una capa complementaria, no un reemplazo de los pasos de endurecimiento que ya ha completado. Piénselo como el filtro que atrapa lo que se escapa de todo lo demás.

Paso 8: Limpiar tablas de plugins abandonados

Cuando desinstala un plugin en WordPress, sus tablas de base de datos generalmente se quedan atrás. WordPress no las elimina automáticamente, y la mayoría de los plugins no se limpian después de sí mismos al eliminarlos.

Con el tiempo, estas tablas huérfanas hinchan su base de datos y crean un riesgo de seguridad oculto: una tabla de un plugin con una vulnerabilidad conocida de inyección SQL sigue siendo explotable incluso después de que el plugin en sí haya desaparecido.

Para identificar tablas huérfanas, utilice un plugin como WP-Optimize o Advanced Database Cleaner. Ambos escanean su base de datos y marcan las tablas que no corresponden a ningún plugin actualmente activo.

Instale uno, ejecute un escaneo de optimización de la base de datos y revise los resultados antes de eliminar nada.

También puede revisar la lista de tablas manualmente en phpMyAdmin. Seleccione su base de datos de WordPress en la barra lateral izquierda y revise la lista de tablas. Las tablas que no coinciden con su $table_prefix actual o que llevan el nombre de un plugin que ya no utiliza son candidatas para su eliminación.

Sin embargo, cree una copia de seguridad de la base de datos nueva primero. Eliminar una tabla es permanente, y algunas tablas que parecen abandonadas todavía se utilizan activamente.

Tenga especial cuidado con cualquier tabla asociada con WooCommerce, plugins de formularios como Gravity Forms o WPForms, y plugins de membresía o LMS. Estos a menudo almacenan registros de transacciones, envíos de formularios y datos de usuario que puede necesitar incluso si el plugin ya no está activo.

Compare cada tabla candidata con su lista de plugins activos antes de eliminarla. Si no está seguro de a qué pertenece una tabla, busque el nombre de la tabla junto con la palabra "WordPress" para identificar el plugin que la creó.

Para eliminar una tabla huérfana confirmada en phpMyAdmin, seleccione la tabla, haga clic en Operaciones y desplácese hacia abajo para hacer clic en Eliminar tabla. Alternativamente, ejecútela a través de la pestaña SQL:

DROP TABLE old_plugin_table_name;

Para confirmar que la limpieza se realizó sin problemas, ejecute una prueba funcional rápida en su sitio después de eliminar las tablas. Verifique su página de inicio, envíe un formulario de prueba si tiene uno, y cierre sesión y vuelva a iniciarla.

Paso 9: Configurar copias de seguridad cifradas

Los pasos anteriores reducen las posibilidades de sufrir un ataque exitoso en su base de datos. Este paso es lo que le saca de uno.

La mayoría de la gente piensa en las copias de seguridad como una herramienta de recuperación ante desastres. Dependiendo de cómo las cree, también pueden ser un riesgo de seguridad.

Un archivo de copia de seguridad sin cifrar en una carpeta de Google Drive es una segunda copia de toda su base de datos. Cualquiera que obtenga acceso a esa cuenta de almacenamiento puede descargarlo, abrirlo y leer cada registro de usuario, hash de contraseña y pedido de cliente sin tocar su sitio en vivo. El cifrado hace que ese archivo sea inútil sin su clave.

Por eso siempre cifro las copias de seguridad con Duplicator. Este plugin te permite activar el cifrado AES-256 en cada copia de seguridad.

AES-256 es el mismo estándar de cifrado que utilizan las instituciones financieras y los sistemas gubernamentales. Con él activado, tu archivo de copia de seguridad es completamente ilegible sin la contraseña, incluso si alguien descarga el archivo directamente de tu cuenta de almacenamiento.

Dos cosas que hacer antes de guardar: anota esta contraseña y guárdala en un gestor de contraseñas. Si la pierdes, tus copias de seguridad cifradas se volverán permanentemente inaccesibles. Guarda una copia en algún lugar fuera de WordPress.

Paso 10: Programar copias de seguridad automáticas de la base de datos

Una copia de seguridad cifrada solo te protege si realmente tienes una cuando algo sale mal.

Las copias de seguridad manuales fallan en la práctica porque la vida se interpone. Te acuerdas de ejecutar una antes de una gran actualización, quizás después de una migración, ocasionalmente cuando algo parece ir mal. Lo que no haces es ejecutar una cada día sin falta.

Esa brecha es la diferencia entre una reversión limpia y una desordenada. Si un atacante crea una cuenta de administrador maliciosa o inyecta contenido malicioso hoy y no te das cuenta durante dos semanas, necesitas una copia de seguridad de antes de que eso sucediera.

Un horario diario te da un punto de restauración limpio que nunca tiene más de 24 horas. Un hábito de copia de seguridad manual te da lo que hayas ejecutado por última vez.

En tu panel de WordPress, navega a Duplicator Pro » Schedule Backup y haz clic en Add New. Nombra el horario de copia de seguridad y elige una plantilla. Por ejemplo, podrías crear una plantilla de copia de seguridad de base de datos.

Elige una ubicación de almacenamiento. Duplicator soporta copias de seguridad locales, así como almacenamiento en la nube popular como Duplicator Cloud, Google Drive, Amazon S3 y Google Cloud.

Establece la frecuencia según la actividad de tu sitio.

Las copias de seguridad diarias de la base de datos son la opción correcta para cualquier sitio que publique contenido regularmente, procese pedidos o tenga cuentas de usuario activas. Semanalmente funciona para sitios estáticos o de bajo tráfico donde la base de datos cambia con poca frecuencia.

Paso 11: Almacenar copias de seguridad fuera del sitio con Duplicator Cloud

Una copia de seguridad almacenada en el mismo servidor que tu sitio no es una copia de seguridad real. Si tu servidor se ve comprometido, el ransomware cifra tus archivos o tu host experimenta un fallo catastrófico, pierdes tu copia de seguridad en el mismo momento en que pierdes tu sitio.

El almacenamiento fuera del sitio es lo que separa "lo perdí todo" de "restauré en 20 minutos".

Duplicator Cloud es la opción de almacenamiento de copias de seguridad de WordPress más sencilla. Fue construido para copias de seguridad de WordPress, se integra directamente en Duplicator Pro y no requiere autenticación API.

Si prefieres una alternativa, Duplicator Pro también soporta Google Drive, Amazon S3, Dropbox, OneDrive y cualquier proveedor de almacenamiento compatible con S3, incluyendo Cloudflare R2, Backblaze B2 y DigitalOcean Spaces.

Una vez que tu almacenamiento esté conectado, edita tu horario de copia de seguridad y configúralo para enviar copias a tu proveedor de almacenamiento conectado automáticamente después de cada ejecución.

Mantén como mínimo una copia en tu host y una copia en almacenamiento en la nube fuera del sitio. Para sitios críticos o aquellos que manejan datos de clientes, una tercera copia descargada localmente añade otra capa de protección.

Si necesita restaurar, Duplicator Pro puede extraer directamente de su almacenamiento en la nube conectado sin necesidad de volver a descargar el archivo a su servidor primero.

Navegue a Duplicator Pro » Copias de seguridad. Busque una copia de seguridad en la nube y pulse Restaurar. Esto es más rápido que una descarga manual y funciona incluso si sus copias de seguridad locales han desaparecido.

Incluso si no tiene acceso a su panel de control wp-admin, puede restaurar una copia de seguridad en la nube. ¡Su panel de control Duplicator Cloud le permite revertir instantáneamente cualquier copia de seguridad de forma remota, incluso copias de seguridad de bases de datos parciales!

Paso 12: Monitorear cambios en la base de datos con Activity Log

El movimiento más común que realiza un atacante después de obtener acceso a la base de datos es crear una cuenta de administrador no autorizada. Les da una forma persistente de volver a su sitio incluso después de que el punto de entrada original se cierre y se limpie.

Sin monitorización, esa cuenta puede permanecer oculta durante semanas. Con un plugin de registro de actividad, aparece en el momento en que se crea.

Registro de actividad registra cada acción en su sitio de WordPress con una marca de tiempo y una dirección IP. Hará un seguimiento sin esfuerzo de los inicios de sesión de los usuarios, la creación de nuevas cuentas, los cambios de roles y los cambios de configuración.

Para la seguridad de la base de datos, los eventos que más importan son los nuevos usuarios que usted no creó, las escaladas de roles donde una cuenta de nivel inferior de repente obtiene acceso de administrador y los intentos de inicio de sesión desde direcciones IP desconocidas.

El Registro de actividad está incluido gratis con Duplicator Elite. Una vez que su plan esté activo, descargue el plugin e instálelo en WordPress. Comenzará a rastrear inmediatamente.

Compruebe el registro regularmente en busca de tres cosas.

1. Cualquier cuenta de usuario nueva que no reconozca.
2. Cualquier usuario existente cuyo rol haya cambiado sin su acción.
3. Cualquier inicio de sesión desde una dirección IP que no coincida con las ubicaciones de su equipo.

Cualquiera de estos puede indicar una brecha activa o una compromiso que ocurrió hace días o semanas.

El Registro de actividad le permite filtrar el registro por usuario, tipo de acción o rango de fechas y exportar los resultados. Esto es útil tanto para auditorías rutinarias como para la respuesta a incidentes, donde necesita identificar exactamente cuándo ocurrió un cambio no autorizado.

Paso 13: Probar la restauración de tu base de datos

La mayoría de las personas descubren que su copia de seguridad está rota exactamente cuando están bajo la mayor presión para recuperarse rápidamente. Una prueba solo lleva unos minutos. Una restauración fallida durante un incidente activo le cuesta mucho más.

La función de staging con un clic de Duplicator Pro le permite restaurar una copia de seguridad en una URL de staging separada sin tocar su sitio en vivo. En Duplicator Pro » Staging, cree un nuevo sitio de staging.

Seleccione una copia de seguridad reciente de todo el sitio como plano. Elija un esquema de color de administrador único para diferenciar su sitio de staging y su sitio en vivo.

Una vez que Duplicator haya terminado de crear su sitio de staging, tendrá una réplica completa de su sitio en vivo. Este es un campo de pruebas efectivo para realizar restauraciones de prueba.

Cargue una copia de seguridad en la página Importar copias de seguridad de Duplicator. Recorra el sitio de staging después de que se complete la restauración.

Comprueba tu página de inicio, inicia sesión en el panel de WordPress, abre algunas entradas y confirma que la configuración de tu plugin sea correcta. Si falta algo o está roto, habrás encontrado el problema ahora en lugar de durante una recuperación real.

Para confirmar que tu prueba de restauración fue exitosa, tu sitio de ensayo debería cargarse limpiamente con todo el contenido, usuarios y configuraciones intactos desde la fecha de la copia de seguridad.

Solución de problemas de seguridad de bases de datos

Incluso cuando sigues cada paso cuidadosamente, las cosas pueden salir mal. Aquí están los puntos de fallo más comunes y cómo superarlos.

Tu sitio se queda en blanco después de cambiar el prefijo de la tabla

Lo que ves: Una pantalla blanca o un error genérico de PHP inmediatamente después de cambiar el prefijo de la tabla.

Por qué sucede: La causa más común es una referencia de tabla omitida. Algunos plugins almacenan el prefijo antiguo dentro de datos PHP serializados en las tablas de opciones o usermeta. Si una consulta SQL directa actualizó los nombres de las tablas pero omitió esas referencias internas, WordPress no puede encontrar lo que busca.

Cómo solucionarlo: Restaura una copia de seguridad inmediatamente. Esta es exactamente la razón por la que esa copia de seguridad es innegociable antes de comenzar estos pasos de seguridad de la base de datos.

Una vez que vuelvas a un estado funcional, usa un plugin como All-In-One Security para hacer el cambio de prefijo en su lugar. Sus herramientas manejan los datos serializados automáticamente y es mucho menos probable que dejen referencias rotas.

WordPress no puede conectarse a la base de datos después de editar wp-config.php

Lo que ves: Un mensaje de "Error al establecer una conexión con la base de datos" en el frontend o una pantalla blanca en blanco.

Por qué sucede: Un error tipográfico en uno de los valores de las credenciales de la base de datos es la causa más común. Mover wp-config.php a una ubicación que tu servidor no puede encontrar es la segunda causa más común. Los permisos de archivo establecidos de forma demasiado restrictiva (como 000) también pueden impedir que WordPress lea el archivo.

Cómo solucionarlo: Conéctate a través de FTP o Administrador de archivos y abre wp-config.php directamente. Verifica que DB_NAME, DB_USER, DB_PASSWORD y DB_HOST sean correctos y coincidan exactamente con lo que hay en tu panel de control de hosting. Si moviste el archivo, confirma que está un directorio por encima de la raíz de WordPress, no más profundo. Establece los permisos en 400 o 440 si se han cambiado a cualquier otra cosa.

Un plugin deja de funcionar después de restringir los privilegios de la base de datos

Lo que ves: Un plugin genera un error, no guarda la configuración o muestra un aviso relacionado con la base de datos después de completar el Paso 3.

Por qué sucede: Algunos plugins necesitan permisos CREATE o ALTER para instalar o actualizar sus propias tablas de base de datos. Una vez que se revocan esos permisos, el plugin no puede realizar los cambios estructurales que necesita.

Cómo solucionarlo: Vuelve a conceder temporalmente los permisos CREATE y ALTER a tu usuario de base de datos a través de phpMyAdmin. Actualiza o reinstala el plugin, deja que complete su configuración y luego revoca esos permisos nuevamente. Esto es una parte normal del mantenimiento de una configuración de base de datos de mínimo privilegio.

Nada funciona: Ruta de recuperación completa

Si tu sitio no responde, tu panel de WordPress está bloqueado y no puedes acceder por medios normales, utiliza una de las opciones de recuperación ante desastres de Duplicator.

Para las copias de seguridad almacenadas en Duplicator Cloud, puedes restaurarlas de forma remota. Tu sitio volverá a estar en línea sin necesidad de solucionar problemas adicionales.

Antes de que ocurran desastres, también puedes configurar una copia de seguridad como punto de recuperación en WordPress. Guarda la URL de recuperación ante desastres en un lugar seguro.

Si tu sitio no funciona, pega esta URL en un navegador web y sigue las instrucciones.

Si no configuraste una recuperación ante desastres o copias de seguridad en la nube, ponte en contacto con la línea de soporte de emergencia de tu proveedor de alojamiento. La mayoría de los hosts gestionados conservan sus propias instantáneas a nivel de servidor. Para sitios bajo un ataque activo con malware propagándose en tiempo real, Wordfence y Sucuri ofrecen servicios de respuesta de emergencia de pago.

Preguntas Frecuentes (FAQs)

Has reforzado tu base de datos. Aquí te explicamos cómo mantenerla así.

Si has seguido todos estos pasos, tu base de datos está en mejor estado que la mayoría de los sitios de WordPress que funcionan actualmente.

Sin embargo, el trabajo no ha terminado. La seguridad de la base de datos no es una configuración única. Es una práctica de mantenimiento.

Revisa tu registro de actividad mensualmente y busca cualquier cosa que no coincida con tu propia actividad. Realiza una prueba de restauración trimestralmente: las conexiones de almacenamiento caducan, las contraseñas de cifrado se pierden y la única forma de saber que tus copias de seguridad son utilizables es usarlas.

Revisa los privilegios de usuario de tu base de datos después de instalar cualquier plugin nuevo, ya que algunos plugins reescalan los permisos durante las actualizaciones sin que sea obvio. Y si alguna vez migras a un nuevo host, repite los pasos 4 y 5 desde el principio. La configuración de acceso remoto y los permisos de archivo no siempre se transfieren como esperarías.

Después de completar esta configuración, crea una copia de seguridad solo de la base de datos y etiquétala claramente como tu línea de base posterior al endurecimiento. Si alguna vez necesitas investigar una intrusión meses después, esa línea de base te proporciona un punto de referencia limpio para comparar.

Más de 1.5 millones de profesionales de WordPress utilizan Duplicator Pro para gestionar copias de seguridad, migraciones, staging y recuperación ante desastres. Es la herramienta detrás de los archivos cifrados con AES-256, el almacenamiento externo en la nube de Duplicator, las restauraciones con un solo clic, la recuperación solo de la base de datos y las URL de recuperación ante desastres que te permiten volver a acceder incluso cuando WordPress no se carga.

Si este tutorial te ha sido útil, estas guías también merecen ser marcadas.

• Cómo optimizar tu base de datos de WordPress
• Estos son los pasos de reparación de la base de datos de WordPress que seguí yo mismo (sin necesidad de desarrollador)
• Mantenimiento de la base de datos de WordPress: Qué hacer semanal, mensual y trimestralmente
• ¿Es WordPress seguro? Revelando la verdad
• Cómo proteger tu sitio web de hackers (Guía definitiva de seguridad)
• ¿Cómo recuperar un sitio de WordPress hackeado (9 consejos de expertos)?