Quais são os usuários e níveis de permissão mais apropriados para sites Drupal em hospedagem compartilhada?

Embora o site Drupal entre em detalhes sobre permissões e segurança, existem apenas referências vagas / pouco claras à hospedagem compartilhada . Do ponto de vista do Drupal, qual é a configuração mais segura (níveis de propriedade e permissão) para um site em hospedagem compartilhada?

Como exemplo do tipo de informação que estou procurando, o WordPress sugere as seguintes configurações de hospedagem compartilhada:

• Todos os arquivos devem pertencer à conta do usuário real, não à conta do usuário usada para o processo httpd.
• A propriedade do grupo é irrelevante, a menos que haja requisitos de grupo específicos para a verificação de permissões do processo do servidor da web. Este não é geralmente o caso.
• Todos os diretórios devem ser 755 ou 750.
• Todos os arquivos devem ser 644 ou 640. Exceção: wp-config.php deve ser 600 para impedir que outros usuários no servidor o leiam.
• Nenhum diretório deve receber 777, mesmo os diretórios de upload. Como o processo php está sendo executado como proprietário dos arquivos, ele obtém permissões dos proprietários e pode gravar até em um diretório 755.

Opções de hospedagem

As opções de hospedagem para um site geralmente são um dos seguintes:

• servidor dedicado
• servidor privado virtual (VPS)
• Hospedagem Compartilhada

Com um servidor dedicado, apenas um site é hospedado em um computador físico e a configuração é tão segura quanto o próprio computador.

Com um VPS, seu software é executado no mesmo computador físico que as máquinas virtuais de outros usuários. No entanto, é funcionalmente equivalente a um servidor dedicado. Mais importante, um VPS tem a privacidade e a segurança de um servidor dedicado.

Com hospedagem compartilhada, seu site reside em um sistema de arquivos compartilhado com outros usuários. Infelizmente, isso o torna menos seguro do que quando está sendo executado em um servidor dedicado ou VPS. O restante deste artigo discute a segurança de um WCMS no ambiente de hospedagem compartilhada.

Meio Ambiente

Um ambiente de hospedagem compartilhada pode ser considerado como consistindo em um servidor web, um sistema de arquivos, um arquivo de configurações, um banco de dados e alguns usuários.

Nos exemplos a seguir, supõe-se que a conta do proprietário seja "tom" e que o arquivo de configurações (mantendo credenciais do banco de dados) seja denominado "settings.php".

O processo do servidor da web pode ser executado com as permissões de usuário da conta do proprietário "tom" ou com as permissões de grupo do grupo "www", dependendo da configuração.

Além disso, é assumido um ambiente Gnu / Linux ou Unix padrão, e supõe-se que o leitor entenda o sistema de controle de acesso Unix com permissões de leitura (r), escrita (w) e diretório de execução / acesso (x) separadas, divididas em três blocos (usuário, grupo, outro).

Antes de continuar discutindo configurações específicas, pode ser útil listar as condições que queremos satisfazer:

1. Para um site estar operacional, o servidor da web deve ter acesso de leitura a todos os arquivos que compõem o site e acesso ao diretório a todos os diretórios que compõem o site.
2. Para operação segura, o servidor da Web não deve ter acesso de gravação a nenhum dos arquivos que ele manipula.
3. Para operação segura, um script da web executado por um usuário não autorizado não deve ter acesso de leitura aos arquivos pertencentes a outro usuário.
4. Para que o proprietário trabalhe em seu próprio site usando a CLI, o usuário deve ter acesso de leitura e gravação aos seus próprios arquivos.
5. Para proteger os arquivos de serem acessados ​​por outros usuários usando a CLI, o bloco "other" não deve ter permissões definidas.

Infelizmente, em um host compartilhado, você pode ter apenas 4 de 5. Não sei como você pode satisfazer todas as cinco condições em um host compartilhado.

Tanto quanto eu sei, duas configurações diferentes são usadas por provedores de host compartilhado. Ambos são discutidos abaixo, juntamente com as permissões a serem usadas para melhor proteger arquivos e diretórios e quais condições a configuração falha em satisfazer.

Configuração 1: o servidor Web está sendo executado como proprietário

