Bloqueando solicitações HTTP inválidas para o aplicativo PHP

Question

Pela primeira vez em alguns anos, sou semi-responsável por ajudar na administração do servidor de um aplicativo da Web PHP (servido usando o Apache).

Estamos vendo várias solicitações de URLs inválidos, que considero serem investigações relacionadas a malware / exploração. Coisas como

r/www/cache/static/home/img/logos/nuomi_ade5465d.png
cgi-bin/test.sh
cgi-sys/entropysearch.cgi

Eu gostaria de bloquear essas solicitações, tanto para os maus atores como para os meus registros. Para esse fim, tenho algumas perguntas

1. Em geral, o bloqueio por endereço IP funciona? Eu sei que faz muito tempo desde "IP Address = = dispositivo único na Internet", mas eu estou querendo saber se esse tipo de sondagem geralmente vem do tipo de redes onde seria seguro para mim apenas bloqueá-las completamente

2. Se eu não conseguir bloquear por endereço IP, alguém mantém uma lista de URLs que os maus atores geralmente pesquisam para que eu possa bloquear por URL?

3. Re: # 2 - Se eu fosse lidar com esse bloqueio no nível do servidor, qual módulo do apache é adequado para esse tipo de coisa? ( MOD_REWRITE , MOD_SECURITY )

4. Existe uma maneira melhor de bloquear essas solicitações que não sejam IP ou URL?

5. Além disso, o sistema está hospedado no EC2 - a Amazon oferece alguma ajuda com esse tipo de coisa?

Answer 1

1. Bloqueio de endereços IP será uma corrida que você não pode ganhar. Essas solicitações geralmente vêm de botnets ou sistemas hackeados. Eu sugeriria bloquear o IP apenas como uma solução temporária para um incidente concreto em que as solicitações causam problemas ao seu lado.

2. Não tenho conhecimento de tal lista

3. Ambos irão funcionar. Mas eu suponho (não testado) que apenas ignorar os pedidos será na verdade menos intenso de CPU

4. Use um proxy reverso (por exemplo, verniz ou mesmo mod_cache) para armazenar em cache ocorrências negativas (404). Assim, as solicitações para as mesmas URLs (não existentes) podem ser tratadas muito rapidamente e não exigem a verificação do sistema de arquivos toda vez.

5. Desconhecido

Answer 2

1. Will, in general, blocking by IP address work? I know it's been a long time since "IP Address == unique device on Internet", but I'm wondering if these sort of probes generally come from the sort of networks where it'd be safe for me to just block them outright

Você pode facilmente bloquear muitas das solicitações usando um simples arquivo .htaccess. Lá você pode bloquear IPs, URLs e muitas coisas. Mas não sei qual é a origem dos seus "pedidos ruins". O que eu sei é que você deve começar interrompendo o tráfego ruim que conhecemos. E isso pode ser feito se você aumentar o seu objetivo e, em vez disso, parar a negação de ataques de serviços e, ao mesmo tempo, limitar os pedidos ruins! Tudo o que você precisa é neste recurso muito útil . No entanto, eles não dizem realmente quais módulos instalar. Eu recomendo: mod_antiloris , mod_evasive mas você pode encontrar mais cargas aqui .

Eu pessoalmente verificaria a configuração de algumas dessas antes de passar para hard-blocking certos urls ou ips. No entanto, se você quiser começar a limitar padrões específicos, pode ser mais fácil fazê-lo usando um PHP scrict. Ou seja Encaminhe todos os parâmetros para index.php e analise-os lá. Isso ainda exigiria um redirecionamento usando o arquivo .htaccess. O Drupal faz algo assim:

# Pass all requests not referring directly to files in the filesystem to
# index.php. Clean URLs are handled in drupal_environment_initialize().
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !=/favicon.ico
RewriteRule ^ index.php [L]

Ao fazer isso, você pode "capturar" todas as URLs incipientes. Drupal realmente tem este built-in e irá dizer-lhe que a pessoa X estava procurando o arquivo Y. E Drupal novamente também tem módulos que podem bloquear o acesso certo com certas regras. Se isso for possível, tenho certeza que conectar-se ao PHP irá expô-lo a várias opções diferentes que você pode usar para bloquear ou não o acesso de ips.

Acho que propus uma solução, mas preciso de mais informações para aconselhar mais. Se você fizer o acima, você será capaz de reunir mais informações para talvez identificar a fonte exata de suas aflições de pedido ruim. Usando essas ferramentas, você poderá ver padrões e, no mínimo, aprender maneiras melhores de configurar regras para bloquear os malfeitores.

