Trazabilidad y auditoría de accesos en Linux

1. Fundamentos de la trazabilidad

La trazabilidad es la cuarta fase del acceso y deja constancia de quién hizo qué, cuándo y desde dónde. Sin ella, las otras tres fases no pueden verificarse. Un sistema puede identificar, autenticar y autorizar correctamente y, aun así, ser imposible de investigar tras un incidente si no conserva evidencias fiables.

Los registros cumplen tres funciones distintas:

Detección: revelan intentos de fuerza bruta, accesos desde orígenes inesperados o elevaciones de privilegios mientras ocurren.
Investigación: permiten reconstruir la secuencia de un incidente y delimitar qué cuentas, archivos y máquinas resultaron afectados.
Responsabilidad: atribuyen cada acción a una persona concreta, lo que exige cuentas nominales y no compartidas.

Un registro solo es útil como evidencia si cumple cinco propiedades:

Propiedad Significado Consecuencia técnica en Linux

Propiedad	Significado	Consecuencia técnica en Linux
Completitud	Se registran todos los eventos relevantes	Reglas de `auditd` y niveles de registro adecuados
Integridad	Nadie puede modificar o borrar entradas sin dejar rastro	Permisos estrictos, atributo `append-only` y copia remota
Imputabilidad	Cada evento se asocia a una identidad real	Cuentas nominales y uso de `sudo` en lugar de `su` con contraseña compartida
Sincronización	Las marcas de tiempo son comparables entre sistemas	Servicio NTP activo y zona horaria definida
Retención	Los registros se conservan el tiempo necesario	Rotación, límites de tamaño y almacenamiento centralizado

Completitud

Se registran todos los eventos relevantes

Reglas de auditd y niveles de registro adecuados

Integridad

Nadie puede modificar o borrar entradas sin dejar rastro

Permisos estrictos, atributo append-only y copia remota

Imputabilidad

Cada evento se asocia a una identidad real

Cuentas nominales y uso de sudo en lugar de su con contraseña compartida

Sincronización

Las marcas de tiempo son comparables entre sistemas

Servicio NTP activo y zona horaria definida

Retención

Los registros se conservan el tiempo necesario

Rotación, límites de tamaño y almacenamiento centralizado

Los registros contienen datos personales

Una dirección IP, un nombre de usuario o la hora de conexión de una persona son datos personales según el RGPD. La política de registro debe justificar qué se recoge, limitar el acceso a esos archivos y definir un plazo de conservación proporcionado.

La manipulación de los registros es una técnica habitual tras un compromiso. MITRE ATT&CK la recoge como Clear Linux or Mac System Logs (T1070.002) y como Disable or Modify Tools (T1562.001), y el uso de credenciales robadas como Valid Accounts (T1078). Por eso las medidas de este capítulo se orientan tanto a recoger los eventos como a protegerlos.

1.1. Eventos de acceso que conviene registrar

Evento Qué se quiere saber Dónde queda registrado

Evento	Qué se quiere saber	Dónde queda registrado
Inicio de sesión correcto o fallido	Quién, desde qué origen y con qué método	`auth.log`, `journalctl -u ssh`, `wtmp` y `btmp`
Uso de `sudo` y `su`	Quién ejecutó qué con privilegios	`auth.log` y registros `USER_CMD` de `auditd`
Alta, baja o cambio de cuentas y grupos	Quién modificó la identidad	`auth.log` y reglas de `auditd` sobre `/etc/passwd`
Cambio de la política de acceso	Quién tocó PAM, `sudoers` o SSH	Reglas de `auditd` sobre `/etc/pam.d/` y `/etc/sudoers.d/`
Bloqueo de cuentas	Qué cuentas alcanzaron el umbral de fallos	`faillock` y `auth.log`
Arranques y paradas del sistema	Ventanas sin supervisión	`last -x` y `journalctl --list-boots`

Inicio de sesión correcto o fallido

Quién, desde qué origen y con qué método

auth.log, journalctl -u ssh, wtmp y btmp

Uso de sudo y su

Quién ejecutó qué con privilegios

auth.log y registros USER_CMD de auditd

