Spamhaus 2013년 DDoS는 개방형 DNS 재귀를 네트워크 책임성 시험으로 만들었다

요약

• Cloudflare는 초기 공격이 Spamhaus의 접속을 포화시켰다고 보고했고, 이후 더 큰 규모로 관찰된 반사 DNS 파도에 대해서도 언급했으나, 이러한 공급자 관점의 관찰이 전체 인터넷의 피크나 글로벌 장애를 입증하지는 못한다. [1][2]
• 실행 가능한 경로는 위조된 소스 주소, 외부에 노출된 재귀 리졸버, 증폭된 응답, 그리고 공유 라우팅·완화 경로를 결합했다. 재귀 DNS와 권한 DNS는 서로 다른 역할이다. [4][10]
• RFC 5358은 이미 재귀 서비스 제한을 권고하고 있었으며, BCP 38과 BCP 84는 소스 주소 검증을 접속·고객·멀티홈 네트워크 에지에 할당하고 있었다. [4][5][6]
• 리졸버 운영자, 접속 네트워크, 완화 공급자, 업스트림, 교환기 운영자, Spamhaus는 각각 실행 경로의 서로 다른 부분을 통제했다. 책임성은 제도적 라벨이 아니라 경로별 증거를 요구한다.
• 웹사이트 중단이 Spamhaus의 분산 차단리스트 데이터가 전 세계에서 중단되었음을 증명하지는 못했다. 서비스 계층의 주장은 종단점, 경로, 관찰 시간대를 명시해야 한다. [3]
• 이후의 DNS 메커니즘, RIPE, MANRS, DNS-OARC 및 연구 자료는 유용한 비교·검증 도구를 제공하지만, 2013년 3월 당시 동일한 형태로 사용 가능했던 통제로 소급 적용할 수는 없다. [7]-[9][14]-[19]
• 책임성 시험은 운영적이다: 의도하지 않은 재귀를 차단하고, 소스 주소를 검증하고, 라우팅과 완화 변경을 기록하고, 협조 증거를 보존하고, 영향받은 경로 밖에서 복구를 검증하는 것이다.

책임성 프레임

2013년 3월 Spamhaus에 대한 공격은 단순한 거대 플러드 전설이 아니라 일반적인 네트워크 통제에 대한 책임성 시험이었다. 3월 18일부터 27일까지 트래픽은 먼저 Spamhaus의 웹사이트를 방해했고, 이후 Cloudflare의 공급자와 피어링 접점에 사용된 인프라에 도달했다. 이 경로는 독립적으로 운영되는 시스템들을 결합했다: 위조된 소스 주소, 요청을 수용하는 노출된 재귀 DNS 서버, 위조된 목적지로 향하는 더 큰 응답, 그리고 총 부하를 운반하는 공유 링크. Cloudflare의 동시대 기록이 이 사건을 규정했고, 더 이른 표준들은 경로의 핵심 부분을 어느 운영자가 통제했는지 규정하고 있었다 [1][2][4][5][6].

재귀 DNS와 권한 DNS는 서로 다른 역할이다. 권한 서버는 자신이 서비스하는 존에 대한 데이터를 공개하고, 재귀 리졸버는 클라이언트를 위한 조회를 수행한다. 임의의 외부 클라이언트에 열려 있는 리졸버는 대상과 아무 관계가 없음에도 반사체가 될 수 있다 [4][10]. RFC 5358은 이미 재귀 서비스 제한을 권고하고 있었고, BCP 38과 BCP 84는 접속·고객·멀티홈 네트워크 에지에서의 소스 주소 검증을 다루고 있었다 [4][5][6]. 첫 번째 통제는 반사를 제한하고, 두 번째는 위조된 패킷을 차단한다.

책임은 실제 통제를 따른다. 리졸버 운영자는 누가 재귀를 수행할 수 있는지와 응답 동작을 통제했다. 접속 및 트랜짓 운영자는 에지 필터링을 통제했다. Cloudflare는 애니캐스트 완화, 라우팅 변경, 그리고 자신의 공개 주장을 통제했다. Spamhaus는 서비스 설계와 복구 커뮤니케이션을 통제했지만, 원격 리졸버나 스푸핑 네트워크는 통제하지 않았다. 교환기 운영자와 업스트림에 대한 결론은 경로 증거가 그들이 무엇을 운반하거나 통제했는지 보여주는 경우에만 정당하다.

이 분석은 Spamhaus 차단리스트의 정당성에 대해 어떤 입장도 취하지 않는다. 더 좁은 결론은 방치된 에지 설정들이 공유된 외부효과로 결합할 수 있다는 것이다. 책임성은 각 운영자가 자신이 통제할 수 있는 것을 복구했다는 증거를 요구한다.

경계가 설정된 사건 기록

사건의 경계는 3월 18~27일의 Spamhaus 캠페인, 그리고 이후 Cloudflare의 공급자 및 피어링 접점 일부에 대한 공격이다. Cloudflare는 공격이 Spamhaus의 접속을 포화시키고 웹사이트에 접근할 수 없게 만든 후 Spamhaus가 완화를 요청했다고 밝혔다. 처음에는 약 10Gbit/s, 이후 열린 재귀 리졸버를 통한 반사가 주를 이루는 75~90Gbit/s 파도를 보고했다 [1]. 후속 기록은 120Gbit/s 방향의 확대와 고객 주소에서 공급자 및 교환기 방향 링크로의 트래픽 이동을 설명했다 [2].

이러한 관찰을 하나의 연속적·균일하게 측정된 사건으로 축소해서는 안 된다. 보호된 고객 인터페이스에서의 트래픽, 완화 네트워크 내부의 트래픽, 업스트림 또는 피어링 링크에 대한 트래픽은 서로 다른 관측 지점에서 나오며 서로 다른 장애 도메인을 가리킬 수 있다. 웹사이트 접근 불가 역시 Spamhaus의 분산 안티스팸 데이터가 사라졌음을 증명하지 못한다. Spamhaus는 이후 자신의 웹사이트, 호스트, DNS 파트너, 지원 서비스가 표적이 되는 동안 차단리스트 데이터는 계속 이용 가능했다고 밝혔다 [3]. 따라서 기록은 글로벌 이메일 필터링이 중단되었음을 보여주지 않는다.

메커니즘은 구체적이었다. Cloudflare에 따르면 요청은 스푸핑된 소스 주소를 사용했고, ripe.net 데이터를 노출된 재귀 리졸버에 요청했으며, 더 큰 응답이 피해자에게 수렴하게 만들었다. Cloudflare는 3만 개 이상의 참여 리졸버와 자신이 관찰한 요청-응답 형태에서 약 100배에 가까운 증폭을 보고했다 [1][2]. 각 리졸버나 소스 네트워크는 로컬에서는 적당한 트래픽만 기여할 수 있지만, 수천 개의 그런 경로가 링크를 포화시키는 플러드로 누적되었다.

