# Analizar los registros del servidor web tras un ataque: cómo leer bien el access log

> Analizar el access log tras un ataque: conservar primero los registros, hallar rastros típicos, comandos para Apache y Nginx y claves sobre PHP2Shell.

Fuente: https://phpsos.de/es/ratgeber/logfiles-auswerten/  
Actualizado: 25/10/2026  
Proveedor: PHP SOS, Ayuda de emergencia para PHP y seguridad de servidores. Ayuda inmediata por WhatsApp: https://wa.me/491736494914?text=Hola%20PHP%20SOS%2C%20necesitamos%20ayuda%20con%20nuestro%20servidor%20PHP.%20Empresa%3A%20%E2%80%A6%20Sitio%20web%3A%20%E2%80%A6

**En resumen:** quien quiera analizar el access log tras un ataque conserva primero los registros sin modificarlos y trabaja después solo con copias. Se buscan peticiones con estado 200 a archivos PHP desconocidos, peticiones POST llamativas, accesos a directorios de subidas y patrones temporales. Para PHP2Shell no hay Indicators of Compromise confirmados y publicados, por eso cuenta la imagen de conjunto de varias fuentes de registro.

## Primero conservar, después analizar

En la mayoría de los servidores, los archivos de registro se rotan automáticamente y se eliminan pasado un tiempo fijo. Tras un ataque, el primer paso es, por tanto, conservar los registros existentes antes de que desaparezcan. Eso vale también si aún no está seguro de que haya pasado algo. Sobre PHP2Shell, la prensa especializada recomienda conservar los registros desde el 20/10/2026.

```bash
# Copiar los registros con marcas de tiempo y guardar las sumas de comprobación
ZIEL=/root/sicherung-logs-$(date +%F)
mkdir -p "$ZIEL"
cp -a /var/log/nginx /var/log/apache2 /var/log/php* "$ZIEL"/ 2>/dev/null
cp -a /var/log/auth.log* /var/log/syslog* "$ZIEL"/ 2>/dev/null
find "$ZIEL" -type f -exec sha256sum {} + > "$ZIEL.sha256"
```

