서버에서 Client IP 를 추출하는 여러가지 방법

서비스 요구사항에 따라 Client IP 가 필요한 상황이 있다. 보안을 위해서 Client IP 를 확인하여 접근을 허용할 수 있다. 허용되지 않은 IP 의 경우 접근을 막을 수 있다.  로그 요구사항으로 어떤 사용자가 접근하고 있는 지를 기록하기 위해 Client IP 를 남겨야 할 수 있다. 

하지만 사용자나 서비스의 네트워크 구성에 따라서 Client IP 를 추출하는 것이 쉽지 않을 수 있다. 프록시가 있어 직접 연결한 Client 를 실제 사용자로 판단할 수 없는 경우가 그렇다. 프록시 뒤에 있는 사용자를 찾으려고 노력하면 Client IP 를 숨기거나 우회하기 위해서 변조를 시도하는 상황을 마주하게 된다. 그래서 Client IP 를 추출하기 위한 여러 방안들을 아래에 정리하게 되었다. 

결론부터 먼저 말하면, 일반적인 상황에서 나는 `X-Forwarded-For` 의 가장 오른쪽의 Public IP 를 Client IP 로 판단하기로 했다. 믿을 수 없는 목록 중에서 신뢰할 수 있으면서 간단하고, 빠른 방법이라 생각하기 때문이다. 하지만 여러 방안들을 조사했을 때, 어떤 상황에서는 사용할 수 있는 지, 또 어떤 지점이 문제가 되는 지 생각해볼 수 있었다. 그래서 고민했었던 여러 방안들을 소개하려고 한다.

### Remote IP
프록시가 없는 간단한 구조의 서비스라면 서버에 연결된 Remote IP 를 Client IP 로 추출할 수 있다. 하지만 Remote IP 가 실제 사용자의 IP 라는 확신이 없다면, Client IP 로 사용하기 어렵다. 사용자 네트워크 구성에서 proxy 가 있다면, 서버에 연결된 Remote IP 는 실제 사용자의 Client IP 가 아닐 수 있다. 

여기에서 서비스 요구사항에 대한 명확한 정의가 필요해질 수 있다. 사용자 네트워크의 사설 IP 를 추출해야 하는 지, 아니면 공인 IP 를 추출해야 하는 지 정의가 필요하다. 사설 IP 는 서비스의 입장에서 큰 의미가 없기 때문에, 보통 공인 IP 를 추출한다. 

요구 사항을 어느 정도까지 정확하게 추출해야 하는 지 명확히 정의하고, 요구 사항에서 필요한 값을 추출해낸다는 생각이 필요하다. 

### `X-Forwarded-For` 헤더 가장 왼쪽의 값 (DON'T)
`X-Forwarded-For` 헤더는 요청이 어떤 IP 들을 거쳐 전달되었는 지 알 수 있도록 도와준다. 요청이 전달되면서 거쳐오는 IP 는 우측에 추가되기 때문에, 가장 왼쪽의 IP 를 Client IP 라고 생각할 수 있다.

