Logs y auditoría de seguridad en WordPress: qué registrar y cómo monitorizar

No puedes proteger lo que no puedes ver

Cuando hablamos de seguridad en WordPress, solemos pensar en medidas bastante concretas: mantener WordPress, plugins y temas actualizados, usar contraseñas fuertes, activar la autenticación en dos pasos, configurar un firewall, limitar permisos, revisar usuarios y tener una buena estrategia de copias de seguridad.

Todo eso es necesario, pero hay una parte que muchas veces queda en segundo plano: saber qué está pasando realmente en la web.

Una instalación de WordPress puede estar funcionando aparentemente bien y, al mismo tiempo, estar recibiendo intentos constantes de acceso, escaneos de plugins vulnerables, peticiones sospechosas a archivos que no deberían existir, errores PHP repetidos, cambios no documentados en usuarios o modificaciones en plugins y temas que nadie recuerda haber hecho.

A veces no hay una señal evidente. La web carga. El panel funciona. Los formularios se envían. Las ventas entran. Pero por debajo pueden estar ocurriendo cosas que solo veremos si tenemos registros suficientes y si sabemos interpretarlos.

Ahí entran los logs y la auditoría de seguridad.

1. No puedes proteger lo que no puedes ver
2. Qué es un log y por qué importa en WordPress
3. Las capas de logs en una instalación WordPress
4. Qué deberíamos registrar en WordPress
5. Qué no conviene registrar
6. Dónde guardar los logs
7. Alertas: pocas, claras y útiles
8. Ejemplos prácticos de auditoría
9. Retención, rotación y privacidad
10. Estrategia según el tipo de proyecto
11. Checklist básica de auditoría
12. Lo que no debemos hacer
13. Conclusión

Un log es un registro de eventos. Puede indicar que una URL se ha visitado desde una IP concreta, que un usuario ha iniciado sesión, que un plugin se ha activado, que PHP ha generado un error fatal o que el servidor ha devuelto muchos errores 500 en pocos minutos.

La auditoría es el paso siguiente: no solo guardar información, sino revisarla, relacionarla y usarla para tomar decisiones.

Sin logs, una investigación de seguridad se convierte casi siempre en una reconstrucción incompleta. Si aparece un usuario administrador desconocido, necesitamos saber cuándo se creó, desde qué IP, con qué cuenta previa y qué ocurrió justo antes y después. Si aparece un archivo PHP sospechoso dentro de wp-content/uploads, necesitamos saber cuándo se subió, qué petición lo generó y si se ejecutó posteriormente. Si una web empieza a redirigir tráfico hacia páginas de spam, necesitamos saber qué archivos han cambiado, qué plugins se han activado y qué accesos se han producido en los últimos días.

Sin esa información, solo podemos hacer suposiciones. Y en seguridad, las suposiciones son peligrosas.

También ocurre lo contrario: hay webs que guardan demasiada información, pero no tienen una estrategia clara. Logs enormes que nadie revisa, alertas que llegan constantemente y se acaban ignorando, archivos de depuración expuestos públicamente, registros llenos de datos personales innecesarios o sistemas que guardan información sensible sin control.

Registrar todo no es necesariamente una buena práctica. Registrar bien sí lo es.

El objetivo no debería ser acumular datos sin criterio, sino tener la información suficiente para detectar problemas, investigarlos y responder con rapidez. Una estrategia útil de logs debe ayudarnos a contestar preguntas muy concretas:

• Qué ha pasado.
• Cuándo ha pasado.
• Desde dónde ha pasado.
• Qué usuario o proceso estaba implicado.
• Qué otros eventos ocurrieron alrededor.
• Qué impacto ha podido tener.

En artículos anteriores ya hemos tratado la seguridad de WordPress desde distintas capas, como vimos en Seguridad completa en WordPress desde los DNS hasta el navegador: DNS, servidor, navegador, usuarios, permisos, WP-CLI, errores habituales y limpieza después de una infección. Los logs conectan con todas esas áreas porque funcionan como hilo conductor. Nos ayudan a relacionar una configuración insegura con sus consecuencias, un error de permisos con un archivo modificado o una mala política de usuarios con un acceso indebido.