“인터넷을 거의 망가뜨렸다”는 표현은 Cloudflare의 헤드라인을 포함한 동시대 홍보적 프레임이었지, 글로벌 장애의 입증된 발견이 아니었다 [2]. 이 경계가 설정된 기록에서 특정 교환기 전체 장애, 보편적 중단, 법적으로 판정된 공격자 신원을 확립하는 인용된 기록은 없다. 그런 주장들은 증거 밖에 남는다.

무엇이, 어디서 측정되었는가

모든 헤드라인 수치에는 이름이 있는 관측자와 측정 맥락이 필요하다. 약 10Gbit/s와 75~90Gbit/s 수치는 Cloudflare가 자사의 고객 완화 기록에서 보고한 것이다 [1]. 120Gbit/s 방향의 이동과 자주 반복되는 300Gbit/s 피크는 Cloudflare의 이후 공급자 측 서사에 속한다 [2]. 따라서 300Gbit/s 수치는 공급자 관측 주장이며 공개 인터넷 전체의 측정이 아니다. 관련 네트워크 전반에 걸친 동기화되고 독립적으로 문서화된 관측 없이는 이 수치들을 보편적 피크로 다룰 수 없다.

동일한 규율이 귀속에도 적용된다. 리졸버 로그는 재귀 노출과 응답 동작을 보여줄 수 있다. 스푸핑 테스트와 고객 에지 기록은 소스 주소 검증이 작동했는지 보여줄 수 있다. 플로우 데이터, 경로 변경, 스크러빙 기록, 트랜짓 협조 기록은 트래픽이 어디에 진입했고 어떤 링크에 압력이 걸렸는지를 찾아낼 수 있다. 어뷰즈 통지와 사후 스캔은 노출된 시스템이 식별되고 복구되었는지 보여줄 수 있다. 애니캐스트는 부하를 분산할 수 있지만 그 결과는 여전히 경로 선택, 피어링, 트랜짓 용량, 트래픽이 도착하는 위치에 달려 있다.

이후의 가이드는 그 증거 모델을 더 정교하게 한다. DNS Cookies, 축소된 ANY 응답 동작, 대규모 권한 서비스 아키텍처는 현대의 비교 지점을 제공한다 [7][8][9]. RIPE와 DNS-OARC 자료 역시 인벤토리, 재귀 차단, 응답 통제, 역할 분리, 운영 검증을 지원한다 [14][16][17][19]. 이러한 자료는 공격 당시 모든 이후 통제가 동일한 방식으로 사용 가능하거나 배치 가능했음을 증명하지 못한다.

여러 한계가 미해결 상태로 남는다: 완전한 소스 AS 분포, 정확한 피크 측정 지점, 보편적 피크의 존재 여부, 보고된 경로 밖의 방관자 혼잡이나 영향의 범위, 캠페인 전후 개별 운영자의 내부 지식, 참여 네트워크 간 정확한 인과 배분. 이러한 미지를 보존하는 것도 책임성 시험의 일부다. 타당한 결론은 추상적으로 누가 비난받아야 하는지가 아니라, 어느 운영자가 작동 가능한 통제를 보유했고, 어떤 증거가 그 상태를 보여주며, 복구가 감사 가능했는지이다.

실행 가능한 반사 경로

실행 가능한 경로는 IP 헤더 속 거짓말에서 시작되었다. 공격자는 작은 UDP DNS 쿼리를 보내면서 소스 주소를 Spamhaus의 주소로, 이후 단계에서는 완화된 트래픽을 운반하는 인프라의 주소로 교체했다. UDP는 응답 전에 연결을 수립하지 않으므로 서버는 답을 위조된 주소로 반환했다. 공격자는 작은 트리거를 제공했고, DNS 서버가 큰 패킷을 보냈다.

중개자는 열린 재귀 리졸버였다. 그것은 임의의 인터넷 주소의 요청을 수용하고, 요청된 데이터를 검색하고, 결과를 주장된 클라이언트에 반환했다. Cloudflare는ripe.net쿼리, 3만 개 이상의 참여 리졸버, 그리고 자신이 관찰한 쿼리-응답 형태에서 약 100배의 증폭을 보고했다 [1]. 이 수치들은 Cloudflare의 관찰이며 모든 리졸버나 패킷의 인구조사가 아니다. 반복이 운영적 효과를 만들었다: 수많은 작은 위조 요청이 하나의 목적지에 수렴하는 더 큰 응답을 유도했다.

그 목적지는 피해자, 애니캐스트 완화 지점, 또는 보호된 서비스를 운반하는 공급자 방향 링크일 수 있었다. 따라서 압력은 애플리케이션에 도달하기 전에 네트워크 용량을 소진시킬 수 있었다. Cloudflare는 Spamhaus에 대한 트래픽과 이후 완화 및 공급자 경로에 영향을 주는 트래픽을 기술했다 [1][2]. 그 경로 위의 반사된 패킷은 응답이 도달했음을 증명할 뿐, 출발 봇넷, 완전한 소스 AS 분포, 보편적 인터넷 피크를 밝히지는 못한다.

재귀 DNS와 권한 DNS는 구별된다. 권한 서버는 자신이 서비스하는 존에 대한 답을 공개한다. 재귀 리졸버는 클라이언트의 질문을 수용하고, 필요할 때 DNS 계층을 따라가며, 결과를 캐시하고, 해결된 답을 반환한다 [10]. 한 기계가 두 기능을 모두 수행할 수 있지만 역할은 분리 가능하다. 이 경로는 “DNS 서버”라는 하나의 계급이 아니라 외부에 이용 가능한 재귀를 악용했다. 권한 서비스는 다른 증폭 패턴을 가능하게 할 수 있지만, 그렇다고 모든 권한 운영자가 열린 리졸버 운영자가 되는 것은 아니다.

재귀는 운영자의 통제다

RFC 5358은 Spamhaus 캠페인 5년 전인 2008년에 이미 이 반사체 문제를 기술했다. 그 핵심 운영 배분은 명확하다: 재귀 네임서버 운영자는 의도된 클라이언트에만 재귀를 제공해야 하고, 네트워크 운영자는 위조된 소스 주소를 가진 패킷이 자신의 네트워크 밖으로 나가지 못하게 해야 한다 [4]. 재귀를 닫는 것은 공개 권한 DNS를 비활성화한다는 뜻이 아니다. 재귀 서비스를 사용할 권한이 누구에게 있는지 정의하고 접근 통제, 인터페이스 정책, 별도 운영 리졸버를 통해 그 경계를 강제한다는 뜻이다.

