De limitar a banir

O curso anterior terminou com um conjunto funcional de limites. Login limitado por endereço e por conta, cadastro e redefinição de senha contidos, um limite geral de volume. Contra um script que martela o mais rápido que consegue, isso basta.

Contra um script que lê a resposta, não basta.

A lacuna

Um throttle tem um período, e um período é uma promessa. Dez tentativas por minuto significa que quem espera ganha mais dez:

12:00:00   10 tentativas   →  10 permitidas, e então 429
12:01:00   10 tentativas   →  10 permitidas, e então 429
12:02:00   10 tentativas   →  10 permitidas, e então 429
...
14.400 tentativas por dia, de um endereço, inteiramente dentro dos seus limites

Nada está quebrado. O limitador faz o que você configurou, e quem ataca faz o que o limitador permite. Catorze mil tentativas de credential stuffing por dia é um ataque real conduzido com educação.

A peça que falta é memória. Um throttle conhece a janela atual e nada mais. Então um cliente que se comporta mal, espera, e se comporta mal de novo parece dois clientes sem relação que se comportaram mal uma vez cada.

Banir é um throttle com braço mais longo

flowchart LR
  R["Requisições"] --> T["Throttle: esta janela passou do limite?"]
  T -->|"sim"| N["429 — zera na próxima janela"]
  T --> F["Fail2Ban: este cliente errou N vezes em findtime?"]
  F -->|"sim"| B["Bloqueado por bantime — toda requisição, não só o excesso"]
  B --> E["Expira sozinho"]

Três números o descrevem, e eles são o vocabulário do resto deste curso:

"Três falhas em dez minutos, bloqueado por uma hora" é uma frase com formato diferente de "dez requisições por minuto". Ela carrega memória entre janelas, e recusa tudo daquele cliente em vez de só o excesso.

Quando escalar é certo

Nem sempre, e ser claro sobre isso evita o erro mais comum deste curso:

Certo para sinais inequívocos. Um pedido de /etc/passwd, uma sondagem por /.env, um login com um e-mail que não existe tentado quarenta vezes. Nenhum cliente legítimo faz isso, então um falso positivo é quase impossível.

Errado para sinais ambíguos. Uma pessoa que esqueceu a senha e tentou seis vezes, um cliente móvel repetindo numa conexão instável, um escritório onde quatro pessoas entraram ao mesmo tempo. Banir aqui produz um chamado de suporte e uma pessoa que não consegue usar o seu produto.

A assimetria é o princípio de projeto inteiro: o custo de um falso positivo é muito maior que o de um falso negativo. Quem ataca e escapa tenta de novo e é pego pelo próximo sinal; um cliente bloqueado vai embora. Todo limiar deste curso deveria ser definido com essa razão em mente, e ela defende banir por tipo de comportamento em vez de por volume dele.

O que um banimento não é

• Não é permanente. Um banimento sem prazo é uma fila de suporte que você criou, e a aula 3 desenvolve o porquê.
• Não é identidade. Você está bloqueando um endereço ou uma chave, não uma pessoa. A pessoa se move; o endereço é reatribuído a alguém inocente.
• Não é dissuasão. Ninguém desiste. Ele encarece, que é o mesmo enquadramento honesto do curso anterior.
• Não é livre de danos colaterais. Bloquear um endereço compartilhado bloqueia todo mundo atrás dele, que é o problema do discriminador grosso, escalado.

O que este curso cobre

1. De limitar a banir (esta aula).
2. Fail2Ban e Allow2Ban.
3. Escalada e recuo.
4. Sinais além da contagem.
5. A borda, e o que a sua aplicação não deve fazer.
6. Resposta a abuso e operação.
7. Juntando tudo: uma defesa em camadas.

Pontos-chave

• Um throttle não tem memória entre janelas, então quem tem paciência ganha o orçamento inteiro todo período, indefinidamente.
• Banir acrescenta memória: maxretry falhas dentro de findtime bloqueiam um cliente por bantime.
• Um banimento recusa tudo daquele cliente, não só as requisições acima de um limite.
• Escale em sinais inequívocos; os ambíguos produzem chamados de suporte e clientes perdidos.
• Um falso positivo custa muito mais que um falso negativo, e todo limiar deve refletir isso.