LB·WAF 뒤에서 클라이언트 실제 IP 살리기 (X-Forwarded-For)

· 운영네트워크트러블슈팅

공개 가능한 형태로 익명화한 운영 기록. 명령어·설정은 일반 환경 기준.

앞단에 LB랑 WAF를 두고 나니, WEB·WAS·웹필터 로그의 출발지 IP가 전부 LB/WAF IP 한두 개로만 찍혔다. 실제 클라이언트 IP를 못 보면 게시판 차단 같은 접근제어도, 로그 분석도 의미가 없어진다.

원인은 단순했다. 프록시가 요청을 대신 전달하면서 TCP 출발지가 프록시로 바뀐 거고, 원래 IP는 X-Forwarded-For(XFF) 헤더에 실려 온다. 그래서 각 계층이 이 헤더를 기록하거나(로그), 실제 IP로 인식하도록(웹필터) 잡아주면 된다.

Nginx — 실제 IP로 인식

set_real_ip_from   10.0.0.0/24;   # 신뢰할 LB/WAF 대역
real_ip_header     X-Forwarded-For;
real_ip_recursive  on;

웹필터/접근제어가 remote_addr 기준이면 이걸로 실제 IP가 반영된다.

Apache — 로그에 XFF 남기기

LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %>s %b" combined_xff
CustomLog logs/access_log combined_xff

Tomcat — AccessLog 패턴에 XFF

<Valve className="org.apache.catalina.valves.AccessLogValve"
       pattern="%{X-Forwarded-For}i %l %u %t &quot;%r&quot; %s %b" />

데몬 재기동한 뒤, 외부에서 접속해보고 로그에 실제 IP가 찍히는지, 차단 정책이 실제 IP 기준으로 도는지 확인했다.

한 가지 조심할 건, XFF는 클라이언트가 위조할 수 있다는 점이다. 그래서 Nginx set_real_ip_from처럼 신뢰하는 프록시(LB/WAF) 대역에서 온 헤더만 믿도록 범위를 꼭 지정해야 한다. 아무 XFF나 믿으면 오히려 우회·스푸핑에 열린다.

예전 블로그에 적었던 작업 기록을 옮겨온 글입니다.

← Blog 목록