Inspección de registros de seguridad

Objetivo:

Comprender y dominar las herramientas de auditoría e inspección de registros de seguridad en Linux, aprendiendo a analizar intentos de acceso, fallos de autenticación, uso de privilegios de superusuario y eventos del sistema mediante journalctl y los ficheros tradicionales en /var/log/auth.log.

Escenario:

  • Herramientas: Terminal Linux, comandos journalctl, grep, awk, y lectura de ficheros de registro en /var/log/auth.log.
  • Conceptos analizados: Systemd Journal (systemd-journald), autenticación PAM (Pluggable Authentication Modules), registros de intentos de acceso SSH fallidos y auditoría del comando sudo.
  • Proceso clave: Realización de una auditoría de seguridad ante una alerta de fuerza bruta, filtrado temporal de eventos de inicio de sesión y rastreo de la actividad de los usuarios con privilegios elevados.

Escenario Real: Detección de ataques de fuerza bruta y auditoría de accesos

Un servidor expuesto a Internet ha registrado múltiples alertas de seguridad debido a intentos masivos de inicio de sesión por SSH con credenciales incorrectas. Como administrador de sistemas, debes inspeccionar los registros de autenticación del sistema para identificar las direcciones IP de origen maliciosas, comprobar si algún atacante logró superar las barreras de entrada y auditar qué comandos ejecutaron los usuarios mediante privilegios de superusuario.

Por defecto, los sistemas operativos registran de forma centralizada todos los eventos críticos de seguridad y autenticación. Saber consultar, filtrar y correlacionar eficientemente estos registros es una competencia fundamental para responder ante incidentes de ciberseguridad y cumplir con las normativas de auditoría técnica.

NOTA: Para realizar esta práctica con total seguridad, utilizaremos exclusivamente comandos de consulta e inspección en modo de solo lectura, evitando alterar o purgar los registros de auditoría activos del sistema.

Instrucciones:

Fase 1: Inspección de los registros de autenticación en texto plano (/var/log/auth.log):

  • Visualizar las últimas líneas generadas en el fichero tradicional de registros de autenticación del sistema: sudo tail -n 50 /var/log/auth.log
  • Filtrar el fichero para aislar de forma específica todos los eventos que contengan la palabra clave de fallo (Failed o Invalid): sudo grep -i "failed" /var/log/auth.log
  • Identificar la estructura de los mensajes, observando la marca temporal, el nombre del servicio de autenticación (como sshd o sudo) y la dirección IP de origen asociada.

Fase 2: Consultas avanzadas y filtrado temporal con journalctl:

  • Consultar el registro estructurado y centralizado generado por el demonio systemd-journald filtrando exclusivamente por el servicio SSH: sudo journalctl -u ssh
  • Filtrar los eventos de seguridad limitándolos a un intervalo temporal reciente (por ejemplo, los registros de la última hora): sudo journalctl --since "1 hour ago"
  • Mostrar los logs en tiempo real a medida que se producen nuevos eventos en el sistema: sudo journalctl -f

Fase 3: Análisis estadístico de intentos de acceso por fuerza bruta:

  • Extraer de forma automatizada las direcciones IP desde las cuales se han producido intentos de contraseña fallidos combinando los registros y utilidades de texto: 
    sudo grep "Failed password" /var/log/auth.log | awk '{print $11}' | sort | uniq -c | sort -nr
  • Analizar los resultados obtenidos para determinar si una dirección IP concreta acumula cientos de peticiones, lo cual evidencia un ataque automatizado de fuerza bruta.

Fase 4: Auditoría de uso de privilegios de superusuario (sudo):

  • Inspeccionar los registros de autenticación para comprobar qué usuarios han empleado el comando sudo para elevar privilegios: sudo grep -i "sudo" /var/log/auth.log
  • Utilizar journalctl para auditar de forma precisa la ejecución de comandos administrativos por parte de los usuarios del sistema: sudo journalctl _COMM=sudo