그 경계는 소프트웨어, 서비스 역할, 수신 인터페이스, 클라이언트 ACL, 캐시 정책, 응답 동작을 선택하는 리졸버 운영자에게 속한다. 권한 서버가 재귀도 제공한다면 운영자는 재귀 역할을 명시적으로 책임져야 하며, 통합 배치가 그 책임을 지우지는 않는다. 노출된 리졸버는 각 반사 응답이 적당하다는 이유로, 또는 Spamhaus를 표적으로 선택하지 않았다는 이유로 면제되지 않는다. 그 설정은 인증되지 않은 외부 요청자에게 실행 가능한 능력을 공급했다.

관련 증거도 마찬가지로 구체적이다. 운영자는 최신 리졸버 인벤토리, 외부에서 수행한 재귀 테스트, 승인된 클라이언트 범위를 보여주는 설정, 사용된 경우의 역할 분리, 복구가 재시작과 페일오버를 통과했음을 보여주는 로그나 측정을 제시할 수 있어야 한다. 응답률 통제는 피해를 줄일 수 있고, 이후 기법은 일부 교환의 스푸핑을 더 어렵게 만들 수 있지만, 그것들은 재귀 경계를 대체하는 것이 아니라 보완한다 [7][19]. RFC 5358의 공격 이전 날짜가 중요하다: 제한된 재귀는 사건에 맞추어 소급적으로 발명된 통제가 아니다.

책임에도 한계가 있다. 리졸버는 일반적으로 UDP 패킷에 표시된 소스 주소를 볼 뿐, 그 주소가 위조된 원격 네트워크를 통제하지 못한다. 반대로 스푸핑을 허용하는 접속 공급자는 원격 리졸버의 재귀 ACL을 관리하지 않는다. 한 조직이 두 시스템을 모두 운영한다면 두 의무가 모두 부착되지만, 서로 다른 증거를 가진 두 개의 통제로 남는다. 책임성은 운영자가 설정하고 검증할 수 있는 구성 요소를 따른다.

네트워크 에지에서의 스푸핑

BCP 38(RFC 2827)은 출발점에 가장 가까운 네트워크에 실용적 통제를 할당한다: 고객 또는 내부 네트워크에서 들어오는 트래픽 중 그 인터페이스에서 정당하게 도달할 수 없는 소스를 주장하는 트래픽을 필터링하라 [5]. 공급자 관점에서 인그레스 필터링이라 불리지만 그 결과는 더 넓은 인터넷에 대한 이그레스 보호다. 고객 또는 기업은 자신의 호스트가 방출하는 것을 통제하고, 접속 공급자는 고객 방향 경계에서 검증을 통제한다. 할당된 프리픽스와 인터페이스 관계가 위조된 소스를 거부할 가장 강한 근거를 제공하는 지점이 바로 거기다.

BCP 84는 유효한 트래픽이 비대칭 경로를 따를 수 있는 멀티홈 네트워크로 배분을 확장한다. 엄격한 역방향 경로 전달이 안전하지 않을 수 있다는 이유만으로 소스 검증을 포기하는 것을 정당화하지 않는다. 인터페이스 ACL과 서로 다른 수용 특성을 가진 역방향 경로 방식 등 토폴로지 인식 선택을 기술하여, 운영자가 정당한 멀티홈 트래픽을 보존하면서도 불가능한 소스는 거부할 수 있게 한다 [6]. 멀티홈 고객은 사용 가능한 소스 프리픽스를 정확히 선언해야 하고, 그 공급자들은 각 접속 지점에서 호환되는 정책을 구현·유지해야 한다.

따라서 트랜짓 네트워크가 우연히 운반하는 모든 스푸핑된 패킷에 대해 자동으로 책임지는 것은 아니다. 책임은 고객-프리픽스 관계를 알고 필터를 통제하는 고객 방향 에지에서 가장 강하다. 임의의 트랜짓 경로의 더 먼 지점에서는 같은 추론이 성립하지 않을 수 있다. 증거는 실제 인터페이스와 정책을 식별해야 한다: 허용 프리픽스 기록, ACL 또는 소스 검증 모드, 비대칭 라우팅 예외, 표본화된 드롭 카운터, 스푸핑 테스트 결과, 변경 이력, 어뷰즈 통지 처리. 배치 격차가 지속되기 때문에 그런 검증은 일반적인 준수 주장보다 유용하다 [15].

RFC 5358과 BCP 38/84는 하나의 경로에서 정반대 끝단을 다룬다. 제한된 재귀는 임의 요청자가 이용할 수 있는 반사체를 제거하고, 소스 주소 검증은 위조된 요청이 어떤 반사체에도 도달하기 전에 막는다 [4][5][6]. 어느 통제도 다른 운영자의 의무를 대체하지 않는다. 증폭된 응답은 이 독립적 실패들이 정렬될 때만 가능해지며, 그래서 패킷 경로 자체가 책임성 지도이기도 하다.

집계는 국지적 방치를 네트워크 외부효과로 바꾼다

열린 재귀 리졸버는 작은 로컬 실수처럼 보일 수 있다: 한 서버가 원래 서비스할 의도가 없던 클라이언트에 답하거나, 접속 네트워크가 자신이 할당한 적 없는 소스 주소의 패킷을 전달하는 것. 어느 행위도 로컬에서 보이는 속도로는 결과적이어 보이지 않는다. 반사는 계산 단위를 바꾼다. 위조된 요청은 피해자를 자신의 소스로 지명하고, 리졸버는 답을 그 피해자에게 보내며, 요청보다 큰 응답이 트래픽을 배가한다. RFC 5358은 이 패턴을 기술하고 2013년 공격 이전에 재귀 제한을 권고했다 [4].

실행 가능한 체인은 행정 경계를 넘는다. 공격 호스트는 위조된 소스 주소를 가진 작은 DNS 쿼리를 방출한다. 소스 네트워크는 그 불가능한 주소가 외부로 나갈 수 있는지 결정하고, 노출된 재귀 리졸버는 임의의 외부 클라이언트가 재귀할 수 있는지 결정한다. 권한 서버는 DNS 계층 내에서 데이터를 공급하지만, 답을 얻어 반환하는 재귀 서비스와 상호 교환 가능하지 않다 [10]. 응답은 라우팅을 따라 트랜짓, 피어링, 완화, 피해자 방향 링크로 들어간다. 모든 홉에서 소프트웨어와 설정—추상적 소속이 아니라—이 체인이 계속되는지를 결정한다.

집계가 일어나는 이유는 각 참가자가 캠페인을 보지 못한 채 용량을 기여하기 때문이다. 초당 몇 메가비트를 내보내는 하나의 리졸버는 경보 임계 아래에 머물 수 있다. 하나의 브로드밴드나 호스팅 네트워크는 수많은 고객에 걸쳐 드문 스푸핑된 요청을 운반할 수 있다. 그러나 수만 개의 리졸버가 병렬로 응답할 수 있다. Cloudflare는 Spamhaus 캠페인에서 3만 개 이상의 참여 리졸버를 보고했고, 관찰된 쿼리-응답 패턴에 대해 약 100배의 증폭을 추정했다 [1]. 이는 귀속된 관찰이지 보편적 상수는 아니지만, 로컬에서 적당한 방출이 원격 병목에 수렴함을 보여준다.