Alta, baja o cambio de cuentas y grupos

Quién modificó la identidad

auth.log y reglas de auditd sobre /etc/passwd

Cambio de la política de acceso

Quién tocó PAM, sudoers o SSH

Reglas de auditd sobre /etc/pam.d/ y /etc/sudoers.d/

Bloqueo de cuentas

Qué cuentas alcanzaron el umbral de fallos

faillock y auth.log

Arranques y paradas del sistema

Ventanas sin supervisión

last -x y journalctl --list-boots

1.2. Arquitectura del registro en Ubuntu

Figura 1. Arquitectura de registro y auditoría en Linux: orígenes, recolectores y destinos

En Ubuntu conviven tres mecanismos complementarios, que no se sustituyen entre sí:

journald recoge los mensajes de los servicios y del núcleo en un diario estructurado, consultable con journalctl. En Ubuntu es persistente, porque existe el directorio /var/log/journal/.
rsyslog recibe esos mensajes y los escribe en los archivos de texto tradicionales, como /var/log/auth.log y /var/log/syslog, según las reglas de /etc/rsyslog.d/. Es también el componente habitual para enviarlos a otra máquina.
auditd registra lo que el propio núcleo observa: llamadas al sistema y accesos a archivos vigilados. Es independiente de los anteriores, no depende de que la aplicación decida registrar algo y no está instalado por defecto.

Los registros de sesiones son un caso aparte, ya que login, sshd y getty escriben directamente en los archivos binarios /var/run/utmp, /var/log/wtmp y /var/log/btmp, que se leen con who, last y lastb.

Los mensajes de sshd, sudo y PAM llegan tanto a journald como a auth.log. Esto no es una duplicación inútil, porque el diario ofrece búsqueda estructurada y los archivos de texto son el formato que consumen la mayoría de herramientas de análisis y de centralización.

2. Registros del sistema

2.1. Archivos principales

Archivo Contenido Propietario y permisos

Archivo	Contenido	Propietario y permisos
`/var/log/auth.log`	Autenticación, `sudo`, `su`, SSH y cambios de cuentas	`syslog:adm`, `640`
`/var/log/syslog`	Mensajes generales del sistema	`syslog:adm`, `640`
`/var/log/wtmp`	Historial de sesiones abiertas y arranques	`root:utmp`, `664`
`/var/log/btmp`	Intentos de inicio de sesión fallidos	`root:utmp`, `660`
`/var/log/lastlog`	Último acceso de cada cuenta	`root:utmp`, `664`
`/var/log/audit/audit.log`	Eventos del subsistema de auditoría	`root:adm`, `640`

/var/log/auth.log

Autenticación, sudo, su, SSH y cambios de cuentas

syslog:adm, 640

/var/log/syslog

Mensajes generales del sistema

syslog:adm, 640

/var/log/wtmp

Historial de sesiones abiertas y arranques

root:utmp, 664

/var/log/btmp

Intentos de inicio de sesión fallidos

root:utmp, 660

/var/log/lastlog

Último acceso de cada cuenta

root:utmp, 664

/var/log/audit/audit.log

Eventos del subsistema de auditoría

root:adm, 640

El grupo adm permite leer los registros sin ser root. Conviene recordar que pertenecer a adm equivale a poder ver todo el historial de accesos de la máquina, incluidos nombres de usuario escritos por error en el campo de contraseña.

/var/log/btmp registra el nombre introducido en un intento fallido. Cuando una persona escribe su contraseña en el campo del usuario, esa contraseña queda guardada en claro en el archivo. Por eso btmp no debe ser legible por todos los usuarios, y sus permisos 660 no deben relajarse.

2.2. Anatomía de los mensajes de autenticación

Cada línea de auth.log sigue el formato marca de tiempo, equipo, programa[PID] y mensaje. Un intento fallido de SSH contra una cuenta inexistente deja este rastro:

2026-10-19T21:49:36+02:00 lab sshd[207595]: Invalid user noexiste from ::1 port 57170                  (1)
2026-10-19T21:49:39+02:00 lab sshd[207595]: Failed password for invalid user noexiste from ::1 port 57170 ssh2   (2)
2026-10-19T21:49:40+02:00 lab sshd[207678]: Accepted password for ana from ::1 port 57184 ssh2         (3)
2026-10-19T21:49:40+02:00 lab sshd[207678]: pam_unix(sshd:session): session opened for user ana(uid=1001) by ana(uid=0)   (4)

1	El usuario no existe, la señal típica de una enumeración o de un ataque de diccionario.
2	Fallo de contraseña. La expresión `invalid user` indica que la cuenta tampoco existe.
3	Acceso correcto, con el método `password`. Con claves públicas aparecería `Accepted publickey`.
4	Apertura de sesión registrada por el módulo PAM del servicio.

Para sudo, cada comando ejecutado deja una línea con el usuario, el directorio, la cuenta de destino y la orden completa:

sudo:   ubuntu : PWD=/home/ubuntu ; USER=root ; COMMAND=/usr/bin/cat /etc/shadow     (1)
sudo:      ana : user NOT in sudoers ; PWD=/home/ubuntu ; USER=root ; COMMAND=/usr/bin/true   (2)
sudo: pam_unix(sudo:auth): authentication failure; logname=ubuntu uid=1001 euid=0 tty= ruser=ana   (3)

1	Ejecución autorizada. La orden figura completa, lo que permite reconstruir la actividad administrativa.
2	Intento de una cuenta sin permisos en `sudoers`. Es un indicio de interés, porque una cuenta que no debería administrar está probando privilegios.
3	Fallo de la contraseña en la pila `auth` de PAM.

Con los conceptos explicados en los apartados anteriores, ya puede realizar el Ejercicio 1. Exploración de las fuentes de registro y el Ejercicio 2. Generación y localización de eventos de acceso.

2.3. Consulta con `journalctl`

journalctl filtra por unidad, programa, prioridad, intervalo de tiempo y texto, sin necesidad de encadenar grep:

Opción Función Ejemplo

Opción	Función	Ejemplo
`-u`	Filtra por unidad de `systemd`	`journalctl -u ssh`
`_COMM=`	Filtra por nombre de programa	`journalctl _COMM=sudo`
`--since`, `--until`	Acota el intervalo	`journalctl --since '-1h'`
`-g`	Filtra por expresión regular	`journalctl -u ssh -g 'Failed password'`
`-p`	Filtra por prioridad	`journalctl -p warning`
`-o`	Cambia el formato de salida	`journalctl -o short-iso`, `-o json`
`-b`	Limita el arranque actual o uno anterior	`journalctl -b -1`
`-f`	Sigue la salida en tiempo real	`journalctl -u ssh -f`

-u

Filtra por unidad de systemd

journalctl -u ssh

_COMM=

Filtra por nombre de programa

journalctl _COMM=sudo

--since, --until

Acota el intervalo

journalctl --since '-1h'

-g

Filtra por expresión regular

journalctl -u ssh -g 'Failed password'

-p

Filtra por prioridad

journalctl -p warning

-o

Cambia el formato de salida

journalctl -o short-iso, -o json

-b

Limita el arranque actual o uno anterior

journalctl -b -1

-f

Sigue la salida en tiempo real

journalctl -u ssh -f

La opción -o short-iso muestra la hora con zona horaria, y -o json expone campos como _UID, _COMM, _EXE y _HOSTNAME, útiles para procesar los eventos con otras herramientas.

3. Historial de sesiones

3.1. Órdenes de consulta

Orden Fuente Información que ofrece

Orden	Fuente	Información que ofrece
`who`, `w`	`utmp`	Sesiones abiertas ahora, su origen y la actividad actual
`last`	`wtmp`	Sesiones pasadas, arranques y apagados con `-x`
`lastb`	`btmp`	Intentos de acceso fallidos, solo para `root`
`lastlog`	`lastlog`	Último acceso de cada cuenta, con `-u` para filtrar una

who, w

utmp

Sesiones abiertas ahora, su origen y la actividad actual

last

wtmp

Sesiones pasadas, arranques y apagados con -x

lastb

btmp

Intentos de acceso fallidos, solo para root

lastlog

Último acceso de cada cuenta, con -u para filtrar una

