주거용 프록시가 IP 차단을 뚫는 방법과 먹히는 탐지 신호

전 세계 주요 프록시 업체가 판매하는 주거용 프록시 출구 노드의 약 4분의 1은, 자기 기기가 누군가의 인프라로 쓰이고 있다는 사실을 모르는 사용자의 기기에서 돌아가고 있습니다. 이 추정치는 여러 해 동안 이런 네트워크를 측정해 온 학계 연구에서 나왔고, 최근 한 보안 업체가 대통령 행정실(Executive Office of the President)에 할당된 IP 대역 안에서 주거용 프록시 출구를 발견한 사건도 이것으로 설명됩니다. 연구자들이 이 트래픽을 발견했을 때 절반이 미국 동부 시간 기준 오후 5시에서 자정 사이에 몰려 있었고, 인터넷은 늘 그렇듯 농담으로 반응했습니다. 하지만 농담 밑에는 우리 모두에게 해당하는 교훈이 있습니다. 주거용 프록시는 IP 기반 방어를 무력화하는 가장 효과적인 수단이고, 아직도 ‘주거용 IP’를 신뢰 신호로 취급하고 있다면 한 세대쯤 뒤처진 것입니다.

중견 SaaS 기업에서 4년 동안 탐지 업무를 맡았는데, 그 변화는 대시보드에서 실시간으로 보였습니다. 크리덴셜 스터핑 조직이 데이터센터 프록시에서 주거용 출구로 옮겨 가던 무렵, 우리 IP 차단 목록은 공격 트래픽의 80%를 잡던 상태에서 거의 아무것도 잡지 못하는 상태가 됐습니다. 공격 방식도, 도구도 같았습니다. 달라진 건 마지막 홉뿐이었습니다. 이 글은 왜 그런 일이 생기는지, 그리고 IP 평판이 더 이상 통하지 않을 때 실제로 효과가 있는 방법이 무엇인지 다룹니다.

주거용 프록시는 실제로 어떻게 동작하나

주거용 프록시는 스마트폰, 스마트TV, 셋톱박스, 가정용 공유기처럼 일반 소비자 기기에서 돌아가는 출구 노드일 뿐입니다. 프록시 네트워크의 고객은 이 기기들을 통해 나가는 트래픽에 돈을 내고, 프록시 업체의 역할은 모든 지역에 수백만 대를 확보해 두는 것입니다. 공급원은 세 곳이며, 평판이 좋은 순서대로 나열하면 다음과 같습니다.

옵트인 SDK. VPN, 날씨 위젯, 모바일 게임, ‘대역폭 공유하고 돈 버세요’ 같은 무료 앱에 프록시 SDK가 번들로 들어 있습니다. 동의 내용은 아무도 읽지 않는 이용약관 깊숙이 묻혀 있지만, 형식상으로는 존재합니다. 대형 업체들이 윤리성을 말할 때 내세우는 모델이 바로 이것입니다.
해킹된 펌웨어와 악성코드. 봇넷은 수년 동안 프록시 재판매로 돈을 벌어 왔습니다. 공장에서 수상한 펌웨어가 올라간 저가 안드로이드 스트리밍 박스는 네트워크에 연결되는 순간 프록시 노드가 됩니다. 소유자는 미디어 플레이어를 샀다고 생각하겠죠.
노골적인 봇넷 임대. 하위 시장은 굳이 숨기지 않습니다. 출처 정책을 명시하지 않은 채 순환 IP 5천만 개를 제공한다면, 계산은 직접 해보시면 됩니다.

중요한 건 이것이 방어하는 쪽에서 어떻게 보이느냐입니다. 트래픽은 Comcast, BT, Deutsche Telekom 같은 주거용 ASN에서 들어옵니다. IP는 그럴듯한 도시로 지오로케이션되고, 역방향 DNS는 pool-96-225-14-7.nycmny.fios.verizon.net 같은 값을 돌려줍니다. 2010년대에 우리가 만든 휴리스틱은 모두 이것을 집에 있는 사람이라고 판단합니다. 하지만 사람이 아닙니다. GB당 3달러짜리 중계기이고, 집에 있는 사람은 그런 게 존재하는지조차 모릅니다.

