Linux LPARファイアウォールでIBM i を保護する
Linux のステートフル Netfilter ファイアウォールはシステム全体のファイアウォールおよびルーターの役割を果たすことができます
IBM の POWER6 および POWER7 仮想入出力システムは、PowerVM バーチャリゼーションと組み合わせると、サーバーを統合するための非常に安定したプラットフォームになります。PowerVM 仮想ネットワーキングを使用して IBM i、AIX、および Linux をすべて同じボックスで実行し、作業負荷を相互接続してアプリケーション要件を満たすことができます。
ただし、仮想化環境でファイアウォール保護を実現するのは難しい場合があります。特に、各 LPAR に LPAR 自身の物理ネットワーク接続をさせるのに、物理イーサネット NIC が十分にない場合は大変です。そこそこの数の LPAR を融通するには、仮想 NIC を使用する必要があります。仮想 NIC によりファイアウォールの接続が複雑になり、アプリケーション・ネットワークの保護されたセグメント間の、ネットワーク容量が制限されます。
さらに、現代の IT 情報ガバナンス・ルールでは、アプリケーションを互いに隔離し、アプリケーション間の通信を徹底的に制御しなければならない場合が多々あります。この場合、LPAR 間をファイアウォールで保護する必要があります。これは外部ファイアウォールでも可能ですが、非常に面倒でパフォーマンスも制限されます。 PowerVM の仮想イーサネットは、ステートレス・パケット・フィルタリングと呼ばれる制限された形の隔離をサポートしていますが、最高レベルの保護は実現しません。また、ポリシーを指定するオプションも制限されています (PowerVM のパケット・フィルタリングの詳細については、"Secure Your IBM i LPARs" (2011 年 10 月、記事 ID 65391 SystemiNetwork.com を参照)。
今日の外部ファイアウォールは、「ステートフル」パケット・フィルタリングという手法を利用します。このフィルタリングでは、ファイアウォールは 2 つのエンドポイント間の、各ネットワーク・セッションの状態を追跡します。ステートフル・フィルタリングは重要です。パケット伝送において異なるルールがセッション期間中の異なる時間に適用されるためです。ステートレス・フィルタリングでは、アプリケーション・サーバーを苦しめるようなネットワーク・スキャンおよびサービス妨害攻撃に対して保護しません。ステートフル・ファイアウォールはそうした保護を実現し、多数の新しいポリシー制約機能を提供します。
かつて IBM は、IBM i および AIX にネイティブのステートフル・ファイアウォール機能を提供していましたが、ユーザーが代わりに PowerVM ステートレス・パケット・フィルタリングを採用すると考え、IBM は何年か前にそれらの機能の開発を中止しました。幸い、オープン・ソース・ソフトウェアが Linux という形で窮地を救い、どの Power プラットフォームにも、独自の組み込みペリメーターおよびアプリケーション間保護を行うことができる、性能の良いソフトウェアを使用したステートフル・ファイアウォールを提供しています。
外部ファイアウォールと内部ファイアウォールの動作の違い、また Linux 組み込みファイアウォールの機能を理解することで、自分の PowerVM 環境で最先端の保護を計画し、配備することができます。
ファイアウォール・デプロイメント・モデル
2 つ以上の LPAR を実行している IBM Power システムでは、2 種類の方法でファイアウォールを配備でき、システム・モデルに応じて 2 種類の仮想イーサネット・テクノロジーがあります。
POWER6 以前は、仮想イーサネットは LPAR 間の接続を行い、仮想入出力サーバー (VIOS) は、外部ネットワークへ直接 LPAR を接続していました。POWER6 以降のシステムでは、ネットワーク・インターフェースは Host Ethernet Adapter (HEA) または Integrated Virtual Ethernet (IVE) と呼ばれています。IVE は 2 つまたは 4 つの物理イーサネット・ポートをサポートし、物理ポートごとに最大 16 個の Logical Host Ethernet Adapter (LHEA) をサポートしています。
VIOS 対応仮想イーサネットは、 IBM i などの 1 次ホスト・オペレーティング・システムで制御され、一方 IVE はハードウェア管理コンソール (HMC) で制御され、OS を独立させています。いずれのタイプの LPAR イーサネットでも、LPAR を接続して 仮想 LAN、つまり VLAN を分離できます。VLAN は、個々の物理イーサネット・セグメントと論理的に同等です。(PowerVM 仮想イーサネットの詳細については、"Configuring Integrated Virtual Ethernet on Power6," 記事 ID 62105 を参照。) この記事では、両方のタイプの論理イーサネット接続に言及する場合「Virtual Ethernet」(Veth) という用語を使用します。
最も単純なデプロイメント (図1) では、外部ファイアウォールは IBM Power Systems サーバー上の 1 つの物理イーサネット・ポートに接続し、PowerVM は、LPAR がそれぞれ接続する高速内部仮想イーサネット LAN (VLAN) を実現しています。このアプローチでは、外部攻撃から LPAR 作業負荷を保護しますが、LPAR を隔離したり、細分化されたネットワーク・セキュリティー・ポリシーを提供したりする方法は実現していません。
LPAR を隔離するには、各 LPAR を自身のプライベート・ネットワーク・セグメントまたは VLAN に接続する必要があります (図2)。この場合、VLAN 対応外部ファイアウォールが必要です。これは、基本的な単一の LAN ファイアウォールより高価で複雑です。異なる LPAR 上のアプリケーションは、外部ファイアウォールのポリシーで許可されている場合を除き、現在互いに通信できませんが、1 つの物理イーサネットはパフォーマンスのボトルネックになります。許可されている LPAR 相互通信は、物理 NIC の有限な帯域幅を求めて、外部トラフィックと競合する必要があります。
しかし、内部ソフトウェア・ファイアウォールを使用すると、アプリケーション間をフルスピードで相互通信しながら、外部ファイアウォールへコストの掛からない選択を実現することができます。手短に説明すると、Linux LPAR はそのようなファイアウォール機能に完璧なホストです。Linux カーネルには、優れた性能を発揮する組み込みファイアウォール機能があるというのがその理由です。
図3 は、Linux LPAR ファイアウォールを配備して、コモン VLAN で 1 つ以上のアプリケーション LPAR を保護できる方法を示しています。Linux LPAR は仮想イーサネット・インターフェース (Veth0) を 1 つ、ホスト・システムの物理イーサネット NIC に接続します。この NIC は外部「ダーティー」ネットワークにつながっています。2 つ目の仮想イーサネット (Veth1) は内部 VLAN に接続し、各 LPAR もそれに接続されています。これは図 1 のセットアップに機能的に理想的ですが、物理ファイアウォールの必要性をなくしています。
しかし、統合 Linux ファイアウォール LPAR の実質的なメリットは、アプリケーション LPAR を互いに隔離する必要がある場合に発生します (図4)。PowerVM の内部 VLAN 機能を活用することで、アプリケーション LPAR ごとに、それぞれ一意の IP サブネット・アドレスを備えた VLAN を個別に作成でき、それらをタグ付き VLAN インターフェースとして、 Linux ファイアウォール LPAR に接続できます。Linux LPAR は、システムのすべての LPAR 間、また LPAR と外界の間の、中央ファイアウォールおよびルーティング・サービスを提供します。Linux はオープン・ソースであるため、ソフトウェア・ファイアウォールを構成し、管理するのに役立つ、幅広いファイアウォール・ポリシー・システムが存在します。
Linux ファイアウォール機能
ステートフル・ファイアウォール機能を提供するため、Linux は統合パケット・フィルタリング・サービスを Netfilter というカーネルに組み込んでいます。Netfilter そのものはファイアウォールではありませんが、Netfilter インターフェースが Linux IP プロトコル・スタックをつかみ、そこからファイアウォール・ソフトウェア・パッケージが IP スタックを通過するパケットと対話できます。
OS としての Linux には、ファイアウォールとしての役割にぴったりな独自機能がいくつかあります。まず、そのオールインワン式カーネル・アーキテクチャーのおかげで、Linux にはパケット処理オーバーヘッドが極めて低くなっています。ある調査では、FreeBSD、Linux、Mac OS X、Solaris、Windows の 5 つのオペレーティング・システムについて 10GigE イーサネットでパケット処理した場合、Linux が最速であることがわかりました (myricom.com/scs/performance/Myri10GE)。Linux は、テスト・システムで CPU オーバーヘッドが最低で、最高の連続スループットを達成しました。特に、ファイアウォールに最も負荷が掛かる小規模パケットについてそれが見られました。
また Linux は、ルール生成プログラム、グラフィカル・インターフェース、侵入検知予防、接続監視など、多数のファイアウォール処理用付属ツールを提供しています。それらのオープン・ソース・ツールは比較的簡単に Linux on Power にポートできます。
ほとんどの Linux ディストリビューションに同梱された Linux ファイアウォール・サポートの基本レベルを "iptables" と呼びます。サポートされている Linux ディストリビューション、Red Hat Enterprise Linux (RHEL) と SuSE Linux Enterprise Server 両方に iptables が組み込まれています。IBM の Linux on Power Installation Toolkit を使用してこれらの Linux ディストリビューションのいずれかをインストールする場合、iptables は基本ルール・セットであらかじめ設定され、有効になっており、そのまますぐにファイアウォール機能を使用できます。
完全に実行準備済みのファイアウォールに対して iptables をそのまま使用できます。出荷された iptables ソフトウェアはコマンドライン構成インターフェースを使用しますが、IPv4 と IPv6 の両方、さらにネットワーク・アドレス変換 (NAT) および他のステートフル・ファイアウォール機能をサポートしています。または、iptables を追加ソフトウェアで増強し、より分かりやすいインターフェースまたは高度な監視制御機能を提供できます。
iptables を使用する前に、それが Linux 組み込み Netfilter カーネル・インターフェースとどのように作用してトラフィック・フローを制御するのか理解することが大切です。
Netfilter を暴く
Netfilter は、ファイアウォール・パケット処理について Linux カーネル内に、入力、ローカル入力、ローカル出力、フォワード、出力という 5 つのインターセプト・ポイントを提供しています (図5)。各ポイントで発生する処理の概要を次に説明します。
- 入力: ルーティング決定が行われる前に、すべてのパケットはこのインターセプト・ポイントを通過します。ネットワーク・アドレス変換 (NAT) が必要な場合、このポイントで変換されます。
- ローカル入力: ファイアウォール自体に発信されたパケットのみ、この処理パスに入ります。リモート管理など、ファイアウォール固有のネットワーク相互作用を制御するルールを適用する場合に使用します。
- ローカル出力: ファイアウォール自体から発信されたパケットのみ、この処理パスに入ります。
- フォワード: 他のマシンに発信されたパケットはこのインターセプト・ポイントを通過します。
- 出力: ルーティング決定が行われた後、ローカル・マシンから出て行く場合にすべてのパケットはこのインターセプト・ポイントを通過します。
パケットは 3 つのうち 1 つのパスで Netfilter を通過できます。これは、iptables ルール・セットを通して次の対応する 3 つのパスで示します。
- 入力、フォワード、出力: ファイアウォール自体に向かわないトラフィックを対象とする最も一般的なパス
- 入力、ローカル入力、ローカル出力: ポート 22 または 80 の管理トラフィックなど、ファイアウォールに発信されたトラフィック
- 出力: syslog および SNMP トラップなど、ファイアウォールが生成するトラフィック
ほとんどの iptables ルールは、最初のパスに沿ってパケットを処理します。最初のパスにより 3 箇所にポリシーが施行されます。iptables ルール処理エンジンにより、プロトコル・タイプ (icmp、tcp、udp など)、ソースまたは宛先 IP アドレスおよびポート、ホップ・カウントおよび TOS フラグなどのパケット属性まで、任意のパケット部分のパターン・マッチングを行うことができます。
ルールはチェーンで編成されており、各チェーンが異なる Netfilter インターセプト・ポイントを表しています。あるパケットがチェーンのあるルールに一致すると、そのルールに関連したアクションが行われ、以降のルールは評価されません。最も一般的なアクションは、パケットが次のインターセプト・ポイントまで通過することを許可する ACCEPT、またパケットを破棄する DROP です。パケットを破棄した場合、今後のインターセプト・ポイントでパケットは表示されません。
sudo iptables -L コマンドを使用して、現在実施中のテーブルを表示します。図6 は、デフォルト名が INPUT の一般的な iptables ルール・チェーンを示しています。
最初のルールは、確立された既存の TCP、UDP、または ICMP フロー、またはセッションの一部であるすべてのパケットを ACCEPT します。iptables はステートフルであるため、非アクティブ・セッションを自動的にタイムアウトしながら、進行中のすべてのセッションのテーブルを保守します。したがって、他のルールによってすでに入念に検査されたパケットの一部であるパケットは、エクスプレスレーンに移送され、直接宛先に送信されます。2 番目のルールは、保護ネットワークで任意のデバイスへの SSH トラフィックを明示的に ACCEPT します。最後のルールは、以前のルールで処理されなかったパケットを DROP します。このルールは、保護を目的とするどのチェーンでも、最後のルールになるということが重要です。
iptables ルールのその他のアクションとして、パケットを優先度の異なるキューにソートして、それらを Quality-of-Service (QoS) コントロールにマークする CLASSIFY、TOS、および DSCP、新しい SSH 接続要求などパケットに関するログ・エントリーを作成する LOG、ネットワーク・アドレス変換 (NAT) を行う DNAT、SNAT、NETMAP、および MASQERADE があります。これらのアクションをその他と含めてさまざまなルール・チェーンで混合させ、一致させることで、複雑なポリシーを実装すると同時に、ファイアウォールの動作の可視性を維持できます。また、ロギング機能を使用して、ルール・チェーンをデバッグするときにシェル・スクリプト記述に挑むことができます。問題の診断に非常に重宝します。
コマンドライン・ツールを使用して、ルールを一度に 1 つずつ iptables 操作ルール・データベースに入力したり、それらをすべてまとめてテキスト・ファイルからインポートしたりできます。オープン・ソース・ツールである iptables は、インターネットから操作指示の詳細、チュートリアル、ベスト・プラクティス・ガイドをすぐに見つけることができます。
iptables を強化する
iptables は RHEL および SLES for Linux on Power に同梱されているデフォルトの Netfilter ファイアウォール・ツールですが、代替ツールセットを考えなければならない場合があります。すべて、それら独自のパケット処理拡張子、ユーザー・インターフェース、マネジメント・エイドを備えた既存の iptables エンジンに機能を追加します。5 つの人気の機能のリストを次に示します。
- Firewall Builder: BSD pf, などの他のオープン・ソース・ファイアウォール、また Cisco ASA などのプロプラエタリー・アプライアンスなど、幅広いファイアウォール・プラットフォームのルール・セットを維持できるクロスプラットフォーム・ファイアウォール管理ツール。ドラッグ・アンド・ドロップ Web インターフェースおよび変更管理やバージョン管理など、多数の構成トラッキング・エイドが特長です。
- Firestarter: 高度な Linux カーネル・チューニング機能を組み込んだ X 対応ルール構築およびファイアウォール管理機能です。
- Shorewall: iptables に基づいて構築されているオープン・ソース・ツールで、合理化されたコマンドライン・ツールを提供し、iptables ルール・セットの管理を簡略化します。ゾーン・コンセプトを実装し、非武装地帯は DMZ、保護されたローカル・エリア・ネットワークは LAN など、宛先デバイスが常駐している場所に基づいてポリシーを定義できます。
- ufw/Gufw (単純なファイアウォールを表す): Gufw は ufw のグラフィカル・インターフェースです。これらはまとめてルール構築およびファイアウォール管理 X 対応インターフェースを提供します。
- Zorp: GPL オープン・ソース・バージョンがライセンスされている商用 Linux ファイアウォール。ただし、有償エディションのみ GUI インターフェースが備わっています。
持ち帰り用ファイアウォール
対応している RHEL および SLES Linux on Power ディストリビューションにすでに組み込まれている Netfilter および iptables のハイレベル機能セット、また他の汎用OS パケット処理に対する Linux のパフォーマンス上の利点を考えると、今日 LPAR を保護するのに Linux ファイアウォールを使用しない手はありません。基本的な iptables ツールを実行することから始めて、アプリケーションに合った適切な機能拡張パッケージを評価してください。これでハッキングされなくなります。
