감사합니다. DO(도메인)입니다. SSL 설정을 다시 돌아와서 더 신경 쓸 예정입니다. Full-strict가 아니라 Full로 설정했는데, 이것이 Let’s Encrypt와 상호작용한다고 생각합니다.
Bot 및 AI-Bot 완화 기능을 활성화했고, 특정 지역 서버 차단도 하나 설정했습니다.
감사합니다. DO(도메인)입니다. SSL 설정을 다시 돌아와서 더 신경 쓸 예정입니다. Full-strict가 아니라 Full로 설정했는데, 이것이 Let’s Encrypt와 상호작용한다고 생각합니다.
Bot 및 AI-Bot 완화 기능을 활성화했고, 특정 지역 서버 차단도 하나 설정했습니다.
응, 좀 이상하긴 해. 내 사이트 중 일부는 full 모드를 쓰고, 일부는 full strict를 써. 전부 같은 웹서버에서 돌고 있는데 꽤 이상하지? Cloudflare를 켤 때 몇 시간 간격으로 확인해 보고, VPN으로 ISP의 DNS 캐시를 우회해 보는 것도 추천해. 내 사이트 중 하나는 strict SSL + origin pull만 쓰다가 그렇지 않으면 에러가 나는 것 같아. SSL 에러가 나면 그냥 작동하는 설정으로 바꿔서 그대로 두는 편이야. CF를 적용한 30개 사이트 중 100%가 하루쯤 뒤에 그 설정을 조정해야 했어.
VPN을 사용하며 이리저리 둘러보는 동안 SSL 오류를 발견하지 못했습니다.
방금 Qualys를 확인해 보니 B 등급을 4번 받았습니다.
그동안 IP가 보호되지 않고 있었네요. 그렇다면 Cloudflare를 중간에 배치하면 더 이상 직접적인 IP 접근이 불가능해지는 것이 맞나요?
어쨌든 서버 IP를 변경할 예정입니다.
그런 셈이죠. 그들은 사이트나 데이터베이스에 직접 접근할 수는 없지만, DNS 기록은 공개되어 있습니다. https://dnshistory.org/ 같은 사이트들이 이를 기록하고 있거든요. 그래서 여전히 해당 IP에 DDoS 공격을 시도할 수는 있습니다. 보통 특정 IP에 대한 DDoS 공격은 그 IP가 어떤 것을 호스팅하는지 모르는 경우라면 드물게 발견됩니다. 그들이 어떤 결과를 만들어내고 있는지 볼 수 없으므로, 그들의 DDoS 대역폭을 낭비하는 셈이니까요.
와. 지난 대시보드 그래프가 제 것과 매우 비슷해 보이는데, 트래픽 볼륨이 더 견고해 보입니다.
타이밍도 같은 것 같습니다. 실제로 증가가 시작된 것은 약 7일 전부터였습니다.
두 단계로 나뉘어 보였습니다.
처음에는 며칠 동안 지속되는, 기분이 좋은 수준의 트래픽 증가가 있었고, 그다음에 두 번째 단계의 급증이 뒤따랐습니다.
지리적 위치도 동일합니다.
같은 물결처럼 보입니다.
지금 비교 그래픽을 올릴 수는 없습니다.
주된 원인으로 보이는 것은 싱가포르의 화웨이 ASN이었습니다. 이를 차단한 후 해당 트래픽이 급감했습니다.
또 다른 결과로, AdSense 지표도 거의 즉시 무너졌습니다.
화웨이는 2019년부터 싱가포르를 AI 허브로 삼아 투자를 시작했습니다.
같은 싱가포르 화웨이 ASN이 멕시코와 홍콩 트래픽에서도 확인되었습니다.
이것이 어떻게 작동하는지 아시는 분 계신가요? 위치 스푸핑인가요?
그리고 ‘기타’ 열도 따로 한번 살펴보세요. 놀라거나 충격을 받거나, 둘 다를 경험하게 될지도 몰라요!
DDoS 공격을 받고 있지 않더라도, 이 가이드는 Cloudflare 커뮤니티(discourse) 포럼에 게시된 Cloudflare의 게시물에서 찾은 것으로, 집중할 점과 처리할 수 있는 가능한 액션 포인트로 유용하다고 생각했습니다.
https://community.cloudflare.com/t/mitigating-an-http-ddos-attack-manually-with-cloudflare/302366
피크 스웜 트래픽이 도달했을 때, **바운스율(Bounce rate)**이 80%를 넘게 급등했습니다. 평소 트래픽에서는 이 수치가 20% 초반에서 중반 수준을 유지하는 것이 일반적입니다.
스웜 급증 기간 동안, @piff 님의 분석 결과와 마찬가지로 평균 참여 시간(average engagement timed)도 극적으로 감소했음을 확인했습니다. 이번에도 이에 상응하는 감소가 관찰되었습니다.
보통 이 지표를 확인하지는 않지만, 그래프를 게시해 주셨기 때문에 확인해 보았습니다. 평균 참여 시간(average engagement timed) 또는 바운스율(bounce rate)은 트래픽의 품질과 유형에 심각한 문제가 있음을 나타내는 좋은 지표라고 생각합니다.
이상하게도 하루치의 트래픽에서 바운스율이 다시 거의 80%까지 급등하는 것을 보고 있습니다 하지만 스웜은 없습니다. 트래픽 수준은 정상, 즉 스웜 발생 전 수준으로 보입니다.
분석 데이터의 지연이 있었습니다. 약간의 스웜이 발생했으며, 이전 메가 스웜의 약 30% 수준입니다. 동일한 패턴이 다시 반복되었습니다. 유일한 차이는 CF(Cloudflare)가 해당 압력을 관리하고 서버가 계속 작동하고 있다는 점이지만, 사용자 참여 지표가 크게 훼손되고 있으므로 이는 좋은 상황이 아닙니다.
제 해결책은 포르투갈어 사용국이 아닌 모든 국가를 지오톡킹하는 것이었습니다. 하지만 여전히 제 국가, 미국, 독일에서 높은 트래픽이 유입되고 있습니다.
브라질이 이 유형의 공격의 가장 큰 원천인 것 같아서 제 시도는 실패로 끝났습니다. 활성 멤버는 20명이지만, 월간 요청 수는 200만 건에 달합니다.
믿기 어렵게도, 플러그인이 비활성화되어 있더라도 제 인스턴스에 Fediverso(페디버스)에서 트래픽이 계속 유입되고 있습니다. 지쳐서 어떻게 해결해야 할지 도무지 감이 안 잡힙니다.
클라우드플레어(Cloudflare) 완화 조치 중 내게 효과적인 방법:
봇(Bots)
WAF 규칙 1)
ASN - JS 챌린지 적용 / ASN = 136907
(트래픽이 가장 많은 지역 순)
@piffy 같은 분들을 포함해 동일한 ASN이 여러분에게도 공격하고 있는지 확인해 주십시오. 이 트래픽은 구글 애널리틱스에서 실제 트래픽처럼 보였으며, 바운스율을 80% 이상으로 끌어올리고 사용자 참여도를 급락시켰습니다. 내 생각에 이는 애드센스(AdSense)의 RPM/CPC에도 악영향을 미칠 것입니다.
WAF 규칙 2)
지오훈도 JS 챌린지 적용 (트래픽이 가장 많은 지역 순)
클라우드플레어 서빙(처리)이 다시 증가하는 추세였고, 여전히 동일한 지리적 지역들이 상위를 차지하고 있어 이제 이 상위 3개 지역 위반자에 대해 지오훈도 JS 챌린지를 적용했습니다.
이 개입의 주된 목적은 분석/사용자 참여 지표의 건강성을 회복하는 것입니다. CF가 캐싱과 봇 공격 관리를 통해 상당 부분을 처리하기 때문에 이 트래픽은 더 이상 서버에 부하를 주지 않지만, 전반적인 지표가 심각하게 훼손되고 있습니다. 이것은 적대적인 트래픽입니다.
애널리틱스 지표/애드센스 등에서 개선이 보이면 업데이트하겠습니다.
WAF 규칙 No.2가 Geo 적용 JS 챌린지를 사용하여 추가 트래픽을 차단했습니다
이전 비율은 대략 4:1이었습니다.
Cloudflare:OriginServer
이제는 1:1로 제공되는 비율에 가깝습니다.
이 지역들은 여전히 막대한 양의 트래픽을 보내고 있었습니다.
분석 도구는 이상치 경보를 계속 발생시켰고, 분석 지표는 여전히 극도로 불안정한 상태였습니다.
AdSense는 정말 큰 타격을 입었습니다. 트래픽 급증으로 인해 페이지 RPM이 거의 0.00센트에 근접했습니다. AdSense가 이를 의심스러운 트래픽으로 감지하고 계측을 중단한 것으로 보입니다.
대시보드
대시보드 뷰는 다음과 같았습니다. 마지막 5일간의 수치가 낮은 이유는 이 시점부터 CF(클라우드플레어) 완화 조치가 적용되었기 때문입니다. 만약 조치가 없었더라면 이 트래픽이 증가를 멈출 이유는 전혀 없었을 것입니다.
비교를 위해, 기타(빨간색) 페이지 뷰 트래픽의 최고 기록 날은 익명(초록색) 페이지 뷰 볼륨의 거의 10배에 달했습니다. 이 의미를 잘 음미해 보세요. ![]()
앞으로 2~3일 안에 상황이 균형 잡히기를 바랍니다.
Challange JS는 관리형(Managed)과 동일한 효과를 제공하지 않습니다. CSS와 JS와 같은 미디어 및 라이브러리에 핫링크 차단(Hotlink Blocking)을 적용했는데, 거의 동일한 방식으로 작동합니다. Referrer(추적 정보)를 기준으로 하며, 새 탭에서 직접 접근을 시도하면 차단됩니다. 이를 통해 대역폭과 CPU 사용량을 줄이는 데 도움이 되었습니다.
아직 CSR(Challenge Solved Rate, 챌린지 해결률)이 0% 이므로, JS Challenge 설정을 당분간 유지할 것입니다.
더 많은 트래픽이 처리되고 있거나/CSR이 실패하기 시작하면 Managed 모드를 실험해 볼 계획입니다.
현재 CF:OS 서비스 비율은 1:1로 더 균형을 이루고 있는 것으로 보입니다.
Mitigated(완화됨) 상태가 자리를 차지하며 급격히 증가했습니다.
JS 챌린지에 의해 x 기간 동안 차단되고 있는데도 왜 공격이 계속되는지 궁금합니다(결국 그렇게 정교하지 않은 것 아닌가요?). 그리고 다른 ASN이나 지리적 위치를 통해 침입을 시도할까요?
이런 상황이 발생하면 새로운 공격 벡터에 대해 Managed 모드를 적용해 볼 것입니다.
JS 챌린지는 동일한 목적을 가지고 있지만 'Manage 챌린지’보다 효율성이 훨씬 낮기 때문에, 이 옵션이 캡차를 표시하지 않고 ‘managed’ 옵션처럼 합법적인 트래픽으로 판단하여 바로 차단하기 때문에 비추천(deprecated)된 것으로 보입니다.
메타에서 이 주제를 발견했는데, 매우 흥미롭고 단독으로 다뤄지는 것이 가장 적합할 것 같습니다: Cloudflare Security WAF (Web Application Firewall) + Discourse?
유용할 수 있는 다른 리소스 - https://radar.cloudflare.com/
주제를 업데이트하겠다고 했으니 업데이트 내용을 공유합니다.
전반적으로 무료 플랜에서 Cloudflare의 방어(Mitigation)가 현재로서는, 즉 단기적인 대응책으로서 매우 잘 작동했습니다.
어떤 의미에서는 Cloudflare이 Discourse와 함께 사용 가능하다는 사실을 알았더라면 좋았을 텐데, 어째서인지 그걸 놓치고 있었습니다.
Cloudflare을 활용한 다양한 방어 조치로 인해 싱가포르, 홍콩, 멕시코(대부분 위장된 것으로 추정)에서 유입되는 이상 트래픽이 거의 즉시 차단되었습니다.
어제와 오늘에는 동일한 트래픽 소스가 공격을 멈춘 것으로 보이는 추세가 관찰되었습니다. 트래픽량이 급격히 감소했기 때문입니다. 이는 공격자가 포기하는 데 걸린 시간과 거의 일치합니다.
하지만 아직 초기 단계입니다.
또한 다른 짧은 시간 동안의 공격(Burst attacks)이나 봇 트래픽도 더 쉽게 식별할 수 있게 되었습니다.
Cloudflare은 보통 30~60분 후에 이러한 공격을 방어하는 것으로 보입니다. Cloudflare이 제공한 서지(Surge) 데이터를 집중적으로 분석하면, 소스 ASN이나 지리 정보를 파악하고 블랙리스트에 추가하거나 WAF 규칙을 적용하는 것이 훨씬 쉬워집니다.
https://radar.cloudflare.com/bots/ 링크는 ASN의 품질을 파악하는 데 정말 유용했습니다. ‘WOW’ 서버 스웜을 몇 개 발견했는데, 아마 월드 오브 워크래프트(World of Warcraft) 서버일 것 같습니다.
해당 항목이 서지 데이터에 자주 등장했습니다.
트래픽이 다시 평소 수준으로 돌아온 것을 확인했는데, 리듬도 더 안정적이고 고르게 보입니다.
AdSense 지표도 거의 정상으로 회복되었거나, 최소한 회복 중인 것으로 보입니다. (즉, RPM이 없느니만 못한 것보다는 낫다는 뜻입니다!) ![]()
이것은 서버에 이렇게 큰 압력을 가해 서비스가 고전하는 트래픽을 처음 목격했던 순간일 것입니다. 이번 사례를 제외하면, IP 변경과 같은 다른 방어 조치와 함께, Cloudflare은 긴급 상황에서의 빠른 해결책이자 관리 도구로서 훌륭했습니다. 특히 공격이 진행 중인 상황에서 nginx 등을 직접 조정할 시간이나 기술이 없을 때 더욱 그렇습니다. 덕분에 최소 사양의 드롭렛(Droplet)이 거의 유휴 상태에 가깝게 실행될 수 있었고, 사양을 초과하는 여유 공간(Headroom)을 확보할 수 있었습니다.