Em qual usuário o apache e o PHP devem estar sendo executados? Quais permissões os arquivos / var / www devem ter?

39

Eu apenas criei uma caixa do Ubuntu 11.10 e então executei apt-get install apache2 php5 para instalar o apache2 e o PHP 5 na caixa. Agora ele está funcionando como um "servidor web" e carrega o "Funciona!" página. Agora estou tentando reforçar a segurança e tenho as seguintes perguntas sobre servidores web linux:

  1. Quem deve estar usando o apache?
  2. Em que grupo (s) esse usuário deve estar?
  3. Que pacote (s) pode fazer o PHP (e o Apache?) rodar como o dono dos arquivos? (como em hosts da Web compartilhados) Devo usar esses pacotes? Eles são fáceis / viáveis de manter em um sistema pequeno?
  4. Quais devem ser as permissões padrão para arquivos e pastas sendo veiculados na web com o apache sendo executado como www-data ? Para apache / php sendo executado como usuário?

Eu fiz as seguintes coisas no exame da configuração padrão:

Estrutura de arquivos

Quando eu cd / e faço uma listagem ls -al do conteúdo, vejo /var :

drwxr-xr-x 13 root root  4096 2012-02-04 20:47 var/

Se eu cd em var e ls -al eu vejo:

drwxr-xr-x  2 root root  4096 2012-02-04 20:47 www/

Finalmente, dentro de /var/www , vejo:

drwxr-xr-x  2 root root 4096 2012-02-04 20:47 ./
drwxr-xr-x 13 root root 4096 2012-02-04 20:47 ../
-rw-r--r--  1 root root  177 2012-02-04 20:47 index.html

Meu principal argumento é que até agora todos esses arquivos pertencem a root:root , os arquivos têm permissões de 644 e os diretórios têm permissões de 755.

Permissões do Apache

Se eu criar um arquivo como root em /var/www/test.php com o conteúdo:

<?php echo shell_exec('whoami');

e carregar esse arquivo em um navegador, ele me diz www-data , que é o mesmo que no arquivo /etc/apache2/envvars :

export APACHE_RUN_USER=www-data
export APACHE_RUN_GROUP=www-data

Se eu ps aux | grep -i apache , vejo o seguinte:

root      1916  1.2 104664  7488 Ss   20:47 /usr/sbin/apache2 -k start
www-data  1920  0.8 105144  5436 S    20:47 /usr/sbin/apache2 -k start
www-data  1921  1.0 105144  6312 S    20:47 /usr/sbin/apache2 -k start
www-data  1922  0.7 104688  4624 S    20:47 /usr/sbin/apache2 -k start
www-data  1923  0.7 104688  4624 S    20:47 /usr/sbin/apache2 -k start
www-data  1924  0.7 104688  4624 S    20:47 /usr/sbin/apache2 -k start
www-data  1925  0.7 104688  4624 S    20:47 /usr/sbin/apache2 -k start

Então, quem é o apache executando como? Parece que talvez o primeiro processo seja como root , talvez do script /etc/init.d/apache quando o sistema foi iniciado e os outros como www-data gerados desde o primeiro. Isso está correto?

Em seguida, se eu digitar groups www-data , vejo www-data : www-data - por isso, parece estar apenas no grupo www-data . Eu estou supondo que esta é uma prática padrão também.

Hospedagem Compartilhada e Segurança

Então, se eu entendi as coisas corretamente, se o apache está rodando como www-data e eu quero que o apache consiga ler um diretório, o x bit precisa ser definido para o grupo world (other) ( o+x ), e isso também precisa ser definido em todos os diretórios pai até a cadeia ( www , var ). E se eu quiser que o apache consiga ler um arquivo, então o o+r bit precisa ser definido.

Infelizmente, acredito que isso introduz uma falha de segurança para vários aplicativos e / ou vários usuários na mesma caixa linux: Todos os arquivos da web precisam ser legíveis e, portanto, também podem ser acessados por outros aplicativos e outros usuários no sistema. . Se um aplicativo instalado no sistema tivesse uma vulnerabilidade de segurança que permitisse entrada do usuário bruta e não validada, que era então executada pelo PHP, um invasor remoto poderia então procurar todos os outros arquivos no sistema web que fossem legíveis por todo o mundo. Da mesma forma, se a caixa tivesse vários usuários e um usuário conhecesse o caminho dos arquivos da web de outro usuário, ele poderia ler o conteúdo do arquivo (e ver coisas sensíveis como sequências de conexão com o banco de dados, etc.).

