Solicitações autenticadas com limitação de taxa * un *


11

Digamos que temos um balanceador de carga que também limita a taxa. A limitação de taxa parece bastante direta para usuários logados - basta olhar para o JWT e talvez usar um armazenamento de dados na memória para ver quantas solicitações nos últimos 10 segundos para esse usuário.

No entanto, e os usuários não conectados (não autenticados)? Não sabemos ao certo quem eles ou de onde a solicitação vem exatamente, portanto, não é possível limitar facilmente essas solicitações ou ..?

Existem soluções integradas para isso na AWS e em outras plataformas de hospedagem, é algo com que precisamos nos preocupar? Parece que precisamos lidar com a lógica de limitação de taxa de usuários logados manualmente, mas e quanto a usuários não logados?

Meu palpite / esperança é que possa haver algum mecanismo interno para solicitações não autenticadas de limitação de taxa em plataformas de hospedagem, informe-nos a todos.


2
Esta página nunca menciona usuários conectados. Na verdade, as técnicas descritas não são citados como uma atenuação de ataques de força bruta contra senhas, o que implica usuários que não estão conectados.
Robert Harvey

1
Por que você deseja usar a limitação de taxa? É para combater ataques de negação de serviço, para impedir que os usuários excedam seu plano de pagamento, algo mais? O caso de uso afeta os métodos que você pode usar efetivamente.
Bart van Ingen Schenau

1
Esta questão pode ser mais adequado para security.stackexchange.com , embora eu não estou dizendo que é off-topic
Peeyush Kushwaha

@BartvanIngenSchenau todos os itens acima?

Por que você deveria ter dois limites de taxa diferentes? Você está vendendo algum tipo de "plano" com diferentes restrições / recursos?
LAIV

Respostas:


9

No entanto, e os usuários não conectados (não autenticados)? Não sabemos ao certo quem eles ou de onde a solicitação vem exatamente, portanto, não é possível limitar facilmente essas solicitações ou ..?

Existem algumas abordagens que você pode adotar. Uma é que você precisa de um identificador de origem razoavelmente confiável, por exemplo, endereço IP. Você pode classificar o limite pelo endereço IP, para que os ataques a uma única máquina comprometida sejam limitados. Essa é uma abordagem bastante simples, mas há uma desvantagem de que grandes provedores de rede podem usar apenas endereços IP de saída únicos para ocultar um número muito grande de usuários atrás de um NAT.

Outra abordagem para limitar a taxa que você pode adotar é exigir uma prova de trabalho para quaisquer solicitações não autenticadas. Seu servidor emite um código de desafio que todos os clientes que fazem solicitações não autenticadas (por exemplo, solicitações de login) precisam calcular uma resposta intensiva em recursos antes que a solicitação seja processada. Uma implementação comum dessa idéia exige que os clientes calculem uma reversão parcial de hash.


Não vejo como a "prova de trabalho" pode impedir ataques do DOS? O cliente pode ignorar o desafio e continuar enviando solicitações até a falha. Existe um terceiro processo lidando com o desafio?
LAIV

4
O @Laiv POW pode ser emitido e verificado de forma confiável, distribuído sem conectar-se a um banco de dados central, onde é que a maioria dos outros esquemas de limitação de taxa falha. Aumenta o custo de um ataque para um invasor, pois reduzir sua defesa e aumentar o fator de carga é mais barato para você e usuários legítimos do que aumentar o ataque para o invasor. Isso cria um desincentivo econômico para atacar o sistema, pois também efetivamente exclui dispositivos de baixa potência (por exemplo, impressoras comprometidas, IOT, roteadores) de serem usados ​​como uma plataforma de ataque eficaz.
Lie Ryan

6

Para saber se uma solicitação é de um usuário autenticado ou de um usuário anônimo, você precisa necessariamente processar a solicitação (embora rapidamente). Isso ainda significa que seu aplicativo está vulnerável a um ataque de negação de serviço.

Você deve verificar as solicitações gerais por segundo e, se um determinado número for excedido, você simplesmente ignora o restante. Esse número deve ser suficientemente alto para não causar problemas durante o funcionamento normal, mas deve proteger contra esses ataques.