Guarde además la copia en otro sistema. De lo contrario, un atacante con acceso al servidor podría modificar los registros a posteriori. Las sumas de comprobación demuestran más adelante que la copia no se ha alterado. Si hace falta una conservación con validez judicial, por ejemplo para una denuncia o para el seguro, debería asumirla un [análisis forense informático](https://phpsos.de/es/leistungen/it-forensik/).

> **Importante:**
> Compruebe la rotación de registros (`/etc/logrotate.d/`) y amplíe temporalmente la retención, para que no se eliminen más archivos durante el análisis.

## Dónde están los registros y cómo es una línea

Las ubicaciones dependen de la distribución y de la interfaz de administración. Rutas típicas:

| Sistema | Registro de acceso y de errores |
|---|---|
| Debian, Ubuntu con Apache | `/var/log/apache2/` |
| RHEL, AlmaLinux, Rocky con Apache | `/var/log/httpd/` |
| Nginx | `/var/log/nginx/` |
| Plesk | `/var/www/vhosts/system/<domain>/logs/` |
| PHP-FPM | `/var/log/php*-fpm.log` o en el journal |

En el formato Combined, muy extendido, cada línea contiene la dirección del cliente, la fecha y la hora, el método y la ruta de la petición, el código de estado, el tamaño de la respuesta en bytes, el referer y el user agent. Preste atención a la zona horaria de la marca de tiempo, sobre todo si contrasta registros con avisos en UTC. Los parches de PHP2Shell, por ejemplo, se publicaron el 21/10/2026 a las 14:00 UTC, es decir, a las 16:00 hora alemana.

Si su sitio web está detrás de un proxy, CDN o balanceador de carga, en el registro puede figurar solo la dirección de ese servicio. La dirección real del visitante se encuentra entonces en un campo propio o en los registros del servicio antepuesto.

### Sin línea de comandos: registros en el panel o en el hosting

No todos los responsables tienen acceso a la shell. En el hosting compartido o en servidores gestionados, las interfaces de administración suelen ofrecer una vista de registros y la descarga de los registros de acceso y de errores. Descargue los archivos de todo el periodo disponible y guárdelos de forma segura. Pregunte por escrito a su proveedor cuánto tiempo conserva los registros y si se pueden guardar estados más antiguos antes de que caduquen.

Tenga en cuenta aquí la protección de datos: los registros contienen direcciones IP y, a menudo, otros datos personales. Guarde las copias con acceso protegido, facilítelas solo a las personas que las necesiten para el esclarecimiento y establezca cuándo se eliminarán una vez cerrado el incidente.

## Analizar el access log: las consultas más importantes

Los comandos siguientes solo leen y sirven para Nginx y Apache en formato Combined. Los archivos rotados y comprimidos se examinan con `zgrep` o `zcat`.

```bash
LOG=/root/sicherung-logs-2026-10-25/nginx/access.log

# Peticiones exitosas a archivos PHP, por frecuencia
awk '$9 == 200 && $7 ~ /\.php/ {split($7,p,"?"); print p[1]}' "$LOG" | sort | uniq -c | sort -rn | head -40

# Llamadas a PHP en directorios de subidas, caché o imágenes
grep -E '"(GET|POST) /[^ ]*(uploads|cache|images|tmp)/[^ ]*\.php' "$LOG"

# Peticiones POST por destino y dirección
awk '$6 == "\"POST" {print $1, $7}' "$LOG" | sort | uniq -c | sort -rn | head -40

# Errores 5xx por hora: las acumulaciones pueden indicar procesos de PHP que se caen
awk '$9 ~ /^5/ {print substr($4, 2, 14)}' "$LOG" | sort | uniq -c

# Incluir los registros rotados
zgrep -h ' 200 ' /var/log/nginx/access.log.*.gz | grep -c '\.php'
```

En la primera consulta interesan sobre todo los nombres de archivo que no conoce o que no pertenecen a la aplicación. Contraste los archivos sospechosos con el sistema de archivos: ¿cuándo se crearon?, ¿a quién pertenecen?, ¿qué contienen? La guía [Detectar y eliminar webshells](https://phpsos.de/es/ratgeber/webshell-erkennen/) ofrece indicaciones al respecto.

## Particularidades de PHP2Shell

En PHP2Shell, las vulnerabilidades residen en el procesamiento de peticiones del propio PHP. Con mod_php se demostró un exploit antes de que se ejecute siquiera el código de la aplicación. Es decir, puede bastar una petición a una página completamente normal. En el access log, una petición así puede parecer discreta, porque el contenido del cuerpo de la petición no figura allí.

No hay Indicators of Compromise confirmados y publicados. Preste por eso atención al comportamiento y a las relaciones, por ejemplo a partir del 17/10/2026, el primer intento de ataque observado según informes de los medios:

- Acumulaciones de errores 500 o respuestas interrumpidas en páginas corrientes.
- Avisos de memoria agotada o de workers terminados en el registro de errores y en el de PHP-FPM.
- Archivos PHP nuevos o archivos modificados poco después de esas acumulaciones.
- Nuevas tareas cron, procesos o conexiones salientes bajo el usuario del servidor web.

Ninguna de estas señales es por sí sola una prueba. Junto con otros rastros, sin embargo, dan una imagen que responde a la pregunta de si ha habido compromiso o justifica una investigación más profunda. Encontrará una visión de conjunto de los indicios en [¿Ya me han comprometido?](https://phpsos.de/es/php2shell/bin-ich-gehackt-anzeichen/).

## Otras fuentes: registro de errores, PHP-FPM y registros del sistema

El access log muestra solo una parte. Para una imagen completa, recurra a otras fuentes:

```bash
# PHP-FPM y servidor web en el journal desde una fecha
journalctl -u 'php*-fpm*' --since "2026-10-17" --no-pager | tail -200

# Inicios de sesión en el servidor
last -Fa | head -40
grep -E 'Accepted|Failed' /var/log/auth.log | tail -100

# Revisar las tareas programadas de todos los usuarios
for u in $(cut -d: -f1 /etc/passwd); do crontab -l -u "$u" 2>/dev/null | sed "s/^/$u: /"; done
```

Los errores típicos en el análisis son examinar solo el registro actual y no también los rotados, pasar por alto la zona horaria y tomar coincidencias aisladas de escáneres automatizados por un ataque exitoso. Igual de arriesgado es lo contrario: considerar un access log sin anomalías como señal de que no pasa nada, cuando el registro de errores y el sistema de archivos aún no se han revisado.

Anote cada hallazgo con hora, fuente y observación en una línea temporal. Esa línea temporal es después la base para las decisiones, para las notificaciones a autoridades o aseguradoras y para el informe final.

## ¿Cómo ayuda PHP SOS en concreto?

- Conservamos registros y archivos relevantes de modo que sigan siendo trazables para revisiones posteriores.
- Analizamos conjuntamente los registros de acceso, de errores, de PHP y del sistema y elaboramos una línea temporal del incidente.
- Ante indicios de compromiso, asumimos la [respuesta a incidentes](https://phpsos.de/es/leistungen/incident-response/) con contención y limpieza.
- Configuramos la rotación y la retención de registros para que, en el siguiente incidente, estén disponibles los datos necesarios.


## Preguntas frecuentes

**¿Cuánto tiempo debo conservar los registros del servidor web?**  
Tanto como lo permita su concepto de protección de datos y tenga sentido un análisis. Sobre PHP2Shell, la prensa especializada recomienda conservar los registros desde el 20/10/2026. Compruebe la rotación de registros para que los archivos más antiguos no se eliminen automáticamente.

**¿Muestra el access log si un ataque tuvo éxito?**  
No por sí solo. Muestra peticiones, códigos de estado y tamaños de respuesta, pero no qué código se ejecutó en el servidor. Solo junto con el registro de errores, el registro de PHP-FPM, los cambios en los archivos y los registros del sistema se obtiene una imagen fiable.

**¿Puedo facilitar direcciones IP de los registros a terceros?**  
Las direcciones IP se consideran, por lo general, datos personales. Para el esclarecimiento de un incidente y para las denuncias penales existen bases legales, pero la transmisión debería acordarse con el delegado de protección de datos.

**¿Por qué veo muchos ataques en el registro aunque no haya pasado nada?**  
Los servidores públicos son escaneados constantemente de forma automatizada. La mayoría de esas peticiones no llegan a nada y terminan con 404 o 403. Interesan sobre todo las peticiones con estado 200 a archivos desconocidos y los patrones que coinciden en el tiempo con otros rastros.

## Fuentes

- [TechTarget: PHP2Shell, 22M exposed servers at risk](https://www.techtarget.com/cybersecurity/news/366652444/PHP2Shell-22M-exposed-servers-at-risk-as-emergency-patches-released)
- [php.net: avisos de seguridad](https://www.php.net/)
- [BSI IT-Grundschutz (protección básica de TI del BSI)](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)