En resumen: antes de reinstalar un servidor comprometido, asegure las pruebas en el orden de su volatilidad: primero procesos, conexiones y usuarios con sesión iniciada; después logs y configuración; luego una imagen completa del sistema y los datos de los servicios situados por delante. Cada copia recibe una suma de verificación y se guarda fuera del servidor. Para ello, el servidor se desconecta de la red, pero no se apaga.
El reflejo de reinstalar de inmediato
Quien descubre una intrusión quiere acabar con ella cuanto antes. Un sistema nuevo, instalado limpiamente, con contraseñas nuevas: da sensación de control. Técnicamente, reconstruir suele ser además el camino correcto, sobre todo si el atacante tuvo derechos de root.
El problema es el momento. Con el sistema antiguo desaparecen todas las respuestas a las preguntas que llegarán en los días siguientes. ¿Por qué brecha entró el atacante? ¿Desde cuándo estaba en el sistema? ¿Tuvo acceso a datos de clientes? ¿Está afectado también el servidor de base de datos de al lado? Sin rastros solo quedan suposiciones, y estas no ayudan ni con la protección de datos ni con el seguro.
Tras PHP2Shell se añade un punto especial: no hay indicadores de compromiso (IoC) publicados y confirmados. Si un servidor se vio afectado, y cómo, solo puede deducirse del comportamiento, es decir, de los rastros que una reconstrucción precipitada borra. La prensa especializada aconseja conservar los logs del servidor a partir del 20/10/2026.
Conservación de pruebas en el servidor: el orden importa
Los rastros tienen distinta volatilidad. Lo que está en la memoria desaparece con el siguiente reinicio. Los logs duran más, pero se rotan. Los datos de los servicios situados por delante desaparecen según sus propios plazos. De ahí resulta el orden:
| Rastro | Volatilidad | Cómo asegurarlo |
|---|---|---|
| Procesos, conexiones de red, usuarios con sesión iniciada | desaparece al reiniciar | volcar a archivos la salida de los comandos del sistema |
| Memoria | desaparece al reiniciar | solo con herramientas especializadas, tarea para peritos forenses |
Archivos temporales en /tmp o /dev/shm |
a menudo se borran al reiniciar | copiar sin ejecutar |
| Logs del servidor web, de PHP y del sistema | se rotan | copiar por completo, detener la rotación |
| Sistema de archivos y base de datos | estable hasta la reinstalación | instantánea o imagen del disco, exportación de la base de datos |
| CDN, WAF, cortafuegos, hoster | conservación según los plazos del proveedor | solicitar la exportación y pedir confirmación por escrito |
La memoria solo se asegura si hay alguien con la herramienta adecuada y experiencia. En sistemas con datos sensibles o ante un litigio previsible, debería encargarse un análisis forense informático.
Registrar los datos volátiles en pocos minutos
Los comandos siguientes no modifican nada en el sistema. Escriben el estado actual en archivos que después se guardan fuera del servidor. Cree el directorio de destino, si es posible, en un disco separado y conectado:
ZIEL=/mnt/sicherung/fall-$(date -u +%Y%m%dT%H%MZ)
mkdir -p "$ZIEL"
date -u > "$ZIEL/zeitpunkt-utc.txt"
ps auxwwf > "$ZIEL/prozesse.txt"
ss -tunap > "$ZIEL/verbindungen.txt"
who -a > "$ZIEL/angemeldet.txt"
last -F > "$ZIEL/anmeldungen.txt"
ip addr > "$ZIEL/netz.txt"; ip route >> "$ZIEL/netz.txt"
for u in $(cut -d: -f1 /etc/passwd); do crontab -l -u "$u" 2>/dev/null | sed "s/^/$u: /"; done > "$ZIEL/cronjobs.txt"
sha256sum "$ZIEL"/* > "$ZIEL.sha256"
Cómo asegurar y analizar después los logs por completo lo describe la guía Analizar los logs del servidor web tras un ataque. En servidores virtuales, una instantánea desde el panel del proveedor es el camino más sencillo hacia una imagen completa. Captura el sistema sin que tenga que iniciar más herramientas en el servidor comprometido.
Para que la copia valga algo más adelante
Una copia solo vale lo que valga su acreditación. Tres reglas la hacen fiable:
- Sumas de verificación: cada archivo asegurado recibe una suma SHA-256. Así se podrá demostrar después que la copia no ha cambiado.
- Registro: ¿quién aseguró qué, cuándo, con qué comando y dónde? Cada entrega a terceros se anota. Los especialistas lo llaman cadena de custodia.
- Almacenamiento separado: las copias deben estar en un sistema al que el atacante no tuvo acceso y seguir utilizándose solo en modo lectura.
Después trabaje únicamente con copias. Todo análisis sobre el original modifica marcas de tiempo y puede sobrescribir rastros. No ejecute nunca archivos sospechosos ni los abra desde el navegador.
Solicite pronto los logs del CDN, del WAF y del hoster. Estos datos están fuera de su servidor y son difíciles de manipular por un atacante, pero a menudo solo se conservan poco tiempo.
Lo que destruye las pruebas
Muchos rastros no los pierde el atacante, sino una primera ayuda bienintencionada. Estos pasos deberían evitarse antes de asegurar las pruebas:
- Reiniciar o apagar: después desaparecen procesos, conexiones y memoria.
- Antivirus con borrado automático: elimina archivos antes de que alguien los haya asegurado y modifica las marcas de tiempo.
- Limpiar logs o carpetas temporales: aunque falte espacio, primero copie y luego borre.
- Instalar en el servidor herramientas nuevas descargadas de internet: toda instalación escribe en el sistema de archivos y puede tapar rastros.
- Iniciar sesión con credenciales privilegiadas sin necesidad: si en el servidor todavía se ejecuta código malicioso, las contraseñas introducidas pueden ser interceptadas.
Precisamente las aseguradoras preguntan después qué se aseguró y cuándo. Encontrará indicaciones sobre las obligaciones habituales en Ciberseguro: qué cuenta en caso de siniestro.
Sopesar: ¿cuánto tiempo hay para asegurar las pruebas?
No todo incidente permite una conservación larga. Si se está produciendo una fuga de datos o se ataca a visitantes, la contención tiene prioridad. Desconectar de la red con el sistema en marcha combina ambas cosas: el atacante pierde el acceso y los rastros se conservan. Para la mayoría de los servidores web basta después con un margen de tiempo razonable para los datos volátiles y la instantánea.
Tome la decisión de forma consciente y déjela por escrito: ¿quién decidió cuándo se reinstala y qué se aseguró antes? Esa nota formará después parte de la cronología del incidente. Si lo correcto es reconstruir o limpiar, lo trata el artículo ¿Reinstalar o limpiar el servidor?.
¿Cómo ayuda PHP SOS en concreto?
- Aseguramos datos volátiles, logs e imágenes del sistema en el orden correcto, con sumas de verificación y registro.
- Solicitamos los datos de los servicios situados por delante antes de que venzan sus plazos de conservación.
- Si es necesario, asumimos con socios especializados la conservación y el análisis forenses.
- Solo después reconstruimos el servidor, cerramos la vía de entrada y documentamos el incidente hasta que quede cerrado.
Preguntas frecuentes
¿Por qué debo conservar pruebas antes de reinstalar?
Porque solo los rastros muestran cómo entró el atacante, cuánto tiempo estuvo en el sistema y a qué datos pudo acceder. Necesita esas respuestas para la protección de datos, para el seguro y para saber si hay otros sistemas afectados. Tras la reconstrucción se pierden.
¿Qué es lo más urgente al asegurar las pruebas?
Los datos volátiles, como procesos en ejecución, conexiones de red y usuarios con sesión iniciada, desaparecen al apagar el sistema. Se registran primero. Después van los registros (logs), una imagen del sistema y los datos de los servicios situados por delante.
¿Basta una copia de seguridad normal como conservación de pruebas?
Normalmente no. Muchas copias de seguridad no incluyen logs, archivos del sistema ni metadatos como marcas de tiempo y propietarios. Para conservar pruebas necesita una copia completa e inalterada con suma de verificación, idealmente una instantánea o una imagen del disco.
¿Puedo desconectar el servidor de la red antes de asegurar las pruebas?
Sí, siempre que siga en funcionamiento. Desconectarlo de la red detiene la fuga de datos y el control remoto sin destruir rastros volátiles. Reiniciar o apagar, en cambio, borra la memoria y los procesos en ejecución.