Prática recomendada para fornecer ao fornecedor do administrador do servidor acesso root (no CentOS)?

Question

Estou contratando um administrador de servidores freelancer (que é mais experiente do que eu - é por isso que eu os contratei) para fazer algum trabalho no meu VPS do CentOS. Eles exigirão acesso em nível de raiz ao servidor, já que eles precisam instalar os daemons do servidor e tal.

Qual é a melhor prática neste cenário: como posso identificar se o contratado instala kits raiz ou faz algo desagradável? O que eu fiz foi criar uma nova conta para o usuário, adicionar a nova conta ao grupo "wheel" e, em seguida, usar visudo para permitir que a roda de grupo executasse todos os comandos.

Existe algum outro passo que eu deveria dar? Aceito que, ao entregar privilégios de sudo, o contratado poderia fazer praticamente o que quisesse e, no final do dia, eu precisava confiar neles; Eu acho que, no mínimo, quero ter certeza de que tenho um registro de tudo o que eles fazem, apenas no caso.

Obrigado

    

Answer 1

Uma opção é usar as ferramentas de configuração do sistema, como o fantoche, para que elas possam descrever explicitamente o que deve ser feito no servidor. Claro, isso requer que alguém revise seu trabalho antes de aplicá-lo.

A outra opção é configurar uma rede syslog service. Ao encaminhar mensagens registradas para outro servidor que elas não controlam, você pode pelo menos garantir a integridade dos logs. Certifique-se de que o sistema registra logins / logouts e, de maneira ideal, restrinja o acesso ao sudo para que todos os comandos root possam ser originados para um usuário específico. Novamente, este servidor precisa ser acessível via root apenas para o menor número possível de pessoas.

    

Answer 2

Solução técnica : Imagem do servidor para que você possa comparar após o fato quais alterações foram feitas. Mantenha esta cópia longe deles.

Solução política : peça-lhes que assinem uma Declaração de Trabalho e contratem empreiteiros nos quais você possa confiar.

    

Answer 3

Como você pode impedi-lo de fazer o que quiser, você deve monitorar o sistema. A melhor maneira de fazer isso é exportar os logs para um local externo e usar um sistema de detecção de intrusão (HIDS) do host.

Você pode usar o splunk e o OSSEC juntos e monitorar o uso do sudo pelo administrador.

O OSSEC também notificará sobre alterações no sistema de arquivos e instalação de pacotes.

    

Answer 4

O que você está pedindo é difícil em condições normais. Você já indicou que eles sabem mais do que você, então está se aproximando da impossibilidade prática de monitorá-los quando eles têm privs equivalentes a você. (Eles realmente precisam de privs completos? Talvez não.)

Se essas pessoas não são alguém em quem você confia, você realmente não deveria estar trabalhando com elas. Como bem apontou matt.j.alexander, isso não é um problema técnico.

Sysadmins de qualidade estão preocupados com sua reputação por essa mesma razão. Eu mantenho meu nariz limpo , porque há muita confiança implícita necessária para que eu faça meu trabalho. Se perder essa confiança pessoal, é um sério problema de carreira.

    

Answer 5

Eu normalmente darei ao usuário uma conta que tenha tela como shell e com um .screenrc que registra tudo o que eles fazem. Dessa forma, posso monitorar o usuário em tempo real usando tail -f no log, além de manter um registro de todas as suas ações.

    

Answer 6

peça ao provedor vps uma foto antes de prosseguir

    

Answer 7

Existem monitores de código-fonte aberto que usam uma técnica cliente-servidor para monitorar o status de um cliente. Um deles é o Xymon (anteriormente conhecido como Hobbit), um fork do bem conhecido software de monitoramento Big Brother, mas implementado em C. Um recurso interessante é a capacidade de verificar um hash MD5 de um arquivo ou diretório. Claro, ele pode monitorar mais do que isso, mas você pode, por exemplo, criar alguns hashes MD5 de / etc / passwd, / etc / shadow, /etc/syslog.conf ou o que você não quiser que mudem silenciosamente. No servidor, você pode definir esses hashes a serem verificados periodicamente (o padrão é 5 minutos). Eles não devem ter acesso a esse servidor de monitoramento. Você também pode criar uma verificação para um cliente em execução no servidor em que estão trabalhando. Você pode não saber o que eles fizeram, mas você pode pelo menos ser notificado se eles mudaram algo que você não pediu para eles mudarem.

    

Answer 8

Uma coisa não mencionada até agora: crie uma cópia temporária de seu servidor para que eles não tenham acesso ao site ativo. Peça-lhes que trabalhem na cópia de teste. Em seguida, periodicamente ou depois de concluídos, compare os dois sites e sincronize as alterações. Dessa forma, você tem a chance de revisar ou reverter qualquer coisa que eles façam.