Cuando un servidor Linux es comprometido, la rapidez y precisión en la recopilación de pruebas forenses son cruciales. Cada segundo que pasa, los datos volátiles pueden perderse, haciendo que el análisis del incidente sea incompleto o incluso engañoso. El objetivo principal es adquirir una instantánea del estado del sistema en el momento de la intrusión, minimizando al mismo tiempo la alteración de las pruebas. Este script, desarrollado y probado en escenarios reales de respuesta a incidentes, automatiza la recopilación de información esencial, desde procesos activos hasta conexiones de red, desde logs del sistema hasta archivos modificados recientemente, proporcionando una base sólida para la investigación forense posterior.
Tested on: Ubuntu 22.04 LTS · Debian 11 · CentOS 7 · [julio 2024]
Requisitos Previos / Entorno de Prueba
Para ejecutar el script es necesario tener acceso al sistema comprometido con privilegios de root o un usuario con acceso sudo. Idealmente, el script debería ejecutarse desde un soporte no persistente (ej. USB live boot) o copiarse y ejecutarse desde un directorio temporal, para reducir el impacto en el disco y prevenir la sobrescritura de pruebas. Asegúrate de que en el sistema estén disponibles comandos estándar como tar, gzip, sha256sum, ps, netstat, ls, cat, find, mount, que suelen estar presentes en todas las distribuciones Linux. El script está diseñado para ser lo más agnóstico posible respecto a la distribución.
1. Comprender la Prioridad de los Datos Volátiles
En una investigación forense, los datos se clasifican en función de su volatilidad. Los más volátiles son aquellos que cambian rápidamente o se pierden al reiniciar el sistema, como los procesos en memoria y las conexiones de red activas. La recopilación de estos datos debe ser la primera prioridad para preservar una imagen precisa del estado del sistema en el momento del incidente. El script comienza precisamente aquí, capturando los datos más efímeros antes de que puedan ser alterados o perdidos.
2. El Script de Recopilación de Pruebas (Forensic Toolkit)
Este script Bash está diseñado para ejecutarse en un sistema Linux potencialmente comprometido. Recopila una serie de información crítica y la empaqueta en un archivo tar.gz con una marca de tiempo para facilitar el análisis posterior. Lee también: Cómo automatizar la creación de reportes con Ansible
#!/bin/bash
# Script de recopilación de pruebas forenses para sistemas Linux
# Autor: Rosario Giordano
# Versión: 1.0
# Fecha: 2024-07-22
# Verifica privilegios de root
if [[ $EUID -ne 0 ]]; then
echo "Este script debe ser ejecutado como root o con sudo."
exit 1
fi
OUTPUT_DIR="/tmp/forensic_collection_$(date +%Y%m%d_%H%M%S)"
mkdir -p "$OUTPUT_DIR"
echo "Iniciando recopilación de pruebas forenses en $OUTPUT_DIR..."
# 1. Datos Volátiles
# Procesos en ejecución
ps auxww > "$OUTPUT_DIR/ps_auxww.txt"
ps -ef > "$OUTPUT_DIR/ps_ef.txt"
ls -l /proc/*/exe > "$OUTPUT_DIR/proc_exe_links.txt" 2>/dev/null
ls -l /proc/*/fd > "$OUTPUT_DIR/proc_fd_links.txt" 2>/dev/null
# Conexiones de red
netstat -tulnp > "$OUTPUT_DIR/netstat_tulnp.txt"
netstat -anp > "$OUTPUT_DIR/netstat_anp.txt"
ss -tulnp > "$OUTPUT_DIR/ss_tulnp.txt" # Alternativa a netstat en sistemas modernos
ss -anp > "$OUTPUT_DIR/ss_anp.txt"
# Tablas ARP
arp -an > "$OUTPUT_DIR/arp_an.txt"
# Cache DNS
cat /etc/resolv.conf > "$OUTPUT_DIR/resolv.conf"
# Para cache DNS específicas de servicios (ej. systemd-resolved, dnsmasq) podría necesitar integración específica
# Variables de entorno (para procesos específicos, si es relevante)
# Ejemplo: cat /proc/PID/environ
# 2. Información del Sistema y Configuración
# Información del kernel y versión OS
uname -a > "$OUTPUT_DIR/uname_a.txt"
cat /etc/os-release > "$OUTPUT_DIR/os_release.txt"
# Usuarios y Grupos
cat /etc/passwd > "$OUTPUT_DIR/passwd.txt"
cat /etc/shadow > "$OUTPUT_DIR/shadow.txt"
cat /etc/group > "$OUTPUT_DIR/group.txt"
cat /etc/sudoers > "$OUTPUT_DIR/sudoers.txt" 2>/dev/null
# Configuraciones de red
ifconfig -a > "$OUTPUT_DIR/ifconfig_a.txt"
ip a > "$OUTPUT_DIR/ip_a.txt"
ip r > "$OUTPUT_DIR/ip_r.txt"
cat /etc/network/interfaces > "$OUTPUT_DIR/network_interfaces.txt" 2>/dev/null
# Servicios en ejecución
systemctl list-units --type=service > "$OUTPUT_DIR/systemctl_services.txt"
# Cron jobs
crontab -l > "$OUTPUT_DIR/crontab_root.txt" 2>/dev/null
# Para otros usuarios: for user in $(cut -f1 -d: /etc/passwd); do crontab -l -u $user 2>/dev/null >> "$OUTPUT_DIR/crontab_${user}.txt"; done
# 3. Logs del Sistema
# Logs recientes (últimas 24h o más, según la rotación)
journalctl --no-pager --since "1 day ago" > "$OUTPUT_DIR/journalctl_last_day.log"
find /var/log -maxdepth 1 -type f -name "*.log" -o -name "messages" -o -name "syslog" -o -name "auth.log" -exec cp --parents {} "$OUTPUT_DIR/logs/" \; 2>/dev/null
# 4. Archivos y Directorios Sospechosos
# Archivos modificados en los últimos X días (ej. 7 días)
find / -type f -mtime -7 -print0 2>/dev/null | xargs -0 tar -rf "$OUTPUT_DIR/recently_modified_files.tar" 2>/dev/null
# Archivos con permisos SUID/SGID
find / -type f -perm /6000 -exec ls -la {} \; > "$OUTPUT_DIR/suid_sgid_files.txt" 2>/dev/null
# Archivos ocultos en el directorio home (ej. .bashrc, .profile)
find /home -maxdepth 2 -type f -name ".*" -print0 2>/dev/null | xargs -0 tar -rf "$OUTPUT_DIR/hidden_home_files.tar" 2>/dev/null
# 5. Integridad de las Pruebas
# Genera hash SHA256 para todos los archivos recopilados
find "$OUTPUT_DIR" -type f -exec sha256sum {} \; > "$OUTPUT_DIR/sha256sums.txt"
# 6. Compresión y Limpieza
# Comprime el directorio completo en un archivo tar.gz
ARCHIVE_NAME="forensic_evidence_$(date +%Y%m%d_%H%M%S).tar.gz"
tar -czvf "/tmp/$ARCHIVE_NAME" -C "$(dirname "$OUTPUT_DIR")" "$(basename "$OUTPUT_DIR")"
echo "Recopilación completada. Archivo creado en /tmp/$ARCHIVE_NAME"
echo "Eliminando directorio temporal $OUTPUT_DIR..."
rm -rf "$OUTPUT_DIR"
echo "Script completado."3. Análisis de las Secciones del Script
El script está estructurado para cubrir las áreas más críticas en caso de incidente. Lee también: SIEM Open Source: Wazuh vs Security Onion
Datos Volátiles
Esta sección es la más importante. ps auxww y ps -ef capturan todos los procesos en ejecución con sus argumentos completos, revelando posibles procesos maliciosos o anómalos. netstat -tulnp y ss -tulnp muestran las conexiones de red activas y los programas en escucha, fundamentales para identificar comunicaciones C2 (Command and Control) o servicios inesperados. Los enlaces en /proc//exe y /proc//fd pueden revelar procesos que han eliminado sus binarios del disco (malware sin archivos) o archivos abiertos hacia destinos inusuales.
Información del Sistema y Configuración
Capturar uname -a y /etc/os-release proporciona un contexto esencial sobre la versión del sistema operativo. Los archivos /etc/passwd, /etc/shadow, /etc/group son vitales para identificar cuentas de usuario comprometidas o añadidas ilícitamente. /etc/sudoers revela quién tiene privilegios elevados. Las configuraciones de red (ifconfig, ip a, /etc/network/interfaces) pueden mostrar modificaciones a direcciones IP, rutas o interfaces. Los servicios del sistema (systemctl) y los cron jobs (crontab -l) son puntos clave donde los atacantes a menudo establecen persistencia.
Logs del Sistema
Los logs son la narrativa de los eventos. journalctl (para sistemas modernos con systemd) y los archivos en /var/log (auth.log, syslog, messages) contienen registros de accesos, errores, intentos de inicio de sesión fallidos y actividades sospechosas. Su análisis es fundamental para reconstruir la línea de tiempo del ataque.
Archivos y Directorios Sospechosos
find es una herramienta potente para identificar archivos modificados recientemente (-mtime), archivos con permisos SUID/SGID inusuales (a menudo usados para escalada de privilegios), o archivos ocultos que podrían contener configuraciones maliciosas. La inclusión de estos archivos en un archivo separado facilita un análisis dirigido. Lee también: Honeypot Agosto: 7 Días, 1.200 Ataques SSH
Errores Comunes y Resolución de Problemas
- Ejecución en sistema comprometido: La ejecución del script en el sistema comprometido puede alterar las pruebas. Idealmente, se debería montar el disco del sistema comprometido en una máquina forense separada y recopilar los datos desde allí. Si no es posible, ejecutar el script en
/tmpy transferir inmediatamente el archivo. - Permisos: Asegúrate de que el script tenga los permisos de ejecución (
chmod +x script.sh) y que se ejecute con privilegios de root (sudo ./script.sh). - Espacio en disco: La recopilación de logs y archivos modificados puede generar un archivo de gran tamaño. Controla el espacio disponible en
/tmpo en el destino del archivo. - Comandos faltantes: Si un comando como
ssojournalctlno está presente (en distribuciones muy antiguas o mínimas), el script continuará, pero los datos de esa sección estarán ausentes. Es un compromiso aceptable para un script genérico. - Time Stomping: Los atacantes pueden modificar las marcas de tiempo de los archivos. Los hashes SHA256 y las marcas de tiempo de recopilación del script son cruciales para demostrar la integridad de las pruebas. Lee también: NIS2 Sanidad: Registro Tratamientos Técnico
FAQ — Preguntas Frecuentes
¿Debo modificar el script para cada incidente?
No, el script está diseñado para ser genérico. Sin embargo, podrías querer añadir secciones específicas para software particulares (ej. configuraciones de bases de datos, logs de aplicaciones web) si sabes que están instalados en el sistema objetivo. Lo importante es mantener su naturaleza no invasiva y la recopilación de los datos críticos.
¿Dónde debería guardar el archivo de pruebas?
El archivo se crea en /tmp. Es fundamental transferirlo lo antes posible a un sistema de almacenamiento seguro y offline, por ejemplo, un servidor de logs centralizado o un dispositivo USB dedicado al análisis forense, para garantizar su integridad y disponibilidad para futuras investigaciones.
¿Este script es suficiente para un análisis forense completo?
Este script proporciona una base excelente para la recopilación inicial de pruebas. No reemplaza un análisis forense profundo que podría incluir la creación de una imagen completa del disco, el análisis de la memoria RAM y el uso de herramientas forenses especializadas. Es un primer paso rápido y robusto para «detener el tiempo» y capturar los datos más críticos.
¿Cómo puedo verificar la integridad del archivo después de la transferencia?
El script genera un archivo sha256sums.txt dentro del archivo. Después de transferir el archivo, puedes extraer este archivo y volver a ejecutar sha256sum -c sha256sums.txt dentro del directorio extraído para verificar que ningún archivo haya sido alterado durante la transferencia o el almacenamiento.
Conclusiones con Puntos Clave Operativos
La gestión de un incidente en un sistema Linux requiere prontitud y metodología. Este script proporciona un marco operativo para la recopilación rápida y sistemática de pruebas forenses. El takeaway principal es que la automatización en esta fase no solo acelera el proceso, sino que reduce significativamente el riesgo de errores humanos y la pérdida de datos cruciales. Tener una herramienta así a mano, probada y comprendida, es una ventaja inestimable para cualquier equipo de seguridad o sysadmin. Recuerda siempre transferir las pruebas recopiladas a un sistema seguro y no analizar directamente en el sistema comprometido para preservar la cadena de custodia. Lee también: Cloud PA PSN: La Realidad de la Migración Obligatoria 2026
Actualizado: julio 2024
