O que o erro “X não está no arquivo sudoers? Este incidente será relatado. ”Filosoficamente / logicamente significa?

29

Juntamente com a pergunta " O nome de usuário não está no arquivo sudoers. Esse incidente será relatado " que explicou os aspectos programáticos do erro e sugeriu algumas soluções alternativas, quero saber: o que esse erro significa?

X is not in the sudoers file.  This incident will be reported.

A primeira parte do erro explica claramente o erro. Mas a segunda parte diz que "este erro será relatado" ?! Mas por que? Por que o erro será relatado e onde? A quem? Sou usuário e administrador e não recebi nenhum relatório:)!

    
por Kasrâmvd 21.06.2018 / 14:22

4 respostas

39

É provável que o (s) administrador (es) de um sistema deseje saber quando um usuário não privilegiado tenta, mas falha ao executar comandos usando sudo . Se isso acontecer, pode ser um sinal de

  1. um usuário legítimo curioso que está experimentando ou
  2. um hacker tentando fazer "coisas ruins".

Como sudo por si só não consegue distinguir entre eles, as tentativas malsucedidas de usar sudo são levadas ao conhecimento dos administradores.

Dependendo de como o sudo está configurado em seu sistema, qualquer tentativa (bem-sucedida ou não) de usar sudo será registrada. Tentativas bem-sucedidas são registradas para fins de auditoria (para poder acompanhar quem fez o quê) e falhas de segurança.

Em uma configuração Ubuntu bem bajuladora que eu tenho, isso está registrado em /var/log/auth.log .

Se um usuário fornecer a senha errada três vezes ou se não estiver no arquivo sudoers , um email será enviado para o root (dependendo da configuração de sudo , veja abaixo). Isso é o que significa "esse incidente será relatado".

O email terá um assunto de destaque:

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

O corpo da mensagem contém as linhas relevantes do arquivo de log, por exemplo

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

(Aqui, o usuário nobody tentou executar ls a sudo como root, mas falhou porque não estavam no arquivo sudoers ).

Nenhum email é enviado se o email (local) não tiver sido configurado no sistema.

Todas essas coisas também são configuráveis e as variações locais na configuração padrão podem diferir entre as variantes do Unix.

Veja a configuração mail_no_user (e as configurações mail_* relacionadas) no manual sudoers (minha ênfase abaixo):

mail_no_user

If set, mail will be sent to the mailto user if the invoking user is not in the sudoers file. This flag is on by default.

    
por 21.06.2018 / 15:51
15

No Debian e seus derivados, os relatórios de incidentes sudo são registrados em /var/log/auth.log , que contém informações de autorização do sistema, incluindo logins de usuários e mecanismos de autenticação que foram usados:

$ 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 arquivo de log é normalmente acessível apenas para usuários no grupo adm , isto é, usuários com acesso a tarefas de monitoramento do sistema :

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

Do Debian Wiki :

Group adm is used for system monitoring tasks. Members of this group can read many log files in /var/log, and can use xconsole. Historically, /var/log was /usr/adm (and later /var/adm), thus the name of the group.

Os usuários do grupo adm geralmente administradores , e esta permissão de grupo é destinada a permitir que eles leiam arquivos de log sem ter que su .

Por padrão sudo usa o recurso Syslog auth para fazer login . O comportamento de criação de log de sudo pode ser modificado usando as opções logfile ou syslog em /etc/sudoers ou /etc/sudoers.d :

  • A opção logfile define o caminho para o arquivo de log sudo .
  • A opção syslog define o recurso de Syslog quando syslog(3) está sendo usado para registro.

O recurso Syslog auth é redirecionado para /var/log/auth.log in etc/syslog.conf pela presença da seguinte sub-rotina de configuração:

auth,authpriv.*         /var/log/auth.log
    
por 21.06.2018 / 15:36
7

Tecnicamente, isso não significa muito. Muitos (se não todos) outros logins de log de software falharam ou não. Por exemplo, sshd e 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

Além disso, muitos sistemas possuem algum tipo de automação para detectar erros excessivos de autenticação, para poder lidar com possíveis tentativas de força bruta, ou apenas usar as informações para reconstruir eventos após o surgimento de problemas.

sudo não faz nada especialmente excepcional aqui. Tudo o que a mensagem significa é que o autor de sudo parece ter adotado uma filosofia um tanto agressiva na comunicação com usuários que executam comandos que não podem usar.

    
por 21.06.2018 / 17:07
6

Significa simplesmente que alguém tentou usar o comando sudo (para acessar privilégios de administrador), que não tem autorização para usá-lo (porque não estão listados no arquivo sudoers). Isso pode ser uma tentativa de invasão ou algum outro tipo de risco de segurança, por isso a mensagem está dizendo que a tentativa de uso de sudo será informada ao administrador do sistema para que ele possa investigar.

    
por 21.06.2018 / 14:30