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.
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>.journalque 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.serviceoauditd.servicedeteniéndose fuera de un reinicio o de una actualización de paquetes,journalctl --vacuum-time,--vacuum-sizeo--rotateejecutados de forma interactiva,- registros de auditoría
CONFIG_CHANGE,auditctl -D(borrar todas las reglas) oauditctl -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,truncateo> filecontra/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/wtmpy 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; elln, sí),journalctl --vacuum-*,utmpdump -rpara 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.