Recuperación de desastres WordPress: el framework de 5 fases

Por qué los frameworks ganan a las heroicidades

En nuestro primer año haciendo trabajo de emergencia WordPress, aprendimos una lección brutal: cada emergencia es diferente, pero el patrón de respuesta que funciona siempre es el mismo. Los equipos que manejan desastres bien no tienen ingenieros más inteligentes — tienen un framework que les previene cometer los errores obvios que componen el daño.

Este artículo describe el framework de 5 fases que usamos en cada emergencia WordPress, desde "el sitio está caído" hasta "esto no volverá a pasar". Cada fase tiene su propia meta, sus propios criterios de éxito y sus propios anti-patrones.

Fase 1 — Identificar

Lo primero que hay que saber es qué se rompió realmente. Esto suena obvio pero es la fase más saltada. Los ingenieros bajo presión empiezan a arreglar antes de entender qué están arreglando.

Meta: caracterizar el incidente en tres oraciones.

• ¿Cuál es la experiencia del usuario? (pantalla blanca, redirect a spam, error 500, página lenta)
• ¿Cuál es la firma técnica? (fatal de PHP, MySQL connection refused, firma de payload de malware, etc.)
• ¿Cuál es el alcance? (una sola página, un solo usuario, todo el sitio, múltiples sitios)

Toolkit estándar de identificación

# ¿Qué ve un visitante?
curl -I https://yoursite.com/

# ¿Qué piensa WordPress que está pasando?
wp doctor check --all

# ¿Qué dice el log del servidor?
tail -200 /var/log/nginx/error.log
tail -200 /var/log/php-fpm.log
journalctl -u mysql -n 200

# ¿Cuándo empezó el fallo?
last -F | head -20   # logins recientes / eventos del sistema
find /var/www/yoursite -newer /tmp/marker -type f   # archivos modificados después de un momento bueno conocido

Anti-patrones

• Saltar a un arreglo antes de leer cualquier log
• Asumir que la causa obvia es la causa real (sitio lento = "necesita plugin de caché" es adivinanza 50/50)
• Intentar arreglar más de un problema simultáneamente
• Saltar la pregunta de alcance y sobre-arreglar

Presupuesto de tiempo: 5–15 minutos. Si no puedes caracterizar el incidente en 15 minutos, te falta algo fundamental — empieza en la capa de red y sube.

Fase 2 — Contener

Una vez sabes qué está mal, detén el daño de propagarse. La contención no es el arreglo; es la medida que detiene el sangrado y te da espacio para hacer el arreglo apropiadamente.

Meta: limitar el radio de daño sin empeorar las cosas.

Movimientos estándar de contención

• Tira el sitio offline si está sirviendo contenido malicioso. Una página de mantenimiento es mejor que servir malware a tus clientes y ser blacklisteado. Usamos un HTML estático de mantenimiento o redirigimos temporalmente a una página de estado.
• Snapshot del estado actual inmediatamente. Lo que sea que vayas a cambiar, toma un backup de cómo se ve ahora mismo. Este es tu fallback si tu arreglo empeora las cosas.
• Bloquea el vector de ataque si está activo. ¿Ataque de fuerza bruta? Cloudflare bajo modo ataque. ¿Sonda de inyección SQL? Bloquea la IP en el WAF. ¿Usuario admin comprometido? Deshabilita la cuenta de usuario.
• Detén procesos en segundo plano que podrían componer el problema. Desactiva cron, pausa backups (respaldarían el estado roto), suspende pipelines de deploy.

Contención para escenarios comunes

Anti-patrones

• Saltar el snapshot porque "sabemos lo que hacemos"
• Esperar que el problema se resuelva solo
• Comunicar a los clientes antes de que la contención esté completa (preguntarán cosas que no puedes responder aún)

Presupuesto de tiempo: 5–10 minutos.

Fase 3 — Recuperar

Ahora arreglas el problema real. Aquí es donde la mayoría de artículos pasan todo su tiempo, pero es solo una fase de cinco. El trabajo de recuperación depende de qué se rompió.

Meta: restaurar operación normal con confianza de que el arreglo es duradero.

Principios de recuperación

• Arregla la causa raíz, no el síntoma. Si los errores 500 empezaron tras una actualización de plugin, no solo desactives el plugin y te alejes — identifica por qué la actualización lo rompió, decide si esperar un arreglo o reemplazar el plugin.
• Prueba en aislamiento antes de desplegar. Si estás parcheando una función, corre el archivo parcheado por php -l primero. Si estás cambiando config, revisa sintaxis antes de recargar.
• Aplica cambios incrementalmente. Un cambio, verifica, siguiente cambio. Los arreglos big-bang tienen mayor riesgo de rollback.
• Restaura desde backup si tienes incertidumbre. Para sitios hackeados donde no puedes estar seguro de haber encontrado cada backdoor, una restauración limpia desde un backup pre-incidente es más rápida y segura que perseguir cada archivo modificado.

Checklists de recuperación para las cuatro emergencias más comunes

