Los registros de autenticación ayudan a explicar los intentos de inicio de sesión, los cambios de privilegios y la actividad de las sesiones. Son pruebas sensibles desde el punto de vista de la seguridad, pero una sola línea rara vez permite establecer la intención de un usuario o demostrar que una cuenta ha sido comprometida.
Registros del Sistema · Lección 5
Registro de autenticación
Aprende a localizar, interpretar y correlacionar de forma segura los registros de autenticación de Linux.
Localizar los registros de autenticación
Las configuraciones syslog de la familia Debian suelen dirigir los eventos de autenticación a /var/log/auth.log; las de la familia Red Hat suelen utilizar /var/log/secure. Un diario de systemd puede conservar los mismos eventos con metadatos de la unidad y el proceso, y un sistema centralizado de registros puede contener la copia de referencia.
Descubre el destino local y consulta el servicio pertinente, por ejemplo:
$ sudo journalctl -u ssh.service --since '1 hour ago'
$ sudo less /var/log/auth.log
La unidad SSH puede llamarse ssh.service o sshd.service. Los permisos suelen restringir estos registros porque exponen detalles sobre cuentas y accesos.
¿Dónde deben almacenarse siempre los eventos de autenticación de Linux?
Interpretar un evento
Un registro tradicional puede contener:
Jan 31 10:37:50 icebox pkexec: pam_unix(polkit-1:session): session opened for user root by (uid=1000)
Esto identifica la hora, la máquina, el programa emisor, el módulo y el servicio PAM, el usuario solicitado para la sesión y el UID de origen. Por sí solo, no identifica a la persona que estaba detrás del UID 1000 ni demuestra que la acción fuera maliciosa. Resuelve el UID con los registros de cuentas válidos en el momento del incidente y correlaciona la terminal, la dirección remota, la sesión y los eventos circundantes.
¿Qué establece uid=1000 en este registro?
Investigar éxitos y fallos
Busca tanto los intentos aceptados como los rechazados dentro de un intervalo limitado. Para SSH, examina también el origen de la conexión, el método de autenticación, la cuenta de destino, la apertura y el cierre de la sesión y los reinicios del servicio. Los fallos repetidos pueden deberse a un error del usuario, a automatizaciones con credenciales obsoletas, a exploraciones o a un ataque; la frecuencia por sí sola no permite elegir una explicación.
last y lastb pueden resumir registros de wtmp y btmp cuando se mantienen, pero esas bases de datos binarias tienen sus propios límites de conservación e integridad. Contrástalas con los registros del diario o de syslog y con las fuentes centralizadas.
¿Con qué deben correlacionarse los intentos repetidos de inicio de sesión fallidos?
Conservar y responder
Si se sospecha de un incidente, registra la hora y la zona horaria de la máquina, conserva los registros originales y sus metadatos y protege todas las copias exportadas. Evita editar las pruebas en su ubicación original. Bloquear cuentas, cambiar el cortafuegos y terminar sesiones puede interrumpir accesos legítimos o alertar a un atacante, así que sigue el proceso de respuesta a incidentes y conserva una vía de recuperación.
¿Cómo deben tratarse las pruebas de autenticación durante una investigación?
Lección completada
Has completado Registro de autenticación
Ahora puedes examinar eventos de autenticación sin afirmar más de lo que demuestra un único registro.
Descubre el destino de los registros de autenticación configurado localmente.
Interpreta en su contexto los campos de identidad, servicio, método y sesión.
Correlaciona la actividad fallida y satisfactoria entre las fuentes conservadas.
Preserva las pruebas y coordina las medidas de respuesta que puedan causar interrupciones.
Guarda tu progreso
Crea una cuenta gratuita para guardar esta lección y continuar en cualquier dispositivo.
Crear una cuenta gratuita