요약

  • Cloudflare의 동시대 라우팅 분석은 2018년 4월 24일 UTC 기준 11:05 직후부터 Amazon의 커버링 Route 53 주소 범위 안에 있는 /24 프리픽스에 대해 무단 더 구체적 광고가 시작되었음을 기록했습니다. 관측된 오리진은 eNet(AS10297)이었고, 일부 경로는 Hurricane Electric(AS6939)을 경유했습니다. 비정상 라우팅 상태는 약 두 시간 지속되었습니다. [1]
  • 장치(메커니즘)는 은유가 아니라 네트워크 인프라였습니다. 더 구체적 경로를 수용한 네트워크들은 Amazon의 권위 DNS 서비스 일부에 대한 트래픽을 잘못된 오리진으로 보냈습니다. 해당 경로로 도달한 시스템은myetherwallet.com에 대해 거짓 응답을 반환했고, 정당한 도메인 질의가 사용자를 사칭 엔드포인트로 안내할 수 있었습니다. [1]
  • 이 사건은 Amazon이 해당 경로를 발원했다는 것, 모든 Route 53 고객이 영향을 받았다는 것, 또는 BGP만으로 TLS를 무력화했다는 것을 증명하지 않습니다. Cloudflare는 사칭 엔드포인트가 통상 신뢰되지 않는 인증서를 사용했다고 보고했습니다. 설명된 자격 증명 탈취 경로가 성공하려면 사용자가 브라우저 경고를 넘어야 했습니다. [1]
  • 번호 자원 및 레지스트리 기록은 해당 주소 공간을 Amazon과 AS16509에 연결했지만, 라우터는 수용된 경로 광고에 따라 동작했습니다. 레지스트리 진실은 필수적인 증거로 남았고, 실행 중인 경로 상태가 패킷 전달을 결정했습니다. 이 차이가 바로 핵심 책임성 표면입니다. [7]-[9][14]
  • RPKI 오리진 검증은 승인 기록을 강제 가능한 라우팅 결정으로 바꿀 수 있습니다. AWS는 이후 광범위한 ROA 커버리지와 자사 네트워크에서 RPKI 무효 경로의 폐기 사실을 문서화했습니다. 이후 진술은 복구 방향을 보여주지만, 2018년 4월 당시 모든 관련 네트워크에 배치된 정확한 통제를 증명하지는 않습니다. [3][4][17]-[19]
  • DNSSEC는 검증 리졸버가 서명된 DNS 데이터를 인증하도록 할 수 있습니다. 그러나 BGP 경로를 합법화하거나, 도달 가능성을 회복시키거나, 올바르게 서명·검증되지 않은 존을 보호하지는 못합니다. 공개 패킷은 해당 도메인의 완전한 과거 DNSSEC 상태를 확립하지 않으므로, 본 기사는 DNSSEC을 조건부 통제로 다룹니다. [5][6]
  • RouteViews, RIPE RIS와 RIS Live, CAIDA BGPStream, RIPEstat, 라우터 로그, DNS 응답 캡처, 인증서 증거는 서로 다른 질문에 답합니다. 어느 것 하나만으로 사건 전체, 운영자 의도, 모든 오염된 캐시, 모든 손실을 증명할 수 없습니다. [8]-[13]
  • 책임성은 경로 발원, 수입 필터링, 자원 승인, 모니터링, 권위 DNS, 리졸버 검증, 도메인 보안, 인시던트 소통, 복구 증명에 대한 실질적 통제를 따라갑니다. 하나의 레지스트리 항목, 하나의 경로 컬렉터 또는 하나의 회사 이름이 전 경로에 대한 주권이라는 식의 귀속은 불가능합니다.

두 컨트롤 플레인이 하나의 사용자 보이는 장애에서 만났다

이 사건은 사용자가 보통 결과물을 통해서만 접하는 두 시스템을 하나로 연결했습니다.

첫 번째는 도메인 간 라우팅이었습니다. BGP(Border Gateway Protocol)는 독립적으로 운영되는 네트워크들이 도달 가능성 정보를 교환하도록 합니다. 경로 광고는 어떤 네트워크가 특정 경로를 통해 한 프리픽스에 대한 트래픽을 전달할 수 있다는 의미입니다. BGP 자체는 오리진이 그 주소 공간을 광고할 승인을 받았다는 보편적 암호학적 증명을 제공하지 않습니다. 운영자들은 프로토콜 주위에 정책, 필터, 레지스트리 데이터, RPKI 검증, 모니터링, 상업적 관계를 더합니다. [14][15]

두 번째는 DNS(Domain Name System)였습니다. 권위 DNS 서비스는 도메인의 레코드에 대한 질문에 답합니다. 재귀 리졸버는 권위 서버에 질의하고, 응답을 캐시하고, 클라이언트에게 돌려줍니다. Route 53이 이 사건에서 관련된 권위 서버 주소를 제공했습니다. 그 서버 주소를 향한 패킷이 정당한 서비스에 도달하기 전에 우회된다면, 리졸버는 원래 권위를 가져서는 안 되는 시스템으로부터 응답을 받을 수 있습니다. [1][5][6]

사용자는 도메인 이름을 보고 그에 상응하는 서비스를 기대했습니다. 네트워크는 먼저 권위 DNS 서버 주소가 어디에서 도달 가능한지 결정해야 했습니다. 답하는 서버는 그다음 도메인에 대한 주소를 제공했습니다. 마지막으로 브라우저가 엔드포인트의 인증서를 신뢰할 수 있는지 판단해야 했습니다.

이것들은 서로 다른 결정입니다:

  1. 어느 네트워크가 DNS 서버 프리픽스를 발원할 승인을 받았는가?
  2. 각 트랜짓 또는 접속 네트워크가 어느 경로를 수용하는가?
  3. 리졸버의 질의를 실제로 어느 서버가 받는가?
  4. DNS 응답은 진위가 검증되어 있는가?
  5. 엔드포인트가 요청된 이름에 대해 신뢰되는 인증서를 제시하는가?
  6. 신뢰 검증이 실패하면 사용자나 애플리케이션이 멈추는가?

