[FUGSPBR] PHP + Segurança

Seg Abr 7 10:04:46 BRT 2003

Luiz,

Muito obrigado pela ajuda, me ajudou bastante.

Um abraço,
Ronan

On Sat, 05 Apr 2003 21:59:26 -0300
"Luiz Rodrigues Maia Neto" <maianeto em inf.ufsc.br> wrote:

> 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?"
> 
> 
> 
_______________________________________________________________
Sair da Lista: http://www2.fugspbr.org/mailman/listinfo/fugspbr
Historico: http://www4.fugspbr.org/lista/html/FUG-BR/