Incident Library

IL-0494 Netlify · 2016-08-22networkingsecurity

DDoS 중 호스팅 사업자가 중앙 로드 밸런서 IP를 null route 해 A 레코드로 Netlify를 가리킨 사이트가 응답하지 않았다

Netlify는 사이트를 두 방식으로 내보낸다. 하나는 Netlify CDN이다. Netlify CDN은 전 세계에 PoP를 두고, 사용자를 지리적으로 가장 가까운 곳으로 보내는 트래픽 라우팅 체계를 갖췄다. 다른 하나는 DNS 사업자가 네이키드 도메인에 CNAME, ANAME, ALIAS 레코드나 CNAME flattening을 지원하지 않는 사용자가 A 레코드로 가리킬 수 있게 공개한 중앙 로드 밸런서 IP다. 2016-08-22까지 이 로드 밸런서는 Rackspace의 시카고 데이터센터에 있었다.

8월 20일 토요일 밤 중앙 로드 밸런서로 들어오는 전송량이 크게 늘었고, Netlify는 용량을 더하고 Rackspace에 물었지만 걱정할 수준이 아니라는 답을 받았다. 8월 22일 월요일 오전 8시 PST에 로드 밸런서가 응답을 멈췄고, Rackspace가 DDoS 때문에 로드 밸런서를 null route 해 공개 IP로 가는 트래픽이 서버에 닿기 전에 멈춰 있었다. 관리형 로드 밸런서라 DDoS 대응은 Netlify가 손댈 수 없었고, Rackspace는 복구 예상 시각도 공격 정보도 주지 못했다.

Netlify는 Rackspace에 문제를 올리는 동시에 Google Compute에 새 CDN 클러스터를 띄우고, Maglev 기반 Google 네트워크 로드 밸런서를 가리키는 새 공개 IP를 연락해 온 고객에게 알려 A 레코드를 바꾸게 했다. 이 방법이 안정적이라고 확신한 뒤 문서를 고치고 Twitter, Gitter, 상태 페이지에 새 IP를 알렸다. 상태 페이지는 Netlify로 띄울 수 없어 외부 CI, S3, CloudFront로 따로 만든 게시 체계를 썼는데, 이 체계가 불안정해 상태 페이지가 제때 갱신되지 않았다.

심각도
–
영향 범위
All sites with an A record pointed at Netlify's central load balancer IP; naked domains used as primary domains were hit hardest
영향 사용자
Netlify users with A records pointed at the load balancer IP
지역
–
감지까지
–
복구까지
–

증상

2016-08-22 월요일 오전 8시 PST에 Netlify 중앙 로드 밸런서가 응답하지 않는다는 알림이 왔다. 로드 밸런서의 공개 IP로 가는 트래픽은 서버에 닿기 전에 멈춘 채 응답이 없었다.

A 레코드로 로드 밸런서 IP를 가리킨 모든 사용자가 어느 정도 영향을 받았다. 네이키드 도메인을 A 레코드로 걸어 주 도메인으로 쓴 사이트가 가장 크게 영향을 받았다.

이틀 전인 8월 20일 토요일 밤에 중앙 로드 밸런서로 들어오는 전송량이 크게 늘었지만 나가는 요청은 그만큼 늘지 않았다. 팀은 로드 밸런서 뒤에 용량을 더하고 Rackspace에 정상 트래픽인지 DDoS 공격의 시작인지 물었고, Rackspace는 걱정할 수준이 아니라고 답했다.

Rackspace에 연락하고서야 Rackspace가 로드 밸런서를 null route 했다는 것을 알았다. 복구 예상 시각과 공격의 규모와 종류를 물었고 계정 관리자에게까지 올렸지만 구체적인 정보를 얻지 못했다.

증상 네트워크 도달 불가

원인

원인 클라우드 제공자 장애

구성 요소 클라우드 로드 밸런서
기여 요인 단일 장애점디버그 접근 제한
촉발
DDoS 트래픽이 Rackspace 시카고 데이터센터에 있던 Netlify 중앙 로드 밸런서로 몰렸고, Rackspace가 그 로드 밸런서의 IP를 null route 했다.

감지

2016-08-22 월요일 오전 8시 PST에 중앙 로드 밸런서가 응답을 멈췄다는 알림을 받았다. 이틀 전 토요일 밤에는 로드 밸런서의 트래픽 패턴에서 들어오는 전송량 급증을 먼저 알아챘다.

조치

후속 조치

교훈

관리형 로드 밸런서를 쓰는 한 DDoS 대응은 Netlify가 손댈 수 없었다. Rackspace의 로드 밸런서는 DDoS 공격에 너무 약했고 DDoS 대응 절차도 함께 일하는 다른 클라우드 사업자에 못 미쳤다. 결국 도메인을 DDoS 장애에서 지키는 유일한 방법은 그 도메인에 고정 IP 주소를 아예 드러내지 않는 것이다. 단일 IP에 기대지 않고 www 도메인을 주 도메인으로 쓰는 것이 성능과 가동 시간에 중요하다. 상태 페이지 게시 체계는 가장 필요할 때 불안정했다.

출처

관련 사례

내 클러스터에도 있는지 확인하기

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: 클라우드 로드 밸런서. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.