2018년 4월 사건은 이 경계들을 순서대로 넘었습니다. 그래서 이를 단지 "BGP 하이재킹"으로만 설명하면 불완전하고, 단지 "DNS 오염"으로만 설명하면 거짓 서버를 도달 가능하게 만든 경로 제어 실패가 가려집니다.

이 연쇄 구조는 또한 책임성을 서비스 이름에 브랜드가 등장했다는 이유만으로 한 주체에 귀속시킬 수 없다는 뜻입니다. Amazon은 자사 주소 자원, Route 53 운영, 모니터링, 커뮤니케이션, 이후 경로 보안 배치를 통제했습니다. 그러나 모든 외부 BGP 스피커를 통제하지는 못했습니다. 무단 오리진과 그 업스트림 관계는 다른 지점을 통제했습니다. 재귀 리졸버 운영자, 도메인 운영자, 브라우저와 사용자 행동은 이후의 경계를 통제했습니다.

엄밀한 서술은 이 연쇄 전반에 걸쳐 능력과 증거를 추적합니다.

공개 라우팅 기록이 확립하는 것

Cloudflare의 기술 포스트는 대략 UTC 기준 11:05에서 12:55 사이에 관측된 BGP 광고를 기술했습니다. Amazon 주소 공간의 다섯 개 /24 프리픽스를 나열하고 AS10297과 AS6939가 포함된 경로를 보여주었습니다. 정당한 커버링 범위는 Amazon, AS16509와 연관된 /23들이었습니다. [1]

/23과 /24의 구분은 운영적으로 중요합니다. 라우팅은 보통 가장 긴 일치 프리픽스를 선택합니다. /24는 /23보다 작은 주소 블록을 커버합니다. 둘 다 존재할 때, 정당한 커버링 경로가 여전히 보이더라도 더 구체적 경로가 트래픽을 끌어당길 수 있습니다.

이 동작은 무단 더 구체적 광고를 강력하게 만듭니다. 공격자나 잘못 설정된 네트워크는 정당한 경로를 지울 필요가 없습니다. 더 좁은 경쟁 주장을 게시하면 됩니다. 이를 수용·전파하는 네트워크는 더 작은 범위에 대한 트래픽을 우회시킬 수 있습니다.

Cloudflare의 컬렉터는 그 범위 안의 Route 53 주소를 관측했습니다. 비정상 라우팅 구간 동안, 응답한 시스템은 일부 질의가 실패하는 것과 함께myetherwallet.com에 특화된 동작, 즉 거짓 주소를 서비스했습니다. Cloudflare는 자사의 1.1.1.1 리졸버도 일부 위치에서 영향을 받았다고 보고했습니다. 리졸버가 나쁜 광고를 직접 수용한 네트워크가 운영할 필요는 없습니다. 권위 서버로의 경로가 그런 네트워크를 지나면 충분했습니다. [1]

이 기록은 몇 가지 한정된 결론을 지지합니다:

  • 프리픽스는 Amazon의 커버링 경로보다 더 구체적이었습니다.
  • 관측된 오리진 ASN은 Amazon의 AS16509와 일치하지 않았습니다.
  • 적어도 하나의 전파 경로에 AS6939가 포함되었습니다.
  • 해당 주소는 Route 53 권위 DNS에 사용되고 있었습니다.
  • 우회된 경로 위에서 한 도메인에 대한 거짓 응답이 관측되었습니다.
  • 라우팅 상태는 전 세계적으로 동일하지 않았고 지역적으로 고르지 않았습니다.

같은 기록이 증명하지 않는 것:

  • 모든 라우터 명령을 누가 내렸는가.
  • AS10297이 의도적으로 침해되었는지, 내부적으로 남용되었는지, 잘못 설정되었는지.
  • 각 전파 단계를 허용한 계약 관계가 무엇인지.
  • 어느 네트워크가 경로를 거부했는지.
  • 거짓 응답을 캐시한 모든 재귀 리졸버.
  • 사칭 페이지를 본 모든 사용자.
  • 사건에 귀속된 모든 금전 손실.

이 경계가 중요한 이유는 경로 컬렉터가 외부적으로 보이는 메시지를 관측하기 때문입니다. 이들은 선택된 피어가 무엇을 들었는지에 대한 강한 증거이지만, 모든 네트워크 운영 센터 내부의 카메라는 아닙니다.

RouteViews는 2018년 4월의 아카이브된 업데이트 데이터를 제공합니다. RIPE RIS와 RIS Live는 BGP 업데이트에 대한 또 다른 측정 시스템을 문서화합니다. CAIDA BGPStream은 라우팅 이벤트 분석을 위한 연구 플랫폼을 제공합니다. RIPEstat는 AS16509와 AS10297에 대한 자원·라우팅 뷰를 제공합니다. 이 시스템들을 결합하면 어떤 서술이 공개 라우팅 증거와 일치하는지 검증할 수 있습니다. [8]-[13]

이들의 적절한 역할은 교차 검증과 재구성입니다. 기사가 컬렉터의 제한된 관측점을 보편적 전파 주장으로 바꿔서는 안 됩니다.

왜 레지스트리 진실이 패킷 진실을 강제하지 못했는가

관련 주소 자원은 Amazon과 연관되어 있었습니다. 이 연관은 중요했습니다. 운영자와 조사자에게 예기치 않은 오리진을 판단할 기준점을 주었기 때문입니다.

그러나 모든 라우터가 광고를 거부하도록 강제하지는 못했습니다.

이것이 기록과 강제 기구의 차이입니다. 레지스트리는 누가 번호 자원을 보유하는지, 어느 ASN이 프리픽스를 발원할 것으로 예상되는지, 어떤 연락처나 보안 메타데이터가 연관되어 있는지 보존할 수 있습니다. 라우터는 여전히 신뢰할 수 있는 데이터를 소비하여 결정을 적용하는 실행 중인 정책을 필요로 합니다.

그 단계가 없으면 정확한 기록과 부정확한 경로가 공존할 수 있습니다.

