Autenticación y sudo

Un servicio de acceso remoto expuesto recibe intentos de adivinar contraseñas todo el tiempo. Un intento fallido aislado no dice nada; lo que se mira es el volumen por origen y la variedad de cuentas probadas, incluidas las que no existen (invalid user). En registro_de_autenticacion, las líneas Failed password dicen la cuenta, la dirección de origen y el puerto de cada intento.

Cuenta los intentos fallidos por dirección de origen.

Después de una ráfaga de fallos, lo importante es si alguna entrada tuvo éxito. Un Accepted indica el método (contraseña o llave pública), la cuenta y el origen. Una entrada aceptada no es por sí sola un problema: hay que compararla con quién debía conectarse y desde dónde.

Una cuenta que no está en la lista de sudo recibe el aviso user NOT in sudoers y su intento queda registrado. Poco después, el registro de su muestra una sesión abierta como root. A las 03:31 la auditoría registra la ejecución de un programa de administración con uid=0. Ese uid dice con qué permisos corrió, no quién estaba detrás.

Mira en auditoria_de_cuentas la fila de las 03:31 y resuelve el campo que conserva la cuenta de la sesión con la tabla cuentas.

Tienes los hechos: intentos fallidos desde una dirección externa, una entrada aceptada de otra, un intento de editar las reglas de sudo sin permiso, una sesión como root y una orden de administración. Lo que no tienes: el motivo de la persona, si la contraseña de root fue compartida o robada, ni si las dos direcciones externas están relacionadas.

El registro de autenticación no está en el mismo archivo en todas las distribuciones: en las de la familia Debian suele ser /var/log/auth.log y en las de la familia Red Hat, /var/log/secure; además, muchos sistemas lo guardan en el diario del sistema. Una regla de detección escrita para un archivo se rompe en silencio al pasar a otra distribución, y el panel sigue verde porque no llega ningún evento.