XFF 변조 환경에서 실제 클라이언트 IP 확인 - JP-Hosting
X-Forwarded-For(XFF) 변조 시 실제 접속 IP 확인 - X-Client-Real-IP 테스트
안녕하세요
JP-Hosting 입니다.
프록시를 사용하는 환경에서는 웹서버에 접속자의 실제 IP가 아닌 프록시 서버의 IP가 기록될 수 있습니다.
이 때문에 실제 접속자 IP를 전달하기 위해 X-Forwarded-For, 흔히 XFF라고 부르는 HTTP 헤더를 사용합니다.
XFF의 기본 개념과 IIS에서 로그를 기록하는 방법은 이전 글에서 다룬 적이 있어, 이번 글에서는 설정 방법보다 실제 프록시 환경에서 헤더가 어떻게 전달되는지를 확인해 보겠습니다.
특히 X-Forwarded-For에 임의의 IP를 넣었을 때 당사 프록시에서 전달하는 X-Client-Real-IP에는 어떤 값이 기록되는지 확인했습니다.
관련 내용은 아래 기존 글에서도 확인할 수 있습니다.
X-Forwarded-For 값은 임의로 넣을 수 있다
X-Forwarded-For는 HTTP 요청 헤더입니다.
따라서 클라이언트가 요청을 보낼 때 임의의 값을 포함하는 것도 가능합니다.
이번 테스트에서 실제 접속 IP는 다음과 같습니다.
150.249.xxx.xxx
하지만 요청에는 실제 IP와 관계없는 값을 XFF로 넣었습니다.
즉 실제 접속자는 150.249.xxx.xxx이지만, 요청에 포함된 XFF 값은 5.5.5.5인 상태입니다.
[X-Forwarded-For: 5.5.5.5 요청 화면]
위 화면에서는 실제 접속 IP와 관계없이 요청 헤더에 X-Forwarded-For: 5.5.5.5가 포함되어 있는 것을 확인할 수 있습니다.
IIS에서 XFF와 X-Client-Real-IP 확인
웹서버는 IIS를 사용했으며, 로그에서 다음 두 값을 확인할 수 있도록 사용자 지정 필드를 추가했습니다.
X-Client-Real-IP
X-Forwarded-For는 요청에 포함되어 전달된 XFF 값을 확인하기 위한 항목입니다.
X-Client-Real-IP는 당사 프록시에서 실제 클라이언트 IP를 전달하기 위해 사용하는 헤더입니다.
IIS에서 XFF 로그 필드를 추가하는 방법은 기존 가이드에서 별도로 다루고 있으므로 여기서는 생략합니다.
[IIS 사용자 지정 로그 필드 설정]
IIS 로그에는 X-Forwarded-For와 X-Client-Real-IP를 각각 기록하도록 설정했습니다.
실제 로그 결과
XFF에 5.5.5.5를 넣은 상태로 접속한 뒤 IIS 로그를 확인했습니다.
결과는 다음과 같이 구분되었습니다.
X-Client-Real-IP : 150.249.xxx.xxx
요청에서 임의로 지정한 5.5.5.5는 X-Forwarded-For에 그대로 기록되었습니다.
반면 X-Client-Real-IP에는 실제 접속 IP인 150.249.xxx.xxx가 확인되었습니다.
즉 두 헤더를 비교하면 요청에 포함된 XFF 값과 실제 접속 IP를 구분할 수 있습니다.
[IIS 로그에서 XFF와 실제 접속 IP 확인]
위 로그에서는 X-Forwarded-For에 5.5.5.5, X-Client-Real-IP에 실제 접속 IP가 각각 기록된 것을 확인할 수 있습니다.
IP 접근제어 테스트
다음으로 같은 환경에서 IP 접근제어가 어떻게 동작하는지도 확인했습니다.
먼저 전체 접근을 제한한 상태에서 실제 접속 IP인 150.249.xxx.xxx를 허용했습니다.
클라이언트 요청에는 여전히 다음과 같은 XFF 값이 포함되어 있습니다.
실제 접속 IP와 XFF 값이 서로 다른 상태입니다.
이 상태에서 실제 접속 IP를 허용했을 때는 사이트에 정상적으로 접속할 수 있었습니다.
XFF에 넣은 IP만 허용한 경우
이번에는 반대로 실제 접속 IP를 허용하지 않고, 요청의 XFF에 넣었던 5.5.5.5만 허용했습니다.
5.5.5.5
요청에도 동일하게 다음 값이 포함되어 있습니다.
만약 클라이언트가 임의로 입력한 XFF 값을 실제 접속 IP로 판단한다면 이 상태에서도 접속이 가능해야 합니다.
하지만 실제 결과는 403 Forbidden으로 접근이 차단되었습니다.
[5.5.5.5 허용 설정]
[403 Forbidden 확인]
XFF에는 여전히 5.5.5.5가 포함되어 있었지만, 해당 값을 허용 IP로 등록하는 것만으로는 접속되지 않았습니다.
테스트 결과
| 구분 | 확인 결과 |
|---|---|
| 실제 접속 IP | 150.249.xxx.xxx |
| 요청에 입력한 XFF | 5.5.5.5 |
| X-Forwarded-For | 5.5.5.5 |
| X-Client-Real-IP | 150.249.xxx.xxx |
| 실제 접속 IP 허용 | 정상 접속 |
| 5.5.5.5만 허용 | 403 Forbidden |
테스트 결과 클라이언트가 X-Forwarded-For에 임의의 값을 넣어 요청할 경우 해당 값은 XFF에 그대로 나타날 수 있었습니다.
하지만 당사 프록시에서 전달하는 X-Client-Real-IP에는 실제 접속자의 IP가 별도로 기록되었습니다.
또한 이번 접근제어 테스트에서는 XFF에 넣은 5.5.5.5를 허용 IP로 등록하는 것만으로는 접속이 허용되지 않았습니다.
XFF 값만 보고 실제 접속 IP라고 판단하면 안 되는 이유
X-Forwarded-For가 있다고 해서 그 값이 항상 실제 접속자의 IP라는 의미는 아닙니다.
이번 테스트처럼 실제 접속 IP와 전혀 다른 값을 요청에 포함하는 것도 가능합니다.
150.249.xxx.xxx
X-Forwarded-For
5.5.5.5
따라서 웹서버 로그나 보안 정책에서 클라이언트 IP를 사용할 때는 단순히 XFF 값이 존재하는지만 볼 것이 아니라, 해당 값이 어떤 경로를 통해 전달되었는지도 함께 확인해야 합니다.
당사 프록시 환경에서는 실제 접속자 IP를 X-Client-Real-IP 헤더로 별도로 전달하고 있습니다.
웹서버에서는 이를 통해 요청에 포함된 XFF 값과 실제 접속 IP를 각각 확인할 수 있습니다.
주의할 점
X-Client-Real-IP 역시 HTTP 헤더이므로 헤더 이름만 보고 무조건 신뢰해서는 안 됩니다.
중요한 것은 신뢰할 수 있는 프록시를 통해 전달된 요청인지 확인한 상태에서 해당 값을 사용하는 것입니다.
Origin 서버에 외부에서 직접 접근할 수 있는 환경이라면 사용자가 동일한 이름의 헤더를 임의로 보내는 것도 가능하기 때문입니다.
따라서 실제 접속 IP를 로그 기록이나 접근제어, 보안 정책에 사용할 경우에는 프록시와 Origin 사이의 접근 경로도 함께 확인하는 것이 좋습니다.
마무리
이번 테스트에서는 실제 접속 IP가 150.249.xxx.xxx인 상태에서 X-Forwarded-For 값을 5.5.5.5로 변경해 요청했습니다.
IIS 로그에서는 다음과 같이 두 값이 구분되어 기록되었습니다.
X-Client-Real-IP : 150.249.xxx.xxx
또한 실제 접속 IP를 허용했을 때는 정상적으로 접속할 수 있었지만, XFF에 임의로 입력한 5.5.5.5만 허용한 경우에는 403 Forbidden으로 차단되었습니다.
프록시 환경에서 접속자 IP를 확인할 때는 XFF 값만을 실제 IP로 판단하기보다, 신뢰할 수 있는 프록시를 통해 전달되는 실제 클라이언트 IP를 함께 확인하는 것이 중요합니다.