건전한 인프라 책임성 모델은 레지스트리를 주권자가 아니라 대장(장부)과 기록 보관자로 다룹니다. 이 관점은 이 사건과 정확히 부합합니다. 레지스트리의 가치를 깎아내는 것이 아니라 그 가치를 올바른 위치에 놓는 것입니다.

주소 기록은 증거를 제공합니다. ROA(Route Origin Authorization)는 암호학적으로 서명된 오리진 권한을 제공할 수 있습니다. 검증기는 수신된 경로를 분류할 수 있습니다. 라우터 정책은 무효 항목을 거부할 수 있습니다. 모니터링은 예상치 못한 오리진이 나타나면 경고할 수 있습니다. 운영 팀은 철회와 복구를 조율할 수 있습니다. 실행되는 경로는 데이터베이스 선언만으로가 아니라 이 모든 기능에서 나옵니다.

이 책임성 모델은 또한 실행 코드를 승인 형식주의보다 위에 놓습니다. 승인된 자원 보유자, 올바른 티켓, 게시된 라우팅 정책이 패킷이 의도된 경로를 따르게 하지는 않습니다. 포워딩 시스템에 설치된 경로가 운영적 사실입니다. 그 경로 위에서 반환되는 DNS 응답은 또 다른 사실입니다. 엔드포인트에서 제시되는 인증서는 또 하나의 사실입니다.

따라서 책임성 있는 운영자는 등록뿐 아니라 대조(reconciliation)가 필요합니다:

  • 모든 발원 프리픽스가 의도된 승인으로 커버되어 있는가?
  • 최대 프리픽스 길이가 의도된 더 구체적 경로만을 허용하는가?
  • 고객·피어 필터가 현재 검증된 데이터로부터 생성되는가?
  • 라우터가 RPKI 무효 오리진을 거부하는가?
  • 모니터가 실제 오리진을 자원 권한과 비교하는가?
  • 팀이 관련 업스트림과 자원 보유자에게 신속히 연락할 수 있는가?
  • 권위 DNS 서비스가 독립된 네트워크에서 도달 가능한 상태를 유지하는가?

2018년 사건이 유해해진 이유는 실행 중인 경로와 자원 증거가 DNS 트래픽이 무단 응답 시스템에 도달할 만큼 오래 갈라져 있었기 때문입니다.

BGP 오리진 검증은 강력하면서도 한계가 있다

RPKI는 서명된 객체를 통해 IP 프리픽스를 승인된 오리진 ASN에 결합하는 방법을 제공합니다. ROA는 어느 ASN이 프리픽스를 발원할 수 있고 허용되는 최대 길이가 무엇인지를 식별합니다. 신뢰 당사자들이 그 객체를 검증합니다. 라우터는 검증된 오리진 데이터를 받아 BGP 경로를 유효, 무효, 미발견으로 분류할 수 있습니다. [17]-[19]

서로 다른 ASN이 더 구체적 프리픽스를 광고하는 사건에서 이 통제는 직접적으로 관련됩니다.

Amazon이 AS16509에게 커버링 프리픽스의 발원을 승인하고, 무단 /24를 배제하는 최대 길이를 설정했다고 가정해 봅시다. 그 /24에 대한 AS10297의 경로는 RPKI 무효여야 합니다. 오리진 검증을 강제하는 네트워크는 그것을 거부할 수 있습니다.

이것은 구체적인 예방 기구입니다. 번호 자원 권한을 라우팅 결정으로 변환합니다.

그러나 이것이 인터넷 라우팅 보안의 완전한 설명은 아닙니다.

오리진 검증은 프리픽스, 길이, 오리진 ASN 사이의 관계를 평가합니다. 경로 내의 모든 ASN을 인증하지는 못합니다. 유효한 오리진도 경로 누출에 연루될 수 있습니다. 나쁜 정책은 의도된 범위 밖으로 경로를 내보낼 수 있습니다. 오래되었거나 잘못된 ROA는 정당한 경로를 오류적으로 무효화할 수 있습니다. 검증을 수행하지 않는 네트워크는 여전히 무효 경로를 수용·전파할 수 있습니다. [15]-[20]

RFC 7908은 경로 누출을 의도된 정책 범위를 넘는 전파로 정의합니다. RFC 9234는 BGP 역할(BGP Roles)과 Only-to-Customer 속성을 특정 누출 패턴을 신호·제한하는 이후의 기구로 추가합니다. 이 통제들은 오리진 검증이 증명하지 못하는 경로 정책 관계를 다룹니다. [16][20]

역사적 경계도 똑같이 중요합니다.

AWS는 2021년 자사 IPv4·IPv6 주소 공간의 99% 이상이 ROA로 커버되며, 자사 존재 지점(point of presence)에서 RPKI 무효 경로를 폐기하고 있다고 서술했습니다. 2025년에는 추가 안전 검사를 포함하는 더 넓은 RPKI 구현과 경로 승인 관련 진행 중인 작업을 기술했습니다. [3][4]

이 진술들은 AWS가 이후 배치했다고 말하는 내용을 보여줍니다. 2018년 4월 24일의 정확한 ROA 커버리지, 최대 길이, 외부 트랜짓 강제, 모니터링 구성을 확립하지는 않습니다.

따라서 책임성 있는 기사는 이후 포스트를 복구(시정) 증거로 사용합니다:

  • AWS는 BGP 오리진 하이재킹을 중대한 네트워크 리스크로 인식합니다.
  • AS16509를 AWS의 주요 ASN으로 식별합니다.
  • ROA와 무효 경로 폐기를 통제로 기술합니다.
  • RPKI 오류 자체가 연결성에 영향을 줄 수 있으므로 안전 검사를 문서화합니다.
  • 라우팅 보안이 네트워크 간 협력을 필요로 함을 인정합니다.

기사가 이 이후의 통제를 사건 시점으로 소급해서 다시 써서는 안 됩니다.

경로 필터링은 여전히 운영자의 책임이다

RPKI는 승인 데이터의 한 원천입니다. 운영자는 고객, 피어, 업스트림으로부터 무엇을 수용할지도 통제합니다.

