Incident Library

IL-0509 SourceHut · 2024-01-10networkingsecurity

DDoS 뒤 상위 망의 null route 로 SourceHut 의 PHL 데이터센터 망이 끊겨 170시간 동안 장애가 이어졌다

SourceHut 은 자기 서버를 PHL, AMS, FRE 세 데이터센터의 코로케이션에 두었다. PHL 이 주 데이터센터였고, FRE 는 오프사이트 백업용, AMS 는 앞으로 옮겨 갈 인프라를 연구하는 곳이었다. 2024년 1월 10일 06:00 UTC 무렵 PHL 인프라를 노린 layer 3 DDoS 가 시작됐다. layer 3 공격은 망 사업자의 도움 없이는 막을 수 없었다. 코로케이션 사업자는 자기 AS 의 서브넷을 SourceHut 에 내주고 Cogent 와 Level 3 로 라우팅했다. 이 가운데 Cogent 가 SourceHut 의 하위 AS 에 null route 를 걸어 09:00 UTC 무렵 PHL 망 전체가 끊겼다. SourceHut 은 공격 자체보다 PHL 상위 망의 대응이 인프라에 더 큰 피해를 줬다고 적었다.

코로케이션 사업자는 14:00 UTC 업무 시간에야 연락이 닿았다. 사업자가 Cogent 를 설득해 null route 를 /24 에서 /32 로 좁히자 18:00 UTC 무렵 서비스가 대부분 돌아왔다. 다음 날 06:30 UTC 무렵 공격이 넓어지자 사업자가 서브넷을 다시 null route 했고, 09:00 UTC 에 SourceHut 은 AMS 로 긴급 이전하고 백업에서 복원하기로 했다. 대기 데이터베이스는 운영 데이터와 30초 이내로 차이가 났고, 큰 저장소 백업은 12시간을 넘지 않았다.

SourceHut 은 AMS 에 새 환경을 처음부터 만들었다. 외부 DNS 로 옮기고, 새 주 데이터베이스를 띄우고, FRE 의 백업을 AMS 로 복원했다. 마지막 백업 이후의 차이는 손으로 반영했고 새 메일 시스템도 갖췄다. Cloudflare 의 견적은 작은 회사가 감당할 수 없는 금액이었다. 그래서 OVH 서버를 두고, 트래픽을 OVH 의 DDoS 방어 망을 거쳐 AMS 의 운영 서브넷으로 NAT 했다. 처음에는 모든 트래픽을 그대로 NAT 해서, 공격이 OVH 로 옮겨 왔을 때 들어온 DDoS 가 OVH 의 방어가 걸리기 전 잠깐 AMS 로 넘어갔다. 그 때문에 새 OVH 계정이 나가는 DDoS 의 출처처럼 보여 OVH 와 이 문제를 푸는 데 품이 들었다. 1월 12일에는 PHL 망 사업자가 임시 서브넷을 내줘 PHL 서버에 대역 외로 접근할 수 있었다.

paste 와 project hub 는 1월 11일 19:00 UTC 에 돌아왔다. git.sr.ht 와 hg.sr.ht 는 20:00 UTC 까지 조금 오래된 백업 데이터로 읽기 전용으로 돌아왔고, git.sr.ht 는 1월 13일 11:00 UTC 에 읽기와 쓰기를 모두 되찾았다. 커뮤니티가 관리하는 hg.sr.ht 는 커뮤니티 관리자가 도와줄 수 있을 때까지 늦어져 1월 15일 08:20 UTC 에 완전히 돌아왔다. pages.sr.ht 가 쓰는 S3 호환 객체 저장소는 오프사이트 백업에서 빠져 있어서 PHL 로 가는 대역 외 링크로 서비스했다. builds.sr.ht 는 OVH 베어메탈 서버에서 1월 16일 18:00 UTC 에 빌드 작업을 다시 받았고, 사용자마다 IPv6 주소를 따로 쓰는 chat.sr.ht 가 1월 17일 10:30 UTC 에 마지막으로 돌아왔다. SourceHut 은 유료 사용자 모두에게 7일 무료 이용으로 보상했다.

심각도
–
영향 범위
All SourceHut services; partial service returned from 12 January and full service on 17 January, and pages.sr.ht users with apex records on the PHL subnet had to update them
영향 사용자
all SourceHut users; paying users were credited 7 days of free service
지역
PHL datacenter
감지까지
0m
복구까지
170h

증상

2024년 1월 10일 06:00 UTC 무렵 모니터링 시스템이 SourceHut 의 PHL 인프라에 이상이 있다고 경보를 울렸다. 09:00 UTC 무렵에는 PHL 망에 아예 닿을 수 없게 됐다.

Cogent 가 SourceHut 의 하위 AS 에 null route 를 걸면서 PHL 망은 SourceHut 직원에게도, 일반 사용자에게도 닿지 않았다.

운영팀은 코로케이션 사업자에게 연락하려 했지만 닿지 않았다. 사업자는 몇 년 사이 두 번 인수됐고, 운영팀이 쓰던 티켓 포털은 폐기됐으며 SourceHut 계정은 새 시스템으로 옮겨지지 않았다. 사업자에게는 14:00 UTC 에 업무 시간이 시작되고서야 닿았다.

null route 가 /24 전체에서 공격받던 IP 주소 하나인 /32 로 좁혀지자 18:00 UTC 무렵 서비스가 대부분 돌아왔다. 다음 날 06:30 UTC 무렵 공격이 PHL 서브넷의 다른 부분까지 넓어지자 코로케이션 사업자가 서브넷을 다시 null route 했고, 그 뒤로 서브넷에는 계속 닿지 않았다.

증상 네트워크 도달 불가서비스 중단

원인

원인 의존성 장애

구성 요소 ISP·트랜짓 망BGP 라우팅
기여 요인 단일 장애점디버그 접근 제한미검증 백업
촉발
2024년 1월 10일 06:00 UTC 무렵 SourceHut 의 PHL 인프라를 노린 layer 3 DDoS 가 시작됐다. 상위 망인 Cogent 가 이에 대응해 SourceHut 의 하위 AS 에 null route 를 걸었다.

감지

06:00 UTC 무렵 모니터링 시스템이 이상을 알아채 경보를 울렸고, 운영팀은 곧 조사를 시작했다.

조치

후속 조치

교훈

SourceHut 은 데이터센터 전체 장애까지 대비해 둔 운영 계획이 이번 대응에 중요했다고 적었다. 이번 사고는 SourceHut 이 이중화와 복원력 목표를 다 이루기 전에, 알고 고치던 약점을 드러냈다. pages.sr.ht 의 S3 호환 객체 저장소가 오프사이트 백업에 들어 있지 않다는 것도 이번에 알았다. SourceHut 은 이번 일로 비상 절차를 실제로 시험해 볼 수 있었고, 안정성을 더 높일 방법을 많이 배웠다고 적었다. 긴급 이전으로 EU 로 옮기려던 장기 목표 상당수를 빨리 이뤘다.

출처

관련 사례

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

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

kubegap 열기

AI 도구와 스크립트용

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