Obrigado. É DO, mas vou voltar e trabalhar mais na configuração SSL. Não é Full-strict, mas Full, o que acho que interage com o letsencrypt. Eu ativei a mitigação de Bot e Ai-Bot + um bloqueio de servidor geográfico muito específico.
Sim, é estranho. Alguns dos meus sites usam ‘full’, outros ‘full strict’. O que é bem estranho, já que todos rodam no mesmo servidor web, haha. Ao ativar o CF, verifique a cada poucas horas, tente uma VPN para contornar o cache DNS do seu provedor de internet, etc. Acho que um dos meus sites usa apenas ‘strict SSL only origin pull’ e dá erros de outra forma, haha. Se eu recebo um erro de SSL, eu apenas mudo para um que funcione e o deixo lá. De cerca de 30 sites, se eu ativei o CF em 100% deles, tive que ajustar essa configuração um dia ou mais tarde.
Eu não encontrei nenhum erro de SSL navegando e isso que espero que esteja usando uma VPN.
Acabei de verificar o Qualys e obtive B 4 vezes.
O IP não estava protegido o tempo todo. Dito isso, uma vez que você coloca o CF no meio, não pode haver mais acessos diretos ao IP, estou certo?
Mais ou menos. Eles não conseguem atacar diretamente o site ou o banco de dados. Mas o histórico do DNS é público. Então eles ainda poderiam fazer um DDoS no IP. Geralmente acho ataques de DDoS a IPs específicos raros se eles não sabem o que está hospedado nele. É uma perda de tempo para a largura de banda de DDoS deles, pois eles não conseguem ver nenhum resultado do que estão afetando.
1 curtida
Também notei um aumento problemático que não parece estar diminuindo. É claramente inorgânico. Algum conselho antes que isso se torne um problema?
2 curtidas
Uau. O gráfico do seu último painel se parece notavelmente com o meu. Talvez o mesmo timing também.
Duas fases também.
Primeiro aumento que se sustenta por vários dias, o que parece um aumento agradável no tráfego e, em seguida, seguido por um pico na fase dois.
Quais são as principais localizações geográficas do tráfego, se você puder ver?
1 curtida
A Huawei começou a investir em Singapura a partir de 2019 como um centro de IA.
O mesmo ASN da Huawei em Singapura veio com o tráfego do México e de Hong Kong.
Como isso funciona? Falsificação de localização?
1 curtida
Dê uma olhada também nas suas outras colunas separadamente.
Mesmo que você não esteja sob ataque DDoS. Achei este guia postado no fórum da comunidade (discourse) da Cloudflare útil como foco e possíveis pontos de ação para trabalhar.
https://community.cloudflare.com/t/mitigating-an-http-ddos-attack-manually-with-cloudflare/302366
Quando o tráfego atingiu o pico, a taxa de rejeição saltou para mais de 80%; normalmente, esta fica entre 20% e 25% em tráfego normal.
Estranhamente, estou vendo outro salto para quase 80% de taxa de rejeição no tráfego de um dia, mas não há nenhum pico. Os níveis de tráfego parecem normais, ou seja, pré-pico.
Durante o pico, o tempo médio de engajamento caiu drasticamente e também há uma queda desta vez. Normalmente não olho para essa métrica, mas olhei por causa do gráfico que você postou. Acho que isso ou a taxa de rejeição são bons alertas de que algo está muito errado com a qualidade e o tipo de tráfego.
1 curtida
Minha solução foi geobloquear todos os países que não falam português, mas ainda estou recebendo muito tráfego do meu país, dos EUA e da Alemanha. Parece que o Brasil é a principal fonte desse tipo de ataque, então minha tentativa falhou. Tenho 20 membros ativos, mas 2 milhões de requisições por mês. Inacreditável, minha instância continua recebendo tráfego do Fediverso mesmo com o plugin desativado. Estou cansado e não tenho ideia de como resolver isso.
1 curtida
Em termos de mitigação do Cloudflare, o que está funcionando para mim:
Regras WAF 1)
ASN - Desafio JS Aplicado / ASN = 136907
(localizações em ordem de maior tráfego)
- Singapura
- Hong Kong
- México
Qualquer pessoa como @piffy, verifique se o mesmo ASN também está te atingindo. Isso parecia tráfego real no Google Analytics, elevou a taxa de rejeição para mais de 80% e o engajamento do usuário desabou. Pelo que pude perceber, isso vai bagunçar seu RPM / CPC do AdSense.
Regra WAF 2)
Geo Desafio JS Aplicado (em ordem de maior tráfego)
- Singapura
- Hong Kong
- México
Pareceu haver um novo aumento nas entregas do Cloudflare e, novamente, as mesmas regiões geográficas estão no topo, então agora apliquei um Geo Desafio JS a esses 3 principais infratores.
Uma intervenção com o principal propósito de restaurar a saúde das métricas de análise / engajamento do usuário, este tráfego não está mais colocando pressão no servidor, já que o CF lida com muito via cache e gerenciamento de ataques de bot, mas no geral as métricas estão sendo realmente bagunçadas. Este é um tráfego beligerante.
Atualizarei se vir melhorias nas métricas de análise / AdSense etc.
1 curtida
Consegui e agora bloqueei novamente todos os países com outras regras ativadas por um tempo, o desafio gerenciado foi o suficiente e pareço que as fontes de ataque diminuíram
Agora meu engajamento aumentou 131% e a rejeição diminuiu 16%, minha suposição é que a Play Store impulsionou, então por um tempo preciso esperar algumas semanas para ver se esse crescimento é de bots ou tráfego legítimo.
1 curtida
Regra WAF nº 2 esmagou o tráfego extra usando o Desafio JS aplicado por Geo
Antes, a proporção era de aproximadamente - 4:1
Cloudflare:Servidor de Origem
Agora está mais perto de 1:1 servindo
Essas regiões ainda estavam enviando muito tráfego.
O Analytics estava emitindo alertas de anomalia e as métricas no analytics ainda estavam confusas.
O Adsense foi realmente destruído, o RPM da página estava quase em .00c com o pico. Acho que o Adsense estava detectando isso como tráfego suspeito e removeu a medição.
Você pode ver o aumento pré-pico (azul), e mesmo assim o RPM desabou, mas o super pico de visualizações de página (azul) totalmente achatou o RPM da página. Os 30 dias anteriores tiveram visualizações de página e padrão muito estáveis.
Painel
É assim que as visualizações do painel pareciam, os últimos 5 dias são menores porque as mitigações da CF foram implantadas a partir daqui. Caso contrário, não haveria razão para esse tráfego parar de aumentar.
Para perspectiva, as visualizações de página Outras (vermelho) no dia de maior volume foram quase 10 vezes o volume das visualizações de página Anon (verde). Pense nisso. 
Dedos cruzados para que isso se equilibre nos próximos 2/3 dias.
1 curtida
O JavaScript não se comporta da mesma forma que (outros recursos) gerenciados. Eu fiz algo parecido, aplicando bloqueio de hotlink em mídias e bibliotecas como CSS e JS. Funciona apenas via referer (abrir acesso direto de uma aba = bloqueado), o que me ajuda a reduzir o uso de largura de banda e CPU.
1 curtida
Manterei o JS Challenge ativo por algum tempo, já que até agora a CSR (Taxa de Resolução de Desafios) = 0%
Experimentarei com o Managed depois que mais tráfego for processado e/ou o CSR começar a vacilar.
No momento, a proporção de atendimento CF:OS está parecendo uma proporção ainda mais apertada de 1:1.
A mitigação assumiu o controle e disparou.
O que me pergunto é por que os ataques continuam se estão sendo bloqueados pelo JS após um período x (afinal, não são muito sofisticados?) e haverá uma tentativa de entrada por outros ASNs e localizações geográficas?
Se isso acontecer, então tentarei o Managed em quaisquer novos vetores de ataque.
1 curtida
Porque o JS Challange tem o mesmo objetivo, mas a pior eficiência que o ‘Manage Challange’, talvez esteja obsoleto, porque esta opção não me mostra um capatcha, apenas me descarta como tráfego legítimo, como o ‘managed’ faz.
Encontrei este tópico no meta que acho de grande interesse e que provavelmente seria melhor servido como um tópico próprio Cloudflare Security WAF (Web Application Firewall) + Discourse?
Outro recurso que pode ser útil - https://radar.cloudflare.com/
Eu disse que atualizaria o tópico, então aqui está a atualização.
No geral, a mitigação da Cloudflare no plano gratuito funcionou muito bem como uma solução por enquanto, ou seja, no curto prazo imediato.
De certa forma, gostaria de ter sabido que a Cloudflare podia ser usada com o Discourse, mas de alguma forma perdi isso.
As várias mitigações usando a Cloudflare instigaram uma parada quase imediata no tráfego espúrio, das localizações de Singapura, Hong Kong e México (provavelmente falsificadas).
Ontem e hoje viram uma tendência onde as mesmas fontes de tráfego parecem ter parado de tentar, pois o volume caiu drasticamente. É mais ou menos o tempo que levou para talvez desistir.
No entanto, ainda é cedo.
Também consigo identificar outros ataques de curta duração / tráfego de bots com mais facilidade.
Acho que a Cloudflare eventualmente mitiga esses ataques após cerca de 30-60 minutos, esses picos servidos pela Cloudflare são o lugar para focar, e torna muito mais fácil identificar ASNs de origem ou localizações geográficas e adicionar à lista de bloqueio ou qualquer regra WAF.
O link do radar https://radar.cloudflare.com/bots/ foi realmente útil para avaliar a qualidade de um ASN, identifiquei alguns enxames de servidores WOW, que presumo ser um servidor de World Of Warcraft? 
Esse aparecia constantemente em picos.
Notei que o tráfego voltou a níveis mais usuais, também parece mais estável e com um ritmo uniforme.
As métricas do AdSense melhoraram quase voltando ao normal ou pelo menos se recuperando (ou seja, um RPM baixo é melhor do que nenhum RPM!) 
Provavelmente foi a primeira vez que vi o tráfego colocar o servidor sob tanta pressão que o serviço estava lutando, neste caso, e além de outras mitigações como mudar o IP do servidor, no geral como uma solução rápida e uma solução de gerenciamento no momento a Cloudflare tem sido ótima, especialmente quando você não tem tempo para mexer ou as habilidades para mexer com nginx etc. enquanto sob algum tipo de ataque crescente, e permitiu que um droplet de especificação mínima rodasse perto do ocioso, dando-lhe margem além de suas especificações.