No se trata de vivir mirando logs todo el día. Se trata de tener visibilidad suficiente para no trabajar a ciegas.

Qué es un log y por qué importa en WordPress

Un log es un registro cronológico de eventos. En una web WordPress, esos eventos pueden venir de muchas capas distintas.

WordPress no vive aislado. Funciona sobre un servidor web, usa PHP, se conecta a una base de datos, ejecuta plugins y temas, recibe tráfico HTTP, programa tareas internas y muchas veces está detrás de servicios como Cloudflare, un CDN, un balanceador o un firewall externo.

Cada una de esas capas puede registrar información diferente.

El servidor web puede decirnos qué peticiones han llegado a la web. PHP puede decirnos qué errores se han producido durante la ejecución del código. WordPress puede registrar eventos internos. Un plugin de seguridad puede guardar intentos de acceso, bloqueos o cambios relevantes. La base de datos puede mostrar consultas lentas. Cloudflare puede registrar tráfico bloqueado antes de que llegue al servidor.

Por eso, cuando hablamos de logs de seguridad en WordPress, no deberíamos pensar únicamente en instalar un plugin y mirar su panel de vez en cuando. Eso puede ayudar, pero normalmente solo nos dará una parte del contexto.

Un incidente de seguridad rara vez se entiende mirando una única fuente.

Si un atacante intenta acceder por fuerza bruta, quizá lo veamos en el registro de accesos del servidor, en el plugin de seguridad y en el sistema de rate limiting. Si una vulnerabilidad permite subir un archivo malicioso, puede quedar rastro en el access log, en la fecha de modificación del archivo, en los registros de PHP y quizá en el historial de actividad de WordPress. Como vimos en Amenazas de seguridad en WordPress: Detección, limpieza y prevención, detectar estas señales a tiempo es clave para investigar el alcance real del incidente y no quedarse solo en eliminar lo visible. Si un administrador legítimo activa un plugin vulnerable sin darse cuenta, el evento puede aparecer en un registro de actividad interno, pero no necesariamente parecerá sospechoso en los logs del servidor.

Los logs importan porque nos ayudan a pasar de la sospecha al dato.

No es lo mismo decir «parece que alguien ha entrado» que poder ver una serie de eventos concretos: un inicio de sesión desde una IP no habitual, una creación de usuario, un cambio de rol, la activación de un plugin y varias peticiones posteriores a archivos recién modificados.

Tampoco es lo mismo decir «la web se cayó» que poder comprobar que, justo antes de la caída, hubo miles de peticiones a xmlrpc.php, un pico de errores 500 y varios procesos PHP saturados.

La diferencia entre una intuición y una investigación útil suele estar en los logs.

También hay que tener en cuenta que no todo lo raro es un ataque. Cualquier web pública recibe tráfico automatizado todos los días: bots que buscan rutas genéricas, crawlers agresivos, peticiones mal formadas, intentos de acceder a archivos .env, búsquedas de copias de seguridad expuestas y escaneos de plugins vulnerables que ni siquiera tienen por qué estar instalados.

Una parte importante de la auditoría consiste precisamente en separar lo normal, lo sospechoso y lo crítico. Si todo nos parece grave, acabaremos ignorándolo todo. Si nada nos parece grave, detectaremos tarde los problemas reales.

Las capas de logs en una instalación WordPress

Para monitorizar bien una instalación WordPress conviene entender qué puede aportar cada capa. No todas serán igual de accesibles en todos los hostings, pero es importante saber dónde mirar.

Logs del servidor web

Los logs del servidor web son una de las fuentes más importantes. Dependiendo del entorno, podemos estar hablando de Apache, Nginx, LiteSpeed u OpenLiteSpeed. Normalmente encontraremos dos tipos principales: access logs y error logs.

El access log registra las peticiones que llegan al servidor. Puede incluir la IP, la fecha, el método HTTP, la URL solicitada, el código de respuesta, el tamaño de la respuesta, el referente y el User-Agent.