Além disso, como regra geral, você provavelmente não deve assumir que um ataque não viria de um usuário autenticado, pelo menos no que diz respeito a ataques do DOS. Uma senha fraca permitiria facilmente a alguém presumir a identidade de um usuário antigo. Portanto, supondo que você possa fazer essa verificação, seus usuários (humanos) nunca devem precisar executar solicitações a essas taxas, não obstante, simplesmente porque você tem muitos usuários individuais.


Suponho que você possa usar endereços IP e definir um limite de taxa alto para cada um. Eu acho que um ataque DoS bem orquestrado poderia usar milhares de endereços IP? talvez mais? idk ... Estou ciente de que o mesmo endereço IP pode ser usado para vários clientes diferentes, mas eu diria que há uma forte probabilidade de que seja o mesmo usuário, certo?
Alexander Mills

@AlexanderMills Bem, suponha que você tenha decidido que o algoritmo seria verificar várias solicitações do mesmo endereço IP. Mesmo se houver milhares, eles seriam repetidos para mais de 1000 solicitações. Seu servidor registra a primeira solicitação de um determinado endereço IP e a inundação começa .. seu servidor já está com pedidos pendentes .. você não pode processar solicitações suficientes para obter a segunda repetição do mesmo IP (que ainda pode ser uma solicitação legítima a propósito). Protegeria contra ataques de DoS onde o mesmo IP é usado apenas. Melhor usar os dois se houver. : P
Neil

0

Uma das principais ofertas da Cloudflare é a proteção contra ataques de negação de serviço, fornecendo um proxy inteligente para o seu API / servidor da web. O serviço básico é gratuito; eles ganham dinheiro com outros serviços relacionados, como serviços CDN e balanceamento de carga. Eles também fornecem serviços de Limitação de taxa mais sofisticados e controláveis , atualmente à taxa de US $ 0,05 por 10 mil solicitações boas (sem cobrança por solicitações rejeitadas), mas é necessário atualizar para planos pagos para obter mais de uma regra global.

Você pode usar o serviço Cloudflare com a AWS ou qualquer outra plataforma, desde que tenha controle sobre os servidores de nomes do domínio (como em, você pode alterar os servidores de nomes registrados para o seu domínio).

Você pode fornecer limites de taxa separados para usuários anônimos e conectados, direcionando os usuários conectados a URLs diferentes. Por exemplo, você pode simplesmente prefixar todos os seus caminhos de URL disponíveis anonimamente com '/ u' para criar um terminal que sempre exige autenticação e tem um limite de taxa diferente.

Observe que o limite de taxa do Cloudflare (como todos os limites comerciais para usuários anônimos que conheço) define um cliente por seu endereço IP. Isso pode causar problemas para as pessoas que usam VPNs comerciais ou Tor, uma vez que tendem a ocultar um grande número de clientes atrás de 1 endereço IP para aumentar a privacidade.


0

Na AWS, existem os serviços relacionados AWS Shield e AWS WAF . Eles são destinados principalmente à prevenção de ataques DDoS, mas também oferecem suporte à limitação de taxa com base em endereços IP.

No WAF, o conceito é chamado de Regras Baseadas em Taxa . A prevenção de tentativas de login baseadas em força bruta é mencionada como um caso de uso no anúncio original :

Esse novo tipo de regra protege os sites e as APIs dos clientes de ameaças como ataques DDoS na camada da web, tentativas de login de força bruta e bots incorretos. As regras baseadas em taxa são acionadas automaticamente quando as solicitações da Web de um cliente excedem um determinado limite configurável.

Outros provedores de nuvem devem ter ofertas semelhantes. Aqui está uma comparação tabular: Google Cloud Armour x AWS WAF x Cloudflare WAF .

Como você já está usando o Nginx, o uso da limitação de taxa interna baseada em IP também pode ser uma opção simples. O módulo é chamado ngx_http_limit_req_module . Esta postagem do blog descreve como pode ser usada.

Observe que a limitação de taxa baseada em IP é um conceito relativamente simples, mas não é perfeito:

  • Os endereços IP podem ser compartilhados (pessoas que trabalham no mesmo escritório), levando a falsos positivos
  • Um invasor pode ter acesso fácil a vários endereços IP e usá-los para contornar os limites (ataque de logon de força bruta distribuída)

Em geral, os endereços IP são um bom começo. Mas se você precisar de uma proteção mais forte, suas melhores opções dependerão do modelo do seu encadeamento (que tipo de ataques você deseja impedir).

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.