물리 법칙은 거짓말을 하지 않는다: TCP RTT로 프록시 탐지하기

안녕하세요. 풀링포레스트 테크리드 김영태입니다.

백엔드 개발자로서 인프라를 운영하다 보면 가장 골치 아픈 순간 중 하나가 바로 '보이지 않는 적'과의 싸움일 때입니다. 며칠 전, 저희 팀은 특정 국가 대역에서 들어오는 비정상적인 트래픽 때문에 꽤나 애를 먹었습니다. WAF(웹 방화벽)에서 IP 기반 차단을 걸고, 최신 IP 인텔리전스 DB를 업데이트해도 교묘하게 방어망을 뚫고 들어오는 요청들이 있었기 때문입니다. 로그를 아무리 뜯어봐도 일반 가정집 IP(Residental Proxy)를 타고 들어오는 탓에 구분이 불가능했죠. "이제 IP 주소만 믿는 보안은 끝난 건가" 하는 막막함이 들더군요. 그러다 우연히 흥미로운 접근 방식을 발견하게 되었고, 이를 통해 네트워크 레벨에서의 '물리적 진실'을 마주하게 되었습니다. 오늘은 최근 화제가 된 'Aroma' 프로젝트의 아이디어를 빌려, TCP RTT(Round Trip Time) 핑거프린팅을 이용한 프록시 탐지 경험을 나누고자 합니다.

솔직히 고백하자면, 그동안 저는 TCP 핸드셰이크나 RTT 같은 지표를 단순히 네트워크 품질 측정 용도로만 생각했습니다. 하지만 이 지표들이 보안의 핵심 키가 될 수 있다는 사실을 이번에 뼈저리게 느꼈습니다. 핵심 아이디어는 간단하면서도 강력합니다. "정보는 빛의 속도보다 빠를 수 없다"는 특수 상대성 이론을 네트워크에 적용하는 것입니다.

일반적인 클라이언트와 서버 간의 직접 연결이라면, TCP 레벨에서 측정되는 min_rtt(최소 왕복 시간)와 smoothed_rtt(평균적으로 보정된 왕복 시간)의 비율은 어느 정도 일관된 패턴을 보입니다. 하지만 중간에 TCP 프록시가 끼어들면 이야기가 달라집니다. 프록시는 본질적으로 두 개의 연결(클라이언트-프록시, 프록시-서버)을 이어 붙인 형태입니다. 이 과정에서 발생하는 버퍼링과 재전송, 그리고 물리적 거리의 불일치는 커널 레벨의 TCP 통계에 독특한 흔적을 남깁니다.

저희는 리눅스 커널의 struct tcp_info에서 제공하는 tcpi_min_rtt와 tcpi_rtt 값을 모니터링하기 시작했습니다. Aroma 프로젝트가 제안한 공식은 매우 단순했습니다. 점수 = tcpi_min_rtt / tcpi_rtt입니다. 정상적인 네트워크 환경, 심지어 와이파이나 모바일 데이터 환경에서도 이 비율은 0.3 이상을 유지하는 경향이 있습니다. 하지만 TCP 프록시를 경유한 연결은 이 점수가 0.1 미만으로 급격히 떨어지는 현상이 관찰되었습니다.

실제로 이 로직을 테스트 환경에 적용해 보았을 때, 기존 WAF가 잡아내지 못했던 '수상한 요청'들의 상당수가 0.1 미만의 점수를 기록하고 있었습니다. IP는 세탁할 수 있어도, 패킷이 물리적으로 이동하는 시간과 그 과정에서 발생하는 지연 패턴까지 세탁할 수는 없었던 겁니다. 마치 범인이 알리바이를 조작해도 CCTV에 찍힌 이동 시간은 속일 수 없는 것과 같았습니다.

물론 이것이 만능열쇠는 아닙니다. 실험 과정에서 Cloudflare WARP 같은 일부 VPN 서비스는 감지되었지만, 네트워크 레이어(L3)에서 라우팅만 변경하는 방식의 VPN은 탐지되지 않았습니다. 또한 위성 인터넷이나 극도로 불안정한 네트워크 환경에서는 오탐(False Positive) 가능성도 존재합니다. 따라서 저희는 이 로직을 단독 차단 기준으로 삼기보다는, 기존의 어뷰징 탐지 시스템에 가산점을 부여하는 '시그널' 중 하나로 활용하기로 결정했습니다.

이번 경험을 통해 개발자로서 한 가지 중요한 태도를 다시금 정립하게 되었습니다. 상위 레벨의 도구(라이브러리, SaaS 솔루션)에만 의존하다 보면 문제의 본질을 놓칠 수 있다는 것입니다. 때로는 OSI 7계층의 아래쪽으로 내려가, 패킷 하나하나가 어떻게 흐르는지 들여다보는 '로우 레벨(Low-level)'의 시각이 필요합니다.

지금 여러분의 서비스가 정체불명의 트래픽으로 고통받고 있다면, 단순히 IP 리스트를 갱신하는 것을 넘어 TCP 스택이 보내오는 신호에 귀를 기울여보는 건 어떨까요? 기술의 트렌드는 변해도 물리 법칙은 변하지 않으니까요.