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

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 queira executar alguns sites usando WordPress, alguns usando Redmine, outros usando Ruby on Rails, talvez alguns usando Django, e eu gostaria de servir a Mercurial repositórios também.

Nos servidores Dreamhost e em muitos outros servidores de configuração semelhante, tudo isso pode ser feito em uma única conta de usuário , mas posso ver algumas desvantagens dessa abordagem:

• Um arquivo .bashrc mais longo
• Se essa conta ficar comprometida, todos os sites serão executados nela.

Por outro lado, ter muitas contas de usuário pode ser um pouco difícil de acompanhar, especialmente se algumas delas tiverem requisitos idênticos em termos de software instalado. Por exemplo, ter uma conta para cada site executando 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 de alguém?

Por favor, poste suas opiniões sobre o assunto, apresentando suas razões.

Além disso, se você tiver algum motivo para pensar que a abordagem adotada em um servidor privado ou VPS deve diferir da abordagem adotada em um servidor compartilhado, descreva o que são e, novamente, seus motivos para eles.

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

Esta é (como eu ouvi pela última vez) ainda a Melhor Prática Atual, e a razão por trás disso é pura e simples paranóia: Esses serviços são expostos à Internet Grande e Ruim, se alguém encontrar uma vulnerabilidade e a explorar antes que eu tenha a chance de corrigir o problema. pelo menos estou confinando-os a uma conta de usuário, com apenas os privilégios necessários para executar o serviço único pelo qual é responsável.
De um modo geral, considero 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 plugin vulnerável do WordPress, tudo o que o Apache tem acesso (ou seja, todos os sites) é efetivamente vulnerável em caso de compromisso.

Assim, uma versão estendida desse argumento pode ser criada para sandboxing sites de clientes de hospedagem compartilhada com sua própria configuração e usuário do Apache (você não precisa necessariamente instalar uma pilha da web completa para cada site, apenas uma configuração do apache separada especificando um usuário diferente ), a desvantagem é que agora cada site está executando vários processos do Apache; portanto, o uso da RAM aumentou substancialmente e coisas legíveis pelo mundo ainda ficam vulneráveis ​​se uma única instância / usuário do Apache for comprometida.

Ampliando ainda mais o argumento para colocar cada Apache em um chroot (ou prisão se você estiver em sistemas BSD) pode ser criado para ainda mais segurança, mas agora você está falando de espaço em disco adicional, pois cada chroot / prisão precisará de todo o software necessário para execute o site que ele contém (e a necessidade de atualizar este software para todos os sites, em vez de apenas uma cópia principal no servidor quando os patches forem lançados), além do requisito de RAM como quando você tinha instâncias de usuários / apache separadas.
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 todos os sites em um servidor físico separado - que então se torna o argumento para separar os sites em diferentes vlans / sub-redes, etc.)

Como em todos os riscos, você não pode eliminá-lo: você só pode reduzi-lo a um nível aceitável com base no dano / custo potencial de um comprometimento, na probabilidade de um comprometimento e no custo de cada nível de mitigação.
Para meu dinheiro, para um ambiente de hospedagem compartilhado não crítico e sem comércio eletrônico, o básico "Um usuário para Apache, um para DNS, outro para correio etc." rede de segurança é suficiente. Se houver necessidade de segurança além desse nível, seus usuários deverão considerar seriamente seu próprio hardware.

Geralmente, o que faço é ter um usuário para serviços externos que não têm permissão para fazer login ("ninguém" por exemplo) e uma conta que tem permissão para fazer login e su ou sudo. Naturalmente, verifique se os nomes de usuário são diferentes e não são fáceis de adivinhar.

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