test

Trusted Solaris 管理の手順

ルーティング

ローカルネットワークから外への通信を単一のラベル (PUBLIC など) に制限したいサイトもあります。このようなサイトでは、ネットワーク認可範囲 PUBLIC を外部ネットワークに接続されているインタフェースに割り当てます。Trusted Solaris 環境には、ネットワーク間通信のルーティング手段が何種類かサポートされているため、セキュリティ管理者役割は、サイトのセキュリティポリシーで要求されるセキュリティレベルを実施できるような経路 (ルート) を設定できます。TCP/IP とルーティングの詳細については、『TCP/IP とデータ通信』を参照してください。

背景

同じネットワーク上でのホストからホストへの通信の場合は、ルートやルーターは必要ありません。 (この項では、ゲートウェイと「ルーター」という用語をそれぞれ置き換えて使用することがあります。なぜなら、ゲートウェイがパケットのルーティングを行うからです)。認可範囲チェックは発信元で実行されます。ただし、受信側ホストが Trusted Solaris を実行している場合は、受信先で実行されます。

発信元ホストと宛先ホストが物理的に異なるネットワークに接続されている場合は、パケットは発信元ホストからゲートウェイに送信されます。宛先ホストと最初のホップのゲートウェイの認可範囲は、ルート選択時に発信元ホストでチェックされます。ゲートウェイは、宛先ホストが接続されているネットワークにパケットを転送します。宛先に到達するまでに、複数のゲートウェイを経由するパケットもあります。Trusted Solaris ゲートウェイでは認可範囲の検査が実行されまることがありますが、中間ゲートウェイでは実行されず、単にパケットを受け渡すだけとなります。

ゲートウェイにはそれぞれ、すべての宛先に対するルートリストが保持されます。標準 Solaris のルーティングメトリックでは、宛先までの最短経路に基づくルート選択が可能ですが、Trusted Solaris 2.5.1 および 7 の拡張版は、それに加え、セキュリティ条件を満たしたトラステッドルーティングを実現しています。パケットに IP セキュリティオプションを付加することによって、中間ルーターでも認可範囲チェックに IP ラベルを使用できるようになるからです。トラステッドルーティングは、すべてのゲートウェイが RIP (拡張経路制御情報プロトコル、extended Routing Information Protocol) を認識するかどうかに依存します。したがって、トラステッドルーティングはルーティングに他のプロトコルを使用するインターネットでは使用できません。すべてのゲートウェイが拡張 RIP (経路制御情報プロトコル、Routing Information Protocol) を使用するイントラネット上でのみトラステッドルーティングは使用できます。

トラステッドルーティングを採用しているサイトでは、ラベルなしホストのクラスタの反対側に接続された Trusted Solaris ホストとの通信や、ラベルを認識しないルーターを 1 つ以上経由する通信のセキュリティを確保しなければなりません。このようなサイトでは、セキュリティ管理者役割がトンネリングを設定する必要があります。なお、「クラスタ」および「トンネリング」という用語については、「用語と概念」で定義しています。

修正版 TCP/IP ルーティング機能

トラステッドネットワークの構成とルートの設定を始める前に、セキュリティ管理者役割は次のことを理解しておく必要があります。

セキュリティ管理者役割はまた、次のことも理解しておかなければなりません。これらの項目については、残りの項で説明します。

次の TCP/IP ルーティング機能は、Trusted Solaris の拡張セキュリティ情報をサポートするよう修正されています。

用語と概念

この項では、知っておかなければならない用語から順に定義していきます。各用語は、先に出てきた用語の定義に基づいて定義されます。

ルーター

厳密にいえば、ルーターは 2 個以上のネットワークインタフェースを持ち、あるネットワークから別のネットワークにパケットを転送するマシンのことをいいます。「ルーター」の代わりに「ゲートウェイ」という用語が使用されることもあります。セキュリティ管理者は通常、Trusted Solaris 環境のルートを慎重に選択しなければならないため、機密情報に使用するすべてのルーターのセキュリティ特性を理解しておく必要があります。

信頼度の最も高いルーティングを確保するには、ルーターに Trusted Solaris ホストを使用してルートを設定します。他の種類のルーター上では、必ずしもすべての Trusted Solaris セキュリティ機能が使えるわけではなく、さらに、パケットはラベル付き (MAC) セキュリティ保護なしでルーターを通過できることを念頭に置いておくことが必要です。

