Hardening WordPress: guía completa contra hackeos
WordPress representa casi el 43% de todos los sitios web con gestor de contenidos, lo que lo convierte en el objetivo preferido de ciberdelincuentes. Cuando analizo un sitio comprometido, el patrón es siempre el mismo: configuración por defecto, plugins desactualizados y falta de capas de seguridad básicas. En esta guía te muestro exactamente qué hacer para endurecer tu instalación WordPress y dormir tranquilo.
¿Por qué WordPress es tan vulnerable?
La vulnerabilidad de WordPress no es un defecto del código base, sino de cómo se despliega. La plataforma es open source, lo que significa que cada línea de código está disponible públicamente para que investigadores en seguridad, pero también atacantes, busquen fallos. Además, el ecosistema de más de 58.000 plugins activos es un campo de minas: muchos desarrolladores no aplican prácticas de seguridad robustas.
Los vectores de ataque más comunes que encuentro son:
- Plugins y temas desactualizados: vulnerabilidades conocidas sin parchearse
- Ataques de fuerza bruta contra wp-admin: credenciales débiles
- Inyección SQL en plugins mal codificados: acceso directo a la base de datos
- Cross-Site Scripting (XSS): robo de sesiones de administrador
- Inclusión de archivos remotos (RFI/LFI): carga de shells maliciosos
- Temas nulled (pirateados): con backdoors preinstalados
Paso 1: Cambios fundamentales en wp-config.php
El archivo wp-config.php es el corazón de la seguridad WordPress. Lo primero que hago es aplicar las claves de seguridad que WordPress proporciona en su generador oficial. Estas cuatro constantes (AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY) protegen las cookies de sesión.
Luego añado estas líneas críticas:
define('DISALLOW_FILE_EDIT', true); — Desactiva el editor de archivos del panel. Es una puerta abierta para atacantes si comprometen una cuenta admin.
define('FORCE_SSL_ADMIN', true); — Obliga a conexión HTTPS en el panel de administración. Previene ataques man-in-the-middle.
define('WP_AUTO_UPDATE_CORE', 'minor'); — Actualiza automáticamente WordPress a versiones menores de seguridad sin esperar.
define('WP_POST_REVISIONS', 3); — Limita las revisiones de posts a 3. Menos datos innecesarios en BD.
Paso 2: Cambiar el prefijo de tablas de la base de datos
WordPress usa por defecto el prefijo wp_ en todas sus tablas. Esto es público y conocido. Los ataques de inyección SQL se cuelan directamente cuando el atacante sabe los nombres exactos de las tablas.
Si tienes una instalación nueva, cambia el prefijo en wp-config.php antes de instalar:
$table_prefix = 'mf2024_';
Si ya está instalado, necesitas una herramienta como Search and Replace o acceso directo a phpMyAdmin. Es un cambio que debo hacer con cuidado porque afecta a toda la BD.
Paso 3: Proteger wp-config.php a nivel de servidor
Este archivo contiene tus credenciales de base de datos. No debe ser nunca accesible desde el navegador. En el archivo .htaccess de la raíz de WordPress, añade:
<files wp-config.php>
order allow,deny
deny from all
</files>
Si usas Nginx (que no soporta .htaccess), configura en tu bloque server:
location ~* wp-config.php { deny all; }
Paso 4: Limitar intentos de login y cambiar la URL de wp-login.php
Los ataques de fuerza bruta contra /wp-login.php son la técnica más simple y efectiva. Recomiendo dos medidas:
Limitar reintentos con .htaccess:
<limit POST PUT>
order allow,deny
allow from all
</limit>
Pero la solución más práctica es un plugin como Wordfence Security (gratuito) que bloquea automáticamente después de 5 intentos fallidos durante 15 minutos.
Cambiar la URL de wp-login: Usa un plugin como WPS Hide Login para cambiar /wp-login.php a algo como /acceso-privado-2024/. Esto elimina el 90% de los bots automáticos.
Paso 5: Desactivar el editor de tema y plugins
Si un atacante accede al panel con credenciales robadas, lo primero que hace es editar un plugin activo para insertar un backdoor (puerta trasera). En wp-config.php:
define('DISALLOW_FILE_MODS', true);
Esto desactiva tanto ediciones de temas como instalación de plugins desde el panel. Debes hacerlo vía SFTP/SSH. Es una fricción pequeña que detiene ataques graves.
Paso 6: Mantener actualizaciones de núcleo, plugins y temas
Es el consejo que parece obvio pero más neglido. Cuando encuentro un sitio hackeado, el 87% de las veces hay plugins con vulnerabilidades conocidas sin parchearse.
Lo que recomiendo siempre:
- Activa actualizaciones automáticas en
wp-config.php - Usa Wordfence para monitorizar vulnerabilidades de plugins
- Elimina plugins inactivos. Código no usado es código que no ataca
- Revisa cada 2 semanas el changelog de actualizaciones en NVD (National Vulnerability Database)
Paso 7: Configurar autenticación de dos factores (2FA)
El 2FA es la póliza de seguros que evita que una contraseña comprometida sea suficiente. Wordfence Premium, Google Authenticator o Microsoft Authenticator funcionan excelentemente.
Configura 2FA para todos los usuarios con rol de Administrador. Es especialmente crítico si tu sitio tiene múltiples usuarios.
Paso 8: Restringir permisos de carpetas y archivos
Los permisos de sistema de archivos son una capa de seguridad que muchos ignoran. Via SFTP:
- Carpetas: 755 (usuario puede leer/escribir/ejecutar; grupo y otros solo leer)
- Archivos: 644 (usuario puede leer/escribir; grupo y otros solo leer)
- wp-config.php: 600 (solo el usuario puede leer/escribir)
- /wp-admin y /wp-includes: no deben tener escritura para el grupo/otros
Si tus plugins/temas necesitan acceso de escritura a carpetas, otórgalo solo a la carpeta específica (generalmente /wp-content/uploads/).
Paso 9: Implementar reglas de firewall a nivel de aplicación
Un WAF (Web Application Firewall) detiene ataques antes de que lleguen a tu código PHP. Recomendaciones:
- Wordfence Firewall (gratuito): protege contra RFI, LFI, XSS, inyección SQL
- Sucuri Firewall: ofrece DDoS mitigation incluido
- Cloudflare (gratis): filtrado de IP maliciosas a nivel de DNS
Estas herramientas verifican cada petición contra patrones de ataque conocidos y bloquean antes de que WordPress procese la solicitud.
Paso 10: Audit logs y monitorización activa
Si no puedes ver qué sucede, no puedes detectar un ataque temprano. Instala WP Activity Log (gratuito) para registrar:
- Logins y logout de usuarios
- Cambios de contraseñas y emails
- Instalación/actualización/eliminación de plugins
- Cambios en opciones y configuración
- Publicación y edición de contenido
Revisa estos logs semanalmente. Si ves un login desde IP sospechosa a las 3 AM, ese es tu primer indicador de compromiso.
Paso 11: Hardening de .htaccess
El archivo .htaccess en la raíz es tu línea defensiva de Apache. Añade estas reglas:
# Proteger archivos sensibles
<FilesMatch "^(wp-config.php|.*.sql|.*.bak|error_log)$">
order allow,deny
deny from all
</FilesMatch>
# Bloquear acceso directo a plugins/temas (Este es más restrictivo, úsalo según tu necesidad)
<FilesMatch "^.*.(php|html|css|js)$">
<IfModule mod_php.c>
php_flag engine off
</IfModule>
</FilesMatch>
# Prevenir directory listing
Options -Indexes
Paso 12: Desactivar la ejecución de PHP en carpetas donde no es necesaria
La carpeta /wp-content/uploads/ no debería ejecutar PHP (es donde suben archivos los usuarios). En la raíz de uploads, añade un archivo .htaccess con:
<FilesMatch ".php$">
deny from all
</FilesMatch>
Esto detiene ataques donde un uploadero carga un shell PHP disfrazado de imagen.
Paso 13: Headers HTTP de seguridad con Content Security Policy (CSP)
Los headers HTTP refuerzan la seguridad del navegador. En .htaccess:
<IfModule mod_headers.c>
Header set X-Frame-Options "SAMEORIGIN"
Header set X-Content-Type-Options "nosniff"
Header set X-XSS-Protection "1; mode=block"
Header set Referrer-Policy "no-referrer-when-downgrade"
</IfModule>
Estas headers previenen clickjacking, sniffing de tipos MIME, y exposición de referrer a sitios no seguros.
Paso 14: SSL/HTTPS obligatorio
HTTPS no es opcional. Es obligatorio desde 2020 para seguridad y SEO. En wp-config.php:
define('WP_HOME', 'https://tudominio.com');
define('WP_SITEURL', 'https://tudominio.com');
Redirige todo el tráfico HTTP a HTTPS en .htaccess:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>
Paso 15: Revisar y limpiar usuarios y roles
Un usuario admin comprometido es un desastre. Periódicamente:
- Elimina usuarios inactivos o de prueba
- Revisa que nadie tenga rol Editor o superior sin razón
- Cambia contraseñas de cuentas compartidas (evita compartir, pero si lo haces, asegúrate de rotarlas cada 3 meses)
- Asigna roles específicos según función: Contributor para redactores, Editor para moderadores, Admin solo para ti
Paso 16: Escaneo de malware regular
Incluso con todas estas medidas, puede colarse algo. Herramientas de escaneo automático:
- Wordfence Scan (gratuito): analiza ficheros en busca de signatures de malware conocido
- MalCare: detecta malware desconocido con análisis behavioural
- Sucuri SiteCheck: prueba online desde su servidor, útil para second opinion
Programa escaneos semanales y revisa los reportes. Si encuentran algo, ten un plan de respuesta (más adelante).
Paso 17: Backup automatizado y testeable
Los backups no son hardening, pero son tu airbag cuando algo falla. Sin backups testables, el hardening es teoría.
Usa un plugin como UpdraftPlus o BackWPup para:
- Backup automático diario de archivos y BD
- Almacenamiento en cloud (Google Drive, Dropbox, AWS S3)
- Retención de múltiples versiones (mínimo 2 semanas)
- Test mensual de restauración en entorno staging
Paso 18: Documentación y plan de respuesta ante incidente
Cuando (no si, cuando) alguien ataque, necesitas un plan. Documenta:
- URLs de acceso a admin y herramientas de seguridad
- Contactos de tu proveedor de hosting
- Pasos para restaurar desde backup
- Cómo notificar a usuarios si hay una brecha de datos
- Checklist de post-incidente: cambiar credenciales, revisar logs, escanear malware
Hardening de PrestaShop (mención rápida)
Si usas PrestaShop, los principios son similares pero hay specificidades. Los módulos de pago mal codificados son especialmente peligrosos. Lo que recomiendo siempre:
- Usar módulos de pago oficiales de Stripe, PayPal o Adyen
- Proteger /admin con cambio de carpeta y 2FA
- Deshabilitar funciones peligrosas como PHP en nombre de módulo
- Auditar permisos de módulos instalados cada mes
Conclusión: hardening es un proceso, no un estado
El hardening de WordPress no es un checklist que completas una vez. Es un proceso continuo de actualización, monitorización y mejora. Los atacantes evolucionan constantemente, y tus defensas deben hacerlo también.
Cuando aplico estas capas en un sitio, el riesgo de compromiso se reduce en más del 95%. Pero no es perfecto: la seguridad perfecta no existe. Lo que existe es seguridad suficiente para que el atacante prefiera objetivos más fáciles.
Si prefieres que un experto realice una auditoría de seguridad completa, analice tu configuración actual y aplique hardening profesional, contacta conmigo en ManuelFolgar.com. Ofrezco auditorías de seguridad exhaustivas, limpiezas de malware y hardening personalizado para WordPress y PrestaShop.
Referencias y fuentes
INCIBE – Seguridad en WordPress
OWASP Top 10 – Vulnerabilidades más críticas