last -n 5 -w
sudo lastb -n 5 -w
lastlog -u ana

Ubuntu 26.04. En esta versión last, lastb y lastlog ya no se instalan. last se obtiene con sudo apt install wtmpdb, que solo registra los accesos posteriores a su instalación, y lastlog con el paquete lastlog2 y la orden lastlog2. No existe sustituto de lastb, y los accesos fallidos se consultan con journalctl -u ssh -g 'Failed password'. Además, el servicio de SSH aparece en los registros como sshd-session en lugar de sshd.

La opción -w muestra los nombres completos, que de otro modo se truncan. Una cuenta con **Never logged in** en lastlog que, sin embargo, tiene una contraseña válida, es candidata a bloqueo o eliminación, porque amplía la superficie de ataque sin aportar ningún uso.

Límites del historial de sesiones

wtmp y btmp son archivos binarios que cualquier root puede editar. Solo registran sesiones con terminal, de modo que un comando remoto ejecutado con ssh usuario@host orden sin -t no aparece en last, aunque sí queda en auth.log. Son una ayuda cómoda, no una evidencia fiable.

3.2. Primeros indicios de ataque

Con las órdenes anteriores se identifican los patrones de mayor interés, que MITRE ATT&CK clasifica como Brute Force (T1110) cuando se repiten contra una cuenta y como Valid Accounts (T1078) cuando uno tiene éxito:

Patrón Cómo se ve Posible interpretación

Patrón	Cómo se ve	Posible interpretación
Muchos fallos desde un mismo origen	Decenas de `Failed password` con la misma IP	Fuerza bruta
Un mismo origen contra muchas cuentas	Varios `Invalid user` con nombres distintos	Enumeración o diccionario
Muchas cuentas desde un único origen con pocos intentos	Un fallo por cuenta	Pulverización de contraseñas
Fallos seguidos de un acceso correcto	`Failed password` y luego `Accepted` con la misma IP	Credencial adivinada
Acceso en un horario atípico o desde un origen nuevo	`last` con horas o IP fuera de lo habitual	Credencial robada
`user NOT in sudoers`	Cuenta sin permisos probando `sudo`	Exploración tras un acceso inicial

Muchos fallos desde un mismo origen

Decenas de Failed password con la misma IP

Fuerza bruta

Un mismo origen contra muchas cuentas

Varios Invalid user con nombres distintos

Enumeración o diccionario

Muchas cuentas desde un único origen con pocos intentos

Un fallo por cuenta

Pulverización de contraseñas

Fallos seguidos de un acceso correcto

Failed password y luego Accepted con la misma IP

Credencial adivinada

Acceso en un horario atípico o desde un origen nuevo

last con horas o IP fuera de lo habitual

Credencial robada

user NOT in sudoers

Cuenta sin permisos probando sudo

Exploración tras un acceso inicial

sudo awk '$3 ~ /^sshd/ && /Failed password/ {for (i = 1; i <= NF; i++) if ($i == "from") print $(i + 1)}' /var/log/auth.log | sort | uniq -c | sort -rn | head

Este patrón de tubería, que cuenta las apariciones de cada origen, se desarrolla con más detalle en el tutorial de análisis de registros del sistema con tuberías.

Con los conceptos explicados en los apartados anteriores, ya puede realizar el Ejercicio 3. Historial de sesiones con last, lastb y lastlog y el Ejercicio 4. Resumen de intentos fallidos.

4. Auditoría del núcleo con `auditd`

4.1. Qué aporta frente a los registros de texto

auth.log contiene lo que cada programa decide contar. Si un administrador edita /etc/shadow con un editor o un atacante modifica /etc/sudoers.d/ con un script, ningún servicio escribe en auth.log. El subsistema de auditoría del núcleo cubre ese hueco, ya que registra los accesos a archivos y las llamadas al sistema con independencia de la aplicación, y los asocia al identificador de auditoría (auid).

El auid se asigna al iniciar sesión y no cambia aunque la persona use sudo o su. Así, un evento con auid=ubuntu uid=root indica que ubuntu actuó con privilegios de root, lo que resuelve el problema de la imputabilidad cuando varias personas administran la misma cuenta.

