▲

죽은 토렌트 트래커를 되살리고 300만 피어를 찾은 경험

 (kianbradley.com)
1P by GN⁺ 14시간전 | ★ favorite | 댓글 1개
  • 작성자는 죽은 토렌트 트래커 도메인을 획득하여 직접 opentracker를 운영함
  • 트래커를 부활시키자 1.7백만 개 토렌트와 3.1백만 피어가 자동으로 연결 시도함
  • BitTorrent 프로토콜에서 트래커는 중앙화된 역할을 하며, 트래커가 없으면 파일 공유가 어려움
  • Mainline DHT 등 탈중앙화 대안도 있으나, 한계와 취약점 존재함
  • 법적 위험성 때문에 최종적으로 도메인과 VPS를 삭제한 경험임

개요

  • 작성자는 Linux ISO 등 토렌트를 다운로드하던 중 트래커 대부분이 죽어있는 상황을 발견함
  • "죽은" 트래커 도메인(udp://open.demonii.si:1337/announce)이 등록되지 않은 것을 알게 됨
  • 해당 도메인을 구입하고 VPS에서 opentracker를 설치해 실제 트래커를 운영해봄

BitTorrent 트래커란 무엇인가

  • 트래커는 BitTorrent 프로토콜에서 피어(사용자) 간 연결을 도와주는 중앙 서비스 기능 수행
  • 트래커가 운영되지 않으면, 사용자가 서로를 찾지 못해 파일 공유가 불가해짐
  • 트래커가 유지되지 않거나 법적 압박을 받을 경우 사용자들이 불편 경험

탈중앙화 대안(DHT)과 한계

  • Mainline DHT는 트래커 없이 분산 네트워크 방식으로 피어 검색 지원
  • DHT는 부트스트랩 노드 의존성, Sybil 공격 취약성 등 한계 존재
  • 작성자가 테스트한 토렌트의 경우, DHT에서도 피어를 찾지 못함

트래커 직접 구축 과정

  • 도메인을 구매 후 익명 VPS에 연결함
  • opentracker(가장 많이 쓰이는 토렌트 트래커 소프트웨어)를 사용해 트래커 서버를 빠르게 구축함
  • 시스템 실행 후, UDP 1337 포트로 대량의 트래픽이 유입됨 확인
  • 한 시간 만에 173만 개 토렌트, 315만 피어가 연결 시도 통계로 나타남

트래커 통계(Stats)

  • 1,735,538개의 토렌트, 3,155,701명의 피어, 1,342,504명의 시더(완전체), 244,224건의 다운로드 완료 기록 확인
  • TCP/UDP 연결, announce, scrape 등 다양한 요청 유형에 대한 데이터 집계
  • 접속 및 에러 통계도 함께 분석, 일부 파라미터 오류(400 Invalid Parameter) 및 '404 Not Found' 오류 소량 존재

법적 쟁점

  • 공공에 공개된 웹사이트 및 .torrent 파일 홍보, 광고 수익 등은 저작권 유도행위로 법적 문제가 됨
  • 단순히 트래커 인프라만 운영하는 것은 법적 책임 소지가 모호함. 그러나 의도 증명이 쟁점이 될 수 있음
  • 무료 및 저작권 있는 토렌트 둘 다 이 트래커를 사용함을 인지

최종 결론

  • 법적 우려 및 실명 결제 방식(카드 결제 등)으로 인해 빠르게 VPS와 도메인을 폐기함
  • 여전히 미사용 트래커 도메인이 많아, 관심 있는 사용자가 쉽게 등록할 수 있음을 안내
  • open.demonii.si 등 공개적으로 등록 가능한 트래커 도메인 소개

마무리

  • BitTorrent 생태계에서 중앙화된 트래커 인프라의 역할과 취약성, 그리고 탈중앙화 기술의 한계를 경험적으로 전달함
  • 오랜 시간 죽어있던 트래커 도메인을 부활시켜도 즉시 수백만 피어가 연결을 시도함이 인상적임
  • 인프라 운영의 법적 위험성에 대한 주의 사항 공유
▲
GN⁺ 14시간전  [-]
Hacker News 의견

  • 이 경우에는 트래커를 직접 호스팅하는 게 아니라 들어오는 연결만 보는 것이라서 불법일 이유가 별로 없다고 생각함. 트래커를 돌린다고 해도 실제로 불법인지 입증하기 쉽지 않음. opentrackr 같은 걸 호스팅하는 건 마치 검색 엔진을 운영하는 것과 비슷함. 법적 삭제 요청에 어떻게 대응하느냐가 핵심 포인트임. 트래커 자체는 꽤 단순한 서버 소프트웨어임. 이런 게 불법이 되는 건 좀 이상하다고 생각함

    • “이게 합법이냐?”라는 질문보다는, “소송을 얼마나 당할 확률이 높냐?”가 훨씬 실질적인 질문임. 민사소송은 합법이든 아니든 일단 당할 수 있음. 변호사들이 타깃으로 삼으면 아주 귀찮아짐
    • 일부러 범죄를 도운 경우, 스스로 범죄를 저지른 것과 마찬가지로 간주됨. 미국 연방법(18 USC 2a, 참고 링크)에 따라 단순한 소프트웨어라는 이유로 잘못된 행동을 해도 면책이 되는 건 아님. 몇 가지 안전한 법적 예외 조항이 존재하기는 하지만(특히 저작권 관련), 전반적으로 타인의 범죄를 돕는다는 건 그 자체로도 범죄라고 생각해야 함. 나는 변호사는 아니지만 범죄를 돕는 건 피하는 게 무난함
    • 트래커(비트토렌트 피어 간 조율을 위한 서버)와 "트래커"(.torrent 파일과 magnet URI를 호스팅하는 사이트)는 구분해야 함. 실제로 법적 삭제 조치는 후자, 즉 .torrent 파일이나 링크를 호스팅하는 사이트에 집중되어 있었음
    • (전문가는 아니지만) 상황에 따라 합법이기도, 불법이기도 할 수 있음. 만약 삭제 요청에 응답하지 않는다면 불법 쪽으로 기울 수 있음. 반대로 삭제 요청에 응답하고 해시를 블랙리스트 처리한다면 대부분 괜찮을 가능성이 큼. 물론 관할 지역과 해시-아이피:포트의 연결 자체가 배포/조력으로 간주되는지에 따라 다름(TPB 사례 참고). 내가 아는 한 분은 수 년간 대형 트래커를 운영하면서 삭제 요청을 블랙리스트 처리해서 아직도 문제없이 지내고 있음
    • 음악/영화 업계가 전반적으로 P2P를 싫어해서 2000년대에 사실상 P2P 생태계를 죽였다고 봄. 언젠가는 다시 논의할 필요가 있다고 생각함. 라이선스 획득이 쉬워진 시대이니 DRM 집행만 잘 한다면 걱정할 필요 없다고 생각함

  • 다양한 비트토렌트 클라이언트들이 존재하고, 그 중 상당수는 안전하지 않은 언어로 작성되어 있음. 그런 상황에서 악의적 트래커가 일부 클라이언트를 공격하는 것도 가능하지 않을까 하는 의문이 생김. 만약 트래커로부터 비정상적인 데이터를 받으면, 일부 클라이언트가 제대로 대응하지 못하고 취약한 동작을 보일 수 있다는 생각이 듦

    • Transmission의 경우 CVE-2018-5702로 알려진 DNS rebinding 취약점으로 인해 원격 코드 실행이 가능했던 적이 있음. 트래커를 통한 공격은 실제로 존재하는 리스크라고 봄
    • 대부분 사용자들이 사용하는 토렌트 클라이언트는 libtorrent라는 라이브러리의 래퍼임. libtorrent는 테스트도 잘 되어 있고 보안 감사도 받은 라이브러리라서 신뢰성이 높음
    • 나도 취미로 클라이언트를 만들어봤는데, 결론적으로는 '그렇다'임. 서버에서 온 입력 데이터를 다루고, 파일시스템과도 복잡히 상호작용함. 메모리 안전 언어로도 겨우 돌아가게 만들기 어렵고, C나 C++로 완전히 안전히 만드는 건 상당히 까다로운 작업이라고 느낌
    • Rust로 작성하지 않은 다른 프로그램들도 많으니 너무 걱정할 필요 없다는 생각이 듦(혹은 모든 소프트웨어가 위험할 수 있다고 볼 수도 있음)
    • 이런 기술적인 위협을 본문에서 좀 더 탐구해줬으면 좋겠음

  • 결국, 도메인을 등록하고 특정 DNS 레코드를 게시하는 것만으로도 원하는 IP를 DDoS할 수 있다는 의미가 됨

    • 일반 인기 클라이언트의 announce 주기는 꽤 김(대략 30분). 하지만 피어가 3백만 명이라면, 그 자체로 네트워크 부담이 생길 수 있음
    • 실제로 그 정도로 심각한 리스크인가 싶음. 내가 써본 비트토렌트 클라이언트들은 연결이 실패하면 최소 60초 정도 대기함. 죽은 트래커 도메인을 구입해서 남의 IP로 연결을 유도하더라도, 그 포트에서 서비스가 돌아가는 것도 아니고 트래커 프로토콜을 안 쓰면, 수백만 클라이언트가 몰려도 과연 진짜로 큰 문제가 될지 의문임

  • 매일 갱신되는 트래커 마스터리스트가 여기에 있음. 이를 이용해서 죽은 트래커를 추가로 찾는 것도 가능함

  • 내 첫 번째 의문은 비트토렌트 클라이언트 중 얼마나 많은 곳에서 취약한 파싱 코드를 갖고 있냐는 점임. 누군가 도메인을 악의적으로 등록해서 클라이언트를 감염시킬 수 있지 않을까 하는 생각임

    • Jon Evans의 소설 “Invisible Armies”와 그 소설에서 저자가 P2P 소프트웨어의 버그/백도어를 사용해서 시스템을 장악하는 장면이 떠오름
    • utorrent v2.1은 아직도 많은 사람들이 사용 중인데, 확실히 취약점이 존재하는 상황임

  • 이 상황은 Cloudflare가 1.1.1.1 IP 주소를 가져갔을 때와 비슷함. 도메인이 열리자마자, 수많은 자동화된 스크립트나 봇들이 그 쪽으로 트래픽을 쏟아부었던 일이 있음

    • Cloudflare가 그 주소를 어떻게 확보했는지 궁금함

  • 예전에 실험 삼아 짧게 개인용 트래커를 운영한 적이 있음. 실제 운영은 아주 짧았고, 트래커 동작 방식은 깊이 파악하지 않았음(Rust로 만든 Aquatic tracker에 webtorrent 지원을 요청해서 써봄 Aquatic 링크). 트래커가 주로 뭘 추적하는지, 피어 간 정보 교환에서 직접적으로 무언가를 알 수 있는지 의문이 듦. 내 추측에는, 단순히 해시나 마그넷 값만 가지고 피어들의 만남을 주선함. 마그넷 자체도 꼭 식별 정보를 포함할 필요는 없다고 생각함(많은 마그넷 링크는 사람 읽을 수 있는 설명도 포함함). 트래커가 해시를 받아서 직접 해당 파일을 다운로드해서 확인할 수도 있겠으나, 직접 다운받지 않는 이상 실제로 어떤 컨텐츠인지 제대로 알긴 힘듦. 마그넷 링크에서 실제로 피어 매칭에 필수적인 요소는 무엇인지, 트래커가 사람이 읽는 필드를 무시하거나 차단해서 중립성을 유지할 수 있는지 궁금함

    • 트래커는 토렌트의 info hash만을 다룸. 파일 이름, 설명, 콘텐츠 리스트 등 그 어떤 것도 다루지 않음. 예를 들어 opentracker는 화이트리스트와 블랙리스트 모드 둘 다 지원함. 대부분 오픈 트래커(예: torrent.eu, opentrackr.org 등)는 블랙리스트 방식으로 운영되며, 거의 모든 사용자들이 (거의) 모든 컨텐츠를 찾을 수 있도록 허용함
    • 트래커는 실제로 추적하는 컨텐츠를 알 수 있음. 내가 예전에 운영하던 TV 프로그램 트래커는 각 사용자의 업로드/다운로드 비율까지도 추적해서 관리함

  • 러시아, 중국, 이란 등에서 도메인을 등록하고 Alibaba에 사이트를 호스팅하면 됨. 미국에서 법적 압박을 넣어도 그 쪽 국가에 전달되는 순간 완전히 무용지물이 됨. 실제로 그런 곳에선 법적 대응이 거의 힘듦

  • 변호사는 아니지만, 미국 내에서 컨텐츠 중립적 트래커를 운영하는 건 합법으로 알고 있음. 다만, 다른 국가에서는 확실히 불법일 수 있으며, VPS 위치와 TLD 국가(.si 등)에 따라 차이가 있음

    • 검색해보면 미국 사법당국에 의해 강제 종료된 트래커 사례가 있음(EliteTorrents, 2005년, 관련 기사). 아마 다른 사례들도 존재할 듯. 민사소송(예: MPAA 등 단체의 손해배상 청구 소송) 등으로 폐쇄된 트래커도 많음. 전체 리스트 대부분이 저작권 컨텐츠라면 미국에서도 얼마든지 폐쇄될 수 있음
    • 예전에 .si에서 운영된 대형 퍼블릭 트래커가 있었음. 슬로베니아에서 거의 20년 동안 온라인 경험자라면 한 번쯤 써봤을 정도임. 이 트래커는 법적 통보로만은 사라지지 않았음
    • VPS는 cockbox.org 기반(본문 참고)에 위치해 있는데, 이 회사는 본사 위치가 몰도바라고 함

  • 만약 누군가 suprnova 도메인을(2004년에 문을 닫은) 다시 구입한다면, 아직 살아있는 시더가 있다면 예전 다운로드 작업을 이어받을 수 있을까 궁금함. DHT 이전 시대에 생성된 것이라면 영향을 받는지도 궁금함. DHT가 예전 토렌트까지 커버할 정도로 “역사적” 기능이 있는지도 알고 싶음

    • DHT는 진짜 “역사적”임. 즉, 토렌트 생성 시점과 무관하게 infohash만 일치하면 동작함. 단, 보통 프라이빗 트래커에서 생성된 토렌트는 “private” 플래그가 켜져 있어서, DHT, PEX 등 일부 기능에서 제외됨. 이 플래그는 직접 삭제할 수 있지만 DHT가 작동하려면 시더 쪽에서도 이 플래그를 풀어야 함
    • DHT는 클라이언트가 해당 기능을 켰다면 언제든 동작함. 만약 예전 시더도 새 버전 클라이언트로 업그레이드했다면, 메타데이터가 자동으로 DHT에 공유될 수 있음
    • 이론적으로는, 위와 같은 상황이 충분히 가능함
답변달기