ロードバランサーをファイアウォールの背後に配置する理由
私は、内部ネットワーク上の5つのWebサーバーのいずれかにインバウンドHTTP接続をプロキシするF5ロードバランシングデバイスの購入を検討しています。私の想定では、F5の外部インターフェースはインターネットに面し、内部インターフェースはWebサーバーが存在する内部ネットワークに面することでした。しかし、私がオンラインで見ているいくつかの図では、F5デバイスを配置します背後ファイアウォールこの配置により、余分なトラフィックがファイアウォールを通過し、ファイアウォールが単一の障害点になります。
この構成の根拠は何ですか？
私はクラシックだと思います：
Firewall <-> Load Balancer <-> Web Servers <-> ...
高価なハードウェアベースのファイアウォールの時代からほとんど残っています。私はそのようなスキームを実装したので、それらは機能しますが、セットアップ全体がより複雑になります。単一障害点を排除するには（たとえば、ファイアウォールのアップグレードを許可するには）、2つのファイアウォールと2つのロードバランサー間のトラフィックをメッシュ化する必要があります（レイヤー2メッシュまたは適切なレイヤー3ルーティングを使用）。
パブリッククラウドでは、次のようなものを実装する傾向があります。
Load Balancer <-> [ (firewall + web) ] <-layer 2 domain or ipsec/ssl-> [ (firewall + app/db) ]
率直に言って十分です。
- ロードバランサーを使用してSSL接続を終了している場合、ロードバランサーの前に配置されたファイアウォールは、暗号化されたトラフィックを検出するため、非常に基本的なレイヤー3フィルタリングのみを実行します。
- F5にはすでにファイアウォールが付属しています。これは、配置したフィルタリングルールと同じくらい優れています。
- レイヤー3に関しては、多層防御の引数はIMHOには弱いものです。Webアプリケーションの攻撃ベクトルはSQLインジェクションであり、ファイアウォールを作動させてルートアクセスを取得するものではありません。
- Puny webサーバーのコアは通常、tcp以降のフィルタリングを処理するのに十分です。
トピックに関するいくつかの議論を見て幸せです。
これは自明だと思っていました。ファイアウォールの背後に何かを配置したのと同じ理由です。
そのファイアウォールを通過する「余分な」トラフィックがあるとは言いません。
5,000の受信リクエストがあり、1,000のリクエストを各サーバーに送信する場合、5,000のリクエストを1つのサーバーに送信した場合、またはファイアウォールをF5の背後に配置した場合（すべて5,000リクエストは、ある時点でそのファイアウォールを通過する必要があります。それ以外の場合は、「プライベート」ネットワーク上にはありません）。
しかし、ファイアウォールが単一障害点であることは事実ですが、単一のF5を購入することを考えずに予算に没頭している場合、そのF5も単一障害点になります。
完全冗長システムを構成する場合は、アクティブ/パッシブHAクラスターに2つのF5が必要です。アクティブ/パッシブHAクラスターにも2つのファイアウォールがあります。
それらはF5のドキュメントでは単一のグラフィックで描かれている場合がありますが、これは物理的なセットアップ（2つのデバイス、そのうちの1つはHAスタンバイ）ではなく、ファイアウォールの論理的な外観（すべての要求に対応する1つのデバイスがある）を示しているためです。 。
ロードバランサーをEdgeファイアウォールの背後に配置するもう1つの理由は、ロードバランサーがデフォルトでWeb強化されていない可能性があるためです（おそらく、管理インターフェイスに脆弱性があるため、デフォルトですべて許可されている可能性があります）。ファイアウォールの背後に配置し、一般に必要なポートに穴をあけるだけで、脆弱なロードバランサーがインターネットにさらされるリスクを大幅に低減できます。
その理由は、ファイアウォールでWebサーバーを保護することです。この場合、ロードバランサーのポイントは、Webサーバーが単一障害点ではないことを確認し、Webサーバー間で負荷を分散することです。ファイアウォールが1つしかない場合は、単一障害点として受け入れられます。
率直に言って、別個のファイアウォールを用意する必要があるセキュリティ担当者をなだめることです。 bigip asmモジュールはファイアウォールを置き換えることができます。これをサーバーのファイアウォールおよびipsecポリシーと組み合わせ、背後にファイアウォールを設けることで、安全なシステムを構築できます。
通常、ロードバランサーとWebサーバーをDMZ（非武装地帯）に配置します。内部および外部ネットワークからDMZへのアクセスは、ロードバランサがファイアウォールの前にある場合、これらの両方の負荷を分散することはできません。
他の人が投稿したように、冗長機器がない限り、ファイアウォールとロードバランサーの両方が単一障害点になります。
Unetは、inetであり、特定のトラフィックのみを通過させるファイアウォールにのみ接触します。
その他はすべてファイアウォールの背後にあります。
それがまさにそれが行われている方法です。ファイアウォールは「ハード」で、信頼できないものにさらされても安全と見なされています。他のすべては避難所を必要としていると考えられます...
セキュリティの実装をセキュリティの個々の層のセットと見なすことはよくあります。これは多くの場合、階層化セキュリティモデルと呼ばれます。
簡単に言えば、通過する必要があるセキュリティの各層は侵入に対する追加の抵抗に貢献します-各層は攻撃者が不正アクセスを取得する可能性のある全体的な難易度を高めます。
私にとって、インターネットエッジで検出、防止、およびフィルタリング機能を使用することは、さまざまな理由で常に非常に賢明であるように思われました-レイヤードセキュリティのコンテキストでは、パケットをファイアウォールで検査することは完全に理にかなっていると思います最初の防御線-そのようなデバイスには、ADCまたはその他のインターネットに面したネットワーク機器を標的とした攻撃から防御できるという追加のボーナスがあります。
私のポイントを説明する例として;トラフィックがネットワークに入ることを許可される前、つまり潜在的に脆弱なデバイスに渡される前に、プロトコルの適合性を検証するために外部（エッジ）ファイアウォールが適切に配置されているかを検討します。ファイアウォールは、技術仕様に準拠しているが、通常の使用または一般的な慣習から逸脱しているトラフィックのバリエーションとパターンを探すこともできます。これにより、隠されたデータストリーム、チェックポイントをバイパスする試み、またはリクエストの密輸の新しい機能を発見する可能性が高まります。
典型的ですが、多少単純化されていますが、Web/SaaS設計は次のようになります。
- 公衆インターネット
- SPIファイアウォール（Cisco ASA、Fortigate）
- ロードバランサー/ ADC/WAF ** SSL/TLS用語。ポイント**（Big-IP、Baracudaなど）
- 次世代ファイアウォール（PaloAlto、CheckPointなど）
- Webアプリケーションサービス
- ポートベースのファイアウォール（ローエンドのCisco ASAやiptablesなど）
- データベースおよびストレージサービス
必要に応じて、個々のコンポーネントに冗長性を追加できます。
個人的には、ロードバランサーがグローバルな高可用性またはサイトフェイルオーバー（サイトごとに1つのBig-IPのみを必要とする）にデプロイされている場合でも、ファイアウォール（たとえば、サイトごとにファイアウォールごとに2ノード）のローカル冗長性を好みます。