Qual usuário o apache e o PHP devem estar executando? Quais permissões os arquivos / var / www devem ter?

Acabei de rodar uma caixa do Ubuntu 11.10 e depois corri apt-get install apache2 php5para instalar o apache2 e o PHP 5 na caixa. Agora 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 o apache deve estar executando como?
2. Em quais grupos esse usuário deve estar?
3. Quais pacotes podem fazer o PHP (e Apache?) Rodar como o proprietário 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 veiculados na Web com o apache em execução www-data? Para o apache / php sendo executado como usuário?

Fiz o seguinte no exame da configuração padrão:

Estrutura do arquivo

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

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

Se eu cdem vare não ls -alvejo:

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

Finalmente, por dentro /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 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 /var/www/test.phpcom o conteúdo:

<?php echo shell_exec('whoami');

e carregue esse arquivo em um navegador www-data, que é o mesmo que o /etc/apache2/envvarsarquivo:

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

Se eu ps aux | grep -i apachevejo 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 está executando o apache? Parece que talvez o primeiro processo seja como root, talvez do /etc/init.d/apachescript quando o sistema foi iniciado, e os outros como www-datagerados desde o primeiro. Isso está correto?

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

Hospedagem e segurança compartilhadas

Portanto, se eu entendo as coisas corretamente, se o apache está sendo executado como www-datae quero que o apache possa ler um diretório, o xbit precisa ser definido para o mundo (outro) group ( o+x) e isso também precisa ser definido em todos os pais. diretórios por toda a cadeia ( www, var). E se eu quiser que o apache seja capaz de ler um arquivo, o o+rbit precisará 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 pelo mundo e, portanto, também são acessíveis por outros aplicativos e outros usuários do sistema. Se um aplicativo instalado no sistema tivesse uma vulnerabilidade de segurança que permitisse entrada bruta e não validada do usuário, que era então executada pelo PHP, um invasor remoto poderia procurar todos os outros arquivos no sistema da web que fossem legíveis mundialmente. 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 cadeias de conexão de banco de dados, etc.).

Já ouvi falar de dois pacotes, suphpe phpsuexecque lidam com permitindo que os arquivos dos usuários para ser servido 'como eles' em um sistema compartilhado. Uma das vantagens disso é que ele permite que aplicativos da Web (como o Wordpress) criem e modifiquem arquivos - muito útil para adicionar temas, plugins e atualizar softwares. É claro que provavelmente é mais seguro fazer essas coisas manualmente, mas pode ser feito um compromisso talvez com um dos pacotes mencionados acima? Ou, possivelmente, usando chownpara tornar o grupo de diretórios do wordpress pertencer www-datae definir o bit no grupo ( g+s)?

Eu os usei apenas como o usuário final de uma empresa de hospedagem na web e, portanto, não conheço os detalhes deles, e se eles são razoáveis ​​para instalar em um sistema pequeno ou se há algum outro medidas de segurança que eu deveria usar, mas pensei em mencioná-las aqui, pois elas parecem ser uma maneira possível de abordar algumas de minhas preocupações.

Voltar para as perguntas

1. Quem o apache deve estar executando como?
2. Em quais grupos esse usuário deve estar?
3. Quais pacotes podem fazer o PHP (e Apache?) Rodar como o proprietário 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 veiculados na Web com o apache em execução www-data? Para o apache / php sendo executado como usuário?

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 mude a propriedade de nada para 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 que o usuário encontre arquivos; os arquivos precisam de permissões de leitura para que o usuário os leia. 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 estiver gravando nenhum arquivo pelo aplicativo php, poderá deixar os arquivos de sua propriedade: você. Nessa circunstância, a permissão mundial (xx4 / 5) é a que se aplica.

Se você deixar os arquivos como pertencentes a você: você com permissões de 644 (arquivos), o que isso significa é que apenas você pode editar os arquivos do site - www-data não é você -, portanto, não pode editar os arquivos.

Se você deseja 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 o apache lê a permissão de grupo (x4 / 5x).

Restrinja ao mínimo os caminhos para os quais você deseja que o apache / php grave - se houver um diretório tmp no qual o aplicativo precise gravar - permita que ele escreva apenas nessa pasta - e para qualquer local gravável, se possível, verifique se está fora do diretório raiz do documento ou tome medidas para garantir que esse caminho gravável não seja acessível pela Web.

Observe que "você" não deve ser root. Permitir acesso direto ao ssh como root é um indicador de outros lapsos de segurança (como não proibir o login de senha), mas isso é um monte de perguntas.

Portanto, se eu entendo as coisas corretamente, se o apache está sendo executado como www-data e quero que o apache seja capaz de ler um diretório, o bit x precisa ser definido para o grupo (outro) mundo (o + x), e isso também precisa ser definido em todos os diretórios principais até a cadeia (www, var). E se eu quiser que o apache seja capaz de ler um arquivo, o bit o + r precisa ser definido.

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

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

Agora apenas os membros do grupo www-datapodem ler /var/www/cwd.com. E somente você (cwd) pode escrever para ele. Se você deseja permitir que seus aplicativos (através do Apache) gravem / modifiquem arquivos nesse diretório, você também o modifica para 770.

Eu acho que isso cobre todos os seus problemas, não vejo razão para alterar o usuário em que o apache está sendo executado.