Skip to content

Detectar manipulación de logs en Linux: huecos y borrados

Cómo probar que se editaron o borraron logs de Linux: huecos de seqnum, líneas ausentes de auth.log, registros wtmp a cero, daemons detenidos y borrados.

Publicado el 5 min de lectura

En resumen. Root puede editar cualquier log de un host Linux por separado. Lo que un intruso rara vez consigue es editarlos todos de forma coherente. La manipulación se manifiesta como discrepancias entre fuentes (una línea en el journal pero no en auth.log, una sesión en audit.log pero no en wtmp, una hora de lastlog sin registro en wtmp) y como daños estructurales (huecos en los números de secuencia, registros a cero, archivos truncados, daemons detenidos). Descarta las causas inocentes y después expón lo que dice cada fuente.

1. Huecos en los números de secuencia del journal

Cada entrada del journal lleva un número de secuencia procedente de un contador que comparten todos los archivos de journal de la máquina. Borrar un archivo de journal completo, o reescribir un archivo sin algunas entradas, deja un rango de números que ninguna entrada recopilada contiene.

Explicaciones inocentes que conviene descartar primero:

  • Archivos user-<UID>.journal que no se recopilaron (sus entradas usan el mismo contador).
  • Archivos archivados eliminados por la política de retención (el hueco está al principio del rango).
  • Una recopilación hecha mientras journald escribía (el hueco está justo al final).

Un hueco en mitad de la ventana del incidente, con los journals de usuario presentes, o uno que coincide con un rm de un archivo de journal en audit.log o en una línea de sudo, es un hallazgo. La cabecera del journal también ayuda: head_entry_seqnum y tail_entry_seqnum indican qué rango debería contener un archivo. Consulta el análisis forense del journal.

2. Líneas de autenticación en el journal que faltan en auth.log

En la mayoría de los hosts con systemd, rsyslog recibe sus líneas de journald. Por eso el mismo mensaje de sshd, sudo o PAM existe en ambos lugares. Si el journal contiene Accepted password for X from IP y auth.log, que cubre ese periodo, no lo contiene, el archivo de texto se editó (normalmente con sed -i o con un limpiador de logs que solo conoce los archivos de texto).

Comprueba primero la cobertura: la línea debe caer entre la primera y la última línea de las generaciones de auth.log que tienes, y rsyslog debía estar en ejecución (su arranque y su parada figuran en el journal). El caso inverso, una línea en auth.log pero no en el journal, suele significar que el journal no conservó ese periodo.

3. Registros de inicio de sesión a cero o truncados

Los limpiadores de wtmp sobrescriben un registro con ceros para que el tamaño del archivo siga alineado. Señales:

  • registros completamente a cero (tipo 0, sin usuario, fecha de 1970 en utmpdump),
  • un tamaño de archivo que no es múltiplo del tamaño de registro (384 bytes en x86_64, 400 en aarch64),
  • marcas de tiempo que retroceden entre registros consecutivos,
  • un wtmp o btmp de cero bytes con una fecha de modificación antigua en un servidor en uso.

Después, contrasta: una sesión SSH interactiva que muestran auth.log, el journal y audit.log, pero no wtmp, aunque wtmp cubra ese momento; o una entrada de lastlog (el último inicio de sesión de un UID) más reciente que cualquier sesión de ese usuario en wtmp. Recuerda que el SSH no interactivo (comandos, scp, sftp) a menudo no tiene ningún registro en wtmp. Más detalles en la guía de wtmp.

4. Registro detenido o reconfigurado

Busca:

  • rsyslog.service, systemd-journald.service o auditd.service deteniéndose fuera de un reinicio o de una actualización de paquetes,
  • journalctl --vacuum-time, --vacuum-size o --rotate ejecutados de forma interactiva,
  • registros de auditoría CONFIG_CHANGE, auditctl -D (borrar todas las reglas) o auditctl -e 0 (desactivar),
  • modificaciones de /etc/rsyslog.conf, /etc/rsyslog.d/, journald.conf (Storage=none, volatile) o /etc/audit/rules.d/,
  • un log de texto que se detiene a mitad del día mientras el journal sigue funcionando: el problema está en el daemon de syslog.

Los reinicios y las actualizaciones también detienen servicios; lee lo que rodea a cada evento.

5. Comandos que borran logs e historial

audit.log (con una regla de execve), las líneas de sudo y el journal pueden capturar el propio borrado:

  • rm, shred, truncate o > file contra /var/log/*, archivos del journal o /var/log/wtmp,
  • scripts ejecutados con la ruta de un log como argumento, como un script de Python al que se le pasa /var/log/wtmp y un nombre de usuario,
  • ln -sf /dev/null ~/.bash_history, unset HISTFILE, export HISTSIZE=0, history -c (los builtins y los cambios de variables no dejan registro execve; el ln, sí),
  • journalctl --vacuum-*, utmpdump -r para reescribir wtmp a partir de texto editado.

logrotate borra archivos antiguos como root desde cron según una programación; un comando interactivo desde una sesión de usuario es otra cosa.

6. Manipulación de la hora

Un reloj atrasado a mano hace que los eventos parezcan más antiguos. En el journal, un realtime que baja mientras los números de secuencia suben lo pone en evidencia; los mensajes de systemd-timesyncd o NTP y las entradas de cambio de hora ayudan. En wtmp, el equivalente son los registros que retroceden en el tiempo.

Redactarlo

Para cada indicador, expón lo que muestra la evidencia y qué otra cosa podría explicarlo. «Faltan números de secuencia del journal entre las 10:02 y las 10:50; no se encontró user-1001.journal; una línea de sudo a las 10:44:10 muestra rm -f ejecutado sobre ese archivo» es un hallazgo. «Se borraron logs» es una conclusión a la que el lector debería poder llegar a partir de él.

En el navegador

Linux Log Parser comprueba estos puntos automáticamente: huecos de secuencia en el journal (con una advertencia cuando no se cargó ningún journal de usuario), líneas de autenticación en el journal que faltan en auth.log, registros de wtmp a cero, parciales o con hora que retrocede, daemons de registro que se detienen, vacuums del journal y cambios en las reglas de auditoría, comandos de borrado de logs e inicios de sesión interactivos sin registro en wtmp. Cada hallazgo enumera los eventos en los que se basa. El caso práctico muestra tres de ellos en una misma intrusión, y la ficha de auth.log enumera más indicios de manipulación por fuente.

Artículos relacionados

Cómo encajan las cuatro familias de logs de Linux en una investigación, qué prueba cada una, dónde discrepan y cómo unirlas en una sola línea de tiempo.
Análisis forense del journal de systemd sin journalctl: formato, campos de confianza, compresión, huecos de seqnum, archivos .journal~ y campos de hora.
Qué recopilar para investigar logs de Linux y cómo: un comando tar en un host en vivo, journalctl, ausearch, UAC, Velociraptor o una imagen de disco montada.