É 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
- um usuário legítimo curioso que está experimentando ou
- 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.