Como rastrear atividades de superusuário

Gostaria de saber quais são as melhores abordagens para rastrear atividades de superusuário em um ambiente Linux.

Especificamente, estou procurando esses recursos:

• A) Registrando pressionamentos de tecla em um servidor syslog seguro
• B) Capacidade de reproduzir sessões de shell (algo como scriptreplay)
• C) Idealmente, isso deve ser algo impossível (ou bastante difícil) de contornar sem ter acesso físico ao servidor.

Pense nisso da perspectiva da segurança / auditoria, em um ambiente em que diferentes administradores de sistemas (ou mesmo terceiros) precisam ter permissão para executar operações privilegiadas em um servidor.

Todo administrador teria sua própria conta nominal e toda sessão interativa deveria ser totalmente registrada, com a possibilidade de reproduzi-la se necessário (por exemplo, se alguém usasse o mc para excluir ou alterar arquivos críticos, não seria suficiente saiba que essa pessoa emitiu o comando mc; deve haver uma maneira de ver exatamente o que foi feito após o lançamento do mc).

Notas adicionais :

1. Como womble apontou, talvez a melhor opção seja não ter pessoas efetuando login com privilégios de root para realizar alterações nos servidores, mas fazê-lo através de um sistema de gerenciamento de configuração. Então, vamos assumir uma situação em que não temos esse sistema e precisamos conceder acesso no nível raiz a pessoas diferentes no mesmo servidor .
2. Eu não estou interessado em fazer isso clandestinamente: todas as pessoas que efetuam login em um servidor com privilégios de root estariam totalmente cientes de que a sessão será gravada (da mesma forma que, por exemplo, os operadores de call center sabem que suas conversas são sendo gravado)
3. Ninguém usaria uma conta de superusuário genérica ("root")
4. Estou ciente do ttyrpld e parece fazer o que estou procurando. Mas antes de seguir esse caminho, gostaria de saber se isso pode ser resolvido usando um kernel não modificado. Quero saber se há alguma ferramenta para o Debian em particular (ou Linux em geral) que permita auditoria completa de contas de superusuário sem corrigir o shell ou o kernel.

Para ambientes com vários administradores, não use root - sempre que possível.

Use o sudo para tudo - o sudo é extremamente configurável e facilmente registrável.

Registre qualquer / todos os logins ou su's para fazer root e investigue-os, pois alguém está seguindo as regras estabelecidas.

Por um lado, que tipo de acesso de usuário raiz você deseja monitorar? Erros estúpidos de administrador ou insider malicioso? O primeiro - você desejará uma boa solução de gerenciamento de configuração, como já foi sugerido. O último - se eles souberem o que estão fazendo, você pode esperar capturar o suficiente para indicar que algo vale a pena investigar. Você só quer saber que alguma forma de atividade não autorizada foi iniciada e ser alertado para esse fato. Se forem inteligentes, desabilitarão a maior parte do registro em que você cria (alterando o estado do servidor ou trazendo suas próprias ferramentas), mas esperamos que você possa entender o início do incidente.

Dito isto, sugiro algumas ferramentas que você pode usar. Primeiro, comece com uma boa política de sudo (que já foi sugerida). Segundo, confira sudoshell se você precisar conceder acesso de shell raiz a esses administradores. Terceiro, provavelmente sua melhor aposta (embora mais intensiva), examine a auditoria do kernel do linux.

O que você pode fazer é usar esta biblioteca para sudo, fornecer a todos sua própria conta de usuário e colocar sudo -i no perfil de todos. Dessa forma, eles têm acesso instantâneo à raiz e todos os comandos que usam estão sendo registrados.

Eles têm raiz. O melhor que você pode esperar é, pelo menos, ver quando eles decidiram romper com sua pequena utopia de monitoramento, mas além disso, o que eles fizeram é uma incógnita.

A opção "melhor" em que posso pensar é exigir o uso de automação e gerenciamento generalizados de configuração e gerenciar seus manifestos usando um sistema de controle de revisão e implantar atualizações por meio disso. Evite logins raiz reais nos servidores. (O acesso de emergência "ah não, eu quebrei alguma coisa" pode ser fornecido por uma senha ou chave SSH não distribuída e alterada após cada uso, e todos assistem ao administrador do sistema que estragou tudo para garantir que não mudar qualquer coisa).

