Referer 위조형 HTTP GET Flood 공격 분석: Cloudflare 로그로 본 L7 DDoS 대응 사례
본문에 포함된 Domain이나 수치는 공개용 예시값으로 변경했습니다.
많은 DDoS 공격 중 하나의 케이스로 참고해 주세요.
개요
4월 어느 날, Cloudflare Security Analytics와 HTTP Traffic 로그를 확인하던 중, 비정상적인 대량 HTTP 요청이 발생한 것을 확인했습니다.
처음에는 다양한 외부 Referer에서 유입된 일반 트래픽처럼 보였지만, 로그를 자세히 보면 정상적인 웹 유입으로 보기 어려운 패턴이 여러 개 확인되었습니다.
이번 트래픽의 핵심 특징은 다음과 같습니다.
- HTTP Method는 대부분 GET
- 공격 대상 Path는 대부분 `/`
- Referer는 유명 사이트 도메인으로 대량 위조
- User-Agent는 Android / Windows Chrome 계열로 위장
- Cloudflare HTTP DDoS Rules에서 known botnet / known bad sources로 대량 차단
- 차단된 트래픽 외에도 동일 시간대에 200 OK 응답 트래픽이 존재이번 사례는 Referer를 위조한 루트 경로 대상 HTTP GET Flood 공격 으로 판단이 되었고, Cloudflare에서 자동으로 방어가 되기 시작했지만, Origin으로 흘러들어간 트래픽도 상당히 있었습니다.
따라서 아래에서 설명하는 확인 절차를 거친 뒤, 추가로 WAF룰을 설정해서 후속 조치를 취해습니다.
1. Cloudflare 자동 방어에서 확인된 트래픽
Cloudflare의 공격 방어 시스템에서 자동 차단된 이벤트는 약 2,777만 건이었습니다.
Action 기준으로 보면 대부분Block처리되었고, HTTP Method는 거의 전부GET이었습니다.
Total blocked events : 약 27.77M
Action : Block
HTTP Method : GETHTTP DDoS Rules 기준으로는 다음과 같은 탐지가 확인되었습니다.
HTTP requests from known botnet : 약 25.73M
Requests coming from known bad sources : 약 2.04M즉, Cloudflare는 이 트래픽을 단순한 일반 요청이 아니라 알려진 Botnet 또는 악성 소스 기반의 L7 DDoS 트래픽으로 판단해 차단한 것으로 볼 수 있습니다.
Cloudflare의 HTTP DDoS Attack Protection managed ruleset은 L7, 즉 애플리케이션 계층의 알려진 DDoS 공격 벡터, 의심스러운 요청 패턴, 프로토콜 위반, Origin 또는 Cache에 과도하게 집중되는 트래픽 등을 탐지하기 위한 관리형 룰셋입니다.
참고 문서:
2. 공격의 중심 Path는 /
처음에는 /notice_on.asp, /realtime.asp, /main.asp 같은 동적 페이지도 공격 대상 후보로 볼 수 있었습니다.
하지만 Path 기준으로 다시 확인해 보면, 실제 공격의 중심은 특정 ASP 파일이 아니라 사이트 루트 경로인 / 였습니다.
Cloudflare 자동 방어에 의해 차단된 트래픽의 Path는 다음과 같았습니다.
/ 약 27.76M
/cdn-cgi/challenge-platform/... 수십 건 수준
/favicon.ico 소량전체 차단 이벤트가 약 2,777만 건이었음을 감안하면, 자동 차단된 요청의 거의 대부분이 /에 집중되어 있었다고 볼 수 있습니다.
따라서 이번 공격은 특정 로그인 페이지, API, 게시판, ASP 파일을 노린 공격이라기보다는, 홈페이지 루트 경로에 대량의 GET 요청을 발생시키는 HTTP GET Flood에 가깝다고 판단했습니다.
정리하면 다음과 같습니다.
공격 Method : GET
공격 Path : /
공격 유형 : L7 HTTP GET Flood
위장 요소 : Referer 위조 + 일반 브라우저 User-Agent 위장
차단 근거 : Cloudflare HTTP DDoS Rules - known botnet / bad sources3. Referer는 정상 유입처럼 보이도록 위조
Referer 목록을 보면 처음에는 여러 유명 사이트에서 유입된 것처럼 보입니다.
예를 들면 다음과 같은 Referer들이 확인되었습니다.
HTTP 200 OK 트래픽 쪽에서도 유사한 패턴이 확인되었습니다.
정상적인 웹 유입이라면 검색엔진, SNS, 광고 캠페인, 특정 외부 링크 등으로 어느 정도 편중이 생기는 것이 일반적입니다.
하지만 이번 로그에서는 서로 관계없는 유명 도메인들이 거의 비슷한 볼륨으로 반복되었습니다. 이는 자연스러운 Referer 분포라고 보기 어렵습니다.
따라서 이 트래픽은 “해당 사이트들에서 실제로 유입된 트래픽”이라기보다는, 공격자가 HTTP Referer 헤더를 임의로 삽입해 정상 유입처럼 보이도록 위장한 것으로 판단했습니다.
위 근거들을 바탕으로 생각을 해본 결과 이번 공격은 Referer 위조형 HTTP GET Flood 공격이었다고 판단했습니다.
4. User-Agent도 정상 브라우저처럼 위장
User-Agent에서도 반복적인 패턴이 확인되었습니다.
대표적으로 다음 계열이 많이 보였습니다.
겉으로는 Android 최신 단말기나 Windows Chrome 브라우저처럼 보입니다.
하지만 동일하거나 유사한 User-Agent가 수백만 건 단위로 반복된다면 정상적인 사용자 분포로 보기 어렵습니다.
이는 Bot이 일반 브라우저처럼 보이기 위해 User-Agent를 템플릿화해서 사용한 것으로 해석할 수 있습니다.
다만 여기서 주의할 점은 Windows NT 10.0; Win64; x64나 Chrome 계열 User-Agent는 실제 정상 사용자도 많이 사용한다는 사실입니다.
따라서 User-Agent는 단독 차단 조건으로 사용하기보다는 다음 조건들과 조합하는 것이 안전하다고 판단했습니다.
- 특정 공격 Path
- 비정상 Referer
- 과도한 요청량
- Bot Score
- Verified Bot 제외
- Rate Limit 초과 여부5. Edge Status Code 200 OK 트래픽
동일 시간대의 HTTP Traffic 그래프에서 Edge Status Code 200 OK만 필터링했을 때도 대량의 요청이 확인되었습니다.
Path 기준으로 보면 200 OK 트래픽에서도 /가 가장 많았습니다.
여기서 중요한 점은, 200 OK가 반드시 Origin 서버까지 도달했다는 의미는 아니라는 점입니다.
200 OK는 다음 세 가지 가능성이 모두 있습니다.
1. Origin 서버가 실제로 200 OK를 반환한 경우
2. Cloudflare Cache가 200 OK를 반환한 경우
3. Cloudflare Edge, Worker, Challenge/Error page 처리 과정에서 200 OK가 반환된 경우따라서 “Cloudflare 자동 방어를 통과한 트래픽이 모두 Origin까지 도달했다”고 단정하면 안 됩니다.
그렇기 때문에 운영 환경에서는 다음 필드를 함께 확인하는 것이 좋습니다.
ClientRequestPath
ClientRequestReferer
ClientRequestUserAgent
EdgeResponseStatus
OriginResponseStatus
CacheCacheStatus
OriginResponseTime
RayID특히 다음 기준으로 보면 됩니다.
CacheCacheStatus = hit
→ Cloudflare Edge에서 응답했을 가능성이 높음
CacheCacheStatus = miss / dynamic / bypass
OriginResponseStatus = 200
→ Origin까지 도달했을 가능성이 높음
EdgeResponseStatus = 200
OriginResponseStatus가 비어 있음
→ Edge 또는 Cloudflare 기능에서 응답했을 가능성 있음이번 공격에서는 CacheCacheStatus = miss / dynamic / bypass인 트래픽이 Origin까지 흘러들어가서 서버에 부하를 발생시켰을 가능성이 크다고 생각했습니다.
6. /cdn-cgi/challenge-platform/ 예외처리
Path 목록에는 /cdn-cgi/challenge-platform/... 요청도 일부 보였습니다.
하지만 이 경로는 공격자가 직접 노린 대상이라기보다는 Cloudflare의 Challenge, Bot Detection, JavaScript Detection 관련 처리 과정에서 사용되는 관리 경로로 보는 것이 맞습니다.
Cloudflare 문서에서도 /cdn-cgi/ endpoint는 Cloudflare 기능을 위해 사용되는 경로이며, /cdn-cgi/challenge-platform/는 JavaScript Detection 등 Bot 관련 기능에서 사용됩니다.
참고 문서:
따라서 WAF Rule을 만들 때 다음과 같은 방식은 피해야 합니다.
잘못된 예:
- /cdn-cgi/* 전체 차단
- /cdn-cgi/challenge-platform/* 차단이 경로를 잘못 차단하면 Cloudflare Challenge가 정상 동작하지 않거나, 사용자가 Challenge 루프에 빠질 수 있습니다.
7. Referer만으로 차단했을 경우의 위험성
이번 공격의 핵심 단서는 Referer였지만, Referer만으로 차단하는 것은 위험합니다.
예를 들어 아래와 같은 룰은 너무 광범위합니다.
http.referer ne ""이렇게 설정하면 Referer가 있는 모든 외부 유입이 차단될 수 있습니다.
검색엔진, SNS, 외부 블로그, 광고, 고객사 링크 등 정상적인 유입도 함께 차단될 수 있습니다.
반대로 아래 조건만 보는 것도 충분하지 않습니다.
http.referer eq ""Referer가 없는 None (direct) 요청도 공격에 포함되어 있었지만, 실제 사용자가 주소창에 직접 URL을 입력하거나, 메신저 앱, 보안 정책, 브라우저 설정에 의해 Referer 없이 접속하는 경우도 많습니다.
따라서 Referer는 단독 조건이 아니라 다음과 같이 조합해서 사용해야 합니다.
- Host
- Path
- Method
- Referer
- User-Agent
- Bot 여부
- Rate Limit
- Bot ScoreCloudflare Custom Rules에서는 요청 조건을 필터링하고 Block, Managed Challenge 같은 Action을 수행할 수 있습니다.
참고 문서:
8. 실효성 있는 WAF Rule 예시
이번 케이스에서는 공격 대상이 대부분 /였기 때문에, WAF Rule도 / 중심으로 설계하는 것이 좋습니다.
아래 예시는 실제 도메인을 example.com으로 표기했습니다.
실제 적용 시에는 운영 중인 도메인으로 변경해야 합니다.
Rule 1. 루트 경로 /에 대한 외부 Referer 요청 Challenge
외부 Referer가 있는 / 요청 중, 자기 도메인에서 온 Referer와 Verified Bot을 제외하고 Managed Challenge를 거는 방식입니다.
(
http.request.method eq "GET"
and http.request.uri.path eq "/"
and http.referer ne ""
and not cf.client.bot
and not http.referer matches r"^https?://(www\.)?example\.com(/|$)"
)- regex matches는 Cloudflare Business/Enterprise에서 사용 가능합니다. Free Plan의 경우 Wildcard 조건으로 대체하는 것이 현실적입니다.
권장 Action:
Managed Challenge공격 중이고 정상 외부 유입이 거의 없는 사이트라면 임시로 Block도 가능하지만, 블로그나 기업 사이트처럼 외부 링크 유입이 있는 경우에는 처음부터 Block하는 것은 신중해야 합니다.
Rule 2. 루트 경로 / Rate Limiting
이번 공격은 /에 집중되었기 때문에 Rate Limiting도 / 기준으로 적용하는 것이 효과적입니다.
Expression:
(
http.request.method eq "GET"
and http.request.uri.path eq "/"
and not cf.client.bot
)초기 기준값 예시:
30 requests / 10 seconds / IP권장 Action:
Managed Challenge공격이 강한 경우에는 일정 시간 Block을 적용할 수도 있습니다.
Cloudflare Rate Limiting Rules는 특정 Expression에 매칭되는 요청이 지정한 요청 수를 초과했을 때 Action을 수행하는 기능입니다.
참고 문서:
Rule 3. 공격 당시 User-Agent 패턴에 대한 임시 Challenge
공격 당시 SM-S928B와 특정 Chrome 버전 문자열이 반복적으로 보였다면, 이를 임시 룰로 사용할 수 있습니다.
(
http.request.method eq "GET"
and http.request.uri.path eq "/"
and not cf.client.bot
and http.referer ne ""
and http.user_agent matches r"(SM-S928B|Chrome/142\.0\.7444)"
)- regex matches는 Cloudflare Business/Enterprise에서 사용 가능합니다. Free Plan의 경우 Wildcard 조건으로 대체하는 것이 현실적입니다.
권장 Action:
Managed Challenge이 룰은 영구 룰로 두기보다는 공격 당시 패턴에 맞춘 임시 대응 룰로 보는 것이 좋습니다.
특히 Chrome, Windows, Android 관련 User-Agent는 정상 사용자도 많이 사용하므로, User-Agent 단독 차단은 피해야 합니다.
Rule 4. /cdn-cgi/challenge-platform/ 예외 처리
광범위한 WAF Rule을 만들 때는 Cloudflare 관리 경로를 잘못 차단하지 않도록 주의해야 합니다.
예를 들어 특정 경로 전체를 강하게 제어하는 룰을 만들 경우, 다음 예외 조건을 추가하는 것이 안전합니다.
and not starts_with(http.request.uri.path, "/cdn-cgi/challenge-platform/")starts_with()는 Cloudflare Rules language에서 문자열이 특정 값으로 시작하는지 확인할 때 사용할 수 있는 함수입니다.
참고 문서:
9. 최종 결론
이번 로그를 기준으로 보면, 이 공격은 단순한 Referer 이상 트래픽이 아닙니다.
핵심은 다음과 같습니다.
- 공격자는 사이트 루트 경로 `/`에 대량의 GET 요청을 발생시켰다.
- Referer는 SoundCloud, WashingtonPost, YouTube, Amazon, Facebook 등 유명 도메인으로 위조되어 있었다.
- User-Agent는 Android 최신 단말기나 Windows Chrome 브라우저처럼 보이도록 구성되어 있었다.
- Cloudflare HTTP DDoS Protection은 이 중 약 2,777만 건을 known botnet / bad source 기반으로 차단했다.
- 그러나 동일 시간대에 200 OK 응답을 받은 `/` 요청도 수백만 건 확인되었다.
- 따라서 자동 DDoS 방어 외에도 `/` 경로 중심의 WAF Rule과 Rate Limiting Rule이 필요하다.이번 사례에서 가장 중요한 교훈은 다음 두 가지입니다.
첫째, Referer는 신뢰할 수 있는 출처 정보가 아닙니다.
HTTP Referer 헤더는 공격자가 쉽게 조작할 수 있으므로, Referer만 보고 정상 유입 또는 공격 유입을 판단해서는 안 됩니다.
둘째, 200 OK는 Origin 도달을 의미하지 않습니다.
200 OK는 Cloudflare Edge, Cache, Worker, Challenge/Error page, Origin 서버 중 어디에서든 발생할 수 있습니다.
따라서 실제 Origin 피해 여부를 판단하려면 OriginResponseStatus, CacheCacheStatus, OriginResponseTime 등을 함께 확인해야 합니다.
최종적으로 이번 공격은 다음과 같이 정의할 수 있습니다.
Referer 위조형 루트 경로 대상 L7 HTTP GET Flood 공격실무적인 대응 우선순위는 다음과 같습니다.
1. Cloudflare HTTP DDoS Protection 유지
2. `/` 경로 Rate Limiting 적용
3. `/` 경로 외부 Referer 요청에 Managed Challenge 적용
4. 공격 당시 반복된 User-Agent 패턴은 임시 Challenge 룰로 대응
5. Bot Score 사용 가능 시 낮은 점수 요청에 Challenge 또는 Block 적용
6. `/cdn-cgi/challenge-platform/`는 차단하지 않도록 예외 처리
7. Cloudflare Logpush와 Origin access_log를 대조하여 실제 Origin 도달 여부 확인Cloudflare의 자동 방어는 이번 공격에서 상당히 효과적으로 동작했습니다.
하지만 자동 방어만으로 모든 공격성 요청을 완전히 걸러낼 수는 없습니다.
결국 안정적인 운영을 위해서는 Cloudflare의 Managed DDoS Protection, Custom WAF Rules, Rate Limiting, Bot Management 등의 보안기능을 최대한 활용해 다층 방어를 구성해야 합니다.