실무에서 발생한 IP 스푸핑 : X-Forwarded-For 헤더를 이용한 악의적 접근

🚩개요

 

사내에선 악성 클라이언트의 요청을 차단하기 위해, IP 차단을 사용합니다. 하지만, 차단한 IP의 클라이언트가 차단되지 않고 계속해서 사내 서버의 요청을 보내는 모습이 모니터링 됐습니다.
요청을 처리하는 비즈니스 로직 앞단 미들웨어에 UrlFilter 가 있지만, 정상적으로 악성 IP를 걸러내지 못해 발생한 문제였는데요. 이러한 문제가 발생한 원인과 문제의 핵심 X-Forwarded-For 헤더에 대해 정리해보겠습니다.

 

 

 

🦹‍♂️스푸핑이란

 

스푸핑(Spoofing)은 속이기(spoof)라는 단어에서 나온 말로,
컴퓨터 보안에서 ‘자신의 신원을 속이거나 위조하여 상대방을 속이는 행위’를 뜻합니다.
즉, “신뢰받는 대상인 척 위장해서 접근하거나, 데이터를 조작하는 행위” 로서 “나 사실 서버야”, “나 진짜 사용자야” 라고 거짓말하는 겁니다.

IP 스푸핑, Email 스푸핑, DNS 스푸핑 등 다양한 스푸핑 공격법이 있습니다.
서버가 위조된 IP나 도메인을 신뢰하면, 인증 우회, 세션 탈취, 내부망 침투 가능해지고, 
이메일/문자 스푸핑은 피싱(Phishing)과 결합해 개인정보 유출하는 문제가 발생하기에 매우 위험합니다.

사내에서도 X-Forwarded-For 헤더를 이용한 IP 스푸핑 공격을 받았습니다.

 

 

🧩 X-Forwarded-For 헤더란 

 

X-Forwarded-For 헤더는 클라이언트의 실제 IP 주소를 전달하기 위해 프록시나 로드밸런서가 추가하는 HTTP 헤더입니다.
쉽게 말하면, “원래 요청을 보낸 사용자의 진짜 IP가 뭐였는지 알려주는 역할”을 합니다.

Client  →  Proxy1  →  Proxy2  →  WAS

X-Forwarded-For: <client ip>+ <proxy sever1 ip>+ <proxy sever2 ip>
//특정 구분자(,/+)를 기준으로 split 가능

 

웹 서버 앞단에는 프록시 서버, 로드 밸런서 (예: AWS ELB, Nginx, Cloudflare) 등이 존재합니다.
만약 X-Forwarded-For 헤더 기능이 없다면, 이런 중간 서버들이 대신 요청을 전달할 때, 요청을 받은 서버 입장에서는 실제 사용자 IP 대신 프록시의 IP만 보이게 됩니다.
X-Forwarded-For는 이런 문제를 해결하기 위해 만들어졌습니다.

 

요청의 흐름이 사용자 → Cloudflare → Nginx → WAS 구조라면 다음과 같습니다.

 

서버(WAS) 입장에서는

• 192.168.0.5 : 진짜 사용자 IP
• 162.158.200.1 : Cloudflare
• 10.0.0.3 : Nginx

이 순서로 이해할 수 있습니다.

 

 

 

🚨사내에서 발생한 문제 사례

 

X-Forwarded-For 헤더는 단순한 HTTP 헤더 문자열입니다. 클라이언트(브라우저, 공격자)가 직접 요청에 이 헤더를 넣어 보낼 수 있고, 프록시가 이를 그대로 전달하면 서버는 그 값을 보게 됩니다.

즉, 클라이언트가 임의의 값을 넣을 수 있으므로 절대적인 신뢰를 할 수 없습니다.

 

사내에서도 악성 클라이언트가 X-Forwarded-For 헤더에 127.0.0.1과 같은 내부 IP를 임의로 삽입하여 요청을 전송한 사례가 있습니다. 

• 로드밸런서가 실제 클라이언트의 IP를 +로 구분하여 추가. 
• 이 중 127.0.0.1은 공격자가 조작한 값이며, 3.229.101.27이 실제 클라이언트의 IP임.

 

공격자 보낸 요청

X-Forwarded-For: 127.0.0.1

 

로드밸런서(신뢰 가능한 프록시)가 실제로는 클라이언트(원격 소켓)가 3.229.101.27에서 왔음을 알고, 기존 헤더 뒤에 자신의 원격 peer IP를 덧붙였다면

