Más allá de Wordfence: construyendo seguridad WordPress real

La trampa de Wordfence

Lo vemos cada semana. Un sitio se compromete. El dueño instala Wordfence, corre un escaneo, remueve el malware obvio, y considera el problema resuelto. Tres meses después el mismo sitio se compromete de nuevo — a veces por el mismo atacante usando el mismo backdoor que el plugin nunca detectó.

Un plugin de seguridad es una capa de defensa, no una estrategia. Los sitios que no se re-comprometen corren seis capas en paralelo. Abajo está la arquitectura que desplegamos para clientes en WooCommerce, sitios de membresía y cualquier negocio donde el downtime cuesta dinero real.

Capa 1 — El servidor mismo

WordPress corre sobre un OS, un servidor web, un runtime PHP y una base de datos. Si esos son débiles, ningún plugin puede salvarte.

Baseline mínima

• Autenticación SSH solo por clave, login con contraseña deshabilitado
• fail2ban sobre SSH, logs web y SMTP (si aplica)
• ufw o firewalld permitiendo solo los puertos que realmente usas
• Actualizaciones de seguridad desatendidas habilitadas
• Un usuario sudo no-root, nunca trabajando como root
• File system: particiones separadas para /var/www y /tmp con noexec en /tmp
• SMTP saliente bloqueado (solo tu relay puede usar el puerto 25)

La brecha más común que rastreamos forensemente no empieza en WordPress en absoluto — empieza en un hosting compartido donde un sitio vecino se comprometió y el atacante pivotó vía el sistema de archivos.

Capa 2 — El WAF

Un Web Application Firewall se sitúa entre el visitante y WordPress, bloqueando ataques antes de que corra cualquier PHP. El WAF correcto detiene el 90%+ de intentos automatizados sin molestar tu servidor.

Lo que un WAF real bloquea

• Fuerza bruta en /wp-login.php y /xmlrpc.php
• Firmas de exploit de CVEs conocidos de plugins
• Patrones de inyección SQL en query strings y bodies
• Intentos de inclusión de archivos (?file=../../etc/passwd)
• Endpoints de REST API usados en ataques de creación de usuarios sin autenticar
• Peticiones POST excesivas desde una sola IP

Opciones que funcionan

• Cloudflare Pro ($20/mes) con el ruleset gestionado de WordPress habilitado
• Sucuri WAF si tu hosting no expone configuración a nivel IP
• ModSecurity self-hosted con el OWASP CRS y reglas WordPress para usuarios VPS

El WAF de Wordfence es un "plugin firewall" — corre dentro de PHP, después de que el atacante ya alcanzó tu aplicación. Es mejor que nada, pero no puede detener ataques que crashean PHP antes de llegar a sus hooks.

Capa 3 — Endurecimiento de WordPress

Una vez el atacante está en la capa WordPress, el endurecimiento interno marca la diferencia entre un intento ruidoso y una brecha exitosa.

Lo no negociable

• Permisos: directorios 755, archivos 644, wp-config.php 600
• DISALLOW_FILE_EDIT puesto a true en wp-config.php (sin editor de tema)
• DISALLOW_FILE_MODS puesto a true si despliegas código vía git
• Salts en wp-config.php rotadas trimestralmente
• Contraseñas fuertes del usuario DB; el usuario DB de WordPress no debe tener privilegios GRANT
• xmlrpc.php bloqueado a nivel del servidor web (a menos que uses Jetpack)
• Endpoint REST API /users restringido a peticiones autenticadas

Lo que siempre removemos

• El usuario admin por defecto (si existe, creamos uno nuevo y lo borramos)
• El post "Hello world" y el comentario de muestra (pistas de fingerprinting de bajo nivel)
• readme.html y license.txt (divulgación de versión)
• Temas y plugins inactivos (cada plugin dormido es superficie de ataque)

Capa 4 — Identidad y acceso

La mayoría de brechas de WordPress que vemos en 2026 no involucran una vulnerabilidad de software — involucran credenciales. Un usuario hizo click en un phishing, reusó una contraseña, o el atacante hizo fuerza bruta contra un pool de admin débil.