Sim, isso será inconveniente e irritante, mas se você é paranóico o suficiente para querer monitorar as ações de todos nesse nível, acho que você está em um ambiente que é inconveniente e irritante o suficiente de outras maneiras. parece um grande problema.

Como outros já disseram, não há praticamente nenhuma maneira de registrar usuários com acesso root completo de uma maneira que eles não possam desabilitar, mas se você estiver executando o debian / ubuntu, dê uma olhada no snoopy , que fica bem próximo do que você deseja

snoopy é apenas uma biblioteca compartilhada usada como um wrapper para a função execve () fornecida pela libc, para registrar todas as chamadas ao syslog (authpriv). os administradores de sistema podem achar o snoopy útil em tarefas como monitoramento de sistemas leves / pesados, rastreando as ações de outros administradores e também obtendo uma boa noção do que está acontecendo no sistema (por exemplo, apache executando scripts cgi).

Concordo com os comentários de disabledleopard sobre o uso do sudo para tudo. Certamente torna as coisas um pouco mais fáceis de registrar.

Eu também adicionaria o backup do arquivo de histórico do bash periodicamente. Aparentemente esquecido, mas às vezes pode ser uma grande fonte de informação ... basta perguntar à Goldman Sachs. ;-)

http://www.guardian.co.uk/business/2009/jul/12/goldman-sachs-sergey-aleynikov

Isso seria difícil ...

O root pode executar scripts cuidadosamente testados que podem violar todas as medidas de segurança (matar processos de monitoramento), destruir arquivos de log / cortá-los etc ... Mas ainda assim ...

Supondo que vários administradores com privilégios de root estejam trabalhando em equipe. E o root também pode matar qualquer processo de monitoramento. E, infelizmente, esse login / senha se torna público. Ou eles obtêm companhia indesejada.

Criar várias contas raiz com UID 0, embora não recomendado, pode ser aplicável aqui.

Em / etc / ssh / sshd_config Alterando a linha para: PermitRootLogin no

é recomendado. Para que, aqui, um usuário efetue login usando sua conta normal (o carimbo de data e hora é registrado junto (talvez o endereço IP falsificado))) e depois muda para o root. usando o comando su

E o login direto como root é evitado assim.

Temos que pensar o que a raiz não pode fazer aqui.

sudo deve ser bom. O backup dos arquivos de configuração do diretório / etc deve ser bom. / var / directory Os arquivos de log devem ser enviados periodicamente por email ou armazenados em NFS separado.

Que tal escrever scripts que integram APIs de empresas do Mobile Gateway que agrupam o SMS em todos os celulares do usuário raiz, que um deles está fora de casa para trabalhar. Eu sei que seria irritante, mas ainda assim.

Quebrar o SSH está principalmente fora de questão.

Temos a seguinte configuração no site de um cliente:

• Da mesma forma, abra para autenticar com o kerberos no AD (contas pessoais)
• Autorização apenas para determinados grupos AD de administradores Unix
• grupo sudoers == grupo AD
• Agentes OSSEC HIDS em todos os servidores e gerente em um servidor protegido
• UI da Web OSSEC
• Splunk 3 com Splunk para OSSEC

Ele registra cada uso do sudo nos servidores e também rastreia quaisquer alterações em arquivos, instalação de pacotes, processos suspeitos, etc.

Temos vários servidores de terminal para acessar todos os nossos equipamentos, o que significa que é possível efetuar logon em qualquer coisa, a partir do servidor de terminal ou se houver acesso físico.

O sshd nos servidores de terminal é atualizado com http://www.kdvelectronics.eu/ssh-logging/ssh-logging.html , funciona bem, mas não foi atualizado por um longo tempo. Eu o modifiquei um pouco para trabalhar no openssh 4.7, mas não o fiz com o 5.1. Segfaults sshd com patch e, desde que não tenha tempo suficiente para consertar isso, quase mudei para ttyrpld.

Até agora, é isso que eu tenho:

• sudosh : parece suportar A e B (embora não esteja totalmente certo sobre A)
• Sudoscript : parece suportar B (Sudoscript tem um componente chamado sudoshell, e se é isso que romandas sugeriu, obrigado pela dica)
• Snoopy Logger ou sudo_exetrace : não exatamente o que estou procurando, mas poderia ser um bom complemento (graças a theotherreceive e blauwblaatje por esses links)

Você conhece outras ferramentas semelhantes que não envolvem o patch do kernel ou outros componentes do sistema?