En los servicios web públicos, básicamente no hay una defensa fundamental contra los atacantes

Hola, soy un inútil.

Últimamente los ataques han aumentado bastante, así que voy a escribir algunas ideas sin mucho orden.

No existe una defensa fundamental contra los ataques desde clientes HTTP

Para empezar, consideremos cada una de las posibles defensas.

Direcciones IP

Con direcciones IPv6 estaría bien, pero en entornos CGNAT se asignan direcciones IPv4 compartidas, por lo que también se ven afectados usuarios que no son el objetivo del ataque.
Además, rotar las IP es fácil, así que se ha vuelto habitual lanzar DDoS desde VPS baratos de EE. UU., que cuenta con una gran cantidad de IP disponibles en todo el mundo y suele usarse para ataques, o desde entornos cloud chinos, preparando miles de direcciones IP. Incluso si se bloquea por número de sistema autónomo (AS Number), si el servicio opera en China, bloquear las IP de los servicios cloud chinos no es una solución fundamental y, además, los usuarios chinos salen un poco perjudicados.
En general, los entornos cloud de China se usan muy a menudo de forma abusiva desde otros países, así que no creo que deban bloquearse indiscriminadamente.

En principio, mi opinión es que, si un servicio forma parte de la World Wide Web y hay aunque sea una persona que disfruta de él, no quiero bloquearlo indiscriminadamente.
Yo también veo vídeos en BiliBili de vez en cuando, y también uso servicios estadounidenses.

User-Agent

En general, no es una opción viable; considero que evaluar los encabezados de las solicitudes como método de restricción de acceso es casi inútil, así que no hay mucho que decir.
Como se puede falsificar sin límite, no se puede bloquear basándose únicamente en una evaluación simple del UA.
Por ejemplo, se podría bloquear por completo a quien se identifique como googlebot en el UA si el host de su resolución DNS inversa no es *.googlebot.com o *.google.com, como hago ahora en este sitio. Pero habría que comprobar si se implementa por cuenta propia o si el CDN tiene algo parecido. Además, aunque Google lo indique oficialmente, también hay algunos bots legítimos que Google envía desde hosts distintos a esos en la resolución inversa, así que no se puede confiar por completo en este único criterio.

Por cierto, incluso a este sitio tan cutre han llegado estos que se hacen pasar por Googlebot:
Informe de fail2ban - fake-googlebot

Bloqueo por país

Puede servir como medida temporal ante un ataque, pero no tiene sentido como solución permanente, por la misma razón que el bloqueo por dirección IP, así que no lo repetiré.
Sin embargo, puede resultar útil si el servicio está destinado únicamente al mercado nacional.

Huella TLS

También es fácil falsificar la huella TLS.
La razón es que basta con integrar en el cliente HTTP una biblioteca criptográfica del mismo tipo que la que utiliza el navegador para poder falsificar la huella del navegador.
No diría que no tenga ningún efecto, pero, por ejemplo, si un bot legítimo que usa la misma biblioteca criptográfica envía una solicitud, se bloqueará por error.
Como hay un alto riesgo de que coincida con muchos clientes HTTP, no se puede evaluar de forma simple.
Por lo tanto, puede usarse como uno de los criterios de evaluación; en lugar de utilizarlo como única condición, creo que puede ser útil combinarlo con otras reglas.

Cloudflare Challenge / desafío PoW

El Cloudflare Challenge se puede evadir fácilmente sin usar siquiera un navegador headless.
No sé qué tal funciona Anubis, pero la experiencia de usuario no es muy buena, ya que exige realizar cálculos en el cliente y hace que navegar entre páginas resulte bastante frustrante.
En cierto sentido, sí puede ofrecer protección combinada con un JS Challenge. De hecho, últimamente cada vez más foros de filtraciones implementan sus propios PoW Challenge. Por eso, habría que limitar bastante los casos de uso y, en primer lugar, preguntarse si tiene sentido protegerse contra DoS con un PoW Challenge, tan cercano a la capa de aplicación. Si se implementa solo en contextos muy concretos, quizá se pueda crear una protección frontal relativamente eficaz sin perjudicar demasiado la experiencia de usuario.

Muro de pago

Lo omito, porque son pocos los servicios que quieren implementar un muro de pago.

Caché HTTP

Dudé un poco si incluir este tema en el artículo, pero al final lo hice.
Si se habla de la posibilidad de llegar hasta el origen, la caché de CDN puede ser útil para solicitudes como GET, pero me da la impresión de que hoy en día ya la tiene implementada todo el mundo.
Más que considerarla una medida de protección, creo que conviene usarla para mejorar la experiencia de usuario y, también, para mitigar las avalanchas de solicitudes cuando se devuelve un error: como mejora del rendimiento que no afecta a la aplicación.

Límite de solicitudes

La propia key varía bastante según el servicio, así que parece recomendable revisar bien las reglas de implementación. Si hablamos de Nginx, se puede configurar para todo el tráfico, por URI, por IP o con una combinación de criterios, así que creo que resulta útil para protegerse contra DoS.

Entonces, ¿qué hacer?

Creo que no queda otra que actuar en varias capas y combinar distintos criterios.
Por ahora, estoy pensando en incluir una lista de permitidos para tres proveedores cloud fiables, por número de AS, y para los rastreadores de las redes sociales de cada empresa, y aplicar medidas algo más estrictas al resto.
Algunos patrones de solicitudes que son claramente sospechosos y típicos de los atacantes son:

• Direcciones IP que han escaneado .env, etc.

• Quienes se hacen pasar por googlebot y son claramente falsos.

• Quienes envían solicitudes imposibles mediante POST/PUT, etc.

• Quienes envían solicitudes disparatadas a rutas como /login o a otras que permiten crear sesiones.

En casos así, ¿no estaría bien bloquearlos directamente? La verdad es que se abusa muchísimo de los VPS baratos, así que también me dan ganas de bloquearlos todos de una vez. Pero yo también tengo un servidor VPN en un VPS barato y suelo visitar sitios desde su IP de salida, así que quizá sería pasarse; aunque, dependiendo del servicio, puede que esté bien.

Además, últimamente se ha criticado la huella digital basada en la detección de dispositivos de audio, pero creo que en realidad puede ser útil, así que bloquear a quienes no se puedan detectar me parece bastante razonable. Aunque tarde o temprano se encontrarán formas de falsificarla...
Quizá en el futuro se adopte la detección de dispositivos de los usuarios mediante una combinación de huellas GPU, huellas de audio, etc.