이것은 네트워크 외부효과다: 재귀를 열어두거나 스푸핑을 허용하는 당사자는 편의를 얻거나 복구 비용을 회피하는 반면, 원격 서비스, 완화 공급자, 통신사, 교환기 방향 링크가 혼잡을 흡수한다. 피해는 이동할 수 있다. Cloudflare의 기록은 Spamhaus를 겨냥한 트래픽에서 공급자 및 피어링 접점을 향한 이후 파도로 이동했고, 거기서 제약 자원은 더 이상 고객 접속만이 아니었다 [1][2]. 애니캐스트는 부하를 여러 지점에 분산할 수 있고, 피어링과 트랜짓 용량은 집중이 어디서 실패가 되는지를 결정한다. 공급자 측 피크는 그 측정 지점을 기술할 뿐, 전체 인터넷의 상태가 아니다 [2].

수천 대 일 효과는 의도나 개별 물량에만 기반한 책임성을 무너뜨린다. 방치된 리졸버가 필수적일 필요는 없고, 소스 네트워크가 큰 흐름을 발생시킬 필요도 없다. 질문은 각 운영자가 그 반복이 플러드를 가능하게 한 실행 가능한 조건을 통제했는지이다. 하나의 리졸버를 닫는 것은 공격을 거의 바꾸지 못하지만, 전체 자산에 걸쳐 재귀를 닫아 두는 것은 반사체 개체수를 바꾼다. 하나의 위조 패킷을 드롭하는 것은 무의미하지만, 모든 고객 에지에서 소스 주소를 검증하는 것은 규모에서 전제 조건을 제거한다. BCP 38과 BCP 84는 그 의무를 접속, 고객, 멀티홈 경계에 위치시킨다 [5][6].

증거는 실제 통제를 따라야 한다

증거는 그 통제 지점을 따라야 한다. 리졸버 운영자는 재귀 인스턴스의 인벤토리, 의도된 클라이언트 프리픽스, ACL 또는 동등한 정책 내보내기, 외부 노출 스캔, 변경 티켓, 표본화된 쿼리-응답 텔레메트리를 보존해야 한다. 기록은 공개 재귀가 언제 감지되었고, 누가 복구를 담당했으며, 외부 관측 지점이 차단을 확인했는지 보여주어야 한다. 속도 제한 설정과 로그는 경계된 동작을 보여주지만 접근 통제를 대체하지 못한다. DNS Cookies나 축소된 ANY 응답 같은 이후 메커니즘은 유용한 비교이지, 2013년 3월 동일한 통제가 사용 가능했거나 배치되었음의 증명이 아니다 [7][8]. 테스트는 재귀와 권한 역할을 분리해야 한다.

접속 공급자는 인터페이스별 소스 프리픽스 정책, 배치 커버리지, 예외 등록부, 검증 실패 카운터, 통제된 스푸핑 테스트 결과를 보존해야 한다. 멀티홈 고객이나 트랜짓 운영자는 필터링이 취약한 단일 업링크 가정이 아니라 실현 가능한 복귀 경로를 반영한다는 증거, 즉 BCP 84가 다루는 문제에 대한 증거가 필요하다 [6]. 어뷰즈 통지는 고객, 인터페이스, AS, 시간대, 처분, 재테스트를 식별해야 한다. 어느 에지가 테스트되었고 어느 것이 면제되었는지 보여주지 않는 한 “BCP 38 활성화”는 약하다. 소스 주소 검증의 지속적인 운영상 어려움은 정책 선언보다 측정된 커버리지의 필요성을 강화한다 [15].

트랜짓, 피어링, 교환기 운영자는 또 다른 계층을 통제한다. 그들은 표본화된 플로우, 인터페이스 사용률, 경로 광고와 철회, 커뮤니티, 트래픽 엔지니어링 변경, 혼잡 경보, 협조 타임스탬프를 보존해야 한다. 이러한 기록은 반사 트래픽이 어디에 진입했고, 어느 링크가 제약되었고, 어떤 라우팅 조치가 결과를 바꿨는지 식별한다. 그것만으로 리졸버 운영자가 노출을 알았음을 증명하거나, 경로 증거 없이 공격 물량을 교환기에 귀속시킬 수는 없다. RIPE와 DNS-OARC 자료는 관찰 가능한 증폭 부하를 대응책과 측정에 연결하며, 공유 인프라를 하나의 무차별적 피해자로 다루지 않는다 [16][17].

완화 공급자는 공격 지문, 표본화 방법론, 측정 위치, 중복 제거 규칙, 애니캐스트 지점 부하, 스크러빙 결정, 경로 변경, 업스트림 요청을 보존해야 한다. 공개 속도 주장에는 타임스탬프, 관측 지점, 수신·드롭·고객 전달 트래픽의 구분이 필요하다. 보고된 300Gbit/s 수치는 Cloudflare의 공급자 측 서사에 속하며, 글로벌 측정된 장애가 되어서는 안 된다 [2]. 사후 증거는 완화가 일부 위치에서 웹사이트를 보존했는지, 또는 공급자 경로를 더 넓게 보호했는지 보여주어야 한다. 이후 대규모 권한 서비스 가이드는 2013년의 능력을 다시 쓰지 않으면서 복원력 검토에 도움을 줄 수 있다 [9].

Spamhaus는 자신의 서비스 아키텍처, 의존성, 복구 선택, 공개 상태 커뮤니케이션을 통제했다. 의존성 지도, DNS와 호스팅 변경, 웹사이트 가용성 측정, 분산 차단리스트 전달에 대한 별도 확인을 보존해야 했다. 웹사이트 중단이 글로벌 이메일 필터링의 실패를 확립하지 않는다. Spamhaus는 원격 리졸버나 위조 패킷을 수용하는 네트워크를 통제하지 않았으며, 업스트림이 Spamhaus의 애플리케이션 설계를 통제하지 않았던 것과 같다. 따라서 감사 가능한 기록은 모든 주장을 통제된 계층, 타임스탬프가 찍힌 관측, 시정 조치, 독립적 재테스트에 매핑하면서, 완전한 소스 AS 분포, 보편적 피크, 관측되지 않은 방관자 효과를 명시적으로 미지로 남겨둔다.

애니캐스트, 트랜짓, 피어링이 장애 도메인을 바꿨다

