route-leak

2 개의 포스트

ASPA: 인터넷 라 (새 탭에서 열림)

인터넷 라우팅의 핵심 프로토콜인 BGP는 설정 오류나 악의적인 공격으로 인해 트래픽이 엉뚱한 경로로 흐르는 '경로 리크(Route Leak)' 취약점을 안고 있습니다. 이를 해결하기 위해 기존의 목적지 검증 기술인 ROA를 넘어, 전체 이동 경로를 암호화 기술로 보호하는 새로운 표준인 ASPA(Autonomous System Provider Authorization)가 도입되고 있습니다. 클라우드플레어는 이러한 흐름에 발맞춰 ASPA 채택 현황을 실시간으로 추적할 수 있는 모니터링 기능을 Radar 서비스에 추가하며 더욱 안전한 인터넷 환경 구축을 지원합니다. ### ASPA의 개념과 필요성 * **기존 RPKI(ROA)의 한계**: 현재 사용되는 ROA(Route Origin Authorization)는 특정 IP 주소를 선언할 권한이 있는 AS(자율 시스템)가 누구인지, 즉 '목적지'만 확인하며 트래픽이 거치는 중간 경로는 검증하지 못합니다. * **경로 검증의 도입**: ASPA는 각 AS가 자신의 상위 프로바이더(Upstream Provider) 목록을 RPKI 시스템에 공식적으로 등록하게 함으로써, 데이터가 승인된 네트워크 체인을 통해서만 이동하는지 확인합니다. * **디지털 인증 기반**: ASPA 레코드는 일종의 인증서 역할을 하여, 수신 측 네트워크가 BGP 내의 AS_PATH를 보고 해당 경로가 사전에 정의된 상위 공급자 관계와 일치하는지 대조할 수 있게 합니다. ### "Valley-Free" 원리를 이용한 리크 탐지 * **상향 및 하향 램프 검증**: 인터넷 라우팅은 일반적으로 고객에서 프로바이더로 올라갔다가(Up-Ramp), 다시 목적지 고객으로 내려가는(Down-Ramp) 산 모양의 계층 구조를 가집니다. * **경로 일관성 확인**: ASPA는 경로의 양단에서 검증을 시작합니다. 출발지부터 상위 프로바이더로 이어지는 체인과 목적지부터 거꾸로 올라오는 체인이 정상적으로 만나는지 확인하여 경로의 유효성을 판단합니다. * **계곡(Valley) 현상 방지**: 고객 네트워크가 두 대형 프로바이더 사이에서 원치 않는 중계 역할을 할 때 발생하는 '경로 리크'는 ASPA 검증 과정에서 두 체인이 연결되지 않는 '단절'로 나타나며, 시스템은 이를 즉시 차단 대상으로 식별합니다. ### 위조된 근원지 하이재킹 방어 * **공격 차단**: 공격자가 실제 목적지 AS인 것처럼 속이면서 가짜 BGP 경로를 생성하는 '위조된 근원지 하이재킹(Forged-origin hijack)' 상황에서 ASPA는 강력한 방어 수단이 됩니다. * **관계의 진실성**: 공격자가 경로 상에 존재하더라도 피해 네트워크가 사전에 정의한 '승인된 프로바이더' 목록에 공격자가 포함되어 있지 않다면, 해당 경로는 유효하지 않은 것으로 간주되어 거부됩니다. * **기술적 한계**: 다만, 프로바이더가 자신의 고객에게 직접 가짜 경로를 광고하는 특수한 형태의 위조 공격 등은 ASPA만으로는 완벽하게 방어하기 어려운 영역으로 남아 있습니다. 인터넷 보안 강화를 위해 네트워크 운영자는 자신의 AS에 대한 ASPA 레코드를 발행하고, 클라우드플레어 Radar와 같은 도구를 통해 전 세계적인 ASPA 채택 추이를 주시하며 라우팅 보안 표준을 준수할 것을 권장합니다.

2026년 1월 (새 탭에서 열림)