이 점은 프록시를 사거나 막는 일을 하지 않더라도 반드시 경계해야 할 부분입니다. 대역폭을 중계하는 같은 SDK는 누군가의 원격 제어 아래에서 돌아가는 소프트웨어이고, 여러분의 네트워크 경계 안에서 실행되고 있습니다. 지금은 대역폭을 팔지만, 운영자나 운영자를 장악한 공격자가 이 노드들에 더 나쁜 일을 시키는 것을 막을 아키텍처적 장치는 없습니다. 민감한 네트워크 안의 기기에 올라간 프록시 SDK는 대역폭 문제가 아닙니다. 청구 부서가 딸린 발판입니다.

IP 기반 방어는 왜 죽었나

IP 평판은 악성 트래픽이 악성처럼 보이는 곳에서 올 때 의미가 있었습니다. 방탄 호스팅, 탈취된 데이터센터 대역, 잊힌 VPS의 오픈 프록시 같은 곳이죠. 나쁜 동네 목록을 만들 수 있었습니다. 주거용 프록시는 나쁜 트래픽을 좋은 동네로 옮겨 놓으면서 그 시대를 끝냈습니다. 감염된 거실 하나씩 말이죠.

경제성이 상황을 더 나쁘게 만듭니다. 데이터센터 IP 공간은 한정되어 있고 감시도 촘촘합니다. /24 대역 하나를 태우면 하루 안에 모든 차단 목록에 오릅니다. 반면 주거용 출구 노드는 사실상 무한하고 스스로 복구됩니다. 크리덴셜 스터핑 한 번으로 수만 개의 서로 다른 가정 IP를 돌아가며 쓸 수 있고, 각 IP는 요청을 두세 개만 보내서 IP별 속도 제한에 걸리지 않습니다. WAF에는 수만 명의 서로 다른 ‘사용자’가 보입니다. 개별 IP를 차단해도 소용없고, ASN 전체를 차단하면 실제 고객까지 막게 됩니다.

그래서 ‘이 트래픽은 백악관에서 왔다’는 주장에는 단서가 필요하고, 이 이야기를 두고 회의적인 사람들이 그 점을 짚는 건 옳습니다. 어떤 IP 대역을 소유하고 있다고 해서 그 공지가 물리적으로 한 장소에 대응하는 것은 아닙니다. 대형 조직은 여러 사이트에서 대역을 공지하고, 게스트 네트워크, 연구실, 통신사 NAT 오버레이를 운영합니다. 조직의 대역에 속한 출구 IP는 그 공간이 누구에게 등록되어 있는지를 알려줄 뿐, 패킷이 어느 책상을 거쳐 갔는지는 알려주지 않습니다. 여러분의 네트워크에서 이런 분석을 하게 된다면, 귀속 결과를 결론이 아니라 내부 플로우 로그로 검증할 가설로 다루세요.

여전히 통하는 탐지 신호

IP 평판은 죽었지만 트래픽이 보이지 않게 된 건 아닙니다. 프록시 출구에는 지문이 있습니다. 어떤 신호도 단독으로는 충분하지 않습니다. 모든 신호에 정상적인 설명이 있기 때문입니다. 하지만 함께 쌓으면 놀랄 만큼 효과적입니다. 현대 탐지 엔지니어링의 표준적인 접근이 바로 이것입니다. 결정적 증거를 찾는 대신 약한 신호들로 점수를 쌓는 것이죠. 같은 철학이 난독화된 스크립트의 행위 지문 분석에도 나타납니다. 행동을 특성화할 수 있다면 코드를 전부 읽을 필요가 없습니다.

ASN과 연결 형태 분석

ASN으로 시작하되 ‘주거용인가’에서 멈추지 마세요. 유용한 질문은 그 ASN이 주장하는 클라이언트와 맞는지입니다. 데스크톱 Chrome 사용자 에이전트를 달고 이동통신사의 소비자용 5G 대역에서 들어오는 요청은 의심스럽습니다. 가정용 ISP ASN에서 데이터센터 같은 동시성으로 API를 두드리는 트래픽도 마찬가지입니다. 개별 프록시 노드는 실제 가정이고, 실제 가정에는 실제 제약이 있습니다. 소비자용 업로드 대역폭, NAT 테이블, 캐리어급 NAT 주소 공유 같은 것이죠. 한 시간 동안 프록시 고객 마흔 명에게 서비스하는 출구 IP는 어떤 가정도 만들지 못하는 연결 패턴을 만들어 냅니다.

