Gracias. Es DO, pero volveré y trabajaré más en la configuración SSL. No es Full-strict sino Full, lo que creo que interactúa con letsencrypt. Habilité la mitigación de Bot y Ai-Bot + un bloqueo geográfico de servidor muy específico.
Sí, es raro. Algunos de mis sitios usan “full”, otros “full strict”. Lo cual es bastante extraño ya que todos se ejecutan en el mismo servidor web, ¡jaja! Al activar CF, revisa cada pocas horas, prueba una VPN para evitar la caché DNS de tu ISP, etc. Creo que uno de mis sitios solo usa “strict SSL” y “origin pull” y da errores de lo contrario, ¡jaja! Si obtengo un error SSL, simplemente lo cambio a uno que funcione y lo dejo así. De unos 30 sitios web, si hubiera hecho CF en el 100% de ellos, tuve que ajustar esa configuración uno o dos días después.
No me he encontrado con ningún error SSL navegando e incluso entrando en una VPN.
Acabo de revisar Qualys y obtuve B 4 veces.
La IP no estuvo protegida todo este tiempo. Dicho esto, una vez que colocas CF en el medio, no puede haber más ataques directos a la IP, ¿tengo razón?
Más o menos. No pueden atacar directamente el sitio o la base de datos. Pero el historial de DNS es público. Así que aún podrían hacer un DDoS a la IP. Normalmente encuentro que los ataques DDoS a IPs específicas son raros si no saben qué alojan. Es una pérdida de tiempo para su ancho de banda de DDoS, ya que no pueden ver ningún resultado de lo que están afectando.
También he notado un aumento problemático que no parece estar disminuyendo. Es claramente inorgánico. ¿Algún consejo antes de que esto se convierta en un problema?
Vaya. El gráfico de tu último panel se parece mucho al mío. Quizás también al mismo tiempo.
Dos fases también.
El primer repunte que se mantiene durante varios días, lo que parece un aumento agradable en el tráfico y luego seguido por el aumento de la fase dos.
¿Cuáles son las ubicaciones geográficas principales del tráfico si puedes verlo?
Huawei comenzó a invertir en Singapur a partir de 2019 como un centro de IA. El mismo ASN de Huawei en Singapur estuvo asociado con el tráfico de México y Hong Kong. ¿Cómo funciona eso? ¿Suplantación de ubicación?
Eche también un vistazo a sus otras columnas por sí solas.
Incluso si no estás bajo ataque DDoS. Encontré útil esta guía publicada en el foro de la comunidad (discourse) de Cloudflare como puntos de enfoque y posibles acciones a seguir.
https://community.cloudflare.com/t/mitigating-an-http-ddos-attack-manually-with-cloudflare/302366
Cuando el tráfico pico alcanzó su máximo, la tasa de rebote saltó por encima del 80%; típicamente, esta se encuentra en el rango bajo a medio del 20% con tráfico normal.
Curiosamente, estoy viendo otro salto a casi el 80% de tasa de rebote en el tráfico de un día, pero no hay un aumento repentino. Los niveles de tráfico parecen normales, es decir, previos al aumento.
Durante el aumento, el tiempo medio de interacción cayó drásticamente y también hay una caída esta vez. Normalmente no miro esa métrica, pero lo hice debido al gráfico que publicaste. Creo que esto o la tasa de rebote son buenas alertas de que algo anda muy mal con la calidad y el tipo de tráfico.
Mi solución fue geobloquear todos los países no lusófonos, pero sigo recibiendo mucho tráfico de mi país, EE. UU. y Alemania. Parece que Brasil es la principal fuente de este tipo de ataque, así que mi intento falló. Tengo 20 miembros activos, pero recibo 2 millones de solicitudes al mes. Increíble, mi instancia sigue recibiendo tráfico de Fediverso incluso cuando el plugin estaba deshabilitado. Estoy cansado y no tengo idea de cómo resolverlo.
En términos de mitigación de Cloudflare, lo que me está funcionando es:
Reglas WAF 1)
ASN - Desafío JS Aplicado / ASN = 136907
(ubicaciones en orden de mayor tráfico)
- Singapur
- Hong Kong
- México
Cualquiera como @piffy, verifique si el mismo ASN también los está afectando. Esto parecía tráfico real en Google Analytics, disparó la tasa de rebote a más del 80% y el engagement del usuario se desplomó. Por lo que puedo ver, arruinará su RPM / CPC de AdSense.
Regla WAF 2)
Desafío JS Geográfico Aplicado (en orden de mayor tráfico)
- Singapur
- Hong Kong
- México
Parecía haber un nuevo repunte en las entregas de Cloudflare y, de nuevo, las mismas regiones geográficas están en la cima, así que ahora he aplicado un Desafío JS Geográfico a estos 3 principales infractores.
Una intervención con el propósito principal de restaurar la salud de las métricas de análisis / engagement del usuario; este tráfico ya no está ejerciendo presión sobre el servidor, ya que CF maneja mucho a través del almacenamiento en caché y la gestión de ataques de bots, pero en general las métricas están siendo realmente alteradas. Este es tráfico beligerante.
Actualizaré si veo mejoras en las métricas de análisis / AdSense, etc.
Lo hice y ahora he vuelto a bloquear todos los países con otras reglas habilitadas por un tiempo. El desafío gestionado fue suficiente y parece que las fuentes de ataque se ralentizaron
Ahora mi tasa de interacción ha crecido un 131% y el rechazo ha bajado un 16%. Mi suposición es que Play Store impulsa, así que por un tiempo necesito esperar un par de semanas para ver si este crecimiento son bots o tráfico legítimo.
Regla No. 2 de WAF ha aplastado el tráfico adicional utilizando el Desafío JS aplicado por Geo.
Antes, la proporción era de aproximadamente 4:1
Cloudflare:Servidor de origen
Ahora está más cerca de una distribución 1:1
Estas regiones todavía enviaban una tonelada de tráfico.
Analytics estaba lanzando alertas de anomalías y las métricas en analytics seguían desordenadas.
Adsense estaba realmente destrozado, el RPM de página estaba casi en .00c con el aumento. Supongo que Adsense estaba detectando esto como tráfico sospechoso y detuvo la medición.
Puedes ver el aumento previo al pico (azul), e incluso entonces el RPM colapsó, pero el aumento de vistas de página (azul) aplastó totalmente el RPM de página. Los 30 días anteriores tuvieron vistas de página y patrones muy estables.
Panel
Así es como se veían las vistas del panel, los últimos 5 días son más bajos porque se implementaron mitigaciones de CF a partir de aquí. Si no, no hay razón para que este tráfico dejara de aumentar.
Como perspectiva, las vistas de página de Otro (rojo) en el día de mayor volumen fueron casi 10 veces el volumen de las vistas de página de Anónimo (verde). Piénsalo. ![]()
Crucemos los dedos para que esto se equilibre en los próximos 2/3 días.
Challenge JS no tiene el mismo efecto que las soluciones gestionadas. Hice casi lo mismo aplicando el bloqueo de hotlink a medios y librerías como CSS y JS; simplemente funciona desde el referente (abrir acceso directo desde una pestaña = bloqueado), lo que me ayuda a reducir el uso de ancho de banda y CPU.
Dejaré el JS Challenge en su lugar por algún tiempo ya que hasta ahora la CSR (Tasa de Resolución de Desafíos) = 0%
Experimentaré con Managed después de que haya más tráfico y/o la CSR empiece a flaquear.
Ahora mismo, la relación de servicio CF:OS parece una proporción aún más ajustada de 1:1.
Mitigado ha tomado el lugar y se ha disparado.
Lo que me pregunto es por qué continúan los ataques si están siendo bloqueados por el JS después de un período x (¿no son muy sofisticados después de todo?) y ¿habrá un intento de entrar a través de otros ASN y ubicaciones geográficas?
Si esto sucede, entonces probaré Managed en cualquier nuevo vector de ataque.
Debido a que JS Challenge tiene el mismo objetivo pero la peor eficiencia que ‘Manage Challenge’, quizás esté obsoleto porque esta opción no me muestra un captcha, simplemente me descarta como tráfico legítimo como lo hace ‘managed’.
Encontré este tema en meta que creo que es de gran interés y probablemente se sirva mejor como un tema propio Cloudflare Security WAF (Web Application Firewall) + Discourse?
Otro recurso que podría ser útil: https://radar.cloudflare.com/
Dije que actualizaría el tema, así que aquí está la actualización.
En general, la mitigación de Cloudflare en el nivel gratuito ha funcionado muy bien como solución por ahora, es decir, a corto plazo.
En cierto sentido, desearía haber sabido que Cloudflare se podía usar con Discourse, pero de alguna manera me lo perdí.
Las diversas mitigaciones que utilizan Cloudflare provocaron una detención casi inmediata del tráfico espurio, de las ubicaciones de Singapur, Hong Kong y México (probablemente falsificadas).
Ayer y hoy se observó una tendencia en la que las mismas fuentes de tráfico parecen haber dejado de intentarlo, ya que el volumen ha caído en picado. Esto es aproximadamente el tiempo que tardó en rendirse.
Sin embargo, todavía es pronto.
También puedo identificar otros ataques de ráfagas cortas / tráfico de bots más fácilmente.
Creo que Cloudflare finalmente mitiga estos ataques después de unos 30-60 minutos, estas oleadas servidas por Cloudflare son el lugar en el que centrarse, y hace que sea mucho más fácil identificar ASN de origen o ubicaciones geográficas y agregarlas a la lista de bloqueo o a cualquier regla de WAF.
El enlace del radar https://radar.cloudflare.com/bots/ fue realmente útil para evaluar la calidad de un ASN, identifiqué algunas oleadas de servidores WOW, supongo que es un servidor de World Of Warcraft. Ese apareció en oleadas.
He notado que el tráfico ha vuelto a niveles más habituales y también parece tener un ritmo más constante y uniforme.
Las métricas de Adsense han mejorado casi a la normalidad o al menos se están recuperando (es decir, un RPM bajo es mejor que ningún RPM).
Probablemente fue la primera vez que vi que el tráfico ponía al servidor bajo tanta presión que el servicio estaba luchando, en este caso, y aparte de otras mitigaciones como cambiar la IP del servidor, en general, como una solución rápida y una solución de gestión en el momento, Cloudflare ha sido genial, especialmente cuando no tienes tiempo para experimentar o las habilidades para meterte con nginx, etc. mientras sufres algún tipo de ataque creciente, y ha permitido que un droplet de especificaciones mínimas funcione casi inactivo, dándole margen más allá de sus especificaciones.








