리버스 프록시가 올바른 클라이언트 IP를 전송하는지 확인하는 방법

알려진 외부 소스와 모든 프록시 헤더 및 백엔드의 최종 파싱된 주소를 비교하여 클라이언트 IP 전달을 확인하세요.

리버스 프록시는 클라이언트 연결을 종료하므로, 프록시가 신뢰할 수 있는 요청 메타데이터를 전달하지 않는 한 백엔드는 일반적으로 프록시의 소켓 주소를 보게 됩니다. 테스트는 직접 피어 주소와 Forwarded, X-Forwarded-For, X-Real-IP를 구분하고, 모든 신뢰할 수 있는 홉을 문서화하며, 인터넷 클라이언트가 로그, 속도 제한 또는 접근 제어에 사용되는 값을 위조할 수 없음을 증명해야 합니다.

외부에서 알려진 클라이언트 IP 테스트 생성

모바일 데이터 또는 다른 외부 네트워크의 장치를 사용하여 요청 직전에 해당 장치의 공용 IPv4 또는 IPv6 주소를 기록하세요. 고유한 경로, 쿼리 값 또는 타임스탬프를 공용 리버스 프록시를 통해 전송하세요.

MDN은 X-Forwarded-For를 프록시 연결 간에 원본 클라이언트 주소를 보존하는 사실상의 헤더로 설명합니다.

해당 요청에 대해 엣지 프록시 로그, 중간 프록시 로그, 백엔드 애플리케이션 로그를 수집하세요. 알려진 소스와 연관된 타임스탬프가 없으면 여러 동시 사용자가 헤더 체인을 모호하게 만들 수 있습니다.

소켓 피어 및 모든 전달된 헤더 기록

백엔드에서 직접 TCP 피어 주소를 Forwarded, X-Forwarded-For, X-Real-IP 및 CDN 전용 클라이언트 헤더와 별도로 기록하세요. 첫 테스트 중에는 원시 값을 덮어쓰지 마세요.

“실제” 클라이언트 IP 처리에 대한 실용적 분석은 정확도가 프록시가 헤더를 설정하거나 추가하는 방식과 이전 값이 위조될 수 있는지 여부에 달려 있음을 경고합니다. 전체 프록시 신뢰 모델은 실제 네트워크 아키텍처와 일치해야 합니다.

백엔드 소켓 피어는 즉각적인 신뢰할 수 있는 프록시와 같아야 하며, 선택된 클라이언트 주소는 외부 테스트 장치와 같아야 합니다. 백엔드가 프록시 주소만 기록한다면 헤더 생성 또는 파싱이 누락된 것입니다.

각 프록시가 헤더를 추가하거나 교체하는 방식 확인

CDN 또는 터널에서 엣지 프록시, 내부 프록시, 애플리케이션까지 모든 홉을 검사하세요. 각 홉이 기존 목록에 추가하는지, 신뢰할 수 없는 입력을 교체하는지, 헤더를 변경 없이 전달하는지 기록하세요.

Sling Academy는 NGINX가 즉각적인 연결에서 X-Real-IP를 설정하고 proxy_add_x_forwarded_for로 체인을 추가할 수 있음을 설명합니다.

첫 번째 신뢰할 수 있는 엣지를 구성하여 클라이언트가 제공한 전달 헤더를 제거하거나 교체한 후 제어된 내부 홉에서 주소를 추가하세요. 신뢰할 수 있는 프록시 수를 정의하지 않고 좌측 또는 우측 값을 무작정 수락하지 마세요.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

백엔드를 알려진 프록시 주소만 신뢰하도록 구성

애플리케이션 또는 웹 서버의 신뢰할 수 있는 프록시 목록을 정확한 리버스 프록시 주소 또는 제어된 서브넷으로 설정하세요. 일반 LAN 또는 인터넷 클라이언트의 직접 연결이 신뢰할 수 있는 헤더 소스로 처리되지 않는지 확인하세요.

Ip2Geo 설명에 따르면 애플리케이션 연결은 로드 밸런서 또는 리버스 프록시에서 시작되며, 원본 IP를 안전하게 파싱하려면 임의 입력을 수락하는 대신 신뢰할 수 있는 홉 규칙이 필요합니다.

컨테이너, 오버레이 네트워크 또는 CDN으로 인해 프록시 주소가 변경되면 지원 범위를 문서화하고 신중하게 업데이트하세요. 프록시가 현재 사설 주소를 사용한다고 해서 모든 사설 주소를 신뢰하지 마세요.

위조된 헤더 테스트 실행

외부 테스트 장치에서 실제 프록시를 통해 연결하면서 위조된 X-Forwarded-For 또는 Forwarded 값을 전송하세요. 원시 수신 헤더, 정규화된 프록시 헤더, 백엔드에서 선택한 클라이언트 주소를 비교하세요.

올바른 결과는 신뢰할 수 있는 엣지가 신뢰할 수 없는 입력을 교체하거나 안전하게 추가하고, 백엔드가 문서화된 신뢰 홉 수를 기준으로 주소를 선택하는 것입니다. 위조된 주소가 인증 또는 허용 목록에 사용되는 값이 되어서는 안 됩니다.

해당 포트에 접근 가능하다면 LAN 세그먼트에서 백엔드 직접 테스트를 반복하세요. 백엔드는 신뢰할 수 없는 직접 클라이언트의 전달 헤더를 무시하고 실제 소켓 피어를 기록해야 합니다.

IPv4, IPv6 및 다중 프록시 경로 검증

IPv4 및 IPv6, 일반 공용 호스트명, 그리고 운영 중인 CDN, 터널 또는 보조 프록시를 통해 테스트를 반복하세요. 로그가 유효한 주소 형식을 보존하고 체인을 잘라내지 않는지 확인하세요.

ZimaSpace의 리버스 프록시 요청 신원 가이드는 올바른 전달 값이 로그를 넘어 왜 중요한지에 대한 주변 맥락을 제공합니다.

알려진 소스가 파싱된 클라이언트 IP와 일치하고, 신뢰할 수 있는 프록시가 원시 체인에 계속 표시되며, 위조 시도가 실패하고, 보안 제어가 정규화된 값을 일관되게 사용할 때만 프록시가 검증됩니다. CDN, 터널 또는 다른 프록시 홉을 추가한 후 다시 확인하세요.