Como posso descobrir qual usuário logou como root?

Question

Temos alguns servidores gerenciados por um grande grupo de administradores. Eles geralmente fazem login como usuários do serviço (digamos, hudson ) e, em seguida, alternam para root para fazer uma pequena correção. Isso significa que muitas vezes não podemos mapear uma alteração feita para uma pessoa.

Alguém tem um script para Unix / Linux que possa me dizer qual usuário logou como root? Logins podem ser de todos os computadores na LAN local. Acesso remoto de fora da LAN como root não é possível; Os administradores devem primeiro fazer login com um usuário da rede local e, em seguida, podem promover a si mesmos para fazer o root (todos usam SSH).

O que eu gostaria é de um script que siga os logins remotos (na LAN local) e imprima o nome de usuário por um certo tempo. Você pode assumir que o script pode logar via ssh em qualquer computador na LAN local como root sem ser solicitado por uma senha.

Background: Eu tenho um script que salva cópias de backup de todos os arquivos editados pelo root. O problema é descobrir quem realmente fez a mudança.

A segurança não é um problema; isso não é para encontrar hackers que possam ter limpado wtmp , é descobrir quem cometeu um erro ao dar feedback.

[EDITAR] Alguns ponteiros: o comando last ajuda:

> last -t 20101029174200 root
root     pts/26       :0.0             Wed Oct 20 15:36 - 15:03  (23:27)    

wtmp begins Fri Oct  1 16:34:36 2010

Então, root fez login via pts/26 . Quem mais sentou naquele pseudo TTY?

> last -t 20101029174200 pts/26
adigulla pts/26       :0               Mon Oct 25 09:45   still logged in   
adigulla pts/26       :0               Fri Oct 22 14:00 - 17:29  (03:29)    
adigulla pts/26       :0               Thu Oct 21 15:04 - 16:05  (01:01)    
root     pts/26       :0.0             Wed Oct 20 15:36 - 15:03  (23:27)    
adigulla pts/26       :0.0             Fri Oct 15 15:57 - 15:57  (00:00)    

wtmp begins Fri Oct  1 16:34:36 2010

Hum ... deve ser eu. Então eu posso acompanhar as alterações do usuário na máquina local. Se eu fizer login em uma máquina remota:

$ last -1 hudson 
hudson   pts/0        192.168.0.51     Fri Oct 29 17:52   still logged in   

Então eu recebo o PTY e o endereço IP de onde eu vim. Como posso estabelecer a conexão da saída de last para hudson para o usuário em 192.168.0.51 ?

[EDIT2] Tenha em atenção que normalmente alteramos o utilizador com ssh , não sudo ou su . Isso permite o logon único e evita ter que informar as senhas aos administradores. Se queremos conceder / revogar o acesso a algo, simplesmente adicionamos / removemos a chave pública da conta de serviço. Eu também sei que o ssh registra no syslog, mas as mensagens não me dizem qual usuário mudou para o root:

sshd[7460]: Accepted publickey for root from ::1 port 36689 ssh2

    

Answer 1

Acho que a melhor maneira de dar feedback aos administradores que logaram por engano como root é desabilitar os logins raiz enquanto ainda permitem su e sudo. Como alternativa, tenha o perfil do root exibindo uma mensagem de feedback adequada e, opcionalmente, saia.

Se alguém que não seja um administrador estiver fazendo login como root, você precisa pelo menos alterar a senha do root: -)

OK, você revisou a pergunta para esclarecer o que deseja alcançar. Você precisa minimizar o número de serviços que permitem logins e garantir que todos registrem um login bem-sucedido. O SSH registra logins bem-sucedidos via syslog.

Se você tem várias pessoas logando como "hudson", você precisa parar com isso. Deve ser uma política do site que administra cada login usando um ID de usuário exclusivo.

Você precisa garantir que a rotação do arquivo de log seja ajustada para que você possa pesquisar logs mais antigos por qualquer período que seja necessário.

Você certamente pode ter um script agendado pelo cron que atualiza diariamente os logins do syslog e que também verifica os timestamps em arquivos críticos de configuração.

Além disso, existem muitas ferramentas para monitorar as alterações nos arquivos de configuração. Muitos sistemas Unix possuem um subsistema de auditoria que pode ser ativado e que também pode ajudar.

Pessoalmente, suspeito que a melhor maneira de fornecer feedback no caso de um erro não é caçar alguém para culpar, mas explicar o problema para todo o grupo, explicar por que a mudança foi um erro e solicitar idéias. para evitar erros.

    

Answer 2

você deve ser capaz de determinar quem está se tornando root analisando /var/log/auth.log .

por exemplo, se eu su para root em minha própria caixa, uma linha como essa é inserida em /var/log/auth.log :

Oct 29 20:10:33 localhost su: pam_unix(su:session): session opened for user root by (uid=1000)

