TL;DR

  • TCP·UDP IP 비교와 TLS 지속 시간/TCP 왕복 시간(RTT) 비율을 결합하면 주거용 프록시를 IP 차단 목록 없이 탐지할 수 있다는 주장임.
  • 대부분의 주거용 프록시 제공업체가 UDP를 지원하지 않으며, WebRTC가 UDP를 사용하므로 브라우저 기반 클라이언트의 IP 불일치를 확인할 수 있음.
  • TCP와 UDP IP가 서로 다른 자율 시스템 번호(ASN)에 있으면 프록시의 주요 경고 신호이며, 같은 ASN과 동일한 /24 대역이면 이동통신망일 가능성이 큼.
  • UDP IP가 없을 때는 TLS 지속 시간/TCP RTT 비율이 3.0 초과하면 프록시일 가능성이 높고, 관찰된 프록시에서는 대체로 6~12배 범위임.
  • Soax, BrightData, OxyLabs와 자체 구축한 Android 프록시 장치 및 명령·제어(C2) 환경에서 테스트했으며, 완벽하지는 않지만 IP 전체를 차단하지 않는 정밀한 탐지 방식이라는 결론임.

문제 제기와 기본 원리

  • 온라인 범죄를 줄이는 데 도움이 될 수 있는 1월의 이상 징후를 공유하는 내용이며, 주거용 프록시 탐지 방법을 제시함.
  • 확인한 대부분의 주거용 프록시 제공업체가 UDP를 지원하지 않음.
  • UDP는 WebRTC가 사용하는 프로토콜이며, 2021년부터 브라우저의 핵심 기능에 포함됨.
  • 따라서 클라이언트가 Chrome, Firefox, Safari를 사용한다고 하면 WebRTC가 존재하는 구조임.

TCP·UDP IP 주소 수집

  • 첫 번째 서브도메인을 만들어 클라이언트의 TCP IP 주소를 수집함.
  • AAAA 레코드를 제공하지 않으면 IPv4로 강제할 수 있으며, 이후 비교를 쉽게 만드는 방식임.
  • 두 번째 서브도메인을 만들어 클라이언트의 UDP IP 주소를 수집함.
  • 이 과정에서는 자체 STUN 서버를 실행하는 방식이 필요함.
  • 변조 저항성을 높이기 위해 STUN 서버가 IPv4 주소와 일부 추가 정보를 암호화한 뒤 IPv6 ICE 후보(ice candidate)로 반환함.
  • 이 방식은 우회적이지만 백엔드 서버 간 통신이 병목이 되는 문제를 피하면서 값을 포착하고 암호화해 반환하는 구조임.

TCP와 UDP IP가 모두 있는 경우

  • 두 IP 주소가 동일함: 주거용 프록시가 아닐 가능성이 큼.
  • 두 IP 주소가 다르지만 동일한 ASN과 동일한 /24 대역에 있음: 이동통신망일 가능성이 큼.
  • 두 IP 주소가 서로 다른 ASN에 있음: 주요 경고 신호임.
  • 주거용 프록시 사용자는 WebRTC를 끄라는 안내를 반복적으로 접해온 경우가 많음.
  • 이 문제가 2010년대 중반에 크게 노출된 뒤에도 WebRTC 유출을 두려워하는 사용자가 많음.
  • 한 주소가 Cisco Web Umbrella 또는 zScaler에 속하고 다른 주소가 주거용이면 기업 보호 방화벽 뒤에 있는 상황일 수 있음.
  • 엄밀한 의미의 프록시는 아니지만 이 알고리즘에서는 프록시로 판정될 수 있음.
  • 위협 모델에 따라 허용 목록에 넣을 수 있는 유형임.

TCP IP만 있는 경우

  • UDP IP를 확보하지 못하면 TLS 지속 시간/TCP RTT > 3.0 조건을 핵심 판별 기준으로 사용함.
  • 많은 주거용 프록시는 출구 지점에서 연결을 분할함.
  • 원본의 TCP 소켓이 출구에서 종료되므로 Linux TCP_INFO는 원본과 출구 사이의 RTT만 추정함.
  • 출구가 실제 클라이언트로 TLS 핸드셰이크 바이트를 전달하므로, ClientHello 핸드셰이크 완료까지의 시간에는 숨겨진 프록시 체인이 포함됨.
  • 비정상적으로 높은 TLS 지속 시간/TCP RTT 비율이 이러한 연결 분할을 드러냄.
  • 판정 기준은 다음과 같음.
  • TCP == UDP: 프록시가 아님.
  • TCP ≈ UDP: 동일한 ASN에 있으면 프록시가 아님.
  • TCP != UDP: 프록시 또는 zScaler 유형일 수 있으며, 필요에 따라 허용 목록에 추가함.
  • UDP 없음 + TLS/TCP RTT 비율 < 3: 프록시가 아닐 가능성이 큼. 이 경우 비율이 낮을수록 좋음.
  • UDP 없음 + TLS/TCP RTT 비율 > 3: 프록시일 가능성이 큼. 관찰된 대부분의 사례는 6~12배 범위임.

테스트와 정확도

  • 지난 6개월 동안 이 방식을 사용했으며, 주로 Soax, BrightData, OxyLabs 프록시를 대상으로 작업함.
  • 자체 ProxyDevice(Android)와 C2를 구축해 개인 네트워크에 연결한 뒤에도 프록시를 탐지함.
  • 이 방식은 IP 주소를 차단 목록에 넣을 필요가 없다는 점이 핵심임.
  • 정상 사용자가 프록시와 동일한 IP에서 접속할 수 있어 IP 차단 방식은 효과가 제한적임.
  • 프록시 클라이언트는 동일한 IP를 사용하더라도 매우 다른 특성을 보임.
  • NetAcuity, MaxMind, StaticList 방식처럼 IP 전체를 차단하는 대신 개별 연결을 정밀하게 차단하는 구조임.
  • 모든 환경에서 100% 정확하다고 주장할 수는 없지만, 제한된 경험을 기준으로 매우 높은 정확도를 보이는 방식이라는 평가임.
  • 완벽하지 않더라도 아무것도 하지 않는 것보다 나은 탐지 수단이며, 목적은 이러한 방식으로 도움을 주는 데 있음.
  • 구축한 시스템과 테스트, 증거, 코드를 공유할 의향이 있다는 내용임.