Merci. C’est DO, mais je vais y retourner et travailler davantage sur la configuration SSL. Ce n’est pas Full-strict mais Full, ce qui, je pense, interagit avec letsencrypt.
J’ai activé la mitigation Bot et Ai-Bot + un bloc de serveur géographique très spécifique
Oui, c’est étrange. Certains de mes sites utilisent « full », d’autres « full strict ». Ce qui est assez bizarre car ils fonctionnent tous sur le même serveur web, lol. Lorsque vous activez CF, vérifiez toutes les quelques heures, essayez un VPN pour contourner le cache DNS de votre FAI, etc. Je pense que l’un de mes sites n’utilise que « strict SSL only origin pull » et donne des erreurs sinon, lol. Si j’obtiens une erreur SSL, je la change simplement pour une qui fonctionne et je la laisse comme ça. Sur environ 30 sites web, si j’ai appliqué CF à 100 % d’entre eux, j’ai dû ajuster ce paramètre un jour ou deux plus tard.
Je n’ai rencontré aucune erreur SSL en naviguant et cela en espérant que cela fonctionne sur un VPN.
Je viens de vérifier Qualys et j’ai obtenu B 4 fois.
L’IP n’était pas protégée pendant tout ce temps. Cela dit, une fois que vous placez CF au milieu, il ne peut plus y avoir de frappes directes sur l’IP, est-ce que j’ai raison ?
En quelque sorte. Ils ne peuvent pas attaquer directement le site ou la base de données. Mais l’historique DNS est public. Donc, ils pourraient toujours faire un DDoS sur l’IP. Habituellement, je trouve que les DDoS sur des IP spécifiques sont rares s’ils ne savent pas ce qu’elles hébergent. C’est une perte de temps pour leur bande passante DDoS car ils ne peuvent voir aucun résultat sur ce qu’ils affectent.
J’ai également remarqué une augmentation problématique qui ne semble pas ralentir. C’est clairement inorganique. Des conseils avant que cela ne devienne un problème ?
Ouah. Le dernier graphique de votre tableau de bord ressemble remarquablement au mien. Peut-être le même calendrier aussi.
Deux phases également.
Première hausse qui se maintient pendant plusieurs jours, ce qui semble être une augmentation agréable du trafic, puis suivie par une montée en puissance de la phase deux.
Quels sont les principaux emplacements géographiques du trafic si vous pouvez le voir ?
Huawei a commencé à investir à Singapour à partir de 2019 en tant que centre d’IA.
Le même ASN Huawei de Singapour est entré avec le trafic du Mexique et de Hong Kong.
Comment cela fonctionne-t-il ? Usurpation de localisation ?
Jetez également un coup d’œil à vos colonnes « autres » séparément.
Même si vous n’êtes pas sous attaque DDoS. J’ai trouvé ce guide publié sur le forum communautaire (discourse) de Cloudflare utile en tant que points de focalisation et d’action possibles à examiner.
https://community.cloudflare.com/t/mitigating-an-http-ddos-attack-manually-with-cloudflare/302366
Lorsque le trafic a atteint son pic, le taux de rebond a dépassé les 80 %, alors qu’il se situe généralement entre 20 et 25 % en période de trafic normal.
Bizarrement, je constate une autre hausse à près de 80 % de taux de rebond sur le trafic d’une journée, mais il n’y a pas de pic. Les niveaux de trafic semblent normaux, c’est-à-dire avant le pic.
Pendant le pic, le temps d'engagement moyen a chuté de façon spectaculaire, et il y a aussi une baisse cette fois-ci. Je ne regarde normalement pas cette métrique, mais je l’ai fait à cause du graphique que vous avez publié. Je pense que cela ou le taux de rebond sont de bonnes alertes indiquant que quelque chose ne va pas du tout avec la qualité et le type de trafic.
Ma solution était de géobloquer tous les pays non lusophones, mais je reçois toujours un trafic élevé de mon pays, des États-Unis et de l’Allemagne. Il me semble que le Brésil est la principale source de ce type d’attaque, donc ma tentative a échoué. J’ai 20 membres actifs mais 2 millions de requêtes par mois en termes de débit. Incroyable, mon instance continue de recevoir du trafic du Fediverso même lorsque le plugin était désactivé. Je suis fatigué et je n’ai aucune idée de comment résoudre cela.
En termes d’atténuation Cloudflare, ce qui fonctionne pour moi :
Règles WAF 1)
Défi JavaScript appliqué à l’ASN / ASN = 136907
(emplacements par ordre de trafic le plus élevé)
Que quelqu’un comme @piffy vérifie si le même ASN vous touche également. Cela ressemblait à du trafic réel dans Google Analytics, cela a fait grimper le taux de rebond à plus de 80 % et l’engagement utilisateur s’est effondré. Cela perturbera votre RPM / CPC AdSense, d’après ce que je peux voir.
Règle WAF 2)
Défi JavaScript géographique appliqué (par ordre de trafic le plus élevé)
Il semblait y avoir une nouvelle augmentation des requêtes servies par Cloudflare et, encore une fois, les mêmes régions géographiques sont en tête, j’ai donc appliqué un défi JavaScript géographique à ces 3 principaux coupables.
Une intervention dans le but principal de restaurer la santé des métriques d’analyse / d’engagement utilisateur, ce trafic ne met plus de pression sur le serveur puisque CF gère une grande partie via la mise en cache et la gestion des attaques de bots, mais globalement les métriques sont vraiment faussées. Il s’agit d’un trafic hostile.
Je mettrai à jour si je constate une amélioration des métriques d’analyse / AdSense, etc.
Je l’ai fait et maintenant j’ai de nouveau bloqué tous les pays avec d’autres règles activées pendant un certain temps, le défi géré était suffisant et j’ai l’impression que les sources d’attaque ralentissent
Maintenant, mon taux d’engagement a augmenté de 131 % et le taux de rejet a baissé de 16 %. Je suppose que le Playstore a une impulsion, donc pendant un certain temps, j’ai besoin d’attendre quelques semaines pour voir si cette croissance est due à des bots ou à un trafic légitime.
Règle WAF n°2 a écrasé le trafic supplémentaire à l’aide du défi JS appliqué par Geo
Avant, le ratio était d’environ - 4:1
Cloudflare : Serveur d’origine
Maintenant, il est plus proche d’un ratio de 1:1
Ces régions envoyaient encore une tonne de trafic.
L’analytique crachait des alertes d’anomalies et les métriques dans l’analytique étaient toujours dans tous les sens.
Adsense était vraiment dévasté, le RPM par page était presque à 0,00c avec la montée en puissance. Je suppose qu’Adsense détectait cela comme un trafic suspect et a arrêté le comptage.
Tableau de bord
Voici à quoi ressemblaient les vues du tableau de bord, les 5 derniers jours sont plus bas car les mesures de CF ont été déployées à partir de ce moment-là. Sinon, il n’y avait aucune raison pour que ce trafic cesse d’augmenter.
Pour perspective, les vues de page Autres (rouge) du jour le plus élevé représentaient près de 10 fois le volume des vues de page Anon (vert). Laissez cela vous imprégner. 
Croisons les doigts pour que cela s’équilibre dans les 2/3 prochains jours.
Le JS non géré n’a pas le même effet que le JS géré. J’ai fait presque la même chose en appliquant le blocage des liens directs (hotlink blocking) aux médias et aux bibliothèques comme le CSS et le JS. Cela fonctionne uniquement via le référent (l’ouverture directe depuis un onglet est bloquée), ce qui m’a aidé à réduire l’utilisation de la bande passante et du CPU.
Je laisserai le JS Challenge en place pendant un certain temps car jusqu’à présent le TCR (Taux de Résolution des Défis) = 0%
J’expérimenterai avec Managed une fois que plus de trafic sera passé et/ou que le TCR commencera à fléchir.
Actuellement, le ratio de service CF:OS ressemble à un ratio 1:1 encore plus serré.
Le trafic atténué a pris le dessus et a explosé.
Ce que je me demande, c’est pourquoi les attaques continuent si elles sont bloquées par le JS après une certaine période (pas très sophistiquées après tout ?) et y aura-t-il une tentative d’entrer via d’autres ASN et emplacements géographiques ?
Si cela se produit, alors j’essaierai Managed sur tout nouveau vecteur d’attaque.
Étant donné que le Défi JS a le même objectif mais une efficacité inférieure à celle du ‘Défi géré’, il est peut-être obsolète car cette option ne m’affiche pas de captcha, elle me rejette simplement comme un trafic légitime, à l’instar de ce que fait le ‘Défi géré’.
J’ai trouvé ce sujet sur meta qui, je pense, présente un grand intérêt et serait probablement mieux traité comme un sujet à part entière Cloudflare Security WAF (Web Application Firewall) + Discourse?
Une autre ressource qui pourrait être utile - https://radar.cloudflare.com/
J’ai dit que je mettrais à jour le sujet, voici donc la mise à jour.
Dans l’ensemble, l’atténuation Cloudflare sur le niveau gratuit a très bien fonctionné comme solution pour l’instant, c’est-à-dire à court terme immédiat.
D’une certaine manière, j’aurais aimé savoir que Cloudflare pouvait être utilisé avec Discourse, mais je l’ai en quelque sorte manqué.
Les diverses atténuations utilisant Cloudflare ont entraîné un arrêt quasi immédiat du trafic fantaisiste, provenant des emplacements de trafic de Singapour, Hong Kong et du Mexique (probablement usurpé).
Hier et aujourd’hui, nous avons constaté une tendance où les mêmes sources de trafic semblent avoir cessé d’essayer car le volume a chuté de façon spectaculaire. C’est à peu près le temps qu’il a fallu pour qu’il abandonne peut-être.
Cependant, il est encore trop tôt.
Je peux également identifier plus facilement d’autres attaques à rafales courtes / trafic de bots.
Je pense que Cloudflare atténue finalement ces attaques après environ 30 à 60 minutes, ces pics servis par Cloudflare sont l’endroit où il faut se concentrer, et cela permet de distinguer beaucoup plus facilement les ASN sources ou les emplacements géographiques et d’ajouter à la liste de blocage ou à toute règle WAF.
Le lien radar https://radar.cloudflare.com/bots/ était vraiment utile pour évaluer la qualité d’un ASN, j’ai repéré des essaims de serveurs WOW, je suppose que c’est un serveur World Of Warcraft ? 
Celui-là revenait sans cesse dans les pics.
J’ai remarqué que le trafic revenait à des niveaux plus habituels, semblant également plus régulier et rythmé.
Les métriques AdSense se sont améliorées, revenant presque à la normale ou se rétablissant (c’est-à-dire qu’un RPM faible est mieux que pas de RPM du tout !) 
C’était probablement la première fois que je voyais le trafic mettre le serveur sous une telle pression que le service peinait, dans ce cas, et en dehors d’autres atténuations comme le changement d’IP du serveur, dans l’ensemble, en tant que solution rapide et solution de gestion sur le moment, Cloudflare a été formidable, surtout quand on n’a pas le temps de bricoler ou les compétences pour toucher à nginx etc. sous une sorte d’attaques croissantes, et a permis à un droplet de spécifications minimales de fonctionner presque au ralenti, lui donnant une marge de manœuvre au-delà de ses spécifications.