Verificación:

  • Comprobar mediante el filtrado con journalctl que se listan con precisión los eventos de inicio de sesión correctos (Accepted publickey o Accepted password).
  • Verificar que el análisis estadístico de IPs permite aislar con claridad el origen de las conexiones sospechosas que intentan vulnerar el servidor.

Posibles errores y resolución de problemas:

Si al intentar consultar el fichero tradicional de registros observas que la ruta /var/log/auth.log no existe o aparece completamente vacía en una distribución moderna de Linux (como versiones recientes de Ubuntu o Fedora), se debe a que el sistema ha prescindido de los ficheros de texto plano.

  • Solución: Muchas distribuciones actuales almacenan los registros exclusivamente de forma binaria y centralizada a través del subsistema systemd-journald. Utiliza directamente el comando journalctl para consultar los eventos indexados sin depender de ficheros de texto tradicionales.

Alternativa directa: Monitorización en directo con journalctl

Si necesitas mantener una ventana abierta en tiempo real analizando exclusivamente los intentos de autenticación fallidos o aceptados del servicio SSH mientras realizas pruebas de conexión, puedes ejecutar el siguiente filtro dinámico:

sudo journalctl -u ssh -f --since "today"

Preguntas de reflexión:

  1. ¿Qué ventajas operativas y de seguridad aporta el almacenamiento centralizado y binario de journalctl frente a los ficheros tradicionales de texto plano en /var/log/?
  2. ¿Qué función desempeñan los módulos PAM (Pluggable Authentication Modules) en la gestión de la identidad y la generación de registros dentro del sistema de autenticación de Linux?
  3. ¿Por qué es un requisito crítico de seguridad auditar periódicamente los eventos asociados al uso del comando sudo en los registros del sistema?
  4. ¿Qué limitaciones temporales o de persistencia presentan los registros locales de un servidor frente a un atacante avanzado que lograse obtener privilegios de superusuario (root)?
Haz clic aquí para ver las soluciones y explicaciones

1. ¿Qué ventajas operativas y de seguridad aporta el almacenamiento centralizado y binario de journalctl frente a los ficheros tradicionales de texto plano en /var/log/?

El diario de systemd almacena los registros en formato binario estructurado e indexado criptográficamente, lo que acelera de forma drástica las consultas por rangos temporales o servicios, ocupa menos espacio gracias a la compresión y dificulta que un atacante modifique los ficheros de texto plano de manera silenciosa para borrar sus huellas.

2. ¿Qué función desempeñan los módulos PAM (Pluggable Authentication Modules) en la gestión de la identidad y la generación de registros dentro del sistema de autenticación de Linux?

PAM actúa como una capa de abstracción flexible que desacopla las aplicaciones del sistema (como SSH o los comandos de login) de los mecanismos subyacentes de verificación de credenciales (contraseñas, ficheros shadow, autenticación multifactor). Es el encargado central de validar los accesos y notificar mediante llamadas al sistema los eventos de éxito o fallo que quedan registrados en los logs de seguridad.

3. ¿Por qué es un requisito crítico de seguridad auditar periódicamente los eventos asociados al uso del comando sudo en los registros del sistema?

Porque permite trazar con absoluta precisión qué usuario con permisos estándar ha elevado sus privilegios a root y qué comandos exactos ha ejecutado, facilitando la detección de abusos de autoridad interna, errores accidentales en la administración o la suplantación de cuentas tras un robo de credenciales.

4. ¿Qué limitaciones temporales o de persistencia presentan los registros locales de un servidor frente a un atacante avanzado que lograse obtener privilegios de superusuario (root)?

Si un atacante compromete la cuenta de root, adquiere la capacidad técnica de alterar, falsificar o vaciar por completo los ficheros de registro locales y el diario del kernel, eliminando las evidencias de su intrusión. Por este motivo, en entornos corporativos críticos es obligatorio exportar los registros de seguridad en tiempo real hacia un servidor de logs remoto e independiente (Syslog centralizado o SIEM).