Hardening automatizado en WordPress: reducir riesgo sin fricción

Por qué WordPress sigue siendo blanco número uno

Antes de hablar de defensas conviene entender por qué WordPress concentra tantos ataques. No es porque sea "inseguro". Es porque:

1. Cuota de mercado: 40%+ de la web pública. Un exploit de scale contra un plugin popular rinde millones de dólares.
2. Ecosistema de plugins heterogéneo: 60.000+ plugins, con quality assurance variable. La superficie real de un sitio típico es la suma de 15-25 plugins + tema.
3. Administradores no-técnicos: muchos sitios los administra alguien cuya especialidad no es seguridad. Updates se postergan, accesos se comparten.
4. Automación de ataques: existen botnets que escanean específicamente WordPress por user-agent, ruta /wp-login.php y respuesta del favicon.

El hardening manual clásico — desactivar XML-RPC, cambiar prefijo de tabla, esconder la versión — ayudaba en 2015. Hoy es condición necesaria pero insuficiente. Lo que mueve la aguja hoy es hardening automatizado, continuo y observable. Eso es lo que hace Drokio.

Las siete capas que hay que endurecer (y cómo se automatiza cada una)

1. Core + plugins + temas: integridad y actualización

Riesgo: archivos modificados por un atacante (webshell, backdoor), plugin obsoleto con CVE conocido, tema con vulnerabilidad sin parche.

Automatización:

• Comparación diaria de checksums contra los archivos oficiales en wordpress.org/plugins y el core de WordPress. Cualquier desviación no intencional dispara alerta y snapshot del archivo.
• Cola de actualización automática con política por clase: seguridad → auto-apply dentro de 24h; minor features → 7 días; major → humano aprueba.
• Staging automático previo a cada update mayor.
• Lista de "plugins de baja confianza" basada en mantenimiento (último commit, tasa de soporte, tamaño de comunidad). Drokio recomienda reemplazos cuando detecta un plugin abandonado.

2. Autenticación

Riesgo: credential stuffing, brute force, fatiga de MFA, reuso de passwords filtrados.

Automatización:

• Rate limiting por IP, por usuario y por ASN en /wp-login.php y REST auth.
• Comparación contra listas de passwords filtrados (hash-based, sin almacenar el password).
• MFA obligatorio para roles administrator, editor y cualquier cuenta con capabilities de install_plugins.
• Detección de travel impossible.
• Revocación automática de sesiones activas si se detecta cambio de contraseña forzado.

3. Superficies expuestas innecesariamente

Riesgo: endpoints que exponen metadata, permiten enumeración o sirven como vector secundario.

Automatización:

• Auditoría de XML-RPC: si no se usa (Jetpack, app móvil), se desactiva con confirmación del operador.
• Auditoría del REST API: endpoints públicos revisados y cerrados cuando procede (/wp-json/wp/v2/users es el clásico).
• Bloqueo de enumeración por autor (?author=1).
• Ocultación de archivos sensibles (readme.html, license.txt, wp-config.php.bak).
• Headers de seguridad: X-Frame-Options, Content-Security-Policy, X-Content-Type-Options, Referrer-Policy, Permissions-Policy.

4. Subida de archivos y ejecución

Riesgo: upload de PHP disfrazado, webshell en carpeta de uploads, ejecución de archivos en directorios no permitidos.

Automatización:

• Bloqueo de ejecución de PHP en /wp-content/uploads/ vía regla del servidor (NGINX/Apache).
• Escaneo de archivos subidos contra firmas conocidas de webshell (c99, r57, b374k) y heurísticas de ofuscación (base64 denso, eval anidado, gzinflate encadenado).
• Lista blanca explícita de extensiones permitidas.
• Cuarentena automática de archivos sospechosos con alerta al operador.

5. Base de datos

Riesgo: SQL injection (casi siempre vía plugin), extracción de wp_users, modificación de opciones (siteurl, home) para defacement de largo plazo.

Automatización:

• Detección de patrones de SQLi en request logs con escalación inmediata.
• Monitoreo de cambios críticos: alteración de siteurl/home, creación de nuevos usuarios con rol admin, cambio de roles existentes, edición masiva de wp_options.
• Backups incrementales cada hora con retención de 30 días; full diario con retención de 90 días.
• Test automatizado de restore en sandbox mensual — un backup que no se restaura no es un backup, es un archivo.

6. Contenido: spam, phishing, defacement

Riesgo: comentarios spam masivos, formularios explotados para envío de phishing, contenido malicioso inyectado en posts por admin comprometido.

Automatización:

