Grazie. È DO, ma tornerò a lavorare di più sulla configurazione SSL. Non è Full-strict ma Full, il che credo interagisca con letsencrypt. Ho abilitato la mitigazione Bot e Ai-Bot + un blocco geo-server molto specifico
Sì, è strano. Alcuni dei miei siti usano ‘full’, altri ‘full strict’. Il che è piuttosto strano dato che girano tutti sullo stesso webserver lol. Quando attivi CF, controlla ogni poche ore, prova una VPN così bypassi la cache DNS del tuo ISP, ecc. Penso che uno dei miei siti usi solo ‘strict SSL only origin pull’ e altrimenti dia errori lol. Se ottengo un errore SSL, lo cambio semplicemente con uno che funziona e lo lascio lì. Su circa 30 siti web, dopo aver applicato CF al 100% di essi, ho dovuto regolare quell’impostazione un giorno o giù di lì dopo.
Non ho riscontrato errori SSL durante la navigazione e questo anche navigando con una VPN.
Ho appena controllato Qualys e ho ottenuto B per 4 volte.
L’IP non è stato protetto per tutto questo tempo. Detto questo, una volta che si inserisce CF in mezzo, non ci possono più essere hit diretti sull’IP, ho capito bene?
In un certo senso. Non possono colpire direttamente il sito o il database. Ma la cronologia DNS è pubblica. Quindi potrebbero comunque DDoS l’IP. Di solito trovo rari i DDoS su IP specifici se non sanno cosa ospitano. È uno spreco di tempo per la loro larghezza di banda DDoS poiché non possono vedere alcun risultato di ciò che stanno influenzando.
1 Mi Piace
Ho anche notato un aumento problematico che non sembra rallentare. È chiaramente inorganico. Qualche consiglio prima che diventi un problema?
2 Mi Piace
Wow. Il grafico della tua ultima dashboard assomiglia incredibilmente al mio. Forse anche con la stessa tempistica.
Due fasi anche.
Primo rialzo che si sostiene per un certo numero di giorni, quello che sembra un piacevole aumento del traffico e poi seguito da un’impennata di fase due.
Quali sono le principali località geografiche del traffico, se puoi vederlo?
1 Mi Piace
Huawei ha iniziato a investire a Singapore a partire dal 2019 come hub per l’IA. Lo stesso ASN Huawei di Singapore è stato associato al traffico del Messico e di Hong Kong. Come funziona? Spoofing della posizione?
1 Mi Piace
Dai un’occhiata anche alle tue colonne “altre” da sole.
Anche se non sei sotto attacco DDoS. Ho trovato utile questa guida pubblicata sul forum della community (discourse) di Cloudflare come focus e possibili punti d’azione su cui lavorare.
https://community.cloudflare.com/t/mitigating-an-http-ddos-attack-manually-with-cloudflare/302366
Quando il traffico di punta ha colpito, la frequenza di rimbalzo è balzata oltre l’80%; tipicamente, con traffico normale, questa si attesta nella fascia bassa-media del 20%.
Stranamente, sto notando un altro balzo a quasi l’80% di frequenza di rimbalzo sul traffico di un solo giorno, ma non c’è alcun picco. I livelli di traffico sembrano normali, ovvero pre-picco.
Durante il picco, il tempo medio di coinvolgimento è calato drasticamente e c’è un calo anche questa volta. Normalmente non guardo quella metrica, ma l’ho fatto a causa del grafico che hai pubblicato. Penso che questa o la frequenza di rimbalzo siano buoni segnali d’allarme che qualcosa non va con la qualità e il tipo di traffico.
1 Mi Piace
La mia soluzione è stata geobloccare tutti i paesi non di lingua portoghese, ma continuo a ricevere traffico elevato dal mio paese, dagli Stati Uniti e dalla Germania. Sembra proprio che il Brasile sia la fonte principale per questo tipo di attacco, quindi il mio tentativo è fallito. Ho 20 membri attivi ma 2 milioni di richieste al mese. Incredibile, la mia istanza continua a ricevere traffico dal Fediverso anche quando il plugin è stato disabilitato. Sono stanco e non ho idea di come risolverlo.
1 Mi Piace
Per quanto riguarda la mitigazione di Cloudflare, ecco cosa sta funzionando per me:
Regole WAF 1)
ASN - Sfida JS applicata / ASN = 136907
(località in ordine di maggior traffico)
- Singapore
- Hong Kong
- Messico
Chiunque, come @piffy, verifichi se lo stesso ASN sta colpendo anche voi. Questo sembrava traffico reale in Google Analytics, ha fatto schizzare la frequenza di rimbalzo a oltre l’80% e il coinvolgimento degli utenti è crollato. A quanto ne so, rovinerà il vostro RPM / CPC di AdSense.
Regola WAF 2)
Sfida JS geografica applicata (in ordine di maggior traffico)
- Singapore
- Hong Kong
- Messico
Sembra esserci stato un nuovo aumento delle richieste a Cloudflare e di nuovo le stesse regioni geografiche sono in cima, quindi ora ho applicato una Sfida JS geografica a questi 3 principali
1 Mi Piace
L’ho fatto e ora ho bloccato di nuovo tutti i paesi con altre regole abilitate per un po’, la sfida gestita è stata sufficiente e sembra che le sorgenti di attacco stiano rallentando
Ora il mio coinvolgimento è aumentato del 131% e il rifiuto è diminuito del 16%, la mia ipotesi è che Play Store stia spingendo, quindi per un po’ dovrò aspettare un paio di settimane per vedere se questa crescita è dovuta a bot o a traffico legittimo.
1 Mi Piace
Regola WAF n. 2 ha bloccato il traffico extra utilizzando la sfida JS applicata da Geo
Prima il rapporto era approssimativamente - 4:1
Cloudflare: OriginServer
Ora è più vicino a un servizio 1:1
Queste regioni stavano ancora inviando una tonnellata di traffico.
Analytics stava generando avvisi di anomalie e le metriche in analytics erano ancora caotiche.
Adsense era davvero rovinato, il RPM della pagina era quasi a 0,00c con l’impennata. Suppongo che Adsense stesse rilevando questo traffico come sospetto e avesse interrotto la misurazione.
Puoi vedere l’aumento pre-impennata (blu), e anche allora il RPM è crollato, ma l’impennata delle visualizzazioni di pagina (blu) ha completamente appiattito il RPM della pagina. I precedenti 30+ giorni con visualizzazioni di pagina e pattern molto stabili.
Dashboard
Ecco come apparivano le visualizzazioni della dashboard, gli ultimi 5 giorni sono più bassi perché le mitigazioni CF sono state distribuite da qui in poi. Altrimenti, non c’è motivo per cui questo traffico non si sarebbe fermato ad aumentare.
Per prospettiva, le visualizzazioni di pagina Altro (rosso) nel giorno più alto erano quasi 10 volte il volume delle visualizzazioni di pagina Anon (verde). Lascia che questo ti faccia riflettere. 
Speriamo che la situazione si equilibri nei prossimi 2/3 giorni.
1 Mi Piace
La sfida con JS è che non ha lo stesso effetto di quando è gestito. Ho fatto quasi lo stesso applicando il blocco hotlink a media e librerie come CSS e JS; funziona solo tramite referer (l’apertura di accesso diretto da una scheda è bloccata). Questo mi aiuta a ridurre l’uso di larghezza di banda e CPU.
1 Mi Piace
Lascerò la JS Challenge attiva per un po’ di tempo, dato che finora il CSR (Challenge Solved Rate) = 0%. Sperimenterò con Managed quando ci sarà più traffico e/o il CSR inizierà a diminuire. Al momento, il rapporto di servizio CF:OS sembra un rapporto 1:1 ancora più stretto. La mitigazione ha preso il sopravvento ed è aumentata a dismisura. Quello che mi chiedo è perché gli attacchi continuano se vengono bloccati dal JS dopo un certo periodo (dopotutto non molto sofisticati?) e ci sarà un tentativo di entrare tramite altri ASN e posizioni geografiche? Se ciò accade, allora proverò Managed su qualsiasi nuovo vettore di attacco.
1 Mi Piace
Poiché ‘JS Challange’ ha lo stesso obiettivo ma un’efficienza peggiore rispetto a ‘Manage Challange’, forse è deprecato, dato che questa opzione non mi mostra un captcha, ma mi scarta semplicemente come traffico legittimo, proprio come fa ‘managed’.
Ho trovato questo argomento su meta che penso sia di grande interesse e probabilmente servirebbe meglio come argomento a sé stante Cloudflare Security WAF (Web Application Firewall) + Discourse?
Un’altra risorsa che potrebbe essere utile: https://radar.cloudflare.com/
Ho detto che avrei aggiornato l’argomento, quindi ecco l’aggiornamento.
Nel complesso, la mitigazione di Cloudflare sul piano gratuito ha funzionato molto bene come soluzione per ora, ovvero per l’immediato breve termine.
Per certi versi, vorrei aver saputo che Cloudflare poteva essere utilizzato con Discourse, ma in qualche modo me lo sono perso.
Le varie mitigazioni che utilizzano Cloudflare hanno causato un arresto quasi immediato del traffico spurio, dalle località di Singapore, Hong Kong e Messico (probabilmente falsificate).
Ieri e oggi si è osservata una tendenza in cui le stesse fonti di traffico sembrano aver smesso di provarci, poiché il volume è diminuito drasticamente. Questo è circa il tempo necessario affinché si arrenda.
Tuttavia, è ancora presto.
Posso anche identificare più facilmente altri attacchi a brevi raffiche / traffico bot.
Penso che Cloudflare alla fine mitighi questi attacchi dopo circa 30-60 minuti, questi picchi serviti da Cloudflare sono il posto su cui concentrarsi, e rende molto più facile individuare ASN o posizioni geografiche di origine e aggiungerli alla lista di blocco o a qualsiasi regola WAF.
Il link radar https://radar.cloudflare.com/bots/ è stato davvero utile per valutare la qualità di un ASN, ho individuato alcuni sciami di server WOW che presumo siano server di World Of Warcraft? 
Quello continuava a comparire nei picchi.
Ho notato che il traffico è tornato a livelli più usuali, appare anche più costante e con un ritmo uniforme.
Le metriche di AdSense sono migliorate quasi tornando alla normalità o almeno si stanno riprendendo (ovvero, un RPM basso è meglio di nessun RPM!) 
Questa è stata probabilmente la prima volta che ho visto il traffico mettere il server sotto così tanta pressione da far lottare il servizio, in questo caso, e oltre ad altre mitigazioni come cambiare l’IP del server, nel complesso come soluzione rapida e soluzione di gestione sul momento Cloudflare è stato eccezionale, specialmente quando non si ha tempo di armeggiare o le abilità per intervenire su nginx ecc. mentre si è sotto qualche tipo di attacco crescente, e ha permesso a un droplet di specifiche minime di funzionare quasi inattivo, dandogli margine oltre le sue specifiche.