# Actualiza el índice de paquetes
sudo apt update

# Instala el servicio de auditoría y sus complementos
sudo apt install -y auditd audispd-plugins

systemctl is-active auditd
sudo auditctl -s

4.2. Reglas de vigilancia

Las reglas se cargan con auditctl y, para que sobrevivan a un reinicio, se guardan en /etc/audit/rules.d/, de donde augenrules las combina en /etc/audit/audit.rules. La forma más sencilla es el vigilante de archivos:

-w /etc/shadow -p wa -k identidad

Elemento Significado

Elemento	Significado
`-w ruta`	Vigila un archivo o un directorio
`-p wa`	Registra escrituras `w` y cambios de atributos `a`. También existen `r` para lectura y `x` para ejecución
`-k clave`	Etiqueta el evento para localizarlo después con `ausearch -k`

-w ruta

Vigila un archivo o un directorio

-p wa

Registra escrituras w y cambios de atributos a. También existen r para lectura y x para ejecución

-k clave

Etiqueta el evento para localizarlo después con ausearch -k

Un conjunto mínimo para controlar el acceso se guarda en /etc/audit/rules.d/50-acceso.rules:

# Cuentas y credenciales
-w /etc/passwd -p wa -k identidad
-w /etc/group -p wa -k identidad
-w /etc/shadow -p wa -k identidad
-w /etc/gshadow -p wa -k identidad
# Privilegios
-w /etc/sudoers -p wa -k privilegios
-w /etc/sudoers.d/ -p wa -k privilegios
# Autenticación y sesiones
-w /etc/pam.d/ -p wa -k autenticacion
-w /var/log/faillock/ -p wa -k intentos
-w /var/log/wtmp -p wa -k sesiones
-w /var/log/btmp -p wa -k sesiones
-w /var/run/utmp -p wa -k sesiones

sudo augenrules --load
sudo auditctl -l

Estas reglas corresponden a los controles habituales del CIS Benchmark sobre auditoría de identidad, de privilegios y de sesiones.

La opción -e 2 al final de las reglas bloquea la configuración de auditoría hasta el siguiente arranque. Es una medida CIS recomendable en producción, pero impide corregir una regla errónea sin reiniciar el equipo. No la active en el laboratorio.

Una regla -a always,exit sobre llamadas muy frecuentes, como open o execve sin filtros por usuario o por ruta, puede llenar el disco en minutos y degradar el rendimiento. Provocar ese desbordamiento es una técnica de los atacantes para ocultar su actividad, por lo que conviene vigilar rutas concretas y dimensionar la rotación.

4.3. Consulta de los eventos

Dos herramientas complementarias permiten explotar /var/log/audit/audit.log:

ausearch busca eventos concretos por clave, usuario, tipo, resultado o intervalo.
aureport genera informes resumidos por categoría.

Orden Resultado

Orden	Resultado
`sudo ausearch -k identidad -i --start today`	Eventos con la clave `identidad`, con nombres de usuario resueltos
`sudo ausearch -k identidad --start recent --format text`	Una frase legible por cada evento
`sudo ausearch -m USER_AUTH,USER_LOGIN -sv no -i`	Autenticaciones y accesos fallidos
`sudo ausearch -m USER_CMD -i --start today`	Órdenes ejecutadas con `sudo`
`sudo aureport -l -i --start today`	Informe de inicios de sesión
`sudo aureport -au -i --start today`	Informe de autenticaciones
`sudo aureport -f -i --start today`	Informe de archivos vigilados accedidos
`sudo aureport -k --summary`	Número de eventos por clave

sudo ausearch -k identidad -i --start today

Eventos con la clave identidad, con nombres de usuario resueltos

sudo ausearch -k identidad --start recent --format text

Una frase legible por cada evento

sudo ausearch -m USER_AUTH,USER_LOGIN -sv no -i

Autenticaciones y accesos fallidos

sudo ausearch -m USER_CMD -i --start today

Órdenes ejecutadas con sudo

sudo aureport -l -i --start today

Informe de inicios de sesión