Solaris ルーターは、IP オプションセクションに認識不能なラベルが検出されても、パケットを破棄せず、そのまま転送します。しかし、CIPSO、RIPSO、MSIX ルーターの場合は、対応するラベル型がパケットの IP オプションセクションに検出されないと、パケットを破棄してしまいます。たとえば、CIPSO ルーターでは、パケットの IP オプションセクションに CIPSO ラベルが検出されなければ、そのパケットは破棄されます。ホスト間の通信を設定する際は、このような注意事項を理解したうえで、パケットが適切なルーターに経由されるようにしなければなりません。

ルーティングテーブル

各ホストのカーネルに保持されるルーティングテーブルには、ルートが定義されます。このルーティングテーブルの各エントリによって、特定の宛先に対するルートが確定します。

 宛先 (特定のホストまたはネットワーク) 最初のホップゲートウェイ (ルート内の最初のゲートウェイ) ゲートウェイに対応するインタフェース

ルーティングソフトウェアはルートテーブルを参照し、宛先ホストに対するルートを見つけようとします。ルートテーブルに宛先ホストが明確に定義されていない場合は、そのホストが接続された (サブ) ネットワークのエントリを探します。宛先ホストも、そのホストが接続されたネットワークも定義されていない場合は、デフォルトゲートウェイにパケットを送信します (デフォルトゲートウェイが定義されている場合)。デフォルトゲートウェイは複数定義でき、それぞれ平等に扱われます。ポインタによって最後に使用されたデフォルトゲートウェイが記録され、次のルーティングにはリストの次のゲートウェイが使用されます。

注 -

場合によっては、複数のデフォルトゲートウェイによってループが生じることもあります。

トラステッドルーティングをサポートできるよう、Trusted Solaris ルーティングテーブルは、宛先までのホップ数を指定するメトリック (計測データ) に加え、セキュリティ情報も保持するよう拡張されています。「SRI」と「拡張メトリック」については、この後で定義します。

ルーティングテーブルのエントリは、次のどちらかの方法で作成されます。

小規模なネットワークでは、管理者役割が手動でルートを設定し、状況の変化に応じて手動でルーティングテーブルを変更することも可能です。たとえば、外部との通信を、すべて 1 台のゲートウェイで行っているサイトも多数あります。このようなケースでは、その 1 台のゲートウェイが、ネットワーク上の各ホストのデフォルトとして静的に定義されます。

注 -

静的ルーティングを使用するルーターは使用可能であることを公示しないためほとんどの場合、動的ルーティングを使用している他の大半のシステムには認識されません。

大規模なネットワークでは、静的ルートを手動で構成したり管理することは不可能です。大規模なネットワークでは、たいていの場合、動的ルーティングが使用されます。

SRI

トラステッドルーティングに必要なセキュリティ属性のセットを SRI (security routing information) と呼びます。SRI には、ルートの認可範囲を確定するために、常に次の情報が含まれます。

route(1M) のマニュアルページに書かれているように、次のセキュリティ属性を SRI に含めることもできます。

SRI は次のどちらかの方法で取得されます。

拡張 RIP

Xerox Routing Information Protocol (RIP) バージョンは、Trusted Solaris 環境用に拡張されており、ルーターからルートが伝達される際に、ルートのメトリックと共にセキュリティ属性がサポートされるようになっています。インターネットでは別のプロトコルを使用してルーティングが行われるため、拡張 RIP の互換性が保持されるのは、すべてのゲートウェイが RIP を認識できるイントラネット内だけになります。

拡張メトリック

拡張メトリック (Extended Metric) は、標準のルーティングメトリックと SRI の両方から成り、ルーティングテーブルにルートのエントリ単位で保存されます。ルーティングソフトウェアは、これらの拡張メトリックを比較することによって、セキュリティ条件を満たす最短の経路を選択します。拡張メトリックは、route(1M) を使用して、静的ルート用に手動で入力することもできます。ルートを手動で定義する方法については、「認可チェック」を参照してください。

