Análisis forense en Linux: qué hacer si sospechas que han entrado en tu servidor

Llevo años administrando servidores Linux y la primera reacción cuando algo huele mal suele ser la peor: reiniciar, borrar y reinstalar. Si quieres saber qué pasó (o necesitas pruebas), hay un orden que seguir. Esta es la versión práctica.

1. No apagues todavía: el orden de volatilidad

Hay datos que desaparecen al apagar. Recógelos de más volátil a menos:

• Registros y caché de la CPU.
• Memoria RAM.
• Conexiones de red y archivos abiertos.
• Procesos en ejecución.
• Disco.

2. Captura lo que se va a perder

Antes de tocar nada, guarda la salida de estos comandos en un USB externo, nunca en el disco sospechoso:

• who, w y last: quién está conectado y quién entró.
• ps auxwww: procesos activos con su línea de comandos completa.
• lsof y ss -tupan: archivos abiertos y conexiones de red.

Para la memoria RAM, hoy se usan herramientas como LiME o AVML, y luego se analiza el volcado con Volatility 3.

3. Copia el disco bit a bit y calcula su hash

Nunca trabajes sobre el disco original. Haz una copia exacta:

dd if=/dev/sdX of=/media/externo/evidencia.img bs=4M conv=sync,noerror status=progress
sha256sum /dev/sdX /media/externo/evidencia.img

Si los dos hashes coinciden, la copia es idéntica. Herramientas como dc3dd o ewfacquire hacen la copia y el hash a la vez.

4. Monta la copia en solo lectura

mount -o ro,noexec,nodev,loop evidencia.img /mnt/analisis

ro impide modificar la evidencia y noexec evita ejecutar por accidente un binario malicioso.

5. Documenta la cadena de custodia

Si el caso puede acabar en un juzgado, anota cada paso: quién tuvo el disco, cuándo, qué hizo y qué hash tenía. Guarda el original en un lugar controlado. Sin cadena de custodia, la prueba pierde valor.

6. Revisa los logs y el historial

• /var/log/auth.log (Debian/Ubuntu) o /var/log/secure (RHEL): accesos y uso de sudo.
• journalctl en sistemas con systemd.
• /var/log/wtmp y /var/log/btmp: inicios de sesión correctos y fallidos (se leen con last y lastb).
• ~/.bash_history de cada usuario y de root.

Ojo: un log vacío o truncado a 0 bytes es una pista en sí misma. Hay scripts («zappers») que sirven precisamente para borrar huellas.

7. Comprueba si han sustituido binarios

• En sistemas RPM: rpm -Va compara cada archivo con lo instalado.
• En Debian/Ubuntu: debsums -c hace lo mismo.

8. Analiza binarios sospechosos

Sin ejecutarlos: file, strings, ldd y nm te dicen qué son, qué texto contienen y qué bibliotecas usan.

9. Busca rootkits

chkrootkit y rkhunter comparan, entre otras cosas, los procesos que ve /proc con los que muestra ps. Si no coinciden, algo se esconde.

10. Reconstruye la línea temporal

The Sleuth Kit con su interfaz Autopsy permite ver los archivos por fechas de modificación, acceso y cambio (marcas MAC) y recuperar archivos borrados. Es la evolución de The Coroner’s Toolkit, que muchas guías antiguas todavía citan.

Lista rápida

• No reinicies.
• Captura RAM, procesos y red.
• Copia el disco y calcula el hash.
• Trabaja siempre sobre la copia, en solo lectura.
• Documenta todo.

Mejor prevenir que investigar: repasa la seguridad digital para torpes y comprueba si alguna de tus claves aparece en filtraciones con esta guía.

Preguntas frecuentes

¿Puedo hacer el análisis en el propio servidor?

Solo la captura de datos volátiles. El análisis del disco, siempre sobre una copia y desde otro equipo.

¿Qué distribución uso para analizar?

Hay distribuciones pensadas para esto, como CAINE, Tsurugi o Kali en modo forense, que no montan discos automáticamente.

¿Y si solo quiero volver a tener el servidor funcionando?

Guarda al menos la copia del disco y los logs antes de reinstalar. Si el atacante entró una vez, sabrás por dónde cerrar la puerta.