X-Forwarded-For: 127.0.0.1+ 3.229.101.27

 

• 127.0.0.1 : 공격자가 직접 넣은 값(스푸핑)
• 3.229.101.27 : 로드밸런서가 추가한 실제 연결 IP(즉 진짜 클라이언트 IP)

 

이때, 백엔드서버가 “첫 번째 값(=맨 왼쪽)”을 신뢰해서 사용하면 공격에 당합니다. 반대로 올바르게 처리하면 실제 IP(3.229.101.27)를 얻을 수 있습니다.

 

 

 

💡문제 해결 

 

위에서 본 바와 같이 오른쪽이 실제 클라이언트 IP 라고 생각해, 맨 오른쪽 IP 를 실제 클라이언트 IP 로 판단하면 안 됩니다. 제일 처음에 말했다시피 거쳐온 서버들의 IP 가 계속 남기에 맨 오른쪽에는 사내 로드밸런서/프록시 서버의 IP 가 남기 때문입니다.

 

이러한 위변조 가능성에 대응하기 위해, 웹서버에서는 최종적으로 받은 X-Forwarded-For 헤더에서 가장 오른쪽에 위치한 IP부터 탐색하여 클라이언트 IP로 식별하고, 407오류 발생 시 차단하고 있습니다.

 

config 파일에 allowProxyIPs라는 프로퍼티로, 우리가 알고 있는 프록시(로드밸런서, CDN 등) 주소들을 관리하고,

헤더를 구분자로 분리 후, 오른쪽(끝)부터 왼쪽으로 순회하면서 allowProxyIPs 에 속하지 않는 첫 IP가 “실제 클라이언트” 라고 판단했습니다.

 

또다른 방법으로는 프록시가 X-Forwarded-For를 덮어쓰도록 설정하면(append 대신 replace) 스푸핑 위험을 더 줄일 수 있습니다.

 

1️⃣ 기본 동작 (append 방식)

일반적으로 로드밸런서나 프록시는
요청을 전달할 때 기존의 X-Forwarded-For 헤더가 있으면 그 뒤에 자기 IP를 추가(append) 합니다.

공격자 → (header 조작)
X-Forwarded-For: 127.0.0.1

↓ (프록시가 추가)
X-Forwarded-For: 127.0.0.1, 203.0.113.10

• 127.0.0.1 → 공격자가 조작한 값
• 203.0.113.10 → 실제 프록시가 본 클라이언트 IP

➡️ 이렇게 되면 헤더에 가짜 IP(127.0.0.1) 가 남게 됩니다.

 

 

2️⃣ 덮어쓰기(Replace) 방식

이때 프록시 설정을 append(추가) 가 아니라 replace(덮어쓰기) 로 바꾸면, 기존 헤더가 존재해도 완전히 새로 쓰게 됩니다.

공격자 요청:
X-Forwarded-For: 127.0.0.1

↓ 프록시가 덮어씀 (replace)
X-Forwarded-For: 203.0.113.10

 

결과적으로,공격자가 가짜로 넣은 127.0.0.1 같은 값은 무시되고,진짜 클라이언트 IP만 남게 되어 스푸핑 공격이 막힙니다.

프록시가 X-Forwarded-For를 매번 새로 써서(기존 값 무시) 전달하도록 하면, 공격자가 헤더를 조작하더라도 서버가 속지 않게 됩니다.

 

 

❗주의점

대신 프록시가 여러 대 있으면, 두 번째 프록시에서 첫 번째 프록시의 IP를 덮어써 버리는 문제가 생길 수 있습니다. 실제 운영에서는 그렇게 되지 않도록,  프록시가 여러 대 있으면 가장 바깥에 있는(엣지) 프록시에서만 replace 하도록 설계해야 합니다.

 

→ 내부 프록시에서는 절대 replace 하면 안 됨
→ 내부 프록시들은 append 또는 pass-through 로 설정해야 함

 

Proxy1 (엣지 프록시)

• 클라이언트 IP: 1.1.1.1
• replace 적용 → XFF: 1.1.1.1

Proxy2 (내부 프록시)

• Proxy1이 보낸 XFF 유지
• 자기 IP만 append
  → XFF: 1.1.1.1, 10.0.0.5  //여기서 append 하지 않고, replace 하게 되면 실제 클라이언트IP 가 없어지고, 프록시1 IP만 남게됨.

WAS

가장 왼쪽 IP (1.1.1.1) 을 실제 client IP로 파싱