Registros de autenticación y de sudo

5 tareas · 38 min · Principiante

Todo lo configurado en las salas anteriores deja huella en un registro: cada entrada por SSH, aceptada o rechazada, y cada orden que alguien ejecuta con sudo. Leer ese registro con criterio es distinguir el ruido de una entrada legítima de un intento de adivinar contraseñas que terminó acertando, y una orden con ticket de una sin él. En Aserríos del Sinú lees un extracto del registro de autenticación de un servidor y los cambios aprobados del día. Todo es lectura de evidencia ficticia.

0 de 5 · 0%

Objetivo de la sala

El servicio SSH escribe dos formas de rechazo muy parecidas: Failed password for invalid user X y Failed password for X. La primera dice que el nombre no existe en el servidor; la segunda, que existe y la contraseña no era la correcta. Una ráfaga de nombres inexistentes sugiere que alguien prueba nombres comunes; una ráfaga contra un nombre que sí existe sugiere que ya sabe quién es.

Esa diferencia ordena la lectura: el primer tipo habla de qué intenta un origen; el segundo, de qué ya conoce.

Responde para continuar

En el registro aparece «Failed password for invalid user test». ¿Qué significa «invalid user»?

Que el nombre test no existe como cuenta en ese servidor Que la cuenta test existe, pero está bloqueada por pam_faillock Que la cuenta test existe y su contraseña caducó

Ver pista de ayuda

El servidor avisa de que el nombre del usuario no es reconocido.

Un patrón conocido en un registro de autenticación: varios fallos desde un mismo origen y, después, un «Accepted» desde ese mismo origen. No dice por sí solo que haya un incidente, pero es lo primero que se prioriza, porque quiere decir que lo que se intentó funcionó. Para seguirlo, se toma el origen de la primera entrada aceptada con contraseña y se comprueba que antes fallaba desde él.

Abre auth.log.txt y lee las líneas de sshd en orden de hora.

Responde para continuar

¿Desde qué dirección se aceptó una contraseña tras una serie de fallos en sinu-web02?

Contar los fallos de un nombre que no existe da el tamaño de la ráfaga. Cada línea cuenta, aunque cambie el número de proceso o el puerto, y hay que contar solo ese nombre, sin sumar otros nombres inexistentes como test.

Cuenta en auth.log.txt las líneas «Failed password for invalid user admin».

Responde para continuar

¿Cuántos fallos de contraseña contra el nombre inexistente admin hay en el extracto?

Una línea de sudo dice quién ejecutó (el primer nombre), con qué permisos (USER=) y qué comando. Para decidir si es normal, se contrasta con los cambios aprobados: la persona, el servidor y la ventana horaria deben coincidir con un ticket. Una orden que cae dentro de la ventana de un ticket de otra persona tampoco queda justificada.

Cruza las líneas de sudo de auth.log.txt con cambios.txt. Comprueba los límites de cada ventana.

Responde para continuar

¿Qué cuenta ejecutó una orden con sudo fuera de cualquier ventana de cambio aprobada?

El registro de autenticación se guarda en un archivo cuyo nombre depende de la distribución (en unas es auth.log, en otras secure) o en el diario del sistema. En una línea de sudo, USER=root no es la persona que actuó: es la cuenta con cuyos permisos se ejecutó. La persona es el primer nombre de la línea, y por eso las cuentas nominales importan.

Responde para continuar

Una línea de sudo dice «soporte : … ; USER=postgres ; COMMAND=/usr/bin/psql». ¿Quién ejecutó el comando?

Ambas cuentas a la vez, por la regla de sudo La cuenta postgres, que es la que figura en USER La cuenta soporte, con los permisos de postgres

Ver pista de ayuda

USER indica con los permisos de quién se ejecuta, no quién lo pidió.

Inicia sesión para registrar tus puntos y progreso en el ranking.

Entrar · Registrarse

1 Dos tipos de fallo Lab

2 La entrada que cerró la ráfaga Lab

3 Contar los intentos contra un nombre inventado Lab

4 La orden sin ticket Lab

5 Dónde mirar y qué dice USER

Whoami-Labs Pro utiliza cookies