ファイアウォールとロードバランサーを通過した後の HTTP リクエスト

Question

1. クライアントは、ファイアウォールの外部アドレスを使用して開始したと信じている SSL セッションと同じセッション内から応答が返されることを期待します。

クライアントは、ファイアウォールが TCP ストリームを SSL 終了ロードバランサーなどの別のデバイスに渡すかどうかは知りません。また、ロードバランサーが終了された SSL セッションを内部バックエンドサーバーに渡すかどうかも知りません (ロードバランサーがデータをバックエンドサーバーに再暗号化された https 形式で渡すか、暗号化されていない http 形式で渡すかは関係ありません)。クライアントは、何らかの方法で IP アドレス (たまたまファイアウォールの外部 IP) との SSL セッションを確立したことだけを知っています。

ファイアウォール、ロードバランサ、SSL ターミネーションのレイヤーを通過して、リクエストはバックエンドサーバーに届きます。ただし、バックエンドが応答を準備するときに、バックエンドサーバーが送信者の IP アドレスを確認し、そこにクライアントの外部 IP アドレスが見つかった場合は、クライアントの IP アドレスに直接応答します。バックエンドからクライアントに直接送信された応答は、クライアントが開始してリクエストを送信した SSL セッションの外部で受信されます。クライアントは当然、このような応答を期待していないため、応答を拒否します。

したがって、クライアントが開始した SSL セッションを介して応答が確実に届くようにするには、ロードバランサはリクエストをバックエンドサーバーに渡す前に微調整する必要があります。

まずクライアントの SSL セッションを復号化し、次に元のリクエストを変更して、ソース IP アドレスをロードバランサに属するソース IP アドレスで上書きしてから、リクエストをバックエンドサーバーに送信します。

バックエンドサーバーは、要求がロードバランサから発信されたと認識し、元のクライアントではなくロードバランサに応答を送信します。

ロードバランサは再度データを変更するため、応答はバックエンドサーバーからではなくロードバランサから送信されたように見えます。その後、ロードバランサはクライアントと確立した同じ SSL セッション内でデータを暗号化し、応答を直接クライアントに送信します。

クライアントはこれを喜んで受け入れ、応答を生成するために使用された実際のネットワークパスを認識しません。

ロードバランサによって行われるこれらのIP変更は、ソースNAT(SNAT) は、私がこれまで使用したすべてのロードバランサーに共通しています。

簡潔にするため、パブリックアドレス空間とプライベートアドレス空間間のファイアウォール変換ファイアウォールによる書き換えとロードバランサによる書き換えを混同しないように、この質問を完全に分離することをお勧めします。ファイアウォールの書き換えはさまざまな方法で実行できるため、ファイアウォールブランドの選択が決定または絞り込まれたら、独自の質問に値します。それまでは、着信パケットまたは発信パケットがファイアウォールを通過するときにファイアウォール内で発生する魔法と考えてください。

上記のように正しい設定を確認する簡単な方法は、内部クライアントを使用して、クライアントとロードバランサ間、およびロードバランサとバックエンドサーバー間で暗号化されていない http セッションを構成することです。

次のようなパケットスニファーを使用するとワイヤーシャーククライアント、ロードバランサ、バックエンドでは、任意の要求/応答ペアと各ネットワーク部分に対して、これらの書き換えの効果を実際に確認できます。

セットアップが機能し、プロセスが理解できたら、最初にクライアントからロードバランサへのパスを暗号化し、次にロードバランサからバックエンドへのパスを暗号化できます。これは、学習曲線を緩和し、正しい最終構成を促進するための提案です。

注意すべき点の 1 つは、バックエンドサーバーがリクエストを認識する点です。

実際の外部クライアントの数に関係なく、バックエンドは 1 つのクライアント (内部ロードバランサの SNAT アドレス) のみを認識してログに記録します。

