Journal de systemd: el registro binario de Linux

Qué es

systemd-journald recoge los registros del kernel, del arranque temprano, de las llamadas syslog, de la API nativa del journal y del stdout/stderr de cada servicio systemd, y los guarda en archivos binarios indexados. Cada entrada es un conjunto de pares FIELD=value. Los campos cuyo nombre empieza por guion bajo los añade el propio journald a partir de la visión que tiene el kernel del emisor (PID, UID, ejecutable, unidad, ID de arranque), por lo que un proceso no puede falsificarlos escribiendo un mensaje falso.

En muchas instalaciones actuales el journal es el registro del sistema principal o incluso el único. Debian 12 dejó de instalar rsyslog por defecto, y Fedora lo retiró de las instalaciones por defecto ya en Fedora 20. Si falta /var/log/auth.log o /var/log/secure, revise el journal antes de concluir que se borraron los registros.

Dónde se encuentra

El destino de los datos depende de Storage=. volatile los mantiene en /run, persistent escribe en /var/log/journal, none los descarta y auto escribe en /var solo si /var/log/journal ya existe. auto fue el valor por defecto de upstream durante años; systemd 259 cambió el valor compilado por defecto a persistent (las distribuciones pueden modificarlo al compilar). Lea la configuración real de la imagen en lugar de suponer uno u otro.

La estructura es la misma en Debian/Ubuntu, RHEL/Fedora, SUSE y Arch. Las diferencias entre distribuciones están en si el almacenamiento persistente está activado y si rsyslog también se ejecuta en paralelo.

Qué prueba

• Qué unidad o proceso emitió un mensaje, con los campos fiables _PID, _UID, _COMM, _EXE, _CMDLINE y _SYSTEMD_UNIT.
• Arranques, paradas y fallos de servicios (por ejemplo, una unidad maliciosa que se inicia en el arranque, o la parada de rsyslog/auditd).
• Mensajes de sshd, sudo, su, PAM y cron, incluso cuando no existe ningún log de texto.
• Mensajes del kernel (_TRANSPORT=kernel): conexión de USB, carga de módulos, líneas LOG del cortafuegos, OOM kills, segfaults.
• Los límites de cada arranque mediante _BOOT_ID, que ponen de manifiesto reinicios inesperados y saltos de reloj.
• No prueba que un mensaje sea veraz: MESSAGE, SYSLOG_IDENTIFIER y PRIORITY los proporciona el cliente, y cualquier usuario local puede escribir entradas con logger o systemd-cat. Para la atribución, apóyese en los campos con guion bajo.
• No registra los comandos tecleados en una shell salvo que algo los registre.

Campos clave

El archivo en disco empieza con la firma LPKSHHRH. Los campos de la cabecera incluyen machine_id, tail_entry_boot_id, head_entry_realtime y tail_entry_realtime, y los objetos de datos pueden estar comprimidos con XZ, LZ4 o ZSTD.

Marcas de tiempo

Todas las horas del journal se guardan en microsegundos. __REALTIME_TIMESTAMP cuenta desde la época Unix en UTC; __MONOTONIC_TIMESTAMP cuenta desde el arranque y solo tiene sentido junto con _BOOT_ID. journalctl muestra las horas en la zona local del equipo de análisis salvo que se pase --utc.

# 1789874047512345 usec -> UTC
date -u -d @$((1789874047512345 / 1000000))
journalctl -D "$J" --utc -o short-iso-precise --since "2026-09-20 03:00" --until "2026-09-20 04:00"

Los valores realtime siguen el reloj del sistema, así que un reloj manipulado produce horas engañosas. Compare el orden monotónico dentro de un arranque y busque mensajes de ajuste de systemd-timesyncd o NTP.

Retención

Por defecto la retención depende del tamaño. SystemMaxUse= vale por defecto el 10 % del sistema de archivos, con un máximo de 4G; SystemKeepFree= vale por defecto el 15 %, también con un máximo de 4G; cada archivo rota al alcanzar un octavo de SystemMaxUse= (máximo 128M) o tras MaxFileSec= (un mes). MaxRetentionSec= está desactivado por defecto. En un servidor con mucha actividad el journal puede abarcar solo unos días, mientras que una VM tranquila puede conservar años. Las vías de borrado incluyen journalctl --vacuum-time/--vacuum-size/--vacuum-files, --rotate seguido de una purga, Storage=volatile o none, o simplemente eliminar los archivos como root.

Adquisición

Copie el directorio completo, incluidos los archivos .journal~, conservando propietarios y marcas de tiempo. En un host en vivo, recoja también /run/log/journal antes del apagado, porque no sobrevive a un reinicio.

# Live, as root
journalctl --flush                       # push /run data to /var if persistent
tar -C / -cpf /media/ir/journal.tar var/log/journal run/log/journal etc/systemd/journald.conf etc/systemd/journald.conf.d
journalctl -o export > /media/ir/journal.export   # lossless serialisation

# Dead box (read-only mount)
cp -a /mnt/evidence/var/log/journal /cases/2026-017/

UAC recoge *.journal y *.journal~ bajo /var/log (el journal volátil /run/log/journal solo lo cubre su artefacto aparte run_log, incluido en ir_triage y full) y ejecuta journalctl --list-boots; el artefacto Linux.Forensics.Journal de Velociraptor analiza los archivos directamente en el endpoint.

Análisis

journalctl en un equipo de análisis es el lector de referencia. Use una versión reciente: los lectores antiguos rechazan los archivos escritos con funciones incompatibles más nuevas (como el modo compacto).

J=/mnt/evidence/var/log/journal
journalctl -D "$J" --list-boots --utc
journalctl -D "$J" --header | less                # file ranges, boot IDs, state
journalctl -D "$J" -b all _TRANSPORT=kernel --utc # kernel messages from every boot
journalctl -D "$J" SYSLOG_IDENTIFIER=sshd SYSLOG_IDENTIFIER=sshd-session -o json > sshd.json
journalctl -D "$J" -F _SYSTEMD_UNIT               # every unit that ever logged
journalctl --file "$J/<machine-id>/system@*.journal~" --utc
journalctl -D "$J" --verify

El parser systemd_journal de Plaso incorpora las entradas a una super timeline, y parse_journald() de Velociraptor las expone en VQL. Linux Log Parser lee en el navegador auth.log / secure, syslog, los archivos del journal, audit.log y wtmp / btmp / lastlog, y los combina en una sola cronología con las sesiones de inicio reconstruidas; no se sube nada.

Consejos para la investigación

• Pase -D o --file siempre. Sin ellos, journalctl lee en silencio el journal del propio equipo de análisis.
• -k implica el arranque actual; en evidencias offline use _TRANSPORT=kernel -b all.
• Muchos archivos .journal~, fallos de --verify concentrados en torno al incidente o una lista de arranques que termina de golpe sin secuencia de apagado son pistas de manipulación o de un corte de corriente. Sin Forward Secure Sealing, --verify solo detecta corrupción, no una reescritura limpia.
• Correlacione _AUDIT_LOGINUID y _AUDIT_SESSION con los valores auid/ses de auditd y con las sesiones de wtmp.
• Una unidad que solo escribe por stdout sigue recibiendo _SYSTEMD_UNIT y _EXE, lo que convierte al journal en el mejor lugar para ver qué imprimió realmente una unidad systemd sospechosa.
• Si rsyslog también se ejecuta, compare ambos: una línea presente en el journal pero ausente de auth.log/secure apunta a una edición del log de texto.