Em serviços públicos da web, basicamente não há defesa contra atacantes em nível fundamental

Olá, sou incompetente.

Os ataques têm aumentado bastante ultimamente, então vou escrever algumas coisas meio que de qualquer jeito.

Não existe uma defesa fundamental contra ataques vindos de clientes HTTP

Antes de mais nada, vamos pensar em cada uma das possíveis defesas.

Endereço IP

Com um endereço IPv6, tudo bem, mas, em um ambiente CGNAT, é atribuído um endereço IPv4 compartilhado, o que acaba envolvendo também vítimas que não são o alvo do ataque.
Além disso, a rotação de IPs é fácil. Nos últimos tempos, tornou-se comum realizar ataques DDoS usando milhares de endereços IP obtidos de VPS baratos nos EUA, país que possui muitos IPs, ou de ambientes de nuvem chineses, ambos bastante usados para ataques. Mesmo que se bloqueie por número de sistema autônomo (AS), se houver serviços operando na China, bloquear os IPs de nuvens chinesas não resolve o problema de forma fundamental e ainda prejudica um pouco os usuários chineses.
Em geral, os próprios ambientes de nuvem chineses são muito usados indevidamente por pessoas de outros países, então não acho que sejam algo que se deva bloquear indiscriminadamente.

Minha opinião é que, se um serviço faz parte da World Wide Web, não quero bloqueá-lo indiscriminadamente, desde que exista ao menos uma pessoa que aproveite esse serviço.
Eu mesmo assisto a vídeos no BiliBili de vez em quando e também uso serviços dos EUA.

User-Agent

Basicamente, não há muito o que dizer: considero quase inútil avaliar os próprios cabeçalhos da requisição como critério para restringir o acesso.
Como é possível falsificá-lo à vontade, não dá para bloquear com base apenas em uma avaliação direta do UA.
Uma possibilidade seria bloquear completamente quem se identifica com um UA de googlebot se o host de DNS reverso não for *.googlebot.com ou *.google.com, como faço neste site. Mas seria preciso verificar se isso requer uma implementação própria ou se algo semelhante já é feito pelo CDN. Além disso, embora o Google diga isso oficialmente, há também alguns bots legítimos enviados pelo Google cujo host de DNS reverso não é nenhum desses; portanto, não dá para confiar inteiramente apenas nesse critério.

A propósito, até mesmo um site tão insignificante como este recebe estas tentativas de se passar pelo Googlebot:
relatório do fail2ban - fake-googlebot

Bloqueio por país

Pode servir como medida provisória quando há um ataque, mas não tem utilidade como solução permanente. O motivo é o mesmo que no caso dos endereços IP, então não vou repetir.
No entanto, pode ser útil se o serviço for voltado apenas ao mercado interno.

Impressão digital TLS

Também é fácil falsificar uma impressão digital TLS.
Isso acontece porque basta incorporar ao cliente HTTP a mesma biblioteca criptográfica usada no navegador para falsificar a impressão digital do navegador.
Não é que não tenha efeito algum, mas, por exemplo, se um bot legítimo usar a mesma biblioteca criptográfica para enviar requisições, ele será bloqueado por engano.
Como há um alto risco de coincidir com muitos clientes HTTP, não dá para avaliar isso isoladamente.
Por isso, pode ser útil como um dos critérios de decisão. Em vez de usá-lo como condição única, porém, acho que pode ter alguma utilidade quando combinado com outras regras.

Cloudlfare Challenge / desafio PoW

O Cloudflare Challenge pode ser facilmente contornado sem sequer usar um navegador headless.
Não sei quanto ao Anubis, mas a experiência do usuário não é muito boa: ele exige cálculos no lado do cliente e causa bastante frustração ao navegar entre páginas.
Em certo sentido, pode funcionar como proteção combinada com um JS Challenge. De fato, nos últimos tempos, cada vez mais fóruns de vazamentos estão implementando seu próprio PoW Challenge. Ainda assim, é questionável onde usar um PoW Challenge e, sobretudo, se faz sentido proteger contra DoS nessa camada tão próxima da aplicação. Se for implementado apenas em situações bem específicas, talvez seja possível criar uma proteção no front-end que preserve ao máximo a experiência do usuário.

Paywall

Há poucos serviços que precisam de paywall, então vou pular esse assunto.

Cache HTTP

Fiquei um pouco na dúvida se deveria incluir este item neste artigo, mas incluí.
O cache em CDN é útil para reduzir o tráfego que chega à origem, por exemplo com GET, mas minha impressão é que praticamente todo mundo já o implementa.
Em vez de pensar nele como proteção, acho melhor usá-lo para melhorar a experiência do usuário e, como medida contra floods quando são retornados erros, como uma melhoria de desempenho que não afete a aplicação.

Limitação de taxa

As próprias key variam bastante de acordo com o serviço, então é melhor conferir as regras de implementação com atenção. No caso do Nginx, é possível limitar com base no tráfego total, por URI, por IP ou até combinar vários critérios; portanto, acho que é útil do ponto de vista da proteção contra DoS.

Então, o que fazer?

Acho que só resta agir em várias camadas e combinar diferentes condições.
O que estou considerando no momento é incluir uma lista de permissões para três provedores de nuvem confiáveis, por número de AS, e para os rastreadores de redes sociais de cada empresa, e tratar os demais com um pouco mais de rigor.
Alguns padrões de requisição claramente suspeitos, típicos de atacantes:

• IPs que fazem varreduras de .env etc.

• Quem se identifica como googlebot, mas obviamente não é

• Quem envia requisições impossíveis por meio de POST/PUT etc.

• Quem envia requisições absurdas a caminhos como /login ou a outros que podem criar sessões

Para esses casos, talvez seja aceitável bloquear de imediato. Para ser sincero, muitos VPS baratos são usados indevidamente, então dá vontade de bloquear todos de uma vez. Mas eu também costumo criar servidores VPN em VPS baratos e acessar sites pelo IP de saída deles, então talvez isso seja exagero — embora possa fazer sentido para alguns serviços.

Além disso, a detecção de impressão digital por dispositivos de áudio tem sido criticada ultimamente, mas acho que, na prática, pode ser útil. Portanto, bloquear quando não for possível detectar pode ser uma opção válida. Em algum momento, talvez surjam maneiras de falsificar esses sinais...
Talvez, no futuro, a impressão digital da GPU, a impressão digital de áudio e outros métodos sejam adotados em conjunto para detectar os dispositivos dos usuários.