Análisis forense de auth.log y secure: SSH, sudo y su

En resumen. auth.log (Debian, Ubuntu) y secure (familia RHEL) son los archivos donde rsyslog escribe las facilities auth y authpriv: sshd, sudo, su, PAM, passwd, useradd, sesiones de cron. Agrupa las líneas de sshd por PID para reconstruir cada conexión, cuenta los fallos por dirección de origen, busca el primer éxito posterior y sigue después la sesión hasta sudo. Identifica el formato de la marca de tiempo antes de convertir nada.

Qué archivo y qué formato

Los dos formatos, uno junto a otro:

Sep 14 10:02:11 fin-jump-01 sshd[3071]: Accepted password for svc_backup from 203.0.113.45 port 51544 ssh2
2026-09-14T10:02:11.482113+00:00 fin-jump-01 sshd[3071]: Accepted password for svc_backup from 203.0.113.45 port 51544 ssh2

Para la primera forma (estilo RFC 3164), lee la zona desde /etc/localtime y deduce el año a partir de la fecha de modificación del archivo y del orden de rotación. Un archivo que abarca el cambio de año contiene líneas de diciembre seguidas de líneas de enero; las de enero pertenecen al año siguiente. En los cambios de horario de verano, las horas locales pueden repetirse o saltarse una hora.

Debian 12 y algunas instalaciones de Fedora no tienen rsyslog. La ausencia de auth.log no prueba un borrado; revisa el journal de systemd.

SSH: reconstruir cada conexión por PID

Cada conexión tiene su propio proceso sshd (en OpenSSH 9.8 y posteriores, el proceso por conexión es sshd-session, así que busca ambos nombres). Todas las líneas de una conexión comparten ese PID:

sshd[2381]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=198.51.100.23  user=svc_backup
sshd[2381]: Failed password for svc_backup from 198.51.100.23 port 40135 ssh2
sshd[2381]: Connection closed by authenticating user svc_backup 198.51.100.23 port 40135 [preauth]

Mensajes clave:

Las líneas pam_unix proceden del módulo pam_unix; systemd-logind: New session 7 of user X aparece a los pocos milisegundos y asigna a la sesión un número que también figura en el journal como session-7.scope.

Intentos de adivinar la contraseña y después un éxito

El patrón relevante no es «muchos fallos» (todo servidor SSH expuesto a Internet los tiene), sino fallos seguidos de un éxito:

1. Cuenta las líneas Failed password e Invalid user por dirección de origen y enumera los nombres de cuenta probados.
2. Busca una línea Accepted para cualquiera de esas cuentas después del último fallo, desde la misma dirección o desde otra. Una dirección distinta minutos después es habitual: los intentos se lanzaron desde una máquina y el inicio de sesión, desde otra.
3. Comprueba si el método que tuvo éxito es password para una cuenta que normalmente inicia sesión con publickey. Una cuenta de servicio que siempre usó una clave y de repente usa una contraseña es una pista sólida.
4. Compara la dirección de origen con el historial de la cuenta. Un inicio de sesión desde una dirección nunca vista para esa cuenta merece una pregunta a su propietario.

zgrep -hE 'sshd(-session)?\[[0-9]+\]: (Failed password|Invalid user)' auth.log* | grep -oE 'from [0-9a-f.:]+' | sort | uniq -c | sort -rn
zgrep -hE 'sshd(-session)?\[[0-9]+\]: Accepted' auth.log*

Recuerda que, en un host que ejecuta rsyslog y journald a la vez, cada línea existe dos veces; contar juntos el journal y auth.log duplica las cifras. btmp guarda una tercera copia de los intentos fallidos.

sudo y su

sudo escribe una línea por comando:

sudo:   svc_backup : TTY=pts/1 ; PWD=/home/svc_backup ; USER=root ; COMMAND=list
sudo:   svc_backup : TTY=pts/1 ; PWD=/home/svc_backup ; USER=root ; COMMAND=/bin/bash
sudo:   pam_unix(sudo-i:session): session opened for user root(uid=0) by svc_backup(uid=1001)

• COMMAND=list es sudo -l: el usuario comprueba qué permisos tiene. A menudo es lo primero que ejecuta un intruso.
• COMMAND=/bin/bash con el servicio PAM sudo-i es sudo -i, una shell de root interactiva. A partir de ese momento, auth.log ya no ve los comandos individuales; solo se registran los comandos que vuelven a pasar por sudo. Sigue la sesión en auditd, donde auid conserva el usuario original.
• Fallos: user NOT in sudoers, command not allowed, N incorrect password attempts y pam_unix(sudo:auth): authentication failure.
• su registra pam_unix(su:session): session opened for user root by X (o su-l para su -) y, en caso de fallo, mensajes del tipo FAILED SU, según la distribución.

Los espacios en los argumentos de sudo se registran tal cual, lo que vuelve ambiguas algunas líneas de comando (¿/srv/finance/Q3 close es un argumento o dos?). El registro de auditoría USER_CMD codifica esos valores en hexadecimal y resuelve la duda.

Cuentas y contraseñas

• Líneas useradd[PID]: new user: name=..., groupadd, usermod y gpasswd para los cambios de cuentas.
• passwd[PID]: pam_unix(passwd:chauthtok): password changed for X cuando se cambia una contraseña. Un intruso que cambia la contraseña de la cuenta por la que entró deja fuera al propietario y conserva el acceso.
• chpasswd y chage para cambios masivos y de caducidad.

Cron

CRON[PID]: pam_unix(cron:session): session opened for user X aparece en auth.log por cada ejecución de una tarea; el comando en sí está en syslog (CRON[PID]: (X) CMD (...)), y la edición de un crontab aparece como crontab[PID]: (root) REPLACE (X). Un nuevo crontab de usuario instalado durante una sesión interactiva es una pista de persistencia.

Hacerlo más rápido

Linux Log Parser lee auth.log, secure, syslog y messages en los tres formatos, incluidos los archivos rotados y .gz, reconstruye las sesiones a partir de las parejas de PID de sshd y de logind, marca las líneas que también existen en el journal e informa de intentos de adivinar contraseñas seguidos de un éxito, inicios de sesión desde una dirección nueva, inicios de sesión SSH como root, shells de root con sudo y su, sudo fallidos y cambios de cuentas. El caso práctico de investigación muestra estos hallazgos sobre un ejemplo.

Tablas de referencia: auth.log y syslog, logs de sudo y artefactos de SSH en linuxforensics.app.