Cloudflare가 완화를 시작하면서 보호는 단일 서버를 넘어섰다. 초기 플러드는 Spamhaus의 접속을 포화시키고 웹사이트에 접근할 수 없게 만들었다. Cloudflare는 약 10Gbit/s의 트래픽, 이후 75~90Gbit/s 파도, 그리고 열린 재귀 리졸버가 DNS 답을 보호된 주소 쪽으로 반사하는 모습을 기술했다 [1]. 애니캐스트는 트래픽이 도착하고 흡수될 수 있는 위치를 바꿨다.

애니캐스트는 동일한 서비스 주소를 여러 위치에서 광고한다. 라우팅은 공격의 일부를 서로 다른 지점으로 끌어당겨 필터링 용량이 하나의 접속 링크 뒤에 집중되는 대신 분산되게 한다. 그 실질 용량은 여전히 선택된 경로, 각 지점의 여유, 패킷이 도달하는 트랜짓·피어링 링크에 달려 있었다. 분산된 에지는 총 완화 용량보다 좁은 상호연결을 드러낼 수 있다.

Cloudflare는 캠페인이 이후 원래의 Spamhaus 목적지를 넘어 약 120Gbit/s에 도달하고, 자신의 네트워크로 가는 경로상의 공급자와 링크를 겨냥했다고 보고했다 [2]. 그 기록은 이 사건을 약 300Gbit/s의 피크와도 연관시켰다 [2]. 이 수치들은 완화 공급자의 가시성 내에서 이루어진 관측을 기술한다. 그것은 모든 인터넷 트래픽의 보편적 측정계가 아니며, 모든 경로상의 모든 네트워크가 동일한 부하를 경험했음을 확립하지 않는다.

따라서 “교환기 방향”은 신중한 해석이 필요하다. 공격 트래픽은 프라이빗 피어, 교환기 포트, 트랜짓 회선, 또는 BGP가 선택한 조합을 통해 완화 지점에 도달할 수 있다. 그런 경로 하나의 포화는 교환기 전체가 실패했음을 증명하지 않으면서 그 경로를 사용하는 네트워크에 영향을 줄 수 있다. 동결된 기록은 공급자 및 피어링 접점으로의 확대를 지원한다 [2]; 교환기 전체 장애를 상정하는 것을 지원하지 않는다. 교환기 근처에서 관찰된 큰 흐름 역시 어느 회원, 포트, 경로, 물리 링크가 결속 제약이었는지 식별하지 못한다. 정확한 귀속은 경로별 증거를 요구한다.

라우팅은 사건 후에 그려진 지도가 아니라 완화 시스템의 일부였다. 서비스 광고는 어느 에지가 패킷을 수용하는지를 결정했고, 경로 변경과 업스트림 협조는 부하를 이동시키거나 억제할 수 있었다. 피어링은 경로를 단축하고 인그레스를 분산시킬 수 있었고, 트랜짓은 도달성과 추가 용량을 제공할 수 있었다. 어느 쪽도 병목 지점이 될 수 있었다. 따라서 신뢰할 수 있는 사후 기록은 광고 변경, 지점별 트래픽, 인터페이스 카운터, 피어 및 트랜짓 협조 기록, 장애 도메인이 이동한 시점을 보여주는 타임스탬프를 보존해야 한다. 총 피크 속도만으로는 그 순서를 재구성할 수 없다.

측정 한계도 똑같이 중요하다. Cloudflare는 3만 개 이상의 참여 리졸버를 보았다고 밝히고, 약 100배 증폭의 쿼리-응답 패턴을 기술했다 [1]. 이는 자신의 관측 내에서의 규모를 확립할 뿐, 소스 자율 시스템의 완전한 인벤토리나 운영자 지식이 아니다. 완전한 소스 AS 분포, 방관자 혼잡의 양, 각 경로에 귀속될 수 있는 인과적 몫은 미지로 남는다. 공격이 “인터넷을 거의 망가뜨렸다”는 동시대 언어는 공급자 서사에 붙은 홍보적 프레임으로 다루어야 하지, 입증된 글로벌 장애 발견으로 다루어서는 안 된다 [2].

책임성은 각 참가자가 행사하고 문서화할 수 있었던 통제를 따라야 한다. Cloudflare는 애니캐스트 설계, 필터링, 경로 변경, 업스트림 협조, 자신이 측정한 것의 보고 정확성을 통제했다 [1][2]. 트랜짓과 피어링 파트너는 자신의 인터페이스, 고객 정책, 혼잡 대응, 협조 기록을 통제했다. 교환기 운영자는 공유 스위칭과 운영 대응을 통제했지만, 자신의 인프라에 결부된 증거 없이 공격 물량이나 장애를 배정받아서는 안 된다. 용량이 중요하다; 용량이 실제로 어디에 있었는지를 보여주는 라우팅 결정과 기록도 그렇다.

웹사이트 가용성은 DNSBL 가용성이 아니었다

첫 번째 가시적 서비스 실패는 구체적이었다: 트래픽이 Spamhaus의 접속을 포화시키고 웹사이트에 접근할 수 없게 만들었다 [1]. 이후 단계는 Cloudflare의 공급자 방향 환경과 지원 경로에 영향을 주었다 [2]. Spamhaus는 호스트, DNS 파트너, 지원 서비스에 대한 공격을 기술하면서도 분산 안티스팸 데이터는 계속 이용 가능했다고 밝혔다 [3]. 이 사실들은 동일한 사건 이력에 속하지만, 하나의 불가분 서비스를 기술하지는 않는다.

공개 웹사이트는 페이지, 연락처 정보, 설명, 운영 커뮤니케이션을 제공한다. DNS 기반 차단리스트는 서로 다른 쿼리 종단점, 복제본, 경로, 캐시, 사용자 의존성을 통해 데이터를 분산한다. 웹 프런트 도어의 상실은 메일 시스템이 차단리스트 답을 얻는 모든 경로를 제거하지 않고도 지원과 공개 상태 정보를 막을 수 있다. 반대로 차단리스트 데이터의 지속 가용성은 웹사이트와 지원 네트워크의 혼란을 사소하게 만들지 않는다. 영향은 서비스별로 기술되어야 한다는 뜻이다.

이 구분은 다운스트림 이메일 필터링에 대한 주장도 제한한다. 이용 가능한 증거는 글로벌 필터링이 중단되었음을 보여주지 않는다. Spamhaus의 성명은 인프라의 다른 부분에 대한 공격 동안 분산 데이터 서비스가 계속 운영되었다는 더 좁은 명제를 지지한다 [3]. 모든 사용자, 리졸버, 지역, 네트워크 경로가 끊김 없이 접근했음을 증명하지 않는다. 국지적 실패와 경로별 열화는 웹사이트 장애로부터 추론될 수 없는 것처럼 이것으로부터 지워질 수도 없다.

