요약

  • RIPEstat의 Abuse Contact Finder API 공식 문서는 스스로 반환되는 어뷰즈 연락처가 '많은 경우 부정확하거나 이용할 수 없다'고 경고하고 있습니다.
  • 2015년 이전에는 이 도구가 데이터의 출처에 따라 별점 1~5개의 신뢰도 등급을 표시했지만, 이 등급이 제거되면서 자격 정보 없이 단 하나의 주소만 남게 되었습니다.
  • 검색은 하위에서 상위로 진행되며 계층 구조에서 가장 먼저 발견된 abuse-c를 반환하는데, 이것이 반드시 실제 조치를 취할 수 있는 운영자의 연락처는 아닙니다.
  • 문서화된 버그들로 인해 플레이스홀더 데이터 때문에 레지스트리 대체 주소가 부당하게 반환되는 사례가 있었습니다.
  • 라우팅 계층의 정확성은 등급 제거 이후 독립적인 측정이 공개된 바가 없습니다.

공식 문서에 명시된 경고

RIPEstat 데이터 API의 Abuse Contact Finder 엔드포인트는 단 하나의 기능을 가지고 있습니다: 프리픽스, IP 주소 또는 ASN에 대해 전용 어뷰즈 연락처 주소와 권위 있는 RIR을 반환하는 것입니다. 그 문서에는 중요 인프라 도구가 거의 감히 쓰지 않는 문장이 들어 있습니다: 주된 목적은 어뷰즈 연락처 정보를 반환하는 것이며, '이 정보가 많은 경우 부정확하거나 이용할 수 없다는 점에 유의하십시오' [0].

이 면책 문구는 형식적인 유보가 아닙니다. RIPE NCC 자신이 문서화한 10년간의 기술적 역사를 요약한 것입니다: 선언적 데이터 위에 구축된 라우팅 계층으로서, 그 품질은 한 번도 독립적으로 측정된 적이 없으며, 유일하게 공개된 신뢰도 지표는 삭제되었습니다.

철수된 별점 다섯 개 등급

2015년 이전 RIPEstat의 Abuse Contact Finder는 연락처가 데이터베이스에서 발견된 위치에 기반한 별점 다섯 개 신뢰도 등급을 표시했습니다. 별 다섯 개: 조회된 IP 주소에서 ripe-563을 준수하는 abuse-c. 네 개: 관련 객체에 있는 abuse-mailbox. 세 개: remarks 속성에서만 발견된 연락처. 두 개: 더 구체적인 객체나 상위 객체에서만 발견된 abuse-mailbox로서, '올바른 연락처가 아닐 수도 있음'. 하나: 올바를 가능성이 '낮은' 연락처 [1].

2015년 이후 이 도구는 '더 이상 등급 휴리스틱을 제공하지 않는다. RIPE 563 문서에 명시된 대로 abuse-c의 이메일 주소만 표시한다' [1]. 불확실성은 등급과 함께 사라진 것이 아니라, 불확실성의 표시가 사라진 것입니다. 신고자는 이제 API 수준의 일반적인 면책 문구와 함께 자격 정보가 없는 주소를 받게 됩니다.

가장 먼저 발견된 abuse-c가 반드시 올바른 수신자는 아니다

RIPE NCC의 어뷰즈 연락처 검색 도구는 하위에서 상위로 작동합니다: INET(6)NUM 객체에 연결된 ORGANISATION 객체에서 abuse-c 참조를 검색하고 '가장 먼저 발견된 것을 반환한다. abuse-c 참조가 발견되면 그것만 반환되며', 과거의 abuse-mailbox 속성은 고려되지 않습니다 [2].

이 기계적 선택에는 구조적 결과가 있습니다: 반환되는 연락처는 데이터베이스에 기록된 가장 구체적인 것이지, 반드시 실제로 어뷰즈를 차단할 수 있는 운영자의 연락처가 아닙니다. 재판매되거나 임대된 IP의 경우 가장 구체적인 것은 우편함이 비활성인 최종 고객일 수 있는 반면, 상위 운영자가 트래픽을 제어합니다. 데이터베이스는 이 둘을 구분하지 않습니다.

문서화된 버그의 역사

과거의 휴리스틱 Abuse Finder는 조회당 RIPE 데이터베이스에 대해 30~150개의 별도 쿼리를 수행했습니다 [3]. 문서화된 두 가지 버그가 이 체인의 취약성을 보여줍니다: 플레이스홀더 데이터 때문에 '도구가 레지스트리의 대체 어뷰즈 주소를 빈번하고 부당하게 반환했고', 객체 유형 간에 기본 키와 인덱스가 고유하지 않아 입력과 무관한 결과가 반환되었습니다 [3].

