Gostaria de saber quais são as melhores abordagens para rastrear atividades de superusuário em um ambiente Linux.
Especificamente, estou procurando esses recursos:
Pense nisso de uma perspectiva de segurança / auditoria, em um ambiente onde diferentes administradores de sistema (ou até 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 repeti-la, se necessário (por exemplo, se alguém usasse o mc para deletar ou alterar arquivos críticos, não ser o suficiente para saber 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 :
Para ambientes com vários administradores, não use root - se 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 root & investigue-os como se alguém estivesse seguindo suas regras estabelecidas.
Por exemplo, que tipo de acesso de usuário root você está procurando monitorar? Erros de administração estúpidos ou insiders maliciosos? O primeiro - você desejará uma boa solução de gerenciamento de configuração, como já foi sugerido. Os últimos - se eles sabem o que estão fazendo, você só pode esperar pegar o suficiente para indicar algo que valesse a pena investigar. Você só quer saber que alguma forma de atividade não autorizada começou e ser alertado para esse fato. Se eles forem espertos, eles desabilitarão a maior parte do registro que você criou (mudando o estado do servidor ou trazendo suas próprias ferramentas), mas esperamos que você consiga 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). Em segundo lugar, confira sudoshell se você precisar dar acesso ao shell de root desses administradores. Terceiro, provavelmente sua melhor aposta (embora mais intensiva), olhe para a auditoria de kernel do Linux.
O que você poderia fazer é usar esta biblioteca para o sudo, dar a todos a sua conta de usuário e colocar sudo - Eu no perfil de todos. Dessa forma, eles têm acesso instantâneo à raiz e todos os comandos que eles usam estão sendo registrados.
Eles têm raiz. O melhor que você pode esperar é, pelo menos, ver quando eles decidiram sair da sua pequena utopia de monitoramento, mas além disso, o que eles fizeram, ninguém sabe.
A opção "melhor" que consigo imaginar é ordenar o uso de automação e gerenciamento de configuração generalizada e gerenciar seus manifestos usando um sistema de controle de revisão e implantar atualizações por meio disso. Em seguida, evite logins raiz reais para os servidores. (Emergência "oh noes eu quebrei algo" o acesso pode ser fornecido por uma senha não-distribuída-e-depois-de-usar-cada ou chave SSH, e todo mundo começa a ver o administrador de sistema que estragou tudo para ter certeza de que não mudar alguma coisa).
Sim, isso vai ser inconveniente e chato, mas se você é paranóico o suficiente para querer monitorar as ações de todos nesse nível, eu estou supondo que você está em um ambiente que é inconveniente e chato o suficiente de outras maneiras que isso não parece um grande problema.
Concordo com os comentários do disabledleopard sobre o uso do sudo para tudo. Isso certamente torna as coisas um pouco mais fáceis de registrar.
Eu também adicionaria o backup do arquivo histórico do bash periodicamente. Aparentemente muitas vezes esquecido, mas às vezes pode ser uma grande fonte de informação ... basta perguntar ao Goldman Sachs. ; -)
Isso seria difícil ...
root pode executar cuidadosamente scripts bem testados que podem violar todas as medidas de segurança (eliminar processos de monitoramento), destruir arquivos de log / apará-los, etc ... Mas ainda assim ...
Supondo que vários administradores tenham privilégios de root, estão 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 têm companhia indesejada.
Criar várias contas raiz com o UID 0, embora não recomendado, pode ser aplicado aqui.
Em / etc / ssh / sshd_config Alterando a linha para: PermitRootLogin não
é recomendado. Então, aqui um usuário efetua login usando sua conta normal (o registro de data e hora é registrado juntamente com (talvez um endereço IP falsificado)) Então muda para root. usando o comando su
E o login direto como root é evitado assim.
Nós temos que pensar, o que a raiz não pode fazer aqui.
sudo deve ser bom. Fazendo o backup do diretório / etc Arquivos de configuração devem ser bons. / var / directory Arquivos de log devem ser enviados periodicamente ou armazenados em NFS separado.
Que tal Escrever Scripts que integram APIs de empresas de Gateway Móvel que agrupam SMS em todos os celulares de usuários de raiz, que um deles está fora de casa para o trabalho. Eu sei que isso seria irritante, mas ainda assim.
A quebra do SSH está fora de questão.
Como outros já disseram, não há praticamente nenhuma maneira de registrar usuários com acesso root completo de uma forma que eles não podem desabilitar, mas se você estiver executando o debian / ubuntu, dê uma olhada em snoopy , que vem bem perto do que você quer
snoopy is merely a shared library that is used as a wrapper to the execve() function provided by libc as to log every call to syslog (authpriv). system administrators may find snoopy useful in tasks such as light/heavy system monitoring, tracking other administrator's actions as well as getting a good 'feel' of what's going on in the system (for example apache running cgi scripts).
Temos a seguinte configuração no site de um cliente:
Ele registrará todos os usos do sudo nos servidores e também rastreará quaisquer alterações nos arquivos, instalação de pacotes, processos suspeitos, etc.
Temos vários servidores de terminal para acessar todos os nossos equipamentos, o que significa que podemos fazer login em qualquer coisa, seja a partir do servidor de terminal ou se houver acesso físico.
O sshd em servidores de terminal é corrigido com o link , funciona bem, mas não foi atualizado por muito tempo. Eu modifiquei um pouco para trabalhar no openssh 4.7, mas não consegui fazer isso com 5.1. Substitui os segfaults do sshd, e desde que eu não tenha tempo suficiente para consertar isso, eu quase mudei para o ttyrpld.
Até agora, é isso que tenho:
Você conhece outras ferramentas similares que não envolvam o patch do kernel ou de outros componentes do sistema?