sudo aureport -au -i --start today

Informe de autenticaciones

sudo aureport -f -i --start today

Informe de archivos vigilados accedidos

sudo aureport -k --summary

Número de eventos por clave

El parámetro -i convierte identificadores numéricos en nombres, y --start acepta today, recent y fechas.

Cuando ausearch se ejecuta con la entrada redirigida, por ejemplo dentro de un script, intenta leer los eventos de la entrada estándar y se queda esperando. En ese caso hay que indicar el origen con -if /var/log/audit/audit.log.

Un evento de modificación de /etc/passwd genera varios registros enlazados por el mismo número, que ausearch agrupa: el tipo SYSCALL identifica la llamada y el auid, el tipo PATH el archivo afectado y el tipo PROCTITLE la orden que lo provocó. La salida --format text resume todo ello en una línea, como ubuntu, acting as root, successfully renamed /etc/passwd+ to /etc/passwd using /usr/sbin/useradd.

Con los conceptos explicados en los apartados anteriores, ya puede realizar el Ejercicio 5. Reglas de vigilancia con auditd y el Ejercicio 6. Auditoría de cambios de cuentas y privilegios.

5. Protección, retención y centralización

5.1. Retención y rotación

Cada mecanismo tiene su propia política, que debe dimensionarse según el plazo de conservación fijado:

Componente Configuración Valores de referencia

Componente	Configuración	Valores de referencia
`journald`	`/etc/systemd/journald.conf.d/*.conf`	`Storage=persistent`, `SystemMaxUse` y `MaxRetentionSec`
`rsyslog`	`/etc/logrotate.d/rsyslog` y `/etc/logrotate.conf`	`weekly` y `rotate` según el plazo requerido
`auditd`	`/etc/audit/auditd.conf`	`max_log_file`, `num_logs` y `max_log_file_action = ROTATE`

journald

