Re: [FUGSPBR] PHP + Segurança

Sáb Abr 5 21:59:26 BRT 2003

Ronan, 

A permissao padrao do /etc somente permite a escrita do usario root 
e/ou do grupo wheel. Alterar suas permissoes de acordo com sua 
sugestao equivale a montar esta particao, para os demais usuarios, 
como "read-only" (ro),  acredito eu. Isto significa que, por exemplo, 
nenhum usuario podera obter os dados armazenados na base de dados de 
usuarios, shell e home, por exemplo. Quaisquer outras informacoes, 
como descobrir quem eh o resolver do DNS neste servidor nao podera 
ser obtido por seus usuarios. Nao tenho certeza se um usuario comum 
conseguiria trocar de senha. Acho que esta eh uma opcao valida (a 
utilizo frequentemente) para obter maior confiabilidade em servidores 
cuja base de usuarios e configuracoes raramente sao alteradas. 
Montando a particao raiz (/) como read-only obtemos um filesystem 
imune (virtualmente) a problemas logicos. Se este fosse um servidor 
cuja base de usuarios nao sofre-se alteracoes, acredito que esta 
seria uma opcao razoavel. Como, acredito eu, sua expectativa eh que 
sua base de clientes aumente a ponto de voce necessitar, rapidamente, 
de um segundo servidor, um terceiro... :)
Todavia, nao garante limites e/ou retricoes aos scripts que forem 
executados no servidor Apache. 

Supondo que voce esta utilizando o Apache, hospedando dominios 
atraves de VirtualHosts, com PHP instalado na forma de um modulo, uma 
opcao eh determinar os parametros de ambiente que podem e/ou devem 
ser impostos aos seus usuarios. Pode experimentar estas opcoes para 
impor certas restricoes a seus usuarios. 

<IfModule mod_php4.c>
  php_value include_path ".:/usr/local/lib/php"
  php_admin_flag safe_mode on
</IfModule>
<IfModule mod_php3.c>
  php3_include_path ".:/usr/local/lib/php"
  php3_safe_mode on
</IfModule>

Tambem nao eh aconselhado que o seu php.ini habilite a execucao de 
extensoes ext/posix em um ambiente onde seguranca eh um dos 
objetivos. Estas restricoes podem ser complementadas por uma classe 
especifica de login, ajustada para, entre outros aspectos, 
estabelecer o valor da variavel coredumpsize como zero. Uma serie de 
tecnicas de acesso nao autorizado podem ser consideravelmente 
prejudicadas atraves deste artificio. 

Tambem eh possivel adicionar a sua configuracao de VirtualHost uma 
diretiva do tipo open_basedir, estabelecendo que cada script PHP seja 
executado em um ambiente chroot que toma por base a localizacao 
indicada na variavel DocumentRoot.

<VirtualHost www.exemplo.com.br>
ServerName www.exemplo.com.br
 DocumentRoot /www/exemplo
[...]
 <Location />
  php_admin_value open_basedir     \ "/www-
home/exemple.com/:/usr/lib/php/"
</Location>
</VirtualHost>

Esta configuracao, somada a variavel "safe_mode on", restringe a 
utilizacao de binarios aos diretorios indicados. De outra forma o PHP 
pode ser configurado para cada VirtualHost indicando diretorios 
especificos (php_admin_value open_basedir "/home/username/"), 
restringindo o acesso de cada usuario a apenas a seus arquivos. 
executando o Apache como o usuario www, por exemplo, e tornando este 
usuario membro de todos os grupos definidos para cada VirtualHost, 
nenhum diretorio necessita de premissoes de leitura amplas. Desta 
forma usuarios nao podem ler scripts php atraves de scripts cgi ou 
atraves de um acesso shell. Lembre-se que a intrucao safe_mode on 
inibe certas funcionalidades do PHP, ocasionando erros quando 
instrucoes PHP como backticks (``), system(), exec(), passthru() sao 
utilizadas.. 

Outro jogo de bola completamente diferente eh observado quando 
utilizamos o PHP para executar CGIs no servidor Apache. Uma opcao 
para este modelo de execucao eh compilar o Apache com suporte a opcao 
SuExec. Desta forma eh possivel determinar o usuario que executa os 
scripts e a hierarquia de diretoios onde estes estao armazenados e os 
diretorios acessiveis aos scripts, previnindo acessos nao autorizados 
a areas restritas. Outro caminho possivel eh impor o redirecionamento 
de CGIs no Apache. As diretivas abaixo podem realizar esta operacao:

Action php-script /cgi-bin/php.cgi
AddHandler php-script .php

Esta opcao indica ao seu servidor que, ao receber uma requisicao como 
a URL abaixo:

http;//exemplo.com.br/minhapagina/teste.html

a reescreva na forma abaixo:

http://exemplo.com.br/cgi-bin/php/minhapagina/teste.html

Para que esta operacao seja possivel compile seu binario PHP com a 
opcao "--enable-force-cgi-redirect" e estabeleca valores aprorpiados 
para a as variaveis doc_root euser_dir no arquivo php.ini.

Tambem eh possivel determinar o montante de recursos que podem ser 
utilizados por cada VirtualHost, dificultando a execucao de 
determinados tipos de exploits, atraves das instrucoes abaixo, 
ajustando a carga que um VirtualHost pode "empurrar" para o servidor 
Apache.

LimitRequestBody 4096
RLimitCPU 5 15
RLimitMEM 8192 16384
RLimitNPROC 10 15

Lembre-se tambem que estes scripts sao ativos, mas estao restritos a 
arvore determinada pela diretiva DocumentRoot do Apache. A inclusao 
da opcao "SymLinksIfOwnerMatch" determina que links simbolicos 
somente serao seguidos se existir correspondencia entre os "donos" da 
origem e do destino. A nao inclusao da opcao Indexes inibe a 
capacidade de obter uma lista dos arquivos de um diretorio que nao 
apresente um arquivo index valido.

Recomendo o livro Professional Apache Security. Emprestei-o semana 
passada a um amigo e nao me recordo de todas as opcoes indicadas 
pelos autores. Outra opcao eh o livro Apache Administrator's 
Handbook. Entretanto, todas as opcoes mencionadas e inumeras outras 
estao documentadas na Internet. Uma busca no Google deve retornar a 
documentacao necessaria para uma investigacao mais acurada. Aqui, no 
RExLab, adotamos estas restricoes na execucao do PHP sem grandes 
transtornos, apenas uma pequena adequacao dos desenvolvedores eh 
necessaria, indicando claramente as restricoes em vigor. 

[]'s

Luiz Maia

Windows: "Where do you want to go tomorrow?"
Linux: "Where do you want to go today?"
FreeBSD: "Are you, guys, comming or what?"

-------------- Próxima Parte ----------
_______________________________________________________________
Sair da Lista: http://www2.fugspbr.org/mailman/listinfo/fugspbr
Historico: http://www4.fugspbr.org/lista/html/FUG-BR/