Actualización de plugin rompió el sitio 1. Identifica el plugin ofensor (Health Check Troubleshooting, log de errores) 2. Rollback vía WP-CLI: wp plugin install pluginname --version=X.Y.Z --force 3. Verifica que front-end y admin ambos funcionan 4. Decide: quedarse en versión vieja, o esperar arreglo?

Infección de malware 1. Toma snapshot completo de archivos + DB del estado comprometido (para forense) 2. Restaura desde backup limpio (tomado antes de la infección) 3. Si no hay backup limpio: limpieza forense de cada archivo modificado (usamos output de escaneo de integridad de archivos) 4. Resetea todas las credenciales: contraseñas admin, contraseña DB, salts, claves API 5. Escanea por backdoors que sobrevivieron (mu-plugins ocultos, archivos del core modificados)

Corrupción de base de datos 1. Detén escrituras inmediatamente 2. Toma un backup binario del directorio de datos 3. Prueba mysqlcheck --repair primero 4. Si InnoDB: innodb_force_recovery=1 hasta 6 en my.cnf, reinicia, vuelca datos buenos 5. Restaura desde el dump a una base de datos fresca

Agotamiento de recursos del servidor 1. Identifica el recurso (CPU, RAM, disco, conexiones) 2. Identifica el consumidor (htop, iotop, SHOW PROCESSLIST) 3. Mata o throttlea el consumidor 4. Añade capacidad si es una carga legítima 5. Optimiza si es un plugin mal portado

Anti-patrones

• Aplicar múltiples arreglos sin verificar cada uno
• "Arreglar" desinstalando todo (pierdes datos de clientes)
• Saltar el paso de backup-antes-de-restore
• Declarar victoria antes de probar en un navegador real

Presupuesto de tiempo: 30 minutos a varias horas dependiendo de la severidad.

Fase 4 — Endurecer

El sitio volvió. No te detengas aquí. El mismo vector de ataque que causó este incidente será usado de nuevo — a veces por el mismo atacante, a veces por uno diferente corriendo la misma herramienta automatizada.

Meta: hacer imposible repetir el mismo incidente.

Endurecimiento basado en tipo de incidente

Endurecimiento genérico que ayuda con cada incidente

• Actualiza el core de WordPress, temas, todos los plugins a lo último
• Quita todos los plugins y temas inactivos
• Pon contraseñas fuertes únicas para cada cuenta
• Fuerza 2FA para roles administrator y editor
• Configura monitoreo de integridad de archivos
• Mueve backups fuera del servidor
• Implementa un WAF si no hay uno

Anti-patrones

• "Endurecimiento rápido" — hacer cambios sin probarlos
• Añadir un plugin de seguridad sin configurarlo
• Compartir las nuevas credenciales en canales en texto plano (Slack, email)

Presupuesto de tiempo: 1–4 horas dependiendo de los cambios necesarios.

Fase 5 — Monitorear

La fase final es la que paga por las cuatro anteriores. Sin monitoreo, te enteras del próximo incidente de la misma forma que te enteraste de este — demasiado tarde, por una queja de cliente.

Meta: detectar una recurrencia en minutos, no días.

El stack de monitoreo

• Uptime — monitor externo haciendo ping cada 60 segundos (UptimeRobot, BetterStack)
• Integridad de archivos — alerta cuando cualquier archivo en wp-content cambia fuera de un deploy planeado
• Base de datos — alerta cuando los patrones de queries se desvían de la baseline
• Tasa de errores — alerta cuando los errores 5xx pican sobre la baseline
• Reputación — chequeo diario contra Google Safe Browsing y principales blacklists
• Log de auditoría — cada acción admin registrada y revisable

A dónde van las alertas

• Cambios de integridad de archivos → Slack, instante
• Uptime caído → Email + SMS, instante
• Aparición en blacklist → Email + SMS, instante
• Pico de tasa de errores → Slack
• Revisión de log de auditoría → Resumen semanal por email

El debrief post-incidente

48–72 horas después de cerrar el incidente, corre un debrief:

• ¿Qué pasó?
• ¿Cómo nos enteramos?
• ¿Qué hicimos?
• ¿Qué funcionó? ¿Qué no?
• ¿Qué cambiaremos en nuestro proceso?

Documenta esto. Tres incidentes después en una práctica real de debrief, el tiempo de respuesta de tu equipo se reducirá a la mitad.

Cuándo este framework se rompe

El framework asume que tienes acceso, tiempo y competencia básica. Se rompe cuando:

• La cuenta de hosting misma está comprometida (bloqueo del panel del hosting)
• El atacante sigue activo en el sistema (necesitas expulsarlo primero)
• La base de datos está destruida más allá de restauración y no existen backups
• Implicaciones legales/regulatorias requieren consejo externo antes de actuar

Estos son los casos donde llamas a especialistas. Manejamos estos escenarios rutinariamente — tiempo promedio al cierre de incidente para una cuenta de hosting comprometida es 4–6 horas.

Respuesta de emergencia — menos de 15 minutos al primer contacto. Eliminación de malware y reparación de sitio hackeado siguen este framework exacto con la profundidad técnica requerida para cada escenario.