• Filtrado de comentarios con múltiples capas (rate limit, honeypot, análisis semántico, listas de abuso).
• Validación de formularios: presencia de token CSRF, timeout humano mínimo, detección de patrones de bot.
• Monitoreo de cambios en contenido publicado: si un post marcado como publicado cambia su contenido por una edición no humana, se revierte y se alerta.

7. Infraestructura subyacente

Riesgo: vulnerabilidad en PHP, servidor web o sistema operativo fuera de la capa WordPress.

Automatización:

• Inventario de versiones (PHP, MariaDB/MySQL, servidor) con CVE feed.
• Alertas cuando la versión de PHP cae fuera de soporte.
• Configuración segura por default para PHP: display_errors=0, allow_url_fopen=0 cuando no se necesita, expose_php=0.
• Auditoría de permisos de archivos: wp-config.php nunca debería ser 0777.

Cómo lo hace Drokio específicamente

Drokio conecta un agente de sitio (plugin ligero + script al nivel de servidor cuando se permite) que envía telemetría a la consola central. Desde ahí:

• Políticas se aplican declarativamente (YAML o UI).
• Cambios se hacen en dry-run y se activan después de revisar impacto.
• El operador ve un dashboard único con todos los sitios bajo gestión (útil para agencias con múltiples clientes).
• Integra con CDN al frente (si hay) para aplicar mitigaciones a nivel red cuando el ataque es distribuido.

Toda la actividad queda loggeada con firma temporal y attribution — útil si el cliente pregunta "¿qué hicieron este mes?".

Checklist de hardening para aplicar hoy (con o sin Drokio)

Esto lo puedes aplicar manualmente antes de automatizarlo:

• Actualizar core, plugins y tema a última versión estable.
• Desactivar (no solo desinstalar) plugins sin uso desde hace > 60 días.
• Cambiar todos los passwords de roles administradores.
• Activar MFA para todos los administrator.
• Eliminar usuario admin por defecto si existe.
• Desactivar edición de archivos desde el dashboard (define('DISALLOW_FILE_EDIT', true); en wp-config).
• Mover wp-config.php un directorio arriba si el servidor lo permite.
• Restringir /wp-admin/ por IP si el equipo que lo usa es conocido y fijo.
• Desactivar XML-RPC si no lo usas.
• Desactivar la enumeración de usuarios vía REST API.
• Aplicar headers de seguridad (CSP, X-Frame-Options, HSTS).
• Configurar backups automáticos off-site con restore test mensual.
• Instalar un plugin de seguridad confiable (Wordfence, Sucuri, iThemes Security) o activar Drokio.

Errores típicos que vemos en auditorías

Error 1: aplicar 10 plugins de seguridad. Conflictos, redundancia, performance destruido, ningún dashboard unificado.

Error 2: hardening agresivo sin plan de rollback. Se bloquea el carrito de compras, la agencia se entera por llamada del cliente.

Error 3: backups sin restore test. 80% de los backups que revisamos en incidentes están rotos o incompletos.

Error 4: ocultar la versión de WordPress como estrategia principal. Security through obscurity no es estrategia.

Error 5: MFA solo para el dueño. Si hay 5 admins y 1 tiene MFA, los otros 4 son la vulnerabilidad.

Medir progreso: KPIs del hardening

• Tiempo promedio para aplicar parche de seguridad (target: < 24h para críticos).
• Porcentaje de sitios bajo gestión con backups probados en último mes.
• Número de plugins activos promedio por sitio (bajar este número es un KPI válido).
• Incidentes por 1.000 sitios por mes.
• Tiempo entre disclosure público de CVE y aplicación de mitigación temporal en sitios afectados.

Hardening por capas: qué cubre cada una

WordPress en producción necesita defensa en profundidad. Las capas que Drokio implementa automáticamente:

Capa 1 — Infraestructura. WAF delante del sitio (Cloudflare, Sucuri, or equivalentes). Certificado TLS válido y renovación automática. HSTS activo. HTTP/2 o /3. DNS con DNSSEC cuando el registrador lo permite.

Capa 2 — Aplicación WordPress core. Versión actualizada siempre (mayor/menor/parche). Archivos con permisos correctos (644 para .php, 755 para carpetas, 600 para wp-config.php). Desactivar edición de archivos desde admin (DISALLOW_FILE_EDIT). Ocultar versión de WordPress en header y feed RSS. Deshabilitar XML-RPC si no se usa.

Capa 3 — Plugins y temas. Auditoría mensual automatizada: plugins sin actualización > 12 meses se marcan. Plugins con CVEs conocidas alertan en tiempo real. Temas desactivados que no se usan, se eliminan (un tema desactivado aún con código vulnerable puede ser atacado).

