Logs de seguridad en Linux: qué son, dónde están y qué buscar

El mapa de /var/log: dónde está cada cosa

El directorio /var/log es el repositorio central de logs en Linux. No todos los archivos tienen el mismo peso desde el punto de vista de la seguridad, pero conviene conocer el mapa completo antes de especializarse en los más críticos.

ls -lh /var/log/

La salida típica en Kali Linux muestra decenas de archivos y subdirectorios. Estos son los que más interesan desde el punto de vista de la seguridad y la administración de sistemas:

auth.log — el más importante en seguridad

Registra todos los eventos de autenticación: logins correctos e incorrectos, uso de sudo, cambios de contraseña, autenticación SSH, PAM. Es el primer archivo que consultar ante cualquier sospecha de acceso no autorizado o fuerza bruta.

tail -f /var/log/auth.log              # Ver en tiempo real
grep "Failed password" /var/log/auth.log   # Intentos fallidos
grep "Accepted password" /var/log/auth.log # Logins correctos
grep "sudo" /var/log/auth.log              # Uso de sudo

Una entrada típica de intento de autenticación SSH fallido:

Jun 05 03:14:22 kali sshd[2341]: Failed password for root from 192.168.56.103 port 54231 ssh2

Y una autenticación correcta:

Jun 05 03:15:01 kali sshd[2344]: Accepted password for kali from 192.168.56.1 port 52140 ssh2

Si ves decenas de líneas de «Failed password» seguidas desde la misma IP en un intervalo de segundos, estás viendo un ataque de fuerza bruta en tiempo real. Si ves «Failed password» repetido muchas veces y luego «Accepted password» desde la misma IP, el ataque tuvo éxito.

syslog — el diario general del sistema

Agrega mensajes de múltiples fuentes: kernel, servicios del sistema, demonios. Es el log más voluminoso y el más ruidoso, pero también el más completo. Útil para diagnosticar fallos de servicios, arranques inesperados o comportamientos anómalos.

tail -100 /var/log/syslog              # Últimas 100 líneas
grep "error" /var/log/syslog           # Filtrar errores
grep "cron" /var/log/syslog            # Ver tareas programadas
grep "$(date '+%b %e')" /var/log/syslog  # Solo entradas de hoy

En syslog interesa especialmente vigilar las entradas de cron: una tarea programada que no pusiste tú puede ser indicador de persistencia tras una intrusión.

kern.log — mensajes del kernel

Registra mensajes generados por el núcleo del sistema: drivers, hardware, módulos del kernel. Relevante en seguridad para detectar modificaciones del kernel (rootkits que cargan módulos maliciosos), fallos de hardware que pueden derivar en vulnerabilidades de estabilidad, y eventos de red a bajo nivel.

tail -50 /var/log/kern.log
grep "iptables" /var/log/kern.log      # Reglas de firewall activadas
grep "segfault" /var/log/kern.log      # Fallos de segmentación (posible exploit)

Un segfault repetido en un proceso de red puede indicar un intento de explotación de buffer overflow que no ha funcionado del todo.

dpkg.log — historial de paquetes instalados

Registra cada instalación, actualización o eliminación de paquetes. Irrelevante en el día a día, pero extraordinariamente útil en respuesta a incidentes: si alguien instaló una herramienta maliciosa o un backdoor empaquetado, aquí queda la hora exacta y el nombre del paquete.

grep "install" /var/log/dpkg.log       # Paquetes instalados
grep "$(date '+%Y-%m-%d')" /var/log/dpkg.log  # Instalaciones de hoy

wtmp, btmp y lastlog — historial de sesiones

Son archivos binarios, no de texto plano, por lo que no se leen directamente con cat o tail. Tienen comandos específicos:

last                    # Historial de logins (lee wtmp)
last -n 20              # Últimos 20 logins
lastb                   # Intentos de login fallidos (lee btmp)
lastlog                 # Último login de cada usuario del sistema

