Como impedir ataques do PHPMyAdmin?

6

Observamos muitos pedidos de arquivos setup.php inexistentes em nossos registros de acesso (veja abaixo). Para alguns de nossos clientes que usam regras de reconfiguração, cada uma dessas solicitações fará com que um script PHP seja executado, causando lentidão considerável no servidor e gerando tráfego desnecessário.

É possível negar rapidamente esse tipo de solicitação? Eu estava pensando em especificar uma regra geral de negação que nega todas as consultas relacionadas a setup.php , mas essa pode não ser a abordagem correta. Alguma sugestão?

217.115.202.30 - - [17/Nov/2010:09:13:35 +0100] "GET /PHPMYADMIN/scripts/setup.php HTTP/1.1" 404 2452 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:13:35 +0100] "GET /PMA/scripts/setup.php HTTP/1.1" 404 2444 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:13:39 +0100] "GET /PMA2005/scripts/setup.php HTTP/1.1" 404 2449 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:13:47 +0100] "GET /SSLMySQLAdmin/scripts/setup.php HTTP/1.1" 404 2452 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:13:42 +0100] "GET /SQL/scripts/setup.php HTTP/1.1" 404 2446 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:13:49 +0100] "GET /admin/phpmyadmin/scripts/setup.php HTTP/1.1" 404 2448 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:13:58 +0100] "GET /admin/scripts/setup.php HTTP/1.1" 404 2442 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:14:00 +0100] "GET /bbs/data/scripts/setup.php HTTP/1.1" 404 2448 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:14:01 +0100] "GET /cpadmin/scripts/setup.php HTTP/1.1" 404 2447 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:14:03 +0100] "GET /cpadmindb/scripts/setup.php HTTP/1.1" 404 2447 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:13:53 +0100] "GET /admin/pma/scripts/setup.php HTTP/1.1" 404 2447 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:14:05 +0100] "GET /cpanelmysql/scripts/setup.php HTTP/1.1" 404 2450 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:14:11 +0100] "GET /cpanelphpmyadmin/scripts/setup.php HTTP/1.1" 404 2452 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:14:13 +0100] "GET /cpanelsql/scripts/setup.php HTTP/1.1" 404 2448 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:14:23 +0100] "GET /cpphpmyadmin/scripts/setup.php HTTP/1.1" 404 2449 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:14:25 +0100] "GET /db/scripts/setup.php HTTP/1.1" 404 2441 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:14:26 +0100] "GET /dbadmin/scripts/setup.php HTTP/1.1" 404 2445 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:14:28 +0100] "GET /myadmin/scripts/setup.php HTTP/1.1" 404 2445 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:14:29 +0100] "GET /mysql-admin/scripts/setup.php HTTP/1.1" 404 2449 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:14:32 +0100] "GET /mysql/scripts/setup.php HTTP/1.1" 404 2448 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:14:33 +0100] "GET /mysqladmin/scripts/setup.php HTTP/1.1" 404 2447 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:14:35 +0100] "GET /mysqladminconfig/scripts/setup.php HTTP/1.1" 404 2453 "-" "ZmEu"
217.115.202.30 - - [17/Nov/2010:09:14:36 +0100] "GET /mysqlmanager/scripts/setup.php HTTP/1.1" 404 2449 "-" "ZmEu"
    
por Ton van den Heuvel 17.11.2010 / 10:13

4 respostas

2

Ainda relevante quase quatro anos depois.

Como presumivelmente o mod_rewrite está manipulando o tráfego legítimo, esses scripts não adicionarão muito mais à carga. Mas sim, eles podem causar um atraso momentâneo. Em geral, você não será capaz de evitar isso completamente.

Os mods e plugins para atenuar isso tendem a se concentrar em freqüências e taxas antes de bloquear o ip no firewall local (iptables). Uma abordagem melhor deve incluir assinaturas como fragmentos de nomes de diretórios (falsos em uso normal). Então, deve ser considerado como isso deve ser reativo. Pode-se adaptar partes do pacote "denyhosts" (um produto para proteger contra problemas semelhantes para logins de senhas SSH) para ler por trás do log e identificar as "assinaturas" para adicionar os endereços IP ao /etc/hosts.deny.

Como regra geral, essas pessoas não voltam do mesmo host, então podemos querer algo mais rápido. A beleza do código aberto é que podemos ajustá-lo. mod_evasive parece OK, mas e se o seu servidor é consultado por scripts legitimamente (curl, wget e afins). Por isso, não há CAPTCHA e a necessidade de listas brancas ou uma reinicialização por pars POST ou GET.

Para aqueles de vocês preocupados com o risco do ataque (o OP não estava, o OP estava incomodado com o consumo de recursos), se você realmente tem phpmyadmin então:

Use as diretivas por diretório.

ORDER DENY, ALLOW
DENY FROM ALL
ALLOW FROM *safe places*

Sério, muito poucas pessoas devem ter acesso. A menos que sejam um DBA, o que justifica o risco? Durante um incidente, o Apache pode ser reconfigurado sob demanda para abrir a porta de um único endereço. Se você estiver ausente, faça VPN em uma área de trabalho VNC / RDP na mesma rede ou use um proxy.

O script deles ainda te atingirá por 404 (e pelo menos um 403). Deixar pastas fictícias e código de configuração para eles encontrarem apenas os encoraja. Eu apenas uso o grep -v para filtrar os nomes dos diretórios.

    
por 01.06.2014 / 12:50
2

comece não servindo nenhum conteúdo do vhost padrão, de modo que os bots que atacam você cegamente com base em um endereço IP tenham menos chances de fazer uma solicitação que acione qualquer ação "pesada" do seu lado.

então você pode usar o fail2ban e verificar o conteúdo de seus logs + ips de bloco de onde vieram as verificações cegas.

    
por 17.11.2010 / 10:32
0

Agora estou usando o @ mod_evasive @ , que está se tornando uma ótima solução.

    
por 17.11.2010 / 15:20
0

Certifique-se de que o PHPMyAdmin esteja atualizado. Esconda-o, coloque-o em um diretório que eles não estarão procurando, como /padmin32 .

    
por 17.11.2010 / 20:06