Este log es especialmente útil para detectar patrones de tráfico sospechosos. Por ejemplo, muchas peticiones seguidas a wp-login.php pueden indicar un intento de fuerza bruta. Muchas peticiones a xmlrpc.php pueden indicar abuso de XML-RPC. Peticiones a rutas como /.env, /wp-config.php.bak, /backup.zip o /database.sql suelen indicar escaneos automatizados buscando archivos sensibles expuestos.

El error log del servidor, en cambio, nos ayuda a detectar errores de permisos, problemas con reglas de reescritura, archivos no accesibles, errores internos o conflictos entre configuración y aplicación.

Logs de PHP y WordPress

WordPress está escrito en PHP, así que los logs de PHP también son fundamentales. Aquí encontraremos errores fatales, warnings, notices, avisos de código obsoleto y, en algunos entornos, información sobre procesos lentos.

No todos los errores PHP son problemas de seguridad. Muchos son simples bugs, incompatibilidades entre plugins, código antiguo o avisos provocados por una actualización de PHP. Pero algunos errores repetidos pueden ser una pista. Errores relacionados con archivos inexistentes, parámetros inesperados, funciones deshabilitadas o rutas extrañas pueden ayudar a entender qué estaba ocurriendo antes de una caída o de una infección.

En producción, los errores PHP no deberían mostrarse en pantalla. Mostrar errores al visitante puede revelar rutas internas, nombres de archivos, estructura del servidor o detalles de plugins instalados. Lo correcto es registrar los errores en un archivo privado y revisar ese archivo cuando sea necesario.

En WordPress también podemos activar el registro de depuración mediante WP_DEBUG_LOG. Es útil en desarrollo, staging o investigaciones puntuales, pero no debería dejarse activado sin control en producción. Además, si el archivo debug.log queda accesible públicamente, puede convertirse en una fuga de información.

Una configuración habitual para registrar errores sin mostrarlos en pantalla sería:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Si se usa en producción, conviene hacerlo durante el tiempo necesario, proteger el archivo generado y desactivarlo cuando ya no haga falta.

Logs de base de datos

La base de datos también puede aportar información útil, sobre todo en problemas de rendimiento o investigaciones más avanzadas.

El slow query log de MySQL o MariaDB permite detectar consultas lentas. No siempre tiene una relación directa con seguridad, pero puede ayudar a encontrar comportamientos anómalos: consultas muy pesadas, procesos repetidos, plugins que generan carga excesiva o situaciones en las que una web parece atacada, pero en realidad está sufriendo por una mala consulta.

También hay tablas de WordPress que merecen especial atención durante una auditoría: wp_users, wp_usermeta, wp_options, tablas de plugins de seguridad, tablas de tareas programadas y cualquier tabla donde se almacenen configuraciones críticas.

Eso no significa que debamos tocar la base de datos sin cuidado. En una investigación, primero se observa, se exporta información si hace falta y se documenta. Borrar registros sin saber qué son puede eliminar evidencias útiles.

Logs externos

Si la web está detrás de Cloudflare, otro CDN o un WAF externo, parte de la información relevante puede no estar en el servidor.

Esto es importante: si Cloudflare bloquea una petición, esa petición puede no llegar nunca a WordPress. Por tanto, no aparecerá en los logs internos de WordPress ni necesariamente en los logs del servidor. Para entender qué ha ocurrido, tendremos que revisar también el panel del servicio externo.

Estos servicios pueden mostrar intentos bloqueados, reglas activadas, países de origen, IP sospechosas, URL atacadas, tráfico automatizado o picos de peticiones. En proyectos sensibles, estos logs externos son muy útiles porque permiten detectar actividad maliciosa antes de que llegue a la aplicación.

Qué deberíamos registrar en WordPress

No todas las acciones tienen la misma importancia. Un buen sistema de auditoría debe centrarse en los eventos que realmente ayudan a detectar cambios relevantes, accesos sospechosos o señales tempranas de compromiso.

Accesos y autenticación

Los accesos son una de las primeras áreas que deberíamos vigilar.

Conviene registrar inicios de sesión correctos, intentos fallidos, cambios de contraseña, restablecimientos de contraseña, cambios de correo electrónico y accesos de usuarios con permisos elevados.

