rafa/feadulta
1
0
Fork 0
Code Issues 71 Pull Requests 5 Actions Packages Projects Releases Wiki Activity

[SECURITY] Lecciones aprendidas: auditoría y hardening para WordPress en Hetzner #184

New Issue
Open
opened 2026-07-29 06:52:54 +00:00 by rafa · 0 comments
rafa commented 2026-07-29 06:52:54 +00:00
Owner
Copy Link
Copy Source

Objetivo

Convertir los hallazgos del incidente de seguridad de WordPress (#183) en controles verificables antes del despliegue definitivo de Fe Adulta en Hetzner.

Estado: lista viva de lecciones aprendidas. No desplegar cambios desde este issue sin una propuesta y aprobación explícitas.

Contexto del incidente

  • WordPress core no conserva una auditoría histórica de logins correctos.
  • Limit Login Attempts Reloaded solo dejó transients temporales de intentos fallidos/bloqueos, insuficientes para atribución.
  • Los access/error logs del hosting actual no están accesibles desde la cuenta operativa.
  • Se detectaron artefactos maliciosos en #183; la investigación y contención siguen activas.

Controles que debe tener el nuevo servidor

Auditoría WordPress

  • Evaluar e instalar un plugin de auditoría mantenido, con log de logins correctos/fallidos, cambios de usuarios/roles, instalación/activación de plugins, cambios de archivos/configuración y modificaciones editoriales relevantes.
  • Definir retención, rotación y exportación de los logs fuera del volumen de la app.
  • Probar alertas para: alta de administrador, cambio de rol, login de admin, reset de contraseña, instalación/activación de plugin y edición de MU-plugin.
  • Restringir acceso a los logs y excluir secretos, cookies, recovery links y contraseñas.

Infra y trazabilidad

  • Conservar access logs y error logs de reverse proxy / web server con IP real (Cloudflare correctamente resuelto), user-agent, request, status y timestamp UTC.
  • Centralizar logs de Docker/Coolify, WordPress/PHP y sistema; definir retención y copias de evidencia para incidentes.
  • Alertas de cambios de integridad para wp-content/mu-plugins, plugins, theme activo, wp-config.php y archivos ejecutables en uploads.
  • Backups verificables y restauración probada; backups separados de la máquina de producción.

Reducción de superficie

  • Política de cuentas: mínimo privilegio, revisión periódica de administradores, cierre de cuentas legacy, MFA donde sea viable, revocación de sesiones/application passwords al retirar acceso.
  • Deshabilitar edición de plugins/temas desde wp-admin y limitar permisos de filesystem del usuario web.
  • WAF/rate limiting para login y REST; proteger wp-login y XML-RPC según necesidades editoriales.
  • Inventario de plugins con propietario, motivo, versión, fecha de revisión y proceso de actualización.

Operación de incidentes

  • Runbook: preservar evidencia → contener → verificar servicio → rotar secretos → investigar → comunicar.
  • Tabla de contactos y procedimiento para solicitar logs forenses a proveedor/infra.
  • Ejercicio de recuperación y simulación de cuenta admin comprometida.

Criterio de cierre

Todos los controles seleccionados quedan desplegados, documentados, probados y con responsable/retención definidos. Incorporar en este issue las conclusiones finales de #183 antes de cerrar.

Relacionados: #183.

## Objetivo Convertir los hallazgos del incidente de seguridad de WordPress (#183) en controles verificables antes del despliegue definitivo de Fe Adulta en Hetzner. **Estado:** lista viva de lecciones aprendidas. No desplegar cambios desde este issue sin una propuesta y aprobación explícitas. ## Contexto del incidente - WordPress core no conserva una auditoría histórica de logins correctos. - Limit Login Attempts Reloaded solo dejó transients temporales de intentos fallidos/bloqueos, insuficientes para atribución. - Los access/error logs del hosting actual no están accesibles desde la cuenta operativa. - Se detectaron artefactos maliciosos en #183; la investigación y contención siguen activas. ## Controles que debe tener el nuevo servidor ### Auditoría WordPress - [ ] Evaluar e instalar un plugin de auditoría mantenido, con log de logins correctos/fallidos, cambios de usuarios/roles, instalación/activación de plugins, cambios de archivos/configuración y modificaciones editoriales relevantes. - [ ] Definir retención, rotación y exportación de los logs fuera del volumen de la app. - [ ] Probar alertas para: alta de administrador, cambio de rol, login de admin, reset de contraseña, instalación/activación de plugin y edición de MU-plugin. - [ ] Restringir acceso a los logs y excluir secretos, cookies, recovery links y contraseñas. ### Infra y trazabilidad - [ ] Conservar access logs y error logs de reverse proxy / web server con IP real (Cloudflare correctamente resuelto), user-agent, request, status y timestamp UTC. - [ ] Centralizar logs de Docker/Coolify, WordPress/PHP y sistema; definir retención y copias de evidencia para incidentes. - [ ] Alertas de cambios de integridad para `wp-content/mu-plugins`, plugins, theme activo, `wp-config.php` y archivos ejecutables en uploads. - [ ] Backups verificables y restauración probada; backups separados de la máquina de producción. ### Reducción de superficie - [ ] Política de cuentas: mínimo privilegio, revisión periódica de administradores, cierre de cuentas legacy, MFA donde sea viable, revocación de sesiones/application passwords al retirar acceso. - [ ] Deshabilitar edición de plugins/temas desde wp-admin y limitar permisos de filesystem del usuario web. - [ ] WAF/rate limiting para login y REST; proteger wp-login y XML-RPC según necesidades editoriales. - [ ] Inventario de plugins con propietario, motivo, versión, fecha de revisión y proceso de actualización. ### Operación de incidentes - [ ] Runbook: preservar evidencia → contener → verificar servicio → rotar secretos → investigar → comunicar. - [ ] Tabla de contactos y procedimiento para solicitar logs forenses a proveedor/infra. - [ ] Ejercicio de recuperación y simulación de cuenta admin comprometida. ## Criterio de cierre Todos los controles seleccionados quedan desplegados, documentados, probados y con responsable/retención definidos. Incorporar en este issue las conclusiones finales de #183 antes de cerrar. Relacionados: #183.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
inma rafa
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: rafa/feadulta#184
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?