하지만 이 값을 실제 Client IP 로 판단하는 것은 위험하다. 헤더는 요청을 전달받은 프록시에서 언제든지 수정 가능하기 때문이다. [이런 지점을 노린 `X-Forwarded-For` 변조는 Stack Overflow 도 당했었던 유명한 공격 기법이다.](https://blog.ircmaxell.com/2012/11/anatomy-of-attack-how-i-hacked.html) 사용자가 언제든지 수정할 수 있는 가장 왼쪽의 IP 를 Client IP 로 판단한다면 예기치 못한 결과가 발생할 수 있다.  

### `X-Forwarded-For` 헤더 내 `proxy hop` 수 이전의 값
앞에서 헤더는 변조 가능하다고 말했다. 하지만 서비스에서 구성해둔 네트워크로 넘어온 뒤에는 값이 변조되기 쉽지 않다. 이런 맥락에서 `X-Forwarded-For` 헤더에서 오른쪽에 위치한 IP 일수록 신뢰할 수 있는 IP 이다. 

서버로 오기 전까지의 서비스 네트워크 hop 수를 `proxy hop` 이라고 하자. 이 `proxy hop` 을 알 수 있다면, `X-Forwarded-for` 헤더의 오른쪽 끝에서 proxy hop 만큼 왼쪽에 있는 IP 를 Client IP 로 판단할 수 있다. 서비스에서 진행한 proxy 구성의 hop 이 고정되어있거나, 알 수 있다면, proxy hop 이전의 값을 client ip 로 사용할 수 있다. 

이 방법의 문제점은 고정된다고 생각했던 `proxy hop` 이 언제까지나 고정되지 않기 때문이다. 프록시가 어떻게 구성되는 지에 따라 Client IP 추출에 영향을 줄 수 있다는 점은 불필요한 의존성을 만든다. (네트워크 구성에 따라 서비스가 변경되어야 한다는 점은 권장되지 않는다. )

### `X-Forwarded-For` 헤더 내 가장 우측의 Public IP
다시 `X-Forwarded-For` 헤더에서 오른쪽에 있는 IP 일 수록 신뢰할 수 있는 IP 라는 점에 집중하자. 그리고 사용자 요청이 인터넷을 통했다는 점을 생각하면, 사용자는 서비스로 요청을 보내기 위해서 공인 IP 를 거쳐야 한다. 

실제 IP 가 x.x.x.x 인 사용자가 값을 `X-Forwarded-For` 값을 변조하여 `1.1.1.1` 을 넣었다고 하자.
이 값으로 요청을 한다면, proxy 는 x.x.x.x 가 요청한 `X-Forwarded-For: 1.1.1.1` 값을 받게 된다. 
서비스는 `X-Forwarded-For: 1.1.1.1, x.x.x.x` 값을 받게 될 것이다. 이 때의 최우측 IP 는 `x.x.x.x` 가 되므로, 이 값을 Client IP 로 판단할 수 있다. 

이 방법에서도 함정이 있을 수 있다. 다만 서비스 네트워크가 공인 IP 간에 프록시하고 있다면, 단순하게 적용하기 어려울 수 있다. 하지만 공인 IP 프록싱이 고정 대역이라면, 해당 값을 필터링하는 식으로 응용해볼 여지도 충분하다. 

### Proxy 에서 특정 헤더에 할당한 값
프록시에서 `X-Real-IP`, `True-Client-IP` 등의 헤더에 기존 Client IP 를 담아두는 방법이 있다. 제한된 상황에서 많이 쓰이기도 하는 방법이다. 

하지만 헤더에 실제 Client IP 를 담는 방법은 보안에 취약할 수 있다. 해커가 특정 헤더에 Client IP 를 담는다는 것을 알고, 이 값을 변조한다면 이 헤더 값을 신뢰할 수 없다. 프록시에서 Client IP 헤더 값을 항상 덮어 쓰는 방법으로 대응할 수도 있다. 하지만 여러 프록시를 거쳐야 하는 경우에는 항상 덮어 쓰는 것이 어려울 수 있다. 서비스의 구성에 따라서 판단하여 사용할 수 있어야 한다. 

### 결론
Client IP 를 추출할 때 생각했던 방안들 중에 가장 신뢰할 수 있었던 값은 `X-Forwarded-For` 헤더에서 가장 오른쪽에 위치한 Public IP 이다. 하지만 빠르게 처리해야 한다면 proxy hop 을 사용하는 방안도 충분히 고려해볼만 한 아이디어였다. 또 proxy 하는 상황이 없다면, 단순 Remote IP 를 가지고도 충분히 Client IP 를 찾을 수 있다. 

하지만 사용자의 네트워크나 서비스 네트워크 환경에서 여러 프록시가 존재하는 일반적인 구성을 고려한다면 X-Forwarded-For 헤더 값에서 가장 오른쪽에 위치한 Public IP 를 추출하는 것이 효과적인 방법이었다.


## 참고
- https://adam-p.ca/blog/2022/03/x-forwarded-for/