ロード バランサーと実際の IP の関係がセキュリティをどのように危険にさらすか?

セキュリティ スペシャリストであることの利点の 1 つは、多数のチームと連携できることです。監査後、セキュリティ専門家はデータベース管理者やアナリストと協力する機会を得ます。アプリケーションが適切かつ安全に機能するために、これらのチームは共通の基盤を持つセキュリティの脆弱性に対処しようとします。これらのチーム間の対話は、実際の IP に関するいくつかの問題を引き起こします。

プロキシと実際の IP の概念

今日の Web アプリケーションは、複数のアプリケーション サーバーとデータベース システムで実行されています。2 つのアプリケーション サーバーが同じソース コードを共有しているとします。ユーザーからの要求は、負荷状況に応じて、これらのサーバーのいずれかによって満たされる準備ができています。アプリケーション サーバーの前で HTTP 要求を処理する負荷分散メカニズムは、どの要求をどのアプリケーション サーバーに転送するかを決定します。これは、ミドルウェア システム管理者とソフトウェア開発者に大きな疑問を投げかけます: ユーザーの実際の IP アドレスは何ですか?

プロキシは、2 つのシステム間のデータ転送を担当します。ロード バランサーは、プロキシを担当するメカニズムです。つまり、1 つのシステムだけがユーザーとアプリケーション サーバーの両方と通信します。ネットワーク トラフィックに関しては、Web A または Web B サーバーは常にロード バランサーの IP アドレスと通信します。ユーザーにも同じことが言えます。セキュリティ プロフェッショナルにとって、ロード バランサーは時間ベースの SQL インジェクション攻撃で深刻な問題を引き起こします。しかし、ここでの主な焦点は IP スプーフィングです。

X-Forwarded-For と IP の関係

X-Forwarded-For、開発者、ミドルウェアの関係を考えてみましょう。たとえば、アプリケーションの開発者のタスクが、ユーザーによる間違ったパスワードの試行など、すべてのアクティビティを IP アドレスとともに記録することであるとします。最初に、開発者は、HTTP 要求が使用するプログラミング言語によって提供される機会に遭遇したときにユーザーの IP アドレスを決定し、アプリケーションでこのデータを引き続き使用しようとします。

その IP アドレスは開発プロセス全体で固定されるため、テスト中は常に同じアドレスが表示されます。これは、通常、企業ネットワーク内のユーザー コンピューターは MAC アドレスを介した静的 IP で動作するためです。ユニットはいくつかの受け入れテストを実行します。ただし、これらには問題があります。テスト ユニットは、この問題をソフトウェア開発者に転送します。

この段階で、開発者は開発環境でコントローラーを作成し、アプリケーションに送信された HTTP 要求を raw 形式で確認できます。これは、全員が同じ IP アドレスを持っているためです。これにより、X-Forwarded-For を使用できるようになります。

X-Forwarded-For というヘッダー情報がアプリケーション サーバーに送信されます。この段階で、ソフトウェア開発者は、ログに表示されるロード バランサーではなく、ipconfig で制御する IP アドレスを確認します。多くのプログラマーは、次のようなコード ブロックでこの問題を解決できると考えています。

function getIPaddress() {
    $ipKeys = array(
'HTTP_CLIENT_IP',
'HTTP_X_FORWARDED_FOR',
'HTTP_X_FORWARDED',
'HTTP_X_CLUSTER_CLIENT_IP',
'HTTP_FORWARDED_FOR', 'HTTP_FORWARDED',
'REMOTE_ADDR'
);
    foreach ($ipKeys as $key) {
        if (array_key_exists($key, $_SERVER) === true) {
            foreach (explode(',', $_SERVER[$key]) as $ip) {
                $ip = trim($ip);
                if (validate_ip($ip)) {
                    return $ip;
                }
            }
        }
    }
    return isset($_SERVER['REMOTE_ADDR'])? $_SERVER['REMOTE_ADDR']: false;
}


これだけでは不十分です。開発者は、受信した値が有効な IP アドレスかどうかを確認する必要があります。

上記はすべて開発者が扱う部分に属していました。しかし、アプリケーションが適切かつ安全に動作するためには、チーム (理論上は連携しますが、実際には互いに極端な点で連携します) は、共通の基盤を持つセキュリティの脆弱性に対処しようとします。ここで、ロード バランサの構成を担当する担当者の観点から問題を見てみましょう。

システム管理者は、HTTP 要求のデータは信頼できないため、開発者が X-Forwarded-For などの情報を記録していると考えるかもしれません。これらの管理者は、X-Forwarded-For を送信することがよくあります。ただし、要求を送信したシステムの TCP ソース アドレスも 2 番目のヘッダー値として送信します。True-Client-IP 構造は、この良い例です。

これらすべてをまとめると、クライアント IP スプーフィングと呼ばれる同じ問題に対して、2 つの異なるユニットが異なる経路をたどります。その結果、IP ログと IP ベースの承認が機能しないという重大な問題が発生します。

侵入テストでクライアント IP スプーフィングを検出する方法

ほとんどの侵入テスターは、セキュリティ チェックに Firefox を使用しています。彼らは、単純なアドオン X-Forwarded-For: 127.0.0.1 をすべての HTTP リクエストに使用して Firefox を構成します。そのため、すべての侵入テストでそのような脆弱性を検出できる可能性が高まります。OWASP チェックリストに従って監査を実行すると、そのような脆弱性を確実にチェックできます。ただし、X-Forwarded-For の脆弱性を検出するには、IP アドレスまたは実行されたアクションを表示するアプリケーション内のモジュールが必要です。

X-Forwarded-For 脆弱性を解決する方法

組織は、すべてのソフトウェア チームとアウトソーシング会社に対して、必須の安全なアプリケーション開発ドキュメントを必要としています。たとえば、ユーザーの IP アドレスが必要な場合、会社は事前に計画を立て、ここで使用するヘッダー情報に関するルールを作成する必要があります。そうしないと、異なるチームが異なるソリューションを作成します。そのような状況に対処できない場合、アウトソーシング アプリケーションが登場し、ソース コードの測定が困難になります。一般に、企業はそのような道をたどりたくありません。

しかし、この問題を解決するには、次の F5 ルールを使用できます。

when HTTP_REQUEST {
  HTTP::header remove X-Forwarded-For
  HTTP::header insert X-Forwarded-For [IP::remote_addr]
}


これにより、外部からの HTTP 要求の X-Forwarded-For フィールドが削除されます。次に、要求を送信したシステムの IP アドレスを追加して、要求を送信します。このようにして、X-Forwarded-For に従って動作するソフトウェアの信頼できるリストが作成されます。

要約すると、ここでの最大の目標は、HTTP 要求に対していくつかのチェックを実行し、信頼できる環境を作成することです。上記のコード ブロックは、これに使用できる良い例です。

企業向けのサイバーセキュリティ フレームワークとドキュメント

互いに独立しているように見えるユニットは、実際には全体の一部です。そのため、すべてが体系的に機能する必要があります。事前に決められたルールは、各ユニット間で適用する必要があります。このような運用システムを採用しないと、X-Forwarded-For の脆弱性など、多くの問題が発生する可能性があります。このためには、すべてを事前に検討し、できるだけ包括的な文書を使用する必要があります。

そして、この大規模なシステムのすべてのユニットは、サイバーセキュリティ フレームワークを採用して実装する必要があります。出発点は、これらのフレームワークの動作ロジックを調査して学習することです。