Un login correcto no siempre es una buena noticia. Si se produce desde una ubicación no habitual, a una hora extraña, con un usuario administrador que llevaba meses sin acceder o justo antes de cambios sensibles, puede ser una señal importante.

También conviene prestar atención a los intentos fallidos. Unos pocos fallos son normales. Cientos o miles de intentos en poco tiempo indican intentos mediante fuerza bruta, credential stuffing o automatización.

Usuarios, roles y permisos

Los cambios en usuarios y roles son críticos. Para profundizar en esta parte, puedes revisar Gestión avanzada de usuarios, roles y permisos en WordPress, donde vimos por qué no todos los usuarios deberían tener los mismos permisos ni conservar accesos que ya no se necesitan.

Deberíamos registrar la creación de usuarios nuevos, la eliminación de usuarios, los cambios de rol, los cambios de capacidades, la creación de nuevos administradores y las modificaciones en perfiles de usuarios con permisos altos.

Tras un incidente, una de las primeras comprobaciones suele ser revisar usuarios administradores. Un atacante que consigue acceso puede crear una cuenta persistente para volver más tarde, aunque eliminemos el malware visible. Para ampliar esta parte con más ejemplos prácticos, puedes revisar Uso de WP-CLI para comprobar y mejorar la seguridad de nuestro WordPress.

Con WP-CLI podemos hacer una comprobación rápida:

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

En una web sana, todos los usuarios administradores deberían ser reconocibles, estar justificados y tener una dirección de correo coherente.

Plugins y temas

Los plugins y temas son otra zona clave. Deberíamos registrar instalaciones, activaciones, desactivaciones, eliminaciones y actualizaciones.

Un plugin activado sin control puede introducir una vulnerabilidad, cambiar el comportamiento de la web o añadir carga innecesaria. Un tema inactivo abandonado puede convertirse en superficie de ataque. Un cambio en functions.php puede ser una modificación legítima o una puerta trasera.

También conviene revisar plugins desconocidos, plugins con nombres sospechosos, extensiones nulled, plugins abandonados y cualquier elemento que no forme parte del flujo normal de mantenimiento.

WP-CLI puede ayudarnos a revisar plugins activos:

wp plugin list --status=active

Y también a comprobar temas instalados:

wp theme list

Estos comandos no sustituyen a una auditoría completa, pero permiten obtener una primera fotografía rápida.

Archivos modificados

Los cambios en archivos son especialmente importantes en investigaciones de seguridad. Deberíamos prestar atención a archivos nuevos, modificados o eliminados, especialmente si están en rutas sensibles.

Una señal clásica es encontrar archivos PHP dentro de wp-content/uploads. En una instalación normal, el directorio de subidas debería contener imágenes, documentos, vídeos u otros archivos estáticos, pero no PHP ejecutable.

Podemos buscar archivos PHP dentro de uploads con:

find wp-content/uploads -type f -name "*.php"

Si aparece algún resultado, no conviene borrarlo sin mirar. Primero hay que revisar la fecha, el propietario, el contenido y el contexto. Puede ser malware, una mala práctica de un plugin o un archivo residual, pero en cualquier caso merece revisión.

También es recomendable comprobar la integridad del core de WordPress:

wp core verify-checksums

Este comando compara los archivos principales de WordPress con los checksums oficiales de la versión instalada. No revisa plugins ni temas, pero ayuda a detectar modificaciones en el core.

Contenido y configuración

La auditoría no debería limitarse a archivos y usuarios. También conviene registrar cambios en contenido y configuración.

Un atacante no siempre busca romper la web. A veces busca modificar enlaces, insertar scripts, añadir spam SEO, cambiar redirecciones, alterar widgets, tocar menús o modificar opciones de plugins.

Por eso tiene sentido registrar cambios en páginas críticas, opciones generales, enlaces permanentes, ajustes de registro de usuarios, configuración de plugins sensibles, menús, widgets y cualquier zona donde pueda introducirse código o enlaces.

En webs editoriales, tiendas online o sitios con muchos usuarios internos, esta parte puede ser especialmente importante. No todos los incidentes son técnicos. Algunos vienen de cuentas legítimas comprometidas o de permisos demasiado amplios.

