Analizador de registros de KI: Analizar logs de Linux durante incidentes de seguridad (Comandos + Automatización)

IRC-Mania Die Seite rund um Sicherheit und Programmierung

Internet, Sicherheit , Internet Relay Chat

Gesponsert

Lo que cubre este artículo

• El mapa de logs de Linux: dónde se encuentra cada archivo de registro (auth.log vs. secure, journalctl, audit.log, wtmp/btmp, bash_history).
• Triage de comandos durante un incidente de seguridad: inicios de sesión sospechosos, fallos de autenticación, historial de shell, auditd, persistencia (Cron, systemd, ld.so.preload), claves SSH backdoor, forensia de /proc.
• Cómo analizar logs localmente con KI (Ollama, LogWhisperer, logllama, Sentinel) frente a servicios en la nube, y por qué lo local es la opción correcta para logs de seguridad.
• Alertas automatizadas: systemd-Timer + LLM + notificaciones a Discord/Slack/Telegram.

Introducción

Cuando hay sospecha de un incidente de seguridad, el tiempo es crítico. Quien ingresó deja rastros en los logs, y la primera pregunta siempre es “qué logs, qué comandos”. Este artículo es la lista de verificación más la capa de KI: cómo un LLM local ordena las líneas sin procesar y alerta automáticamente, sin que los logs abandonen nunca tu servidor.

El mapa de logs de Linux: dónde se encuentra cada uno

En sistemas puramente basados en systemd, estos archivos de texto pueden no existir, entonces usa: journalctl -u ssh -u sshd -S "2026-09-22 01:00:00" --no-pager.

Triage de incidente de seguridad: Los comandos

1. ¿Quién entró exitosamente?

# Inicios de sesión SSH exitosos (Debian/Ubuntu)
grep -E "Accepted (publickey|password)" /var/log/auth.log | tail -25

# Lo mismo en RHEL/Fedora
grep "Accepted" /var/log/secure | tail -25

# Quién está conectado ahora + últimos inicios de sesión
who
last -20
lastlog | grep -v "Never"

2. Tormenta de fallos de login (Fuerza bruta)

# Logins fallidos de btmp (no están en el log de texto)
sudo lastb | head -20

# IPs atacantes más frecuentes
grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head

3. ¿Qué se ejecutó? Historial de shell + auditd

# Historial del usuario (atención: los atacantes lo borran frecuentemente)
cat /home/user/.bash_history | tail -50
cat /root/.bash_history | tail -50

# Mejor: auditd proporciona CADA ejecución a nivel de kernel
sudo ausearch -m EXECVE --start recent | tail -100
sudo ausearch -i -m EXECVE --start today        # legible (-i = interpret)
sudo aureport --failed                          # eventos fallidos
sudo aureport -x --summary                      # todos los llamados execve

auditd ve lo que el historial oculta porque opera a nivel de kernel. Reglas importantes para prepararse (en /etc/audit/rules.d/):

-a always,exit -F arch=b64 -S execve -S execveat -k exec
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/sudoers -p wa -k privilege
-w /etc/cron.d/ -p wa -k persistence
-w /etc/systemd/system/ -p wa -k persistence
-w /root/.ssh/ -p wa -k persistence
-w /etc/ld.so.preload -p wa -k preload

4. Encontrar persistencia: dónde el atacante esconde su acceso para el “día 2”

# Todos los crontabs (trabajos ocultos)
for u in $(cut -d: -f1 /etc/passwd); do echo "== $u"; crontab -l -u $u 2>/dev/null; done
ls -la /etc/cron.d/ /etc/cron.daily/ /etc/cron.hourly/ /var/spool/cron/crontabs/

# systemd-Timers (el disfraz moderno de cron)
systemctl list-timers --all

# Archivos de servicio nuevos
ls -lt /etc/systemd/system/ /lib/systemd/system/ | head -15

# Scripts de inicio de shell
grep -r "curl\|wget\|base64\|nc " /etc/profile.d/ ~/.bashrc ~/.profile /etc/profile 2>/dev/null

5. Claves SSH backdoor

# Encontrar todos los authorized_keys en el sistema
sudo find / -name "authorized_keys" -type f 2>/dev/null

# Revisar contenido, ¿claves desconocidas?
cat /root/.ssh/authorized_keys /home/*/.ssh/authorized_keys 2>/dev/null

# Archivos modificados recientemente en todo el sistema (artefactos del atacante)
sudo find / -ctime -2 -type f 2>/dev/null | grep -v -E "^/(proc|sys|run|dev|var/log)"

6. Forensia de /proc: Lo que los rootkits no pueden ocultar

Un rootkit en userspace (LD_PRELOAD) puede ocultar procesos de ps. /proc es la verdad:

# Ejecutable de un proceso sospechoso
sudo ls -l /proc/<PID>/exe

# Binarios eliminados pero aún en ejecución (signo clásico de rootkit)
sudo ls -l /proc/*/exe 2>/dev/null | grep "(deleted)"

# Entorno y línea de comandos del proceso
sudo cat /proc/<PID>/cmdline | tr '\0' ' '; echo
sudo cat /proc/<PID>/environ | tr '\0' '\n' | grep -i "preload\|ld_"