TLS와 TCP 지문

허술한 운영자를 잡아내는 곳이 바로 여기입니다. 대부분의 프록시 고객은 업체의 클라이언트 소프트웨어를 쓰거나, Python requests, Go의 net/http, Node 같은 표준 HTTP 라이브러리로 트래픽을 보냅니다. 각각은 고유한 TLS ClientHello를 가집니다. 암호 스위트 순서, 확장 목록, 지원 그룹 등이 다릅니다. JA3, JA4 해시를 쓰면 TLS 핸드셰이크가 말하는 클라이언트 정체와 사용자 에이전트가 주장하는 정체를 비교할 수 있습니다. ‘Windows의 Chrome 126’이라고 주장하면서 Go TLS 지문을 보내는 요청은 탈을 쓴 봇입니다. 일부 정교한 프록시 네트워크는 고객 기기에서 TLS를 그대로 통과시켜 이 거짓말을 유지하지만, 대부분은 그렇지 않고 좋은 업체도 TCP 계층에서 새어 나갑니다. Windows라고 주장하는 클라이언트인데 TTL과 윈도우 크기가 리눅스를 가리킨다면, 그것도 점수를 올리는 또 하나의 근거입니다.

지연 시간과 타이밍 패턴

모든 주거용 프록시는 소비자 하드웨어와 소비자 업링크를 거치는 홉을 하나 추가합니다. 그 홉에는 비용이 있습니다. 서비스가 WebRTC, CDN 엣지 측정, 혹은 세션 내 요청 타이밍 분포를 통해 클라이언트의 실제 지연 시간을 본다면, 네트워크 RTT와 주장하는 지리적 위치를 비교할 수 있습니다. 버지니아 데이터센터와 4ms RTT를 가진 ‘덴버 사용자’는 덴버에 있지 않습니다. 세션 내 타이밍도 중요합니다. 사람의 브라우징에는 글 읽는 멈춤, 마우스 움직임, 불규칙한 리듬이 있습니다. 자동화 스크립트가 프록시를 통해 보내는 트래픽은 메트로놈 같은 성질을 띱니다. 요청 간격이 일정하고, 유휴 시간의 흔들림이 없으며, 폼 제출이 즉시 일어납니다. 공격자가 지터를 추가하더라도, 사람이라면 절대 만들어 내지 않을 분포에서 뽑은 지터일 뿐입니다.

행동 휴리스틱

가장 강력한 신호는 클라이언트가 무엇인지가 아니라 무엇을 하는지입니다. 실제 사용자는 이리저리 돌아다닙니다. 봇은 계획을 실행합니다. 로그인하고, UI 경로로는 연결되지 않는 URL로 설정 페이지에 바로 들어가고, 이메일을 바꾸고, 90초 만에 지급 요청을 POST한 세션은 IP가 뭐라고 하든 사람이 아닙니다. 시퀀스 엔트로피를 추적하세요. 세션이 프론트엔드가 실제로 움직이는 방식대로 앱을 거치는지, 아니면 API 문서를 읽은 사람만 고를 법한 순서로 엔드포인트를 치는지 보는 겁니다. 여기서 세션 간 집계가 킬러 기능입니다. 주거용 IP 하나가 요청 세 개를 보내면 무해해 보입니다. 하지만 주거용 IP 300개가 각각 요청 세 개씩, 똑같은 TLS 지문, 똑같은 화면 해상도, 똑같은 엔드포인트 순서로 보낸다면, 그것은 탈을 300개 쓴 하나의 작전입니다.

네트워크 패킷 흐름 위에 겹겹이 놓인 투명한 신호 필터를 거시적 시선으로 그린 일러스트. 각 층이 서로 다른 입자를 걸러낸다 — 단독으로 프록시 출구를 식별하는 신호는 없습니다. 약한 신호를 쌓아야 보입니다.

자체 네트워크에서 프록시 SDK 위협 헌팅하기

