Quando devo criar uma nova conta de usuário para executar o software em um servidor?

Question

Em geral, quando alguém deve criar uma nova conta de usuário para executar um software voltado para a Internet em um servidor?

Por exemplo, suponha que eu esteja usando um servidor Debian compartilhado (por exemplo via Dreamhost) e eu quero rodar alguns sites usando o WordPress, alguns usando Redmine, alguns usando Ruby on Rails, talvez alguns usando Django, e eu gostaria para servir repositórios do Mercurial também.

Nos servidores Dreamhost e em muitos outros servidores similares, tudo isso pode ser feito sob uma única conta de usuário , mas vejo algumas desvantagens nessa abordagem:

• Um .bashrc mais longo
• Se essa conta for comprometida, o mesmo acontece com todos os sites em execução.

Por outro lado, ter muitas contas de usuário pode se tornar um pouco difícil de controlar, especialmente se algumas delas tiverem requisitos idênticos em termos de software instalado. Por exemplo, ter uma conta para cada site que executa o WordPress pode ser um exagero.

Qual é a melhor prática? É simplesmente uma questão de reduzir o número de sites hospedados (ou repositórios hospedados, etc.) por conta de usuário proporcionalmente ao nível de paranóia?

Por favor, publique suas opiniões sobre isso, dando suas razões para elas.

Além disso, se você tiver motivos para pensar que a abordagem adotada em um servidor privado ou VPS deve diferir da abordagem adotada em um servidor compartilhado, descreva quais são e, mais uma vez, suas razões para eles.

    

Answer 1

Geralmente sou fã de "Um usuário para qualquer coisa que abre o soquete de escuta na rede" - Um para o Apache, um para o Mail, um para o DNS, etc.

Esta é (como ouvi pela última vez) ainda a Melhor Prática Corrente, e a razão por trás disso é paranóia simples e simples: Esses serviços são expostos à Big Bad Internet, se alguém encontrar uma vulnerabilidade e explorá-la antes que eu tenha uma chance para corrigir o software, pelo menos estou limitando-os a uma conta de usuário, com apenas os privilégios necessários para executar o único serviço pelo qual é responsável.
De modo geral, considero que esse nível de isolamento é suficiente para proteger o sistema, embora cada aplicativo seja uma ilha de vulnerabilidade (por exemplo, se alguém instala um plug-in vulnerável do WordPress todos os itens aos quais o Apache tem acesso todos os sites) são efetivamente vulneráveis no caso de um compromisso.

Uma versão estendida desse argumento pode ser feita para sandboxing de sites de clientes Hosting Compartilhado com sua própria configuração e usuário do Apache (você não precisa necessariamente instalar uma pilha web completa para cada site, apenas uma configuração separada do apache) um usuário diferente), a desvantagem é que cada site agora está executando um monte de processos Apache, então seu uso de RAM aumentou substancialmente, e coisas que são legíveis ao mundo ainda estão vulneráveis se qualquer instância / usuário do Apache ficar comprometido.

Estendendo ainda mais o argumento para colocar cada Apache em um chroot (ou cadeia se você em sistemas BSD) pode ser feito para ainda mais segurança, mas agora você está falando sobre espaço adicional em disco já que cada chroot / jail precisará de todo o software necessário para executar o site que ele contém (e a necessidade de atualizar este software para cada site, em vez de apenas uma cópia mestre no servidor quando os patches saírem), além do requisito de RAM como quando você tinha usuários / instâncias de apache separados. br> Isso mitiga tudo, exceto um bug do OS / Kernel que permite que os usuários saiam do chroot (que se torna o argumento para executar cada site em um servidor físico separado - que se torna o argumento para separar os sites em diferentes vlans / subnets, etc.)

Como com todos os riscos, você não pode eliminá-lo: você só pode reduzi-lo a um nível aceitável com base no potencial dano / custo de um comprometimento, na probabilidade de um comprometimento e no custo de cada nível de mitigação.

Pelo meu dinheiro, para um ambiente de hospedagem compartilhada não-crítica, não-E-Commerce, o básico "Um usuário para Apache, um para DNS, um para e-mail, etc." rede de segurança é suficiente. Se houver necessidade de segurança além desse nível, seus usuários devem considerar seriamente seu próprio hardware.

    

Answer 2

Geralmente, o que faço é ter um usuário para serviços externos que não tem permissão para efetuar login ("nobody", por exemplo) e uma conta com login permitido e su ou sudo. Naturalmente, certifique-se de que seus nomes de usuário sejam diferentes e não sejam fáceis de adivinhar.

Não vejo um usuário por serviço como necessário, a menos que você esteja executando um ambiente de hospedagem compartilhada em que cada cliente tenha um login. Se você realmente se vê como um alvo muito atraente para hacking, você pode isolar o máximo possível. No entanto, a menos que você esteja fazendo algo muito controverso ou hospedando dados financeiros, você não é realmente atraente de um alvo.