Lista de seguridad de WordPress: 15 cosas que revisar hoy

La seguridad de WordPress no tiene nada de exótico. Es una lista corta de tareas corrientes hechas con regularidad, y la lista de abajo cubre la gran mayoría de las formas en que se vulneran realmente los sitios WordPress: plugins desactualizados, accesos débiles o robados, permisos de archivos demasiado abiertos e infecciones que nadie notó.

Cada punto indica qué comprobar y cómo. Los comandos suponen WP-CLI por SSH; todos tienen también su equivalente en wp-admin o en el administrador de archivos. Reserva entre 30 y 45 minutos para la primera revisión. Las siguientes llevan unos diez minutos, porque solo confirmas que nada ha cambiado.

Actualizaciones

1. El núcleo de WordPress está en la última versión. Mira Escritorio, luego Actualizaciones, o ejecuta wp core version y wp core check-update. Las versiones de seguridad del núcleo se parchean rápido, y los atacantes empiezan a buscar sitios sin parchear en cuestión de días.
2. Todos los plugins están actualizados. Ejecuta wp plugin list --update=available. Los plugins desactualizados son la vía de entrada más común a los sitios WordPress, así que si solo haces un punto de esta lista, haz este. En un sitio que genera ingresos, lee antes el registro de cambios y guarda una copia de seguridad antes de actualizar.
3. Todos los temas están actualizados, incluido el tema padre si usas un tema hijo. wp theme list --update=available muestra lo que va atrasado.
4. Los plugins y temas sin uso están eliminados, no solo desactivados. El código inactivo aún puede solicitarse directamente por su URL, de modo que un plugin vulnerable que desactivaste sigue siendo una puerta de entrada. Conserva un tema por defecto como respaldo y elimina el resto.

Credenciales y acceso

5. Cada cuenta de administrador tiene una contraseña única y robusta. Usa un gestor de contraseñas y no reutilices nunca la de otro servicio. Las contraseñas de bases de datos filtradas se prueban contra los accesos de WordPress a todas horas; la guía de ataques de fuerza bruta explica cómo es ese tráfico.
6. La lista de usuarios no tiene cuentas que no reconozcas. Ejecuta wp user list --role=administrator y revisa cada nombre y correo. Un administrador nuevo que no creaste es una de las señales más claras de un compromiso.
7. El acceso con dos factores está activado para cada administrador. Evita que una contraseña robada sea suficiente. Conviene cubrir también a editores y gestores de tienda si pueden publicar o cambiar pedidos.
8. Las credenciales de hosting, base de datos y SSH son distintas del acceso a WordPress. Si una sola contraseña lo abre todo, una sola filtración lo pierde todo. Para el acceso al servidor, las claves SSH son más seguras que las contraseñas; consulta claves SSH o contraseñas en WordPress.

Archivos y configuración

9. Los permisos de archivos siguen el esquema estándar: 755 para directorios y 644 para archivos, más estrictos para wp-config.php. Lista lo que sea más abierto con find . -type f -perm /o+w. La guía de permisos de archivos tiene el esquema completo y los comandos para corregirlo.
10. wp-config.php está protegido. Contiene la contraseña de tu base de datos y las claves secretas, así que no debe poder leerlo otro usuario del servidor (600 o 640 si tu hosting lo permite), y WordPress puede cargarlo desde una carpeta por encima de la raíz web. Consulta cómo proteger wp-config.php.
11. No hay archivos PHP desconocidos en wp-content/uploads. Esta carpeta es para imágenes y documentos, por lo que los archivos PHP que haya casi siempre son maliciosos. Ejecuta find wp-content/uploads -name "*.php". Lo que quieres es un resultado vacío.
12. Los archivos del núcleo coinciden con las sumas de verificación oficiales. Ejecuta wp core verify-checksums. Cualquier archivo señalado como modificado o inesperado merece una revisión, porque los atacantes suelen editar archivos del núcleo para ocultar una puerta trasera. La guía de integridad de archivos del núcleo explica cómo leer el resultado.

Copias de seguridad y monitorización

13. Existe una copia reciente y se ha restaurado al menos una vez. Una copia que nunca se ha probado es una apuesta. Restaura una en una copia de pruebas y confirma que el sitio carga. Guarda copias fuera del servidor y recuerda que una copia puede contener una infección; consulta la seguridad del hosting gestionado para ver por qué una copia no es un escaneo.
14. Google Search Console está conectada y no muestra problemas de seguridad. Google suele detectar un hackeo, como páginas de spam o redirecciones, antes que el propietario, y el informe de Problemas de seguridad es donde te lo dice.
15. Algo comprueba la integridad de los archivos y los patrones de malware de forma programada. Puedes ser tú, un plugin o un servicio automatizado. Semanal es un ritmo razonable para la mayoría de los sitios, y con qué frecuencia escanear explica cuándo ir más rápido.

Si algún punto de la lista falla

Arregla primero lo barato: actualizaciones, eliminar código sin uso y cambiar contraseñas. Después sigue con permisos y configuración. Si encuentras un archivo que no sabes explicar, un administrador que no creaste o PHP en la carpeta uploads, trata el sitio como posiblemente comprometido y sigue la comprobación de hackeo en cinco minutos antes de cambiar nada más, para no destruir pruebas ni dejarle al atacante el camino de vuelta.