RIPE NCC 자신은 과거의 행동을 '가능한 최선의 제안'으로 표현하며, 이것이 '신뢰할 수 없고 논쟁의 여지가 있는 것으로 밝혀졌다'고 인정했습니다 [2]. 또한 데이터베이스를 직접 조회하고 발견된 모든 주소로 신고를 보내는 방식으로 도구를 우회하는 것을 권하지 않으며, 이 우회를 역효과적이라고 판단합니다 [2]. 그 문서는 '데이터베이스에서 발견된 다른 모든 이메일 주소로 메시지를 복사한다고 해서 신고가 더 빨리 처리되지 않는다'고 명시합니다 [4].

검증이 측정하는 것 — 그리고 측정하지 않는 것

정책 제안 2017-02는 abuse-c 뒤의 정확성 문제를 문서화했습니다: ripe-563에는 어떠한 검증도 규정되어 있지 않았고, RIPE NCC는 매년 수백 건의 무효한 연락처 보고를 받았으며, 예비 무작위 테스트는 약 70,000개의 개별 속성 중 10~25%의 abuse-mailbox 속성이 '부정확하거나 비활성일 수 있다'는 것을 시사했습니다 [5].

2017-02가 도입한 자동화된 검증은 구문, 도메인 및 메일 서버 구성을 확인하며, 스스로 '거짓 음성과 거짓 양성이 가능하다'고 인정합니다 [5]. RIPE NCC는 이를 솔직하게 표현했습니다: '우리 검증의 성격은 RIPE 데이터베이스에 기능하는 이메일이 존재하고, 이메일을 수신할 수 있는 서버와 일치하는지 확인하는 것입니다. 운영자가 수신한 어뷰즈 보고서를 어떻게 처리하는지에 대해서는 우리가 말할 수 있는 것이 없습니다' [6]. 2019년 RIPE 80에서는 77,168개의 개별 주소 중 71,711개(93%)가 자동화된 검증을 통과했고 5,457개(7%)가 실패했으며 — 나열된 실패 모드에는 다른 조직의 가짜 이메일, 한 번도 읽히지 않는 우편함, 존재하지 않는 직원 등이 포함되었습니다 [7].

즉, 검증은 전달 가능성을 측정합니다. 라우팅의 정확성 — 그것이 올바른 우편함인지, 올바른 주체인지 — 는 어떤 메커니즘으로도 테스트되지 않습니다. 데이터베이스 내의 유효한 abuse-c가 '신고의 올바르거나 효과적인 목적지임을 보장하지 않습니다' [6].

한 번도 제도화되지 않은 정정

이 도구에 관한 RIPE Labs 페이지에서 RIPE NCC 직원의 답변은 자원 보유자가 제공하는 어뷰즈 연락처를 '사용자나 RIPE NCC가 정정하거나 검증할 수 있는 절차가 존재하지 않는다'고 인정했습니다 [1]. 오늘날 RIPE NCC는 무효하거나 누락된 연락처를 보고하기 위한 양식을 제공합니다 [8]. 하지만 유효하지만 잘못된 연락처의 정정 — 신고자에게 가장 교활한 경우 — 은 여전히 문서화되어 있지 않습니다.

신고자에게 이것이 의미하는 것

RIPE NCC의 공식 가이던스는 경고합니다: RIPEstat이 표시하는 연락처는 해당 IP 주소가 속한 네트워크의 연락처로 — 'ISP 또는 다른 네트워크 운영자이며, 어뷰즈 행위자가 아닙니다!' [8]. 따라서 세 계층의 불확실성이 겹칩니다: 도구가 올바른 주체를 반환하는가(한 번도 측정되지 않은 라우팅 정확성), 우편함이 존재하는가(연간 검증되는 전달 가능성), 누군가 그것을 읽는가(한 번도 테스트되지 않은 응답성). 신고자는 사후에 이 세 가지 실패를 구분할 공개적 수단이 전혀 없습니다.

이는 연간 검증, 측정과 구제의 분리, RIPE-858 구제 경로에 관한 BTW의 이전 보도에서 문서화된 것과 동일한 실이며, 여기서는 신고자가 가장 먼저 접하는 계층 — 검색 도구 자체 — 에서 그 실을 살펴봅니다. 그 도구의 정확성은 다른 모든 고리가 적어도 하나의 지표를 가진 체인에서 측정되지 않은 고리입니다.