Qué no conviene registrar

Registrar más no siempre es mejor. Un sistema de logs mal planteado puede convertirse en un problema de privacidad, rendimiento o seguridad.

Hay datos que no deberíamos registrar salvo que exista una razón muy clara y una protección adecuada. Entre ellos están contraseñas, claves API, tokens privados, cookies completas, datos de tarjetas, documentos personales, datos de salud, formularios completos con información sensible o cualquier dato personal que no sea necesario para la finalidad de seguridad.

También conviene evitar logs excesivamente detallados. Registrar cada pequeño evento puede parecer buena idea al principio, pero si el volumen es excesivo, nadie revisará nada. Además, puede aumentar el tamaño de la base de datos, llenar el disco o dificultar la búsqueda de señales importantes.

La regla práctica es sencilla: registrar lo necesario para detectar, investigar y responder, pero no más de lo necesario.

En proyectos sujetos a obligaciones legales o contractuales, hay que cuidar especialmente la retención y el acceso a los logs. Una IP puede considerarse dato personal en determinados contextos. Si guardamos logs durante meses o años, deberíamos poder justificar para qué, quién tiene acceso y cómo se protegen.

Dónde guardar los logs

Guardar logs en el propio servidor es lo más habitual y lo más sencillo. Tiene ventajas claras: es rápido, no requiere servicios externos y suele estar disponible en casi cualquier hosting. Pero también tiene limitaciones.

Si el servidor cae, podemos perder acceso a los logs. Si el disco se llena, la web puede tener problemas. Si un atacante obtiene acceso suficiente, puede borrar o modificar evidencias. Y si no hay rotación, los archivos pueden crecer sin control.

Por eso es importante configurar rotación de logs, limitar permisos y evitar que los registros queden dentro de rutas públicas.

En muchos hostings gestionados, los logs se consultan desde el panel. Es cómodo, pero suele haber retención limitada y poca flexibilidad. Puede ser suficiente para una web pequeña, pero corto para una investigación compleja.

En proyectos más críticos puede tener sentido enviar logs a un sistema externo. Esto facilita búsquedas, alertas, conservación y análisis. También dificulta que un atacante borre todas las huellas si se compromete el servidor. El inconveniente es que añade coste, configuración y responsabilidad sobre los datos enviados.

Los plugins de auditoría guardan normalmente información dentro de WordPress, muchas veces en la propia base de datos. Son cómodos porque muestran los eventos dentro del panel, con contexto de usuario y acciones internas. Pero no deberían ser la única fuente. Si WordPress falla, si la base de datos está dañada o si el atacante tiene control suficiente, esos logs pueden no ser fiables.

Alertas: pocas, claras y útiles

Una alerta solo es útil si alguien la atiende. Si un sistema envía cientos de avisos al día, lo normal es que acaben ignorándose.

Por eso conviene diferenciar entre eventos informativos y eventos críticos. No todo debe generar una notificación inmediata. Algunos eventos pueden registrarse para revisión posterior. Otros sí deberían avisarnos en el momento.

Merece la pena generar alertas para eventos como estos:

• Creación de un nuevo usuario administrador.
• Cambio de rol a administrador.
• Activación o instalación de un plugin.
• Modificación de archivos críticos.
• Detección de archivos PHP en uploads.
• Muchos intentos fallidos de login en poco tiempo.
• Pico de errores 500.
• Caída de la web.
• Cambios en wp-config.php.
• Desactivación de un plugin de seguridad.

En cambio, alertar por cada login correcto, cada 404 o cada visita bloqueada por un bot suele generar demasiado ruido. Es mejor registrar esos eventos y consultarlos cuando haga falta, pero no convertirlos todos en urgencias.

El canal también importa. El correo puede ser suficiente para eventos de prioridad media. Para eventos críticos, puede ser más útil Slack, Telegram, un webhook o el sistema interno de incidencias del equipo.

La clave es que la alerta tenga contexto. No basta con decir «se ha producido un evento». Debería indicar qué ha pasado, cuándo, en qué web, qué usuario está implicado y qué acción conviene revisar.

Ejemplos prácticos de auditoría

