Logs de sudo: uso de privilegios en Linux

Qué es

El plugin de política sudoers de sudo registra cada petición aceptada y rechazada. Por defecto envía una línea por evento a syslog, con la facility authpriv cuando está disponible (prioridad notice para las permitidas, alert para las denegadas). Esas líneas acaban en el log de texto de autenticación y en el journal. Ajustes opcionales añaden un archivo de log dedicado, salida JSON, el código de salida, el registro de subcomandos y grabaciones completas de las pulsaciones y la pantalla de las sesiones.

La propia política (/etc/sudoers y sus directorios de inclusión) también es evidencia: un atacante que añade una regla NOPASSWD ha creado persistencia y ha eliminado la petición de contraseña que, de otro modo, aparecería como evento de autenticación.

Dónde se encuentra

Qué prueba

• La cuenta que invoca, el usuario de destino (USER=), el terminal, el directorio de trabajo y la línea de comandos completa de cada comando permitido.
• Las denegaciones: user NOT in sudoers, user NOT authorized on host, command not allowed, N incorrect password attempts, a password is required.
• El contexto PAM que lo rodea: pam_unix(sudo:session): session opened for user root(uid=0) by deploy(uid=1001) y pam_unix(sudo:auth): authentication failure.
• Con registro de E/S: exactamente lo que se tecleó y se mostró, reproducible.
• No muestra lo que ocurrió dentro de sudo -i, sudo -s o sudo bash: el log solo registra la shell. Para eso, use auditd (auid), el historial de la shell, log_subcmds o los logs de E/S.
• Un usuario con root puede editar estos logs, y cualquiera puede inyectar líneas de aspecto similar con logger.

Campos clave

Comando aceptado, formato de log de sudo:

Sep 20 03:15:30 web-prod-03 sudo:   deploy : TTY=pts/0 ; PWD=/home/deploy ; USER=root ; COMMAND=/usr/bin/bash
Sep 20 03:16:02 web-prod-03 sudo:   deploy : TTY=pts/0 ; PWD=/tmp ; USER=root ; TSID=000001 ; COMMAND=/usr/bin/tar -xf /tmp/x.tar
Sep 20 03:17:44 web-prod-03 sudo:   intern : user NOT in sudoers ; TTY=pts/1 ; PWD=/home/intern ; USER=root ; COMMAND=/usr/bin/id

Los caracteres de control se registran en octal precedidos de # (#011 para el tabulador), y los espacios en la ruta del comando aparecen como #040. Con log_format=json, el archivo de log contiene objetos JSON con todos los detalles del usuario y el entorno.

Registro de auditoría de la misma acción (familia RHEL):

type=USER_CMD msg=audit(1789874130.201:8830): pid=4302 uid=1001 auid=1001 ses=12 msg='cwd="/home/deploy" cmd="/usr/bin/bash" terminal=pts/0 res=success'

cmd y cwd se codifican en hexadecimal cuando contienen espacios; ausearch -i los decodifica.

Marcas de tiempo

Las líneas de syslog heredan el formato del demonio syslog: hora local tradicional sin año con la configuración por defecto de RHEL, RFC 3339 con desfase en Debian 12+ y Ubuntu 24.04 (ver auth.log). La copia del journal tiene una marca de tiempo UTC en microsegundos y es el punto de referencia más sencillo. El archivo de log propio de sudo usa una fecha de estilo Mmm dd HH:MM:SS y solo añade el año con log_year. Los logs de E/S registran el inicio de la sesión en el archivo log/log.json y los retardos relativos en timing.

Retención

La copia de syslog dura lo mismo que auth.log/secure (unas cuatro generaciones semanales por defecto) y la copia del journal lo que permitan sus límites de tamaño. sudo nunca rota los logs de E/S; el ID de sesión de seis caracteres en base 36 (00/00/01) vuelve a empezar al llegar a maxseq, y a partir de ahí se sobrescriben las sesiones antiguas. Los archivos de aviso y ~/.sudo_as_admin_successful persisten hasta que se borran.

Adquisición

E=/mnt/evidence
tar -C "$E" -cpf /cases/2026-017/sudo.tar \
  etc/sudoers etc/sudoers.d var/log/sudo-io var/lib/sudo var/db/sudo 2>/dev/null
journalctl -D "$E/var/log/journal" SYSLOG_IDENTIFIER=sudo -o json --utc > sudo-journal.json
zgrep -h 'sudo:' "$E"/var/log/auth.log* "$E"/var/log/secure* 2>/dev/null > sudo-lines.txt

UAC recoge /var/log, /etc y las marcas de tiempo de aviso de sudo (artefacto sudo_lectured). En un sistema en vivo, sudo -l -U <user> muestra los derechos efectivos de una cuenta sin modificar nada.

Análisis

# Allowed commands per invoking user
zgrep -h 'COMMAND=' auth.log* | sed -E 's/.*sudo: +([^ ]+) : .*USER=([^ ]+) ; .*COMMAND=(.*)/\1 -> \2 : \3/' | sort | uniq -c
# Failures
zgrep -hE 'sudo:.*(NOT in sudoers|not allowed|incorrect password)' auth.log*
# Replay a recorded session (read-only)
sudoreplay -d /cases/2026-017/var/log/sudo-io -l
sudoreplay -d /cases/2026-017/var/log/sudo-io 000001
# Audit copy
ausearch -if audit.log -m USER_CMD -i

Cada directorio de sesión de E/S contiene log, log.json, timing, ttyin, ttyout, stdin, stdout y stderr. Plaso recoge las líneas de sudo mediante sus parsers de syslog. 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

• Revise cada archivo de /etc/sudoers.d/ y su mtime/ctime. Las entradas nuevas NOPASSWD: ALL, Defaults !syslog, !log_allowed o syslog_goodpri=none silencian el registro y son indicadores sólidos.
• COMMAND=/usr/bin/bash, /bin/su, editores, find, less, vi o intérpretes indican que la actividad real ocurrió en un proceso hijo; siga el auid en audit.log y el historial de la shell de la cuenta.
• Un sudo correcto sin una petición pam_unix(sudo:auth) previa es normal dentro de timestamp_timeout (5 minutos por defecto) o con NOPASSWD; los archivos de /run/sudo/ts/ solo existen en un sistema en vivo.
• El archivo de aviso se crea la primera vez que sudo muestra su aviso junto con la petición de contraseña (por defecto lecture=once). Sus marcas de tiempo y el ~/.sudo_as_admin_successful de Ubuntu dan una fecha de primer uso de sudo por cuenta, útil para cuentas recién creadas por un atacante (ver cuentas).
• Las líneas con TTY=unknown proceden de scripts, cron o SSH no interactivo; correlacione con cron y con las líneas de sshd.
• Compare las copias del log de texto, del journal y de auditoría: un evento de sudo en el journal pero no en auth.log apunta a una edición del archivo de texto.