このジレンマは、ロードバランサがリクエストを SNAT することによって生じますが、ロードバランサがバックエンドサーバーに実際のクライアントの外部 IP アドレスを通知することによって解決されます。リクエストのソース IP 自体が変更されると、実際のクライアント IP アドレスの情報は、HTTP リクエストに HTTP ヘッダーを挿入することによってバックエンドに渡されます。

ヘッダーには、すでに使用されていない有効な名前を指定できます。一般的な選択肢はX-転送先。

この修正が機能するための最初の要件は、このようなヘッダーを挿入するようにロードバランサーを構成することです。2 番目の要件は、このヘッダーの存在をバックエンドサーバーに通知することです。構成はロードバランサーとバックエンドサーバーのブランドに固有のものであり、簡単に Google で検索できます。ここたとえば、Tomcat バックエンドを x-forwarded-for からログを記録するように構成する方法です。最後に ARR を構成してからかなり時間が経っており、x-forwarded-for がどのように追加されたかを記憶では思い出せませんが、動作させるにはいくつかの実験と少しのグーグル検索が必要だったことを思い出します。

2) はい、上記のように Wireshark などのプロトコルデコーダーによってトラフィックをスニッフィングできるため、攻撃ベクトルが存在します。

これは、攻撃者がネットワークトラフィックにアクセスできることを前提としています。

ロードバランサからバックエンドへのトラフィックがクリアテキストで送信される場合、ロードバランサまたはバックエンドサーバーの構成ミスのトラブルシューティングは容易になりますが、前述のリスクが伴います。

この設計選択をどのように行うかについては、社内だけでなく社外の関係者と話し合う価値があります。

3) CSR は通常、SSL が終了する場所で作成されます。

クライアントからロードバランサへのトラフィックを暗号化するには、ロードバランサで csr 要求を作成します。

ロードバランサーからバックエンドへのトラフィックを暗号化するには、バックエンドサーバーに CSR を作成します。

署名された証明書と対応する秘密キーの両方をバンドルとしてエクスポートし、別のサーバーにインポートする方法があります。これは、すべてのメンバーが同じ証明書を提示する必要があるロードバランサークラスターを構成する場合や、ロードバランサークライアントの SSL 構成を簡素化するために複数の同一のバックエンドを構成する場合 (つまり、ロードバランサーが HTTP データを再暗号化するときにバックエンドサーバーへの SSL クライアントとして機能する場合) に役立ちます。

4) クライアントの SSL 終了を実行する場所を決定します。

一部のファイアウォールでは SSL を終了することが可能ですが、より一般的なのは、TCP ストリームをファイアウォール経由でロードバランサに転送し、ロードバランサでクライアントの SSL セッションを終了する方法です。

バックエンドサーバーが SSL を終了する純粋な TCP ストリームをロードバランサーでロードバランシングすることも可能です。これは珍しいことなので、ここではそのオプションについては説明しません。

最初の SSL が終了したら、たとえばロードバランサと次のジャンプの間でデータを再暗号化するかどうかを決定します。次のジャンプは、バックエンドサーバーまたは別のロードバランサなどになります。

データをクリアテキストで送信するステップや、チェーンの最後のサーバーに到達するステップなど、繰り返します。

SSL を終了することは、ロードバランサが http x-forwarded-for ヘッダーを挿入したり、クリアテキストデータへのアクセスを必要とするその他の操作を実行したりするために必要です。したがって、ロードバランサの前、ロードバランサ上、またはその両方で SSL を終了するのが一般的です。

バックエンドへのトラフィックを暗号化して送信することも、暗号化せずに送信することも一般的です。これは、組織の状況と送信されるデータの目的によって異なります。

SSL オフロードは、ある技術が別の技術に代わって SSL 暗号化/復号化を実行するプロセスを説明する用語です。

これは、SSL を復号化し、クリアテキストをバックエンドに渡すロードバランサーである可能性があります。バックエンドは SSL オフロードされています。

SSL 暗号化/復号化専用の特殊なハードウェア回路を備えたロードバランサにすることができます。ロードバランサの CPU は SSL オフロードされています。などなど...

Answer 1