Los logs tienen más sentido cuando los aplicamos a casos reales. Estos son algunos escenarios habituales en WordPress.

Intentos de fuerza bruta contra wp-login.php

Una de las señales más comunes es encontrar muchas peticiones a wp-login.php, especialmente mediante POST.

Un ejemplo sencillo de búsqueda en un access log podría ser:

grep "POST /wp-login.php" access.log

Si aparecen miles de líneas en pocos minutos, probablemente hay un intento automatizado. En ese caso conviene revisar IP de origen, códigos de respuesta, frecuencia y si algún intento terminó en acceso correcto.

Las respuestas pueden ser varias: activar doble factor de autenticación, limitar intentos, aplicar rate limiting, proteger el login desde el WAF o revisar si hay usuarios con contraseñas débiles.

Abuso de xmlrpc.php

Los accesos a xmlrpc.php⁣ pueden ser legítimos en algunos casos, pero también se han usado mucho para ataques de fuerza bruta y amplificación de peticiones.

Podemos revisar su actividad con:

grep "xmlrpc.php" access.log

Si hay muchas peticiones y no usamos ninguna funcionalidad que dependa de XML-RPC, podemos valorar bloquearlo o limitarlo. Si hay dependencias, conviene actuar con más cuidado para no romper integraciones legítimas.

Usuarios administradores sospechosos

Si aparece un administrador desconocido, hay que tratarlo como una señal crítica hasta demostrar lo contrario.

Primero podemos listar administradores:

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

Después conviene revisar cuándo se creó, si hay logs de actividad asociados, desde qué IP se accedió, si cambió opciones, si instaló plugins o si modificó archivos.

No basta con borrar ese usuario. Hay que entender cómo llegó ahí.

Archivos PHP en uploads

Encontrar PHP dentro de uploads es una señal que siempre merece revisión:

find wp-content/uploads -type f -name "*.php"

Si hay resultados, hay que revisar contenido, fecha de modificación y permisos. También conviene comprobar si esos archivos han recibido peticiones desde el access log.

En muchos casos, una medida preventiva recomendable es impedir la ejecución de PHP dentro de uploads desde la configuración del servidor. Así, aunque un archivo malicioso llegue a subirse, no podrá ejecutarse directamente desde el navegador.

Picos de errores 500

Un pico de errores 500 puede tener muchas causas: una actualización defectuosa, falta de memoria, un plugin incompatible, una consulta pesada, saturación de PHP workers o tráfico malicioso.

La investigación debería cruzar varias fuentes: access log, error log del servidor, log de PHP, cambios recientes en plugins y métricas de recursos.

Si todos los errores coinciden con una misma URL o una misma acción, podemos acotar rápido. Si coinciden con un pico de tráfico o con muchas peticiones automatizadas, quizá estemos ante abuso externo. Si empiezan justo después de una actualización, probablemente el origen sea interno.

Retención, rotación y privacidad

Los logs tienen valor durante un tiempo, pero no deberían guardarse indefinidamente sin criterio.

En una web pequeña, quizá baste con conservar access logs durante unas semanas y logs de auditoría durante algo más de tiempo. En un WooCommerce, una membresía o un proyecto crítico, puede tener sentido conservar determinados eventos durante varios meses, siempre con una política clara.

La rotación es fundamental. Los logs deben comprimirse, archivarse o eliminarse según una frecuencia definida. Si no se rotan, pueden llenar el disco. Y un disco lleno puede provocar caídas, errores de escritura, fallos de sesiones, problemas de caché o corrupción de datos.

También hay que controlar quién puede acceder a los logs. Un log puede contener IP, rutas internas, nombres de usuario, correos electrónicos, errores con información sensible o detalles de infraestructura. No deberían estar disponibles para cualquier usuario ni quedar dentro de directorios públicos.

Si se exportan logs a servicios externos, hay que revisar qué datos se envían, dónde se almacenan y durante cuánto tiempo.

Estrategia según el tipo de proyecto

No todas las webs necesitan el mismo nivel de monitorización.

Una web corporativa pequeña puede funcionar bien con logs del hosting, un plugin ligero de actividad, alertas para eventos críticos y una revisión mensual.