RFC 7454는 BGP 보안과 필터링에 대한 운영 관행을 다룹니다. MANRS는 잘못된 광고 방지, 스푸핑 트래픽 방지, 조율 지원, 글로벌 검증 활성화를 위한 조치를 기술합니다. [15][22]

중요한 질문은 네트워크에 "라우팅 정책"이라는 제목의 문서가 있었는지가 아니라, 관련 세션에서 실행 중인 정책이 관측된 광고를 거부했을 것인지입니다.

고객 또는 소규모 네트워크의 경우 업스트림이 예상 프리픽스와 ASN의 허용 목록을 유지할 수 있습니다. 프리픽스 수 한도는 예상치 못한 확장을 제약할 수 있습니다. 최대 프리픽스 길이 규칙은 고객이 내보낼 승인이 없는 더 좁은 광고를 방지할 수 있습니다. RPKI 검증은 암호학적 오리진 증거를 더할 수 있습니다. 경보는 수동 보고 이전에 새 오리진이나 예상치 못한 경로를 식별할 수 있습니다.

각 통제에는 유지비용과 실패 모드가 있습니다.

허용 목록은 낡을 수 있습니다. 프리픽스 한도는 정당한 확장을 차단하거나 너무 높아 도움이 되지 않을 수 있습니다. 경로 객체는 부정확할 수 있습니다. ROA는 잘못된 최대 길이를 사용할 수 있습니다. 모니터는 대응자 없이 경고하거나 자사 관측점 밖의 지역을 놓칠 수 있습니다.

그래서 책임성은 현재 운영 중이라는 증거를 요구합니다:

  • 승인된 고객 프리픽스 집합과 그 출처.
  • 마지막 검토의 날짜와 담당자.
  • 라우터에 설치된 컴파일된 필터.
  • 무단 더 구체적 경로의 거부를 보여주는 테스트.
  • 통제된 예상치 못한 오리진 훈련에서 생성된 경보.
  • 업무 시간 외에도 작동하는 연락처와 철회 경로.

공개 기록은 모든 관련 구성을 공개하지 않습니다. 그 증거의 부재는 비난이 아니라 미지로 남아야 합니다. 기사는 그래도 종이 위의 정책과 경로 수용을 바꾸는 정책을 구분할 증거가 무엇인지는 식별할 수 있습니다.

권위 DNS가 라우팅 오류를 증폭시켰다

우회된 주소는 일반 웹 서버 주소가 아니었습니다. Route 53 권위 DNS 인프라에 속한 주소였습니다.

그 역할이 효과를 증폭시켰습니다.

myetherwallet.com에 대한 응답을 찾는 재귀 리졸버는 먼저 도메인의 권위 서버에 도달해야 했습니다. BGP가 그 서버 트래픽을 우회하면 리졸버는 거짓 레코드를 받을 수 있고, 만료 또는 수정까지 그 응답을 캐시해 클라이언트에 제공할 수 있습니다. 자체 접속 네트워크가 무단 경로를 직접 수용하지 않은 사용자도 그런 경로를 사용하는 재귀 리졸버로부터 오염된 응답을 받을 수 있었습니다. [1]

이것은 두 개의 지리적 지도를 만듭니다:

  1. 권위 서버로의 경로가 무단 광고를 따른 네트워크.
  2. 재귀 리졸버가 그 경로 위에서 응답을 얻어 캐시한 사용자.

두 지도는 겹치지만 동일하지는 않습니다.

이 구분은 최종 사용자 접속 네트워크만 기반한 영향 보고가 불완전할 수 있는 이유를 설명합니다. 리졸버는 다른 네트워크나 지역에 있을 수 있습니다. 캐시된 응답은 경로 변경보다 오래 남을 수 있습니다. 반대로 네트워크가 경로를 수용하더라도 리졸버의 캐시에 이미 유효한 정당한 응답이 있을 수 있습니다.

따라서 책임성 증거에는 다음이 포함되어야 합니다:

  • BGP 업데이트와 오리진 상태.
  • 영향받은 권위 주소로 보내진 질의.
  • 여러 리졸버와 관측점에서 관측된 DNS 응답.
  • TTL과 캐시 만료 동작.
  • 해당되는 경우 DNSSEC 검증 결과.
  • 반환된 엔드포인트에서의 인증서 관측.
  • 경로 철회, 수정된 응답, 캐시 복구의 타임스탬프.

이 사건은 또한 권위 DNS가 높은 레버리지를 가진 네트워크 의존성임을 보여줍니다. 비교적 작은 서버 주소 집합에 영향을 주는 경로 변경은 그 서버에 위임된 도메인의 해석에 영향을 줄 수 있습니다. 그렇다고 모든 Route 53 존이 영향을 받았다는 뜻은 아닙니다. Cloudflare는 한 도메인에 집중된 동작을 관측했습니다. [1]

올바른 주장은 더 좁습니다: 권위 DNS 트래픽의 우회는 나쁜 경로를 직접 수용한 네트워크 밖의 사용자에게도 영향을 줄 수 있는 거짓 응답 경로를 만들었다는 것입니다.

DNSSEC은 다른 신뢰 질문에 답한다

DNSSEC는 리졸버가 서명된 신뢰 사슬 안에서 DNS 데이터의 진위를 검증하도록 합니다. Route 53 문서는 도메인 등록과 호스티드 존 서명 워크플로우 모두를 설명하고, 검증 리졸버가 사슬에 맞지 않는 DNS 데이터를 거부할 수 있음을 설명합니다. [5][6]

이 통제는 거짓 DNS 응답과 직접 관련됩니다.

그러나 BGP 통제는 아닙니다.

DNSSEC는 어느 ASN이 IP 프리픽스를 광고할 수 있는지 결정하지 않습니다. 권위 서버를 도달 가능하게 하지 않습니다. 트래픽 우회를 막지 않습니다. 검증 리졸버가 받은 DNS 데이터가 암호학적으로 진위한지 물을 수 있도록 합니다.

