¿Qué significa el error “X no está en el archivo sudoers. Se informará de este incidente”. filosófica / lógicamente significa?

este problema se puede tratar de diversas formas, pero en este caso te compartimos la que para nosotros es la respuesta más completa.

Solución:

Es probable que los administradores de un sistema quieran saber cuándo un usuario sin privilegios intenta pero no puede ejecutar comandos usando sudo. Si esto sucede, podría ser una señal de

1. un usuario legítimo curioso que simplemente está probando cosas, o
2. un hacker que intenta hacer “cosas malas”.

Ya que sudo por sí mismo no puede distinguir entre estos, intentos fallidos de utilizar sudo se señalan a la atención de los administradores.

Dependiendo de como sudo está configurado en su sistema, cualquier intento (exitoso o no) de usar sudo se registrará. Los intentos exitosos se registran con fines de auditoría (para poder realizar un seguimiento de quién hizo qué y cuándo) y los intentos fallidos de seguridad.

En una configuración de Ubuntu bastante básica que tengo, esto está registrado /var/log/auth.log.

Si un usuario da una contraseña incorrecta tres veces, o si no está en el sudoers archivo, se envía un correo electrónico a la raíz (dependiendo de la configuración de sudo, vea abajo). Esto es lo que significa “este incidente será informado”.

El correo electrónico tendrá un asunto destacado:

Subject: *** SECURITY information for thehostname ***

El cuerpo del mensaje contiene las líneas relevantes del archivo de registro, por ejemplo

thehostname : Jun 22 07:07:44 : nobody : user NOT in sudoers ; TTY=console ; PWD=/some/path ; USER=root ; COMMAND=/bin/ls

(Aquí, el usuario nobody traté de correr ls mediante sudo como root, pero fallaron ya que no estaban en el sudoers expediente).

No se envía ningún correo electrónico si no se ha configurado el correo (local) en el sistema.

Todas estas cosas también son configurables, y las variaciones locales en la configuración predeterminada pueden diferir entre las variantes de Unix.

Eche un vistazo al mail_no_user entorno (y relacionados mail_* ajustes) en el sudoers manual (mi énfasis a continuación):

mail_no_user

Si está configurado, se enviará correo al usuario mailto si el usuario que invoca no está en el sudoers expediente. Esta bandera está activada de forma predeterminada.

En Debian y sus derivados, el sudo los informes de incidentes se registran en /var/log/auth.log que contiene información de autorización del sistema, incluidos los inicios de sesión de los usuarios y los mecanismos de autenticación que se utilizaron:

$ sudo su
[sudo] password for regularjohn: 
regularjohn is not in the sudoers file.  This incident will be reported.

[as root]

$ tail -n 1 /var/log/auth.log
Jun 21 16:30:26 marvin sudo: regularjohn : user NOT in sudoers ; TTY=pts/19 ; PWD=/home/regularjohn ; USER=root ; COMMAND=/bin/su

Este archivo de registro generalmente solo es accesible para los usuarios en el adm grupo, es decir, usuarios con acceso a tareas de monitorización del sistema:

$ ls -la /var/log/auth.log
-rw-r----- 1 syslog adm 76189 Jun 21 16:30 /var/log/auth.log

De la Wiki de Debian:

Group adm se utiliza para tareas de supervisión del sistema. Los miembros de este grupo pueden leer muchos archivos de registro en / var / log y pueden usar xconsole. Históricamente, / var / log era / usr / adm (y más tarde / var / adm), de ahí el nombre del grupo.

Usuarios en el adm grupo son generalmente administradores, y este permiso de grupo está destinado a permitirles leer archivos de registro sin tener que su.

Por defecto sudo usa el Syslog auth facilidad para la tala. sudoEl comportamiento de registro se puede modificar utilizando el logfile o syslog opciones en /etc/sudoers o /etc/sudoers.d:

• los logfile La opción establece la ruta a la sudo archivo de registro.
• los syslog La opción establece la función Syslog cuando syslog(3) se está utilizando para la tala.

El Syslog auth la instalación se redirige a /var/log/auth.log en etc/syslog.conf por la presencia de la siguiente estrofa de configuración:

auth,authpriv.*         /var/log/auth.log

Técnicamente, no significa mucho. Muchos (si no todos) otros inicios de sesión de registros de software, fallidos o no. Por ejemplo sshd y su:

Jun 21 17:52:22 somehost sshd[25807]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=::1  user=root
Jun 21 17:52:22 somehost sshd[25807]: Failed password for root from ::1 port 37268 ssh2
Jun 21 17:52:23 somehost sshd[25807]: Connection closed by ::1 port 37268 [preauth]
Jun 21 17:52:28 somehost su[25809]: pam_unix(su:auth): authentication failure; logname= uid=1000 euid=0 tty=/dev/pts/15 ruser=someuser rhost=  user=root
Jun 21 17:52:28 somehost su[25809]: pam_authenticate: Authentication failure
Jun 21 17:52:28 somehost su[25809]: FAILED su for root by someuser

Además, muchos sistemas tienen algún tipo de automatización para detectar errores de autenticación excesivos para poder lidiar con posibles intentos de fuerza bruta, o simplemente usar la información para reconstruir eventos después de que aparezcan los problemas.

sudo no hace nada especialmente excepcional aquí. Todo lo que el mensaje significa es que el autor de sudo parece haber adoptado una filosofía algo agresiva al comunicarse con los usuarios que ejecutan comandos que no pueden usar.

Comentarios y calificaciones

Si sostienes alguna duda y capacidad de innovar nuestro artículo puedes escribir un paráfrasis y con placer lo leeremos.

---

---

Utiliza Nuestro Buscador