2.45 Billion Requests, 1.2 Million IPs: 전통적인 Rate Limiting이 사라진 이유
I’m ready to translate the article for you, but I’ll need the text you’d like translated. Could you please paste the content (or the portion you want translated) here? Once I have the text, I’ll provide the Korean translation while preserving the source link, formatting, and any code blocks or URLs unchanged.
무슨 일인가요
최근 대규모 사용자 생성 콘텐츠 플랫폼을 대상으로 5시간 만에 24억 5천만 건의 악성 요청이 발생한 대규모 DDoS 캠페인이 진행되었습니다.
공격자는 1,200,000개의 고유 IP 주소와 **16,402개의 자율 시스템(ASN)**에 트래픽을 분산시켜, 각 IP당 요청 속도를 낮게 유지함으로써 정상 트래픽처럼 보이게 했습니다.
- 각 소스는 평균 9초에 한 번 요청을 보냈습니다.
- 단일 IP나 네트워크가 두드러지지 않았으며, 가장 큰 기여를 한 ASN은 전체 공격 트래픽의 **3 %**에 불과했습니다.
- 캠페인의 피크는 **초당 205,344 요청(RPS)**였으며, 지속 평균은 ≈136,000 RPS였습니다.
공격 구조
- 파동 패턴: 지속적인 홍수가 아니라, 공격자는 의도적인 파동으로 트래픽을 전송했으며, 파동마다 IP를 회전시키고, 사용자 에이전트를 교체하며, 페이로드를 변형했습니다.
- 전략적 일시정지를 통해 집계된 속도 제한 카운터를 초기화시켜, 각 새로운 파동이 신선하고 정상 트래픽처럼 보이게 했습니다.
- 트래픽은 프라이버시 중심 인프라(예: 1337 Services GmbH, Church of Cyberology)와 주요 클라우드 제공업체(AWS, Cloudflare, Google) 전반에 걸쳐 혼합되었습니다. 이를 통해 악성 요청이 방대한 정상 클라우드 아웃바운드 트래픽과 섞이게 되었습니다.
전통적인 속도 제한이 실패한 이유
표준 속도 제한 방식은 개별적으로 요청을 평가하여, 단일 IP나 세션이 일정 시간 창 내에서 임계값을 초과했는지를 확인합니다. 1.2 백만 개의 IP가 각각 9초마다 한 번씩 요청을 보냈을 때, 어느 개별 소스도 제한에 걸리지 않았습니다.
- ASN 별 차단은 효과가 없었습니다: 트래픽이 16,000개가 넘는 ASN에 고르게 분산되어 있었고, 어느 단일 ASN도 전체의 3 % 이상을 차지하지 않았습니다.
- 헤더 및 쿠키 검사는 제한적인 가치만 제공했습니다; 공격자들은 이러한 값을 위조하고 클라이언트 측 식별 신호를 지속적으로 전환했습니다.
완화 접근 방식
공격은 정적 임계값 대신 계층적 행동 감지를 사용하여 실시간으로 탐지 및 차단되었습니다:
- 서버‑사이드 지문화 – 네트워크‑계층 불일치를 포착했습니다.
- 행동 분석 – 시간 및 출처에 걸친 비정상적인 세션 시퀀스를 식별했습니다.
- 위협 인텔리전스 – 부정적인 평판을 가진 IP를 표시했습니다.
“이 단일 요청이 의심스러운가?”라고 묻는 대신, 시스템은 “시간과 출처에 걸친 행동 패턴이 타당한가?”라고 물었습니다.
개발자 및 엔지니어링 팀을 위한 권장 사항
1. Rate limiting은 필요하지만 충분하지 않다
- 단순 남용을 방지하기 위해 IP당 제한을 유지하되, 분산 공격을 처리하기 위한 추가 레이어를 추가한다.
2. 개별 요청이 아니라 패턴을 생각하라
- aggregate behavior(집계 행동)를 모니터링한다: 동일한 엔드포인트에 대해 비슷한 타이밍으로 접근하는 고유 IP 수가 급증하면, 각 IP가 정상처럼 보여도 신호가 될 수 있다.
3. 클라이언트‑사이드 신호를 검증하라
- TLS 지문, JavaScript 실행 동작, 세션 연속성의 일관성을 확인한다. 이번 캠페인에서는 공격자가 브라우저 식별 신호를 일관되게 유지하지 못했다.
4. 주요 클라우드 제공업체에서 온 트래픽을 무조건 신뢰하지 말라
- AWS, Google Cloud 등에서 오는 요청이 자동으로 합법적인 것은 아니다; 공격자는 이러한 제공업체를 통해 화이트리스트를 우회하는 경우가 많다.
5. 방어를 레이어링하라
- Rate limiting을 다음과 결합한다:
- 행동 분석
- IP 평판 검사
- 지문화
- 챌린지 메커니즘(예: CAPTCHA, JavaScript 챌린지)
6. 공격자의 약점을 활용하라
- 공격자는 일관된 브라우저 동작을 위조하거나 JavaScript 챌린지를 해결하지 못했다. 이러한 검증을 구현하면 방어자는 결정적인 이점을 얻을 수 있다.
Takeaway
정적이고 임계값 기반 방어만으로는 더 이상 충분하지 않습니다. 탐지는 시간과 출처에 걸친 행동 기준에 기반해야 하며, 개별 요청을 따로 평가하는 것이 아니라 전체적인 맥락을 고려해야 합니다. 계층화된 접근 방식은 공격자에게 동시에 여러 문제를 해결하도록 강요하여, 캠페인의 비용과 복잡성을 높입니다.