Una web profesional con tráfico medio debería tener acceso a logs del servidor, auditoría de usuarios, revisión periódica de plugins y temas, monitorización del tiempo de disponibilidad, alertas críticas y alguna comprobación mediante WP-CLI.

Un WooCommerce o una membresía necesitan más control. Además de usuarios y accesos, conviene vigilar errores del proceso de pago, cambios en plugins de pago, modificaciones de roles, acciones programadas fallidas, rendimiento de la base de datos y disponibilidad del sitio.

Un multisitio o un proyecto con muchos administradores requiere todavía más disciplina: control de superadministradores, revisión de cuentas inactivas, registro detallado de cambios y política clara de permisos.

La estrategia debe adaptarse al riesgo. No tiene sentido montar una infraestructura compleja para una web sencilla, pero tampoco es razonable gestionar una tienda importante sin saber quién entra, qué cambia y cuándo falla.

Checklist básica de auditoría

Una revisión periódica puede incluir estas comprobaciones:

• Revisar usuarios administradores.
• Revisar usuarios inactivos con permisos altos.
• Comprobar plugins activos e inactivos.
• Revisar temas instalados.
• Verificar actualizaciones pendientes.
• Comprobar la integridad del core con WP-CLI.
• Buscar archivos PHP dentro de uploads.
• Revisar peticiones repetidas a wp-login.php.
• Revisar actividad de xmlrpc.php.
• Revisar errores 500.
• Revisar errores PHP recientes.
• Comprobar tareas cron.
• Revisar cambios en opciones críticas.
• Comprobar que debug.log no es público.
• Revisar alertas configuradas.
• Comprobar rotación de logs.
• Verificar que existen copias de seguridad recientes.

Esta lista no sustituye a una auditoría avanzada, pero ayuda a detectar muchos problemas habituales antes de que se conviertan en incidentes graves.

Lo que no debemos hacer

Uno de los errores más frecuentes es no registrar nada hasta que ocurre un problema. En ese momento ya es tarde para reconstruir lo que no se ha guardado.

Otro error habitual es activar WP_DEBUG_LOG en producción y olvidarse de él. Puede ser útil durante una investigación, pero si queda expuesto o crece sin control, se convierte en un riesgo.

También es frecuente confiar únicamente en un plugin de seguridad. Los plugins ayudan, pero no lo ven todo. Una auditoría razonable debería combinar logs internos, logs del servidor y, cuando proceda, información del WAF o CDN.

Otro problema habitual es no tener clara la hora de los eventos. Si el servidor, WordPress y los servicios externos usan zonas horarias diferentes, reconstruir una línea temporal puede ser confuso. En una investigación, la hora exacta importa.

También conviene evitar borrar evidencias demasiado pronto. Si encontramos malware, usuarios sospechosos o archivos modificados, la primera reacción suele ser eliminarlo todo. Pero antes de borrar, conviene guardar muestras, fechas, rutas y contexto. Eso puede ser clave para entender la entrada y evitar que se repita.

Conclusión

Los logs no hacen que una web WordPress sea segura por sí solos. No sustituyen a las actualizaciones, a las copias de seguridad, a una buena política de usuarios, al doble factor de autenticación ni a una configuración correcta del servidor.

Pero sin logs, cualquier investigación de seguridad queda incompleta.

Una buena estrategia de auditoría permite detectar señales tempranas, entender qué ha ocurrido, responder con más precisión y reducir el tiempo necesario para resolver un incidente. También ayuda a encontrar problemas de rendimiento, errores de configuración, plugins conflictivos o comportamientos anómalos que podrían pasar desapercibidos.

La clave no está en registrarlo todo, sino en registrar lo importante: accesos, usuarios, roles, plugins, temas, archivos, errores críticos, peticiones sospechosas y cambios relevantes de configuración.

También es importante guardar esos registros de forma segura, rotarlos, limitar el acceso y configurar alertas útiles. Pocas alertas, pero bien elegidas, suelen ser más eficaces que un sistema que avisa de todo y acaba siendo ignorado.

En seguridad, detectar pronto marca la diferencia. Y para detectar pronto, primero hay que poder ver qué está pasando.