클라이언트 IP 정보를 변조하는 프록시
클라이언트 IP 정보를 변조하는 프록시는 HTTP 요청 헤더에 가짜 클라이언트 IP 주소를 넣습니다. 해당 필드에서는 실제 주소를 숨기지만, 요청에 프록시 사용 흔적이 남을 수 있습니다. 필드 하나를 바꿨다는 사실만으로 요청의 다른 부분에도 실제 주소가 없다고 단정할 수는 없습니다. ‘Distorting’이라는 이름은 이렇게 클라이언트 정보를 다른 값으로 바꾸는 동작을 가리킵니다.
이 용어는 과거의 프록시 익명성 수준 분류에서 유래했습니다. 오늘날 상용 프록시에는 Elite, 즉 고익명 프록시의 동작이 기대됩니다. 클라이언트의 원래 IP를 전달하지 않고 프록시 사용을 알리는 헤더도 추가하지 않는 방식입니다. Distorting이라는 분류는 주로 오래된 설명이나 공개 프록시 목록의 표시를 이해할 때 유용합니다.
요청에서 바뀌는 정보
내 공인 IP가 198.51.100.24이고 프록시가 203.0.113.80에서 웹사이트에 연결한다고 가정해 보겠습니다. 프록시는 암호화되지 않은 HTTP 요청의 헤더에 세 번째 주소를 넣습니다. X-Forwarded-For: 192.0.2.55입니다.
세 번째 주소는 프록시가 삽입한 가짜 값입니다. 내 실제 IP도 아니고 웹사이트에 연결할 때 쓰는 주소도 아닙니다.
다른 헤더에는 요청을 중개자가 처리했다는 흔적이 남을 수 있습니다. 예를 들어 Via 헤더는 프록시가 관여했음을 나타냅니다. 클라이언트 IP를 바꿔도 이 흔적은 없어지지 않습니다.
웹사이트에 실제로 보이는 정보
연결은 여전히 203.0.113.80에서 들어옵니다. 헤더에 다른 주소를 넣어도 프록시가 다른 나라로 이동하거나 해당 IP의 네트워크와 평판이 바뀌지는 않습니다. 요청마다 가짜 값을 바꾸는 것은 실제 IP 순환이 아닙니다. 연결 주소는 그대로이기 때문입니다.
IP 확인 도구는 연결 주소를 표시할 수도 있고 헤더에서 가져온 값을 표시할 수도 있습니다. 따라서 같은 프록시인데도 결과가 다르게 나올 수 있습니다. 테스트 페이지에 가짜 주소가 보인다고 해서 모든 웹사이트가 그 주소를 내 IP로 취급하는 것은 아닙니다.
어떤 헤더를 사용하고 누구의 값을 신뢰할지는 각 웹사이트가 결정합니다. 서버는 자체 리버스 프록시에서 받은 클라이언트 IP 정보만 받아들일 수도 있습니다. 해당 웹사이트를 방문할 때 사용하는 프록시가 자동으로 신뢰받는 정보원이 되는 것은 아닙니다.
HTTPS에도 적용되나요?
이 예시가 성립하려면 프록시가 HTTP 요청을 읽고 수정할 수 있어야 합니다. CONNECT로 설정한 일반적인 HTTPS 터널에서는 요청과 헤더가 종단 간 TLS 연결 안에서 전송됩니다. 암호화된 트래픽을 전달하기만 하는 프록시는 이 헤더에 가짜 IP를 넣을 수 없습니다. 따라서 일반 HTTP 테스트에서 Distorting으로 판정됐다고 해서 같은 프록시가 HTTPS에서도 똑같이 동작한다고 볼 수는 없습니다.