유용한 가용성 증거는 HTTP 도달성, 권한 DNS 건강, DNSBL 쿼리 성공, 업데이트 신선도, 지연, 오류율을 분리할 것이다. 여러 네트워크와 위치를 표본화하고, 어느 종단점과 경로가 테스트되었는지 기록하고, 단일 “온라인” 라벨 대신 시간대를 보존할 것이다. 공개 인시던트 커뮤니케이션은 그 성명이 웹사이트, 지원 공급자, 네임서버, 차단리스트 쿼리 서비스, 데이터 공행 중 무엇에 관한 것인지 식별해야 한다.

Spamhaus는 그 서비스 아키텍처와 복구 메시지의 정밀성을 통제했다. Cloudflare는 자신이 수용한 트래픽과 경로에 대한 완화를 통제했다. 어느 쪽도 원격 열린 리졸버나 스푸핑된 소스 패킷을 수용한 네트워크를 통제하지 않았다. 그 통제 경계를 가시적으로 유지하면 웹사이트 중단이 전 세계 DNSBL 실패로 팽창하는 것을 막으면서, 분산 데이터 평면이 계속 답하는 동안에도 지원 네트워크에 대한 공격이 운영 연속성을 위협할 수 있음을 인정한다.

2013년 전후의 표준

2013년 캠페인은 표준화 단체가 아직 식별하지 못한 통제 문제를 드러내지 않았다. 2008년에 공개된 RFC 5358은 위조된 피해자 주소와 공개 접근 가능한 재귀 서버를 이용한 DNS 증폭을 기술한다. 재귀를 의도된 클라이언트로 제한할 것을 권고하고, 응답 생성 서비스의 제한이 한 지점에서 반사를 다루고, 소스 주소 검증이 다른 지점에서 스푸핑을 다룬다는 점을 적시한다 [4]. 이 구분은 Spamhaus에 대한 올바른 동시대 기준이다: 리졸버 운영자와 위조 요청을 운반하는 네트워크는 동일한 실행 체인의 서로 다른 링크를 통제했다.

RFC 2827(BCP 38)은 2000년부터 고객 방향 에지에서 인그레스 필터링을 요구하여, 정당한 고객 프리픽스 밖의 소스 주소를 가진 트래픽이 전파되지 않게 했다 [5]. RFC 3704는 멀티홈 네트워크를 위한 운영 모델을 확장하며, 비대칭 라우팅이 단순 규칙을 복잡하게 만드는 경우 엄격 및 실현 가능 경로 역방향 검사와 다른 필터링 방법을 논의했다 [6]. 함께 이 문서들은 2013년 3월까지 두 관련 의무가 문서화되어 있었음을 보여준다: 무제한 재귀를 제공하지 말 것, 그리고 명백히 위조된 트래픽을 수출하지 말 것. 그것들은 어느 참가자가 무엇을 배치했고, 무엇을 알았고, 어떤 특정 패킷을 발생시켰는지 증명하지 않는다. 책임성은 여전히 경로별 증거를 요구한다.

이후의 자료는 오늘의 검증을 더 정교하게 해야 하며, 마치 2013년의 기준선인 것처럼 소급 적용되어서는 안 된다. DNS Cookies는 양쪽 종단이 지원하는 경우 스푸핑 저항을 더할 수 있다 [7]; ANY 답을 최소화하면 역사적으로 유용한 증폭 형태 하나를 줄일 수 있다 [8]; 이후의 권한 서비스 아키텍처 가이드는 규모에서의 복원력과 운영 설계를 다룬다 [9]. 어느 것도 의도하지 않은 재귀를 닫거나 위조 소스를 필터링하는 것을 대체하지 못한다.

RIPE 운영 가이드, MANRS 자료, DNS-OARC 발표, 측정 연구는 마찬가지로 비교, 테스트 방법, 지속 노출에 대한 증거를 제공한다 [14][15][16][17][18][19]. 그것들은 성숙한 보증이 오늘 어떤 모습인지 보여줄 수 있다. 그것들은 3월 18~27일 사건 동안 모든 이후 기법이 사용 가능했고, 균일하게 배치 가능했고, 실제로 배치되었음을 확립할 수 없다. 역사적 발견은 더 좁게 남아야 한다: 주요 통제 범주는 이미 공개되어 있었지만, 그 구현과 검증은 파편화되어 있었다.

운영자를 위한 검증 프로그램

신뢰할 수 있는 프로그램은 재현 가능한 주장에서 시작한다. 각 운영자는 모든 재귀 리스너를 소유자, 인터페이스, 주소 패밀리, 허용 클라이언트 범위, 소프트웨어 버전, 설정 출처, 변경 티켓에 매핑한 날짜가 기입된 인벤토리를 유지해야 한다. 무단 네트워크에서의 외부 프로브는 재귀 서비스를 받아서는 안 되고; 내부 테스트는 의도된 클라이언트가 여전히 해석됨을 보여주어야 한다. UDP와 TCP, IPv4와 IPv6, 그리고 흔한 대체 또는 간과된 인터페이스를 모두 테스트하라. 서명된 설정 스냅샷, 프로브 위치, 타임스탬프, 패킷 캡처, 예외 승인을 보존하라. 테스트된 개체군과 부정적 결과 없이 “재귀가 닫혔다”는 대시보드 주장은 증거가 아니다.

그런 다음 정책이 강제될 수 있는 에지에서 스푸핑 통제를 검증하라. 각 고객, 접속 세그먼트, 클라우드 테넌트 클래스, 피어링 또는 트랜짓 역할에 대해 기대되는 소스 프리픽스와 사용된 메커니즘—ACL, 유니캐스트 역방향 경로 검증, 실현 가능 경로 논리, 또는 동등한 통제—을 문서화하라. 고의로 무효인 소스로 승인된 테스트를 수행하고, 패킷이 통제된 경계를 떠나는지 기록하라. 라우팅 변경 후 반복하라. 멀티홈과 비대칭 경로는 한때 올바른 엄격 검사를 우회 또는 부수적 필터링으로 바꿀 수 있기 때문이다 [5][6]. 예외에는 소유자, 기술적 근거, 보완 통제, 만료일, 재테스트가 필요하다.

텔레메트리는 이 두 통제 평면을 연결해야 한다. 리졸버 로그 또는 표본화된 플로우 기록은 불필요한 사용자 데이터를 보존하지 않으면서 요청되지 않은 쿼리 속도, 요청된 이름과 유형, 응답 크기, 잘림, 속도 제한 조치를 식별해야 한다. 경계 텔레메트리는 인터페이스별·고객 정책별 스푸핑 드롭을 보여주어야 하고, 경로와 용량 기록은 반사 트래픽이 어디에 진입했는지 보여주어야 한다. 운영자는 다음에 답할 만큼의 상세를 보존해야 한다: 리졸버에 접근 가능했는가? 요청 소스가 위조되었을 수 있었는가? 어떤 응답을 생성했는가? 어느 링크가 그것을 운반했는가? 어느 통제가 바뀌었는가? AS별 어뷰즈 통지는 단순 IP 주소 목록이 아니라 UTC 구간, 목적지와 겉보기 소스, 프로토콜, 대표 패킷 증거, 측정 방법, 연락 가능한 케이스 식별자를 포함해야 한다.

