사례3건

3건 중 1~3번째

1. IL-0394 Cloudflare Miami 라우터가 내부 IPv6 경로를 BGP 피어와 트랜짓 제공자에게 유출해 25분 동안 백본이 혼잡해지고 트래픽이 드롭됐다

   Cloudflare2026

   증상

   2026년 1월 22일 20:25 UTC 부터 Cloudflare 의 Miami edge 라우터 하나가 BGP 트랜짓 제공자와 피어에게 예상하지 않은 경로를 광고했다. 20:40 UTC 에 네트워크 팀이 Miami 에서 나간 의도하지 않은 경로 광고를 조사하기 시작했다.

   패킷 손실지연 시간 증가

   촉발

   20:25 UTC 에 정책 자동화 플랫폼으로 Bogotá 데이터센터용 BGP 광고를 Miami 에서 빼는 변경을 내보냈다. 이 변경이 Miami 라우터의 여러 BGP export 정책에서 prefix-list 6-BOG04-SITE-LOCAL 줄만 지워, 남은 정책이 route-type internal 인 경로를 모두 받아들여 밖으로 광고하게 됐다.

   원인

   설정 변경

   구성 요소

   BGP 라우팅백본망

   기여 요인

   설정 테스트 부재

   감지

   20:40 UTC 에 네트워크 팀이 Miami 에서 나간 의도하지 않은 경로 광고를 조사하기 시작했고, 20:44 UTC 에 대응을 조율하려고 인시던트를 열었다.

   조치

   • 20:50 UTC 에 네트워크 운영자가 잘못된 설정 변경을 손으로 되돌렸다. 이때 영향이 끝났다.
   • 자동화가 같은 라우터에서 다시 돌지 않도록 그 라우터의 자동화를 멈췄다.
   • 21:47 UTC 에 유출을 촉발한 변경을 네트워크 자동화 코드 저장소에서 되돌렸다.
   • 22:07 UTC 에 운영자가 라우팅 정책 버그 없이 자동화가 다시 돌 수 있음을 확인했고, 22:40 UTC 에 Miami 라우터의 자동화를 다시 켰다.

   후속 조치

   • 경로 유출을 일으킨 라우팅 정책 자동화의 결함을 고치고, 이 결함과 비슷한 결함을 바로 막는다.
   • 외부 export 정책에서 제공자와 피어에게서 받은 경로를 명시적으로 거부하는 BGP community 기반 안전장치를 라우팅 정책에 더한다.
   • 비어 있거나 잘못된 정책 term 을 찾는 라우팅 정책 자동 평가를 CI/CD 파이프라인에 넣는다.
   • 네트워크 설정 문제와 자동 변경의 나쁜 영향을 더 일찍 알아채도록 개선한다.
   • RFC9234 의 BGP role 과 Only-to-Customer Attribute 를 배포하기에 앞서 라우팅 장비 공급사의 구현을 검증한다. BGP role 과 Only-to-Customer Attribute 는 라우팅 정책과 상관없이 자기 AS 에서 생기는 경로 유출을 막는 유일한 방법이다.
   • 비정상적인 AS path 를 가진 경로를 네트워크가 자동으로 거부할 수 있게 하는 RPKI Autonomous System Provider Authorization, 곧 ASPA 를 장기적으로 채택하도록 권한다.

   교훈

   Cloudflare 는 이번 사고로 경로 유출을 실수로 일으키기가 얼마나 쉬운지 직접 겪었다고 적었다. 경로 유출을 막으려면 여러 갈래의 대책이 필요하고, 라우팅 정책 설정과 자동화에서 단기와 장기로 고칠 곳을 여럿 찾았다고 했다.

   사례 보기