관련 존이 올바르게 서명되어 있고, 사슬이 온전하며, 재귀 리졸버가 검증을 강제했다면 유효한 서명이 없는 위조 응답은 실패해야 합니다. 검증 실패는 오류를 반환함으로써 무결성을 보호할 수 있지만 여전히 가용성 문제를 만들 수 있습니다.

존이 서명되지 않았거나 리졸버가 검증하지 않았다면 DNSSEC는 그 보호를 제공하지 않습니다.

원본 패킷은 2018년 4월 24일myetherwallet.com의 완전한 과거 DNSSEC 상태를 확립하지 않습니다. 추가 1차 증거 없이 도메인이 특정 구성을 갖고 있었거나 없었다고 주장하는 것은 부적절합니다.

책임성 있는 서술은 조건부입니다:

  • RPKI는 경로 오리진 검증을 도울 수 있습니다.
  • DNSSEC는 DNS 데이터 검증을 도울 수 있습니다.
  • TLS는 브라우저에 엔드포인트를 인증할 수 있습니다.
  • 어느 것도 나머지를 대체하지 않습니다.

계층화된 설계는 애플리케이션이 실패 시 멈출 때만 강점입니다. 우회된 경로 위에서 전달된 DNSSEC 유효 응답도 정당한 서명자로부터 왔다면 진위할 수 있습니다. DNSSEC 무효 응답은 검증 리졸버에서 실패해야 합니다. 유효한 DNS 응답도 침해된 애플리케이션을 가리킬 수 있습니다. 올바른 경로도 악성 콘텐츠를 운반할 수 있습니다. 인증서 경고도 무시될 수 있습니다.

책임성은 각 경계에서 실패 동작을 시험하는 것을 요구합니다.

TLS는 여전히 보이는 정지 신호였다

Cloudflare는 사칭 엔드포인트가 통상 신뢰되지 않는 인증서를 제시했다고 보고했습니다. 도메인 이름은 인증서 데이터에서 올바르게 보였지만 인증서는 신뢰된 기관에 체인되지 않은 자체 서명 인증서였습니다. 브라우저는 경고를 표시해야 했습니다. [1]

이 증거는 중요한 한계를 설정합니다.

BGP와 DNS 조작은 사용자를 잘못된 서버로 보낼 수 있었습니다. 그러나 자동으로 공격자에게 신뢰된 인증서를 주지는 않았습니다. 설명된 탈취 경로는 사용자가 경고를 무시하고 진행하거나 인증서 경계를 올바르게 강제하지 않는 소프트웨어를 사용해야 성공했습니다.

이 사실이 라우팅이나 DNS 실패를 면죄시키지는 않습니다. 사용자를 사칭 엔드포인트 앞에 놓아서는 안 됩니다. 그러나 BGP가 TLS를 무의미하게 만들었다는 과장된 주장은 막아줍니다.

사건은 대신 스트레스 하의 계층 방어를 보여줍니다:

  • 경로 오리진 검사는 DNS 이전에 우회를 막을 수 있었습니다.
  • DNSSEC 검증은 서명된 존에 대한 위조 DNS 응답을 막을 수 있었습니다.
  • TLS 검증은 사칭 엔드포인트에 대한 신뢰를 막을 수 있었습니다.
  • 사용자 인터페이스와 애플리케이션 동작은 자격 증명 제출을 막을 수 있었습니다.

남은 방어는 불완전했습니다. 사용자는 경고를 클릭해 넘어갈 수 있습니다. 애플리케이션은 검증을 잘못 다룰 수 있습니다. 일부 인터페이스는 리스크를 이해하기 어렵게 만듭니다. 그러나 공개 증거는 경고가 존재했다고 말합니다.

책임성 검토는 작동한 방어를 보존하면서 이전 통제가 왜 실패했는지를 검토해야 합니다. 그렇지 않으면 기사가 모든 계층을 하나의 총체적 실패로 평평하게 만들어 정확한 증거를 벌하게 됩니다.

책임은 실질적 통제를 따른다

이 사건에는 서로 다른 능력을 가진 여러 주체가 관련되었습니다.

무단 오리진과 그 네트워크 운영자

관측된 오리진으로 식별된 네트워크는 더 구체적 경로가 나타난 BGP 세션을 통제하거나 그와 연관되었습니다. 관련 증거에는 라우터 구성, 인증, 계정 접근, 변경 기록, 고객 관계, 인시던트 로그가 포함됩니다. 공개 컬렉터는 한 ASN에 귀속된 광고를 보여주지만, 그 광고를 발행한 개인이나 시스템을 식별하지는 못합니다. [1][9]

전파하는 업스트림과 트랜짓 네트워크

업스트림은 수입 필터, 고객 프리픽스 승인, 최대 프리픽스 설정, 오리진 검증, 전파를 통제했습니다. AS6939를 경유해 보이는 경로는 경로 관측을 확립하지만 완전한 계약이나 과실 판단은 아닙니다. 증거 질문은 네트워크가 광고를 거부했어야 하는 현재의 통제를 갖고 있었는지, 그 통제가 작동하고 있었는지입니다.

Amazon Web Services

AWS는 주소 자원, Route 53 서비스, 공개 자원 레코드, 경로 보안 태세, 서비스 모니터링, 고객 커뮤니케이션을 통제했습니다. ROA를 게시하고, 예상치 못한 오리진을 모니터링하고, 피어와 조율하고, 시정 조치를 문서화할 수 있었습니다. 그러나 모든 외부 라우터를 일방적으로 프로그래밍할 수는 없었습니다. AWS의 이후 RPKI 포스트는 내부 검증과 산업 협력 모두를 기술하며, 그 공유된 경계를 반영합니다. [3][4]

재귀 리졸버 운영자

리졸버 운영자는 서버가 사용할 업스트림 경로, DNSSEC 검증 여부, 응답 캐시 방식, 보존하는 원격 측정, 알려진 거짓 데이터의 플러시 속도를 통제했습니다. 그들은 Route 53 프리픽스를 발원하지 않았고 도메인 존에 서명하지도 않았습니다.

도메인 운영자

