Leer los logs de tu web: detectar lo que no encaja

Los logs de tu web son la grabación de todo lo que pasa en ella: quién entra, qué pide, qué falla y desde dónde. Cuando algo va raro (la web va lenta, sospechas de un ataque, quieres saber si alguien está tocando cosas) ahí está la respuesta, línea por línea. El problema es que parecen un muro de texto indescifrable. Este artículo te enseña dónde encontrarlos, cómo leer una línea campo a campo, qué ruido es normal ignorar y qué patrones concretos deberían encender una alarma, aunque no sepas programar.

Qué logs tienes y dónde están: acceso, errores, correo y WordPress

No hay un solo log, hay varios, y cada uno cuenta una parte de la historia:

Log de acceso (access log): registra cada petición que llega a tu web. Cada imagen, cada página, cada intento de entrar. Es el más útil para detectar ataques.
Log de errores (error log): apunta lo que falla. Errores de PHP, páginas que revientan, permisos denegados. Aquí aparecen las pistas cuando la web da un error 500.
Log de correo: si tu servidor envía email, registra cada envío. Es donde se ve si tu web está mandando spam sin que lo sepas.
Registros de WordPress: WordPress no guarda logs de acceso por sí mismo, pero puedes activar un debug log o instalar un plugin de registro de actividad que apunte quién inicia sesión, quién cambia qué y desde qué IP.

¿Dónde están? Si tienes un panel tipo cPanel, busca las secciones Métricas o Raw Access (acceso sin procesar) para descargar el log de acceso, y Errores para ver el de errores. Si tienes acceso por SSH, en servidores habituales están en rutas como /var/log/apache2/access.log y /var/log/apache2/error.log (o nginx en lugar de apache2). Y en muchos hostings hay un archivo access-logs directamente en la carpeta de tu cuenta. Si no lo encuentras, tu proveedor de hosting te dirá exactamente dónde está el tuyo.

Cómo se lee una línea de access log, campo a campo

Una línea de log de acceso asusta al principio, pero tiene una estructura fija. Esta es una línea real, desmontada:

203.0.113.45 - - [04/Sep/2026:11:20:33 +0200] "GET /tienda/producto-1 HTTP/1.1" 200 5312 "https://google.com" "Mozilla/5.0..."

De izquierda a derecha, lo que significa cada trozo:

203.0.113.45 es la dirección IP de quien hace la petición. El de dónde.
[04/Sep/2026:11:20:33 +0200] es la fecha y hora exactas, con la zona horaria.
GET /tienda/producto-1 es qué está pidiendo: el método (GET para leer, POST para enviar datos) y la dirección concreta.
200 es el código de respuesta: qué le contestó tu servidor. El más importante de toda la línea.
5312 es el tamaño en bytes de lo que se envió.
Lo último entre comillas es de dónde venía (el referer) y con qué navegador o programa (el user agent).

El código de respuesta es donde tienes que fijar la vista. 200 significa «todo bien, aquí tienes lo que pediste». 301/302 es una redirección. 404 es «esto no existe». 403 es «no tienes permiso». 500 es «algo se ha roto en el servidor». Con solo entender estos cinco números ya puedes leer un log.

Lo que es normal: bots, escáneres y ruido de fondo

Antes de asustarte, hay que asumir una cosa: internet es ruidoso, y tu web recibe basura constantemente sin que eso signifique nada. Es completamente normal ver en tus logs:

Bots de buscadores (Google, Bing) rastreando tus páginas. Su user agent lo dice claramente.
Escáneres automáticos probando direcciones que no existen en tu web: /wp-admin aunque no uses WordPress, /.env, /phpmyadmin, /wp-login.php. Son programas que barren internet entero buscando webs mal configuradas. Que lo intenten es normal; lo que importa es que reciban un 404 o un 403.
Peticiones a archivos que no tienes, con respuestas 404. Mientras sea 404, significa que no lo han encontrado. No es un problema.

La regla mental es sencilla: un intento fallido (404, 403) es ruido de fondo; molesto, pero inofensivo. Lo preocupante es cuando esos intentos tienen éxito.

Lo que no es normal: POST a ficheros raros, 200 donde debería haber 404

Aquí es donde el log se convierte en una herramienta de detección. Estos son los patrones que deberían encender la alarma:

Un 200 donde esperarías un 404. Si ves peticiones exitosas (código 200) a archivos con nombres raros que tú no has creado, como /wp-content/uploads/2026/09/xz.php o /imagenes/logo.php, malo. Un archivo PHP dentro de la carpeta de subidas (uploads), respondiendo 200, es casi siempre una puerta trasera funcionando. Ese es exactamente el tipo de fichero que hay que buscar como puerta trasera en la web.
Peticiones POST repetidas a un mismo archivo desde la misma IP. Un POST envía datos al servidor. Si una IP hace decenas de POST seguidos a /wp-login.php, está probando contraseñas (fuerza bruta). Si los hace a un archivo raro que respondió 200, probablemente está manejando una puerta trasera ya instalada.
Muchos 404 seguidos desde una IP, y de repente un 200. Es el patrón de un atacante buscando una vulnerabilidad a ciegas hasta que da con una que funciona. El salto de una ristra de 404 a un 200 marca el momento en que encontró algo.
Códigos 500 que aparecen justo después de una petición sospechosa. A veces el atacante rompe algo al intentar explotarlo. Si ves un error 500 que no sabes si es del hosting o un ataque, mira qué petición lo provocó en la línea anterior.
User agents vacíos o absurdos. Un navegador real siempre se identifica. Peticiones con el user agent en blanco, o con nombres de herramientas de ataque, son señal de tráfico automatizado hostil.

Buscar en el log sin saber programar

No hace falta leer miles de líneas a mano. Si descargas el log de acceso desde cPanel, lo abres con cualquier editor de texto y usas buscar (Ctrl+F) sobre lo que te interese: busca POST, busca .php, busca una IP concreta, busca wp-login. Con eso filtras el 90% del ruido.

Si tienes acceso por SSH, el comando grep hace lo mismo pero más rápido. Un par de ejemplos que puedes copiar tal cual, cambiando el nombre del archivo por el tuyo:

grep "POST" access.log

Te muestra todas las peticiones POST. Para ver solo las que van a archivos PHP dentro de uploads (el patrón de puerta trasera):

grep "POST" access.log | grep "uploads"

Y para ver toda la actividad de una IP que te resulte sospechosa:

grep "203.0.113.45" access.log

Un truco más, útil cuando quieres saber si una IP está insistiendo mucho: añadir | wc -l al final cuenta las veces que aparece. Por ejemplo, grep "203.0.113.45" access.log | wc -l te dice de un vistazo si esa dirección hizo tres peticiones o tres mil. Un número muy alto desde una sola IP en poco tiempo es, por sí mismo, una señal de que algo automatizado está trabajando contra tu web.

No necesitas entender de programación para usar esto: es buscar texto dentro de un archivo. La clave no está en el comando, sino en saber qué buscar, y eso es lo que acabas de aprender en el apartado anterior. Y un consejo de método: cuando encuentres una petición sospechosa en el log de acceso, mira el log de errores a esa misma hora. Muchas veces el intento de ataque deja también un rastro ahí (un error de PHP, un permiso denegado) que confirma qué estaba intentando hacer. Cruzar los dos registros por la marca de tiempo es la forma más rápida de pasar de «esto me da mala espina» a «esto es lo que pasó».

Cuánto tiempo se guardan y por qué eso importa después de un incidente

Aquí hay un detalle que mucha gente descubre demasiado tarde: los logs no se guardan para siempre. Muchos hostings compartidos conservan solo unos días de log de acceso, o los rotan (borran los viejos al llegar a cierto tamaño) sin avisar. Cuando te das cuenta de que te han hackeado, puede que las pruebas de cómo entraron ya se hayan borrado.

Por eso, dos recomendaciones. Primera: comprueba en tu panel cuánto tiempo guarda los logs tu hosting, y si puedes, súbelo o configura que se archiven. Segunda, y más importante: si sospechas de un incidente, lo primero es descargar y guardar los logs antes de hacer nada más. Cópialos a tu ordenador tal cual. Si luego limpias la web, restauras una copia o el hosting rota los registros, esas líneas ya no vuelven, y son justo lo que permite entender qué pasó y cerrar la puerta por la que entraron. Guardar bien esas pruebas es parte de saber tener el hosting configurado con cabeza.

Cuándo dejar de mirar y llamar a alguien

Leer los logs para entender qué está pasando es algo que puedes y debes hacer tú: te da contexto, te tranquiliza cuando solo es ruido y te permite explicar bien el problema si tienes que pedir ayuda. Hasta ahí, no necesitas a nadie.

Hay un punto, sin embargo, en el que conviene parar. Si en los logs ves señales claras de que entraron (un archivo PHP sospechoso respondiendo 200, POST a puertas traseras, un acceso administrador que no reconoces) y encima hay datos de clientes o pagos de por medio, seguir hurgando por tu cuenta puede borrar rastros importantes y complicar la limpieza. Ahí el orden correcto es: guardar los logs, no tocar nada más y buscar ayuda.

Si en tu log hay líneas que no sabes explicar y quieres una respuesta clara sobre qué pasó y por dónde entraron, un analista puede seguir el rastro a partir de esos registros y decirte con pruebas qué ocurrió, hasta dónde llegaron y qué hay que cerrar para que no vuelva a pasar.

Seguir leyendo en esta sección

Ver todo en Accesos y contraseñas → · Mapa completo del sitio