Atrasando a execução do script PHP

Question

Qual é a melhor maneira de parar os bots, usuários maliciosos etc. de executar scripts PHP muito rápido? Tudo bem se eu usar o usleep() ou sleep() Funções para simplesmente fazer "nada" por um tempo (pouco antes do código desejado executar), ou isso é estúpido e há maneiras melhores para isso?

Exemplo:

function login() {
 //enter login code here
}

function logout() {
 //enter logout code here
}

Se eu apenas coloque, digamos, usleep(3000000) Antes dos códigos de login e logout, tudo bem, ou há maneiras melhores e mais sábias de alcançar o que eu quero alcançar?

editar: Com base nas sugestões abaixo, faz então usleep ou sleep Faça com que o processador se desengate do script atual que está sendo executado pelo usuário atual ou faz com que ele se desenrole de todo o serviço? ou seja, se um usuário+script invocar um sleep/usleep, todos os usuários simultâneos+scripts também serão adiados?

Answer 1

A maneira como a maioria dos servidores da Web funciona (Apache, por exemplo) é manter uma coleção de threads de trabalhadores. Quando um script PHP é executado, um thread executa o script PHP.

Quando seu script faz sleep(100), o script leva 100 segundos para executar. Isso significa que o seu tópico de trabalhador está amarrado por 100 segundos.

O problema é que você tem um número muito finito de threads de trabalhadores - digamos que você tenha 10 threads e 10 pessoas login - agora seu servidor da Web não pode atender mais respostas.

A melhor maneira de avaliar os logins do limite (ou outras ações) é usar algum tipo de coisa rápida de armazenamento na memória (Memcached é perfeito para isso), mas isso requer um processo separado e é bastante complicado (você pode fazer isso se executar algo como o Facebook ..).

Mais simples, você pode ter uma tabela de banco de dados que armazena user_id ou ip_address, first_failed e failure_counter.

Toda vez que você recebe um login com falha, você (no código pseudo) fazia:

if (first_failed in last hour) and (failure_counter > threshold):
    return error_403("Too many authentication failures, please wait")
elseif first_failed in last hour:
    increment failure_counter
else:
    reset first_failed to current time
    increment failure_counter

Talvez não seja o mais eficiente, e existem maneiras melhores, mas deve parar muito bem de forças brutas. Usar o memcached é basicamente o mesmo, mas o banco de dados é substituído por memcached (o que é mais rápido)

Answer 2

Para parar os bots, usuários maliciosos etc. de executar scripts PHP muito rápido?

Eu primeiro perguntava o que você está realmente tentando prevenir? Se forem ataques de negação de serviço, eu teria que dizer que não há nada que você possa fazer se estiver limitado pelo que pode adicionar aos scripts PHP. O estado da arte está muito além do que nós, como programadores, podemos proteger. Comece a analisar as ferramentas Sysadmin projetadas para esse fim.

Ou você está tentando limitar seu serviço para que as pessoas reais possam acessá -lo, mas os bots não podem? Nesse caso, eu examinaria algumas técnicas "Captcha".

Ou você está tentando impedir que os usuários pesquisem seu site a cada segundo procurando um novo conteúdo? Nesse caso, eu investigaria o fornecimento de um feed RSS ou alguma outra maneira de notificá -los para que eles não consumam sua largura de banda.

Ou é outra coisa?

Em geral, eu diria que nem o sono () nem a USleep () são um bom caminho.

Answer 3

Seu método sugerido forçará todos os usuários a esperar desnecessariamente antes de fazer login.

A maioria dos servidores de lâmpadas (e a maioria dos roteadores/comutadores, na verdade) já está configurada para evitar ataques de negação de serviços. Eles fazem isso negando várias solicitações consecutivas do mesmo endereço IP.

Answer 4

Você não quer dormir no seu PHP. Isso reduzirá bastante o número de solicitações simultâneas que seu saque pode lidar, pois você terá conexões mantidas em espera aberta.

A maioria dos servidores HTTP possui recursos que você pode ativar para evitar ataques de DOS, mas, sem que você deve rastrear endereços IP que você já viu muitas vezes recentemente e envie um 403 proibido com uma mensagem pedindo que esperassem um segundo.

Se, por algum motivo, você não pode contar com o Remote_addr sendo específico do usuário (todos por trás do mesmo firewall, etc.), você pode provar um desafio no formulário de login e fazer com que o navegador remoto faça um cálculo estendido sobre ele (digamos, fator um número ) que você pode verificar rapidamente no lado do servidor (com multiplicação rápida).