도메인 운영자는 위임 선택, DNSSEC 서명, 레코드 관리, TLS 배치, 사용자 커뮤니케이션, 인시던트 대응을 통제했습니다. 그러나 글로벌 BGP 수용을 통제하지는 못했습니다. 기사는 증거 없이 과거 DNSSEC 구성을 추론해서는 안 됩니다.

브라우저와 애플리케이션 운영자

브라우저와 클라이언트 운영자는 인증서 검증과 경고 동작을 통제했습니다. 그들의 보호는 라우팅과 DNS가 이미 실패한 이후의 경계였습니다.

사용자

사용자는 인증서 경고에서 멈출 수 있었지만, 경로 발원, 권위 DNS 인프라, 리졸버 정책을 통제하지는 못했습니다. 일부가 경고를 클릭해 넘어갔다는 이유로 사용자에게 1차 책임을 돌리는 것은 거짓 경로를 만든 업스트림 통제를 무시하는 것입니다.

책임 지도는 균등한 비난의 공식이 아닙니다. 증거와 능력의 지도입니다.

탐지는 승인, 경로, 응답을 대조해야 한다

유용한 탐지 시스템은 한 계층만 감시하지 않습니다.

자원 모니터링은 실제 오리진 ASN을 ROA 및 예상 오리진과 비교할 수 있습니다. 경로 컬렉터는 새 더 구체적 광고와 그 전파를 식별할 수 있습니다. 권위 DNS 운영자는 여러 네트워크에서 서비스 주소를 프로브할 수 있습니다. 리졸버 모니터는 응답과 검증 상태를 비교할 수 있습니다. 인증서 모니터는 예상치 못한 엔드포인트를 식별할 수 있습니다.

각 신호는 시끄럽거나 불완전할 수 있습니다.

새 오리진은 계획된 마이그레이션일 수 있습니다. 더 구체적 경로는 합법적 트래픽 엔지니어링일 수 있습니다. DNS 응답은 의도적으로 다를 수 있습니다. 인증서는 교체될 수 있습니다. 경로 컬렉터는 한 지역을 놓칠 수 있습니다.

해법은 변경 권한과의 상관입니다:

  1. 경로가 현재 승인으로 커버되어 있는가?
  2. 광고가 승인된 배치와 일치하는가?
  3. 여러 독립 컬렉터가 그것을 보는가?
  4. 권위 DNS 프로브가 예상된 서명 데이터를 반환하는가?
  5. 리졸버 응답과 인증서 사슬이 일치하는가?
  6. 책임 있는 소유자가 변경을 확인했는가?

경보는 결정에 사용된 증거를 보존해야 합니다. 일시적 BGP 이벤트는 조사가 시작되기 전에 사라질 수 있습니다. RouteViews 아카이브와 RIPE RIS는 역사적 기록을 제공하며, 로컬 라우터 로그와 DNS 캡처는 운영자별 세부 사항을 더합니다. [10]-[13]

대응에도 권한 지도가 필요합니다. 누가 경로를 철회할 수 있는가? 누가 오리진과 업스트림에 연락할 수 있는가? 누가 ROA를 안전하게 갱신할 수 있는가? 누가 DNS 고객에게 경고할 수 있는가? 누가 거짓 리졸버 캐시를 식별·플러시할 수 있는가? 누가 도메인과 인증서 대응을 조율할 수 있는가?

대응 담당자가 없는 대시보드는 통제가 아닙니다.

복구는 연쇄 전체를 닫아야 한다

무단 경로의 철회는 필요합니다. 그러나 복구를 완성하지 않을 수 있습니다.

리졸버는 TTL 만료 또는 플러시까지 거짓 응답을 유지할 수 있습니다. 사용자는 활성 세션이나 침해된 자격 증명을 가질 수 있습니다. 도메인 운영자는 비밀 키 교체, 거래 조사, 경고 게시가 필요할 수 있습니다. 경로 보유자는 ROA, 필터, 모니터링 수정이 필요할 수 있습니다. 업스트림은 경로가 왜 수용되었는지 검토해야 할 수 있습니다.

따라서 마감 기록은 다음을 구분해야 합니다:

  • 경로 수정 시각.
  • 글로벌 전파 감쇠.
  • 권위 DNS 응답 수정.
  • 리졸버 캐시 복구.
  • 인증서와 엔드포인트 검증.
  • 사용자 통지.
  • 자격 증명 또는 자산 보호.
  • 장기 경로 제어 시정.

이 타임스탬프들은 서로 다른 질문에 답합니다. 경로가 사라질 때 인시던트를 종결하면 잔여 DNS 또는 사용자 피해를 숨길 수 있습니다. 반대로 모든 다운스트림 결과를 기다렸다가 네트워크 복구를 선언하면 기록이 혼란스러워질 수 있습니다.

정확한 마감은 어느 계층이 회복되었고 무엇이 남았는지 말합니다.

AWS의 이후 RPKI 배치 진술은 하나의 장기 방향에 대한 증거입니다. ROA 커버리지, 무효 경로 폐기, 안전 검사를 기술합니다. 다음 질문은 현재 테스트가 정당한 서비스를 차단하지 않으면서 동등한 무단 더 구체적 경로를 통제가 거부하는지 보여주는가입니다. [3][4]

외부 네트워크의 증거에는 고객 프리픽스 필터 생성, RPKI 무효 거부, 경로 누출 탐지, 연락 절차가 포함될 수 있습니다. DNS 운영자는 애니캐스트 도달 가능성 프로브, 서명 존 검증, 리졸버 캐시 대응을 보여줄 수 있습니다. 도메인 운영자는 DNSSEC 상태, 인증서 통제, 테스트된 인시던트 플레이북을 보여줄 수 있습니다.

복구는 시험 가능할 때 책임성이 생깁니다.

실용적인 증거 아젠다

이사회, 규제자, 고객, 네트워크 운영자는 유용한 질문을 하기 위해 모든 비공개 구성 줄이 필요하지 않습니다. 통제에 연결된 증거가 필요합니다.

