Introducción
En los campos de la administración de sistemas y la ciberseguridad, el análisis de registros (logs) es una habilidad crítica. Los registros del sistema registran una amplia gama de eventos, desde operaciones rutinarias hasta errores críticos y posibles brechas de seguridad. Ser capaz de navegar e interpretar eficazmente estos registros es esencial para monitorear la salud del sistema, solucionar problemas y responder a incidentes de seguridad.
Este laboratorio te introduce a journalctl, la herramienta estándar para consultar y mostrar registros del servicio journald en sistemas Linux modernos. Aprenderás a realizar tareas básicas de análisis de registros que forman la base del monitoreo y la respuesta a incidentes.
A lo largo de este laboratorio, usted:
- Revisará los registros de arranque del sistema.
- Filtrará registros para encontrar eventos específicos como fallos de autenticación.
- Simulará y detectará un evento sospechoso.
- Exportará registros para un análisis posterior.
Revisar Registros de Arranque del Sistema con Journalctl
En este paso, aprenderá a usar el comando journalctl para revisar los registros del sistema, centrándose específicamente en los mensajes generados durante el proceso de arranque más reciente. Este es un primer paso común al diagnosticar problemas de inicio.
El comando journalctl le permite consultar el contenido del journal de systemd. Sin ningún argumento, muestra todos los registros, lo que puede ser abrumador.
Para hacer la salida más manejable, podemos usar la opción -b o --boot para ver solo los registros de la sesión de arranque actual.
Ejecute el siguiente comando en su terminal para ver los registros del arranque actual:
journalctl -b
Verá una salida paginada que comienza con los mensajes más antiguos del proceso de arranque. Puede usar las teclas de flecha Arriba y Abajo para navegar. Presione q para salir del paginador y volver al prompt del comando.
-- Journal begins at Tue 2023-10-31 08:30:00 UTC, ends at Tue 2023-10-31 09:00:00 UTC. --
Oct 31 08:30:01 labex-vm kernel: Linux version 5.15.0-87-generic ...
Oct 31 08:30:01 labex-vm kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-5.15.0-87-generic ...
Oct 31 08:30:01 labex-vm kernel: KERNEL supported cpus:
Oct 31 08:30:01 labex-vm kernel: Intel GenuineIntel
Oct 31 08:30:01 labex-vm kernel: AMD AuthenticAMD
...
(END)
Este comando es invaluable para comprender qué servicios se iniciaron correctamente y para identificar cualquier error que ocurriera durante el inicio del sistema.
Filtrar Registros de Fallos de Autenticación
En este paso, filtrará el journal para encontrar eventos específicos, como intentos de autenticación fallidos, que son críticos para el monitoreo de seguridad. Un objetivo común para los atacantes es el servicio SSH, por lo que monitorear sus registros es una alta prioridad.
Podemos usar la opción -u con journalctl para filtrar registros por una unidad systemd específica. Para el servicio SSH, la unidad suele ser ssh.service (en Ubuntu/Debian) o sshd.service (en Red Hat/CentOS).
Filtremos los registros para ver solo las entradas relacionadas con el demonio SSH. Tenga en cuenta que es posible que necesite usar sudo para ver los registros del sistema:
sudo journalctl -u ssh
Este comando muestra todas las entradas de registro generadas por el servicio sshd. Para acotar nuestra búsqueda a posibles problemas de seguridad, podemos canalizar esta salida al comando grep para buscar palabras clave como "Failed".
Ejecute el siguiente comando para encontrar intentos de contraseña fallidos para el servicio SSH:
sudo journalctl -u ssh | grep "Failed password"
Si no ha habido intentos de inicio de sesión fallidos recientes, este comando puede no producir ninguna salida. Esto es normal en un sistema seguro. En el siguiente paso, generaremos nosotros mismos dicho evento para ver cómo aparece en los registros.
Simular un Evento Sospechoso y Analizar Registros
Ahora, simularemos un evento sospechoso y luego utilizaremos nuestras habilidades de análisis de registros para detectarlo. Un signo común de un ataque de fuerza bruta es una serie de intentos de inicio de sesión fallidos. Simularemos uno de estos intentos intentando conectarnos por SSH a nuestra propia máquina (localhost) con un nombre de usuario que no existe.
Ejecute el siguiente comando en su terminal. Se le pedirá una contraseña; puede ingresar cualquier cosa, ya que se espera que falle.
ssh non_existent_user@localhost
El sistema denegará la conexión, que es el resultado esperado. Debería ver un mensaje como este:
non_existent_user@localhost's password:
Permission denied, please try again.
non_existent_user@localhost's password:
Permission denied (publickey,password).
Ahora que hemos generado un evento de inicio de sesión fallido, volvamos a ejecutar nuestro comando de análisis de registros del paso anterior para ver si podemos encontrarlo.
sudo journalctl -u ssh | grep "Failed password"
Esta vez, el comando debería producir una salida que muestre el intento fallido que acabamos de realizar.
Oct 31 09:15:12 labex-vm sshd[1234]: Failed password for invalid user non_existent_user from 127.0.0.1 port 48492 ssh2
Este simple ejercicio demuestra el ciclo central de respuesta a incidentes: ocurre un evento, se registra y un administrador o sistema automatizado analiza los registros para detectarlo.
Exportar Registros para Simulación de Análisis Centralizado
En un escenario del mundo real, a menudo exportaría registros de máquinas individuales a un servidor de registro centralizado (como un SIEM) para almacenamiento a largo plazo y correlación. En este paso, simularemos esto exportando nuestros registros SSH recientes a un archivo.
journalctl puede generar registros en varios formatos. El formato json-pretty es particularmente útil, ya que es legible por humanos y fácil de analizar por otras herramientas.
Exportemos todos los registros SSH de los últimos 10 minutos a un archivo llamado ssh_logs.json en su directorio actual (~/project).
sudo journalctl -u ssh --since "10 minutes ago" -o json-pretty > ~/project/ssh_logs.json
Ahora, verifique que el archivo se ha creado:
ls -l ~/project
Debería ver ssh_logs.json en el listado de archivos.
total 4
-rw-r--r-- 1 labex labex 1234 Oct 31 09:20 ssh_logs.json
Finalmente, veamos el contenido de nuestro archivo de registro exportado.
cat ~/project/ssh_logs.json
La salida será una matriz JSON estructurada, con cada entrada de registro como un objeto. Este formato es ideal para la ingesta en otras plataformas de análisis.
[
{
"__CURSOR" : "s=...",
"__REALTIME_TIMESTAMP" : "...",
"__MONOTONIC_TIMESTAMP" : "...",
"_BOOT_ID" : "...",
"_TRANSPORT" : "syslog",
"PRIORITY" : "6",
"SYSLOG_FACILITY" : "4",
"SYSLOG_IDENTIFIER" : "sshd",
"MESSAGE" : "Failed password for invalid user non_existent_user from 127.0.0.1 port 48492 ssh2",
"_PID" : "1234",
...
}
]
Ha simulado con éxito el proceso de preparación de registros para análisis centralizado.
Resumen
En este laboratorio, adquirió experiencia práctica con journalctl, una herramienta potente para el análisis de registros en sistemas Linux modernos. Estas son habilidades fundamentales para cualquier administrador de sistemas, ingeniero DevOps o profesional de seguridad.
Ha aprendido a:
- Revisar registros del sistema y de arranque para diagnosticar problemas de inicio.
- Filtrar registros por servicios específicos y contenido de mensajes para encontrar eventos relevantes.
- Identificar actividades sospechosas, como inicios de sesión fallidos, a partir de las entradas de registro.
- Exportar registros en un formato estructurado como JSON para almacenamiento centralizado y análisis posterior.
Dominar estas técnicas le permitirá monitorear mejor sus sistemas, solucionar problemas de manera más eficiente y dar los primeros pasos en la respuesta a incidentes de seguridad.