인바운드 문제가 주목받지만, 이 사건을 촉발한 이야기는 사실 아웃바운드 이야기입니다. 더 잘 알았어야 할 네트워크의 기기가 다른 사람의 트래픽을 중계하고 있었던 것이죠. 경계를 직접 통제할 수 있으니 실제로 손쓸 수 있는 시나리오입니다. 언젠가 누군가가 감염된 스트리밍 박스를 꽂거나 업무용 폰에 ‘무료 VPN’을 설치할 것이라고 가정하세요. 여러분의 일은 그 사건이 크게 울리도록 만드는 것입니다.

탐지 로직은 단순합니다. 프록시 SDK에는 특징적인 자세가 있기 때문입니다. 노드는 지시를 받고 트래픽을 중계하기 위해 존재하며, 그래서 다음과 같은 특성이 나타납니다.

지속적인 제어 채널 연결. 낯선 도메인이나 IP로 이어지는 장기 TLS 세션이며, 종종 작고 주기적인 페이로드가 붙습니다. 아웃바운드 목적지의 기준선을 만드세요. 여러분의 소프트웨어 벤더가 하나도 운영하지 않는 국가의 호스트와 6시간짜리 연결을 유지하는 클라이언트 기기는 들여다볼 가치가 있습니다.
클라이언트 기기의 높은 연결 팬아웃. 워크스테이션이 시간당 수백 개의 서로 다른 외부 IP로 아웃바운드 연결을 만든다면 사람이 아니라 인프라처럼 행동하는 것입니다. 노트북은 브라우징을 하고, 중계기는 중계를 합니다.
클라이언트 서브넷으로 향하는 인바운드 시작 플로우. 많은 프록시 프레임워크는 인바운드 터널을 뚫거나 STUN 방식의 NAT 통과를 씁니다. 게스트나 IoT VLAN의 기기가 인터넷으로부터 연결을 받고 있다면 세그먼테이션에 심각한 문제가 있는 것입니다. 찾아내세요.
비대칭적 업로드 패턴. 업로드량이 다운로드량에 육박하는 폰이나 TV 박스는 콘텐츠를 서빙하거나 트래픽을 중계하고 있는 것입니다. 소비자 기기에서 둘 다 정상은 아닙니다.
시간대별 기준선. 정부 네트워크의 출구를 발견한 연구자들도 바로 이 점에 기댔습니다. 저녁 시간에 활동이 몰린 것은 게스트가 아닌 개인 네트워크의 기기임을 시사했습니다. 여러분의 버전은 더 단순합니다. 기기의 트래픽 패턴이 양만이 아니라 성격까지 바뀌면 알림을 보내세요.

이런 탐지에는 심층 패킷 검사가 필요 없습니다. 신뢰받는 네트워크를 운영하고 싶다면 이 점이 중요합니다. 플로우 메타데이터, 즉 NetFlow, Zeek conn 로그, VPC 플로우 로그에 위의 모든 신호가 들어 있습니다. 아직 아웃바운드 플로우 데이터를 보관하고 기준선을 만들지 않고 있다면, 무엇을 사기 전에 그 공백부터 메우세요. 여기의 사각지대는 클라우드 인증 로깅의 사각지대와 닮아 있습니다. 데이터는 존재하지만 사고가 나기 전까지 아무도 들여다보지 않습니다.

# Quick-and-dirty hunt: client devices acting like relays
# Feed this Zeek-style conn logs; flag RFC1918 sources with
# high distinct-destination fan-out and heavy upload ratios.
awk -F'\t' '
$3 ~ /^(10\.|192\.168\.|172\.(1[6-9]|2[0-9]|3[01]))/ {
src=$3; dst=$5
up[src]+=$10; down[src]+=$12
seen[src SUBSEP dst]=1
}
END {
for (k in seen) { split(k,a,SUBSEP); fanout[a[1]]++ }
for (s in fanout)
if (fanout[s] > 200 && up[s] > down[s] * 0.5)
printf "%s dsts=%d up=%d down=%d\n", s, fanout[s], up[s], down[s]
}' conn.log | sort -t= -k2 -nr | head -20