통제는 가정되어서는 안 되고 행사되어야 한다. 운영자의 승인된 자산 전반에 걸쳐 예정된 외부 재귀 스캔, 대표 이그레스 지점에서의 소스 검증 테스트, 안전한 응답 크기 및 속도 제한 테스트, DNS·애니캐스트·트랜짓·커뮤니케이션 페일오버 훈련을 실행하라. 각 복구 전후의 관찰된 동작을 비교하라. 이후 메커니즘은 심층 방어로 포함될 수 있다: DNS Cookie 협상, 축소된 ANY 동작, 권한/재귀 역할 분리, 대규모 서비스 페일오버를 실제 배치 조건에 따라 테스트하라 [7][8][9]. 이후의 RIPE, MANRS, DNS-OARC 자료를 활용하여 오늘의 커버리지를 다듬으라. 특히 노출이 조직 경계를 넘어 지속될 때 그렇다 [14][15][17][19].

인시던트 기록은 탐지, 완화, 경로 변경, 업스트림 접촉, 용량 압박, 복구의 순서를 보존해야 한다. 애니캐스트 공급자는 어느 지점이 서비스를 광고했는지, 트래픽이 어떻게 이동했는지, 혼잡이 어디서 나타났는지, 어느 경로나 정책이 바뀌었는지 보여주어야 한다. 트랜짓 공급자는 고객 에지 필터링과 협조 증거를 제시해야 하지만, 그럴듯한 경로 위에 있었다는 이유만으로 공격 물량을 배정받아서는 안 된다. 교환기 운영자는 자신의 측정 범위 내에서만 포트 및 패브릭 관측을 보고해야 한다. 리졸버 운영자는 차단과 재테스트를 입증해야 한다. 접속 네트워크는 위조 소스 패킷이 더 이상 나가지 않음을 입증해야 한다. 서비스 소유자는 웹사이트 가용성, DNS 및 지원 호스트 가용성, 별도의 분산 데이터 서비스를 구분해야 한다; 하나의 녹색 상태가 모두를 대신해서는 안 된다.

마지막으로 거버넌스는 이러한 산출물을 반복 가능한 책임성으로 바꾸어야 한다. 각 실패한 테스트를 실질적 통제를 가진 운영자에게 할당하고, 노출에 기반한 복구 기한을 설정하고, 종료 전 독립적 재테스트를 요구하라. 커버리지 분모를 추적하라—수정된 리졸버나 차단된 패킷의 개수만이 아니라—그리고 신중하게 범위가 지정된 지표를 공개하라: 테스트된 자산, 방법, 관찰 시간대, 잔여 예외, 맹점. 분기별 표본화는 인수, 네트워크 재설계, 리졸버 업그레이드, 새 트랜짓, 대규모 경로 정책 변경 이후의 테스트로 보완되어야 한다. 연구와 동시대 측정은 표본화와 기대되는 실패 모드에 정보를 줄 수 있지만 [18][19], 운영자는 자신의 가동 중인 시스템에서 현재의 경로별 증거를 제출해야만 통과한다.

공개 기록의 한계

공개 기록은 2013년 3월 18~27일 캠페인을 둘러싼 전설보다 좁다. Cloudflare의 동시대 기록은 Spamhaus의 웹사이트에 접근할 수 없게 만든 초기 공격, 약 10Gbit/s의 트래픽, 이후 75~90Gbit/s 파도, 그리고 압력이 고객 주소에서 공급자 및 피어링 방향 인프라로 이동하면서 120Gbit/s 방향으로 확대되는 것을 기술한다.[1][2] 널리 반복되는 300Gbit/s 수치는 Cloudflare의 공급자 측 관측에 속한다. 그것은 공개 인터넷을 가로지르는 트래픽의 보편적 측정이 아니다. 마찬가지로 “인터넷을 거의 망가뜨렸다”는 것은 홍보적 프레임이지, 입증된 글로벌 장애 발견이 아니다.[2]

메커니즘은 총 규모보다 더 확립되어 있다. 공격자는 위조된 피해자 주소를 가진 DNS 요청을 공개적으로 도달 가능한 재귀 리졸버에 보냈다. 그 리졸버들은 요청보다 훨씬 큰 응답을 위조된 주소 쪽으로 반환하여, 작은 아웃바운드 패킷을 총 인바운드 플러드로 변환했다. Cloudflare는 ripe.net 데이터를 포함한 쿼리, 3만 개 이상의 참여 리졸버, 그리고 자신이 관찰한 요청-응답 형태에서 약 100배의 증폭을 보고했다.[1][2] 이는 귀속된 관찰이지 완전한 인구조사가 아니다. 재귀 서비스는 권한 DNS와도 구별되어야 한다: 운영적 결함은 무제한 재귀와 스푸핑 가능한 트래픽의 결합이었지, DNS 서버의 존재 자체가 아니었다.[4][10]

영향받은 서비스에도 같은 정밀성이 필요하다. Spamhaus의 웹사이트와 지원 공급자 경로가 표적이었지만, 분산 차단리스트 데이터는 구별되며 보고에 따르면 계속 이용 가능했다.[3] 완화 공급자, 업스트림, 교환기 방향 링크를 겨냥한 트래픽은 Spamhaus와 분쟁이 없는 당사자들에게 비용을 부과할 수 있었다. 그러나 동결된 기록은 특정 교환기에 특정 장애를 배정할 근거가 없고, 무관한 네트워크가 경험한 모든 혼잡을 측정하지도 않는다.[2][16][18]

다음은 미지로 남는다: 완전한 소스 AS 분포; 보편적 피크의 존재 여부; 방관자 영향의 전체 범위; 개별 리졸버, 접속, 트랜짓, 교환기, 완화 또는 피해자 운영자가 사건 전후에 무엇을 알았는지; 모든 행위의 결정적 귀속; 참가자 간 정확한 인과 배분. 이후의 체포 통지는 관련 맥락이지만, 모든 기술적 또는 법적 귀속 질문을 닫지는 못한다.[3] 이 간극들은 판단의 경계이지, 기록을 추론으로 채우라는 초대가 아니다.

책임성 시험

현실 계층의 책임성 시험이 중심이다: 이 사건은 가동 중인 인프라로서만 이해 가능하다. 노출된 재귀, 위조 소스 도달성, 응답 증폭, 애니캐스트 실행, 피어링 및 트랜짓 경로, 서비스 연속성 중 하나를 제거하면 책임성 명제는 사라진다. 여기서 정당성은 제도적 지위, 커뮤니티 수사, Spamhaus 차단리스트에 대한 도덕적 동의에서 오지 않는다. 운영자가 실제 장애 표면을 통제했고, 정확한 운영 기록을 유지했고, 자신의 시스템이 실제로 허용한 것을 복구했는지에서 온다.

