방화벽이 있고 그 다음에는 LoadBalancer(IIS-ARR 로드 밸런서)와 2개의 IIS 웹 서버가 있습니다. 2개의 IIS 웹 서버는 개인 IP를 사용하여 LAN에 있습니다. 내 웹사이트는 두 웹서버 모두에서 호스팅됩니다. 실제 문제는 내 웹사이트에 결제 게이트웨이가 있고 요청이 웹사이트 이름(예:www.abc.com) 또는 IIS-ARR 로드 밸런서에 구성된 공용 고정 IP입니다.
4가지 질문이 있습니다.
http 요청이 2개의 웹 서버 중 하나에서 처리되는 경우 로드 밸런서에 할당된 웹 사이트 이름/공용 고정 IP에서 요청이 발생합니다. 또는 WebServers 개인 IP가 됩니다.
http 요청이 로드 밸런서에서 LAN 내의 일반 텍스트로 실제 서버로 흐르기 때문에 IIS-ARR 로드 밸런서의 SSL 오프로딩은 공격을 받기 쉽습니다.
내 웹사이트에 대한 SSL CSR 요청을 생성하는 위치입니다. IIS-ARR 서버 또는 두 개의 WebServer 중 하나에서. 필요한 SSL 인증서 수.
요청 전반에 걸쳐 https(SSL)를 유지하는 방법. 클라이언트 브라우저에서 방화벽, 로드 밸런서, 실제 서버까지. (SSL 오프로딩 없음)
답변1
1. 클라이언트는 방화벽 외부 주소로 시작되었다고 생각되는 것과 동일한 SSL 세션 내에서 응답이 나올 것으로 기대합니다.
클라이언트는 방화벽이 SSL 종료 로드 밸런서와 같은 다른 장치에 TCP 스트림을 전달하는지 여부를 알 수 없습니다. 로드 밸런서가 종료된 SSL 세션을 내부 백엔드 서버로 전달하는지 여부도 알 수 없습니다(로드 밸런서가 데이터를 다시 암호화된 https 또는 암호화되지 않은 http 형식으로 백엔드 서버에 전달하는지 여부에 관계 없음). 클라이언트는 방화벽의 외부 IP인 IP 주소를 사용하여 SSL 세션을 어떻게든 설정했다는 것만 알고 있습니다.
방화벽, 로드 밸런서 및 SSL 종료 계층을 통해 요청은 백엔드 서버까지 전달됩니다. 그러나 백엔드가 응답을 준비하면서 백엔드 서버가 보낸 사람의 IP 주소를 보고 거기에 있는 클라이언트 외부 IP 주소를 보면 클라이언트의 IP 주소로 직접 응답하게 됩니다. 백엔드에서 클라이언트로 직접 전송된 응답은 클라이언트가 시작하고 요청을 보낸 SSL 세션 외부에서 수신됩니다. 당연히 클라이언트는 그러한 응답을 기대하지 않으며 이를 거부할 것입니다.
따라서 클라이언트가 시작한 SSL 세션을 통해 응답이 도착하도록 하려면 로드 밸런서는 요청을 백엔드 서버에 전달하기 전에 요청을 조정해야 합니다.
먼저 클라이언트 SSL 세션의 암호를 해독한 다음 요청을 백엔드 서버로 보내기 전에 소스 IP 주소를 로드 밸런서에 속한 소스 IP 주소로 덮어쓰도록 원래 요청을 수정합니다.
이제 백엔드 서버는 요청이 로드 밸런서에서 발생했다고 믿고 원래 클라이언트 대신 로드 밸런서에 응답을 보냅니다.
로드 밸런서는 응답이 백엔드 서버가 아닌 로드 밸런서에서 오는 것처럼 보이도록 데이터를 다시 수정합니다. 그런 다음 로드 밸런서는 클라이언트와 설정한 동일한 SSL 세션 내에 있도록 데이터를 암호화하고 클라이언트에 직접 응답을 보냅니다.
클라이언트는 이를 기꺼이 받아들이고 응답을 생성하기 위해 사용된 실제 네트워크 경로를 인식하지 못합니다.
로드 밸런서에 의해 수행된 이러한 IP 수정을 이라고 합니다.소스 NAT(SNAT)이며 제가 지금까지 작업한 모든 로드 밸런서에 공통적입니다.
간결하게 하기 위해 포함하지 않았습니다.공용 주소 공간과 개인 주소 공간 간의 방화벽 변환. 방화벽이 수행한 재작성과 로드 밸런서가 수행한 재작성을 혼동하지 않도록 해당 질문을 완전히 분리하는 것이 좋습니다. 방화벽 재작성은 여러 가지 방법으로 수행될 수 있으며 일단 방화벽 브랜드 선택이 결정되거나 범위가 좁혀지면 자체적인 질문을 받을 가치가 있습니다. 그때까지는 각 인바운드 또는 아웃바운드 패킷이 방화벽을 통과할 때 방화벽에서 발생하는 마술이라고 생각하십시오.
위에서 설명한 대로 올바른 설정을 확인하는 간단한 방법은 내부 클라이언트를 사용하여 시작하고 클라이언트와 로드 밸런서 간, 그리고 로드 밸런서와 백엔드 서버 간에 암호화되지 않은 http 세션을 구성하는 것입니다.
다음과 같은 패킷 스니퍼를 사용하여와이어샤크클라이언트, 로드 밸런서 및 백엔드에서 특정 요청/응답 쌍과 각 네트워크 부분에 대해 실제로 이러한 재작성의 효과를 확인할 수 있습니다.
설정이 작동하고 프로세스가 이해되면 먼저 클라이언트-로드 밸런서 경로를 암호화한 다음 로드 밸런서-백엔드 경로를 암호화할 수 있습니다. 이는 학습 곡선을 완화하고 올바른 최종 구성을 촉진하기 위한 제안입니다.
한 가지 주의 사항은 요청에 대한 백엔드 서버 인식에 있습니다.
외부 클라이언트의 실제 수에 관계없이 백엔드는 하나의 클라이언트, 즉 내부 부하 분산 장치 SNAT 주소만 보고 기록합니다.
이 딜레마는 로드 밸런서가 요청을 SNAT하도록 하여 발생하며, 로드 밸런서가 백엔드 서버에 실제 클라이언트 외부 IP 주소를 알리도록 하여 해결됩니다. 요청 소스 IP 자체가 수정됨에 따라 http 요청에 http 헤더를 삽입하여 실제 클라이언트 IP 주소 정보가 백엔드로 전달됩니다.
헤더에는 아직 사용되지 않은 유효한 이름이 있을 수 있습니다. 일반적인 선택은 다음과 같습니다.X-전달-For.
이러한 헤더를 삽입하도록 로드 밸런서를 구성하는 것은 이 수정 사항이 작동하기 위한 첫 번째 요구 사항이며, 두 번째 요구 사항은 백엔드 서버에 이 헤더가 있음을 알리는 것입니다. 구성은 로드 밸런서 및 백엔드 서버 브랜드에 따라 다르며 쉽게 검색할 수 있습니다.여기예를 들어 x-forwarded-for에서 로그하도록 Tomcat 백엔드를 구성하는 방법입니다. ARR을 마지막으로 구성한 지 오래되어 x-forwarded-for가 어떻게 추가되었는지 기억할 수 없지만 작동하려면 약간의 실험과 약간의 인터넷 검색이 필요했다는 것을 기억하십시오.
2) 네, 위에서 제안한 것처럼 Wireshark와 같은 프로토콜 디코더로 트래픽을 스니핑할 수 있으므로 공격 벡터가 있습니다.
이는 공격자가 네트워크 트래픽에 액세스할 수 있다고 가정합니다.
로드 밸런서에서 백엔드까지의 트래픽이 일반 텍스트로 전송되는 경우 로드 밸런서 또는 백엔드 서버 구성 오류 문제를 해결하는 것이 더 쉽지만 앞서 언급한 위험이 따릅니다.
이러한 디자인 선택 방법은 외부 이해관계자는 물론 내부적으로도 논의할 가치가 있는 논의입니다.
3) CSR은 SSL이 종료되는 곳에서 흔히 만들어진다.
클라이언트-로드 밸런서 트래픽을 암호화하려면 로드 밸런서에서 csr 요청을 생성하십시오.
로드 밸런서에서 백엔드까지의 트래픽을 암호화하려면 백엔드 서버에서 csr을 생성하십시오.
서명된 인증서와 해당 개인 키를 번들로 내보내는 방법이 있으며, 이를 다른 서버에서 가져올 수 있습니다. 이는 모든 멤버가 동일한 인증서를 제공해야 하는 로드 밸런서 클러스터를 구성하거나 로드 밸런서 클라이언트 SSL 구성(즉, 로드 밸런서가 백엔드 서버에 대한 SSL 클라이언트로 작동하는 경우)을 단순화하기 위해 여러 개의 동일한 백엔드를 구성하는 데 유용합니다. http 데이터를 다시 암호화하기 때문입니다).
4) 클라이언트 SSL 종료를 수행해야 하는 위치를 결정합니다.
일부 방화벽에서는 SSL을 종료할 수 있지만 더 일반적인 방법은 방화벽을 통해 tcp 스트림을 로드 밸런서로 전달한 다음 클라이언트 SSL 세션을 종료하는 것입니다.
백엔드 서버가 SSL을 종료하는 순수 TCP 스트림의 로드 밸런싱을 로드 밸런서에서 수행하도록 하는 것도 가능합니다. 이는 드문 일이므로 여기서는 옵션을 살펴보지 않겠습니다.
초기 SSL이 종료되면 로드 밸런서와 다음 점프 사이에서 데이터를 다시 암호화해야 하는지 여부를 결정합니다. 다음 점프는 백엔드 서버나 다른 로드 밸런서 또는...
데이터를 명확하게 전송해야 하거나 체인의 마지막 서버에 도달하는 등의 단계를 반복합니다.
예를 들어 로드 밸런서가 http x-forwarded-for 헤더를 삽입하거나 일반 텍스트 데이터에 액세스해야 하는 다른 작업을 수행하려면 SSL 종료가 필요합니다. 따라서 로드 밸런서 이전이나 로드 밸런서 또는 둘 다에서 SSL을 종료하는 것이 일반적입니다.
트래픽을 암호화된 백엔드로 보내는 것과 암호화되지 않은 채로 보내는 것도 일반적입니다. 이는 단순히 조직의 상황과 전송되는 데이터의 목적에 따라 다릅니다.
SSL 오프로딩한 기술이 다른 기술 대신 SSL 암호화/암호 해독을 수행하는 프로세스를 설명하는 용어일 뿐입니다.
SSL을 해독하고 백엔드에 일반 텍스트를 전달하는 로드 밸런서일 수 있습니다. 백엔드는 SSL 오프로드되었습니다.
SSL 암호화/복호화 전용 특수 하드웨어 회로가 있는 로드 밸런서일 수 있습니다. 로드 밸런서 CPU는 SSL 오프로드되었습니다. 등등...