agora procurando em /etc/passwd , vemos:

brad:x:1000:100:brad clawsie,,,:/home/brad:/bin/zsh

que nos permite correlacionar o uid 1000 a um nome. escrever um script perl para fazer isso deve ser muito simples, você está simplesmente juntando o uid em /var/log/auth.log e /etc/passwd em um determinado intervalo de tempo, ou seja, o mtime para o arquivo que você está investigando.

se alguém su fizer o root e simplesmente executar o comando touch no arquivo que você está pesquisando, ele irá configurar o seu mtime, e você acreditará erroneamente que foram eles que editaram o arquivo.

Se eu fosse recomendar uma prática recomendada para evitar seus problemas, seria para armazenar todos scripts, crons, arquivos de configuração ... tudo como arquivos em um sistema de controle de versão que deve ser editado por um usuário real, então aplicado ao sistema live com algum tipo de ferramenta de implementação (make, apt, whatever). Se as pessoas continuarem quebrando as coisas, terão sua assinatura cancelada por um desenvolvedor mais sênior antes da implantação.

seus backups podem não ajudar se você não conseguiu fazer uma cópia no momento certo ... um sistema de controle de versão permite reverter quantas edições desejar.

a qualquer momento, arquivos em sistemas de produção ao vivo estão sendo editados no local por raiz, isso é um grande problema. Eu não posso dizer em sua pergunta se hudson é uma pessoa real em seu sistema ou um usuário sintético para um serviço (ou seja, o serviço hudson). se for um usuário sintético, eu perguntaria por que esse uid recebe um shell de login "real".

    

Answer 3

Renomeie su para log_su e coloque a chamada su (agora seu log_su) dentro de um wrapper chamado su

#!/usr/bin/env bash
$SU_LOG=<path to log file>
echo "User: $USER running su at $(date)" >> $SU_LOG
log_su

    

Answer 4

Eu fiz um pequeno programa que, quando usado, informa qual usuário fez login como root se usou sudo su , sudo bash ou sudo -i . Só sei que atualizei bastante ultimamente porque tenho adicionado pequenas coisas aqui e ali para torná-lo melhor e mais eficiente. Mas se você estiver interessado em usá-lo, basta acessar este link: link . Existe um arquivo README.md que explica a finalidade do programa e seus recursos / falhas. Apenas saiba que o script só informará você sobre usuários que efetuaram login no root nos últimos sete dias.

    

Answer 5

Os comandos su e sudo podem ser parametrizados para manter os registros.

Assumindo que (1) ir à raiz não é uma ação frequente e que (2) geralmente não mais do que um administrador se torna raiz ao mesmo tempo e dado algum registro de data e hora, seu script pode simplesmente pesquisar o su / sudo registra para localizar o administrador que era root naquele momento.

Se você estiver usando o ssh, você pode gerar uma chave de autenticação para cada administrador e fazê-los usá-lo durante o login, em vez do mecanismo de senha.

Conforme descrito em Como posso obter o comentário da chave ssh do authorized_keys atual , é possível usar o campo de comentários no arquivo-chave para identificar a pessoa que efetuou login.

O restante é o mesmo: usando o registro de data e hora da modificação do arquivo em auth.log para identificar a sessão ssh presumida que editou o arquivo.

    

Answer 6

O Linux contém um sistema de auditoria avançado, que pode ser configurado para rastrear todas as alterações em arquivos específicos.

De Compreendendo a auditoria do Linux , vejo que ela pode ser definida até também rastrear logins SSH, além de alterações de arquivo, para que possa ser uma possível solução para o seu problema.

    

Answer 7

Please also note that we usually change user with ssh, not sudo or su. This allows for single sign on and avoids having to tell admins any passwords.

Isso parece um pouco ridículo. Você está disposto a tolerar o uso de recursos de ssh-ing em localhost (buffers de rede, tty-alocações, criptografia e descriptografia inúteis, etc.), em vez de configurar seu sudo para simplesmente não solicitar senhas ?

gandalf     ALL = NOPASSWD: ALL

If we want to grant/revoke access to something, we simply add/remove the public key from the service account.

Você também pode remover a entrada correspondente de /etc/sudoers .

I also know that ssh logs to syslog but the messages don't tell me which user switched to root

Você também pode verificar o ~/.history (ou ~/.bash_history ) de todos os admins para ssh-invocations em torno dos tempos registrados pelo sshd. Isso é bastante fácil para um nogoodnick moderadamente determinado escapar, é claro, mas também é qualquer coisa para uma pessoa com acesso root.

Ainda assim, usar o sudo configurado corretamente é uma opção muito melhor. As versões modernas até suportam /etc/sudoers.d/ , portanto você pode remover / remover (pequenos) arquivos do subdiretório em vez de editar o único (grande) /etc/sudoers .