lastb es especialmente útil: si ves cientos de intentos fallidos desde IPs externas, tienes un escáner de fuerza bruta activo o pasado. Si ves intentos fallidos seguidos de un login exitoso, tienes un incidente que investigar.

Logs de servicios específicos

Muchos servicios escriben sus propios logs en subdirectorios de /var/log. Los más relevantes en un servidor típico:

/var/log/apache2/access.log    # Peticiones HTTP recibidas
/var/log/apache2/error.log     # Errores de Apache
/var/log/nginx/access.log      # Peticiones HTTP en Nginx
/var/log/mysql/error.log       # Errores de MySQL/MariaDB
/var/log/ufw.log               # Log del firewall UFW

En apache2/access.log puedes ver intentos de directory traversal, inyecciones SQL básicas o escaneos de paths típicos de herramientas automatizadas. En ufw.log, los paquetes bloqueados por el firewall.

journalctl: el sistema de logs moderno con systemd

Las distribuciones Linux modernas usan systemd como sistema de inicio, y con él llega journald, un demonio de logging que captura mensajes del kernel, de los servicios del sistema y de las aplicaciones, y los almacena en formato binario estructurado en /var/log/journal/. La interfaz para consultarlos es journalctl.

La ventaja de journald sobre los logs de texto plano es que permite filtrar por unidad de servicio, por rango de tiempo, por prioridad o por proceso, sin necesidad de combinar grep y awk. La desventaja es que no es legible directamente sin journalctl, lo que complica el análisis forense en sistemas comprometidos donde journalctl podría no estar disponible.

Comandos esenciales de journalctl

journalctl                          # Todo el journal (muy largo)
journalctl -n 50                    # Últimas 50 líneas
journalctl -f                       # Seguimiento en tiempo real (como tail -f)
journalctl -b                       # Solo el arranque actual
journalctl -b -1                    # Arranque anterior
journalctl --since "2026-06-05"     # Desde una fecha
journalctl --since "1 hour ago"     # Última hora
journalctl --until "2026-06-05 12:00:00"  # Hasta una hora concreta

Filtrar por servicio y prioridad

journalctl -u ssh                   # Logs del servicio SSH
journalctl -u apache2               # Logs de Apache
journalctl -u cron                  # Logs del demonio cron
journalctl -p err                   # Solo errores (priority: error)
journalctl -p warning               # Advertencias y superior
journalctl -p crit                  # Solo críticos y emergencias
journalctl -u ssh -p err            # Errores del SSH

Las prioridades siguen el estándar syslog: emerg, alert, crit, err, warning, notice, info, debug. Para monitorización de seguridad, el nivel habitual de trabajo es warning hacia arriba.

Filtrar por proceso o usuario

journalctl _PID=1234                # Logs de un proceso concreto
journalctl _UID=1000                # Logs generados por un usuario (UID)
journalctl _COMM=sshd               # Logs del binario sshd
journalctl _COMM=sudo               # Todo lo que pasó por sudo

Salida en distintos formatos

journalctl -o short                 # Formato por defecto
journalctl -o verbose               # Todos los campos del entry
journalctl -o json                  # Salida JSON (útil para parsear)
journalctl -o json-pretty           # JSON formateado y legible
journalctl -o cat                   # Solo el mensaje, sin metadatos

La salida JSON es especialmente útil si quieres procesar los logs con scripts o enviarlos a un sistema externo. Si estás explorando tu propio Mini-SIEM, journalctl -o json -f es una fuente de datos estructurada lista para ingestar.

Comandos útiles para analizar logs desde terminal

Leer los logs en crudo es solo el primer paso. El verdadero análisis empieza cuando combinas las herramientas de texto de Linux para filtrar, contar y correlacionar eventos.

Comandos básicos de lectura

tail -f /var/log/auth.log            # Seguimiento en tiempo real
tail -n 200 /var/log/syslog          # Últimas 200 líneas
head -n 50 /var/log/auth.log         # Primeras 50 líneas
less /var/log/syslog                 # Paginado interactivo (q para salir)
cat /var/log/auth.log | wc -l        # Contar líneas totales