Já ouvi falar de dois pacotes, suphp e phpsuexec , que tratam de permitir que os arquivos dos usuários sejam exibidos "como eles" em um sistema compartilhado. Uma das sutilezas disso é que ele permite que aplicativos da Web (como o Wordpress) criem e modifiquem arquivos - muito úteis para adicionar temas, plugins e atualizar softwares. É claro que é provavelmente mais seguro fazer essas coisas manualmente, mas um compromisso pode ser feito talvez com um dos pacotes mencionados acima? Ou possivelmente usando chown para fazer com que o grupo de diretórios wordpress pertença a www-data e defina o bit fixo no grupo ( g+s )?

Eu só os usei como usuário final de uma empresa de hospedagem e, por isso, não sei os detalhes deles e se eles são até razoáveis para instalar em um sistema pequeno ou se há Há algumas outras medidas de segurança que devo usar em vez disso, mas pensei em mencioná-las aqui, pois elas parecem ser uma maneira possível de resolver algumas das minhas preocupações.

Voltar para as perguntas

  1. Quem deve estar usando o apache?
  2. Em que grupo (s) esse usuário deve estar?
  3. Que pacote (s) pode fazer o PHP (e o Apache?) rodar como o dono dos arquivos? (como em hosts da Web compartilhados) Devo usar esses pacotes? Eles são fáceis / viáveis de manter em um sistema pequeno?
  4. Quais devem ser as permissões padrão para arquivos e pastas sendo veiculados na web com o apache sendo executado como www-data ? Para apache / php sendo executado como usuário?
por cwd 04.02.2012 / 23:02

2 respostas

17
  1. não raiz
  2. não raiz
  3. SuEXEC
  4. Depende. 644 para arquivos e 755 para pastas são um padrão seguro.

Não altere a propriedade de nada para o www-data, a menos que você queira que o php possa editar o conteúdo desse arquivo / pasta

Independentemente de qualquer outra coisa que você faça: as pastas precisam de permissões de leitura e execução para o usuário encontrar arquivos; os arquivos precisam de permissão de leitura para o usuário lê-los. Se você receber algum erro de permissão ao alterar as coisas, você conseguiu remover essas permissões fundamentalmente necessárias.

Se você não está escrevendo nenhum arquivo através do seu aplicativo php, você pode deixar arquivos de sua propriedade: você. Nessa circunstância, a permissão do mundo (xx4 / 5) é a que se aplica.

Se você deixar os arquivos como de sua propriedade: com permissões de arquivo de 644 (arquivos), o que isso significa é que somente você pode editar os arquivos do site - www-data não é você - por isso não pode editar os arquivos.

Se você quiser restringir o acesso ao apache + você e bloquear todos os outros acessos chown -R you:www-data * . Com permissões de arquivo de 640 e permissões de pasta de 750 você pode editar, www-data pode ler - porque então o apache lê a permissão de grupo (x4 / 5x).

Restrinja ao mínimo os caminhos para os quais o apache / php pode gravar - se houver um diretório tmp em que o aplicativo precise gravar - permita que ele grave em aquela pasta - e para qualquer gravável Se possível, certifique-se de que o local está fora da raiz do documento ou tome medidas para garantir que esse caminho gravável não seja acessível pela Web.

Note que "você" não deve ser raiz. Permitir acesso ssh direto como root é um indicador de outros lapsos de segurança (como não desabilitando o login por senha), mas isso é um monte de perguntas para si mesmo.

    
por 05.02.2012 / 00:41
10

So if I understand things correctly, if apache is running as www-data and I want apache to be able to read a directory, the x bit needs to be set for the world (other) group (o+x), and that also needs to be set on all parent directories all the way up the chain (www, var). And if I want apache to be able to read from a file, then the o+r bit needs to be set.

Isso não é verdade, você não precisa definir rwx para 'outro'. Você deve alterar o proprietário e / ou grupo da pasta / arquivo específico que você está tentando proteger. Por exemplo:

chown -R cwd:www-data /var/www/cwd.com
chmod 750 /var/www/cwd.com

Agora, apenas membros do grupo www-data podem ler /var/www/cwd.com . E só você (cwd) pode escrever para ele. Se você quiser permitir que seus aplicativos (através do Apache) escrevam / modifiquem arquivos nesse diretório também, você chmodá-lo para 770.

Acho que isso abrange todos os seus problemas, não vejo razão para alterar o usuário que o apache está sendo executado.

    
por 04.02.2012 / 23:55