Rate limiting: identificar e deletar comportamentos abusivos #338
Comments
|
Ótima ideia de criar regras por IP, só precisamos tomar cuidado que quando falando de IP estamos falando do IP de saída da internet. Existem empresas por exemplo com vários funcionários utilizando o mesmo IP de saída, Mas acredito que seria só ajustar o item: Podemos criar uma tabela "castigo" assim que um IP quebrar as regras colocamos um castigo por um período. |
Pensei exatamente isso @rodrigoKulb ! Aqui em casa por exemplo somos dois que são cadastrados no TabNews. Nesse cenário só ia poder fazer um cadastro por dia hehe. Acredito que a regra de 1 conta por IP por dia é algo muito rigoroso. Esse limite poderia até existir, mas deveria ser algo pra +10 por conta de empresas.
O ideal é realmente não termos um controle de criação de conta por IP e sim essa blacklist temporária (ou até permanente?) em caso do não cumprimento das demais regras. Assim um IP na blacklist não conseguiria criar contas. |
Por algum motivo, isso me deu um calor no coração 😍 E total, as regras precisam atrapalhar o máximo que puder só quem estiver abusando. Outra regra interessante a se criar é de tentativas de login. Nesse caso a gente deveria ser abusado e responder uma resposta que imite uma resposta real para o script do atacante não saber que caiu na regra. |
|
Em outra Issue falei sobre o recaptcha, não considera uma opção? Exemplo errou o login já aparece na 2 tentativa. O Google reCAPTCHA é um serviço gratuito para contas que realizam até 1 milhão de avaliações por mês em qualquer de suas versões. Entretanto, as contas que geram avaliações além de 1 milhão devem pagar taxas. Para até 10 milhões de avaliações por mês, o preço da taxa é de US$1 a cada mil avaliações. |
Acho uma solução totalmente válida 🤝 talvez até já de largada no cadastro. |
|
Implementado pelo PR #444 🤝 |
Contexto
Hoje o TabNews não possui nenhuma proteção contra DoS ou DDoS, tanto em ataques contra a infraestrutura, quanto ataques de conteúdo. Eventualmente precisaremos colocar um Cloudflare na frente, mas eu não sei se ele vai identificar um ataque de conteúdo, por exemplo alguém fazer um script que crie 1 conteúdo a cada minuto, durante 60 minutos. Se ele identificar, alguém me avisa para eu configurar, se não, vamos executar no modo manual.
Execução
Acredito que nessa hora todo mundo irá recomendar usar alguma outra tecnologia de cache, como o Redis, mas vamos explorar qual o máximo que conseguimos da instância mínima de Postgres da AWS. Então a ideia é em cada Controller do site colocar um middleware (assim como fazemos para injetar o id da request) que terá a responsabilidade por tomar nota do evento (o
ipque está fazendo a requisição, oiddo usuário, qual tipo de requisição, ou outras informações que quisermos) e ele mesmo irá verificar os dados e decidir continuar com a request ou não.Então com esses dados poderíamos criar regras como (só exemplo mesmo):
ipnão pode criar mais do que uma conta por dia.ipnão pode criar mais do que 10rootcontents por hora.ipnão pode criar mais do que 30childcontents por hora.ipnão pode fazer mais do que 500 requests por hora.E com essas regras, poderíamos criar consequências e side-effects, por exemplo:
iptentou criar mais do que 10rootcontents dentro de uma hora, automaticamente ouserrelacionado tem suas features removidas, e todos esses conteúdos (ou todos os conteúdos da conta), são alterados paradraft(ou se a gente tiver certeza que é um ataque, colocar tudo paradeleted) e fazer a request retornar uma mensagem para entrar em contato com o suporte.The text was updated successfully, but these errors were encountered: