Threat Model

공개 프록시 서버의 위험과 그에 대처하는 방법

3 min read Published Updated 510 words

모든 무료 프록시를 신뢰할 수 없는 인프라로 취급하세요. 실제로 그렇기 때문입니다. 운영자는 익명이고, 자금 조달 모델은 불분명하며, 동일한 소켓이 일주일 내에 봇넷, 손상된 가정용 라우터, 연구자의 허니팟을 거쳐 순환할 수 있습니다. 그렇다고 해서 무료 프록시를 사용할 수 없는 것은 아닙니다. 단지 몇 가지 습관을 반드시 지켜야 한다는 의미입니다.

일반적인 공격 유형

위협은 극적이지 않습니다. 대부분의 사용자가 방어에 신경 쓰지 않기 때문에 성공하는 지루한 유형입니다.

평문 HTTP에서의 자격 증명 도난. 알 수 없는 프록시를 통해 http://로 무엇이든 로그인하면 운영자가 비밀번호를 볼 수 있습니다. 항상 CONNECT를 통해 TLS를 터널링하거나 자체적으로 HTTPS를 적용하는 대상에 SOCKS를 사용하세요. 현대적인 로그인 흐름은 주요 사이트에서 HTTPS 전용이지만, 레거시 인트라넷, IoT 관리 페이지, 오래된 CMS 배포는 그렇지 않습니다.

헤더 및 콘텐츠 주입. 적대적인 HTTP 프록시는 요청의 임의 부분을 다시 작성할 수 있습니다: 쿠키 변경, 리퍼러 교체, 추적 매개변수 주입, 캐시 헤더 제거 등이 가능합니다. 동일한 프록시는 응답에 콘텐츠를 주입할 수 있습니다 — HTML에 스크립트, JSON에 리디렉션, 정적 페이지에 광고를 삽입합니다. 프록시를 통해 서버 측 응답을 읽는 경우, 신뢰할 수 있는 경로에서 무결성을 확인할 수 있을 때까지 해당 응답이 손상된 것으로 간주하세요.

SOCKS5를 통한 DNS 하이재킹. SOCKS5는 프록시에서 호스트 이름을 확인할 수 있습니다. 프록시가 DNS 레코드에 대해 거짓말을 하면 운영자가 제어하는 서버에 연결됩니다. 가능한 경우 클라이언트가 로컬에서 확인하도록 설정하세요: curl --resolve example.com:443:93.184.216.34, 또는 코드에서 호스트 이름 대신 IP를 전달하세요.

트래픽 로깅. 선의의 프록시조차도 가져오는 모든 URL을 기록할 수 있습니다. "이 사람이 어떤 URL을 요청했는가"를 포함하는 위협 모델의 경우, 모든 공개 프록시는 잘못된 도구입니다. Tor 또는 게시된 무로그 정책과 법적 소환에 대응한 실적이 있는 유료 VPN을 사용하세요.

클라이언트에 대한 리소스 고갈. 일부 프록시는 의도적으로 연결을 느리게 제한하거나, 매우 큰 응답을 반환하거나, 데이터를 보내지 않고 소켓을 열린 상태로 유지합니다. 클라이언트 측에서 엄격한 응답 크기 제한과 연결 시간 제한을 설정하세요.

방어 방법 (우선순위 순)

모든 트래픽을 CONNECT를 통해 TLS 내부로 보내거나 SOCKS를 통해 HTTPS 대상으로 보내세요. 공개 프록시 뒤에서 다른 곳에서 재사용할 자격 증명을 절대 재사용하지 마세요. 인증서를 엄격하게 검증하세요 — 발급자 고정은 일상적인 사용에는 과도하지만, 모든 체인을 수락하는 것은 무모합니다. 연결 및 읽기에 짧은 시간 제한을 설정하세요. 작업이 중요한 경우 포렌식 검토를 위해 프록시 응답을 기록하세요. 자주 교체하세요; 5분 전에 작동했던 프록시가 지금도 동일한 프록시라고 단정할 수 없습니다.

무료 프록시가 실제로 유용한 용도

세 가지 작업 범주가 이러한 번거로움을 정당화합니다. 지리적 콘텐츠 변형 테스트: CDN이 프랑크푸르트와 상파울루에서 올바른 페이지를 제공하는가? 공개적이고 인증되지 않은 데이터 스크래핑: 검색 엔진 결과, IP당 속도 제한이 없는 공개 API, 이미 다른 곳에 색인된 콘텐츠. 애플리케이션이 대상에 익숙하지 않은 아웃바운드 IP에서 올바르게 동작하는지 확인 — IP 기반 사기 휴리스틱을 사용하는 시스템의 QA에 유용합니다.

이러한 용도로 사용하세요. 실패율을 감수하세요. 잃어도 괜찮은 것만 프록시 뒤에 두세요.