Controles de identidad que funcionan

• 2FA obligatorio para todos los roles administrator y editor
• Códigos basados en tiempo (TOTP) preferidos sobre SMS
• Códigos de respaldo impresos y guardados offline
• Login restringido a rangos IP conocidos vía el WAF (si tu equipo trabaja desde ubicaciones fijas)
• Timeout de sesión reducido de los 14 días por defecto a 24 horas para admins
• Todas las cuentas inactivas deshabilitadas, no borradas (preserva el rastro de auditoría)

La trampa de Application Passwords

WordPress 5.6+ trajo Application Passwords para acceso REST API. Los atacantes lo saben. Deshabilitamos Application Passwords para todo rol excepto los que genuinamente necesitan acceso API, vía el filtro wp_is_application_passwords_available.

Capa 5 — Monitoreo

Defensa no es suficiente. Necesitas saber cuándo algo pasa el perímetro — en minutos, no semanas.

Los cuatro monitores que siempre configuramos

1. Monitoreo de integridad de archivos — alerta cuando cualquier archivo en wp-content cambia fuera de un deploy. Usamos tripwire, aide o un watcher inotify custom.
2. Agregación de logs — Nginx, PHP, MySQL y logs de auditoría WordPress centralizados para que patrones sospechosos sean visibles.
3. Monitoreo de peticiones salientes — un sitio comprometido normalmente empieza a hacer POSTs salientes a servidores C2 del atacante. Vigilamos egress por anomalías.
4. Uptime + reputación externos — UptimeRobot para downtime; chequeos periódicos contra Google Safe Browsing, Spamhaus y Sucuri SiteCheck.

El enrutamiento de alertas importa: cambios de archivos van a Slack en 60 segundos, alertas de blacklisting van a email y SMS en 5 minutos.

Capa 6 — Backups y recuperación probada

La última capa es la que más dueños hacen mal. "Tengo backups" no significa nada a menos que hayas probado restaurarlos. Hemos visto backups diarios sin testear por meses y resultar corruptos cuando finalmente se necesitan.

Una estrategia real de backups

• Ubicación fuera del servidor (S3, Backblaze o un data center diferente)
• Encriptación en reposo (AES-256 con la clave no guardada en el mismo servidor)
• Retención: diarios por 14 días, semanales por 12 semanas, mensuales por 12 meses
• Dumps de base de datos usando mysqldump --single-transaction para evitar corrupción
• Un simulacro de restauración mensual en un servidor de staging — esta es la única prueba de que los backups funcionan

Objetivos de tiempo de recuperación

Para un sitio de negocio serio apuntamos a: - RTO (objetivo de tiempo de recuperación): menos de 30 minutos para restauración completa - RPO (objetivo de punto de recuperación): menos de 4 horas de pérdida de datos

Cualquier cosa más laxa está bien para sitios hobby — no para un negocio que depende del sitio.

Errores comunes que seguimos viendo en 2026

• Wordfence + nada más — escaneo rápido de plugin + sin endurecimiento del servidor + sin WAF al frente
• Backups en el mismo servidor — cuando el servidor se compromete, los backups se van con él
• 2FA solo en el admin principal — los atacantes crean un nuevo admin (sin 2FA forzado) y bypasean
• Vendor lock-in para backups de migración — usar un plugin que produce backups solo restaurables por el mismo plugin
• Monitoreo de integridad de archivos deshabilitado porque "es ruidoso" — sin él literalmente no sabes cuándo aterriza el malware

Cuándo llamar a un especialista

Si te han comprometido más de una vez en 12 meses, el problema no es el malware — es la ausencia de capas. Desplegamos este stack para clientes en recuperación WordPress y endurecemos cada capa de una forma que el atacante original no puede replicar.

Reparación de sitio hackeado cubre limpieza post-brecha. Soporte de emergencia WordPress maneja incidentes activos. Eliminación de malware profundiza en infecciones con profundidad forense — y sí, también cerramos el punto de entrada.