Gostaria de reduzir o tráfego e a largura de banda usados por bots que enviam URLs GET para testar falhas de segurança "clássicas" em um site.
URLs como GET /.env GET /.git/config GET /phpinfo.php ..
quando olho meus logs, há milhares deles. Alguns dos bots mudam seus IPs regularmente, alguns deles continuam mudando suas strings User-Agent, ..
Então, eu estava pensando em uma lista codificada extraída dos meus logs e enviar a eles um 403 Forbidden ou algo assim, mas eu gostaria de torná-la rápida o suficiente para que o nginx ou o varnish pudessem lidar com esse filtro rápido o suficiente para que isso não afetasse seu desempenho.
Você já tentou lidar com esse fluxo constante de solicitações com essa lista? Existe algum truque especial, como uma árvore binária no Nginx ou Varnish, que pode ajudar a configurar uma lista enorme de caminhos para uma correspondência rápida?
Na verdade, pode doer mais se você enviar
403 Forbidden
o 404 padrão.403 Forbidden
pode ser interpretado como "há algo aqui, tente mais".A única maneira eficaz de reduzir o tráfego/largura de banda usada por bots é usar um serviço como o Cloudflare na frente do seu serviço web. Eles filtrarão o tráfego de acordo com as regras que você definir e seu servidor de origem receberá menos tráfego ruim.
Como o Varnish compila sua configuração VCL em código de máquina, a execução do código VCL será rápida o suficiente para não se preocupar com desempenho, mesmo que a lista de itens cresça.
Correspondência de URL estática
O código poderia ser tão simples quanto isto:
Correspondência de padrões regex
É claro que você também pode combinar padrões de URL com expressões regulares, conforme ilustrado no código abaixo:
Armazene regexes em um arquivo separado
Se você quiser armazenar as regras de bloqueio em um arquivo separado, posso recomendar o módulo de reescrita que faz parte do Varnish Enterprise e do Varnish Pro .
Você pode criar um arquivo de texto com os padrões, que se parece com isto:
Isso reescreverá os padrões correspondentes para
/block
e assim que virmos a/block
URL entrar, retornaremossynth(403)
. Este seria o código VCL correspondente:Se você alterar o conteúdo de
/etc/varnish/block.txt
, você tem que recarregar o arquivo VCL através desudo varnishreload
. Isso não tem impacto no cache e não reiniciará ovarnishd
processo, ele apenas recarregará a configuração VCL e carregará/etc/varnish/block.txt
.Caso você não queira usar 403
Outras respostas e comentários referem-se ao fato de que um
403
código de status pode causar mais danos do que benefícios, porque indica que algo está lá .Você poderia chamar
return(synth(404))
em vez disso, mas também poderia retornar uma200
resposta real com conteúdo falso. E é aí que você pode alavancar respostas sintéticas no Varnish e estendervcl_synth
.Aqui está um exemplo:
Então, se você executar um
return(synth(700))
, a resposta sintética será convertida em um200
status real com algum conteúdo Lorem ipsum como corpo da resposta.No entanto, uma
404
resposta também poderia funcionar.