이건 완성품이 아니라 첫걸음입니다. 팬아웃 임계값은 여러분의 기준선에 맞춰 조정하고, 화이트리스트에 넣을 때까지 미디어 서버와 백업 에이전트가 오탐을 낼 것을 예상하세요. 핵심은 이 헌팅이 저렴하다는 점입니다. 오후 한나절의 로그 분석으로 수억 원짜리 어플라이언스가 찾아내는 것을 찾을 수 있습니다.

진짜 해법은 세그먼테이션

제 강한 의견은 어렵게 얻은 결론입니다. 침해된 소비자 기기와의 탐지 군비 경쟁에서는 절대 이길 수 없습니다. 공급량이 너무 많고, 불안전한 펌웨어를 출하하는 벤더는 아무런 대가를 치르지 않습니다. 할 수 있는 일은 침해된 기기를 지루한 존재로 만드는 것입니다. 제대로 세그먼트된 IoT VLAN에 있는 감염된 스트리밍 박스는 대역폭을 프록시 네트워크에 팔 수 있습니다. 성가시고, 민감한 IP 대역이라면 민망할 수도 있죠. 하지만 여러분의 파일 공유, 내부 API, 민망함을 침해 사고로 바꿔 버릴 무엇에도 닿을 수 없습니다.

사고 리뷰에서 패턴은 늘 같습니다. 조직에는 평평한 네트워크가 있었거나, 내부 DNS와 관리 인터페이스에 도달할 수 있는 ‘게스트’ 네트워크가 있었거나, 클릭 동의 말고는 아무것도 강제하지 않는 BYOD 정책이 있었습니다. 그러다 저가 안드로이드 박스나 번들 SDK가 깔린 폰이 네트워크에 들어오고, 조직의 출구 IP가 프록시 업체 목록에 나타납니다. 사후 조치는 사전에 했어야 할 것과 같습니다. 게스트 네트워크의 클라이언트 격리, 송신 전용 접근만 허용하고 RFC1918 목적지를 막은 VLAN의 IoT 기기, 개인 기기를 운영 신뢰 영역 근처에도 두지 않기입니다. 심층 방어는 화려하지 않지만, 계층형 방어와 단일 강력 통제를 두고 이야기했듯이, 어떤 통제든 하나는 반드시 실패하기 때문에 계층이 여러분을 구합니다.

내부적으로 나눠볼 정책 이야기도 있습니다. ‘무료’ 앱이 바로 이 SDK가 들어오는 경로입니다. 직원이 네트워크에 닿는 기기에 임의의 소프트웨어를 설치할 수 있다면, 여러분은 경계를 모바일 광고 기술 기업에 위임한 셈입니다. MDM과 앱 허용목록으로 대응하는 조직도 있지만, 대부분은 네트워크 세그먼테이션이 정치적 비용이 덜 드는 방식으로 같은 격리 효과를 냅니다.

이 사건이 실제로 말해주는 것

정치적 추측을 걷어내면, 이 이야기는 두 가지 사실을 깔끔하게 보여줍니다. 첫째, 주거용 프록시 탐지는 하나의 제품 카테고리로 성숙했습니다. 연구자들은 이제 출구 노드를 대규모로 열거하고 IP 대역에 매핑할 수 있으며, 이는 실제로 유용한 텔레메트리입니다. 둘째, 더 불편한 사실인데, 모든 네트워크는 부주의한 기기 하나를 사는 것만으로 누군가의 인프라가 될 수 있습니다. 세계에서 가장 철저히 지켜지는 네트워크에도 사람이 있고, 사람은 무언가를 꽂습니다.

한 가지만 가져가신다면, 여러분 조직의 아웃바운드 IP가 주거용 프록시 목록에 나타나는지 확인하세요. 몇몇 서비스가 알려줄 것이고, 위협 인텔 피드에 이미 포함되어 있을 수도 있습니다. 대역이 목록에 올라 있다고 해서 침해가 증명되는 것은 아닙니다. 캐리어급 NAT와 공유 주소 공간 때문에 그림이 흐려지니까요. 하지만 헌팅을 시작하기에는 저렴하고 신호가 강한 출발점입니다. 그다음 아웃바운드 팬아웃, 장기 연결, VLAN 설계를 들여다보세요.

공격자들은 몇 년 전에 이미 좋은 동네로 들어왔습니다. 이를 알아챈 방어자들은 주소 확인을 멈추고 행동을 들여다보기 시작한 사람들입니다.