2. IL-0283 Cloudflare 네트워크 전체에서 코어 프록시가 Bot Management 피처 파일을 읽다 실패해 사이트 방문자들이 HTTP 5xx 오류 페이지를 받았다

   Cloudflare2025

   증상

   11:20 UTC 부터 Cloudflare 네트워크가 내보내는 HTTP 5xx 오류가 치솟았다. 고객 사이트를 찾은 인터넷 사용자들은 Cloudflare 네트워크 안에서 실패했다는 오류 페이지를 봤다.

   오류율 상승서비스 중단지연 시간 증가응답 품질 저하

   촉발

   11:05 UTC 에 Cloudflare 는 ClickHouse 사용자들이 암묵적으로 갖고 있던 r0 데이터베이스 하위 테이블 접근 권한을 명시적으로 주는 변경을 배포했다. Bot Management 피처 파일을 만드는 쿼리는 데이터베이스 이름으로 거르지 않았고, 이 변경 뒤 쿼리 결과에 중복 행이 섞이기 시작했다.

   원인

   설정 변경

   구성 요소

   데이터베이스CDN 과 엣지 네트워크

   기여 요인

   미검증 가정부분 배포단계적 배포 부재설정 테스트 부재장애 중첩재시도 폭주

   감지

   11:31 UTC 에 첫 자동 테스트가 문제를 감지했고, 11:32 에 수동 조사가 시작됐으며, 11:35 에 장애 대응 통화가 열렸다.

   조치

   • 13:05 UTC 에 Workers KV 와 Cloudflare Access 를 내부 우회 경로로 돌려 이전 버전의 코어 프록시를 쓰게 했다. 이전 버전에도 같은 문제가 있었지만 영향이 작았다.
   • 14:24 UTC 에 새 Bot Management 설정 파일의 자동 배포를 멈췄다.
   • 알려진 정상 피처 파일을 피처 파일 배포 큐에 손으로 넣었다.
   • 코어 프록시를 강제로 재시작했다. 14:30 UTC 에 주된 영향이 풀렸다.
   • 쌓인 로그인 시도와 재시도로 느려진 대시보드를 컨트롤 플레인 동시성을 늘려 15:30 UTC 무렵 되살렸다.
   • 나쁜 상태에 빠진 나머지 서비스들을 재시작했고, 17:06 UTC 에 5xx 오류량이 평소로 돌아왔다.

   후속 조치

   • Cloudflare 가 직접 만든 설정 파일도 사용자 입력처럼 엄격하게 검증한 뒤 받아들인다.
   • 기능을 네트워크 전체에서 끌 수 있는 킬 스위치를 더 늘린다.
   • 코어 덤프나 다른 오류 보고가 시스템 자원을 다 써 버리지 못하게 한다.
   • 모든 코어 프록시 모듈이 오류가 났을 때 어떻게 실패하는지 검토한다.

   사례 보기
3. IL-0225 라우터 명령 하나가 Microsoft WAN 의 모든 라우터에 토폴로지를 다시 계산하게 해 전 세계 Azure 네트워크 연결이 불안정해졌다.

   Microsoft Azure2023

   증상

   2023-01-25 07:08 UTC 부터 Azure 리전의 리소스와 Microsoft 365, Power Platform 같은 Microsoft 서비스에 연결할 때 네트워크 지연이 길어지거나 타임아웃이 났다. 모니터링은 07:11 UTC 부터 DNS 와 WAN 문제를 잡았고, 명령을 실행하고 5분 안에 당직 엔지니어에게 알림이 갔다.

   지연 시간 증가간헐적 타임아웃간헐적 연결 실패패킷 손실네트워크 도달 불가

   촉발

   07:08 UTC 에 마드리드에서 전 세계 WAN 에 용량을 더하던 엔지니어가, 다시 검증하지 않은 표준 운영 절차대로 IGP 데이터베이스를 비우는 명령을 실행했다. 이 명령은 한 제조사의 라우터에서는 로컬 라우터에 그치지 않고 IGP 로 이어진 모든 라우터에 IGP 토폴로지 데이터베이스를 다시 계산하라고 지시했다.

   원인

   설정 변경

   구성 요소

   백본망내부 라우팅BGP 라우팅

   기여 요인

   설정 테스트 부재미검증 가정과도한 영향 범위수동 조치 악화

   감지

   모니터링이 07:11 UTC 부터 DNS 와 WAN 문제를 잡았고, 명령을 실행하고 5분 안에 당직 엔지니어에게 알림이 갔다. 변경하던 엔지니어는 바뀐 절차 때문에 이 알림을 전달받지 못했다. 팀은 최근 변경을 모두 살펴 08:20 UTC 에 문제의 명령을 찾았다.

   조치

   • WAN 라우팅이 수렴한 뒤에도 남은 패킷 손실을 없애려고, 사고 중 멈춰 있던 비정상 장비 제거 시스템과 트래픽 엔지니어링 시스템을 손으로 다시 시작했다. 12:43 UTC 에 복구를 마쳤다.

   후속 조치

   • 세 제조사 전부와 모든 WAN 라우터 역할을 대상으로, 넓은 영향을 줄 수 있는 비슷한 명령을 감사하고 막는다. 2023년 2월에 끝낼 예정이다.
   • 승인된 자동화와 승인된 비상 접근인 break glass 작업, 승인되지 않은 장비 작업을 실시간으로 보여 줘, 당직 엔지니어가 누가 네트워크 장비에서 무엇을 바꾸는지 볼 수 있게 한다. 2023년 2월에 끝낼 예정이다.
   • 정기적인 필수 운영 교육과 모든 표준 운영 절차를 지키겠다는 확인 절차를 도입해 절차를 계속 개선한다. 2023년 2월에 끝낼 예정이다.
   • 아직 검증을 기다리는 표준 운영 절차를 모두 감사하고, 엔지니어 의견을 받아 30일 안에 Change Advisory Board 검토를 우선 받게 한다. 2023년 4월에 끝낼 예정이다.

   사례 보기

원인별1