Capa 4 — Autenticación. 2FA obligatorio para admin. Límite de intentos de login (5 por IP por hora). Captchas en login y en formularios expuestos. URL de admin cambiada (no /wp-admin). Contraseñas forzadas a password manager, longitud mínima 16 caracteres.

Capa 5 — Datos. Backups automáticos diarios (base de datos + archivos) con retención de 30 días. Restauración testeada mensualmente (un backup sin test es teoría). Cifrado en reposo si el hosting lo soporta.

Capa 6 — Observabilidad. Logs de access, error y security centralizados. Alertas por patrones anómalos (spike de 404, login desde geolocalización nueva, creación de usuario admin).

Drokio configura las 6 capas en la instalación inicial y las monitorea continuamente. Cualquier desvío (ej. plugin sin actualizar) genera ticket automático en el sistema del cliente.

Los anti-patrones de seguridad WordPress que aún se ven

Anti-patrón 1: plugin de seguridad como única defensa. Wordfence, iThemes, All-in-One Security son útiles pero no suficientes. Son una capa, no la solución. Confiar solo en el plugin = castillo de cartas.

Anti-patrón 2: hosting barato sin aislamiento. Shared hosting donde 500 sitios viven en el mismo servidor. Si uno se infecta, contaminación cruzada. Subí un escalón a VPS o managed WordPress (WP Engine, Kinsta, Pressable).

Anti-patrón 3: "lo tengo funcionando, no toco nada". Regla de oro: lo que no se actualiza, eventualmente se explota. Más del 60% de incidentes WordPress tienen raíz en versiones viejas de plugin o core.

Anti-patrón 4: admin con email genérico. admin@empresa.com, info@empresa.com — cuentas compartidas que si se comprometen, nadie sabe quién tuvo acceso. Cada admin con email propio + 2FA.

Anti-patrón 5: no monitorear cambios en archivos. Un atacante que inyecta código en un archivo PHP se queda meses sin ser detectado. File integrity monitoring (FIM) debería ser estándar.

Benchmarks que Drokio expone al cliente

El valor del hardening automatizado se ve en métricas:

• Tiempo medio para aplicar parche crítico. Objetivo: < 48 horas desde el release del CVE.
• % de plugins actualizados. Objetivo: 100% de los con CVEs pendientes.
• Intentos de login bloqueados/mes. Visibilidad del nivel de ataque ambiente.
• Integridad de archivos. Alertas por modificación no autorizada de archivos del core o de plugins.
• Tiempo de detección de compromiso. Objetivo: < 24h desde que un archivo malicioso aparece.

Sin estos KPIs el hardening es decoración. Con ellos es gestión de riesgo visible al negocio.

Preguntas frecuentes

¿Drokio requiere instalar un plugin?

Sí, un plugin ligero que actúa como agente. Es open-source y el código está disponible para auditoría. Si el entorno no permite instalar plugins, hay un modo híbrido con reglas a nivel servidor.

¿Funciona con hosting compartido?

Con limitaciones. Algunas defensas requieren acceso a nivel servidor que shared hosting no permite. Para agencias con muchos sitios en shared, recomendamos migrar los críticos a VPS o managed WordPress.

¿Rompe mi sitio si activo todo?

No debería. Las políticas se activan primero en modo warn-only, se revisan falsos positivos, y luego se promueven a enforcement. Es un setup progresivo.

¿Qué pasa si un plugin legítimo queda marcado como sospechoso?

Hay una whitelist explícita. El operador marca el plugin como confiable, documenta la razón, y la regla se ajusta. Si un plugin genera false positives repetidos, hay un caso para revisar si vale la pena mantenerlo.

¿Se integra con Cloudflare, Sucuri, o WAFs externos?

Sí. Drokio coopera con WAFs que ya tengas; no los reemplaza. El objetivo es tener telemetría unificada en vez de duplicar controles.

¿Cómo maneja sitios multisite?

Nativo. Cada subsite tiene su política, pero comparten telemetría y controles críticos a nivel de red. Útil para agencias con portfolio.

¿Puedo exportar la evidencia para auditoría?

Sí. Reporte mensual automático en PDF con inventario de controles, incidentes, tiempo de respuesta. Exportable a CSV para SIEM.

Si tienes 3 o más sitios WordPress en producción y el hardening manual ya no escala, empezá con un diagnóstico de 10 minutos — evaluamos tu superficie y proponemos plan. Para el contexto mayor, leé Seguridad moderna: del plugin a la plataforma, la ficha del producto en /products/drokio, o el sitio propio en drokio.com.