De sua própria descrição, sugiro que você comece removendo o contador e veja se isso realmente faz diferença. É tão facilmente testado que estou surpreso que você ainda não tenha feito isso.
Eu tenho um problema estranho - em um site de alto tráfego (milhões de visitantes por mês), todos os dias recebemos cerca de 20 situações em que um host começa a solicitar incessantemente a mesma página, várias vezes por segundo, por qualquer período de tempo, de alguns minutos até o dia todo.
O ataque aparentemente não é malicioso, já que recorri ao endereço IP e combinei com alguns dos nossos usuários registrados, que entrevistei. Eles dizem que, quando isso acontece, um contador de javascript no nosso site "continua atualizando", o computador fica lento, mas é de outra forma utilizável. Isso não acontece em todas as páginas, mas esporadicamente.
Os hits de log têm a seguinte característica:
Estamos no final da sagacidade com o que fazer com isso. Um simples filtro DoS não é apropriado - nós temos isso e o limite para acioná-lo é muito maior do que uma única solicitação de página (sem imagens relacionadas, css, etc.) por segundo.
A pilha é LAMP, Redhat install, PHP 5.2, Apache 2.2.3, com uma caixa NGINX operando como um balanceador de carga de software.
Isso está destruindo nosso site-- por favor ajude! Na ausência de boas idéias, vamos recorrer à criação de um filtro fictício que armazena uma chave de IP + URI no memcached e incrementa cada solicitação de página. Uma vez que cruzar um determinado limite em um determinado período de tempo, serão 403 pedidos adicionais. Eu não acho que este é o lugar apropriado na pilha de rede para lidar com esse problema, no entanto.
Obrigado por qualquer coisa que você possa contribuir!
De sua própria descrição, sugiro que você comece removendo o contador e veja se isso realmente faz diferença. É tão facilmente testado que estou surpreso que você ainda não tenha feito isso.
Procurando hits e enviando um 403 está realmente mascarando o problema. Parece que uma maneira melhor de corrigir o problema seria corrigir o javascript defeituoso na página ofensiva.
O problema com a solução memcached é que você ainda está obtendo os resultados, mas está planejando evitar qualquer trabalho intensivo para atendê-la, verificando o memcached e determinando se isso é uma solicitação incorreta. Isso é trabalho em si, embora com certeza, pode estar salvando seu servidor web ou servidor de banco de dados alguns cpu.
A outra abordagem para usar o memcached para isso é calcular a resposta para esse URI e, se for exclusivo do IP, armazenar a resposta codificada pelo IP + URI no memcached, se não apenas codificar por URI com qualquer outros parâmetros de solicitação exclusivos que variam a resposta. Em seguida, responda a todas as solicitações com qualquer resposta armazenada em cache com menos de X segundos. Agora você ainda está recalculando a cada X segundos, mas isso é menos que muitos laços por segundo. Acredito que um proxy ou um servidor da web com memcache poderia ser configurado para fazer isso sem escrever nada de mais, digamos MemProxy , ou Nginx respectivamente.
Chegar à causa principal do mau comportamento seria preferível. Se estiver relacionado a JavaScript, pode ser JavaScript associado a um anúncio específico em suas páginas. Você precisa ter um mecanismo em desenvolvimento para recarregar a página com cada anúncio possível. Se você não tem isso, você não pode acabar pegando os anúncios que estão dando problemas a alguns usuários.