Registros de autenticación y del sistema

En Linux los accesos se anotan en más de un sitio. El registro de autenticación (/var/log/auth.log en Debian y Ubuntu, /var/log/secure en la familia de Red Hat) es un archivo de texto donde sshd, sudo, su y cron escriben cada inicio de sesión, cada fallo y cada uso de privilegios. Aparte, el sistema mantiene registros binarios de sesiones: wtmp guarda los inicios y cierres de sesión y se lee con last; btmp guarda los intentos fallidos y se lee con lastb.

Que sean fuentes distintas es lo que las hace útiles. Un archivo de texto se puede editar con cualquier herramienta; un registro binario se escribe por otro camino. Ninguno es infalible, pero si cuentan la misma historia se refuerzan, y si discrepan, la discrepancia es el hallazgo.

Un origen que prueba nombres de cuenta distintos uno tras otro y acaba entrando con uno de ellos no está olvidando una contraseña: está recorriendo una lista. En auth.log ese patrón se lee por la secuencia de líneas: «Invalid user» cuando el nombre no existe, «Failed password» en cada fallo, y por fin «Accepted» cuando una pareja de cuenta y contraseña funciona. El número de cuentas distintas que probó dice si fue una conjetura aislada o un barrido.

La cuenta que finalmente cede suele ser la que menos vigilada estaba: una cuenta de servicio con contraseña activa. Anota el origen, la hora del primer intento y la del acceso.

Abre auth.log y sigue las líneas del origen externo hasta el acceso.

sudo anota en auth.log cada intento de usar privilegios, y el mensaje distingue casos que no son equivalentes. Una línea sin error indica que el comando se ejecutó con los permisos pedidos. «user NOT in sudoers» indica que la cuenta no tiene ningún permiso de sudo. «command not allowed» indica que la cuenta sí figura en la configuración de sudo, pero no para ese comando. «incorrect password» indica un fallo de contraseña.

Leer bien estas líneas evita dos errores opuestos: ver un acceso con privilegios donde solo hubo un intento, y descartar el intento porque falló. Una línea de rechazo prueba la intención y deja abierta la pregunta de si hubo otros intentos que sí funcionaron.

Busca la línea de sudo de svc-tienda en auth.log.

Un servidor produce líneas con regularidad. En cds-tienda01, por ejemplo, cron abre y cierra una sesión de root cada cinco minutos y la anota en auth.log. Esa cadencia es un latido: si en una franja de tiempo faltan latidos, faltan líneas, y alguien pudo recortar el archivo. No prueba quién lo hizo, pero marca el tramo exacto donde mirar.

El cruce con last completa la imagen. Una sesión que wtmp recuerda y auth.log no, dentro del tramo sin latidos, es una sesión cuyo rastro de texto fue retirado. La hora de inicio que da last es la que permite buscar esa sesión en las demás fuentes.

Compara last.txt con auth.log.