動的ルーティングが使用される場合は、ルーティングデーモンの in.routed がセキュリティ強化された特殊な応答パケットを送信し、検出されたルートを伝達します。

送信側と受信側ホストの間には、複数のゲートウェイを経由する数種類のルートが存在する場合があり、ルートごとに拡張メトリックが異なることもあります。このような場合は、ルーティングソフトウェアによって、SRI がパケットのセキュリティ属性と一致するルートが選択されます。

sec_response パケット

基本的な Solaris システムでは、in.routed(1M) が各インタフェースのリクエストパケットを転送し、他のホストから送られてくるリクエストパケットや応答パケットを待ちます。一方、Trusted Solaris システムの in.routed は、応答パケットを送信する際に必ず sec_response パケットも送信します。このパケットには、ルートのメトリック以外に SRI も含まれています。応答パケットと同様に、sec_response パケットも、1 ホップずつメトリックと SRI を調整しながらルートを伝達していきます。

sec_response パケットは、Trusted Solaris ゲートウェイからは伝送されても、Trusted Solaris 以外の (以下、非 Trusted Solaris と呼びます) ゲートウェイからは伝送されません。2 台の Trusted Solaris ホスト間で、Trusted Solaris ルーターから 非 Trusted Solaris ゲートウェイにルートのセキュリティ情報を送信するには、クラスタのエッジにある Trusted Solaris ルーターにトンネリングを設定する必要があります。こうすることによって、Trusted Solaris ホストとその他のオペレーティングシステムまたは環境で実行されるホストが混在するイントラネットでも、経路制御が可能になります。次の「クラスタ / 雲」および 「トンネリング」を参照してください。

クラスタ / 雲

このマニュアルでいうクラスタとは、0 台以上のホストと1台以上のゲートウェイの集合 (または雲) を指します。

以下に示す 2 つの図では、イントラネットとその中のクラスタが雲の形で示されています。Trusted Solaris クラスタは白抜きの雲で、同ゲートウェイは白抜きの円で囲まれています。また、非 Trusted Solaris クラスタは影のついた雲で、同ゲートウェイは正方形で囲まれています。

次の図は、3 つのクラスタで構成されたイントラネットを示しています。Trusted Solaris ホストの H1 は、Trusted Solaris 7 または 2.5.1 ゲートウェイで 非 Trusted Solaris の雲に接続されています。ホスト H2 は、応答および sec_response パケットを自分のネットワークに伝送します。応答パケットはホスト H1 が接続されたネットワークに伝達されますが、sec_response パケットは伝達されません。sec_response パケットがないと、ホスト H1 はホスト H2 までのルートのセキュリティ情報が入った拡張メトリックを取得できません。なぜなら、中間クラスタの非 Trusted Solaris ゲートウェイで実行されている標準の RIP は、拡張 RIP のパケット を H2 のネットワークから H1 のネットワークに転送できないからです。

図 9-6 イントラネット内のクラスタの例

Graphic

トンネリング

2 つの Trusted Solaris クラスタの間に、トラステッドルーティングを使用する非 Trusted Solaris クラスタが存在するときは、セキュリティ管理者役割はトンネリングを設定して、2 つの Trusted Solaris クラスタ内のゲートウェイが各ルートの拡張メトリックを交換できるようにしなければなりません。クラスタはすべて同一イントラネット内に構成する必要があります。また、以前の Trusted Solaris リリースでは、動的ルーティングと、拡張メトリックを制御する拡張 RIP がサポートされていないため、Trusted Solaris ゲートウェイでは Trusted Solaris 7 または 2.5.1 を実行しなければなりません。図 9-7 は、トンネリングの設定方法を示しています。

1台以上の非 Trusted Solaris ゲートウェイを介してトンネルに設定される Trusted Solaris ルーターは、すべて転送ホストとして機能し、反対側に接続された Trusted Solaris ホストまでのルートの拡張メトリックを伝達します。図 9-7 では、転送ホストゲートウェイ G1 の tunnel ファイルに、ホスト H2 が接続されたネットワークの IP アドレスが保持されます。G1 の Trusted Solaris ルーティングソフトウェアは、H1 までのルートの拡張メトリックを、H2 が接続されたネットワークに直接ブロードキャストします。G2 は H1 までのルートの拡張メトリックを取得し、それを自分のルーティングテーブルに追加します (双方向通信を行う場合は、ゲートウェイ G3 と G4 にも、ホスト H1 のネットワークの IP アドレスが入った tunnel ファイルを作成する必要があります)。