Filtrado y búsqueda con grep

grep "Failed" /var/log/auth.log                    # Filtrar por palabra
grep -i "error" /var/log/syslog                    # Sin distinción may/min
grep -v "CRON" /var/log/syslog                     # Excluir cron del syslog
grep -c "Failed password" /var/log/auth.log        # Contar ocurrencias
grep -E "Failed|Invalid" /var/log/auth.log         # Buscar varios patrones
grep "Failed" /var/log/auth.log | tail -20         # Últimos 20 fallos

Análisis con awk y sort para detectar patrones

Uno de los análisis más útiles: contar cuántos intentos fallidos ha habido por IP de origen. Muy rápido para detectar fuerza bruta:

# IPs con más intentos fallidos de SSH, ordenadas de mayor a menor
grep "Failed password" /var/log/auth.log \
  | awk '{print $(NF-3)}' \
  | sort | uniq -c | sort -rn | head -20

Si una IP aparece cientos de veces, tienes un escáner de fuerza bruta activo o pasado. Si esa misma IP aparece después en una línea de «Accepted password», tienes un incidente.

# Usuarios que más veces han usado sudo
grep "sudo" /var/log/auth.log \
  | awk '{print $6}' \
  | sort | uniq -c | sort -rn

# Contar entradas de log por hora (para ver picos de actividad)
grep "Failed" /var/log/auth.log \
  | awk '{print $3}' \
  | cut -d: -f1 \
  | sort | uniq -c

Caso práctico: análisis de auth.log en Kali Linux

Todos los ejemplos se ejecutan sobre Kali Linux (IP 192.168.56.102) del laboratorio de VirtualBox. El objetivo es familiarizarse con la lectura e interpretación de los logs de autenticación antes de pasar a herramientas más avanzadas.

Paso 1 — Ver el estado actual de auth.log

sudo tail -50 /var/log/auth.log

Las primeras líneas ya dan mucha información. Busca patrones: ¿hay entradas repetidas? ¿Hay IPs que aparecen varias veces? ¿Hay comandos sudo que no recuerdas haber ejecutado?

Paso 2 — Contar intentos fallidos por IP

sudo grep "Failed password" /var/log/auth.log \
  | awk '{print $(NF-3)}' \
  | sort | uniq -c | sort -rn

En un laboratorio aislado sin tráfico externo, lo normal es ver pocas o ninguna entrada. Si hay muchas desde IPs externas, la máquina tiene exposición a internet que no debería tener.

Paso 3 — Ver todos los logins exitosos

sudo grep "session opened" /var/log/auth.log
last -n 20

Compara los logins que muestra last con los que recuerdas haber hecho. En un entorno real, cualquier sesión que no reconozcas es un indicador de compromiso que hay que investigar.

Paso 4 — Revisar el journal del servicio SSH

sudo journalctl -u ssh --since "today"
sudo journalctl -u ssh -p warning

journalctl te da los mismos eventos que auth.log pero con mejor filtrado y con contexto adicional de systemd. Úsalo cuando quieras acotar por tiempo o prioridad sin necesidad de combinar grep y awk.

Paso 5 — Comprobar si hay tareas cron sospechosas

grep "CRON" /var/log/syslog | tail -30
sudo journalctl -u cron --since "today"

Las tareas cron son uno de los mecanismos de persistencia más usados tras una intrusión. Si ves entradas de cron ejecutando scripts desde directorios inusuales (/tmp, /dev/shm) o con nombres poco descriptivos, merece investigación.

Referencia rápida: archivos de log más importantes

Referencia rápida: comandos esenciales

La Página de Draven · Ciberseguridad · Logs de seguridad en Linux · 2026

#LogsSeguridad #Linux #KaliLinux #varlog #journalctl #authlog #BlueTeam #Ciberseguridad #Monitorización #AdministraciónSistemas #ASIR #MásterCiberseguridad