Un sitio WordPress es tan sólido como su plugin, su cuenta o su copia de seguridad más débil. El núcleo de WordPress recibe versiones de seguridad con regularidad; lo que usted le añada y cómo lo gestione depende de usted. Esta lista recoge los controles más importantes, más o menos en el orden en que los aplicaríamos nosotros.
1. Mantenga actualizados el núcleo, los plugins y los temas
Las actualizaciones automáticas en segundo plano del núcleo existen desde WordPress 3.7 y, por defecto, cubren las versiones menores. Desde WordPress 5.5 también puede activar las actualizaciones automáticas de cada plugin y cada tema desde las pantallas de administración.
- Active las actualizaciones automáticas de los plugins de desarrolladores de confianza y revise el resto cada semana.
- Las actualizaciones automáticas dependen de WP-Cron. Revise Herramientas > Salud del sitio en busca de errores, porque si el cron falla, las actualizaciones se detienen sin avisar.
- Asegúrese de que puede volver atrás antes de confiar en las actualizaciones automáticas. La documentación de WordPress recomienda lo mismo.
2. Elimine los plugins abandonados y los que no use
La guía de bastionado de WordPress es clara: mantenga los plugins actualizados y borre los que no use. Desactivarlos no basta, porque el código sigue en el servidor.
El directorio de plugins de WordPress.org le ofrece dos señales de alarma:
- Un aviso amarillo que indica que un plugin «no se ha probado con las 3 últimas versiones principales de WordPress».
- Un aviso rojo que indica que un plugin se ha cerrado y ya no se puede descargar. Pasados 60 días se muestra el motivo, y «problema de seguridad» es uno de los motivos posibles.
Un plugin cerrado no recibirá actualizaciones a través de WordPress.org. Sustitúyalo. No instale nunca copias «nulled» (pirateadas) de plugins premium, e instale solo desde WordPress.org o desde proveedores de confianza.
3. Revise las cuentas de administrador
Haga una lista de todas las cuentas con el rol de administrador y elimine las que nadie sepa explicar. Con WP-CLI:
wp user list --role=administrator --fields=ID,user_login,user_email,user_registeredDé a cada persona su propia cuenta nominal, nunca un usuario admin compartido. Use el rol más bajo que permita hacer el trabajo: la mayoría de los editores de contenido no necesitan ser administradores. Exija contraseñas robustas y únicas, idealmente guardadas en un gestor de contraseñas.
4. Active la autenticación de dos factores
Active la 2FA para todos los administradores. El núcleo de WordPress no incluye 2FA, así que necesita un plugin o un proveedor de inicio de sesión único que la imponga. Dé preferencia a métodos como las llaves de seguridad o las llaves de acceso (passkeys) si su plugin los admite, y guarde los códigos de recuperación en un lugar seguro.
5. Limite los intentos de inicio de sesión y decida qué hacer con XML-RPC
La documentación de WordPress describe wp-login.php y xmlrpc.php como objetivos habituales de los ataques de fuerza bruta. Recomienda limitar los intentos de inicio de sesión en el perímetro (un WAF o una CDN) o en el servidor web. Un plugin de seguridad también puede limitarlos, pero se ejecuta en PHP, así que la opción a nivel de servidor resiste mejor cuando hay mucho tráfico.
Si no usa XML-RPC, desactívelo. Algunas aplicaciones móviles y servicios como Jetpack lo necesitan, así que compruébelo antes. Tenga en cuenta que el filtro xmlrpc_enabled solo desactiva los métodos que requieren autenticación. Los pingbacks y otros métodos sin autenticación siguen funcionando. Para desactivarlo por completo, bloquee el archivo en el servidor web. En nginx:
location = /xmlrpc.php {
deny all;
}6. Desactive el editor de archivos integrado
El editor de temas y plugins del escritorio permite a cualquiera con una sesión de administrador modificar código PHP. Desactívelo en wp-config.php:
define( 'DISALLOW_FILE_EDIT', true );Según la documentación de wp-config.php, DISALLOW_FILE_MODS va más allá y también bloquea la instalación y la actualización de plugins y temas desde el escritorio. Úselo solo si despliega los cambios de otra forma, por ejemplo con Git o WP-CLI.
7. Guarde las copias de seguridad fuera del servidor y fuera de la raíz web
La guía de bastionado recomienda copias de seguridad periódicas tanto de los archivos como de la base de datos, varias instantáneas y un lugar de almacenamiento de confianza. Proteja su integridad con cifrado, hashes registrados o soportes de solo lectura.
De ahí se derivan dos reglas prácticas. Una copia dentro de la raíz web, como un archivo zip en wp-content, puede descargarla cualquiera que adivine su nombre. Una copia en el mismo servidor puede borrarla el mismo atacante. Guarde al menos una copia en un lugar al que no lleguen las credenciales del sitio y pruebe una restauración completa.
8. Compruebe la integridad de los archivos
WP-CLI puede comparar sus archivos con las sumas de comprobación oficiales de WordPress.org sin cargar WordPress:
wp core verify-checksums --include-root
wp plugin verify-checksums --allEl primer comando señala los archivos del núcleo modificados, y --include-root avisa de los archivos inesperados en el directorio raíz. El segundo compara los plugins con las sumas de comprobación de WordPress.org, así que solo sirve para los plugins alojados allí. Busque también archivos PHP en wp-content/uploads, que normalmente solo debería contener archivos multimedia.
9. Use un usuario de base de datos con privilegios mínimos
Dé a cada sitio su propia base de datos y su propio usuario de base de datos, con permisos solo sobre esa base de datos. No se conecte nunca como usuario root de la base de datos.
La guía de bastionado señala que el funcionamiento diario solo necesita SELECT, INSERT, UPDATE y DELETE. No recomienda revocar DROP, ALTER y GRANT, porque los plugins y las actualizaciones principales pueden necesitar cambiar el esquema. Si los elimina de todos modos, mantenga copias de seguridad probadas.
10. Fije los permisos de los archivos
El punto de partida de la guía es 755 para los directorios y 644 para los archivos. Los archivos del núcleo, wp-admin y wp-includes solo deberían poder modificarse con su cuenta de usuario, no desde el servidor web. wp-content es la excepción: el servidor web necesita escribir ahí para las subidas. Para wp-config.php, la guía sugiere 400 o 440.
find /var/www/example -type d -exec chmod 755 {} \;
find /var/www/example -type f -exec chmod 644 {} \;
chmod 440 /var/www/example/wp-config.phpAdapte las rutas y la propiedad de los archivos a su alojamiento antes de ejecutar estos comandos.
11. Envíe cabeceras de seguridad
Cabeceras como Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options y Referrer-Policy añaden protección en el navegador. Siempre que pueda, fíjelas en el servidor web o en la CDN en lugar de hacerlo con un plugin. Empiece con una Content Security Policy en modo report-only, porque los temas y los maquetadores visuales pueden depender de scripts en línea.
12. Ponga un WAF delante
La documentación de WordPress describe tres niveles: plugins de seguridad que filtran las peticiones dentro de WordPress, un cortafuegos a nivel de servidor como ModSecurity y servicios de proxy inverso que filtran el tráfico antes de que llegue a su servidor. Cuanto más lejos se haga el filtrado, menos carga llega a PHP. Un WAF no sustituye a las actualizaciones. Le da tiempo entre la publicación de una vulnerabilidad y la aplicación de su parche.
La versión corta
| Área | Mínimo |
|---|---|
| Actualizaciones | Actualizaciones automáticas menores del núcleo activadas, plugins revisados cada semana |
| Plugins | Ningún plugin cerrado, abandonado o sin usar instalado |
| Cuentas | Cuentas nominales, pocos administradores, 2FA para todos ellos |
| Inicio de sesión | Límite de intentos en el servidor o en el perímetro, XML-RPC bloqueado si no se usa |
| Cambios de código | DISALLOW_FILE_EDIT activado |
| Copias de seguridad | Fuera del servidor y de la raíz web, restauración probada |
| Integridad | Sumas de comprobación verificadas, sin PHP en las subidas |
| Base de datos | Un usuario por sitio, con permisos solo sobre su propia base de datos |
| Navegador | HSTS y una CSP probada |
| Perímetro | WAF o proxy inverso delante |
Por dónde empezar
Empiece por los cuatro primeros puntos. Llevan poco tiempo y no requieren cambios en su alojamiento. Después, compruebe sus cabeceras actuales con nuestro escáner de cabeceras de seguridad.
Si quiere que se lo comprueben, SecAudit analiza WordPress en busca de malware y web shells, verifica la integridad de los archivos con las sumas de comprobación oficiales y relaciona los plugins instalados con vulnerabilidades conocidas.