번호 자원 권한

  • 어떤 RIR 기록이 주소 공간을 커버하는가?
  • 어느 ASN이 각 프리픽스를 발원할 승인을 받았는가?
  • 어떤 최대 길이가 허용되는가?
  • ROA 생성, 검토, 만료, 긴급 수정은 누가 소유하는가?
  • 승인 변경이 독립적으로 승인되는가?

경로 수용

  • 각 고객이 어느 프리픽스를 광고할 수 있는가?
  • 필터를 생성하는 출처는 무엇인가?
  • 얼마나 빨리 갱신되는가?
  • RPKI 무효 경로가 거부되는가?
  • 알 수 없는 경로가 문서화된 리스크 정책 아래 수용되는가?
  • 최대 프리픽스와 더 구체적 경로 한도가 테스트되는가?

모니터링

  • 어떤 컬렉터와 내부 피드가 예상치 못한 오리진을 탐지하는가?
  • 경보 임계값은 무엇인가?
  • 경보가 계획된 마이그레이션과 하이재킹을 구분할 수 있는가?
  • 24시간 대응 담당자가 있는가?
  • 경로와 DNS 관측이 보존되는가?

권위 DNS

  • 서비스 주소가 독립 네트워크에서 프로브되는가?
  • 필요한 존이 서명되어 있는가?
  • 검증 리졸버가 거짓 데이터를 거부하는가?
  • 운영자가 어느 캐시가 나쁜 응답을 받았는지 식별할 수 있는가?
  • 고객 커뮤니케이션이 영향받은 DNS 경로와 독립적인가?

엔드포인트 신뢰

  • 클라이언트가 신뢰되지 않는 인증서를 거부하는가?
  • 경고가 명확하고 우연히 우회하기 어려운가?
  • 도메인 운영자가 세션을 철회하고 자격 증명을 교체할 수 있는가?
  • 거래 모니터링이 인시던트 타임라인과 연결되어 있는가?

복구 증명

  • 무단 오리진 훈련이 실행되었는가?
  • 필터와 검증이 그것을 거부했는가?
  • 모니터링이 사용자 보고 이전에 경보했는가?
  • 권위 DNS가 올바르게 유지되었는가?
  • 대응 팀이 연락처와 철회 경로를 완료했는가?
  • 예외, 실패, 재테스트가 기록되어 있는가?

이 아젠다는 민감한 구성 게시와 막연한 안심 사이의 허위 이분법을 피합니다. 증거는 모든 비공개 세부를 노출하지 않고도 구체적일 수 있습니다.

이 통제 연쇄가 특정한 이유

책임성 질문은 단순히 BGP가 불안전한지 아닙니다. 이 사건에서 도메인 간 라우팅은 Route 53 권위 DNS 주소 공간 일부에 대한 질의에 어느 서버가 응답할지를 결정했습니다. 도달한 시스템은 한 도메인에 대한 거짓 DNS 데이터를 반환했고, TLS가 별도의 경고 경계를 제공하는 사칭 엔드포인트로 향하는 경로를 만들었습니다. 이 순서는 번호 자원 승인, 경로 수용, 권위 DNS 무결성, 리졸버 동작, 엔드포인트 인증을 하나로 연결합니다. [1][14]

따라서 Route 53 통제 연쇄는 다음을 포함합니다:

  • 표적 프리픽스가 권위 DNS를 서비스했다.
  • 더 구체적 경로가 리졸버 질의에 응답하는 서버를 바꿨다.
  • 한 도메인에 대한 거짓 DNS 데이터가 사칭 엔드포인트 경로를 만들었다.
  • DNSSEC과 TLS가 별도의 무결성 경계를 제공했다.
  • 리졸버 캐시 동작이 분석을 직접 경로 수용 너머로 확장했다.

이것은 일반적인 경로 누출 분석보다 좁습니다. 그 구체적 질문은 번호 자원 승인과 경로 필터링이 DNS 응답 무결성과 엔드포인트 신뢰에 어떻게 연결되는가입니다. 따라서 증거는 어떤 경로가 수용되었는지만이 아니라, 어느 권위 시스템에 도달했고, 무엇을 반환했으며, 리졸버가 그 응답을 어떻게 처리했고, 클라이언트가 최종 인증 경계를 보존했는지를 보여야 합니다.

출처의 한계

Cloudflare의 2018년 4월 24일 포스트가 핵심 동시대 기술 출처입니다. 관측된 프리픽스, 시각, AS 경로, Route 53 주소 사용, DNS 동작, 인증서 경계를 포함합니다. Cloudflare는 중립적 법원이나 규제자가 아니라 관측자이자 영향받은 리졸버 운영자였습니다. 그 컬렉터는 모든 라우터를 볼 수 없었습니다. [1]

Cloudflare의 이후 하이재킹 탐지 기사는 자사 모니터링 모델을 설명하고 같은 사건을 예로 듭니다. 기제와 시정 맥락에는 유용하지만 2018년 모든 세부 사항의 독립 교차 검증은 아닙니다. [2]

AWS의 2021·2025 라우팅 보안 포스트는 이후 통제에 대한 1자 서술입니다. 2018년 정확한 통제 상태나 외부 채택을 증명하지 않습니다. [3][4]

AWS Route 53 문서는 DNSSEC과 서비스 동작을 나중 문서화된 대로 설명합니다. 관련 도메인의 완전한 과거 서명·검증 상태를 확립하지 않습니다. [5][6]

AWS IP 범위 문서와 RIPEstat는 자원 맥락을 제공합니다. 의도나 모든 운영 관계를 증명하지 않습니다. [7]-[9]

RouteViews, RIPE RIS, RIS Live, CAIDA BGPStream은 공개 측정 능력을 제공합니다. 그 가시성은 피어와 수집 지점에 의존합니다. 모든 비공개 경로, 라우터 구성, DNS 캐시, 운영자 결정을 노출하지 않습니다. [10]-[13]

RFC들은 프로토콜, 리스크 분류, 권장 기구를 정의합니다. 특정 운영자가 통제를 배치했거나 특정 법적 의무를 부담했다는 증거가 아닙니다. [14]-[20]

ARIN과 MANRS 문서는 운영 도구와 규범을 설명합니다. 사건의 모든 주체에 대한 컴플라이언스를 확립하지 않습니다. [21][22]