Essa é a configuração mais usada do AFAIK. O servidor da web está sendo executado como proprietário dos arquivos. Isso significa que um usuário não autorizado não pode usar seu servidor da Web para executar um script para ler os arquivos de outro usuário. Esse tipo de configuração também protege os usuários um do outro na CLI.

No entanto, isso também significa que não podemos ter permissões separadas para o proprietário e o servidor da web. Para satisfazer a condição 2 com esse tipo de configuração, você precisa restringir as permissões de gravação do proprietário para impedir o acesso de gravação do servidor da Web a tudo, exceto ao diretório de upload.

Permissões:

Directories:  500 r-x --- --- tom.tom
Files:        400 r-- --- --- tom.tom
settings.php: 400 r-- --- --- tom.tom
Upload Dir.:  700 rwx --- --- tom.tom

Infelizmente, isso significa que a condição 4 não pode ser satisfeita. Ou seja, o site não pode ser mantido através da CLI. O proprietário será obrigado a usar algum tipo de painel baseado na Web para acessar o site (minha recomendação é que o proprietário mantenha uma cópia em algum servidor intermediário no qual ele tenha acesso irrestrito e espelhe as alterações feitas no servidor intermediário no host compartilhado )

Configuração 2: o servidor da Web está sendo executado como um membro do grupo www

Essa configuração é usada por alguns provedores menos profissionais (IMHO) de uma solução de host compartilhado. O servidor da web está sendo executado como membro do grupo www e recebe o acesso de leitura necessário através do bloco do grupo:

Permissões:

Directories:  750 rwx r-x --- tom.www
Files:        640 rw- r-- --- tom.www
settings.php: 640 rw- r-- --- tom.www
Upload Dir.:  770 rwx rwx --- tom.www

Essas configurações têm a vantagem de conceder ao proprietário acesso total aos seus arquivos por meio da CLI e restringe o servidor da Web apenas ao acesso de leitura.

No entanto, ele também falha em satisfazer a condição 3. Ou seja, permite que um usuário não autorizado no host compartilhado (ou um hacker que comprometeu o site de outro usuário que compartilha o host) execute um script para ler qualquer arquivo que possa ser lido pelo servidor. servidor web. Isso dá ao script não autorizado acesso ao arquivo settings.php com as credenciais do banco de dados, o que torna trivial assumir completamente o controle do site.

Minha recomendação é evitar esse tipo de configuração.

Adendo: Qual é o perigo de usar um host compartilhado?

Eu certamente não colocaria nada sensível, como números de cartão de crédito ou registros médicos, em um host compartilhado. Mas a hospedagem compartilhada é barata, e há uma atração nisso. Eu mesmo uso a hospedagem compartilhada em vários sites. Ainda não fui invadido, mas sei que o risco existe e estou preparado para o dia em que isso acontecer. Se eu for hackeado, simplesmente excluirei tudo no host compartilhado e reinstale o site a partir de uma cópia espelhada que mantenho em um servidor de armazenamento temporário seguro.

Com "config 2", o principal problema são os outros . Se algum outro site com o qual você compartilhar o host for comprometido, ele também será o almoço. Fazer a segurança depender de outra parte que você não conhece e não tem controle não é uma boa ideia. É por isso que minha recomendação é evitar arranjos de hospedagem do tipo "config 2".

Com "config 1", você sozinho controla a segurança do seu site. Isso é melhor (em particular se você sabe o que está fazendo). Mas não é à prova de idiotas. Ninguém é perfeito, e se você melhorar e seu site estiver comprometido, o invasor terá acesso a todos os arquivos armazenados no host que lhe pertence. Em outras palavras, para minimizar a perda de dados quando você é invadido, não mantenha nada nesse host que possa causar danos se outra pessoa tiver acesso a ele. Em particular, não mantenha seu email nesse host compartilhado. Geralmente, existem muitos dados confidenciais no email, portanto você não o deseja nem perto de um servidor Web executando como "você".

E se o seu aplicativo da web estiver lidando com dados confidenciais, verifique se o seu orçamento permite um host dedicado ou um VPS.

Você também pode consultar este guia para Proteger permissões e propriedade de arquivos em Drupal.org.