{"id":"IL-0509","org":"SourceHut","date":"2024-01-10","docs":[],"title":{"en":"SourceHut was down for 170 hours after a DDoS led its upstream network to null-route the PHL datacenter's subnet","ko":"DDoS 뒤 상위 망의 null route 로 SourceHut 의 PHL 데이터센터 망이 끊겨 170시간 동안 장애가 이어졌다"},"domain":["networking","security"],"impact":{"scope":"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","users":"all SourceHut users; paying users were credited 7 days of free service","region":"PHL datacenter"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"The operational plans SourceHut kept for failures up to the loss of a whole datacenter proved important in this incident. The incident exposed a known shortcoming in redundancy and resilience that the team was working on but had not finished, and the response of the upstream network to the attack did more damage than anything else.","ko":"SourceHut 은 데이터센터 전체 장애까지 대비해 둔 운영 계획이 이번 대응에 중요했다고 적었다. 이번 사고는 SourceHut 이 이중화와 복원력 목표를 다 이루기 전에, 알고 고치던 약점을 드러냈다. pages.sr.ht 의 S3 호환 객체 저장소가 오프사이트 백업에 들어 있지 않다는 것도 이번에 알았다. SourceHut 은 이번 일로 비상 절차를 실제로 시험해 볼 수 있었고, 안정성을 더 높일 방법을 많이 배웠다고 적었다. 긴급 이전으로 EU 로 옮기려던 장기 목표 상당수를 빨리 이뤘다."},"related":[],"sources":[{"url":"https://sourcehut.org/blog/2024-01-19-outage-post-mortem/","kind":"blog","archived":"https://web.archive.org/web/20260804180050/https://sourcehut.org/blog/2024-01-19-outage-post-mortem/"}],"summary":{"en":"SourceHut runs its own servers in colocation at three datacenters: PHL, the primary; FRE, used for off-site backups, including a Postgres standby replicated in real time and daily backups of large data such as git.sr.ht; and AMS, a research installation for a planned migration to the EU, provisioned to run most of a SourceHut installation. In PHL, SourceHut rented network service from its colocation provider, which provisioned a subnet out of its own AS and routed it through Cogent and Level 3. In response to a layer 3 DDoS attack that began at about 06:00 UTC on 10 January 2024, Cogent null-routed SourceHut's downstream AS. Service mostly returned by 18:00 UTC after the null route was narrowed to the one targeted /32, but the attack broadened the next morning and the colocation provider null-routed the whole subnet again. The write-up says the upstream network's response did more damage to SourceHut's infrastructure than anything else.\n\nAt 09:00 UTC on 11 January SourceHut decided to migrate to AMS in an emergency and restore from backups. The standby database was less than 30 seconds behind production and large storage backups were no more than 12 hours old. The team built a new SourceHut installation from scratch: it moved DNS to an external provider, brought up a new primary database, restored backups from FRE to AMS, applied the difference between production data and the last backups by hand, provisioned a new mail system, and brought services up as their restores finished. A layer 3 attack can only be absorbed with more bandwidth than the attacker or filtered far enough upstream, and many DDoS protection services only cover web traffic, while SourceHut also serves SSH, SMTP and IRC and terminates end-to-end encryption on its own servers. Cloudflare's quote was beyond SourceHut's means, so the team set up an OVH box that NATs traffic through OVH's DDoS-resistant network to a production subnet in AMS kept secret. From 12 January a temporary subnet from the PHL provider gave out-of-band access to the PHL servers.\n\nServices came back in stages. paste and the project hub, which need only a working SQL server, returned at about 19:00 UTC on 11 January; git.sr.ht came back read-only from somewhat stale backups by 20:00 UTC and read/write at 11:00 UTC on 13 January; hg.sr.ht at 08:20 UTC on 15 January; builds.sr.ht at 18:00 UTC on 16 January on dedicated OVH bare-metal servers, because AMS lacked compute; and chat.sr.ht, which needs a separate IPv6 address per user for outbound IRC connections, last at 10:30 UTC on 17 January. pages.sr.ht used S3-compatible object storage that the off-site backups did not cover, so it ran over an out-of-band link to PHL while the slow object storage migration continued, and users whose apex records pointed directly at the PHL subnet had to change them. The outage lasted 170 hours.","ko":"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 상위 망의 대응이 인프라에 더 큰 피해를 줬다고 적었다.\n\n코로케이션 사업자는 14:00 UTC 업무 시간에야 연락이 닿았다. 사업자가 Cogent 를 설득해 null route 를 /24 에서 /32 로 좁히자 18:00 UTC 무렵 서비스가 대부분 돌아왔다. 다음 날 06:30 UTC 무렵 공격이 넓어지자 사업자가 서브넷을 다시 null route 했고, 09:00 UTC 에 SourceHut 은 AMS 로 긴급 이전하고 백업에서 복원하기로 했다. 대기 데이터베이스는 운영 데이터와 30초 이내로 차이가 났고, 큰 저장소 백업은 12시간을 넘지 않았다.\n\nSourceHut 은 AMS 에 새 환경을 처음부터 만들었다. 외부 DNS 로 옮기고, 새 주 데이터베이스를 띄우고, FRE 의 백업을 AMS 로 복원했다. 마지막 백업 이후의 차이는 손으로 반영했고 새 메일 시스템도 갖췄다. Cloudflare 의 견적은 작은 회사가 감당할 수 없는 금액이었다. 그래서 OVH 서버를 두고, 트래픽을 OVH 의 DDoS 방어 망을 거쳐 AMS 의 운영 서브넷으로 NAT 했다. 처음에는 모든 트래픽을 그대로 NAT 해서, 공격이 OVH 로 옮겨 왔을 때 들어온 DDoS 가 OVH 의 방어가 걸리기 전 잠깐 AMS 로 넘어갔다. 그 때문에 새 OVH 계정이 나가는 DDoS 의 출처처럼 보여 OVH 와 이 문제를 푸는 데 품이 들었다. 1월 12일에는 PHL 망 사업자가 임시 서브넷을 내줘 PHL 서버에 대역 외로 접근할 수 있었다.\n\npaste 와 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일 무료 이용으로 보상했다."},"trigger":{"en":"A layer 3 DDoS attack against SourceHut's PHL infrastructure that began at about 06:00 UTC on 10 January 2024 and broadened to more of the PHL subnet on 11 January.","ko":"2024년 1월 10일 06:00 UTC 무렵 SourceHut 의 PHL 인프라를 노린 layer 3 DDoS 가 시작됐다. 상위 망인 Cogent 가 이에 대응해 SourceHut 의 하위 AS 에 null route 를 걸었다."},"severity":"unknown","symptoms":["network-unreachable","service-unavailable"],"timeline":{"detected_after":"0m","resolved_after":"170h"},"date_kind":"incident","detection":{"en":"SourceHut's monitoring systems noticed that something was wrong and raised the alarm from about 06:00 UTC on 10 January.","ko":"06:00 UTC 무렵 모니터링 시스템이 이상을 알아채 경보를 울렸고, 운영팀은 곧 조사를 시작했다."},"components":["isp-network","bgp"],"root_cause":"dependency-failure","remediation":[{"text":{"en":"Got Cogent, through the colocation provider, to narrow the null route from the /24 to the targeted /32, which mostly restored service on 10 January","ko":"코로케이션 사업자가 Cogent 를 설득해 null route 를 /24 전체에서 DDoS 가 노리던 IP 주소 하나인 /32 로 좁혔다."}},{"text":{"en":"Moved DNS to an external DNS provider","ko":"외부 DNS 로 옮겼다."}},{"text":{"en":"Brought up a new primary database in AMS","ko":"새 주 데이터베이스를 띄웠다."}},{"text":{"en":"Restored backups from FRE to AMS","ko":"FRE 의 백업을 AMS 로 복원했다."}},{"text":{"en":"Applied the difference between production data and the last backups by hand","ko":"운영 데이터와 마지막 백업 사이의 차이를 손으로 반영했다."}},{"text":{"en":"Provisioned a new mail system and configured the mail services for it","ko":"새 메일 시스템을 갖추고 메일 서비스를 그 시스템에 맞게 설정했다."}},{"text":{"en":"Set up an OVH box that NATs traffic through OVH's DDoS-resistant network to the production subnet in AMS","ko":"OVH 서버를 두고 트래픽을 OVH 의 DDoS 방어 망을 거쳐 AMS 의 비공개 운영 서브넷으로 NAT 했다. 이 방식으로 종단 간 암호화를 지키면서 임의의 TCP 프로토콜도 서비스했다."}},{"text":{"en":"Used a temporary subnet from the PHL network provider for out-of-band access to the PHL servers","ko":"1월 12일 PHL 망 사업자가 임시 서브넷을 내줘 PHL 서버에 대역 외로 접근했고, 이것으로 대체 인프라를 더 빨리 갖췄다."}},{"text":{"en":"Served pages.sr.ht through an out-of-band link to PHL while its object storage was migrated","ko":"PHL 에서 AMS 로 객체 저장소를 옮기는 동안 pages.sr.ht 를 PHL 로 가는 대역 외 링크로 서비스했다. 성능에는 제약이 있었다."}},{"text":{"en":"Emailed pages.sr.ht users whose apex records pointed at the PHL subnet with instructions","ko":"pages.sr.ht 가 새 서브넷과 IP 주소로 옮겨 가면서, apex 레코드가 PHL 서브넷을 직접 가리키던 사용자에게 손으로 고치는 방법을 메일로 보냈다."}},{"text":{"en":"Ran build workers on dedicated bare-metal OVH servers","ko":"AMS 의 연산 용량이 모자라 builds.sr.ht 의 빌드 워커를 OVH 의 전용 베어메탈 서버에서 돌렸다."}}],"action_items":[{"text":{"en":"Provision a new standby database","ko":"새 대기 데이터베이스를 갖춘다. 사고 뒤 작업 가운데 이미 끝난 일이다."}},{"text":{"en":"Configure backups from AMS to FRE","ko":"AMS 에서 FRE 로 백업을 받도록 설정한다. 이미 끝난 일이다."}},{"text":{"en":"Install a new monitoring system","ko":"새 모니터링 시스템을 설치한다. 진행 중인 일이다."}},{"text":{"en":"Retire the PHL datacenter installation and ship its servers to AMS","ko":"PHL 데이터센터의 설비를 완전히 정리하고, PHL 의 서버를 포장해 AMS 로 보내 용량을 보탠다."}},{"text":{"en":"Move build service back onto SourceHut-operated servers once the build servers are shipped from PHL to AMS","ko":"몇 주 안에 빌드용 연산 서버를 PHL 에서 AMS 로 옮긴 뒤 빌드 서비스를 SourceHut 이 운영하는 인프라로 되돌린다."}},{"text":{"en":"Research and implement a way to run SourceHut in an on-premise Kubernetes cluster","ko":"SourceHut 을 온프레미스 쿠버네티스 클러스터에서 돌리는 방법을 연구해 구현한다. 내부 유지 보수 때 사용자가 겪는 중단을 줄이고 이런 사고에 더 잘 견디려는 것이다."}},{"text":{"en":"Plan a second production-ready datacenter to load balance against, able to take over full service in a datacenter outage","ko":"그 작업이 끝나면 두 번째 운영 데이터센터를 계획한다. 두 데이터센터가 함께 부하를 나누고, 한 데이터센터에 장애가 나면 다른 쪽이 전체 서비스를 넘겨받게 한다."}}],"contributing":["single-point-of-failure","limited-debug-access","backup-unverified"],"recurrence_of":null,"symptoms_text":{"en":"At about 06:00 UTC on 10 January 2024, SourceHut's monitoring raised the alarm as a layer 3 DDoS attack hit its infrastructure in the PHL datacenter, and at about 09:00 UTC SourceHut lost all access to its PHL network. PHL was the primary datacenter, and the network became unreachable for SourceHut staff and the general public alike.\n\nThe PHL network was unreachable because Cogent, one of the two carriers through which the colocation provider routed SourceHut's subnet, announced null routes for SourceHut's downstream AS. SourceHut could not mitigate a layer 3 attack without its network provider, but the ticketing portal it used to page the provider had been deprecated after the provider was acquired twice, and SourceHut's account had not been moved to the new system. The provider could not be reached until its office hours began at 14:00 UTC.\n\nOnce reached, the provider got Cogent to narrow the null route from SourceHut's entire /24 to the single /32 address being targeted, and service was mostly back by 18:00 UTC. At about 06:30 UTC the next morning the attack escalated to other parts of the PHL subnet, the colocation provider null-routed the subnet again, and it stayed unreachable from then on.\n\nThe attacker targeted SourceHut specifically and followed it, moving the attack to new infrastructure as it was being set up. When SourceHut first NAT'd all traffic from an OVH box through to AMS, the attack on the OVH infrastructure was briefly forwarded to AMS before OVH's mitigations started, which made the new OVH account look like the source of an outgoing DDoS and took some work to resolve with OVH.","ko":"2024년 1월 10일 06:00 UTC 무렵 모니터링 시스템이 SourceHut 의 PHL 인프라에 이상이 있다고 경보를 울렸다. 09:00 UTC 무렵에는 PHL 망에 아예 닿을 수 없게 됐다.\n\nCogent 가 SourceHut 의 하위 AS 에 null route 를 걸면서 PHL 망은 SourceHut 직원에게도, 일반 사용자에게도 닿지 않았다.\n\n운영팀은 코로케이션 사업자에게 연락하려 했지만 닿지 않았다. 사업자는 몇 년 사이 두 번 인수됐고, 운영팀이 쓰던 티켓 포털은 폐기됐으며 SourceHut 계정은 새 시스템으로 옮겨지지 않았다. 사업자에게는 14:00 UTC 에 업무 시간이 시작되고서야 닿았다.\n\nnull route 가 /24 전체에서 공격받던 IP 주소 하나인 /32 로 좁혀지자 18:00 UTC 무렵 서비스가 대부분 돌아왔다. 다음 날 06:30 UTC 무렵 공격이 PHL 서브넷의 다른 부분까지 넓어지자 코로케이션 사업자가 서브넷을 다시 null route 했고, 그 뒤로 서브넷에는 계속 닿지 않았다."},"updated_at":"2026-11-14T12:34:15.360742Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0509","org_slug":"sourcehut"}