소개
2024년 6월 27일, 전 세계에 걸쳐 소수의 사용자들이 1.1.1.1에 연결할 수 없거나 성능이 저하되었다는 사실을 알았을 수도 있습니다. 그 근본 원인에는 BGP(경계 게이트웨이 프로토콜) 하이재킹과 라우팅 유출이 혼합되어 있었습니다.Cloudflare는 라우팅 시작점 유효성 검사(ROV)를 위한 리소스 공개 키 인프라(RPKI)의 얼리어답터였습니다. IP 접두사 소유자는 RPKI를 통해 소유권 정보를 안전하게 저장하고 공유할 수 있으며, 다른 사업자는 수신된 BGP 경로를 라우팅 시작점 유효성 검사(ROA) 형태에 저장된 경로와 비교하여 BGP 발표를 확인할 수 있습니다. 네트워크에서 라우팅 시작점 유효성 검사를 시행하고 접두사가 ROA를 통해 서명되면 BGP 하이재킹의 영향이 크게 제한됩니다. 지난 몇 년 동안 RPKI 채택이 증가했고 사고 중 1.1.1.0/24가 서명된 리소스임에도 불구하고 ELETRONET SA(AS267613)에서 1.1.1.1/32가 생성되었으며, 최소 하나의 계층 1 공급자를 포함한 여러 네트워크에서 채택되었습니다. 이 계층 1 공급자는 1.1.1.1/32를 블랙홀 경로로 받아들였습니다. 이로 인해 70개국 300여 개의 네트워크에서 DNS 확인자 주소에 즉시 연결할 수 없게 되었지만, 전체 사용자 비율에 미치는 영향은 매우 낮았고(예: 영국과 독일의 사용자는 1% 미만) 일부 국가에서는 사용자가 영향을 받은 것을 알아차리지 못했습니다.
라우팅 유출은 Cloudflare에서 작성하고 이야기한 적이 있는 문제이며, 불행히도 오늘날 광범위한 배포에는 공급자별 IRR(Internet Routing Registry) 접두사 목록 필터링과 같은 최선을 다하는 보호 장치밖에 없습니다. 1.1.1.1/32 하이재킹과 같은 기간에, 1.1.1.0/24가 Nova Rede de Telecomunicações Ltda(AS262504)에 의해 업스트림으로 실수로 유출되었습니다. 이 유출은 Peer-1 Global Internet Exchange(AS1031)에 의해 추가로 널리 전파되었으며, 이로 인해 고객들이 사고 중에 느끼는 영향에도 기여했습니다.
1.1.1.1 사용자가 겪었던 영향에 대해 사과드리며, 해당 서비스의 작동을 매우 엄중하게 생각하고 있습니다. 영향의 근본 원인은 Cloudflare 외부에 있었지만, 우리는 더 빠른 응답 시간을 제공하기 위해 탐지 방법을 지속적으로 개선할 것이며 인터넷 커뮤니티 내에서 우리의 입장을 활용하여 BGP에 대한 라우팅 시작점 유효성 검사(ROV) 및 자율 시스템 공급자 승인(ASPA) 개체와 같은 RPKI 기반 하이재킹 및 유출 방지 메커니즘의 채택을 더욱 장려할 것입니다.
배경
Cloudflare에서는 2018년에 1.1.1.1 공용 DNS 리졸버 서비스를 도입했습니다. 발표 이후 1.1.1.1은 누구나 무료로 사용할 수 있는 가장 인기 있는 확인자 IP 주소 중 하나가 되었습니다. 인기와 쉽게 인식되는 IP 주소와 함께 몇 가지 운영상의 어려움이 따릅니다. 이러한 어려움은 연구실의 네트워크에서 또는 테스트 IP 주소로 1.1.1.1을 역사적으로 사용했기 때문에 예상치 못한 트래픽이 남아 있거나 블랙홀 라우팅 동작이 발생했기 때문에 발생합니다. 이 때문에 Cloudflare는 BGP의 잘못된 라우팅 트래픽의 영향을 처리하는 데 익숙하며, 그 중 두 가지를 아래에서 다룹니다.
BGP 하이재킹
일부 어려움은 1.1.1.1의 잠재적인 라우팅 하이재킹에서 비롯됩니다. 예를 들어, 일부 가상의 FooBar Networks가 라우터 중 하나에 1.1.1.1/32를 할당하고 내부 네트워크 내에서 이 접두사를 공유하는 경우 고객은 1.1.1.1 DNS 서비스로 라우팅하는 데 어려움을 겪게 됩니다. 즉각적인 네트워크 외부에 1.1.1.1/32 접두사를 알리는 경우 영향은 훨씬 더 커질 수 있습니다. Cloudflare에서 발표한 1.1.1.0/24 BGP 대신 1.1.1.1/32가 선택되는 이유는 Longest Prefix Matching(LPM) 때문입니다. 라우팅 테이블의 많은 접두사는 1.1.1.0/24, 1.1.1.0/29 및 1.1.1.1/32와 같이 1.1.1.1 주소와 일치할 수 있지만 1.1.1.1/32는 '가장 긴 일치'로 간주됩니다. LPM 알고리즘은 1.1.1.1 주소와 일치하면서 동일한 비트 수가 가장 많고 서브넷 마스크가 가장 길기 때문입니다. 간단히 말해서 1.1.1.1/32를 1.1.1.1에서 사용할 수 있는 '가장 구체적인' 경로라고 부릅니다.
1.1.1.1로 향하는 트래픽이 Anycast를 통해 Cloudflare로 라우팅되어 전 세계 서버 중 하나에 착륙하는 대신, FooBar 네트워크 내의 장치 어딘가에 착륙하여, 그곳에서 1.1.1.1이 종료되고 클라이언트에 정상적인 응답이 제공되지 못하게 됩니다. 이는 1.1.1.1에 대한 요청 하이재킹으로 간주되며, FooBar 네트워크 내의 네트워크 운영자가 의도적으로 또는 실수로 수행한 것으로 간주됩니다.
BGP 라우팅 유출
1.1.1.1에서 때때로 직면하는 영향의 또 다른 원인은 BGP 라우팅 유출입니다. 라우팅 유출은 BGP 발표의 관점에서 네트워크가 업스트림 공급자가 되어서는 안 되는 네트워크의 업스트림이 될 때 발생합니다.
다음은 고객이 한 공급자에게서 알게 된 경로를 다른 공급자에게 전달하여 유형 1 유출(RFC7908에 정의됨)이 발생하는 라우팅 유출의 예입니다.
Default-Free Zone(DFZ) 내의 충분한 네트워크에서 라우팅 유출이 허용되는 경우, 이는 잘못된 경로를 따라 트래픽을 전달하는 데 널리 사용될 수 있습니다. 이로 인해 현재 끌어오고 있는 글로벌 트래픽의 양에 대비하지 못하기 때문에 접두사를 유출하는 네트워크가 과부하되는 경우가 많습니다. 저희는 펜실베이니아의 한 공급자가 일반적으로 트래픽을 전송하지 않았을 글로벌 목적지로 트래픽을 유도했을 때 인터넷의 상당 부분을 중단시킨 대규모 라우팅 유출에 대해 글을 작성한 적이 있습니다. Cloudflare가 전 세계적으로 13,000여 개의 네트워크와 상호 연결되어 있더라도 유출된 경로에 할당된 BGP 로컬 기본 설정은 네트워크가 Cloudflare에서 직접 수신한 경로보다 높을 수 있습니다. 이는 비생산적인 것 같지만, 불행하게도 이런 일이 일어날 수 있습니다.
이런 일이 발생하는 이유를 설명하려면 BGP를 인터넷의 라우팅 프로토콜과 함께 비즈니스 정책 엔진으로 생각하는 것이 도움이 됩니다. 전송 공급자에게는 데이터 전송 대가를 지불하는 고객이 있으므로 논리적으로 해당 공급자는 사설 또는 인터넷 익스체인지(IX) 피어링보다 높은 BGP local-preference를 할당하므로 유료 연결이 가장 많이 활용됩니다. local-preference를 트래픽을 보낼 발신 연결의 우선 순위에 영향을 미치는 방법이라고 생각하면 됩니다. 네트워크마다 인터넷 익스체인지(IX) 수신 경로보다 사설 네트워크 상호 연결(PNI)을 선호하도록 선택할 수도 있습니다. 그 이유 중 하나는 안정성 때문인데, 프라이빗 연결은 중간에 걱정할 타사 관리 패브릭이 없는 두 네트워크 간의 지점 간 연결로 볼 수 있기 때문입니다. 또 다른 이유는 비용 효율성 때문일 수 있습니다. 마치 라우터 포트를 할당하고 자신과 다른 피어 사이의 교차 연결을 구매하는 데 어려움을 겪은 것처럼 이를 활용하여 최고의 투자 수익을 얻고자 하는 것처럼 말입니다.
BGP 하이재킹과 라우팅 유출 모두 1.1.1.1뿐만 아니라 인터넷의 모든 IP 및 접두사에서도 발생할 수 있습니다. 그러나 앞서 언급한 바와 같이, 1.1.1.1은 인식하기 쉬우면서 과거에 남용된 주소이므로 다른 IP 리소스보다 우발적인 하이재킹이나 유출이 발생하기 쉽습니다.
2024년 6월 27일에 발생한 Cloudflare 1.1.1.1 사고를 통해 Cloudflare에서는 BGP 하이재킹과 라우팅 유출의 조합으로 인한 영향에 대처해야 하게 되었습니다.
사고 타임라인 및 영향
모든 타임스탬프는 UTC 기준입니다.
2024-06-27 18:51:00 AS267613(Eletronet)이 피어, 공급자, 고객에게 1.1.1.1/32를 발표하기 시작. 1.1.1.1/32는 AS267613 원본 AS로 발표됨
2024-06-27 18:52:00 AS262504 (Nova), 1.1.1.0/24 유출. AS267613으로부터도 수신, AS 경로 '1031 262504 267613 133335'를 사용하여 AS1031(PEER 1 글로벌 인터넷 익스체인지) 업스트림
2024-06-27 18:52:00 AS1031(Nova의 업스트림)에서 1.1.1.0/24를 다양한 인터넷 익스체인지 피어 및 라우트 서버로 전파하여 유출의 영향력 확대
2024-06-27 18:52:00 계층 1 공급자가 AS267613으로부터 RTBH(원격 트리거 블랙홀) 경로로 발표된 1.1.1.1/32를 수신하여, 모든 계층 1 고객에게 트래픽 블랙홀이 초래됨
2024-06-27 20:03:00 Cloudflare에서 다양한 국가로부터 1.1.1.1 연결 문제와 관련하여 내부 사고를 제기
2024-06-27 20:08:00 Cloudflare에서 1.1.1.0/24로의 트래픽을 수신하는 AS 267613이 있는 파트너 피어링 위치를 비활성화
2024-06-27 20:08:00 Cloudflare 팀에서 피어링 파트너 AS267613을 사고에 참여시킴
2024-06-27 20:10:00 AS262504에서 AS1031에 의해 재배포되는 새로운 AS 경로 "262504 53072 7738 13335"를 사용하여 1.1.1.0/24를 유출. 이 경로를 따라 트래픽이 Cloudflare로 성공적으로 전달되지만, 영향을 받는 클라이언트의 대기 시간이 길어짐.
2024-06-27 20:17:00 Cloudflare에서 업스트림 공급자에 대한 1.1.1.0/24의 라우팅 유출과 관련하여 AS262504를 참여시킴
2024-06-27 21:56:00 Cloudflare 엔지니어가 브라질이 아닌 여러 소스로부터 1.1.1.0/24용 트래픽을 수신하는 AS267613의 두 번째 피어링 포인트를 비활성화함
2024-06-27 22:16:00 AS262504에서 1.1.1.0/24가 다시 유출되어 상파울루의 AS267613과 피어링하는 Cloudflare로 일부 트래픽이 유입됨. 결과적으로 일부 1.1.1.1 요청은 더 높은 대기 시간으로 반환되지만, 1.1.1.1/32 하이재킹 및 트래픽 블랙홀링은 해결된 것으로 보임
2024-06-28 02:28:00 AS262504 1.1.1.0/24의 라우팅 유출 완전 해결
고객에 대한 영향은 두 가지 중 하나로 나타났습니다. 1.1.1.1에 전혀 도달할 수 없거나, 1.1.1.1에 도달할 수 있지만, 요청당 대기 시간이 길었습니다.
AS267613이 네트워크 어딘가에서 1.1.1.1/32 주소를 하이재킹하고 있었으므로 자율 시스템의 일부 장치에서 많은 요청이 실패했습니다. 사고가 발생하는 동안 대기 시간이 길기는 했지만, 1.1.1.1에 대한 요청을 Cloudflare 데이터 센터로 성공적으로 라우팅하는 간헐적인 기간 또는 플랩이 있었습니다.
사고 당시 독일과 미국에서 1.1.1.1에 대한 영향을 받은 트래픽의 출처인 두 국가를 살펴보면 다음과 같습니다.
사용자 출처 국가:
전반적으로 이는 출처 국가별 총 요청의 비교적 적은 양을 나타낼 수 있지만, 일반적으로 1.1.1.1의 경우 미국이나 독일에서 브라질로 라우팅하는 요청은 전혀 없다는 점을 유의하세요.
Cloudflare 데이터 센터 도시:
그래프를 보면, 1.1.1.1에 대한 요청은 브라질 데이터 센터에 도착했습니다. 이 사이의 격차는 AS267613 이전에 또는 AS267613 내에서 1.1.1.1 요청이 블랙홀링 되었을 때이며, 급증 자체는 트래픽이 요청 및 응답에 대해 긴 대기 시간을 유지하면서 Cloudflare로 전송될 때입니다. AS267613을 사용하여 Cloudflare 피어링 위치로 성공적으로 전송된 트래픽의 짧은 스파이크는 네트워크 내에서 1.1.1.1/32 경로 플랩핑으로 설명될 수 있으며, 때때로 트래픽이 중간 경로 어딘가에 떨어지지 않고 Cloudflare를 통과하도록 허용합니다.
오류에 대한 기술적 설명 및 발생한 방식
일반적으로 사용자의 1.1.1.1에 대한 요청은 BGP Anycast를 통해 가장 가까운 데이터 센터로 라우팅됩니다. 사고 당시 AS267613(Eletronet)은 1.1.1.1/32를 피어에게 알렸고 AS262504는 1.1.1.0/24 업스트림을 유출하여 여러 아이볼 네트워크에 대한 BGP Anycast의 정상적인 경로가 크게 바뀌었습니다.
공개 라우팅 수집기와 단품 도구를 통해 악성 BGP 업데이트를 검색할 수 있습니다.
위에서 AS398465 및 AS13760에서는 영향이 시작될 무렵 AS267613에서 1.1.1.1/32를 받았다고 경로 보기 수집기에 보고했습니다. 일반적으로 Default-Free-Zone(DFZ)에서 허용되는 가장 긴 IPv4 접두사는 /24이지만 이 경우 전달을 위해 AS267613의 1.1.1.1/32 경로를 사용하는 여러 네트워크를 관찰했는데 이는 트래픽 블랙홀링으로 명백해졌습니다. Cloudflare Point of Presence(POP)에 도착하지 않은 것입니다. AS267613에 의한 1.1.1.1/32의 기원은 BGP 경로 하이재킹입니다. 라우팅 시작점 인증(ROA)이 최대 접두사 길이가 /24인 원본 AS13335(Cloudflare)에 대해서만 서명되었음에도 불구하고 그들은 원본 AS267613의 접두사를 발표했습니다.
Cloudflare에서sms 자체 BMP(BGP 모니터링 프로토콜) 데이터를 살펴보면서 1.1.1.1/32에 대한 BGP 업데이트도 확인했습니다. 최소한 두 개의 서로 다른 경로 서버에서 BGP를 통해 자체 1.1.1.1/32 공지를 받았습니다. 다행히 Cloudflare에서는 잘못된 AS 원본 및 접두사 길이로 인해 가져올 때 이러한 경로를 RPKI Invalid 및 DFZ Invalid로 거부합니다. BMP 데이터 표시는 정책 이전입니다. 이는 경로를 거부했지만 피어링 세션을 통해 BGP 업데이트를 수신하는 위치를 볼 수 있다는 것을 의미합니다.
따라서 여러 네트워크에서는 글로벌 라우팅 테이블에 존재해서는 안 되는 접두사를 허용할 뿐만 아니라 RPKI(Resource Public Key Infrastructure) 잘못된 경로도 허용합니다. 설상가상으로 한 Tier-1 전송 제공업체에서는 1.1.1.1/32 알림을 AS267613의 RTBH(원격 트리거 블랙홀) 경로로 수락하여 일반적으로 Cloudflare로 라우팅되는 에지의 모든 트래픽을 삭제했습니다. 1.1.1.1로의 라우팅에서 이 특정 Tier-1 공급자를 활용하는 네트워크는 사고 중에 IP 주소에 도달할 수 없었기 때문에 이것만으로도 광범위한 영향이 미쳤습니다.원격 트리거 블랙홀링에 익숙하지 않은 분들을 위해 설명하자면, 이는 네트워크 내에서 트래픽을 삭제하려는 대상 집합을 공급자에게 알리는 방법입니다. 이는 DDoS 공격에 맞서 싸우는 노골적인 방법으로 존재합니다. 특정 IP 또는 접두사에서 공격을 받는 경우 업스트림 공급자에게 네트워크 포트에 도달하기 전에 해당 대상 IP 주소 또는 접두사로 향하는 모든 트래픽을 흡수하도록 지시할 수 있습니다. 이번 사건 중 문제는 AS267613이 블랙홀 1.1.1.1/32에 대해 승인되지 않았다는 것입니다. Cloudflare만이 AS13335로 향하는 트래픽을 폐기하기 위해 RTBH를 활용할 수 있는 유일한 권리를 가져야 하는데, 이는 실제로 우리가 결코 하지 않을 일입니다.
monocle search --start-ts 2024-06-27T18:51:00Z --end-ts 2024-06-27T18:55:00Z --prefix '1.1.1.1/32'
A|1719514377.130203|206.126.236.209|398465|1.1.1.1/32|398465 267613|IGP|206.126.236.209|0|0||false|||route-views.eqix
–
A|1719514377.681932|206.82.104.185|398465|1.1.1.1/32|398465 267613|IGP|206.82.104.185|0|0|13538:1|false|||route-views.ny
–
A|1719514388.996829|198.32.132.129|13760|1.1.1.1/32|13760 267613|IGP|198.32.132.129|0|0||false|||route-views.telxatl1.1.1.0/24용 BGP 업데이트 살펴보기 여러 네트워크가 AS262504에서 접두사를 받고 이를 수용했습니다.
여기에서 우리는 다시 AS 경로에 주목합니다. 이번에는 AS13335가 알림의 맨 마지막에 있는 원본 AS입니다. 이 BGP 알림은 원본이 올바르게 AS13335이므로 RPKI가 유효하지만, 경로 자체가 유효하지 않기 때문에 1.1.1.0/24의 라우팅 유출입니다.
라우팅 유출임을 어떻게 알 수 있을까요?
예시 경로인 "199524 1031 262504 267613 13335"를 보면 AS267613은 기능적으로 AS13335의 피어이며 1.1.1.0/24 발표를 피어 또는 업스트림과 공유하지 않고 고객(AS Cone)과만 공유해야 합니다. AS262504는 AS267613의 고객이자 경로의 다음 인접 ASN이므로 이 시점까지는 특정 발표를 공유해도 괜찮습니다. 1.1.1.0/24가 잘못되는 곳은 AS262504가 업스트림 AS1031에 접두사를 발표할 때입니다. 또한 AS1031은 해당 알림을 피어에게 재배포했습니다.
이는 AS262504가 유출 네트워크라는 것을 의미합니다. AS1031은 고객 AS262504의 유출을 수락하고, 전 세계 여러 위치에 경로를 분산시켜 광범위한 영향을 미쳤습니다. AS1031(Peer-1 Global Internet Exchange)은 자신을 글로벌 피어링 Exchange라고 알립니다. Cloudflare는 AS1031의 고객이 아니므로, 1.1.1.0/24는 경로 서버나 AS1031의 업스트림에 절대로 재배포되지 않아야 합니다. AS1031은 고객 BGP 세션을 대상으로 어떤 광범위한 필터링을 수행하지 않고, 인접 항목(이 경우 AS262504)을 기준으로 일치시키는 것만 수행하고 이 기준을 충족하는 모든 항목을 재배포합니다. 안타깝게도 이는 AS1031의 무책임한 행동으로 1.1.1.1과 보호되지 않은 경로 전파의 희생양이 될 다른 서비스에 직접적인 영향을 미치고 있습니다. 원래 유출된 네트워크는 AS262504였지만, AS1031과 다른 사람들이 하이재킹 또는 유출을 수락하고 추가로 발표 내용을 배포했을 때 영향이 크게 증폭되었습니다.
~> monocle search --start-ts 2024-06-27T20:10:00Z --end-ts 2024-06-27T20:13:00Z --prefix '1.1.1.0/24' --as-path ".* 267613 13335" --include-sub
.. some advertisements removed for brevity ..
A|1719519011.378028|187.16.217.158|1031|1.1.1.0/24|1031 262504 267613 13335|IGP|187.16.217.158|0|0|1031:1031 1031:4209 1031:6045 1031:7019 1031:8010|false|13335|162.158.177.1|route-views2.saopaulo
–
A|1719519011.629398|45.184.147.17|1031|1.1.1.0/24|1031 262504 267613 13335|IGP|45.184.147.17|0|0|1031:1031 1031:4209 1031:4259 1031:6045 1031:7019 1031:8010|false|13335|162.158.177.1|route-views.fortaleza
–
A|1719519036.943174|80.249.210.99|50763|1.1.1.0/24|50763 1031 262504 267613 13335|IGP|80.249.210.99|0|0|1031:1031 50763:400|false|13335|162.158.177.1|route-views.amsix
–
A|1719519037|80.249.210.99|50763|1.1.1.0/24|50763 1031 262504 267613 13335|IGP|80.249.210.99|0|0|1031:1031 50763:400|false|13335|162.158.177.1|rrc03
–
A|1719519087.4546|45.184.146.59|199524|1.1.1.0/24|199524 1031 262504 267613 13335|IGP|45.184.147.17|0|0||false|13335|162.158.177.1|route-views.fortaleza
A|1719519087.464375|45.184.147.74|264409|1.1.1.0/24|264409 1031 262504 267613 13335|IGP|45.184.147.74|0|0|65100:7010|false|13335|162.158.177.1|route-views.fortaleza
–
A|1719519096.059558|190.15.124.18|61568|1.1.1.0/24|61568 262504 267613 13335|IGP|190.15.124.18|0|0|1031:1031 1031:4209 1031:6045 1031:7019 1031:8010|false|13335|162.158.177.1|route-views3
–
A|1719519128.843415|190.15.124.18|61568|1.1.1.0/24|61568 262504 267613 13335|IGP|190.15.124.18|0|0|1031:1031 1031:4209 1031:6045 1031:7019 1031:8010|false|13335|162.158.177.1|route-views3사건의 대부분의 시간 동안 AS262504에 의한 유출로 인해 결국 AS267613 내에 요청이 도착했고, AS267613은 네트워크 어딘가에서 1.1.1.1/32 트래픽을 삭제했습니다. 이를 위해 AS262504는 업스트림 경로를 유출하여 1.1.1.1 도달 불가 측면에서 영향을 증폭시켰습니다.
라우팅 유출의 영향을 제한하기 위해 Cloudflare에서는 AS267613을 사용하여 여러 위치에서 피어링을 비활성화했습니다. AS262504가 여전히 상파울루를 가리키는 오래된 경로를 누출하고 있었기 때문에 문제가 완전히 사라지지는 않았습니다. 상파울루에 도착하는 요청은 사용자에게 왕복 시간이 오래 걸리긴 했지만, 서비스를 제공할 수 있었습니다. Cloudflare에서는 유출 및 향후 예방 메커니즘과 관련하여 이 게시물 전체에 언급된 모든 네트워크와 함께, 그리고 Cloudflare에서 승인하지 않은 블랙홀 경로로 AS267613의 1.1.1.1/32를 받아들여 광범위한 영향을 초래한 최소 한 개의 티어 1 전송 공급자와 협력해 왔습니다.
복원 및 후속 조치
BGP 하이재킹
RPKI 원본 유효성 검사RPKI는 라우팅 시작점 인증(ROA)으로 서명된 접두사 측면에서 배포 비율이 50%라는 중요한 마일스톤에 도달했습니다. RPKI는 하이재킹된 BGP 접두사가 인터넷 전역으로 확산되는 것을 제한하는 데 확실히 도움이 되지만, 모든 네트워크, 특히 다운스트림 자율 시스템(AS)이 많은 주요 네트워크에서 제 역할을 다해야 합니다. 1.1.1.1/32의 하이재킹 기간 동안, 여러 네트워크에서 트래픽 포워딩을 위해 AS267613에서 발표한 경로를 수락하고 사용했습니다.
RPKI와 원격 트리거된 블랙홀링(RTBH)이 사건 중에 발생한 상당한 영향은 계층 1 공급자가 Cloudflare가 아닌 제3자의 블랙홀 경로로 1.1.1.1/32를 수락했기 때문입니다. 이것은 그 자체로 1.1.1.1의 하이재킹이며 매우 위험한 것입니다. RTBH는 대규모 DDoS 공격에 대한 완화가 절실할 때 많은 네트워크에서 사용하는 유용한 도구입니다. 문제는 RTBH에 사용되는 BGP 필터링이 본질적으로 느슨하고 종종 인터넷 라우팅 레지스트리에 있는 AS-SET 개체에만 의존한다는 것입니다. 라우팅 시작점 인증(ROA)에 의존하는 것은 RTBH 필터링에 적합하지 않습니다. 이를 위해서는 Cloudflare 규모의 네트워크에 대해 수천 개의 잠재적 ROA를 생성해야 하기 때문입니다. 뿐만 아니라 특정 /32 항목을 생성하면 AS13335인 것처럼 가장하는 누군가가 1.1.1.1/32와 같은 개별 주소를 발표하여 인터넷에서 1.1.1.1에 대한 최선의 경로가 되어 심각한 영향을 미칠 가능성이 생깁니다.
AS-SET 필터링은 1.1.1.1/32와 같이 경로를 블랙홀링 할 수 있는 권한을 대표하지 않습니다. Cloudflare에서만 운영 권한을 가진 대상을 블랙홀링 할 수 있어야 합니다. RTBH 세션에서 공급자에게 관대했던 필터링을 바로잡을 잠재적인 방법은 다시 RPKI를 활용하는 것입니다. IETF의 예를 보면, 만료된 Draft-spaghetti-sidrops-rpki-doa-00 제안은 특정 원본에 대해서만 블랙홀 작업을 승인할 권한을 부여하는 데 사용되는 원본 인증 삭제(DOA) 개체를 지정했습니다. 이러한 개체가 서명되고 개체에 대해 RTBH 요청이 검증된 경우, AS267613에 의한 1.1.1.1/32의 무단 블랙홀링 시도는 계층 1 공급자가 수락하는 대신 유효하지 않았을 것입니다.
BGP 모범 사례MANRS 에서 제시한 BGP 모범 사례를 따르고 Default-Free Zone(DFZ)에서 /24보다 긴 IPv4 접두사를 거부하는 것만으로도 1.1.1.1에 대한 영향은 줄어들 것입니다. 더 넓은 인터넷 내에서 유효하지 않은 접두사 길이를 거부하는 것은 모든 네트워크에 대한 표준 BGP 정책의 일환이어야 합니다.
BGP 라우팅 누출
라우팅 누출 감지
오늘날 Cloudflare에서는 라우팅 유출을 피할 수 없지만, 인터넷은 본질적으로 상호 연결을 신뢰에 의존하므로 영향을 제한하기 위해 몇 가지 조치를 취해야 합니다.
저희는 더 많은 네트워크를 대상으로 라우팅 유출 감지 시스템에 사용할 데이터 소스를 확장했으며, 향후 유사한 이벤트에 적시에 대응할 수 있도록 실시간 데이터를 감지 시스템에 통합하고 있습니다.
BGP용 ASPA
Cloudflare에서는 AS 경로 기반 라우팅 유출 방지에 RPKI를 계속해서 채택하려는 것을 지지합니다. 자율 시스템 공급자 인증(ASPA) 개체는 승인된 원본 AS로 접두사에 서명하는 대신 AS 자체가 경로 전파가 허용된 공급자 네트워크 목록으로 서명한다는 점을 제외하면 ROA와 비슷합니다. 따라서 Cloudflare의 경우 유효한 업스트림 전송 공급자만이 1.1.1.0/24 업스트림과 같은 AS13335 접두사를 광고할 권한이 있는 것으로 서명됩니다.
AS262504(AS267613의 고객)가 1.1.1.0/24 업스트림을 공유한 라우팅 유출 사례에서, AS267613이 승인된 공급자에 서명하고 AS1031이 해당 목록에 대해 경로를 검증했다면 BGP ASPA는 이 유출을 확인할 수 있습니다. 그러나 RPKI 원본 유효성 검사와 유사하게 이는 장기적인 노력이 필요하며 ASPA 개체를 기반으로 잘못된 AS 경로를 거부하는 네트워크, 특히 대규모 공급자에 따라 달라집니다.
기타 잠재적인 접근법
다양한 채택 단계에서 주목할 만한 ASPA에 대한 대체 접근 방식이 존재합니다. 그러나 다음과 같은 접근 방식이 광범위한 인터넷 배포 단계에 도달한다는 보장은 없습니다.
예를 들어, RFC9234는 BGP 기능 및 속성 내에서 피어 역할이라는 개념을 사용하며, 업데이트 경로를 따라 라우터의 구성에 따라 1.1.1.0/24와 같은 접두사의 업스트림 확산을 방지하는 '고객 전용'(OTC) 속성을 접두사에 추가하여 유출된 경로를 따라 확산되는 접두사를 방지할 수 있습니다. 단점은 각 피어링 세션에 다양한 역할을 할당하기 위해 BGP 구성을 완료해야 하며, 실제 프로덕션에서 긍정적인 결과를 얻으려면 벤더의 도입을 완전히 마무리해야 한다는 것입니다.
라우팅 유출을 해결하는 모든 접근 방식과 마찬가지로, 성공하려면 인터넷에서 네트워크 운영자들이 협력해야 합니다.
결론
Cloudflare의 1.1.1.1 DNS 확인자 서비스가 BGP 하이재킹과 BGP 라우팅 동시 유출 이벤트의 피해자가 되었습니다. 외부 네트워크의 활동은 Cloudflare의 직접적인 제어 범위를 벗어나지만, 인터넷 커뮤니티와 Cloudflare 내부에서 모든 조치를 취하여 영향을 보다 빠르게 감지하고 사용자에 대한 영향을 최소화하고자 합니다.
Cloudflare에서는 장기적으로 RPKI 기반 원본 유효성 검사 및 AS 경로 유효성 검사를 채택하도록 계속 지원합니다. 전자는 세계 최대의 다양한 네트워크에 배포되는 중이며, 후자는 IETF(인터넷 엔지니어링 태스크 포스)에서 아직 초안을 작성하는 중입니다. 그동안 귀하의 ISP에서 RPKI 출처 유효성 검사를 시행하고 있는지 확인하려면, 언제든지 isbgpsafeyet.com에 접속하여 _Test Your ISP_를 방문하시기 바랍니다.