첫 번째 시험은 능력이다. 리졸버 운영자는 재귀 서비스를 의도된 클라이언트로 제한하고, 재귀와 권한 역할을 분리하고, 노출을 인벤토리화하고, 남용적 응답 동작을 경계할 수 있다. RFC 5358은 캠페인 수년 전에 반사체 위험을 기술하고 재귀 제한을 권고했다.[4] 접속 네트워크는 불가능한 소스 주소를 가진 패킷이 외부로 나가지 못하게 할 수 있다. BCP 38과 BCP 84는 그 필터링 책임을 일반 및 멀티홈 환경에 구체화했다.[5][6] 어느 통제도 단독으로 모든 공격을 끝내지 못한다: 재귀 차단은 다른 곳의 스푸핑을 막지 못하고, 소스 검증은 노출된 리졸버를 복구하지 못한다. 책임성은 각 운영자가 실제로 행사할 수 있었던 통제를 따른다.

두 번째 시험은 증거다. 신뢰할 수 있는 리졸버 운영자는 날짜가 기입된 노출 스캔, 접근 통제 설정, 쿼리 및 속도 제한 기록, 어뷰즈 티켓 처리, 복구 후 검증을 제출할 수 있어야 한다. 접속 또는 트랜짓 운영자는 소스 주소 검증 정책, 고객 에지 테스트, 예외, 통지 기록, 실패 이후 검증을 보여줄 수 있어야 한다. 소스 검증 배치의 지속적 어려움은 그런 증명을 덜 중요하게 하는 것이 아니라 더 중요하게 한다.[15] 증거는 “모범 사례”라는 일반적 약속을 가동 중인 코드에 대한 감사 가능한 주장으로 바꾼다.

Cloudflare는 자신의 애니캐스트 분산, 스크러빙 선택, 경로 변경, 용량 결정, 피어 및 트랜짓 공급자와의 협조, 자신이 측정한 것의 보고 정밀성을 통제했다.[1][2] 애니캐스트는 부하를 분산할 수 있었지만, 여유가 다른 링크나 지점으로 장애 경계를 옮길 수도 있었다. 피어, 교환기, 업스트림은 협조와 혼잡 대응을 통제했지만, 경로별 증거 없이 공격 물량이나 책임을 배정받아서는 안 된다. Spamhaus는 서비스 아키텍처, 복구 커뮤니케이션, 웹사이트와 분산 데이터의 구분을 통제했지만, 원격 리졸버나 스푸핑 트래픽을 허용한 네트워크는 통제하지 않았다.

세 번째 시험은 외부효과다. 하나의 리졸버는 적은 트래픽만 내보낼 수 있고, 하나의 접속 네트워크는 얇은 위조 요청 스트림만 통과시킬 수 있다. 그러나 수천 개의 개별적으로 방치된 통제가 링크를 포화시키는 플러드로 결합할 수 있다. 따라서 로컬 설정은 운영자 자신의 네트워크 밖에 비용을 만든다. AS별 어뷰즈 통지, 열린 리졸버 인벤토리, 스푸핑 테스트, 속도 제한 텔레메트리, 트랜짓 협조 로그, 경로 변경 기록, 사후 검증은 관찰된 동작에서 복구까지의 실용적 사슬을 제공한다.[16][17][19]

이후의 표준은 2013년을 다시 쓰지 않으면서 그 증거 모델을 더 정교하게 한다. DNS Cookies는 지원되는 교환에서 스푸핑 저항에 도움이 될 수 있다; 최소 ANY 응답은 매력적인 응답 형태 하나를 줄인다; 이후의 권한 서비스 가이드는 복원력 있는 대규모 아키텍처를 다룬다.[7][8][9] 이는 캠페인 동안 모든 이후 통제가 동일하고 배치 가능한 형태로 존재했음의 증명이 아니라 비교 지점이다. 공정한 질문은 2013년의 운영자가 미래의 모든 RFC를 예상했는지가 아니다. 이용 가능한 통제가 사용되었고, 한계가 문서화되었고, 시정 작업이 검증되었는지이다.

결론

Spamhaus 캠페인이 중요한 이유는 단일한 극적 파이프가 아니라 분산된 책임성 실패를 드러냈기 때문이다. 피해자, 반사체, 스푸핑 네트워크, 완화 플랫폼, 상호연결 조직은 서로 다른 통제를 보유하고 서로 다른 증거를 만들었다. 어떤 슬로건도 그 통제들을 관찰된 패킷과 운영 기록에 매핑하는 것을 대신할 수 없다.

그 접근은 Spamhaus의 정책 역할을 지지하지도 비난하지도 않는다. 더 좁은 질문을 한다: 누가 실행 가능한 경로를 바꿀 수 있었고, 무엇을 증명할 수 있었으며, 복구가 회피 가능한 피해를 외부로 수출하지 않으면서 서비스 연속성을 보존했는가. 기록이 답할 수 없는 곳에서 결론은 미지로 남아야 한다. 운영자가 실질적 통제를 보유한 곳에서 책임성은 제도적 수사나 소급적 확실성이 아니라 감사 가능한 조치를 요구한다.

출처

1. https://blog.cloudflare.com/the-ddos-that-knocked-spamhaus-offline-and-ho/
2. https://blog.cloudflare.com/the-ddos-that-almost-broke-the-internet/
3. https://www.spamhaus.org/resource-hub/ddos/second-arrest-in-response-to-ddos-attack-on-spamhaus/
4. https://www.rfc-editor.org/rfc/rfc5358.html
5. https://www.rfc-editor.org/rfc/rfc2827.html
6. https://www.rfc-editor.org/rfc/rfc3704.html
7. https://www.rfc-editor.org/rfc/rfc7873.html
8. https://www.rfc-editor.org/rfc/rfc8482.html
9. https://www.rfc-editor.org/rfc/rfc9199.html
10. https://www.rfc-editor.org/rfc/rfc1034.html
11. https://www.rfc-editor.org/rfc/rfc6891.html
12. https://www.rfc-editor.org/rfc/rfc4787.html
13. https://www.rfc-editor.org/rfc/rfc8767.html
14. https://www.ripe.net/publications/docs/ripe-823/
15. https://manrs.org/2023/04/why-is-source-address-validation-still-a-problem/
16. https://ripe67.ripe.net/presentations/133-RW-DNS-Amplification-RIPE67.pdf
17. https://www.dns-oarc.net/files/pres/Mitchell-CWRU-13_12_03.pdf
18. https://arxiv.org/abs/1310.4216
19. https://labs.ripe.net/author/giovane_moura/dissecting-dns-defenses-during-ddos-attacks/