# La verificación clásica de rootkit preload
cat /etc/ld.so.preload 2>/dev/null    # ¡debería estar vacío!
ls -la /etc/ld.so.preload

7. Importante saber: Los logs son manipulables

Un atacante serio elimina líneas de auth.log y bash_history. Las contrapruebas: auditd (kernel), wtmp/btmp (formato binario, más difícil de editar), syslog remoto (la copia en el servidor central no puede ser falsificada por el atacante) y timestamps de archivo. Siempre cruza múltiples fuentes.

Análisis de logs con KI: Local vs. Nube

Advertencia sobre la nube primero: Los logs de seguridad contienen IPs, nombres de usuarios, nombres de host, a veces rutas internas, exactamente lo que un atacante necesitaría. Pegar auth.log en ChatGPT o una API web es un problema de privacidad y seguridad. Por eso: LLMs locales a través de Ollama son la opción correcta para análisis de logs. Ver KI local y Ollama.

Herramientas de KI locales listas para usar

La pipeline clásica DIY (autohospedada, 0 €)

El patrón detrás de todas estas herramientas es el mismo y se puede construir en aproximadamente 50 líneas:

# 1. Recopilar logs (aquí: últimos fallos de auth.log)
grep "Failed password" /var/log/auth.log | tail -100 > /tmp/fails.txt

# 2. Enviar a Ollama local
ollama run llama3.1:8b "Eres administrador Linux. Analiza estos fallos de login:
¿Patrones? ¿IPs? ¿Fuerza bruta o dirigida? Responde brevemente + estructurado.
$(cat /tmp/fails.txt)"

# 3. Automatizar: systemd-Timer cada 5 minutos
#    journalctl/Loki → Python → API de Ollama → Clasificación → Alerta

Expandido a producción (este es exactamente el camino de LogWhisperer/Sentinel):

journalctl -f  (o consulta de Loki cada 5 min)
  → Puerta de palabras clave (solo ERROR/Failed/Accepted-pattern, sin necesidad de LLM)
  → Ollama-LLM: "¿Ruido o anomalía: [razón]?"
  → si anomalía → alerta a Discord/Slack/Telegram/webhook de n8n
  → caché de dedup: no reportar dos veces la misma firma

Modelos locales recomendados: llama3.1:8b para logs de seguridad, gemma2:9b para análisis general (ambos ~5-6 GB RAM en Q4). N8N puede construir el mismo flow sin Python, ver Mejores workflows de n8n.

Importante: la IA clasifica, tú decides

El LLM actúa como prefiltro (elimina ruido, explica patrones), no como perito forense. La cadena de pruebas sigue siendo responsabilidad de los comandos anteriores. Herramientas de calidad como logllama fuerzan “respalda cada afirmación con la línea del log”, exactamente lo que tu prompt debe exigir: “Cita el número de línea como evidencia. Sin suposiciones.”

Lista de verificación para incidentes (en orden)

1. ¿Quién entró?    → grep "Accepted" auth.log/secure, last, lastlog
2. ¿Quién intentó?  → sudo lastb, Failed-password-IPs
3. ¿Qué se ejecutó?  → ausearch -m EXECVE --start recent, bash_history
4. ¿Qué persiste?    → cron, systemd-timer, authorized_keys, ld.so.preload
5. ¿Qué corre ahora? → /proc/*/exe (deleted), cmdline, environ
6. Asegurar          → Revocar keys, cambiar contraseñas, syslog remoto, reglas auditd
7. Notificar         → Pipeline de IA en operación continua, no solo una vez

Enlaces de interés

• IRC-Security.de: más artículos y guías sobre seguridad.
• IRC-Coding.de: tutoriales de programación y artículos de código.
• Logging: estrategia de logging.
• Monitoring: fundamentos de alerting.
• Agentes-Sicherheit: guardrails.
• Ollama: el LLM local detrás del análisis.
• Mejores workflows n8n: automatización de alertas.
• Manejo correcto de Secrets: nunca envíes credenciales en logs.

Puntos clave:

• Mapa de distros: Debian/Ubuntu registran auth en /var/log/auth.log, familia RHEL en /var/log/secure, fallback systemd journalctl -u ssh.
• Comandos de incidentes: grep "Accepted", last/lastb, ausearch -m EXECVE --start recent, aureport --failed, crontab -l, systemctl list-timers, find / -name authorized_keys, /proc/PID/exe, /etc/ld.so.preload.
• Verificación de persistencia: cron (todos los usuarios), systemd-timers, scripts de inicio, SSH keys, preload.
• Análisis de IA localmente vía Ollama: LogWhisperer, logllama, log-explainer, Sentinel, o DIY journalctl → LLM → alerta en Discord/Slack/n8n. Nunca envíes logs a la nube.
• El LLM es el prefiltro, la cadena de pruebas la proporcionan los comandos.

Preguntas frecuentes

Fuentes y lecturas complementarias

• LogWhisperer, logllama, log-explainer
• Sentinel / OpenClaw Log-Anomaly, AI Log Analysis mit Ollama
• auditd Incident Response, ausearch(8) man page
• IRC-Security.de: más artículos sobre seguridad.
• IRC-Coding.de: tutoriales de programación.

Premium VPS Hosting

Schnelle und sichere VPS Server

Gesponsert