/etc/systemd/journald.conf.d/*.conf

Storage=persistent, SystemMaxUse y MaxRetentionSec

rsyslog

/etc/logrotate.d/rsyslog y /etc/logrotate.conf

weekly y rotate según el plazo requerido

auditd

/etc/audit/auditd.conf

max_log_file, num_logs y max_log_file_action = ROTATE

[Journal]
Storage=persistent
SystemMaxUse=200M
MaxRetentionSec=6month

Por defecto, auditd conserva cinco archivos de 8 MB, una capacidad pequeña para un servidor real. Si se llena, la acción disk_full_action = SUSPEND detiene la auditoría en lugar de detener el sistema, lo cual deja un periodo sin evidencias. En entornos críticos se sube el tamaño y se configura space_left_action para que avise antes.

logrotate -f /etc/logrotate.conf fuerza una rotación inmediata. La rotación individual de un solo archivo, como logrotate -f /etc/logrotate.d/rsyslog, falla en Ubuntu con el aviso de directorio con permisos inseguros, porque la directiva su root syslog solo está en el archivo principal.

5.2. Integridad de los registros

Permisos: los archivos de /var/log/ no deben ser legibles por todos. En Ubuntu, auth.log y syslog son 640 y btmp es 660.
Atributo append-only: chattr +a impide truncar o borrar un archivo, aunque sí permite añadir líneas. Conviene en archivos que no se rotan, porque logrotate también necesita borrar y no puede trabajar sobre un archivo con +a.
Verificación del diario: journalctl --verify comprueba la consistencia interna de los archivos del diario y detecta corrupción accidental. Sin sellado Seal=yes, no protege frente a un atacante con privilegios que reescriba el diario completo.
Sincronización horaria: sin una hora fiable, los registros de varias máquinas no pueden correlacionarse. timedatectl indica si el reloj está sincronizado.

timedatectl show -p NTPSynchronized
sudo journalctl --verify 2>&1 | grep -E 'PASS|FAIL'

Ninguna de estas medidas detiene a un atacante con acceso de root en la propia máquina, que puede desactivar auditd o editar los archivos. La única defensa sólida es sacar copia de los registros fuera de la máquina mientras se generan.

5.3. Envío a un colector remoto con `rsyslog`

rsyslog puede reenviar los eventos de autenticación a un servidor central por TCP. En el equipo emisor, una regla en /etc/rsyslog.d/90-envio.conf selecciona las categorías de autenticación:

auth,authpriv.* action(type="omfwd" target="192.0.2.10" port="6514" protocol="tcp")

En el equipo colector, un archivo en /etc/rsyslog.d/10-receptor.conf abre el puerto y guarda los mensajes en un directorio por equipo:

module(load="imtcp")
input(type="imtcp" port="6514" ruleset="remoto")
template(name="PorEquipo" type="string" string="/var/log/remoto/%HOSTNAME%/%PROGRAMNAME%.log")
ruleset(name="remoto") {
    action(type="omfile" dynaFile="PorEquipo")
}

El envío por TCP sin cifrar expone el contenido de los registros y permite que un tercero inyecte eventos falsos. En producción debe usarse TLS con el módulo gtls, con certificados en ambos extremos, y restringir el puerto del colector a las direcciones de los emisores. En el laboratorio se usa el bucle local para practicar la configuración sin montar una infraestructura de certificados.

La Guía de PKI explica cómo emitir los certificados necesarios para proteger este canal.

Con los conceptos explicados en los apartados anteriores, ya puede realizar el Ejercicio 7. Retención, rotación e integridad y el Ejercicio 8. Envío remoto de registros con rsyslog.

6. Guía consolidada de bastionado y lista de verificación

6.1. Matriz de riesgos y medidas técnicas

Vector de amenaza Impacto potencial Medida de bastionado Verificación técnica

Vector de amenaza	Impacto potencial	Medida de bastionado	Verificación técnica
Fuerza bruta no detectada	Cuentas comprometidas sin alerta	Revisión periódica de `Failed password` y `faillock`	`sudo lastb -n 20 -w`
Borrado de registros tras el acceso	Pérdida de evidencias	Copia remota y `chattr +a` en archivos no rotados	`grep -r omfwd /etc/rsyslog.d/`
Modificación de `sudoers` o de PAM	Persistencia con privilegios	Reglas de `auditd` sobre `/etc/sudoers.d/` y `/etc/pam.d/`	`sudo auditctl -l -k privilegios`
Actividad atribuida a una cuenta compartida	Imposibilidad de imputar	`sudo` nominal y `auid` en los eventos	`sudo ausearch -m USER_CMD -i --start today`
Desbordamiento del almacenamiento	Pérdida de auditoría	Límites de `journald` y rotación de `auditd`	`journalctl --disk-usage`
Marcas de tiempo inconsistentes	Correlación imposible	Sincronización NTP activa	`timedatectl show -p NTPSynchronized`
Archivos de registro legibles por todos	Exposición de datos personales	Permisos `640` o más estrictos	`stat -c '%a %U:%G %n' /var/log/auth.log`

Fuerza bruta no detectada

Cuentas comprometidas sin alerta

Revisión periódica de Failed password y faillock

sudo lastb -n 20 -w

Borrado de registros tras el acceso

Pérdida de evidencias

Copia remota y chattr +a en archivos no rotados

grep -r omfwd /etc/rsyslog.d/

Modificación de sudoers o de PAM

Persistencia con privilegios

Reglas de auditd sobre /etc/sudoers.d/ y /etc/pam.d/

sudo auditctl -l -k privilegios

Actividad atribuida a una cuenta compartida

Imposibilidad de imputar

sudo nominal y auid en los eventos

sudo ausearch -m USER_CMD -i --start today

Desbordamiento del almacenamiento

Pérdida de auditoría

Límites de journald y rotación de auditd

journalctl --disk-usage

Marcas de tiempo inconsistentes

Correlación imposible

Sincronización NTP activa

timedatectl show -p NTPSynchronized

Archivos de registro legibles por todos

Exposición de datos personales

Permisos 640 o más estrictos

stat -c '%a %U:%G %n' /var/log/auth.log

6.2. Lista de verificación CIS Benchmark para Ubuntu 24.04

auditd instalado y activo desde el arranque:

dpkg -s auditd | grep -E '^(Status|Version)'
systemctl is-enabled auditd && systemctl is-active auditd

Reglas sobre identidad, privilegios, sesiones e intentos de acceso, cargadas y también persistentes:

sudo auditctl -l | grep -E 'identidad|privilegios|sesiones|autenticacion'
ls /etc/audit/rules.d/

Retención de auditd dimensionada:

sudo grep -E '^(max_log_file|num_logs|max_log_file_action|space_left_action|disk_full_action)' /etc/audit/auditd.conf

journald persistente y con límites definidos:

grep -rE '^(Storage|SystemMaxUse|MaxRetentionSec)' /etc/systemd/journald.conf /etc/systemd/journald.conf.d/ 2>/dev/null

rsyslog activo y con permisos de creación restrictivos:

systemctl is-active rsyslog
grep -r FileCreateMode /etc/rsyslog.conf /etc/rsyslog.d/

Permisos de los archivos de registro:

stat -c '%a %U:%G %n' /var/log/auth.log /var/log/syslog /var/log/btmp /var/log/audit/audit.log

Registros enviados a un colector remoto:

grep -rE 'omfwd|^[^#]*@@?[0-9a-z]' /etc/rsyslog.conf /etc/rsyslog.d/

Reloj sincronizado:

timedatectl | grep -E 'synchronized|NTP service'

7. Ejercicios prácticos

Los ejercicios están diseñados para realizarse en orden sobre una máquina virtual Ubuntu 24.04 de pruebas, ya que algunos reutilizan usuarios y reglas creados en ejercicios anteriores. Puede crearla con la guía de Multipass.

No realice estos ejercicios en un servidor en producción. Los ejercicios habilitan temporalmente la autenticación por contraseña en SSH para poder generar intentos fallidos, y la limpieza final restaura la configuración original.

Los ejercicios se han verificado en Ubuntu 24.04 LTS. En Ubuntu 26.04 LTS cambian las herramientas de historial de sesiones, como se indica en el apartado 3.1, y sudo es sudo-rs, que registra los eventos con un formato ligeramente distinto y no anota las denegaciones de quien no figura en sudoers. El paso 4 del ejercicio 2, el ejercicio 3 y las comprobaciones de user NOT in sudoers del ejercicio 4 requieren adaptación.

Nº Ejercicio Competencia que desarrolla

Nº	Ejercicio	Competencia que desarrolla
1	Exploración de las fuentes de registro	Localizar dónde queda cada evento de acceso
2	Generación y localización de eventos de acceso	Reconocer los mensajes de `sshd` y `sudo`
3	Historial de sesiones con `last`, `lastb` y `lastlog`	Consultar sesiones y accesos fallidos
4	Resumen de intentos fallidos	Detectar indicios de fuerza bruta con `journalctl` y `awk`
5	Reglas de vigilancia con `auditd`	Instalar `auditd` y vigilar archivos sensibles
6	Auditoría de cambios de cuentas y privilegios	Atribuir acciones con `ausearch` y `aureport`
7	Retención, rotación e integridad	Dimensionar `journald` y comprobar la integridad
8	Envío remoto de registros con `rsyslog`	Sacar copia de los eventos fuera del origen
9	Auditoría CIS de la trazabilidad	Verificar la conformidad de forma automatizada
10	Limpieza del entorno	Revertir los cambios realizados durante la práctica

Exploración de las fuentes de registro

Localizar dónde queda cada evento de acceso

Generación y localización de eventos de acceso

Reconocer los mensajes de sshd y sudo

Historial de sesiones con last, lastb y lastlog

Consultar sesiones y accesos fallidos

Resumen de intentos fallidos

Detectar indicios de fuerza bruta con journalctl y awk

Reglas de vigilancia con auditd

Instalar auditd y vigilar archivos sensibles

Auditoría de cambios de cuentas y privilegios

Atribuir acciones con ausearch y aureport

Retención, rotación e integridad

Dimensionar journald y comprobar la integridad

Envío remoto de registros con rsyslog

Sacar copia de los eventos fuera del origen

Auditoría CIS de la trazabilidad

Verificar la conformidad de forma automatizada

Limpieza del entorno

Revertir los cambios realizados durante la práctica