2026년 1월 22일, Cloudflare 마이애미 데이터 센터에서 자동화된 라우팅 정책 설정 오류로 인해 약 25분간 IPv6 BGP 경로 유출(Route Leak) 사고가 발생했습니다. 특정 접두사 목록(Prefix-list)을 제거하는 과정에서 정책 필터가 의도치 않게 모든 내부 경로를 허용하게 되었고, 이로 인해 전 세계 IPv6 트래픽이 마이애미로 잘못 유도되어 네트워크 혼잡과 서비스 지연이 초래되었습니다. 이 사고는 자동화 코드가 생성한 구성 파일의 논리적 허점으로 인해 발생했으며, 운영진의 수동 복구와 자동화 일시 중지를 통해 해결되었습니다. ### BGP 경로 유출의 메커니즘과 영향 * **경로 유출의 정의**: 네트워크(Autonomous System, AS)가 원래 전달해서는 안 될 트래픽을 자신에게 보내도록 인터넷 경로 정보를 잘못 광고하는 현상을 의미합니다. * **위반 사항**: 이번 사고는 RFC 7908에 정의된 유형 3 및 유형 4 유출의 혼합 형태로, 피어(Peer)나 상위 제공자(Provider)로부터 받은 경로를 다시 다른 피어나 제공자에게 재분배함으로써 '계곡 없는 라우팅(Valley-free routing)' 원칙을 위반했습니다. * **네트워크 충격**: 마이애미 데이터 센터의 백본 인프라에 트래픽이 집중되면서 혼잡이 발생했고, Cloudflare 서비스뿐만 아니라 외부 네트워크의 트래픽도 마이애미로 유입되었다가 방화벽 필터에 의해 차단되거나 높은 지연 시간을 겪었습니다. ### 설정 오류의 기술적 원인: 과도하게 허용된 정책 * **변경 목적**: 보고타(Bogotá) 데이터 센터로 향하던 IPv6 트래픽을 마이애미를 거치지 않게 하기 위해, 정책 자동화 플랫폼을 통해 기존의 특정 접두사 목록(`6-BOG04-SITE-LOCAL`)을 제거하려고 했습니다. * **JunOS 동작 특성**: JunOS 및 JunOS EVO 운영체제에서 `from route-type internal` 조건은 모든 내부 BGP(iBGP) 경로와 일치합니다. * **논리적 결함**: 특정 접두사 필터가 삭제되자, 해당 정책 구문은 "모든 내부 경로를 수락하고 외부로 광고하라"는 광범위한 규칙으로 변질되었습니다. 이로 인해 마이애미 라우터는 수천 개의 내부 경로를 Telia, Cogent, GTT와 같은 외부 피어와 제공자에게 대량으로 전송하게 되었습니다. ### 사고 대응 타임라인 * **20:25 UTC**: 마이애미 에지 라우터에서 자동화 도구가 실행되어 잘못된 설정이 적용되었고, 즉시 경로 유출과 서비스 영향이 시작되었습니다. * **20:40 UTC**: 네트워크 팀이 의도치 않은 경로 광고를 감지하고 조사를 시작했으며, 4분 뒤 공식적인 장애 대응 프로세스가 가동되었습니다. * **20:50 UTC**: 네트워크 운영자가 문제가 된 설정을 수동으로 되돌리고 해당 라우터의 자동화를 일시 중지함으로써 경로 유출 상황이 종료되었습니다. * **22:40 UTC**: 자동화 코드 저장소의 버그를 수정한 후, 마이애미 라우터의 자동화 기능을 다시 활성화하여 정상 상태로 복구했습니다. ### 기술적 교훈 및 추천 사항 * **정책 검증 강화**: 라우팅 정책을 자동 생성할 때, 특정 필터(Prefix-list 등)가 제거된 결과가 '기본 허용(Default Accept)' 상태가 되지 않도록 방어적인 로직을 설계해야 합니다. * **운영체제 특성 이해**: JunOS의 `route-type internal`과 같이 벤더별로 상이하게 동작할 수 있는 매칭 조건을 사용할 때는 예상치 못한 경로 광고를 막기 위한 추가적인 안전장치(Safety-net)를 마련해야 합니다. * **단계적 배포**: 대규모 인프라 변경 시 자동화 도구가 전체 라우터에 동시에 적용되지 않도록 카나리(Canary) 배포나 단계적 적용을 통해 영향 범위를 최소화하는 것이 권장됩니다.