データセンターなどの大規模環境にファイアウォールを設置する場合、単体のファイアウォールでは処理能力が足りないことがあります。また、当然のことながら、冗長化によるハイアベイラビリティを確保しなければなりません。こんなとき、ファイアウォールのデザインはどうあるべきでしょうか? ロードバランサを使ってファイアウォール ロードバランスを行うのでしょうか? あるいはシャーシ型の大きなファイアウォールを予め導入するのでしょうか? 実は、もっとシンプルで費用対効果の高い方法があります。
100Gbps を超えるような処理能力の大規模なファイアウォールが必要な場合には、冒頭に述べたようにロードバランサに頼ったり、あるいは、最初からブレードが増やせるようなシャーシ型のファイアウォールを使うことが一般的でした。もちろん、これらのソリューションは素晴らしいのですが、費用対効果やラックスペースの確保という視点から考えると、必ずしも完璧なソリューションというわけではありません。
例えば、導入当初は 10Gbps 程度のトラフィックに対するファイアウォール サービスを提供できればいい、という状態で、かつ、今後のトラフィック量の伸び方が明確に予測できない、といった場合に、最初からシャーシ型の大型ファイアウォールを導入するのは、費用やラックスペースという観点から考えると、非効率です。このような場合、最初はスモール スタートができるようなファイアウォールを選択することが必要です。また、やがてトラフィックが増えて、最初に導入したファイアウォールでは処理能力が足りなくなってきた際に、新たにロードバランサを導入してファイアウォール ロードバランスに移行するとなると、ネットワーク デザインが複雑になり、導入作業に手間がかかってしまいます。
これらのソリューションを使わずに、必要になったときにファイアウォールを追加するような方法があれば便利ですし、費用対効果も高く、不必要なラックスペースの占有もありません。シスコの ASA 5500 シリーズのハイエンドモデルである ASA 5585-X シリーズ
には、これを実現する方法があります。ファイアウォール クラスタリングというソリューションです。ものすごく乱暴に言ってしまえば、こんな感じです。
- 同じモデルの ASA5585-X シリーズを並べる。
- トラフィックのロードバランシングは、スイッチやルータの既存の方法に完全に任せてしまい、ファイアウォールでは感知しない。
- ファイアウォール同士を「裏側」のネットワークでつなぐ。
- 行きと帰りで違うファイアウォールにパケットが届いたら、ファイアウォール間で「裏側」のネットワークを使って「なんとかする」。
- 設定は代表となるファイアウォールで一元管理。
絵にすると、こんなイメージです。
このソリューションを使えば、
- 新たにロードバランサを追加することなく、スイッチの既存機能でトラフィックを分散させることで、全体の処理能力と冗長性を向上させることができる。
- 最初からシャーシ型の大型ファイアウォールを導入することなく、必要に応じてファイアウォールを追加することができるため、費用対効果が高く、最初からラックスペースを占有することもない。
- ファイアウォール間のセッション テーブルの同期は行わないので、ファイアウォールに余計な負荷がかかることが無い。
というメリットがあります。
では、なぜこのような方法が実現できるのでしょうか? ファイアウォール間でセッション テーブルの同期を行わないと、行きと帰りのパケットが異なるファイアウォールに届いた場合、ファイアウォールは帰りのパケットを破棄してしまいます。ファイアウォール クラスタリングは、この問題を解決することができます。秘密は、ファイアウォール間の「裏側」のネットワークにあります。この「裏側」のネットワークを Cluster Control Link（CCL） と呼びます。CCL を使って、ファイアウォールの設定同期や互いの死活監視を行っておりますが、この CCL で、先に記載した「なんとかする」を実現しています。ファイアウォール クラスタリングでは、ファイアウォール間でのセッション テーブル同期は、負荷軽減のために行っておりません。この仕組みを2枚の絵で説明します。
以下の図は、行きと帰りのパケットが同じファイアウォールに届いた場合の説明です。このときは、通常のファイアウォールと同じように処理がなされますが、Directorと呼ばれるファイアウォールが選定されます。Director は、そのセッションがどのファイアウォールが処理すべきなのか、すなわちどのファイアウォールが Owner なのかを学習します。
一方、以下の図は、行きと帰りのパケットが異なるファイアウォールに届いた場合の説明です。いきなり帰りのパケットを受け取ったファイアウォール （Forwarder）は、そのパケットを破棄するのではなく、Director となるファイアウォールに、正しいファイアウォール（Owner） がどの ASA なのかを問い合わせ、CCL 経由でそのパケットを Owner に転送します。こうすることで、ロードバランサに頼ることなく、ファイアウォール内で非対称トラフィックを「なんとかする」のです。
当然、非対称トラフィックが多く発生すると、CCL 経由での通信が増え、ファイアウォールの仕事も増えてしまうので、なるべく行きと帰りのパケットが同じファイアウォールに届くように、スイッチ側をデザインすることが必要です。もっとも簡単な方法は、イーサチャネル ロードバランスを使い、イーサチャネルのインターフェイス選定アルゴリズムを、ソースとディスティネーションの IP アドレスペアでハッシュする方法です。inside インターフェイスと outside インターフェイスを同じイーサチャネルに VLAN タグで同居させてしまうと、とてもわかりやすくなりますが、もちろん、inside インターフェイスと outside インターフェイスを物理的に分けても問題ありません。
なお、ASA のファイアウォール クラスタリングでは、ファイアウォールのシャーシをまたいで 1 つのイーサチャネルを形成する Spanned EtherChannel という技術がサポートされており、LACP と互換性のある cLACP というプロトコルで、ダイナミックにイーサチャネルを形成できます。
以下の図では、inside インターフェイスと outside インターフェイスを分けて、Spanned EtherChannel を使ったデザインの例を説明しています。
このソリューションでは、ASA に IPS モジュールを搭載した形でも動作します。ASA に追加された IPS から見れば、届くパケットはファイアウォール クラスタリングにより、必ず行きと帰りのパケットが同じシャーシで処理されていることが保障されていますので、IPS は何も特別なことをしなくても、通常のディープパケット インスペクションや、レピュテーション フィルタリング、ノーマライゼーション チェックができます。つまり、このソリューションでは、大規模環境の IPS も合わせて実現できるわけです。
リモート アクセス VPN が未サポートだったり、一部のアプリケーション インスペクションが使えなかったり、Next Generation Firewall Services がまだサポートできていなかったり、と制限事項はありますが、大規模な環境のエッジ セキュリティをどうデザインするべきか? を考えるときに、ひとつの案としてご検討ください。ASA ソフトウェア 9.0 からサポートされています。筆者のお気に入りソリューションのひとつです。
詳しくはコンフィグレーションガイドをご確認ください。
(英語) http://www.cisco.com/en/US/docs/security/asa/asa91/configuration/general/ha_cluster.html
Authors