2. If I can't block by IP address, does anyone maintain a list of URLs that bad actors generally probe for so I can block by URL?

Existem módulos do apache que fazem isso e usam suas próprias bibliotecas. Existem também bibliotecas para PHP que fazem isso e várias redes que rastreiam "bandidos", sejam spammers usando IPs ou spam usando endereços de email, etc. Aqui está uma lista completa de pessoas que acompanham os servidores que ficam na lista negra por vários motivos. Experimente digitando www.google.com.br.

3. Re #2. If I was going to handle this blocking at the server level, which apache module is right for this sort of thing? (MOD_REWRITE, MOD_SECURITY)

MOD_REWRITE trabalharia para obter o pedido para um arquivo PHP, após o qual você pode lidar com o problema no PHP. Mas isso tem um pouco de sobrecarga. Você é melhor de usar MOD_SECURITY e talvez MOD_EVASIVE

4. Is there a better way to block these requests other than by IP or URL?

Isso realmente depende. Você deve estudar os padrões que surgem e identificar a causa. Fiquei muito frustrado por termos recebido solicitações de "transparent.png" (ou algo assim) que se tornaram um novo pedido padrão para muitos telefones celulares. Nós pensamos que era ruim, era bom. Não acabe fazendo isso.

5. Also, the system is hosted on EC2 -- does amazon offer any help with this sort of thing?

Eu não sei. Fora da minha própria experiência pessoal, que foi mais com o uso para enviar informações, ficamos na lista negra muito rapidamente, mesmo enviando menos de 2500 e-mails. Mas se você estiver hospedando com eles e quiser que eles bloqueiem as "solicitações incorretas" recebidas, eles já devem estar fazendo isso até certo ponto. A menos que você tenha um exército de bots em massa atacando seu servidor a cada poucos dias, você deve pedir para eles intervirem. Talvez peça-lhes para ajudá-lo a identificar a fonte ou fazer sua própria investigação e decidir a partir daí.

    

Answer 3

No meu entender, não há uma maneira perfeita e documentada de lidar com esses problemas. Você só pode minimizar as tentativas suspeitas em seu aplicativo da Web.

Sim, os IPs podem ser bloqueados no Apache. Verifique os documentos do Apache aqui . Ele usa mod_rewrite e fornece o código de resposta 403 ao cliente se o IP estiver na lista negra. É um trabalho doloroso monitorar os logs e manter hosts.deny

Um trabalho menos doloroso do que a primeira opção é se você conhece o padrão desses URLs inválidos, use mod_rewrite para bloquear as solicitações de acordo com o padrão solicitado. Estendendo a regra usada em uma primeira opção, adicione condições extras à regra.

RewriteMap hosts-deny txt:/path/to/hosts.deny
RewriteCond ${hosts-deny:%{REMOTE_ADDR}|NOT-FOUND} !=NOT-FOUND [OR]
RewriteCond ${hosts-deny:%{REMOTE_HOST}|NOT-FOUND} !=NOT-FOUND [OR]
RewriteCond %{QUERY_STRING} <any suspicious keyword/pattern> [NC,OR]
RewriteCond %{REQUEST_URI} <any suspicious keyword/pattern> [NC] 
RewriteRule ^ - [F] 

Adicione regras diferentes com base no que seu site faz. Digamos que seu site só exiba .php arquivos adicione apenas mais uma condição ao código acima. RewriteCond %{REQUEST_URI} !.php$ [NC]

    

Answer 4

O Fail2ban foi projetado para fazer exatamente o que você descreve. Por exemplo. veja link

Você pode configurá-lo para ser sensível a (por exemplo) 404 respostas. Ou você pode até configurar honeypots nas URLs para aumentar as bandeiras pretas imediatas para o fail2ban agir.

Com relação a perguntas específicas:

1. sim, vai funcionar, mas cuidado, você não usa o DOS por ter links ruins

2. Essa lista ficaria desatualizada rapidamente - é por isso que você deve usar o tráfego como fonte de dados. Mas / ^ / cgi-bin / e /.asp(x+)$/ são coisas que você pode querer sinalizar em preto

3. Nenhum módulo necessário, a menos que você queira redirecionar as URLs sinalizadas negras para um manipulador mais sofisticado

4. Você está pagando à Amazon por um serviço e nos perguntando por que está pagando?