Saltar al contenido

4.4 Auditoría Forense y Logs

¡Prepárate!

  • Aprenderás DÓNDE guarda Linux todos los registros históricos (/var/log). - Entenderás qué ficheros leer para hackeos (auth.log) o para errores de discos (syslog). - Aprenderás la magia de filtrar miles de líneas instantáneamente con el lector binario journalctl.

Si un servidor se cae, el Administrador Junior entra en pánico, mira la pantalla negra e intenta reiniciar. El Administrador Senior (LFCS) nunca adivina. Sabe que Linux es un “chivato” compulsivo que registra absolutamente todo lo que pasa en el sistema, desde el momento en que se enchufa un pendrive hasta el milisegundo en que alguien falla una contraseña.

Ese registro inmenso de la verdad se llama comúnmente Logs.


Por tradición histórica (y todavía en uso), casi todos los programas del mundo Linux que no tienen interfaz gráfica guardan sus lamentos y triunfos en forma de texto plano dentro de subcarpetas en /var/log.

Como estos archivos crecen cientos de Megabytes a la semana, no puedes abrirlos con un editor pesado como nano porque colapsaría. Siempre debes leer logs usando el visor ágil less o el rastreador tail.

  • /var/log/syslog (en Debian) o /var/log/messages (en RHEL): El diario general del sistema. Aquí acaba la basura genérica.
  • /var/log/auth.log (o secure): El diario ultra-sensible. Todo inicio de sesión por SSH, todos los usos del comando sudo y los errores de contraseña se listan aquí obligatoriamente.
  • /var/log/dmesg: Mensajes exclusivos de hardware. Útil para ver por qué la placa base no reconoce la tarjeta de red.
  • /var/log/nginx/ o /var/log/apache2/: Carpetas exclusivas que crean los servidores web para separar sus millones de accesos de la basura del sistema.

Desde que irrumpió Systemd (el rey de la Fase 5 del que hablamos en la lección anterior), trajo consigo su propio sistema recolector de logs llamado systemd-journald.

En lugar de crear archivos de texto plano desordenados, journald traga millones de logs de todos los demonios instalados y los comprime en un formato binario indexado. Como es binario, no puedes abrirlo con cat o nano. Tienes que interrogar a la base de datos usando su herramienta oficial: journalctl.

journalctl es tan inmensamente superior a buscar textos a mano en /var/log, que se ha convertido en la herramienta principal requerida en el examen LFCS.

Ejecutar journalctl a secas te escupiría 500,000 líneas a la cara. Siempre debemos filtrar:

  • Filtrar por Servicio Específico (-u de unit): journalctl -u sshd (Muestra TODOS los logs de la historia de los inicios de sesión).

  • Filtrar por Tiempo (--since y --until): journalctl -u apache2 --since "yesterday" (Logs del servidor web desde ayer). journalctl --since "2024-05-30 08:00:00" --until "2024-05-30 10:00:00" (Descubrir qué mató al servidor concretamente en ese rango de dos horas).

  • Filtrar por Severidad (-p de priority): journalctl -p err (Silencia toda la información irrelevante y te escupe directa y únicamente los Errorres Fatales reales del sistema).

  • La Combinación Definitiva (Modo Sysadmin en Llamas):

    ventana terminal
    # "Dime qué errores graves han ocurrido en el servicio Nginx durante la última hora del reloj"
    journalctl -u nginx -p err --since "1 hour ago"

  1. Son las 4:00 AM, está sonando tu buscapersonas telefónico y el cliente jura que el programa principal de facturación dejó de responder a eso de las “tres y media”. No tienes tiempo de leer el larguísimo texto general syslog buscando a ciegas. Tienes Systemd activo, túnel a internet y necesitas un bisturí. ¿Qué comando ejecutas para ir al grano forense?

  2. Acabas de alquilar un VPS barato en un proveedor desconocido en Internet poniéndole un usuario simple. Tienes la paranoia extrema de que alguien ha conseguido acceder a tu Debian adivinando la contraseña mientras tú logueabas esta mañana a las 9. ¿Qué fichero de texto plano ancestral debes inspeccionar en vivo con less para confirmar tus sospechas?

  3. Hay un usuario Junior escribiendo un script gigantesco en el directorio temporal, y quiere que mires la pantalla porque “siempre que ejecuta su script de limpieza, el servidor explota, pero es incapaz de leer el error porque la pantalla se desliza rapidísimo tapándolo con nuevas líneas en décimas de segundo”. ¿Cómo te pegas en vivo a la cañería del archivo custom del usuario /var/log/script_junior.log para ver matrizamente cómo cae el error el momento que él pulse Enter?