이 기사는 특정 운영자의 악의적 의도, 형사 책임, 과실, 계약 위반, 검증된 피해자 수, 검증된 총 손실, 완전한 캐시 오염, 모든 네트워크에 걸친 지속적 시정을 확립하지 않습니다. RPKI, DNSSEC 또는 TLS 중 하나만으로 모든 피해가 예방되었을 것이라고 주장하지 않습니다.

이 한계들은 책임성 기록의 일부입니다. 더 강한 조사에 필요한 것이 무엇인지를 식별합니다.

결론

2018년 Route 53 하이재킹은 번호 자원 권한과 실행 중인 경로 상태 사이의 불일치가 DNS와 사용자 신뢰까지 넘어갈 수 있음을 보여주었습니다.

레지스트리와 할당 기록은 프리픽스를 Amazon에 연결했습니다. 그럼에도 라우터는 다른 오리진의 더 구체적 광고를 수용했습니다. 재귀 리졸버는 그 경로 위에서 서버에 도달했습니다.myetherwallet.com에 대한 거짓 응답은 사용자를 사칭 엔드포인트로 보냈습니다. TLS는 사라지지 않고 이후의 경고 경계로 남았습니다.

각 계층은 서로 다른 질문에 답했습니다:

  • 레지스트리 데이터: 누가 자원을 보유하는가?
  • ROA와 RPKI: 어느 ASN이 발원할 수 있는가?
  • BGP 정책: 네트워크는 어느 경로를 수용하는가?
  • 경로 모니터링: 인터넷은 무엇을 광고했는가?
  • 권위 DNS: 도달한 서버는 어떤 응답을 제공했는가?
  • DNSSEC: DNS 데이터는 진위한가?
  • TLS: 엔드포인트는 인증되었는가?
  • 사용자와 애플리케이션 동작: 실패 시 거래가 멈추는가?

책임성은 그 응답들을 정확하게 만들고 정렬 상태로 유지할 수 있었던 운영자를 따릅니다.

가장 강한 복구는 주소 기록이 항상 정확했다는 주장이 아닙니다. 부정확한 실행 상태가 거부되고, 탐지되고, 봉쇄된다는 증명입니다. 자원 보유자는 정밀한 승인을 유지합니다. 오리진과 트랜짓 네트워크는 필터와 검증을 강제합니다. DNS 운영자는 도달 가능성과 응답 무결성을 관측합니다. 리졸버는 서명된 데이터를 검증합니다. 브라우저는 무효 인증서에서 멈춥니다. 인시던트 팀은 경로 변경부터 캐시와 사용자 복구까지 타임스탬프가 붙은 기록을 보존합니다.

이것이 운영적 실체 계층입니다. 레지스트리는 장부로서 없어서는 안 됩니다. 그러나 패킷에 대한 주권은 아닙니다. 실행 코드와 설치된 정책이 트래픽이 어디로 가는지 결정합니다. 번호 자원은 고유성, 정확한 승인, 보안 메타데이터, 운영 연속성이 필요합니다. 기록이 이를 강제하는 시스템에 유용해야 하기 때문입니다.

이 사건은 한 회사가 인터넷 전체를 통제했다는 것을 증명해서가 아니라 그 반대를 증명하기 때문에 여전히 중요합니다. 도메인 간 라우팅과 DNS는 공유 시스템입니다. 한 참여자에게만 존재하는 복구는 리스크를 줄일 수 있지만 전 경로를 보장할 수 없습니다. 따라서 책임성 있는 기준은 지역적이면서도 협력적입니다: 운영자가 통제할 수 있는 것을 통제하고, 그 통제의 증거를 게시하고, 그 신호를 함께 움직여야 하는 네트워크가 사용할 수 있게 만듭니다.

최종 시험은 운영적입니다. 안전한 훈련에서 무단 더 구체적 경로를 광고합니다. 승인 데이터가 정확한지, 필터가 그것을 거부하는지, 모니터가 경보하는지, DNS 응답이 진위를 유지하는지, 클라이언트가 인증서 검사를 보존하는지, 대응자가 책임 있는 피어에 도달하는지, 보존된 증거가 모든 결정을 설명하는지 확인합니다.

이 훈련을 보여줄 수 없다면 레지스트리 항목은 여전히 경로에 대한 약속일 뿐입니다. 보여줄 수 있다면 기록은 작동하는 통제의 일부가 된 것입니다.

출처

  1. https://blog.cloudflare.com/bgp-leaks-and-crypto-currencies/
  2. https://blog.cloudflare.com/bgp-hijack-detection/
  3. https://aws.amazon.com/blogs/networking-and-content-delivery/how-aws-is-helping-to-secure-internet-routing/
  4. https://aws.amazon.com/blogs/networking-and-content-delivery/aws-secures-internet-routing-with-rpki-plus-security-checks/
  5. https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/domain-configure-dnssec.html
  6. https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-configuring-dnssec.html
  7. https://docs.aws.amazon.com/vpc/latest/userguide/aws-ip-ranges.html
  8. https://stat.ripe.net/AS16509
  9. https://stat.ripe.net/AS10297
  10. https://archive.routeviews.org/bgpdata/2018.04/UPDATES/
  11. https://www.ripe.net/analyse/internet-measurements/routing-information-service-ris/
  12. https://ris-live.ripe.net/manual/
  13. https://bgpstream.caida.org/
  14. https://www.rfc-editor.org/rfc/rfc4271
  15. https://www.rfc-editor.org/rfc/rfc7454
  16. https://www.rfc-editor.org/rfc/rfc7908
  17. https://www.rfc-editor.org/rfc/rfc6811
  18. https://www.rfc-editor.org/rfc/rfc6480
  19. https://www.rfc-editor.org/rfc/rfc8210
  20. https://www.rfc-editor.org/rfc/rfc9234
  21. https://www.arin.net/resources/manage/rpki/
  22. https://www.manrs.org/wp-content/uploads/2021/02/MANRS-Network-Operators-Actions-v2.4.4.pdf