図 9-7 イントラネット内の非 Trusted Solaris クラスタを通過するトンネリング

Graphic

有効なエントリで tunnel ファイルが作成されている場合は、拡張 in.routed デーモンによって、sec_t_response という特殊なラベルなし応答パケットが送信されます。ルートの拡張メトリック情報を含む sec_t_response パケットは、tunnel ファイルにリストされたネットワークに直接送信されます。

図 9-7 では、転送ホストゲートウェイ G1 の tunnel ファイルに、ホスト H2 が接続されたネットワークの IP アドレスが保持されます。G1 の Trusted Solaris ルーティングソフトウェアは、H1 までのルートの拡張メトリックが入った sec_t_response パケットを、H2 が接続されたネットワークに直接ブロードキャストします。このようにして、G2 は H1 までのルートの拡張メトリックを取得し、それを自分のルーティングテーブルに追加します (双方向通信を行う場合は、ゲートウェイ G3 と G4 にも、ホスト H1 のネットワークの IP アドレスが入った tunnel ファイルを作成する必要があります)。

sec_response パケットと同様に sec_t_response パケットも、in.routed が Trusted Solaris ルーターから応答パケットを送信するときに必ず送信されます。sec_t_response パケットは、直接宛先ネットワークに送信される必要があります。これは、宛先ネットワークとの間にある非 Trusted Solaris 2.5.1 または 7 ルーターでは sec_response パケットを転送できないからです。

非 Trusted Solaris クラスタを通る非 Trusted Solaris ルートはすべて、同じ SRI を持っていなければなりません。すなわち、これらのルートは、同じデフォルトラベルと IP ラベルオプション (ある場合) を使用して Trusted Solaris システムで定義される必要があります。

詳細については、in.routed(1M) のマニュアルページを参照してください。また、「トンネリングの設定」 および 第 10 章「トラステッドネットワークデータベース におけるセキュリティ属性の指定とルーティング設定」 「トンネリングを設定するには」を参照してください。

静的ルーティング

静的ルーティングは、同じく静的ルーティングを使用している他の Trusted Solaris ホストとネットワークとの通信にしか使用できません。静的ルーティングを使用するルーターは使用可能であることを公示しないため、動的ルーティングを使用しているシステムに認識されないからです。起動時には、次のファイルのどちらかが route(1M) コマンドによって使用され、カーネルテーブルにルーティングエントリが作成されます。

動的ルーティング

Trusted Solaris 2.5.1 またはそれ以降のバージョンは、Solaris 2.5 またはそれ以降のリリースで使用されている次の 2 つの動的ルーティングプロトコルを使用します。

なお、RIP プロトコルは拡張されています。

in.rdisc

ホストに /usr/sbin/in.rdisc プログラムはあっても、/etc/defaultrouter と /etc/tsolgateways ファイルが存在しない場合は、ICMP Router Discovery (RDISC) が動的ルーティングに使用されます。また、このプロトコルは、デフォルトゲートウェイをルーティングテーブルにインストールします。

デフォルトでは、in.rdisc がホストで実行されるようになっています。ホストで in.routed を実行するには、/usr/sbin/in.rdisc を削除するか、リネームする必要があります。in.rdisc によって設定されたデフォルトゲートウェイには、対応する拡張メトリックはありません。

in.routed

/usr/sbin/in.rdisc が存在しない場合、ホストは in.routed を実行します。『TCP/IP とデータ通信』に書かれているように、ルーターとして構成されたマシンは、自動的に Routing Information Protocol (RIP) バージョン 1 と RDISC プロトコルを実行します。in.routed は、完全なルーティングテーブルをインストールします。

動的ルーティングまたは静的ルーティングの決定

次の図に、ゲートウェイ以外の Trusted Solaris ホスト上に特定のファイルおよびプログラムが存在するかどうかによって、静的ルーティングまたは動的ルーティングのどちらを行うかを決定する方法を示します。

図 9-8 ホストが使用するルーティングの種類の確定方法

Graphic