test

Solaris のシステム管理 (IP サービス)

パート IV IP セキュリティー

このパートでは、ネットワークセキュリティーについて説明します。IP セキュリティーアーキテクチャー (IPsec) は、ネットワークをパケットレベルで保護します。インターネット鍵管理 (IKE) は、IPsec のキーを管理します。Oracle Solaris IP フィルタはファイアウォールを提供します。

第 19 章 IP セキュリティーアーキテクチャー (概要)

IP セキュリティーアーキテクチャー (IPsec) は、IPv4 および IPv6 ネットワークパケットで IP データグラムを暗号化して保護します。

この章では、次の内容について説明します。

IPsec をネットワークに実装する方法については、第 20 章IPsec の構成 (手順)を参照してください。参考情報については、第 21 章IP セキュリティーアーキテクチャー (リファレンス)を参照してください。

IPsec の新機能

Solaris 10 4/09: このリリース以降、サービス管理機能 (SMF) は IPsec を一連のサービスとして管理します。

デフォルトでは、システムの起動時に次の 2 つの IPsec サービスが有効になります。

デフォルトでは、システムの起動時に鍵管理サービスは無効になっています。

SMF の下で IPsec ポリシーを有効にするには、次の手順を実行します。

  1. ipsecinit.conf ファイルに IPsec ポリシーエントリを追加します。

  2. Internet Key Exchange (IKE) を構成するか、鍵を手動で構成します。

  3. IPsec ポリシーサービスを更新します。

  4. 鍵管理サービスを有効にします。

SMF の詳細については、『Solaris のシステム管理 (基本編)』の第 18 章「サービスの管理 (概要)」を参照してください。smf(5) および svcadm(1M) のマニュアルページも参照してください。

このリリース以降では、ipsecconf コマンドと ipseckey コマンドに -c オプションが追加されており、それぞれの構成ファイルの構文をチェックできます。また、IPsec と IKE を管理するための Network IPsec Management 権利プロファイルが用意されています。

Solaris 10 7/07: このリリース以降、IPsec はトンネルモードのトンネルを完全に実装し、トンネルをサポートするユーティリティーは変更されます。

Solaris 10 1/06: このリリース以降では、IKE は完全に NAT-Traversal サポート (RFC 3947 とRFC 3948 を参照) に準拠します。IKE 操作は暗号化フレームワークから PKCS #11 ライブラリを使用し、パフォーマンスを向上させます。

この暗号化フレームワークは、メタスロットを使用するアプリケーションにソフトトークンキーストアを提供します。IKE がメタスロットを使用するとき、キーを格納する場所として、ディスク、接続したボード、またはソフトトークンキーストアを選択できます。

IPsec とは

IPsec は、パケットの認証または暗号化、もしくはこの両方を実行することで、IP パケットを保護します。IPsec は、アプリケーション層よりかなり下の IP モジュール内で実行されます。したがって、インターネットアプリケーションは、IPsec を使用するために自分自身を設定することなく、IPsec を利用できます。正しく使用すれば、IPsec は、ネットワークトラフィックの保護に有効なツールとなります。

IPsec による保護では、次の 5 つのコンポーネントが主に使用されます。

IPsec は、セキュリティー機構を IP 宛先アドレスに転送される IP データグラムに適用します。受信側ユーザーは、SADB の情報を使用して、到着パケットが正当なことを確認し、それらを復号化します。アプリケーションで IPsec を呼び出すと、ソケット単位レベルでも IP データグラムにセキュリティー機構が適用されます。

ソケットの動きはポートとは異なりますので注意してください。

IPsec RFC

インターネットエンジニアリングタスクフォース (IETF) は、IP 層のセキュリティーアーキテクチャーを説明するいくつかの RFC (Requests for Comments) を公表しています。すべての RFC の著作権は、インターネット協会が有しています。RFC へのリンクについては、http://www.ietf.org/を参照してください。次の RFC リストは、比較的一般的な IP セキュリティーの参考文献です。

IPsec の用語

IPsec RFC は、IPsec をシステムに実装する際に分かっていると便利な用語を多数定義しています。次の例は、IPsec の用語、それらの一般的に使用されている用語を示し、各用語を定義しています。キーのネゴシエーションで使用する用語の一覧は、表 22–1 を参照してください。

表 19–1 IPsec の用語、略語、および使用方法

IPsec の用語 

略語 

定義 

セキュリティーアソシエーション 

SA 

ネットワーク上の 2 つのノード間の一意の接続。接続は、 セキュリティープロトコル、セキュリティーパラメータインデックス、および IP 宛先の 3 つで定義されます。IP 宛先は、IP アドレスまたはソケットのどちらでもかまいません。 

セキュリティーアソシエーションデータベース 

SADB 

アクティブなセキュリティーアソシエーションをすべて含むデータベース。 

セキュリティーパラメータインデックス 

SPI 

セキュリティーアソシエーションの索引値。SPI は、同じ IP 宛先およびセキュリティープロトコルを持つ SA を区別する 32 ビットの値です。 

セキュリティーポリシーデータベース

SPD 

出力パケットと入力パケットの保護レベルが指定どおりかを判断するデータベース。 

キー交換 

 

非対称暗号化アルゴリズムのキーを生成する処理。主な手法には RSA プロトコルと Diffie-Hellman プロトコルがあります。 

Diffie-Hellman プロトコル 

DH 

キー生成とキー認証に関るキー交換プロトコル。しばしば「認証されたキー交換」と呼ばれます。

RSA プロトコル 

RSA 

キーの生成とキーの配布に関係するキー交換プロトコル。このプロトコル名は、作成者の Rivest、Shamir、Adleman の三氏に因んでいます。 

インターネットセキュリティーアソシエーションおよび鍵管理プロトコル 

ISAKMP 

SA 属性の形式を設定し、SA のネゴシエーション、変更、削除を行うための共通フレームワーク。ISAKMP は、IPsec SA 処理の IETF 標準です。 

IPsec パケットのフロー

図 19–1 は、IPsec が出力パケットで呼び出されたときに、IP アドレスを持つパケットが IP データグラムの一部としてどのように処理されるかを示しています。フロー図は、認証ヘッダー (AH) とカプセル化されたセキュリティーペイロード (ESP) エンティティーがどこでパケットに適用されるかを示しています。これらのエンティティーの適用方法とアルゴリズムの選択方法については、これ以降の節で説明します。

図 19–2 は、IPsec 入力プロセスを示しています。

図 19–1 出力パケットプロセスに適用された IPsec

フロー図は、出力パケットがまず ESP によって、次に AH によって保護されていることを示しています。次にパケットは、トンネルまたは物理インタフェースに送られます。

図 19–2 IPsec を入力パケットプロセスに適用

フロー図は、IPsec がまず AH ヘッダーを処理して、次に入力パケットの ESP ヘッダーを処理することを示しています。十分に保護されていないパケットは、振り落とされます。

IPsec セキュリティーアソシエーション

IPsec の セキュリティーアソシエーション (SA) は、通信するホストが認識するセキュリティープロパティーを示します。1 つの SA は、1 方向のデータを保護します。つまり、1 つのホストかグループ (マルチキャスト) アドレスのどちらかです。大部分の通信がピアツーピアかクライアントサーバーなので、両方向のトラフィックの安全性を確保するために 2 つの SA が必要です。

次の 3 つの要素は、IPsec SA を一意に識別します。

任意の 32 ビット値の SPI は、AH パケットまたは ESP パケットで転送されます。AH および ESP によって保護される範囲については、 ipsecah(7P) と ipsecesp(7P) のマニュアルページを参照してください。完全性チェックサム値を使用して、パケットを認証します。認証が失敗すると、パケットがドロップされます。

SA は、セキュリティーアソシエーションデータベース (SADB) に格納されます。ソケットベースの管理エンジン PF_KEY インタフェースにより、特権を持つアプリケーションでそのデータベースを管理できます。たとえば、IKE アプリケーションと ipseckeys コマンドは PF_KEY ソケットインタフェースを使用します。

IPsec での鍵管理

セキュリティーアソシエーション (SA) は、認証および暗号化で使用するキー作成素材を必要とします。この「キーを作成する素材」の管理を「鍵管理」と呼びます。IKE (インターネットキー交換) プロトコルにより、鍵管理が自動的に行われます。また、ipseckey コマンドを指定して、鍵管理を手動で行うこともできます。

IPv4 と IPv6 パケットの SA は、どちらの鍵管理方法も使用できます。手動で鍵管理を行う決定的な理由がない限り、自動の鍵管理をお勧めします。たとえば、Solaris システム以外のシステムと相互運用する場合などは、手動の鍵管理が必要な場合もあります。

現在のリリースでは、SMF は次の IPsec 鍵管理サービスを提供します。

Solaris 10 4/09 リリースより前のリリースでは、in.iked コマンドと ipseckey コマンドで鍵情報を管理します。

IPsec の保護機構

IPsec は、データを保護するために次の 2 つのセキュリティープロトコルを提供しています。

AH は、認証アルゴリズムでデータを保護します。ESP は、暗号化アルゴリズムでデータを保護します。オプションとして、ESP は、認証アルゴリズムでデータを保護します。アルゴリズムの各実装は、「機構」と呼ばれます。

認証ヘッダー

認証ヘッダーは、IP データグラムに対するデータ認証、強力な完全性、再送保護を供給します。AH では大部分の IP データグラムを保護します。次の図に示されているように、AH は IP ヘッダーとトランスポートヘッダーの間に挿入されます。

この図では、IP ヘッダーと TCP ヘッダーの間に AH ヘッダーがあります。

トランスポートヘッダーは、TCP、UDP、SCTP、または ICMP のいずれかです。トンネルを使用している場合は、トランスポートヘッダーがこれ以外の IP ヘッダーである場合もあります。

カプセル化セキュリティーペイロード

カプセル化セキュリティーペイロード (ESP)モジュールは、ESP がカプセル化した対象の機密性を守ります。また、AH が提供するサービスも提供します。ただし、保護される対象は、データグラムのうち ESP がカプセル化した部分だけです。ESP は、保護されたパケットの完全性を保証するオプションの認証サービスを提供します。ESP は暗号化対応技術を使用するため、ESP を提供するシステムは輸出入管理法の対象となります。

ESP はデータをカプセル化します。したがって、次の図に示されているように、ESP が保護するのはデータグラム内の EPS の開始点以降のデータのみです。

この図では、IP ヘッダーと TCP ヘッダーの間に ESP ヘッダーがあります。TCP ヘッダーは、ESP ヘッダーによって暗号化されます。

TCP パケットでは、ESP は TCP ヘッダーとそのデータだけをカプセル化します。パケットが IP 内 IP データグラムの場合、ESP は内部 IP データグラムを保護します。ソケット別ポリシーでは、「自己カプセル化」ができるため、必要に応じて ESP では IP オプションをカプセル化できます。

自己カプセル化が設定されている場合は、IP 内 IP データグラムを構築するために IP ヘッダーのコピーが作成されます。たとえば、TCP ソケットに自己カプセル化が設定されていない場合、データグラムは次の形式で送信されます。


[ IP(a -> b) options + TCP + data ]

TCP ソケットに自己カプセル化が設定されている場合、データグラムは次の形式で送信されます。


[ IP(a -> b) + ESP [ IP(a -> b) options + TCP + data ] ]

さらに詳しくは、「IPsec のトランスポートモードとトンネルモード」を参照してください。

AH と ESP を使用する場合のセキュリティー上の考慮事項

次の表では、AH と ESP が提供する保護を比較しています。

表 19–2 IPsec で AH と ESP が提供する保護

プロトコル 

パケットの範囲 

保護 

対象となる攻撃 

AH 

IP ヘッダーからトランスポートヘッダーまでのパケットを保護 

強力な完全性およびデータ認証を提供します。 

  • 送信側が送ったものとまったく同じものを受信側が受け取ることを保証する

  • AH がリプレー保護を有効にしていない場合は、リプレー攻撃を受けやすい

リプレー、カットアンドペースト 

ESP 

データグラムの ESP 開始後のパケットを保護 

暗号化オプションで、IP データグラムを暗号化します。機密性を確保します 

盗聴 

認証オプションで AH と同じ保護を提供します 

リプレー、カットアンドペースト 

両方のオプションで、強力な完全性、データ認証、および機密性を提供します 

リプレー、カットアンドペースト、盗聴 

IPsec の認証アルゴリズムと暗号化アルゴリズム

IPsec セキュリティープロトコルは、認証と暗号化という 2 種類のアルゴリズムを提供しています。AH モジュールは、認証アルゴリズムを使用します。ESP モジュールは、暗号化アルゴリズムと認証アルゴリズムを使用します。ipsecalgs コマンドを使用すると、システムのアルゴリズムとプロパティーの一覧を取得できます。詳細は、ipsecalgs(1M) のマニュアルページを参照してください。getipsecalgbyname(3NSL) のマニュアルページで説明されている機能を使用して、アルゴリズムのプロパティーを検索することもできます。

Solaris システムの IPsec は、Solaris 暗号フレームワークを使用して、アルゴリズムにアクセスします。このフレームワークは、その他のサービスに加えて、アルゴリズムの中央リポジトリを提供します。このフレームワークによって、IPsec は、高性能な暗号ハードウェアアクセラレータを利用できます。このフレームワークは、リソース制御機能も提供しています。たとえば、このフレームワークを使用すると、カーネルでの暗号処理に費やされる CPU 時間を制限できます。

詳細については、次を参照してください。

IPsec での認証アルゴリズム

認証アルゴリズムは、データとキーを基に整合性チェックサムの値、つまり、「ダイジェスト」を生成します。AH モジュールは、認証アルゴリズムを使用します。ESP モジュールも、認証アルゴリズムを使用します。

IPsec での暗号化アルゴリズム

暗号化アルゴリズムは、キーでデータを暗号化します。 IPsec の ESP モジュールは、暗号化アルゴリズムを使用します。暗号化アルゴリズムでは、「ブロックサイズ」ごとにデータを処理します。

デフォルトで使用される暗号化アルゴリズムは、Solaris 10 OS のリリースによって異なります。

注意 – 注意 –

Solaris 10 7/07 リリース以降では、システムに Solaris Encryption Kit を追加しないでください。このキットはシステムにおける暗号化のパッチレベルを低下させます。このキットはシステム上の暗号化と互換性がありません。

IPsec の保護ポリシー

IPsec の保護ポリシーは、どのセキュリティー機構も使用できます。IPsec ポリシーは、次のレベルで適用できます。

IPsec は、システム共通ポリシーを出力データグラムと入力データグラムに適用します。出力データグラムは、保護付きまたは保護なしで送信されます。保護が適用されると、特定アルゴリズムか汎用アルゴリズムのどちらかになります。システムで認識されるデータがあるため、出力データグラムにはその他の規則も適用できます。入力データグラムの処理は、受理されるか拒絶されるかのどちらかです。入力データグラムの受理か拒絶を決定する基準はいくつかありますが、場合によってはその基準が重複したり競合することがあります。競合の解決に当たっては、どの規則の構文解析を最初に行うかが決定されます。ポリシーのエントリによって、そのトラフィックがすべてのほかのポリシーを省略すると指示されている場合を除いて、トラフィックは自動的に受理されます。

データグラムを保護する通常のポリシーを省略することもできます。それには、システム規模ポリシーに例外を指定するか、ソケット単位ポリシーで省略を要求します。システム内トラフィックの場合、ポリシーは実施されますが、実際のセキュリティー機構は適用されません。その代わりに、イントラシステム内パケットの出力ポリシーが、セキュリティー機能の適用された入力パケットになります。

ipsecinit.conf ファイルと ipsecconf コマンドを使用して、IPsec ポリシーを設定します。詳細と例については、ipsecconf(1M) のマニュアルページを参照してください。

IPsec のトランスポートモードとトンネルモード

IPsec 規格では、IPsec の動作モードとして「トランスポートモード」と「トンネルモード」という 2 つの異なるモードが定義されています。これらのモードは、パケットの符号化には影響を与えません。各モードで、パケットは AH または ESP、あるいはその両方によって保護されます。内側のパケットが IP パケットである場合に、モードによってポリシーの適用方法が次のように異なります。

トランスポートモードでは、外側のヘッダー、次のヘッダー、および次のヘッダーでサポートされるすべてのポートを使用して、IPsec ポリシーを決定できます。実際、IPsec は 2 つの IP アドレスの間で異なるトランスポートモードポリシーを適用でき、ポート単位まで細かく設定できます。たとえば、次のヘッダーが TCP であれば、ポートをサポートするので、外側の IP アドレスの TCP ポートに対して IPsec ポリシーを設定できます。同様に、次のヘッダーが IP ヘッダーであれば、外側のヘッダーと内側の IP ヘッダーを使用して IPsec ポリシーを決定できます。

トンネルモードは IP 内 IP データグラムに対してのみ機能します。トンネルモードのトンネリングは、自宅のコンピュータから中央コンピュータに接続する場合に役立ちます。トンネルモードでは、IPsec ポリシーは内側の IP データグラムの内容に適用されます。内側の IP アドレスごとに異なる IPsec ポリシーを適用できます。つまり、内側の IP ヘッダー、その次のヘッダー、および次のヘッダーでサポートされるポートを使用して、ポリシーを適用することができます。トランスポートモードとは異なり、トンネルモードでは、外側の IP ヘッダーによって内側の IP データグラムのポリシーが決まることはありません。

したがって、トンネルモードでは、ルーターの背後にある LAN のサブネットや、そのようなサブネットのポートに対して、IPsec ポリシーを指定することができます。これらのサブネット上の特定の IP アドレス (つまり、ホスト) に対しても、IPsec ポリシーを指定することができます。これらのホストのポートに対しても、固有の IPsec ポリシーを適用できます。ただし、トンネルを経由して動的経路制御プロトコルが実行されている場合は、サブネットやアドレスは選択しないでください。ピアネットワークでのネットワークトポロジのビューが変化する可能性があるためです。そのような変化があると、静的な IPsec ポリシーが無効になります。静的ルートの構成を含むトンネリング手順の例については、「IPsec による VPN の保護」を参照してください。

Solaris OS では、IP トンネルネットワークインタフェース上でのみトンネルモードを実施できます。ipsecconf コマンドには、IP トンネルネットワークインタフェースを選択するための tunnel キーワードがあります。規則内に tunnel キーワードが含まれている場合は、その規則に指定されているすべてのセレクタが内側のパケットに適用されます。

トランスポートモードでは、ESP または AH、あるいはその両方を使用してデータグラムを保護できます。

次の図は、IP ヘッダーと保護されていない TCP パケットを示します。

図 19–3 TCP 情報を伝送する保護されていない IP パケット

図は、IP ヘッダーのあとに TCP ヘッダーが続くことを示しています。TCP ヘッダーは、保護されていません。

トランスポートモードで、ESP は次の図のようにデータを保護します。網かけされた領域は、パケットの暗号化された部分を示します。

図 19–4 TCP 情報を伝送する保護された IP パケット

この図では、IP ヘッダーと TCP ヘッダーの間に ESP ヘッダーがあります。TCP ヘッダーは、ESP ヘッダーによって暗号化されます。

トランスポートモードで、AH は次の図のようにデータを保護します。

図 19–5 認証ヘッダーで保護されたパケット

この図では、IP ヘッダーと TCP ヘッダーの間に AH ヘッダーがあります。

AH はデータがデータグラムに出現する前に、実際データを保護します。その結果、 AH による保護は、トランスポートモードでも、IP ヘッダーの一部をカバーします。

トンネルモードでは、データグラム全体が IPsec ヘッダーの保護下にあります。図 19–3 のデータグラムは、トンネルモードでは外側の IPsec ヘッダー (この例では ESP) によって保護され、次の図のようになります。

図 19–6 トンネルモードで保護された IPsec パケット

図は、ESP ヘッダーが、IP ヘッダーのあと、IP ヘッダーと TCP ヘッダーの前にあることを示しています。最後の 2 つのヘッダーは、暗号化によって保護されています。

ipsecconf コマンドには、トンネルをトンネルモードまたはトランスポートモードで設定するためのキーワードが用意されています。

仮想プライベートネットワークと IPsec

設定したトンネルは、ポイントツーポイントインタフェースです。トンネルによって、IP パケットを別の IP パケット内にカプセル化できます。トンネルの設定には、トンネルソースとトンネル宛先が必要です。詳細は、tun(7M) のマニュアルページと、IPv6 サポート用のトンネルの構成を参照してください。

トンネルは、IP への物理インタフェースのようなものを作成します。この物理的リンクの完全性は、基本になるセキュリティープロトコルによって異なります。セキュリティーアソシエーション (SA) を確実に行えば、信頼性の高いトンネルになります。トンネルのデータパケットのソースはトンネル宛先で指定したピアでなければなりません。この信頼関係があるかぎり、インタフェース別 IP 送信を利用して仮想プライベートネットワーク (VPN)を作成できます。

IPsec を使用して、VPN を構築できます。IPsec が接続の安全性を確保します。たとえば、それぞれのネットワークとともに独立したオフィスを持つ組織があって、オフィス間が VPN テクノロジで接続されている場合、IPsec を利用すれば、2 つのオフィス間でトラフィックを安全にやりとりできます。

次の図は、ネットワークシステムに配置した IPsec で、2 つのオフィスがインターネットを利用して VPN を形成する方法を示します。

図 19–7 仮想プライベートネットワーク

図は、オフィス 1 と 2 が hme0 インタフェースを使用して、互いに通信を行っていることを示しています。各オフィスは、内部の通信に hme1 を使用しています。

設定手順の詳細な例については、「IPv4 トンネルモードの IPsec トンネルで VPN を保護する方法」を参照してください。

IPv6 アドレスを使用する同様の例については、「IPv6 トンネルモードの IPsec トンネルで VPN を保護する方法」を参照してください。

IPsec と NAT 越え

IKE は、NAT ボックスを通して IPsec SA とネゴシエートできます。この機能により、システムは、システムが NAT デバイスの背後にある場合も、リモートネットワークから安全に接続を行うことができます。たとえば、自宅で働く社員や会議場からログオンする社員も IPsec で自分のトラフィックを保護できます。

NAT は、Network Address Translation (ネットワークアドレス変換) の略語です。NAT ボックスは、プライベートな内部アドレスを一意のインターネットアドレスに変換します。NAT は、ホテルなどのインターネットへの公共のアクセスポイントでは非常によく使用されています。詳細は、「Oracle Solaris IP フィルタの NAT 機能の使用」を参照してください。

NAT ボックスが通信システム間にある場合に IKE を使用する機能は、NAT traversal、または NAT-T と呼ばれます。Solaris 10 リリースでは、NAT-T には次の制限があります。

次の RFC は、NAT 機能と NAT-T の制限事項について説明しています。RFC のコピーは、http://www.rfc-editor.org から入手できます。

NAT を通して IPsec を使用するには、「移動体システム用の IKE の設定 (作業マップ)」を参照してください。

IPsec と SCTP

Solaris OS は、SCTP (Streams Control Transmission Protocol) をサポートしています。STCP プロトコルと SCTP ポート番号を使用して IPsec ポリシーを指定することもできますが、頑丈ではありません。RFC 3554 に指定されている SCTP の IPsec 拡張は、まだ実装されていません。これらの制限事項によって SCTP 向けの IPsec ポリシーの作成が複雑になる場合もあります。

SCTP は、単独の SCTP アソシエーションのコンテキストで、複数の発信元アドレスと宛先アドレスを利用できます。1 つの発信元アドレスまたは 1 つの宛先アドレスに IPsec ポリシーを適用すると、SCTP がそのアソシエーションの発信元アドレスまたは宛先アドレスを切り替えたときに、通信が失敗する恐れがあります。IPsec ポリシーは、元のアドレスしか認識しません。SCTP については、RFC および「SCTP プロトコル」をお読みください。

IPsec と Solaris のゾーン

共有 IP ゾーンについては、IPsec の構成は大域ゾーンから行います。IPsec ポリシー構成ファイル ipsecinit.conf は、大域ゾーンだけに存在します。このファイルには、大域ゾーンに適用するエントリだけでなく、非大域ゾーンに適用するエントリも含めることができます。

排他的 IP ゾーンについては、IPsec の構成は非大域ゾーンで行います。

IPsec をゾーンで使用する方法については、「IPsec によるトラフィックの保護」を参照してください。ゾーンについては、『Oracle Solaris のシステム管理 (Oracle Solaris コンテナ : 資源管理と Oracle Solaris ゾーン)』の第 16 章「Solaris ゾーンの紹介」を参照してください。

IPsec と論理ドメイン

IPsec は論理ドメインで動作します。論理ドメインは、IPsec を含む Solaris OS バージョン (Solaris 10 リリースなど) を実行している必要があります。

論理ドメインを作成するには、Oracle VM Server for SPARC (以前の名称は Logical Domains) を使用する必要があります。論理ドメインを構成する方法については、『Logical Domains 1.2 管理ガイド』または『Oracle VM Server for SPARC 2.0 Administration Guide』を参照してください。

IPsec ユーティリティーおよび IPsec ファイル

表 19–3 は、IPsec を構成および管理するために使用するファイル、コマンド、およびサービス識別子について説明しています。完全性を期すために、鍵管理ファイルとコマンドも含めました。

Solaris 10 4/09 リリース以降では、IPsec は SMF によって管理されます。For more information about service identifiers, see 『Solaris のシステム管理 (基本編)』の第 18 章「サービスの管理 (概要)」.

表 19–3 選択される IPsec ユーティリティーとファイルのリスト

IPsec ユーティリティー、ファイル、またはサービス 

説明 

マニュアルページ 

svc:/network/ipsec/ipsecalgs

現在のリリースでは、IPsec アルゴリズムを管理する SMF サービス。 

smf(5)、ipsecalgs(1M)

svc:/network/ipsec/manual-key

現在のリリースでは、手動でのセキュリティーアソシエーション (SA) を管理する SMF サービス。 

smf(5)、ipseckey(1M)

svc:/network/ipsec/policy

現在のリリースでは、IPsec ポリシーを管理する SMF。

smf(5)、ipsecconf(1M)

svc:/network/ipsec/ike

現在のリリースでは、IPsec SA の自動管理のための SMF サービス。 

smf(5)、in.iked(1M)

/etc/inet/ipsecinit.conf ファイル

IPsec ポリシーファイル。Solaris 10 4/09 リリースより前のリリースでは、このファイルが存在する場合、IPsec は起動時にアクティブになります。

現在のリリースでは、SMF policy サービスはシステムの起動時にこのファイルを使用して IPsec ポリシーを構成します。

ipsecconf(1M)

ipsecconf コマンド

IPsec ポリシーコマンド。現在の IPsec ポリシーの表示および変更や、テストを行うときに役立ちます。Solaris 10 4/09 リリースより前のリリースでは、ブートスクリプトは ipsecconf を使用して /etc/inet/ipsecinit.conf ファイルを読み込み、IPsec を有効にします。

現在のリリースでは、ipsecconf は、システムの起動時に IPsec ポリシーを構成するために SMF policy サービスで使用されます。

ipsecconf(1M)

PF_KEY ソケットインタフェース

SA データベース (SADB) のインタフェース。手動と自動の鍵管理を処理します。

pf_key(7P)

ipseckey コマンド

IPsec SA キー作成コマンド。ipseckey は、PF_KEY インタフェースに対するコマンド行フロントエンドです。ipseckey は、SA を作成、破棄、または修正できます。

ipseckey(1M)

/etc/inet/secret/ipseckeys ファイル

IPsec SA のキー。Solaris 10 4/09 リリースより前のリリースでは、ipsecinit.conf ファイルが存在する場合、起動時に ipseckeys ファイルが自動的に読み込まれます。

現在のリリースでは、ipseckeys は、システムの起動時に SA を手動で構成するために SMF manual-key サービスで使用されます。

 

ipsecalgs コマンド

IPsec アルゴリズムコマンド。IPsec アルゴリズムとそのプロパティーの一覧を参照および変更するときに役立ちます。

現在のリリースでは、システムの起動時に既知の IPsec アルゴリズムをカーネルと同期するために SMF ipsecalgs サービスで使用されます。

ipsecalgs(1M)

/etc/inet/ipsecalgs ファイル

構成されている IPsecプロトコルとアルゴリズム定義を含みます。このファイルは、ipsecalgs コマンドによって管理されます。手動では絶対に編集しないでください。

 

/etc/inet/ike/config ファイル

IKE の構成とポリシーファイル。デフォルトでは、このファイルはありません。Solaris 10 4/09 リリースより前のリリースでは、このファイルが存在する場合、IKE デーモン in.iked は自動鍵管理を提供します。/etc/inet/ike/config ファイル内の規則およびグローバルパラメータに基づいて管理が行われます。「IKE ユーティリティーおよび IKE ファイル」を参照してください。

現在のリリースでは、このファイルが存在する場合、svc:/network/ipsec/ike サービスは IKE デーモン in.iked を起動して自動鍵管理を提供します。

ike.config(4)

Solaris 10 リリースでの IPsec の変更点

Solaris の新機能の完全な一覧や各 Solaris リリースの説明については、『Oracle Solaris 10 9/10 の新機能』を参照してください。Solaris 9 リリースから、IPsec には次の機能が追加されました。

第 20 章 IPsec の構成 (手順)

この章では、ネットワークに IPsec を実装する手順について説明します。この手順は、次の作業マップで説明されています。

IPsec の概要については、第 19 章IP セキュリティーアーキテクチャー (概要)を参照してください。IPsec の参考情報については、第 21 章IP セキュリティーアーキテクチャー (リファレンス)を参照してください。

IPsec によるトラフィックの保護 (作業マップ)

次の作業マップに、1 台以上のシステム間で IPsec を設定する手順を示します。ipsecconf(1M)、ipseckey(1M)、および ifconfig(1m) のマニュアルページも、それぞれの「例」で役立つ手順を説明しています。

作業 

説明 

説明 

システム間のトラフィックを保護します。 

あるシステムから別のシステムへのパケットを保護します。 

「IPsec で 2 つのシステム間のトラフィックを保護するには」

IPsec ポリシーによる Web サーバーを保護します。 

Web 以外のトラフィックに IPsec の使用を求めます。Web クライアントは、IPsec チェックをバイパスする特定のポートによって識別されます。 

「IPsec を使って Web 以外のトラフィックから Web サーバーを保護する方法」

IPsec ポリシーの表示 

現在実施されている IPsec ポリシーを、ポリシーの実行順序に従って表示します。 

「IPsec ポリシーを表示するには」

乱数を生成します。 

手動で作成するセキュリティーアソシエーションのためにキー作成素材用の乱数を生成します。 

「Solaris System で乱数を生成するには」

『Solaris のシステム管理 (セキュリティサービス)』の「pktool コマンドを使用して対称鍵を生成する方法」

手動によるセキュリティーアソシエーションの作成または置き換えを行います。 

次のようなセキュリティーアソシエーション向けのローデータを提供します。 

  • IPsec アルゴリズム名とキー作成素材

  • セキュリティーパラメータインデックスのキー

  • IP 発信元アドレスおよび着信先アドレス

「IPsec セキュリティーアソシエーションを手動で作成する方法」

IPsec がパケットを保護しているかどうかを検査します。 

snoop の出力を調べ、IP データグラムがどのように保護されているかを示すヘッダーをチェックします。

「IPsec によってパケットが保護されていることを確認する方法」

(任意) ネットワークセキュリティーの役割を作成します。 

セキュリティーネットワークを設定できるが、スーパーユーザーより権限が少ない役割を作成します。 

「ネットワークセキュリティーの役割を設定する方法」

IPsec と鍵情報を一連の SMF サービスとして管理します。 

サービスの有効化、無効化、更新、および再起動を行うコマンドを、いつどのように使用するかについて説明します。サービスのプロパティー値を変更するコマンドについても説明します。 

「IKE および IPsec サービスを管理する方法」

セキュリティー保護された仮想プライベートネットワーク (VPN) を設定します。 

インターネットによって切り離されている 2 つのシステム間で IPsec を設定します。 

「IPsec による VPN の保護 (作業マップ) 」

IPsec によるトラフィックの保護

この節では、2 つのシステム間のトラフィックを保護する手順と、Web サーバーを保護する手順について説明します。VPN を保護する手順については、「IPsec による VPN の保護 (作業マップ) 」を参照してください。追加手順では、鍵情報とセキュリティーアソシエーションの提供、IPsec が設定どおり動作しているかどうかの確認を行います。

次の情報は、すべての IPsec 構成作業で使用されます。

ProcedureIPsec で 2 つのシステム間のトラフィックを保護するには

この手順では、次の設定がすでになされているものとします。

始める前に

システムまたは共有 IP ゾーンの IPsec ポリシーの構成は、大域ゾーンで行う必要があります。排他的 IP ゾーンについては、非大域ゾーンで IPsec ポリシーを構成します。

  1. システムコンソール上で、Primary Administrator の役割を引き受けるか、スーパーユーザーになります。

    Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

    注 –

    リモートログインすると、セキュリティー上重要なトラフィックが盗聴される可能性があります。何らかの方法でリモートログインを保護していても、システムのセキュリティーがリモートログインセッションレベルに低下します。セキュリティー保護されたリモートログインには、ssh コマンドを使用してください。例については、例 20–1 を参照してください。

  2. 各システムでホストエントリを確認します。

    現在のリリースでは、/etc/inet/hosts ファイルにホストエントリを追加します。

    Solaris 10 7/07 リリースより前のリリースを実行しているシステムでは、/etc/inet/ipnodes ファイルに IPv4 と IPv6 のエントリを追加します。次のように、1 つのシステムのエントリは連続してそのファイルに入力します。システムの構成ファイルについては、「TCP/IP 構成ファイル」および第 11 章IPv6 の詳細 (リファレンス)を参照してください。

    IPv4 アドレスだけを持つシステムどうしを接続する場合は、/etc/inet/hosts ファイルに変更を加えます。この例で接続するシステムはどちらも、以前の Solaris リリースを実行しており、IPv6 アドレスを使用しています。

    1. enigma という名前のシステムでは、hosts または ipnodes ファイルに次のように入力します。


      # Secure communication with partym
192.168.13.213 partym
2001::eeee:3333:3333 partym

    2. partym という名前のシステムでは、hosts または ipnodes ファイルに次のように入力します。


      # Secure communication with enigma
192.168.116.16 enigma
2001::aaaa:6666:6666 enigma

    記号名にネームサービスを使用するのは安全ではありません。

  3. 各システムで IPsec ポリシーファイルを作成します。

    ファイル名は /etc/inet/ipsecinit.conf です。例は、/etc/inet/ipsecinit.sample ファイルを参照してください。

  4. IPsec ポリシーエントリを ipsecinit.conf ファイルに追加します。

    1. enigma システムで、次のポリシーを追加します。


      {laddr enigma raddr partym} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

    2. partym システムで、同じポリシーを追加します。


      {laddr partym raddr enigma} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

      IPsec ポリシーエントリの構文については、ipsecconf(1M)のマニュアルページを参照してください。

  5. 各システムで、2 つのシステム間に IPsec SA ペアを追加します。

    インターネットキー交換 (IKE) を設定すると、SA が自動的に生成されます。SA は手動でも追加できます。

    注 –

    キーの生成や保守を手動で行う必要が特にない場合は、IKE を使用すべきです。IKE 鍵管理では、手動での鍵管理よりも強力なセキュリティー効果が得られます。

  6. IPsec ポリシーを有効にします。

  7. IPsec ポリシーファイルの構文を確認します。


    # ipsecconf -c -f /etc/inet/ipsecinit.conf

    エラーがあれば修正し、ファイルの構文を確認してから続行します。

  8. IPsec ポリシーを更新します。


    # svcadm refresh svc:/network/ipsec/policy:default

    IPsec ポリシーはデフォルトで有効になっているので、「更新」を行います。IPsec ポリシーを無効にしてある場合は有効にしてください。


    # svcadm enable svc:/network/ipsec/policy:default

  9. IPsec 用の鍵を有効にします。

    • 手順 5 で IKE を構成した場合は、次のいずれかを実行します。

      • ike サービスが有効になっていない場合は有効にします。


        # svcadm enable svc:/network/ipsec/ike:default

      • ike サービスが有効になっている場合は再起動します。


        # svcadm restart svc:/network/ipsec/ike:default

    • 手順 5 で鍵を手動で構成した場合は、次のいずれかを実行します。

      • manual-key サービスが有効になっていない場合は有効にします。


        # svcadm enable svc:/network/ipsec/manual-key:default

      • manual-key サービスが有効になっている場合は更新します。


        # svcadm refresh svc:/network/ipsec/manual-key:default

  10. パケットが保護されていることを確認します。

    手順については、「IPsec によってパケットが保護されていることを確認する方法」を参照してください。

例 20–1 ssh 接続を使用している場合に IPsec ポリシーを追加する

この例では、管理者はスーパーユーザーとして 2 つのシステムの IPsec ポリシーと鍵を構成します。その際、ssh コマンドを使用して 2 番目のシステムにアクセスします。詳細は、ssh(1) のマニュアルページを参照してください。

2 つのシステムが次に通信を行うとき、ssh 接続を使用した通信も含め、通信は IPsec で保護されます。

例 20–2 リブートを行わないで IPsec によるトラフィックの保護

次の例は、Solaris 10 4/09 リリースより前のリリースを実行している場合に役立ちます。つまり、そのようなリリースでは、IPsec はサービスとして管理されません。この例では、テスト環境での IPsec の実装方法を示します。実際の稼働環境では、ipsecconf コマンドを実行するよりもリブートする方が安全です。セキュリティー上の考慮事項については、この例の最後を参照してください。

手順 6 でリブートする代わりに、次のオプションのいずれかを選択します。

セキュリティーについて – ipsecconf コマンドを実行するときには、警告を読んでください。ソケットがすでにラッチされている (使用されている) 場合には、システムへ侵入される恐れがあります。詳細については、「ipsecinit.conf と ipsecconf のセキュリティーについて」を参照してください。

ProcedureIPsec を使って Web 以外のトラフィックから Web サーバーを保護する方法

セキュリティー保護された Web サーバーでは、Web クライアントであれば Web サービスと通信できます。セキュリティー保護された Web サーバーでは、Web トラフィック以外のトラフィックは、セキュリティー検査を通る必要があります。次の手順には、Web トラフィックの検査省略手順が含まれています。さらに、この Web サーバーでは、セキュリティー保護されていない DNS クライアント要求を出すことができます。その他のすべてのトラフィックでは、AES と SHA-1 アルゴリズムによる ESP が必要です。

始める前に

IPsec ポリシーの構成は大域ゾーンで行う必要があります。排他的 IP ゾーンについては、非大域ゾーンで IPsec ポリシーを構成します。「IPsec で 2 つのシステム間のトラフィックを保護するには」を完了して、次の条件が成立しています。

  1. システムコンソール上で、Primary Administrator の役割を引き受けるか、スーパーユーザーになります。

    Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

    注 –

    リモートログインすると、セキュリティー上重要なトラフィックが盗聴される恐れがあります。何らかの方法でリモートログインを保護していても、システムのセキュリティーがリモートログインセッションレベルに低下します。セキュリティー保護されたリモートログインには、ssh コマンドを使用してください。

  2. セキュリティーポリシー検査を省略するサービスを指定します。

    Web サーバーの場合、TCP ポート 80 (HTTP) と 443 (保護 HTTP) が該当します。Web サーバーが DNS 名検査をするときは、TCP と UDP の両方にポート 53 も組み込む必要がある場合もあります。

  3. Web サーバーの IPsec ポリシーを作成し、有効にします。

    • Solaris 10 4/09 リリース以降では、手順 4 から手順 7 までを実行します。

    • Solaris 10 4/09 リリースより前のリリースを実行している場合は、手順 8 から手順 11 までを実行します。

    手順 12 はすべての Solaris リリースで省略可能です。

  4. Web サーバーのポリシーを IPsec ポリシーファイルに追加します。

    /etc/inet/ipsecinit.conf ファイルに次の行を追加します。


    # Web traffic that web server should bypass.
{lport  80 ulp tcp dir both} bypass {}
{lport 443 ulp tcp dir both} bypass {}

# Outbound DNS lookups should also be bypassed.
{rport 53 dir both} bypass {}

# Require all other traffic to use ESP with AES and SHA-1.
# Use a unique SA for outbound traffic from the port
{} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

    これで、保護トラフィックだけがシステムへのアクセスを許可されます。ただし、手順 4 で説明した、検査を省略するトラフィックは例外です。

  5. IPsec ポリシーファイルの構文を確認します。


    # ipsecconf -c -f /etc/inet/ipsecinit.conf

  6. IPsec ポリシーを更新します。


    # svcadm refresh svc:/network/ipsec/policy:default

  7. IPsec 用の鍵を更新します。

    これで設定が完了しました。必要に応じて、手順 12 を実行します。

  8. Web サーバーポリシー用のファイルを /etc/inet ディレクトリに 作成します。

    注 –

    次の手順は、Solaris 10 4/09 リリースより前のリリースを実行している Web サーバーを構成するためのものです。

    このファイルにその目的を表す名前を与えます (たとえば、IPsecWebInitFile)。このファイルに次のように入力します。


    # Web traffic that web server should bypass.
{lport  80 ulp tcp dir both} bypass {}
{lport 443 ulp tcp dir both} bypass {}

# Outbound DNS lookups should also be bypassed.
{rport 53 dir both} bypass {}

# Require all other traffic to use ESP with AES and SHA-1.
# Use a unique SA for outbound traffic from the port
{} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

    これで、保護トラフィックだけがシステムへのアクセスを許可されます。ただし、手順 4 で説明した、検査を省略するトラフィックは例外です。

  9. 手順 8 で作成したファイルの内容を /etc/inet/ipsecinit.conf ファイルにコピーします。

  10. IPsecWebInitFile ファイルを読み取り専用アクセス権で保護します。


    # chmod 400 IPsecWebInitFile

  11. リブートせずに Web サーバーをセキュリティー保護します。

    次のオプションのいずれかを選択します。

    • 鍵管理に IKE を使用する場合は、in.iked デーモンをいったん停止後、再起動します。


      # pkill in.iked
# /usr/lib/inet/in.iked

    • 手動でキーを管理する場合は、ipseckey および ipsecconf コマンドを実行します。

      ipsecconf コマンドの引数には、 IPsecWebInitFile を使用します。引数に ipsecinit.conf ファイルを使用すると、ipsecconf コマンドは、ファイル内のポリシーがすでにシステムに実装されている場合は、エラーを生成します。


      # ipseckey -c -f /etc/inet/secret/ipseckeys 
# ipsecconf -a /etc/inet/IPsecWebInitFile
    注意 – 注意 –

    ipsecconf コマンドの実行時には警告を読んでください。ソケットがすでにラッチされている (使用されている) 場合には、システムへ侵入される恐れがあります。詳細については、「ipsecinit.conf と ipsecconf のセキュリティーについて」を参照してください。in.iked デーモンの再起動時にも、同じ警告が表示されます。

    リブートすることもできます。システムをリブートすると、IPsec ポリシーがすべての TCP 接続に適用されます。リブート時に、IPsec ポリシーのファイルで指定したポリシーが TCP 接続で使用されます。

  12. (省略可能) Web 以外のトラフィックのために Web サーバーと通信する場合は、リモートシステムを有効にします。

    リモートシステムの ipsecinit.conf ファイルに次のポリシーを入力します。


    # Communicate with web server about nonweb stuff
#
{laddr webserver} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

    IPsec ポリシーが一致した場合にかぎり、リモートシステムは、非 Web トラフィックを持つ Web サーバーと安全に通信できます。

ProcedureIPsec ポリシーを表示するには

引数を指定しないで ipsecconf コマンドを実行すると、システムに構成されているポリシーを確認できます。

始める前に

ipsecconf コマンドは大域ゾーンで実行する必要があります。排他的 IP ゾーンについては、非大域ゾーンで ipsecconf コマンドを実行します。

  1. Network IPsec Management プロファイルを持つ役割またはスーパーユーザーになります。

    Solaris 10 4/09 リリースより前のリリースを実行している場合、Network IPsec Management プロファイルは使用できません。Network Security プロファイルを使用してください。

    ネットワークセキュリティープロファイルを含む役割を作成し、その役割をユーザーに割り当てるには、「ネットワークセキュリティーの役割を設定する方法」を参照してください。

  2. IPsec ポリシーの表示

    1. 追加された順序でグローバルな IPsec ポリシーエントリを表示します。


      $ ipsecconf

      各エントリが、「インデックス」とそのあとに番号が付いて表示されます。

    2. 一致した順序で IPsec ポリシーエントリを表示します。


      $ ipsecconf -l

    3. トンネルごとのエントリも含め、IPsec ポリシーエントリを一致した順序で表示します。


      $ ipsecconf -L

ProcedureSolaris System で乱数を生成するには

キーを手動で指定する場合、鍵情報はランダムでなければなりません。Solaris システム用の鍵情報は 16 進形式です。ほかのオペレーティングシステムでは、ASCII 形式の鍵情報が必要になる場合があります。ASCII 形式を必要とするオペレーティングシステムと通信する Solaris システム用に鍵情報を生成する方法については、例 23–1 を参照してください。

乱数発生関数がすでにある場合は、それを使用してください。ない場合は、Solaris の /dev/random デバイスを入力として od コマンドを実行できます。詳細は、od(1) のマニュアルページを参照してください。

Solaris 10 4/09 リリースでは、pktool コマンドも使用できます。このコマンドの構文は、od コマンドの構文より単純です。詳細は、『Solaris のシステム管理 (セキュリティサービス)』の「pktool コマンドを使用して対称鍵を生成する方法」を参照してください。

  1. 16 進数の乱数を生成します。


    % od -x|-X -A n file | head -n
    -x

    8 進数ダンプを 16 進数形式で表示します。16 進数形式は鍵情報を表すのに役立ちます。16 進数を 4 文字単位で表示します。

    -X

    8 進数ダンプを 16 進数形式で表示します。16 進数を 8 文字単位で表示します。

    -A n

    表示から入力オフセットベースを取り除きます。

    file

    乱数のソースとなります。

    head -n

    出力の冒頭の n 行に表示を限定します。

  2. これらの出力を組み合わせて、適切な長さのキーを作成します。

    同じ行にある乱数間のスペースを取り除き、32 文字キーを作成します。32 文字キーの長さは 128 ビットです。セキュリティーパラメータインデックス (SPI) の場合は、8 文字キー 1 個を使用します。そのキーは、0x 接頭辞を使用します。

例 20–3 IPsec のキー素材の生成

次の例は、8 つ 16 進数文字のグループそれぞれに 2 行のキーを表示します。


% od -X -A n /dev/random | head -2
         d54d1536 4a3e0352 0faf93bd 24fd6cad
         8ecc2670 f3447465 20db0b0c c83f5a4b

最初の行で 4 つの数字を組み合わせることで、32 文字のキーを作成できます。0x に続く 8 文字の数字は、0xf3447465 などの適切な SPI 値を提供します。

次の例は、4 つ 16 進数文字のグループそれぞれに 2 行のキーを表示します。


% od -x -A n /dev/random | head -2
         34ce 56b2 8b1b 3677 9231 42e9 80b0 c673
         2f74 2817 8026 df68 12f4 905a db3d ef27

最初の行で 4 つの数字を組み合わせることで、32 文字のキーを作成できます。

ProcedureIPsec セキュリティーアソシエーションを手動で作成する方法

次の手順では、「IPsec で 2 つのシステム間のトラフィックを保護するには」の手順で使用するキー作成素材を提供します。partym と enigma という 2 つのシステムの鍵を生成しようとしています。一方のシステムで鍵を生成してから、このシステムの鍵を両方のシステムで使用します。

始める前に

共有 IP ゾーンのキー情報の手動管理は、大域ゾーンで行う必要があります。

  1. SA の鍵情報を生成します。

    16 進のアウトバウンドトラフィックと、同じく 16 進のインバウンドトラフィックには、それぞれ 3 種類の乱数が必要です。

    つまり、1 台のシステムで次の数値を生成する必要があります。

    • spi キーワードの値として、2 つの 16 進数の乱数。1 つはアウトバウンドトラフィック用です。もう 1 つはインバウンドトラフィック用です。それぞれの乱数の最大桁数は 8 桁です。

    • 認証の SHA1 アルゴリズム用として、2 つの 16 進数の乱数。160 ビットのキーの場合、各乱数は 40 桁でなければなりません。1 つは dst enigma 用です。もう 1 つは dst partym 用です。

    • ESP 暗号化の AES アルゴリズム用として、2 つの 16 進数の乱数。256 ビットのキーの場合、各乱数は 64 桁でなければなりません。1 つは dst enigma 用です。もう 1 つは dst partym 用です。

    乱数発生関数がすでにある場合は、それを使用してください。ない場合は、od コマンドを使用できます。手順については、「Solaris System で乱数を生成するには」を参照してください。

  2. いずれかのシステムのシステムコンソールで、Primary Administrator の役割を引き受けるか、スーパーユーザーになります。

    Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

    注 –

    リモートログインすると、セキュリティー上重要なトラフィックが盗聴される恐れがあります。何らかの方法でリモートログインを保護していても、システムのセキュリティーがリモートログインセッションレベルに低下します。セキュリティー保護されたリモートログインには、ssh コマンドを使用してください。

  3. SA を作成します。

    • Solaris 10 4/09 リリース以降では、手順 8 から手順 10 までを実行します。

    • Solaris 10 4/09 リリースより前のリリースを実行している場合は、手順 4 から手順 9 までを実行します。

  4. 次のコマンドを入力して ipseckey コマンドモードを有効にします。


    # ipseckey

>

    > プロンプトは、ipseckey コマンドモードであることを示します。

  5. 既存の SA を置き換える場合は、現在の SA を消去してください。


    > flush
>

    攻撃者に SA を破る時間を与えないように、キー作成素材は置き換えが必要です。

    注 –

    管理者は、通信システム上のキーの置き換えを調整する必要があります。あるシステムの SA を置き換える場合は、それと通信しているリモートシステムの SA も置き換える必要があります。

  6. SA を作成するには、次のコマンドを実行します。


    > add protocol spi random-hex-string \
src addr dst addr2 \
protocol-prefix_alg protocol-algorithm  \
protocol-prefixkey random-hex-string-of-algorithm-specified-length

    次の構文で、フラッシュした SA を置き換えることもできます。

    protocol

    esp または ah を指定します。

    random-hex-string

    16 進数形式の最大 8 桁の乱数を指定します。0x が前置されます。セキュリティーパラメータインデックス (SPI) が受け取る以上の桁数を入力すると、超過部分は無視されます。SPI が受け取るより少ない桁数を入力すると、パディングが行われます。

    addr

    システムの IP アドレスを指定します。

    addr2

    addr のピアシステムの IP アドレスを指定します。

    protocol-prefix

    encr または auth を指定します。encr 接頭辞は esp プロトコルとともに使用されます。auth 接頭辞は ah プロトコルとともに、そして、esp プロトコルを認証する場合に使用されます。

    protocol-algorithm

    ESP または AH のアルゴリズムを指定します。それぞれのアルゴリズムには、特定の長さのキーが必要です。

    認証アルゴリズムには MD5 と SHA1 があります。Solaris 10 4/09 リリース以降では、SHA256 と SHA512 がサポートされています。暗号化アルゴリズムには、DES、3DES、AES、および Blowfish があります。

    random-hex-string-of-algorithm-specified-length

    アルゴリズムによって必要とされる長さをもつ 16 進数の乱数を指定します。たとえば、MD5 アルゴリズムでは、128 ビットキーのため 32 桁の乱数が必要です。3DES アルゴリズムでは、192 ビットキーのため 48 桁の乱数が必要です。

    1. たとえば、enigma システムで出力パケットを保護します。

      手順 1 で生成した乱数を使用します。

      Solaris 10 1/06 の場合:


      > add esp spi 0x8bcd1407 \
src 192.168.116.16 dst 192.168.13.213 \
encr_alg aes \
auth_alg sha1 \
encrkey c0c65b888c2ee301c84245c3da63127e92b2676105d5330e85327c1442f37d49 \
authkey 6fab07fec4f2895445500ed992ab48835b9286ff
>
      注 –

      ピアシステムでは、同じ鍵情報および同じ SPI を使用する必要があります。

    2. enigma システムの ipseckey コマンドモードでは、入力パケットを保護します。

      パケットを保護するには、次のコマンドを入力します。


      > add esp spi 0x122a43e4 \
src 192.168.13.213 dst 192.168.116.16 \
encr_alg aes \
auth_alg sha1 \
encrkey a2ea934cd62ca7fa14907cb2ad189b68e4d18c976c14f22b30829e4b1ea4d2ae \
authkey c80984bc4733cc0b7c228b9b74b988d2b7467745
>
      注 –

      これらのキーと SPI は、SA ごとに変更できます。SA ごとに異なるキーと異なる SPI を割り当てるべきです。

  7. ipseckey コマンドモードを終了するには、Control-D キーを押すか、quit と入力します。

  8. /etc/inet/secret/ipseckeys ファイルに鍵情報を追加します。

    Solaris 10 4/09 リリースより前のリリースでは、この手順により、リブート時に IPsec で鍵情報を確実に使用できるようになります。

    /etc/inet/secret/ipseckeys ファイルの行と ipseckey コマンド行の言語が同じになるようにします。

    1. たとえば、enigma システム上の /etc/inet/secret/ipseckeys ファイルは次のようになります。


      # ipseckeys - This file takes the file format documented in 
#   ipseckey(1m).
#   Note that naming services might not be available when this file
#   loads, just like ipsecinit.conf.
#
# for outbound packets on enigma
add esp spi 0x8bcd1407 \
   src 192.168.116.16 dst 192.168.13.213  \
   encr_alg aes \
   auth_alg sha1  \
   encrkey  c0c65b888c2ee301c84245c3da63127e92b2676105d5330e85327c1442f37d49 \
   authkey  6fab07fec4f2895445500ed992ab48835b9286ff
#
# for inbound packets
add esp spi 0x122a43e4 \
   src 192.168.13.213 dst 192.168.116.16 \
   encr_alg aes \
   auth_alg sha1  \
   encrkey a2ea934cd62ca7fa14907cb2ad189b68e4d18c976c14f22b30829e4b1ea4d2ae \
   authkey c80984bc4733cc0b7c228b9b74b988d2b7467745

    2. 読み取り専用ファイルを保護します。


      # chmod 400 /etc/inet/secret/ipseckeys

  9. partym システムでこの手順を繰り返します。

    enigma システムの場合と同じ鍵情報を使用します。

    両システムの鍵情報は同じでなければなりません。次の例のように、ipseckeys ファイル内のコメントだけが異なります。コメントが異なるのは、dst enigma が enigma システム上ではインバウンド、partym システム上ではアウトバウンドになるからです。


    # partym ipseckeys file
#
# for inbound packets
add esp spi 0x8bcd1407 \
   src 192.168.116.16 dst 192.168.13.213  \
   encr_alg aes \
   auth_alg sha1  \
   encrkey  c0c65b888c2ee301c84245c3da63127e92b2676105d5330e85327c1442f37d49 \
   authkey  6fab07fec4f2895445500ed992ab48835b9286ff
#
# for outbound packets
add esp spi 0x122a43e4 \
   src 192.168.13.213 dst 192.168.116.16 \
   encr_alg aes \
   auth_alg sha1  \
   encrkey a2ea934cd62ca7fa14907cb2ad189b68e4d18c976c14f22b30829e4b1ea4d2ae \
   authkey c80984bc4733cc0b7c228b9b74b988d2b7467745

  10. manual-key サービスを有効にします。


    # svcadm enable svc:/network/ipsec/manual-key

    現在のリリースで鍵を置き換える方法については、例 20–4 を参照してください。

例 20–4 IPsec SA を置き換える

この例では、管理者が現在の Solaris 10 リリースを実行しているシステムを構成しようとしています。管理者は新しい鍵を生成し、ipseckeys ファイルの鍵情報を変更してから、サービスを再起動します。

ProcedureIPsec によってパケットが保護されていることを確認する方法

パケットが保護されていることを確認するには、snoop コマンドで接続をテストします。snoop 出力に表示される接頭辞は、次のとおりです。

始める前に

snoop 出力を作成するためには、スーパーユーザーであるか、それと同等の役割でなければなりません。さらに、接続をテストするためには、両方のシステムにアクセスできなければなりません。

  1. 一方のシステム (たとえば、partym) でスーパーユーザー になります。


    % su -
Password: Type root password
#

  2. partym システムから、リモートシステムからパケットをスヌープする準備をします。

    partym の端末ウィンドウで、enigma システムからパケットをスヌープします。


    # snoop -v enigma
Using device /dev/hme (promiscuous mode)

  3. リモートシステムからパケットを送信します。

    別の端末ウィンドウで、enigma システムにリモートからログインします。パスワードを入力します。次に、スーパーユーザーになり、enigma システムからのパケットを partym システムに送信します。パケットは、snoop -v enigma コマンドで取り込む必要があります。


    % ssh enigma
Password: Type your password
% su -
Password: Type root password
# ping partym

  4. snoop の出力を調べます。

    partym システムで、冒頭の IP ヘッダー情報のあとに AH と ESP 情報が含まれている出力を確認します。次のような AH と ESP の情報は、パケットが保護されていることを示します。


    IP:   Time to live = 64 seconds/hops
IP:   Protocol = 51 (AH)
IP:   Header checksum = 4e0e
IP:   Source address = 192.168.116.16, enigma
IP:   Destination address = 192.168.13.213, partym
IP:   No options
IP:
AH:  ----- Authentication Header -----
AH:
AH:  Next header = 50 (ESP)
AH:  AH length = 4 (24 bytes)
AH:  <Reserved field = 0x0>
AH:  SPI = 0xb3a8d714
AH:  Replay = 52
AH:  ICV = c653901433ef5a7d77c76eaa
AH:
ESP:  ----- Encapsulating Security Payload -----
ESP:
ESP:  SPI = 0xd4f40a61
ESP:  Replay = 52
ESP:     ....ENCRYPTED DATA....

ETHER:  ----- Ether Header -----
...

Procedureネットワークセキュリティーの役割を設定する方法

役割によるアクセス制御 (RBAC) でシステムを管理している場合は、ネットワーク管理またはネットワークセキュリティー上の役割を提供するためにこの手順を使用します。

  1. ローカルの prof_attr データベースで Network 権利プロファイルを検索します。

    現在のリリースでは、次のような出力が表示されます。


    % cd /etc/security
% grep Network prof_attr
Network IPsec Management:::Manage IPsec and IKE...
Network Link Security:::Manage network link security...
Network Management:::Manage the host and network configuration...
Network Security:::Manage network and host security...
Network Wifi Management:::Manage wifi network configuration...
Network Wifi Security:::Manage wifi network security...

    Solaris 10 4/09 リリースより前のリリースを実行している場合は、次のような出力が表示されます。


    % cd /etc/security
% grep Network prof_attr
Network Management:::Manage the host and network configuration  
Network Security:::Manage network and host security  
System Administrator::: Network Management 

    Network Management プロファイルは、System Administrator プロファイルを補完するプロファイルです。System Administrator 権利プロファイルを役割に含めると、その役割は Network Management プロファイルでコマンドを実行できます。

  2. Network Management 権利プロファイルに含まれているコマンドを調べます。


    % grep "Network Management" /etc/security/exec_attr
Network Management:solaris:cmd:::/usr/sbin/ifconfig:privs=sys_net_config
…
Network Management:suser:cmd:::/usr/sbin/snoop:uid=0

    solaris ポリシーコマンドは、特権 (privs=sys_net_config) で実行されます。suser ポリシーコマンドは、スーパーユーザー (uid=0) として実行されます。

  3. サイトでのネットワークセキュリティーの役割の範囲を決定します。

    決定には、手順 1 の権利プロファイルの定義を参考にしてください。

    • すべてのネットワークセキュリティーを扱う役割を作成する場合は、Network Security 権利プロファイルを使用します。

    • 現在のリリースで、IPsec と IKE だけを扱う役割を作成する場合は、Network IPsec Management 権利プロファイルを使用します。

  4. Network Management 権利プロファイルを含むネットワークセキュリティーの役割を作成します。

    Network Management プロファイルに加え、Network Security または Network IPsec Management 権利プロファイルを持つ役割は、ifconfig、snoop、ipsecconf、および ipseckey コマンドなどを適切な特権で実行できます。

    役割の作成、役割のユーザーへの割り当て、ネームサービスによる変更点の登録については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

例 20–5 ネットワークセキュリティーの責任を役割に振り分ける

この例では、管理者がネットワークセキュリティーの責任を 2 つの役割に振り分けます。一方の役割は wifi とリンクのセキュリティーを管理し、もう一方の役割は IPsec と IKE を管理します。各役割には、シフトごとに 1 人、合計 3 人を割り当てます。

管理者によって次のように役割が作成されます。

ProcedureIKE および IPsec サービスを管理する方法

次の手順では、IPsec の管理、IKE の管理、および手動での鍵管理に SMF サービスを使用する代表的な方法について説明します。デフォルトでは、policy サービスと ipsecalgs サービスは有効になっています。また、デフォルトでは、ike サービスと manual-key サービスは無効になっています。

  1. IPsec ポリシーを管理するには、次のいずれかを実行します。

    • ipsecinit.conf ファイルに新しいポリシーを追加したあと、policy サービスを更新します。


      # svcadm refresh svc:/network/ipsec/policy

    • サービスのプロパティーの値を変更したあと、プロパティーの値を表示し、policy サービスを更新してから再起動します。


      # svccfg -s policy setprop config/config_file=/etc/inet/MyIpsecinit.conf
# svcprop -p config/config_file policy
/etc/inet/MyIpsecinit.conf
# svcadm refresh svc:/network/ipsec/policy
# svcadm restart svc:/network/ipsec/policy

  2. 鍵を自動的に管理するには、次のいずれかを実行します。

    • /etc/inet/ike/config ファイルにエントリを追加したあと、ike サービスを有効にします。


      # svcadm enable svc:/network/ipsec/ike

    • /etc/inet/ike/config ファイルのエントリを変更したあと、ike サービスを更新します。


      # svcadm refresh svc:/network/ipsec/ike

    • サービスのプロパティーの値を変更したあと、プロパティーの値を表示し、サービスを更新してから再起動します。


      # svccfg -s ike setprop config/admin_privilege=modkeys
# svcprop -p config/admin_privilege ike
modkeys
# svcadm refresh svc:/network/ipsec/ike
# svcadm restart svc:/network/ipsec/ike

    • ike サービスを停止するには、無効にします。


      # svcadm disable svc:/network/ipsec/ike

  3. 鍵を手動で管理するには、次のいずれかを実行します。

    • /etc/inet/secret/ipseckeys ファイルにエントリを追加したあと、manual-key サービスを有効にします。


      # svcadm enable svc:/network/ipsec/manual-key

    • ipseckeys ファイルを変更したあと、サービスを更新します。


      # svcadm refresh manual-key

    • サービスのプロパティーの値を変更したあと、プロパティーの値を表示し、サービスを更新してから再起動します。


      # svccfg -s manual-key setprop config/config_file=/etc/inet/secret/MyIpseckeyfile
# svcprop -p config/config_file manual-key
/etc/inet/secret/MyIpseckeyfile
# svcadm refresh svc:/network/ipsec/manual-key
# svcadm restart svc:/network/ipsec/manual-key

    • 鍵を手動で管理できないようにするには、manual-key サービスを無効にします。


      # svcadm disable svc:/network/ipsec/manual-key

  4. IPsec のプロトコルとアルゴリズムのテーブルを変更した場合は、ipsecalgs サービスを更新します。


    # svcadm refresh svc:/network/ipsec/ipsecalgs
注意事項

サービスの状態を調べるには、svcs service コマンドを使用します。サービスが maintenance (保守) モードになっている場合は、svcs -x service コマンドの出力に表示されるデバッグのヒントに従ってください。

IPsec による VPN の保護

IPsec トンネルで VPN を保護することができます。Solaris 10 7/07 リリースでは、トンネルはトンネルモードまたはトランスポートモードで使用できます。「トンネルモード」は、ほかのベンダーによって実装された IPsec と相互運用できます。「トランスポートモード」は、以前のバージョンの Solaris OS と相互運用できます。トンネルのモードについては、「IPsec のトランスポートモードとトンネルモード」を参照してください。

トンネルモードのトンネルを使用すると、トラフィックをよりきめ細かく制御できます。トンネルモードでは、内側の IP アドレスに対して、必要に応じて特定の保護をポート単位まで細かく指定できます。

トンネルモードのトンネルを使用して VPN を IPsec で保護する例

図 20–1 IPsec トンネル図

この図は、2 つの LAN を接続する VPN を示しています。各 LAN には 4 つのサブネットがあります。

次の例では、LAN のすべてのサブネットに対してトンネルを構成することを前提にしています。


## Tunnel configuration ##
# Tunnel name is ip.tun0
# Intranet point for the source is 10.1.2.1
# Intranet point for the destination is 10.2.3.1
# Tunnel source is 192.168.1.10
# Tunnel destination is 192.168.2.10
例 20–6 すべてのサブネットで使用できるトンネルの作成

この例では、図 20–1 の Central LAN のローカル LAN から送信されるすべてのトラフィックが、ルーター 1 からルーター 2 にトンネリングされ、Overseas LAN のすべてのローカル LAN に配信されます。トラフィックは AES で暗号化されます。


## IPsec policy ##
{tunnel ip.tun0 negotiate tunnel} 
 ipsec {encr_algs aes encr_auth_algs sha1 sa shared}
例 20–7 2 つのサブネットだけを接続するトンネルの作成

この例では、Central LAN のサブネット 10.1.2.0/24 と Overseas LAN のサブネット 10.2.3.0/24 の間のトラフィックだけがトンネリングされ、暗号化されます。Central に対するほかの IPsec ポリシーがない場合、Central LAN がこのトンネル経由でほかの LAN にトラフィックを配信しようとすると、トラフィックはルーター 1 でドロップされます。


## IPsec policy ##
{tunnel ip.tun0 negotiate tunnel laddr 10.1.2.0/24 raddr 10.2.3.0/24} 
 ipsec {encr_algs aes encr_auth_algs md5 sha1 shared}
例 20–8 2 つのサブネット間だけの電子メールトラフィック用トンネルの作成

この例では、電子メールトラフィック専用のトンネルが作成されます。トラフィックは、Central LAN のサブネット 10.1.2.0/24 から、Overseas LAN の 10.2.3.0/24 サブネット上にある電子メールサーバーに配信されます。電子メールは Blowfish で暗号化されます。ポリシーは、リモートおよびローカルの電子メールポートに適用されます。rport ポリシーは、Central からリモートの Overseas の電子メールポートに送信される電子メールを保護します。lport ポリシーは、Central のローカルポート 25 で受信される Overseas からの電子メールを保護します。


## IPsec policy for email from Central to Overseas ##
{tunnel ip.tun0 negotiate tunnel ulp tcp rport 25 
 laddr 10.1.2.0/24 raddr 10.2.3.0/24} 
 ipsec {encr_algs blowfish encr_auth_algs sha1 sa shared}
 

## IPsec policy for email from Overseas to Central ##
{tunnel ip.tun0 negotiate tunnel ulp tcp lport 25 
 laddr 10.1.2.0/24 raddr 10.2.3.0/24} 
 ipsec {encr_algs blowfish encr_auth_algs sha1 sa shared}
例 20–9 すべてのサブネットに対する FTP トラフィック用トンネルの作成

この例の IPsec ポリシーは、図 20–1 の Central LAN のすべてのサブネットから Overseas LAN のすべてのサブネットまで、FTP ポートを AES で保護します。この構成は、FTP アクティブモードで機能します。


## IPsec policy for outbound FTP from Central to Overseas ##
{tunnel ip.tun0 negotiate tunnel ulp tcp rport 21} 
  ipsec {encr_algs aes encr_auth_algs sha1 sa shared}
{tunnel ip.tun0 negotiate tunnel ulp tcp lport 20} 
  ipsec {encr_algs aes encr_auth_algs sha1 sa shared}
 

## IPsec policy for inbound FTP from Central to Overseas ##
{tunnel ip.tun0 negotiate tunnel ulp tcp lport 21} 
  ipsec {encr_algs aes encr_auth_algs sha1 sa shared}
{tunnel ip.tun0 negotiate tunnel ulp tcp rport 20} 
  ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

IPsec による VPN の保護 (作業マップ)

次の作業マップに、インターネット経由のトラフィックを保護するように IPsec を構成する手順を示します。これらの手順を使用すると、インターネットで隔てられている 2 つのシステムの間に、セキュリティー保護された仮想プライベートネットワーク (VPN) を設定できます。この技術の一般的な使用法の 1 つは、自宅勤務者と会社のオフィスの間のトラフィックを保護することです。

タスク 

説明 

説明 

IPv4 トンネルモードでトンネルトラフィックを保護します。 

2 つの Solaris 10 システム間、2 つの Oracle Solaris システム間、または Solaris 10 システムと Oracle Solaris Express システムの間で、トンネルモードでトラフィックを保護します。Solaris 10 システムで Solaris 10 7/07 リリース以上が実行されている必要があります。 

また、Solaris 10 システムまたは Oracle Solaris Express システムと、別のプラットフォームで稼働中のシステムの間でも、トンネルモードでトラフィックを保護します。Solaris 10 システムで Solaris 10 7/07 リリース以上が実行されている必要があります。 

「IPv4 トンネルモードの IPsec トンネルで VPN を保護する方法」

IPv6 トンネルモードでトンネルトラフィックを保護します。 

IPv6 プロトコルを使用している 2 つの Oracle Solaris システム間で、トンネルモードでトラフィックを保護します。 

「IPv6 トンネルモードの IPsec トンネルで VPN を保護する方法」

IPv4 トランスポートモードでトンネルトラフィックを保護します。 

2 つの Solaris 10 システム間、2 つの Solaris システム間、または Solaris 10 システムと Oracle Solaris システムの間で、トランスポートモードでトラフィックを保護します。Solaris 10 システムで Solaris 10 7/07 リリース以上が実行されている必要があります。 

また、以前のバージョンの Solaris OS を実行しているシステムと、Solaris 10 または Oracle Solaris システムの間でも、トランスポートモードでトラフィックを保護します。Solaris 10 システムで Solaris 10 7/07 リリース以上が実行されている必要があります。 

「IPv4 トランスポートモードの IPsec トンネルで VPN を保護する方法」

推奨されなくなった古い構文を使用してトラフィックを保護します。この方法は、以前のバージョンの Solaris OS を実行しているシステムと通信する場合に役立ちます。この方法を使用すると、2 つのシステム上にある構成ファイルの比較が簡単になります。 

例 20–11

例 20–16

IPv6 トランスポートモードでトンネルトラフィックを保護します。 

IPv6 プロトコルを使用している 2 つの Oracle Solaris システム間で、トランスポートモードでトラフィックを保護します。 

「IPv6 トランスポートモードの IPsec トンネルで VPN を保護する方法」

IP のスプーフィングを防止します。 

SMF サービスを作成して、システムがパケットを復号化せずに VPN 上で転送することを防止します。 

「IP のスプーフィングを防止する方法」

IPsec で VPN を保護する作業のためのネットワークトポロジの説明

この節以降に説明する手順では、次の設定がすでになされているものとします。図 20–2 はこのネットワークを表しています。

図 20–2 インターネットで隔てられているオフィス間の VPN の例

この図は、ヨーロッパのオフィスとカリフォルニアのオフィスを接続する VPN の詳細を示しています。

前の図に示すように、IPv4 ネットワーク向けの手順では次の構成パラメータを使用します。

パラメータ 

ヨーロッパ 

カリフォルニア 

システム名 

 

enigma
 

partym

システムイントラネットインタフェース 

 

hme1
 

hme1

システムイントラネットアドレス。手順 7 の -point アドレスでもある

 

10.16.16.6
 

10.1.3.3

システムインターネットインタフェース 

 

hme0
 

hme0

システムイントラネットアドレス。手順 7 の tsrc アドレスでもある

 

192.168.116.16
 

192.168.13.213

インターネットルーターの名前 

 

router-E
 

router-C

インターネットルーターのアドレス 

 

192.168.116.4
 

192.168.13.5

トンネル名 

 

ip.tun0
 

ip.tun0

手順では次の IPv6 アドレスを使用します。トンネル名は同じです。

パラメータ 

ヨーロッパ 

カリフォルニア 

システムイントラネットアドレス 

 

6000:6666::aaaa:1116
 

6000:3333::eeee:1113

システムインターネットアドレス 

 

2001::aaaa:6666:6666
 

2001::eeee:3333:3333

インターネットルーターのアドレス 

 

2001::aaaa:0:4
 

2001::eeee:0:1

ProcedureIPv4 トンネルモードの IPsec トンネルで VPN を保護する方法

トンネルモードでは、内側の IP パケットによって、その内容を保護する IPsec ポリシーが決まります。

この手順は、「IPsec で 2 つのシステム間のトラフィックを保護するには」の手順の応用です。設定については、「IPsec で VPN を保護する作業のためのネットワークトポロジの説明」を参照してください。

注 –

両方のシステムでこの手順を実行してください。

この手順では、2 つのシステムを接続するだけでなく、これら 2 つのシステムに接続している 2 つのイントラネットを接続します。この手順における 2 つのシステムはゲートウェイとして機能します。

始める前に

システムまたは共有 IP ゾーンの IPsec ポリシーの構成は、大域ゾーンで行う必要があります。排他的 IP ゾーンについては、非大域ゾーンで IPsec ポリシーを構成します。

  1. システムコンソール上で、Primary Administrator の役割を引き受けるか、スーパーユーザーになります。

    Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

    注 –

    リモートログインすると、セキュリティー上重要なトラフィックが盗聴される恐れがあります。何らかの方法でリモートログインを保護していても、システムのセキュリティーがリモートログインセッションレベルに低下します。セキュリティー保護されたリモートログインには、ssh コマンドを使用してください。

  2. IPsec を構成する前に、パケットフローを制御します。

    1. IP 転送と IP 動的経路制御が無効になっていることを確認します。


      # routeadm
Configuration       Current         Current
       Option       Configuration  System State
--------------------------------------------------
IPv4 forwarding     disabled           disabled
   IPv4 routing     default (enabled)   enabled
…

      IP 転送や IP 動的経路制御が有効な場合は、次のように入力して無効にします。


      # routeadm -d ipv4-routing -d ipv4-forwarding
# routeadm -u

      IP 転送をオフにすると、このシステムを経由したネットワーク間のパケット送信ができなくなります。routeadm コマンドの説明については、routeadm(1M) のマニュアルページを参照してください。

    2. 次のコマンドを入力して IP の厳密宛先マルチホームをオンに設定します。


      # ndd -set /dev/ip ip_strict_dst_multihoming 1

      IP 厳密宛先マルチホームをオンに設定すると、システムの宛先アドレスのうちの 1 つに宛てたパケットは、正しい宛先アドレスに必ず到着します。

      厳密宛先マルチホームが有効な状態では、特定のインタフェースに到着したパケットに、そのインタフェースのいずれかのローカル IP アドレスを指定する必要があります。その他のパケットは、システムのほかのローカルアドレスが指定されているものも含めてすべて捨てられます。

      注意 – 注意 –

      システムの起動時に、マルチホームの値はデフォルトに戻ります。変更した値を持続させる方法については、「IP のスプーフィングを防止する方法」を参照してください。

    3. 大部分のネットワークサービス、可能な場合はすべてのネットワークサービスを無効にします。

      注 –

      「制限付き」SMF プロファイルでシステムをインストールした場合、この手順は省略できます。Solaris Secure Shell 以外のネットワークサービスは無効になります。

      ネットワークサービスを無効にすると、IP パケットがシステムにダメージを与えるのを防止できます。たとえば、SNMP デーモン、telnet 接続、rlogin 接続などを最大限に活用できます。

      次のオプションのいずれかを選択します。

      • Solaris 10 11/06 以降のリリースが稼働している場合は、「制限付き」SMF プロファイルを実行します。


        # netservices limited

      • それ以外の場合は、ネットワークサービスを個別に無効にします。


        # svcadm disable network/ftp:default
# svcadm disable network/finger:default
# svcadm disable network/login:rlogin
# svcadm disable network/nfs/server:default
# svcadm disable network/rpc/rstat:default
# svcadm disable network/smtp:sendmail
# svcadm disable network/telnet:default

    4. ほとんどのネットワークサービスが無効になっていることを確認します。

      ループバックマウントと ssh サービスが稼働していることを確認します。


      # svcs | grep network
online         Aug_02   svc:/network/loopback:default
…
online         Aug_09   svc:/network/ssh:default

  3. 2 つのシステム間に SA ペアを追加します。

    次のオプションのいずれかを選択します。

  4. IPsec ポリシーを追加します。

    /etc/inet/ipsecinit.conf ファイルを編集して、VPN 用の IPsec ポリシーを追加します。ポリシーを強化する方法については、例 20–12 を参照してください。その他の例については、「トンネルモードのトンネルを使用して VPN を IPsec で保護する例」を参照してください。

    このポリシーでは、ローカル LAN 上のシステムとゲートウェイの内部 IP アドレスの間に IPsec 保護は必要でないため、bypass 文を追加します。

    1. enigma システムで、ipsecinit.conf ファイルに次のエントリを入力します。


      # LAN traffic to and from this host can bypass IPsec.
{laddr 10.16.16.6 dir both} bypass {}

# WAN traffic uses ESP with AES and SHA-1.
{tunnel ip.tun0 negotiate tunnel} 
 ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

    2. partym システムで、ipsecinit.conf ファイルに次のエントリを追加します。


      # LAN traffic to and from this host can bypass IPsec.
{laddr 10.1.3.3 dir both} bypass {}

# WAN traffic uses ESP with AES and SHA-1.
{tunnel ip.tun0 negotiate tunnel} 
 ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

  5. (省略可能) IPsec ポリシーファイルの構文を確認します。


    # ipsecconf -c -f /etc/inet/ipsecinit.conf

  6. トンネルを構成し、それを IPsec で保護する場合は、Solaris のリリースに応じて次の手順に従います。

    • Solaris 10 4/09 リリース以降では、手順 7 から手順 13 までを実行したあと、手順 22 の経路制御プロトコルを実行します。

    • Solaris 10 4/09 リリースより前のリリースを実行している場合は、手順 14 から手順 22 までを実行します。

  7. トンネル ip.tun0 を /etc/hostname.ip.tun0 ファイルで構成します。

    ファイルの構文は次のとおりです。


    system1-point system2-point tsrc system1-taddr tdst system2-taddr router up

    1. enigma システムで、hostname.ip.tun0 ファイルに次のエントリを追加します。


      10.16.16.6 10.1.3.3 tsrc 192.168.116.16 tdst 192.168.13.213 router up

    2. partym システムで、hostname.ip.tun0 ファイルに次のように追加します。


      10.1.3.3 10.16.16.6 tsrc 192.168.13.213 tdst 192.168.116.16 router up

  8. 作成した IPsec ポリシーでトンネルを保護します。


    # svcadm refresh svc:/network/ipsec/policy:default

  9. トンネル構成ファイルの内容をカーネルに読み込むには、ネットワークサービスを再起動します。


    # svcadm restart svc:/network/initial:default

  10. hme1 インタフェースの IP 転送をオンに設定します。

    1. enigma システムで、/etc/hostname.hme1 ファイルにルーターエントリを追加します。


      192.168.116.16 router

    2. partym システムで、/etc/hostname.hme1 ファイルにルーターエントリを追加します。


      192.168.13.213 router

    IP 転送とは、別のインタフェースから到着したパケットを転送できることを意味します。IP 転送はまた、送信するパケットがもともとは別のインタフェースから発信されたパケットである可能性も意味します。パケットを正しく転送するには、受信インタフェースと送信インタフェースの IP 転送をオンに設定しておきます。

    hme1 インタフェースはイントラネットの「内部」にあるため、hme1 の IP 転送はオンに設定しておきます。さらに、ip.tun0 はインターネットを通してこれら 2 つのシステムを接続するため、ip.tun0 の IP 転送はオンに設定しておきます。

    hme0 インタフェースの IP 転送はオフです。そのため、「外部」からパケットが保護イントラネットに侵入するのを防ぐことができます。「外部」とはインターネットを意味します。

  11. 経路制御プロトコルによってイントラネット内のデフォルトのルートが通知されていないことを確認します。

    1. enigma システムで、private フラグを /etc/hostname.hme0 ファイルに追加します。


      10.16.16.6 private

    2. partym システムで、private フラグを /etc/hostname.hme0 ファイルに追加します。


      10.1.3.3 private

    hme0 の IP 転送がオフになっていても、経路制御プロトコルの実装によっては、このインタフェースを通知することがあります。たとえば、in.routed プロトコルは、イントラネット内のピアにパケットが転送される際に hme0 を有効なインタフェースとして通知する場合があります。インタフェースの「private」フラグを設定して、このような通知が行われないようにします。

  12. hme0 インタフェース経由のデフォルトルートを手動で追加します。

    デフォルトルートは、インターネットに直接アクセスできるルーターでなければなりません。

    1. enigma システムで、次のルートを追加します。


      # route add default 192.168.116.4

    2. partym システムで次のルートを追加します。


      # route add default 192.168.13.5

      hme0 インタフェースはイントラネットの一部ではありませんが、インターネットを介してそのピアシステムにアクセスする必要があります。hme0 は、自身のピアを見つけるために、インターネット経路制御情報を必要とします。インターネットの残りの要素にとって、VPN システムは、ルーターというよりもホストのような存在です。したがって、デフォルトルーターを使用するか、ルーター発見プロトコルを実行すれば、ピアシステムを見つけることができます。詳細については、route(1M) と in.routed(1M) のマニュアルページを参照してください。

  13. 手順を完了するために、手順 22 に進んで経路制御プロトコルを実行します。

  14. トンネル ip.tun0 を構成します。

    注 –

    次の手順は、Solaris 10 4/09 リリースより前のリリースを実行しているシステムでトンネルを構成するためのものです。

    ifconfig コマンドを使用してポイントツーポイントインタフェースを作成します。


    # ifconfig ip.tun0 plumb

# ifconfig ip.tun0 system1-point system2-point \
tsrc system1-taddr tdst system2-taddr

    1. enigma システムで、次のコマンドを入力します。


      # ifconfig ip.tun0 plumb

# ifconfig ip.tun0 10.16.16.6 10.1.3.3 \
tsrc 192.168.116.16 tdst 192.168.13.213

    2. partym システムで、次のコマンドを入力します。


      # ifconfig ip.tun0 plumb

# ifconfig ip.tun0 10.1.3.3 10.16.16.6  \
tsrc 192.168.13.213 tdst 192.168.116.16

  15. 作成した IPsec ポリシーでトンネルを保護します。


    # ipsecconf

  16. トンネル用のルーターを起動します。


    # ifconfig ip.tun0 router up

  17. hme1 インタフェースの IP 転送をオンに設定します。


    # ifconfig hme1 router

    IP 転送とは、別のインタフェースから到着したパケットを転送できることを意味します。IP 転送はまた、送信するパケットがもともとは別のインタフェースから発信されたパケットである可能性も意味します。パケットを正しく転送するには、受信インタフェースと送信インタフェースの IP 転送をオンに設定しておきます。

    hme1 インタフェースはイントラネットの「内部」にあるため、hme1 の IP 転送はオンに設定しておきます。さらに、ip.tun0 はインターネットを通してこれら 2 つのシステムを接続するため、ip.tun0 の IP 転送はオンに設定しておきます。

    hme0 インタフェースの IP 転送はオフです。そのため、「外部」からパケットが保護イントラネットに侵入するのを防ぐことができます。「外部」とはインターネットを意味します。

  18. 経路制御プロトコルによってイントラネット内のデフォルトのルートが通知されていないことを確認します。


    # ifconfig hme0 private

    hme0 の IP 転送がオフになっていても、経路制御プロトコルの実装によっては、このインタフェースを通知することがあります。たとえば、in.routed プロトコルは、イントラネット内のピアにパケットが転送される際に hme0 を有効なインタフェースとして通知する場合があります。インタフェースの「private」フラグを設定して、このような通知が行われないようにします。

  19. hme0 経由のデフォルトルートを手動で追加します。

    デフォルトルートは、インターネットに直接アクセスできるルーターでなければなりません。

    1. enigma システムで、次のルートを追加します。


      # route add default 192.168.116.4

    2. partym システムで次のルートを追加します。


      # route add default 192.168.13.5

      hme0 インタフェースはイントラネットの一部ではありませんが、インターネットを介してそのピアシステムにアクセスする必要があります。hme0 は、自身のピアを見つけるために、インターネット経路制御情報を必要とします。インターネットの残りの要素にとって、VPN システムは、ルーターというよりもホストのような存在です。したがって、デフォルトルーターを使用するか、ルーター発見プロトコルを実行すれば、ピアシステムを見つけることができます。詳細については、route(1M) と in.routed(1M) のマニュアルページを参照してください。

  20. VPN がリブート後に開始するように、/etc/hostname.ip.tun0 ファイルにエントリを追加します。


    system1-point system2-point tsrc system1-taddr tdst system2-taddr router up

    1. enigma システムで、hostname.ip.tun0 ファイルに次のエントリを追加します。


      10.16.16.6 10.1.3.3 tsrc 192.168.116.16 tdst 192.168.13.213 router up

    2. partym システムで、hostname.ip.tun0 ファイルに次のように追加します。


      10.1.3.3 10.16.16.6 tsrc 192.168.13.213 tdst 192.168.116.16 router up

  21. 適切なパラメータが経路制御デーモンに渡されるようにインタフェースファイルを設定します。

    1. enigma システムで、/etc/hostname.interface ファイルを変更します。


      # cat /etc/hostname.hme0
## enigma
10.16.16.6 private
      		 

      # cat /etc/hostname.hme1
## enigma
192.168.116.16 router

    2. partym システムで、/etc/hostname.interface ファイルを変更します。


      # cat /etc/hostname.hme0
## partym
10.1.3.3 private
      		 

      # cat /etc/hostname.hme1
## partym
192.168.13.213 router

  22. 経路制御プロトコルを実行します。


    # routeadm -e ipv4-routing
# routeadm -u

    経路制御プロトコルを実行する前に経路制御プロトコルの構成が必要な場合があります。詳細は、「Oracle Solaris の経路制御プロトコル」を参照してください。手順については、「IPv4 ルーターの構成方法」を参照してください。

例 20–10 テスト時に一時的なトンネルを作成する

この例では、管理者が Solaris 10 4/09 システムでトンネルの作成をテストします。あとで 「IPv4 トンネルモードの IPsec トンネルで VPN を保護する方法」の手順を使用して、これらを永続的なトンネルにします。テスト中に、管理者はシステム system1 および system2 で次の一連の手順を実行します。

例 20–11 コマンド行を使用して以前のバージョンの Solaris システムにトンネルを作成する

Solaris 10 7/07 リリースでは、ifconfig コマンドの構文が簡素化されました。この例では、Solaris 10 7/07 リリースより前のバージョンの Solaris を実行しているシステムに対するトンネルの作成を管理者がテストします。ifconfig コマンドの元の構文を使用すれば、通信する 2 つのシステムで同じコマンドを使用できます。あとで 「IPv4 トンネルモードの IPsec トンネルで VPN を保護する方法」の手順を使用して、これらを永続的なトンネルにします。

テスト中に、管理者はシステム system1 および system2 で次の手順を実行します。

例 20–12 LAN 上のすべてのシステムでの IPsec ポリシーの要求

この例では、手順 4 で構成した bypass ポリシーをコメントにして、保護を強化します。このポリシーを構成した場合は、LAN 上のすべてのシステムが、ルーターと通信するために IPsec を有効にしなければなりません。


# LAN traffic must implement IPsec.
# {laddr 10.1.3.3 dir both} bypass {}

# WAN traffic uses ESP with AES and SHA-1.
{tunnel ip.tun0 negotiate tunnel} ipsec {encr_algs aes encr_auth_algs sha1}
例 20–13 IPsec を使用して Telnet トラフィックと SMTP トラフィックを異なる方法で保護する

この例の最初の規則は、ポート 23 の telnet トラフィックを Blowfish と SHA-1 で保護します。2 番目の規則はポート 25 の SMTP トラフィックを AES と MD5 で保護します。


{laddr 10.1.3.3 ulp tcp dport 23 dir both} 
  ipsec {encr_algs blowfish encr_auth_algs sha1 sa unique}
{laddr 10.1.3.3 ulp tcp dport 25 dir both} 
 ipsec {encr_algs aes encr_auth_algs md5 sa unique}
例 20–14 トンネルモードの IPsec トンネルを使用して、ほかのネットワークトラフィックとは異なる方法でサブネットを保護する

次のトンネル構成は、トンネルを経由するサブネット 10.1.3.0/24 からのすべてのトラフィックを保護します。


{tunnel ip.tun0 negotiate tunnel laddr 10.1.3.0/24} 
  ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

次のトンネル構成は、トンネルを経由するサブネット 10.1.3.0/24 からほかのサブネットへのトラフィックを保護します。10.2.x.x で始まるサブネットはトンネルを経由します。


{tunnel ip.tun0 negotiate tunnel laddr 10.1.3.0/24 raddr 10.2.1.0/24} 
  ipsec {encr_algs blowfish encr_auth_algs sha1 sa shared}
 

{tunnel ip.tun0 negotiate tunnel laddr 10.1.3.0/24 raddr 10.2.2.0/24} 
  ipsec {encr_algs blowfish encr_auth_algs sha1 sa shared}
 

{tunnel ip.tun0 negotiate tunnel laddr 10.1.3.0/24 raddr 10.2.3.0/24} 
  ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

ProcedureIPv6 トンネルモードの IPsec トンネルで VPN を保護する方法

IPv6 ネットワークで VPN を使用するには、IPv4 ネットワークの場合と同じ手順を実行します。ただし、コマンドの構文は少し違います。特定のコマンドを実行する理由についての詳細は、「IPv4 トンネルモードの IPsec トンネルで VPN を保護する方法」の該当する手順を参照してください。

注 –

両方のシステムでこの手順を実行してください。

この手順では、次の構成パラメータを使用します。

パラメータ 

ヨーロッパ 

カリフォルニア 

システム名 

 

enigma
 

partym

システムイントラネットインタフェース 

 

hme1
 

hme1

システムインターネットインタフェース 

 

hme0
 

hme0

システムイントラネットアドレス 

 

6000:6666::aaaa:1116
 

6000:3333::eeee:1113

システムインターネットアドレス 

 

2001::aaaa:6666:6666
 

2001::eeee:3333:3333

インターネットルーターの名前 

 

router-E
 

router-C

インターネットルーターのアドレス 

 

2001::aaaa:0:4
 

2001::eeee:0:1

トンネル名 

 

ip6.tun0
 

ip6.tun0

  1. システムコンソール上で、Primary Administrator の役割を引き受けるか、スーパーユーザーになります。

    Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

    注 –

    リモートログインすると、セキュリティー上重要なトラフィックが盗聴される恐れがあります。何らかの方法でリモートログインを保護していても、システムのセキュリティーがリモートログインセッションレベルに低下します。セキュリティー保護されたリモートログインには、ssh コマンドを使用してください。

  2. IPsec を構成する前に、パケットフローを制御します。

    これらのコマンドの効果については、「IPv4 トンネルモードの IPsec トンネルで VPN を保護する方法」の手順 2 を参照してください。

    1. IP 転送と IP 動的経路制御が無効になっていることを確認します。


      # routeadm
Configuration       Current         Current
       Option       Configuration  System State
--------------------------------------------------
…
IPv6 forwarding     disabled          disabled
   IPv6 routing     disabled          disabled

      IP 転送や IP 動的経路制御が有効な場合は、次のように入力して無効にします。


      # routeadm -d ipv6-forwarding -d ipv6-routing
# routeadm -u

    2. 次のコマンドを入力して IP の厳密宛先マルチホームをオンに設定します。


      # ndd -set /dev/ip ip6_strict_dst_multihoming 1
      注意 – 注意 –

      システムの起動時に、ip6_strict_dst_multihoming の値はデフォルトに戻ります。変更した値を持続させる方法については、「IP のスプーフィングを防止する方法」を参照してください。

    3. 大部分のネットワークサービス、可能な場合はすべてのネットワークサービスを無効にします。

      注 –

      「制限付き」SMF プロファイルでシステムをインストールした場合、この手順は省略できます。Solaris Secure Shell 以外のネットワークサービスは無効になります。

      ネットワークサービスを無効にすると、IP パケットがシステムにダメージを与えるのを防止できます。たとえば、SNMP デーモン、telnet 接続、rlogin 接続などを最大限に活用できます。

      次のオプションのいずれかを選択します。

      • Solaris 10 11/06 以降のリリースが稼働している場合は、「制限付き」SMF プロファイルを実行します。


        # netservices limited

      • それ以外の場合は、ネットワークサービスを個別に無効にします。


        # svcadm disable network/ftp:default
# svcadm disable network/finger:default
# svcadm disable network/login:rlogin
# svcadm disable network/nfs/server:default
# svcadm disable network/rpc/rstat:default
# svcadm disable network/smtp:sendmail
# svcadm disable network/telnet:default 

    4. ほとんどのネットワークサービスが無効になっていることを確認します。

      ループバックマウントと ssh サービスが稼働していることを確認します。


      # svcs | grep network
online         Aug_02   svc:/network/loopback:default
...
online         Aug_09   svc:/network/ssh:default

  3. 2 つのシステム間に SA ペアを追加します。

    次のオプションのいずれかを選択します。

  4. VPN 用の IPsec ポリシーを追加します。

    /etc/inet/ipsecinit.conf ファイルを編集して、VPN 用の IPsec ポリシーを追加します。

    1. enigma システムで、ipsecinit.conf ファイルに次のエントリを追加します。


      # IPv6 Neighbor Discovery messages bypass IPsec.
{ulp ipv6-icmp type 133-137 dir both} pass {}

# LAN traffic to and from this host can bypass IPsec.
{laddr 6000:6666::aaaa:1116 dir both} bypass {}

# WAN traffic uses ESP with AES and SHA-1.
{tunnel ip6.tun0 negotiate tunnel} 
  ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

    2. partym システムで、ipsecinit.conf ファイルに次のエントリを追加します。


      # IPv6 Neighbor Discovery messages bypass IPsec.
{ulp ipv6-icmp type 133-137 dir both} pass {}

# LAN traffic to and from this host can bypass IPsec.
{laddr 6000:3333::eeee:1113 dir both} bypass {}

# WAN traffic uses ESP with AES and SHA-1.
{tunnel ip6.tun0 negotiate tunnel} 
  ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

  5. (省略可能) IPsec ポリシーファイルの構文を確認します。


    # ipsecconf -c -f /etc/inet/ipsecinit.conf

  6. トンネルを構成し、それを IPsec で保護する場合は、Solaris のリリースに応じて次の手順に従います。

    • Solaris 10 4/09 リリース以降では、手順 7 から手順 13 までを実行したあと、手順 22 の経路制御プロトコルを実行します。

    • Solaris 10 4/09 リリースより前のリリースを実行している場合は、手順 14 から手順 22 までを実行します。

  7. /etc/hostname.ip6.tun0 ファイルで、トンネル ip6.tun0 を構成します。

    1. enigma システムで、hostname.ip6.tun0 ファイルに次のエントリを追加します。


      6000:6666::aaaa:1116 6000:3333::eeee:1113 tsrc 2001::aaaa:6666:6666 tdst 2001::eeee:3333:3333 router up

    2. partym システムで、hostname.ip6.tun0 ファイルに次のエントリを追加します。


      6000:3333::eeee:1113  6000:6666::aaaa:1116 tsrc 2001::eeee:3333:3333 tdst 2001::aaaa:6666:6666 router up

  8. 作成した IPsec ポリシーでトンネルを保護します。


    # svcadm refresh svc:/network/ipsec/policy:default

  9. トンネル構成ファイルの内容をカーネルに読み込むには、ネットワークサービスを再起動します。


    # svcadm restart svc:/network/initial:default

  10. hme1 インタフェースの IP 転送をオンに設定します。

    1. enigma システムで、/etc/hostname6.hme1 ファイルにルーターエントリを追加します。


      2001::aaaa:6666:6666 inet6 router

    2. partym システムで、/etc/hostname6.hme1 ファイルにルーターエントリを追加します。


      2001::eeee:3333:3333 inet6 router

  11. 経路制御プロトコルによってイントラネット内のデフォルトのルートが通知されていないことを確認します。

    1. enigma システムで、private フラグを /etc/hostname6.hme0 ファイルに追加します。


      6000:6666::aaaa:1116 inet6 private

    2. partym システムで、private フラグを /etc/hostname6.hme0 ファイルに追加します。


      6000:3333::eeee:1113 inet6 private

  12. hme0 経由のデフォルトルートを手動で追加します。

    1. enigma システムで、次のルートを追加します。


      # route add -inet6 default 2001::aaaa:0:4

    2. partym システムで次のルートを追加します。


      # route add -inet6 default 2001::eeee:0:1

  13. 手順を完了するために、手順 22 に進んで経路制御プロトコルを実行します。

  14. セキュアトンネル ip6.tun0 を構成します。

    注 –

    次の手順は、Solaris 10 4/09 リリースより前のリリースを実行しているシステムでトンネルを構成するためのものです。

    1. enigma システムで、次のコマンドを入力します。


      # ifconfig ip6.tun0 inet6 plumb

# ifconfig ip6.tun0 inet6 6000:6666::aaaa:1116 6000:3333::eeee:1113 \
tsrc 2001::aaaa:6666:6666   tdst 2001::eeee:3333:3333

    2. partym システムで、次のコマンドを入力します。


      # ifconfig ip6.tun0 inet6 plumb

# ifconfig ip6.tun0 inet6 6000:3333::eeee:1113 6000:6666::aaaa:1116 \
tsrc 2001::eeee:3333:3333   tdst 2001::aaaa:6666:6666

  15. 作成した IPsec ポリシーでトンネルを保護します。


    # ipsecconf

  16. トンネル用のルーターを起動します。


    # ifconfig ip6.tun0 router up

  17. 各システムで、hme1 インタフェースの IP 転送をオンに設定します。 


    # ifconfig hme1 router

  18. 経路制御プロトコルによってイントラネット内のデフォルトのルートが通知されていないことを確認します。


    # ifconfig hme0 private

  19. hme0 経由のデフォルトルートを手動で追加します。

    デフォルトルートは、インターネットに直接アクセスできるルーターでなければなりません。

    1. enigma システムで、次のルートを追加します。


      # route add -inet6 default 2001::aaaa:0:4

    2. partym システムで次のルートを追加します。


      # route add -inet6 default 2001::eeee:0:1

  20. VPN がリブート後に開始するように、/etc/hostname6.ip6.tun0 ファイルにエントリを追加します。

    このエントリは、手順 14 で ifconfigコマンドに渡されたパラメータを複製します。

    1. enigma システムで、hostname6.ip6.tun0 ファイルに次のエントリを追加します。


      6000:6666::aaaa:1116 6000:3333::eeee:1113 \
tsrc 2001::aaaa:6666:6666  tdst 2001::eeee:3333:3333 router up

    2. partym システムでは、次のエントリを hostname6.ip6.tun0 ファイルに追加します。


      6000:3333::eeee:1113 6000:6666::aaaa:1116 \
tsrc 2001::eeee:3333:3333   tdst 2001::aaaa:6666:6666  router up

  21. 各システムで、適切なパラメータが経路制御デーモンに渡されるようにインタフェースファイルを設定します。

    1. enigma システムで、/etc/hostname6.interface ファイルを変更します。


      # cat /etc/hostname6.hme0
## enigma
6000:6666::aaaa:1116 inet6 private
      		 

      #  cat /etc/hostname6.hme1
## enigma
2001::aaaa:6666:6666 inet6 router

    2. partym システムで、/etc/hostname6.interface ファイルを変更します。


      # cat /etc/hostname6.hme0
## partym
6000:3333::eeee:1113 inet6 private
      		 

      # cat /etc/hostname6.hme1
## partym
2001::eeee:3333:3333 inet6 router

  22. 経路制御プロトコルを実行します。


    # routeadm -e ipv6-routing
# routeadm -u

    経路制御プロトコルを実行する前に経路制御プロトコルの構成が必要な場合があります。詳細は、「Oracle Solaris の経路制御プロトコル」を参照してください。手順については、「IPv6 ルーターの構成」を参照してください。

ProcedureIPv4 トランスポートモードの IPsec トンネルで VPN を保護する方法

トランスポートモードでは、外側のヘッダーによって、内側の IP パケットを保護する IPsec ポリシーが決まります。

この手順は、「IPsec で 2 つのシステム間のトラフィックを保護するには」の手順の応用です。この手順では、2 つのシステムを接続するだけでなく、これら 2 つのシステムに接続している 2 つのイントラネットを接続します。この手順における 2 つのシステムはゲートウェイとして機能します。

この手順では、「IPsec で VPN を保護する作業のためのネットワークトポロジの説明」で説明されている設定を使用します。特定のコマンドを実行する理由についての詳細は、「IPv4 トンネルモードの IPsec トンネルで VPN を保護する方法」の該当する手順を参照してください。

注 –

両方のシステムでこの手順を実行してください。

  1. システムコンソール上で、Primary Administrator の役割を引き受けるか、スーパーユーザーになります。

    Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

    注 –

    リモートログインすると、セキュリティー上重要なトラフィックが盗聴される恐れがあります。何らかの方法でリモートログインを保護していても、システムのセキュリティーがリモートログインセッションレベルに低下します。セキュリティー保護されたリモートログインには、ssh コマンドを使用してください。

  2. IPsec を構成する前に、パケットフローを制御します。

    1. IP 転送と IP 動的経路制御が無効になっていることを確認します。


      # routeadm
Configuration       Current         Current
       Option       Configuration  System State
--------------------------------------------------
IPv4 forwarding     disabled           disabled
   IPv4 routing     default (enabled)   enabled
…

      IP 転送や IP 動的経路制御が有効な場合は、次のように入力して無効にします。


      # routeadm -d ipv4-routing -d ipv4-forwarding
# routeadm -u

    2. 次のコマンドを入力して IP の厳密宛先マルチホームをオンに設定します。


      # ndd -set /dev/ip ip_strict_dst_multihoming 1
      注意 – 注意 –

      システムの起動時に、ip_strict_dst_multihoming の値はデフォルトに戻ります。変更した値を持続させる方法については、「IP のスプーフィングを防止する方法」を参照してください。

    3. 大部分のネットワークサービス、可能な場合はすべてのネットワークサービスを無効にします。

      注 –

      「制限付き」SMF プロファイルでシステムをインストールした場合、この手順は省略できます。Solaris Secure Shell 以外のネットワークサービスは無効になります。

      ネットワークサービスを無効にすると、IP パケットがシステムにダメージを与えるのを防止できます。たとえば、SNMP デーモン、telnet 接続、rlogin 接続などを最大限に活用できます。

      次のオプションのいずれかを選択します。

      • Solaris 10 11/06 以降のリリースが稼働している場合は、「制限付き」SMF プロファイルを実行します。


        # netservices limited

      • それ以外の場合は、ネットワークサービスを個別に無効にします。


        # svcadm disable network/ftp:default
# svcadm disable network/finger:default
# svcadm disable network/login:rlogin
# svcadm disable network/nfs/server:default
# svcadm disable network/rpc/rstat:default
# svcadm disable network/smtp:sendmail
# svcadm disable network/telnet:default 

    4. ほとんどのネットワークサービスが無効になっていることを確認します。

      ループバックマウントと ssh サービスが稼働していることを確認します。


      # svcs | grep network
online         Aug_02   svc:/network/loopback:default
…
online         Aug_09   svc:/network/ssh:default

  3. 2 つのシステム間に SA ペアを追加します。

    次のオプションのいずれかを選択します。

  4. IPsec ポリシーを追加します。

    /etc/inet/ipsecinit.conf ファイルを編集して、VPN 用の IPsec ポリシーを追加します。ポリシーを強化する方法については、例 20–15 を参照してください。

    1. enigma システムで、ipsecinit.conf ファイルに次のエントリを入力します。


      # LAN traffic to and from this host can bypass IPsec.
{laddr 10.16.16.6 dir both} bypass {}

# WAN traffic uses ESP with AES and SHA-1.
{tunnel ip.tun0 negotiate transport} 
 ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

    2. partym システムで、ipsecinit.conf ファイルに次のエントリを追加します。


      # LAN traffic to and from this host can bypass IPsec.
{laddr 10.1.3.3 dir both} bypass {}

# WAN traffic uses ESP with AES and SHA-1.
{tunnel ip.tun0 negotiate transport} 
 ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

  5. (省略可能) IPsec ポリシーファイルの構文を確認します。


    # ipsecconf -c -f /etc/inet/ipsecinit.conf

  6. トンネルを構成し、それを IPsec で保護する場合は、Solaris のリリースに応じて次の手順に従います。

    • Solaris 10 4/09 リリース以降では、手順 7 から手順 13 までを実行したあと、手順 22 の経路制御プロトコルを実行します。

    • Solaris 10 4/09 リリースより前のリリースを実行している場合は、手順 14 から手順 22 までを実行します。

  7. /etc/hostname.ip.tun0 ファイルで、トンネル ip.tun0 を構成します。

    1. enigma システムで、hostname.ip.tun0 ファイルに次のエントリを追加します。


      10.16.16.6 10.1.3.3 tsrc 192.168.116.16 tdst 192.168.13.213 router up

    2. partym システムで、hostname.ip.tun0 ファイルに次のように追加します。


      10.1.3.3 10.16.16.6 tsrc 192.168.13.213 tdst 192.168.116.16 router up

  8. 作成した IPsec ポリシーでトンネルを保護します。


    # svcadm refresh svc:/network/ipsec/policy:default

  9. hostname.ip.tun0 ファイルの内容をカーネルに読み込むには、ネットワークサービスを再起動します。


    # svcadm restart svc:/network/initial:default

  10. hme1 インタフェースの IP 転送をオンに設定します。

    1. enigma システムで、ルーターエントリを /etc/hostname.hme1 ファイルに追加します。


      192.168.116.16 router

    2. partym システムで、ルーターエントリを /etc/hostname.hme1 ファイルに追加します。


      192.168.13.213 router

  11. 経路制御プロトコルによってイントラネット内のデフォルトのルートが通知されていないことを確認します。

    1. enigma システムで、private フラグを /etc/hostname.hme0 ファイルに追加します。


      10.16.16.6 private

    2. partym システムで、private フラグを /etc/hostname.hme0 ファイルに追加します。


      10.1.3.3 private

  12. hme0 経由のデフォルトルートを手動で追加します。

    1. enigma システムで、次のルートを追加します。


      # route add default 192.168.116.4

    2. partym システムで次のルートを追加します。


      # route add default 192.168.13.5

  13. 手順を完了するために、手順 22 に進んで経路制御プロトコルを実行します。

  14. トンネル ip.tun0 を構成します。

    注 –

    次の手順は、Solaris 10 4/09 リリースより前のリリースを実行しているシステムでトンネルを構成するためのものです。

    ifconfig コマンドを使用してポイントツーポイントインタフェースを作成します。


    # ifconfig ip.tun0 plumb

# ifconfig ip.tun0 system1-point system2-point \
tsrc system1-taddr tdst system2-taddr

    1. enigma システムで、次のコマンドを入力します。


      # ifconfig ip.tun0 plumb

# ifconfig ip.tun0 10.16.16.6 10.1.3.3 \
tsrc 192.168.116.16 tdst 192.168.13.213

    2. partym システムで、次のコマンドを入力します。


      # ifconfig ip.tun0 plumb

# ifconfig ip.tun0 10.1.3.3 10.16.16.6  \
tsrc 192.168.13.213 tdst 192.168.116.16

  15. 作成した IPsec ポリシーでトンネルを保護します。


    # ipsecconf

  16. トンネル用のルーターを起動します。


    # ifconfig ip.tun0 router up

  17. hme1 インタフェースの IP 転送をオンに設定します。


    # ifconfig hme1 router

  18. 経路制御プロトコルによってイントラネット内のデフォルトのルートが通知されていないことを確認します。


    # ifconfig hme0 private

  19. hme0 経由のデフォルトルートを手動で追加します。

    デフォルトルートは、インターネットに直接アクセスできるルーターでなければなりません。


    # route add default router-on-hme0-subnet

    1. enigma システムで、次のルートを追加します。


      # route add default 192.168.116.4

    2. partym システムで次のルートを追加します。


      # route add default 192.168.13.5

  20. VPN がリブート後に開始するように、/etc/hostname.ip.tun0 ファイルにエントリを追加します。


    system1-point system2-point tsrc system1-taddr \
tdst system2-taddr encr_algs aes encr_auth_algs sha1 router up

    1. enigma システムで、hostname.ip.tun0 ファイルに次のエントリを追加します。


      10.16.16.6 10.1.3.3 tsrc 192.168.116.16 \
tdst 192.168.13.213 router up

    2. partym システムで、hostname.ip.tun0 ファイルに次のように追加します。


      10.1.3.3 10.16.16.6 tsrc 192.168.13.213 \
tdst 192.168.116.16 router up

  21. 適切なパラメータが経路制御デーモンに渡されるようにインタフェースファイルを設定します。

    1. enigma システムで、/etc/hostname.interface ファイルを変更します。


      # cat /etc/hostname.hme0
## enigma
10.16.16.6 private
      		 

      # cat /etc/hostname.hme1
## enigma
192.168.116.16 router

    2. partym システムで、/etc/hostname.interface ファイルを変更します。


      # cat /etc/hostname.hme0
## partym
10.1.3.3 private
      		 

      # cat /etc/hostname.hme1
## partym
192.168.13.213 router

  22. 経路制御プロトコルを実行します。


    # routeadm -e ipv4-routing
# routeadm -u
例 20–15 すべてのシステムにトランスポートモードで IPsec ポリシーを要求する

この例では、手順 4 で構成した bypass ポリシーをコメントにして、保護を強化します。このポリシーを構成した場合は、LAN 上のすべてのシステムが、ルーターと通信するために IPsec を有効にしなければなりません。


# LAN traffic must implement IPsec.
# {laddr 10.1.3.3 dir both} bypass {}

# WAN traffic uses ESP with AES and SHA-1.
{tunnel ip.tun0 negotiate transport} ipsec {encr_algs aes encr_auth_algs sha1}
例 20–16 推奨されなくなった構文を使用してトランスポートモードの IPsec トンネルを構成する

この例では、Solaris 10 7/07 システムを、Solaris 10 リリースを実行しているシステムに接続します。したがって、管理者は構成ファイルで Solaris 10 の構文を使用し、ifconfig コマンドに IPsec アルゴリズムを含めます。

管理者は、「IPv4 トランスポートモードの IPsec トンネルで VPN を保護する方法」の手順に従いますが、構文を次のように変更します。

ProcedureIPv6 トランスポートモードの IPsec トンネルで VPN を保護する方法

IPv6 ネットワークで VPN を使用するには、IPv4 ネットワークの場合と同じ手順を実行します。ただし、コマンドの構文は少し違います。特定のコマンドを実行する理由についての詳細は、「IPv4 トンネルモードの IPsec トンネルで VPN を保護する方法」の該当する手順を参照してください。

注 –

両方のシステムでこの手順を実行してください。

この手順では、次の構成パラメータを使用します。

パラメータ 

ヨーロッパ 

カリフォルニア 

システム名 

 

enigma
 

partym

システムイントラネットインタフェース 

 

hme1
 

hme1

システムインターネットインタフェース 

 

hme0
 

hme0

システムイントラネットアドレス 

 

6000:6666::aaaa:1116
 

6000:3333::eeee:1113

システムインターネットアドレス 

 

2001::aaaa:6666:6666
 

2001::eeee:3333:3333

インターネットルーターの名前 

 

router-E
 

router-C

インターネットルーターのアドレス 

 

2001::aaaa:0:4
 

2001::eeee:0:1

トンネル名 

 

ip6.tun0
 

ip6.tun0

  1. システムコンソール上で、Primary Administrator の役割を引き受けるか、スーパーユーザーになります。

    Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

    注 –

    リモートログインすると、セキュリティー上重要なトラフィックが盗聴される恐れがあります。何らかの方法でリモートログインを保護していても、システムのセキュリティーがリモートログインセッションレベルに低下します。セキュリティー保護されたリモートログインには、ssh コマンドを使用してください。

  2. IPsec を構成する前に、パケットフローを制御します。

    1. IP 転送と IP 動的経路制御が無効になっていることを確認します。


      # routeadm
Configuration       Current         Current
       Option       Configuration  System State
--------------------------------------------------
…
IPv6 forwarding     disabled          disabled
   IPv6 routing     disabled          disabled

      IP 転送や IP 動的経路制御が有効な場合は、次のように入力して無効にします。


      # routeadm -d ipv6-forwarding -d ipv6-routing
# routeadm -u

    2. 次のコマンドを入力して IP の厳密宛先マルチホームをオンに設定します。


      # ndd -set /dev/ip ip6_strict_dst_multihoming 1
      注意 – 注意 –

      システムの起動時に、ip6_strict_dst_multihoming の値はデフォルトに戻ります。変更した値を持続させる方法については、「IP のスプーフィングを防止する方法」を参照してください。

    3. ほとんどのネットワークサービスが無効になっていることを確認します。

      ループバックマウントと ssh サービスが稼働していることを確認します。


      # svcs | grep network
online         Aug_02   svc:/network/loopback:default
…
online         Aug_09   svc:/network/ssh:default

  3. 2 つのシステム間に SA ペアを追加します。

    次のオプションのいずれかを選択します。

  4. IPsec ポリシーを追加します。

    /etc/inet/ipsecinit.conf ファイルを編集して、VPN 用の IPsec ポリシーを追加します。

    1. enigma システムで、ipsecinit.conf ファイルに次のエントリを追加します。


      # IPv6 Neighbor Discovery messages bypass IPsec.
{ulp ipv6-icmp type 133-137 dir both} pass {}

# LAN traffic can bypass IPsec.
{laddr 6000:6666::aaaa:1116 dir both} bypass {}

# WAN traffic uses ESP with AES and SHA-1.
{tunnel ip6.tun0 negotiate transport} 
 ipsec {encr_algs aes encr_auth_algs sha1}

    2. partym システムで、ipsecinit.conf ファイルに次のエントリを追加します。


      # IPv6 Neighbor Discovery messages bypass IPsec.
{ulp ipv6-icmp type 133-137 dir both} pass {}

# LAN traffic can bypass IPsec.
{laddr 6000:3333::eeee:1113 dir both} bypass {}

# WAN traffic uses ESP with AES and SHA-1.
{tunnel ip6.tun0 negotiate transport} 
 ipsec {encr_algs aes encr_auth_algs sha1}

  5. (省略可能) IPsec ポリシーファイルの構文を確認します。


    # ipsecconf -c -f /etc/inet/ipsecinit.conf

  6. トンネルを構成し、それを IPsec で保護する場合は、Solaris のリリースに応じて次の手順に従います。

    • Solaris 10 4/09 リリース以降では、手順 7 から手順 13 までを実行したあと、手順 22 の経路制御プロトコルを実行します。

    • Solaris 10 4/09 リリースより前のリリースを実行している場合は、手順 14 から手順 22 までを実行します。

  7. /etc/hostname.ip6.tun0 ファイルで、トンネル ip6.tun0 を構成します。

    1. enigma システムで、hostname.ip6.tun0 ファイルに次のエントリを追加します。


      6000:6666::aaaa:1116 6000:3333::eeee:1113 tsrc 2001::aaaa:6666:6666 tdst 2001::eeee:3333:3333 router up

    2. partym システムで、hostname.ip6.tun0 ファイルに次のエントリを追加します。


      6000:3333::eeee:1113  6000:6666::aaaa:1116 tsrc 2001::eeee:3333:3333 tdst 2001::aaaa:6666:6666 router up

  8. 作成した IPsec ポリシーでトンネルを保護します。


    # svcadm refresh svc:/network/ipsec/policy:default

  9. hostname.ip6.tun0 ファイルの内容をカーネルに読み込むには、ネットワークサービスを再起動します。


    # svcadm restart svc:/network/initial:default

  10. hme1 インタフェースの IP 転送をオンに設定します。

    1. enigma システムで、/etc/hostname6.hme1 ファイルにルーターエントリを追加します。


      2001::aaaa:6666:6666 inet6 router

    2. partym システムで、/etc/hostname6.hme1 ファイルにルーターエントリを追加します。


      2001::eeee:3333:3333 inet6 router

  11. 経路制御プロトコルによってイントラネット内のデフォルトのルートが通知されていないことを確認します。

    1. enigma システムで、private フラグを /etc/hostname6.hme0 ファイルに追加します。


      6000:6666::aaaa:1116 inet6 private

    2. partym システムで、private フラグを /etc/hostname6.hme0 ファイルに追加します。


      6000:3333::eeee:1113 inet6 private

  12. hme0 経由のデフォルトルートを手動で追加します。

    1. enigma システムで、次のルートを追加します。


      # route add -inet6 default 2001::aaaa:0:4

    2. partym システムで次のルートを追加します。


      # route add -inet6 default 2001::eeee:0:1

  13. 手順を完了するために、手順 22 に進んで経路制御プロトコルを実行します。

  14. セキュアトンネル ip6.tun0 を構成します。

    注 –

    次の手順は、Solaris 10 4/09 リリースより前のリリースを実行しているシステムでトンネルを構成するためのものです。

    1. enigma システムで、次のコマンドを入力します。


      # ifconfig ip6.tun0 inet6 plumb

# ifconfig ip6.tun0 inet6 6000:6666::aaaa:1116 6000:3333::eeee:1113 \
tsrc 2001::aaaa:6666:6666   tdst 2001::eeee:3333:3333

    2. partym システムで、次のコマンドを入力します。


      # ifconfig ip6.tun0 inet6 plumb

# ifconfig ip6.tun0 inet6  6000:3333::eeee:1113  6000:6666::aaaa:1116 \
tsrc 2001::eeee:3333:3333   tdst 2001::aaaa:6666:6666

  15. 作成した IPsec ポリシーでトンネルを保護します。


    # ipsecconf

  16. トンネル用のルーターを起動します。


    # ifconfig ip6.tun0 router up

  17. hme1 インタフェースの IP 転送をオンに設定します。 


    # ifconfig hme1 router

  18. 経路制御プロトコルによってイントラネット内のデフォルトのルートが通知されていないことを確認します。


    # ifconfig hme0 private

  19. 各システムで、hme0 経由のデフォルトルートを手動で追加します。

    デフォルトルートは、インターネットに直接アクセスできるルーターでなければなりません。

    1. enigma システムで、次のルートを追加します。


      # route add -inet6 default 2001::aaaa:0:4

    2. partym システムで次のルートを追加します。


      # route add -inet6 default 2001::eeee:0:1

  20. 各システムで、VPN がリブート後に開始するように、/etc/hostname6.ip6.tun0 ファイルにエントリを追加します。

    このエントリは、手順 14 で ifconfigコマンドに渡されたパラメータを複製します。

    1. enigma システムで、hostname6.ip6.tun0 ファイルに次のエントリを追加します。


      6000:6666::aaaa:1116  6000:3333::eeee:1113 \
tsrc 2001::aaaa:6666:6666   tdst 2001::eeee:3333:3333  router up

    2. partym システムでは、次のエントリを hostname6.ip6.tun0 ファイルに追加します。


      6000:3333::eeee:1113  6000:6666::aaaa:1116 \
tsrc 2001::eeee:3333:3333   tdst 2001::aaaa:6666:6666  router up

  21. 適切なパラメータが経路制御デーモンに渡されるようにインタフェースファイルを設定します。

    1. enigma システムで、/etc/hostname6.interface ファイルを変更します。


      # cat /etc/hostname6.hme0
## enigma
6000:6666::aaaa:1116 inet6 private
      		 

      #  cat /etc/hostname6.hme1
## enigma
2001::aaaa:6666:6666 inet6 router

    2. partym システムで、/etc/hostname6.interface ファイルを変更します。


      # cat /etc/hostname6.hme0
## partym
6000:3333::eeee:1113 inet6 private
      		 

      # cat /etc/hostname6.hme1
## 
partym2001::eeee:3333:3333 inet6 router

  22. 経路制御プロトコルを実行します。


    # routeadm -e ipv6-routing
# routeadm -u
例 20–17 推奨されなくなった構文を使用して IPv6 トランスポートモードの IPsec トンネルを構成する

この例では、Solaris 10 7/07 システムを、Solaris 10 リリースを実行しているシステムに接続します。したがって、管理者は構成ファイルで Solaris 10 の構文を使用し、ifconfig コマンドに IPsec アルゴリズムを含めます。

管理者は、「IPv6 トランスポートモードの IPsec トンネルで VPN を保護する方法」の手順に従いますが、構文を次のように変更します。

ProcedureIP のスプーフィングを防止する方法

システムがパケットの復号化を試みずに別のインタフェースに転送することを防止するには、IP のスプーフィングをチェックする必要があります。その方法の 1 つは、ndd コマンドを使用して IP 厳密宛先マルチホームのパラメータを設定することです。SMF マニフェストでこのパラメータが設定されている場合、システムのリブート時にこのパラメータが設定されます。

注 –

両方のシステムでこの手順を実行してください。

  1. システムコンソール上で、Primary Administrator の役割を引き受けるか、スーパーユーザーになります。

    Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

  2. IP のスプーフィングをチェックするように、サイト固有の SMF マニフェストを作成します。

    次のサンプルスクリプト /var/svc/manifest/site/spoof_check.xml を使用します。

    <?xml version="1.0"?>
<!DOCTYPE service_bundle SYSTEM "/usr/share/lib/xml/dtd/service_bundle.dtd.1">

<service_bundle type='manifest' name='Custom:ip_spoof_checking'>

<!--    This is a custom smf(5) manifest for this system. Place this
        file in /var/svc/manifest/site, the directory for local
        system customizations. The exec method uses an unstable
        interface to provide a degree of protection against IP
        spoofing attacks when this system is acting as a router.

        IP spoof protection can also be achieved by using ipfilter(5).
        If ipfilter is configured, this service can be disabled.

        Note: Unstable interfaces might be removed in later
        releases.  See attributes(5).
-->

<service
        name='site/ip_spoofcheck'
        type='service'
        version='1'>

        <create_default_instance enabled='false' />
        <single_instance />

        <!--    Don't enable spoof protection until the
                network is up.
        -->
        <dependency
                name='basic_network'
                grouping='require_all'
                restart_on='none'
                type='service'>
        <service_fmri value='svc:/milestone/network' />
        </dependency>

        <exec_method
                type='method'
                name='start'
                exec='/usr/sbin/ndd -set /dev/ip ip_strict_dst_multihoming 1'
<!--    
     For an IPv6 network, use the IPv6 version of this command, as in:
                exec='/usr/sbin/ndd -set /dev/ip ip6_strict_dst_multihoming 1
-->
                timeout_seconds='60'
        />

        <exec_method
                type='method'
                name='stop'
                exec=':true'
                timeout_seconds='3'
        />

        <property_group name='startd' type='framework'>
                <propval
                        name='duration'
                        type='astring'
                        value='transient'
                />
        </property_group>

        <stability value='Unstable' />

</service>
</service_bundle>

  3. このマニフェストを SMF リポジトリにインポートします。


    # svccfg import /var/svc/manifest/site/spoof_check.xml

  4. ip_spoofcheck サービスを有効にします。

    マニフェストで定義されている名前 /site/ip_spoofcheck を使用します。


    # svcadm enable /site/ip_spoofcheck

  5. ip_spoofcheck サービスがオンラインになっていることを確認します。


    # svcs /site/ip_spoofcheck

第 21 章 IP セキュリティーアーキテクチャー (リファレンス)

この章では、次の内容について説明します。

使用しているネットワークに IPsec を実装する方法については、第 20 章IPsec の構成 (手順)を参照してください。IPsec の概要については、第 19 章IP セキュリティーアーキテクチャー (概要)を参照してください。

IPsec サービス管理機能

サービス管理機能 (SMF) は、次の IPsec サービスを提供します。

SMF の詳細については、『Solaris のシステム管理 (基本編)』の第 18 章「サービスの管理 (概要)」を参照してください。smf(5)、svcadm(1M)、および svccfg(1M) のマニュアルページも参照してください。

ipsecconf コマンド

ホストの IPsec ポリシーを構成するには、ipsecconf コマンドを使用します。このコマンドを実行してポリシーを設定すると、IPsec ポリシーのエントリがカーネル内に作成されます。システムは、これらのエントリを使用して、インバウンドおよびアウトバウンドの IP データグラムすべてがポリシーに沿っているかどうかを検査します。転送されたデータグラムは、このコマンドで追加されたポリシー検査の対象外になります。また、ipsecconf コマンドはセキュリティーポリシーデータベース (SPD) を構成します。

ipsecconf コマンドを呼び出すには、スーパーユーザーになるか、同等の役割を引き受ける必要があります。このコマンドは、両方向のトラフィックを保護するエントリを受け入れます。このコマンドは、片方向だけのトラフィックを保護するエントリも受け入れます。

ローカルアドレスとリモートアドレスというパターンのポリシーエントリは、1 つのポリシーエントリで両方向のトラフィックを保護します。たとえば、指定されたホストに対して方向が指定されていない場合、laddr host1 と raddr host2 というパターンを含むエントリは、両方向のトラフィックを保護します。そのため、各ホストにポリシーエントリを 1 つだけ設定すれば済みます。

ソースアドレスから宛先アドレスへというパターンのポリシーエントリは、1 方向のみのトラフィックを保護します。たとえば、saddr host1 daddr host2 というパターンのポリシーエントリは、インバウンドかアウトバウンドのどちらかのトラフィックのみを保護します。両方向ともは保護しません。したがって、両方向のトラフィックを保護するには、saddr host2 daddr host1 とという先ほどとは逆方向のエントリを ipsecconf コマンドに渡す必要があります。

マシンがブートするときに IPsec ポリシーが確実にアクティブになるようにするには、IPsec ポリシーファイル /etc/inet/ipsecinit.conf を作成します。このファイルは、ネットワークサービスが起動するときに読み取られます。IPsec ポリシーファイルを作成する方法については、「IPsec によるトラフィックの保護 (作業マップ)」を参照してください。

Solaris 10 4/09 リリース以降では、-c オプションを指定して ipsecconf コマンドを実行すると、引数として指定した IPsec ポリシーファイルの構文がチェックされます。

ipsecconf コマンドで追加されたポリシーエントリには持続性がなく、システムのリブート時に失われます。システムの起動時に IPsec ポリシーが確実にアクティブになるようにするには、/etc/inet/ipsecinit.conf ファイルにポリシーエントリを追加します。現在のリリースでは、policy サービスを更新するか有効にします。Solaris 10 4/09 リリースより前のリリースでは、リブートするか ipsecconf コマンドを使用します。例については、「IPsec によるトラフィックの保護 (作業マップ)」を参照してください。

ipsecinit.conf ファイル

Solaris オペレーティングシステム (Solaris OS) を起動したときに IPsec セキュリティーポリシーを呼び出すには、特定の IPsec ポリシーエントリを利用して構成ファイルを作成し IPsec を初期化します。このファイルのデフォルトの名前は /etc/inet/ipsecinit.conf です。ポリシーエントリとその形式の詳細については、ipsecconf(1M) のマニュアルページを参照してください。ポリシーの構成後、ipsecconf コマンドを使用すると、既存の構成を表示または変更できます。Solaris 10 4/09 リリース以降では、policy サービスを更新することによって、既存の構成を変更します。

サンプルの ipsecinit.conf ファイル

Solaris ソフトウェアには、サンプルの IPsec ポリシーファイル ipsecinit.sample があります。このファイルをテンプレートとして独自の ipsecinit.conf ファイルを作成できます。ipsecinit.sample ファイルには、次のエントリが含まれています。


#
# For example,
#
#	 {rport 23} ipsec {encr_algs des encr_auth_algs md5}
#
# will protect the telnet traffic originating from the host with ESP using
# DES and MD5. Also:
#
#	 {raddr 10.5.5.0/24} ipsec {auth_algs any}
#
# will protect traffic to or from the 10.5.5.0 subnet with AH 
# using any available algorithm.
#
#
# To do basic filtering, a drop rule may be used. For example:
#
#	 {lport 23 dir in} drop {}
#	 {lport 23 dir out} drop {}
# will disallow any remote system from telnetting in.
#
# If you are using IPv6, it may be useful to bypass neighbor discovery
# to allow in.iked to work properly with on-link neighbors. To do that,
# add the following lines:
#
#        {ulp ipv6-icmp type 133-137 dir both } pass { }
#
# This will allow neighbor discovery to work normally.

ipsecinit.conf と ipsecconf のセキュリティーについて

ipsecinit.conf ファイルをネットワーク経由で転送するときには、特に注意する必要があります。ネットワークマウントファイルが読み取られている場合、不正に読み取られる可能性があります。たとえば、NFS マウントされたファイルシステムから /etc/inet/ipsecinit.conf ファイルをアクセスまたはコピーしようとした場合、このファイルに含まれるポリシーは不正に変更される可能性があります。

IPsec ポリシーは通信を開始する前に設定してください。新しいポリシーエントリを追加すると既存の接続が影響を受けることがあるためです。同じ理由から、通信の途中ではポリシーを変更しないでください。

特に、SCTP ソケット、TCP ソケット、または UDP ソケットに対して、connect() または accept() 関数呼び出しが行われた場合、これらのソケットの IPsec ポリシーは変更できません。ポリシーの変更ができないソケットを、「ラッチされたソケット」と呼びます。新しいポリシーエントリは、すでにラッチされたソケットを保護しません。詳細については、connect(3SOCKET) と accept(3SOCKET) のマニュアルページを参照してください。

ネーミングシステムを保護してください。次の 2 つの条件に該当する場合、そのホスト名は信頼できません。

セキュリティーの弱点の多くは、実際のツールではなく、ツールの使用方法にあります。ipsecconf コマンドを使用するときは注意が必要です。各操作の最も安全なモードでコンソールを使用するか、ハード接続の TTY を使用してください。

ipsecalgs コマンド

Solaris 暗号化フレームワークは、認証と暗号化のアルゴリズムを IPsec に提供します。ipsecalgs コマンドを使用すると、各 IPsec プロトコルでサポートされているアルゴリズムを一覧表示できます。ipsecalgs の構成は /etc/inet/ipsecalgs ファイルに保存されます。通常、このファイルを変更する必要はありません。ただし、このファイルを変更する必要がある場合は、ipsecalgs コマンドを使用します。決して直接には編集しないでください。現在のリリースでは、サポートされるアルゴリズムは、システムの起動時に svc:/network/ipsec/ipsecalgs:default サービスによってカーネルと同期されます。

有効な IPsec プロトコルおよびアルゴリズムは、RFC 2407 に記載されている ISAKMP 解釈ドメイン (DOI) によって記述されます。一般的な意味では、DOI は、データ形式、ネットワークトラフィック交換タイプ、およびセキュリティー関連情報の命名規約を定義します。セキュリティー関連情報の例としては、セキュリティーポリシーや、暗号化アルゴリズム、暗号化モードなどがあります。

特に、ISAKMP DOI は、有効な IPsec アルゴリズム PROTO_IPSEC_AH とそのプロトコルの PROTO_IPSEC_ESP の命名規約や番号付け規約を定義します。1 つのアルゴリズムは 1 つのプロトコルだけに関連します。このような ISAKMP DOI 定義は、/etc/inet/ipsecalgs ファイルにあります。アルゴリズム番号とプロトコル番号は、Internet Assigned Numbers Authority (IANA) によって定義されます。ipsecalgs コマンドは、IPsec アルゴリズムのリストを拡張します。

アルゴリズムの詳細については、ipsecalgs(1M) のマニュアルページを参照してください。Solaris 暗号化フレームワークの詳細については、『Solaris のシステム管理 (セキュリティサービス)』の第 13 章「Solaris の暗号化フレームワーク (概要)」を参照してください。

IPsec のセキュリティーアソシエーションデータベース

IPsec セキュリティーサービスの鍵情報は、セキュリティーアソシエーションデータベース (SADB) に保存されます。セキュリティーアソシエーション (SA) は、インバウンドパケットとアウトバウンドパケットを保護します。SADB の保守は、1 つまたは複数の (そしておそらくは協力する) ユーザープロセスがメッセージを特殊なソケット経由で送信することによって行われます。SADB を保守するこの方法は、 route(7P) のマニュアルページで説明している方法に類似しています。SADB にアクセスできるのは、スーパーユーザーか、同等の役割を引き受けたユーザーだけです。

in.iked デーモンと ipseckey コマンドは PF_KEY ソケットインタフェースを使用して SADB を保守します。SADB が要求やメッセージを処理する方法の詳細については、pf_key(7P) のマニュアルページを参照してください。

IPsec キー生成ユーティリティー

IKE プロトコルは、IPv4 アドレスおよび IPv6 アドレスのキーを自動的に管理します。IKEを設定する方法については、第 23 章IKE の設定 (手順)を参照してください。手動キーユーティリティーは ipseckey コマンドです (ipseckey(1M) のマニュアルページを参照)。

セキュリティーアソシエーションデータベース (SADB) を手動で生成するには、ipseckey コマンドを使用します。通常、手動での SA 生成は、何らかの理由で IKE を使用できない場合に使用します。ただし、SPI の値が一意であれば、手動での SA 生成と IKE を同時に使用することができます。

ipseckey コマンドを使用すると、システムで認識されているすべての SA を表示できます。このような SA には、手動または IKE によって鍵が追加されています。Solaris 10 4/09 リリース以降では、-c オプションを指定して ipseckey コマンドを実行すると、引数として指定した鍵ファイルの構文がチェックされます。

ipseckey コマンドで追加された IPsec SA には持続性がなく、システムのリブート時に失われます。現在のリリースでは、手動で追加した SA をシステムの起動時に有効にするには、/etc/inet/secret/ipseckeys ファイルにエントリを追加してから、svc:/network/ipsec/manual-key:default サービスを有効にします。手順については、「IPsec セキュリティーアソシエーションを手動で作成する方法」を参照してください。

ipseckey コマンドには少数の一般オプションしかありませんが、多くのコマンド言語をサポートしています。マニュアルキー操作に固有のプログラムインタフェースで要求を配信するように指定することもできます。詳細については、pf_key(7P) のマニュアルページを参照してください。

ipseckey におけるセキュリティーについて

ipseckey コマンドを使用すると、スーパーユーザーまたは Network Security または Network IPsec Management 権利プロファイルの役割を引き受けたユーザーは、暗号鍵に関する機密情報を入力できます。場合によっては、不正にこの情報にアクセスして IPsec トラフィックのセキュリティーを損なうことも可能です。

鍵情報を扱う場合および ipseckey コマンドを使用する場合には、次のことに注意してください。

セキュリティーの弱点の多くは、実際のツールではなく、ツールの使用方法にあります。ipseckey コマンドを使用するときには注意が必要です。各操作の最も安全なモードでコンソールを使用するか、ハード接続の TTY を使用してください。

その他のユーティリティーに対する IPsec 拡張機能

ifconfig コマンドには、トンネルインタフェースで IPsec ポリシーを管理するオプションがあります。snoop コマンドは、AH ヘッダーと ESP ヘッダーを構文解析できます。

ifconfig コマンドと IPsec

Solaris 10、Solaris 10 7/05、Solaris 10 1/06、および Solaris 10 11/06 リリースの場合: IPsec をサポートするため、ifconfig では次のオプションを利用できます。Solaris 10 7/07 リリースでは、これらのセキュリティーオプションは ipsecconf コマンドで処理されます。

すべての IPsec セキュリティーオプションは 1 度の呼び出しでトンネルに指定する必要があります。たとえば、ESP だけを使ってトラフィックを保護する場合、次のように両方のセキュリティーオプションを指定して、トンネル ip.tun0 を設定します。


# ifconfig ip.tun0 encr_algs aes encr_auth_algs md5

同様に、ipsecinit.conf エントリは、次のように 1 度に両方のセキュリティーオプションを指定して、トンネルを構成します。


# WAN traffic uses ESP with AES and MD5.
   {} ipsec {encr_algs aes encr_auth_algs md5}

auth_algsセキュリティーオプション

このオプションは、指定した認証アルゴリズムで、トンネルの IPsec AH を有効にできます。auth_algs オプションの書式は次のとおりです。


auth_algs authentication-algorithm

アルゴリズムには、番号またはアルゴリズム名を指定できます。特定のアルゴリズムが指定されないようにするパラメータ any も使用できます。トンネルセキュリティーを無効にするには、次のオプションを指定します。


auth_algs none

利用できる認証アルゴリズムのリストについては、ipsecalgs コマンドを実行してください。

注 –

auth_algs オプションは NAT-Traversal と一緒には機能しません。詳細は、「IPsec と NAT 越え」を参照してください。

encr_auth_algs セキュリティーオプション

このオプションは、指定した認証アルゴリズムで、トンネルの IPsec ESP を有効にできます。encr_auth_algs オプションの書式は次のとおりです。


encr_auth_algs authentication-algorithm

アルゴリズムには、番号またはアルゴリズム名を指定できます。特定のアルゴリズムが指定されないようにするパラメータ any も使用できます。ESP 暗号化アルゴリズムを指定し、認証アルゴリズムを指定しない場合、ESP 認証アルゴリズム値はデフォルトのパラメータ any になります。

利用できる認証アルゴリズムのリストについては、ipsecalgs コマンドを実行してください。

encr_algs セキュリティーオプション

このオプションは、指定した暗号化アルゴリズムで、トンネルの IPsec ESP を有効にできます。encr_algs オプションの書式は次のとおりです。


encr_algs encryption-algorithm

このアルゴリズムの場合、番号またはアルゴリズム名を指定できます。トンネルセキュリティーを無効にするには、次のオプションを指定します。


encr_algs none

ESP 認証アルゴリズムを指定し、暗号化アルゴリズムを指定しない場合、ESP 暗号化アルゴリズム値はデフォルトのパラメータ null になります。

利用できる暗号化アルゴリズムのリストについては、ipsecalgs コマンドを実行してください。

snoop コマンドと IPsec

snoop コマンドは、AH ヘッダーと ESP ヘッダーを構文解析できます。ESP はそのデータを暗号化するため、ESP で暗号化および保護されたヘッダーは snoop コマンドでは読み取ることができません。しかし、AH はデータを暗号化しません。したがって、AH で保護されたトラフィックは snoop コマンドで読み取ることができます。このコマンドに -V オプションを指定すると、いつ AH がパケットに使用されているかを表示できます。詳細は、snoop(1m) のマニュアルページを参照してください。

保護されたパケットに snoop コマンドを実行した場合の詳細な出力については、「IPsec によってパケットが保護されていることを確認する方法」を参照してください。

第 22 章 インターネットキー交換 (概要)

インターネットキー交換 (Internet Key Exchange、IKE) は、Ipsec の鍵管理を自動化します。IKE について説明するこの章の内容は次のとおりです。

IKE を実装する手順については、第 23 章IKE の設定 (手順)を参照してください。参照情報については、第 24 章インターネットキー交換 (リファレンス)を参照してください。IPsec については、第 19 章IP セキュリティーアーキテクチャー (概要)を参照してください。

IKE の新機能

Solaris 10 4/09: このリリース以降、サービス管理機能 (SMF) は IKE をサービスとして管理します。デフォルトでは、svc:/network/ipsec/ike:default サービスは無効になっています。また、このリリースでは、IPsec と IKE を管理するための Network IPsec Management 権利プロファイルが用意されています。

Solaris 10 7/07: このリリース以降では、IKE で AES アルゴリズムを使用でき、IKE を大域ゾーンで構成して非大域ゾーンで使用できます。

IKE による鍵管理

IPsec セキュリティーアソシエーション (SA) の鍵情報を管理することを「鍵管理」といいます。自動鍵管理では、キーの作成、認証、および交換にセキュリティー保護された通信チャネルを要求します。Solaris オペレーティングシステム では、Internet Key Exchange (IKE) を使って鍵管理を自動化します。IKE を使用すれば、セキュリティー保護されたチャネルを大量のトラフィックに割り当てるために容易にスケーリングできます。IPv4 および IPv6 パケットの IPsec SAでは、IKE の利点を生かすことができます。

Sun Crypto Accelerator 1000 ボード、Sun Crypto Accelerator 4000 ボード、または Sun Crypto Accelerator 6000 ボードを搭載したシステムで IKE を使用する場合には、公開鍵の操作はこのボードで行われます。公開鍵の操作のためにオペレーティングシステムのリソースが使用されることはありません。Sun Crypto Accelerator 4000 ボードまたは Sun Crypto Accelerator 6000 ボードを搭載したシステムで IKE を使用する場合には、証明書、公開鍵、および非公開鍵はこのボードに格納されます。鍵の格納先をシステム以外の場所にすることで、保護機能が強化されます。

IKE のキーネゴシエーション

IKE デーモン in.iked は、機密性の高い方法で、SA の鍵情報をネゴシエートし、認証します。また、Solaris オペレーティングシステム によって提供される内部機能からキーのランダムシードを使用します。IKE は、PFS (Perfect Forward Secrecy) をサポートしています。PFS では、データ伝送を保護するキーを使用しないで追加キーを取得し、データ伝送のキーの作成に使用するシードを再利用しません。in.iked(1M) のマニュアルページを参照してください。

IKE デーモンによってリモートシステムの公開暗号鍵が検出されると、ローカルシステムではその鍵を使用できるようになります。ローカルシステムは、リモートシステムの公開鍵を使用してメッセージを暗号化します。メッセージを読み取れるのは、このリモートシステムだけです。IKE デーモンでは、そのジョブを「交換」と呼ばれる 2 つのフェーズで実行します。

IKE のキー用語について

次の表は、キーネゴシエーションで使用される用語と、一般的に使われるその略語、各用語の定義と使用についてまとめたものです。

表 22–1 キーネゴシエーションの用語、略語、使用

キーネゴシエーションの用語 

略語 

定義と使用 

キー交換 

 

非対称暗号化アルゴリズムのキーを生成する処理。主な手法には RSA プロトコルと Diffie-Hellman プロトコルがあります。 

Diffie-Hellman プロトコル 

DH 

キー生成とキー認証に関るキー交換プロトコル。しばしば「認証されたキー交換」と呼ばれます。

RSA プロトコル 

RSA 

キー生成とキー転送に関るキー交換プロトコル。このプロトコル名は、作成者の Rivest、Shamir、Adleman の三氏に因んでいます。 

Perfect Forward Secrecy

PFS 

認証されたキー交換だけに適用されます。PFS では、キーの長期的な機密情報が、以前の通信で交換されたキーの機密性を損なうことがありません。  

PFS では、データ伝送を保護するために使用されるキーが、追加のキーを導き出すために使用されることはありません。さらに、データ伝送を保護するために使用されるキーのソースが、追加のキーを導き出すために使用されることはありません。 

Oakley 方式 

 

フェーズ 2 のキーを安全な方法で確立する 1 つの手法。このプロトコルは、キー交換の Diffie-Hellman 方式に似ています。Diffie-Hellman と同じように、Oakley グループキー交換では、キー生成とキー認証が行われます。Oakley 方式は PFS のネゴシエーションに使用されます。 

IKE フェーズ 1 交換

フェーズ 1 交換は、「メインモード」といわれているものです。フェーズ 1 交換では、IKE は公開鍵暗号方式を使用して、ピア IKE エンティティーと IKE 自体を認証します。その結果がインターネットセキュリティーアソシエーションと鍵管理プロトコル (ISAKMP) セキュリティーアソシエーション (SA) で、IKE で IP データグラムの鍵情報のネゴシエーションを行うためのセキュリティー保護されたチャネルとなります。IPsec SA とは異なり、ISAKMP SA は双方向であるため、1 つの SA だけ必要です。

IKE がフェーズ 1 交換で鍵情報をネゴシエートする方法は構成可能です。IKE では、/etc/inet/ike/config ファイルから設定情報を読み取ります。次の設定情報があります。

認証方式には、事前共有鍵と公開鍵証明書の 2 つがあります。公開鍵証明書は自己署名付きであっても、公開鍵インフラ (PKI) 組織の 認証局 (CA) が発行したものであってもかまいません。この組織には、Trusted、Entrust、GeoTrust、RSA Security、Verisign などがあります。

IKE フェーズ 2 交換

フェーズ 2 交換は「クイックモード」といいます。フェーズ 2 交換では、IKE は IKE デーモンを実行するシステム間の IPsec SA を作成および管理します。また、フェーズ 1 交換で作成したセキュリティー保護されたチャネルを使用して、鍵情報の伝送を保護します。IKE デーモンは、/dev/random デバイスを使用して乱数発生関数からキーを作成します。また、IKE デーモンは、キーを一定の割合 (構成可能) で更新します。この鍵情報は、IPsec ポリシーの構成ファイル ipsecinit.conf に指定されているアルゴリズムによって使用されます。

IKE 構成の選択

/etc/inet/ike/config 構成ファイルには、IKE ポリシーのエントリが含まれています。2 つの IKE デーモンを相互に認証するためには、これらのエントリが有効でなければなりません。さらに、鍵情報も必要です。構成ファイルのエントリは、フェーズ 1 交換を認証するための鍵情報の使用方法を決定します。選択肢は、事前共有鍵か公開鍵証明書のどちらかです。

エントリ auth_method preshared は、事前共有鍵が使用されることを示します。auth_method の値が preshared 以外の場合には、公開鍵証明書が使用されることを示します。公開鍵証明書は自己署名付きにするか、PKI 組織から発行できます。詳細は、ike.config(4) のマニュアルページを参照してください。

IKE と事前共有鍵

事前共有鍵は、管理者によって 1 つのシステムで作成され、そのあと、リモートシステムの管理者によって別帯域で共有されます。管理者は、大きなランダム鍵を作成すること、そのファイルと別帯域での伝送の保護に十分注意する必要があります。鍵は、各システムの /etc/inet/secret/ike.preshared ファイルに保存されます。IPsec の場合は ipseckeys ファイルですが、IKE の場合は ike.preshared ファイルとなります。ike.preshared ファイルにある鍵に何らかの問題があると、その鍵から導出されるすべての鍵に問題が発生します。

あるシステムの事前共有鍵は、そのリモートシステムの鍵と同一である必要があります。これらの鍵は、特定の IP アドレスに関連付けられています。あるシステムの管理者が通信先のシステムを制御する場合、これらの鍵は最も安全です。詳細は、ike.preshared(4) のマニュアルページを参照してください。

IKE と公開鍵証明書

公開鍵証明書を使用すると、通信するシステムが秘密鍵情報を帯域外で共有する必要がなくなります。公開鍵では、鍵の認証とネゴシエーションに Diffie-Hellman プロトコル (DH) を使用します。公開鍵証明書には、2 つの方法があります。公開鍵証明書は、自己署名付きにすることも、認証局 (CA) が認証することもできます。

自己署名付き公開鍵証明書は、自ら (管理者) が作成します。ikecert certlocal -ks コマンドを実行して、システムの公開鍵と非公開鍵のペアの非公開部分を作成します。そのあと、管理者は、リモートシステムから X.509 形式で自己署名付き証明書の出力を取得します。リモートシステムの証明書は、鍵のペアの公開部分の ikecert certdb コマンドに入力されます。自己署名付き証明書は、通信するシステムの /etc/inet/ike/publickeys ディレクトリに保存されます。証明書をシステムに接続されているハードウェアに保存したい場合は、-T オプションを指定します。

自己署名付き証明書は、事前共有鍵と CA 間の中間ポイントになります。事前共有鍵とは異なり、自己署名付き証明書は移動体システムまたは再番号付け可能なシステムで使用できます。固定番号を使用しないで、システムの証明書に自己署名するには、DNS ( www.example.org) または email (root@domain.org) の代替名を使用します。

公開鍵は、PKI または CA 組織で配信できます。公開鍵とそれに関連する CA は、/etc/inet/ike/publickeys ディレクトリに格納されます。証明書をシステムに接続されているハードウェアに保存したい場合は、-T オプションを指定します。また、ベンダーは証明書失効リスト (CRL) も発行します。管理者は鍵と CA を格納するだけでなく、CRL を /etc/inet/ike/crls ディレクトリに格納する責任があります。

CA には、サイトの管理者ではなく、外部の機関によって認証されるといった特長があります。その点では、CA は公証された証明書となります。自己署名付き証明書と同様に、CA は移動体システムまたは再番号付け可能なシステムで使用できます。その一方、自己署名付き証明書とは異なり、CA は通信する多くのシステムを保護するために容易にスケーリングできます。

IKE とアクセラレータハードウェア

IKE アルゴリズムは、特にフェーズ 1 交換において大量の処理を必要とします。大量の交換処理を行うシステムでは、Sun Crypto Accelerator 1000 ボードを使って公開鍵の操作を処理できます。フェーズ 1 の大量の処理には、Sun Crypto Accelerator 6000 ボードおよび Sun Crypto Accelerator 4000 ボードを使用することもできます。

IKE の負荷を高速化ボードに移すために IKE をどのように構成するかについては、「Sun Crypto Accelerator 1000 ボードを検出するように IKE を設定する方法」を参照してください。キーを格納する方法については、「Sun Crypto Accelerator 4000 ボードを検出するように IKE を設定する方法」と cryptoadm(1M) のマニュアルページを参照してください。

IKE とハードウェアストレージ

公開鍵証明書、非公開鍵、公開鍵は、Sun Crypto Accelerator 6000 または Sun Crypto Accelerator 4000 ボードに格納できます。RSA 暗号化の場合、Sun Crypto Accelerator 4000 ボードは最大で 2048 ビットをサポートします。DSA 暗号化の場合、このボードは最大で 1024 ビットをサポートします。Sun Crypto Accelerator 6000 ボードは、SHA-512 および ECC アルゴリズムをサポートします。

ボードにアクセスするように IKE を構成する方法については、「Sun Crypto Accelerator 1000 ボードを検出するように IKE を設定する方法」を参照してください。ボードに証明書や公開鍵を追加する方法については、「ハードウェア上で公開鍵証明書を生成、格納する方法」を参照してください。

IKE ユーティリティーおよび IKE ファイル

次の表は、IKE ポリシーの構成ファイルや、IKE キーの格納場所、IKE を実装する各種のコマンドとサービスについてまとめたものです。サービスの詳細については、『Solaris のシステム管理 (基本編)』の第 18 章「サービスの管理 (概要)」を参照してください。

表 22–2 IKE 構成ファイル、キーの格納場所、コマンド、サービス

ファイル、場所、コマンド、またはサービス 

説明 

詳細 

svc:/network/ipsec/ike

現在のリリースでは、IKE を管理する SMF。

smf(5)

/usr/lib/inet/in.iked デーモン

インターネットキー交換 (IKE) デーモン。自動鍵管理を有効にします。現在のリリースでは、ike サービスがこのデーモンを有効にします。これより前のリリースでは、in.iked コマンドを使用します。

in.iked(1M)

/usr/sbin/ikeadm コマンド

IKE ポリシーの表示および変更用 IKE 管理コマンド。

ikeadm(1M)

/usr/sbin/ikecert コマンド

公開鍵証明書が格納されているローカルデータベースを操作する証明書データベース管理コマンド。データベースも接続された Sun Crypto Accelerator 4000 ボードに格納できます。

ikecert(1M)

/etc/inet/ike/config ファイル

/etc/inet ディレクトリにある、デフォルトの IKE ポリシー構成ファイル。インバウンド IKE 要求のマッチングとアウトバウンド IKE 要求の準備に関するサイトの規則が含まれています。

現在のリリースでは、このファイルが存在する場合、ike サービスが有効になると in.iked デーモンが起動します。このファイルの場所は svccfg コマンドで変更することができます。

ike.config(4)

ike.preshared ファイル

/etc/inet/secret ディレクトリにある事前共有鍵ファイル。フェーズ 1 交換での認証の秘密鍵情報が含まれます。事前共有鍵を使って IKE を構成するときに使用されます。

ike.preshared(4)

ike.privatekeys ディレクトリ

/etc/inet/secret ディレクトリにある非公開鍵ディレクトリ。公開鍵と非公開鍵のペアの非公開部分が含まれています。

ikecert(1M)

publickeys ディレクトリ

/etc/inet/ike ディレクトリ内のディレクトリ。公開鍵と証明書ファイルが格納されています。公開鍵と非公開鍵のペアの公開部分が含まれています。

ikecert(1M)

crls ディレクトリ

/etc/inet/ike ディレクトリ内のディレクトリ。公開鍵や証明書ファイルの失効リストが格納されています。

ikecert(1M)

Sun Crypto Accelerator 1000 ボード 

オペレーティングシステムの処理を少なくすることで公開鍵操作を高速化するハードウェア。 

ikecert(1M)

Sun Crypto Accelerator 4000 ボード 

オペレーティングシステムの処理を少なくすることで公開鍵操作を高速化するハードウェア。公開鍵、非公開鍵、および公開鍵証明書も格納します。 

ikecert(1M)

Solaris 10 リリースにおける IKE の変更

Solaris 9 リリース以降、IKE に次の機能が追加されています。

第 23 章 IKE の設定 (手順)

この章では、使用するシステムにあわせて Internet Key Exchange (IKE) を設定する方法について説明します。IKE の設定が完了すると、そのネットワークにおける IPsec の鍵情報が自動的に生成されます。この章では、次の内容について説明します。

IKE の概要については、第 22 章インターネットキー交換 (概要)を参照してください。IKE の参照情報については、第 24 章インターネットキー交換 (リファレンス)を参照してください。詳細な手順については、ikeadm(1M)、ikecert(1M)、および ike.config(4) のマニュアルページで使用例のセクションを参照してください。

IKE の設定 (作業マップ)

IKE を認証するには、事前共有鍵、自己署名付き証明書、および認証局 (CA) の証明書を使用できます。規則として、保護しようとしているエンドポイントには、特定の IKE 認証方法を関連付けます。したがって、1 つのシステムに 1 つまたはすべての IKE 認証方法を使用できます。PKCS #11 ライブラリへのポインタによって、証明書は、接続されたハードウェアアクセラレータを使用できます。

IKE を設定したあと、IKE 設定を使用する IPsec 作業を実行します。次の表に、特定の IKE 設定に注目した作業マップを示します。

タスク 

説明 

説明 

事前共有鍵で IKE を設定します 

2 つのシステムに秘密鍵を共有させることにより、その通信を保護します。 

「事前共有鍵による IKE の設定 (作業マップ)」

公開鍵証明書で IKE の設定します 

公開鍵証明書を使って通信を保護します。証明書は、自己署名付き、または PKI 機関の保証付きです。 

「公開鍵証明書による IKE の設定 (作業マップ)」

NAT 境界を越えます 

IPsec と IKE を設定して、移動体システムと通信します 

「移動体システム用の IKE の設定 (作業マップ)」

公開鍵証明書を生成し、接続されたハードウェアに格納するように設定します 

Sun Crypto Accelerator 1000 ボードまたは Sun Crypto Accelerator 4000 ボードを使って IKE 操作を高速化します。Sun Crypto Accelerator 4000 ボードには、公開鍵証明書も格納できます。 

「接続したハードウェアを検出するための IKE の設定 (作業マップ)」

フェーズ 1 鍵ネゴシエーションパラメータを調整します 

IKE 鍵ネゴシエーションのタイミングを変更します。 

「IKE 転送パラメータの変更 (作業マップ)」

事前共有鍵による IKE の設定 (作業マップ)

次の表に、事前共有鍵で IKE を設定および保守する手順を示します。

タスク 

説明 

説明 

事前共有鍵で IKE を設定します 

共有する IKE ポリシーファイルと 1 つの鍵を作成します。 

「事前共有鍵により IKE を設定する方法」

実行中の IKE システムで事前共有鍵を更新します 

通信するシステムに最新の鍵情報を追加します。 

「IKE の事前共有鍵を更新する方法」

実行中の IKE システムへ事前共有鍵を追加します 

現在 IKE ポリシーを実施しているシステムに、新しい IKE ポリシーエントリと新しい鍵情報を追加します。 

「ipsecinit.conf の新しいポリシーエントリ用に IKE 事前共有鍵を追加する方法」

事前共有鍵が同一であることをチェックします 

両方のシステムの事前共有鍵を表示して、その鍵が同一であることを調べます。 

「事前共有鍵が同一であることを確認する方法」

事前共有鍵による IKE の設定

事前共有鍵は、IKE 用の最も簡単な認証方法です。2 つのシステムが IKE を使用するように設定している場合、さらに、両方のシステムの管理者である場合、事前共有鍵を使用することはよい選択です。しかし、公開鍵認証とは異なり、事前共有鍵は特定の IP アドレスに縛られます。事前共有鍵は、移動体システムなど、番号が変更される可能性があるシステムでは使用できません。また、事前共有鍵を使用するときには、接続されたハードウェアに IKE 計算を任せることはできません。

Procedure事前共有鍵により IKE を設定する方法

IKE 実装では、鍵の長さが異なるさまざまなアルゴリズムが提供されます。鍵の長さは、サイトのセキュリティーに応じて選択します。一般的に、鍵の長さが長いほど、セキュリティーが高くなります。

これらの手順には、システム名 enigma および partym を使用します。enigma と partym を各自使用しているシステムの名前に置き換えてください。

  1. システムコンソール上で、Primary Administrator の役割を引き受けるか、スーパーユーザーになります。

    Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

    注 –

    リモートログインすると、セキュリティー上重要なトラフィックが盗聴される恐れがあります。何らかの方法でリモートログインを保護していても、システムのセキュリティーがリモートログインセッションレベルに低下します。セキュリティー保護されたリモートログインには、ssh コマンドを使用してください。

  2. システムごとに、/etc/inet/ike/config.sample ファイルを /etc/inet/ike/config にコピーします。

  3. システムごとに、規則とグローバルパラメータを ike/config ファイルに入力します。

    これらの規則やグローバルパラメータは、システムの ipsecinit.conf ファイルに設定されている IPsec ポリシーが正しく動作するものでなければなりません。次の ike/config の例は、「IPsec で 2 つのシステム間のトラフィックを保護するには」の ipsecinit.conf の例で機能します。

    1. たとえば、enigma システムの /etc/inet/ike/config ファイルを次のように変更します。


      ### ike/config file on enigma, 192.168.116.16

## Global parameters
#
## Phase 1 transform defaults
p1_lifetime_secs 14400
p1_nonce_len 40
#
## Defaults that individual rules can override.
p1_xform
  { auth_method preshared oakley_group 5 auth_alg sha encr_alg des }
p2_pfs 2
#
## The rule to communicate with partym
#  Label must be unique
{ label "enigma-partym"
  local_addr 192.168.116.16
  remote_addr 192.168.13.213
  p1_xform
   { auth_method preshared oakley_group 5 auth_alg sha1 encr_alg aes }
  p2_pfs 5
}
      注 –

      auth_method パラメータのすべての引数は同じ行になければなりません。

    2. partym システムの /etc/inet/ike/config ファイルを次のように変更します。


      ### ike/config file on partym, 192.168.13.213
## Global Parameters
#
p1_lifetime_secs 14400
p1_nonce_len 40
#
p1_xform
  { auth_method preshared oakley_group 5 auth_alg sha encr_alg des }
p2_pfs 2

## The rule to communicate with enigma
#  Label must be unique
{ label "partym-enigma"
  local_addr 192.168.13.213
  remote_addr 192.168.116.16
p1_xform
   { auth_method preshared oakley_group 5 auth_alg sha1 encr_alg aes }
p2_pfs 5
}

  4. システムごとに、ファイルの構文を確認します。


    # /usr/lib/inet/in.iked -c -f /etc/inet/ike/config

  5. 鍵情報として使用する乱数を生成します。

    乱数発生関数がすでにある場合は、それを使用してください。Solaris システムでは、od コマンドを使用できます。たとえば、次のコマンドを入力すると、16 進数の数値が 2 行に渡って表示されます。


    % od -X -A n /dev/random | head -2
         f47cb0f4 32e14480 951095f8 2b735ba8
         0a9467d0 8f92c880 68b6a40e 0efe067d

    od コマンドについては、「Solaris System で乱数を生成するには」と od(1) のマニュアルページを参照してください。

    注 –

    ほかのオペレーティングシステムでは、ASCII 形式の鍵情報が必要になる場合があります。同じ鍵を 16 進形式と ASCII 形式で生成する方法については、例 23–1 を参照してください。

  6. 手順 5 の出力から、1 つの鍵を作成します。


    f47cb0f432e14480951095f82b735ba80a9467d08f92c88068b6a40e

    この手順における認証アルゴリズムは SHA–1 です (手順 3 を参照)。事前共有鍵として推奨する最小のサイズは、ハッシュのサイズ (つまり、認証アルゴリズムの出力のサイズ) で決まります。SHA–1 アルゴリズムの出力は 160 ビット、すなわち 40 文字です。例の鍵の長さは 56 文字であり、IKE が使用する鍵情報が追加されています。

  7. システムごとに /etc/inet/secret/ike.preshared ファイルを作成します。

    各ファイルに事前共有鍵を書き込みます。

    1. たとえば、enigma システムの ike.preshared ファイルは次のようになります。


      # ike.preshared on enigma, 192.168.116.16
#…
{ localidtype IP
	localid 192.168.116.16
	remoteidtype IP
	remoteid 192.168.13.213
	# enigma and partym's shared key in hex (192 bits)
	key f47cb0f432e14480951095f82b735ba80a9467d08f92c88068b6a40e
	}

    2. partym システムの ike.preshared ファイルは次のようになります。


      # ike.preshared on partym, 192.168.13.213
#…
{ localidtype IP
	localid 192.168.13.213
	remoteidtype IP
	remoteid 192.168.116.16
	# partym and enigma's shared key in hex (192 bits)
	key f47cb0f432e14480951095f82b735ba80a9467d08f92c88068b6a40e
	}
    注 –

    両システムの事前共有鍵は同一にする必要があります。

例 23–1 オペレーティングシステムの異なる 2 つのシステムに対して同じ鍵情報を生成する

Solaris IPsec は、ほかのオペレーティングシステムと相互運用できます。ASCII 形式の事前共有鍵を必要とするシステムと通信する場合は、1 つの鍵を 16 進形式と ASCII 形式の 2 つの形式で生成する必要があります。

この例では、Solaris システムの管理者が 56 文字の鍵情報を使用しようとしています。管理者は、次のコマンドを使用して、ASCII パスフレーズから 16 進形式の鍵を生成します。オプション -tx1 を指定すると、一度に 1 バイトずつ、すべての Solaris システムに出力されます。


# /bin/echo "papiermache with cashews and\c" | od -tx1 | cut -c 8-55 | \
tr -d '\n' | tr -d ' ' | awk '{print}'
7061706965726d616368652077697468206361736865777320616e64

オフセットを削除して 16 進出力を連結すると、Solaris システム用の 16 進形式の鍵は 7061706965726d616368652077697468206361736865777320616e64 になります。管理者は、この値を Solaris システムの ike.preshared ファイルに格納します。


# Shared key in hex (192 bits)
key 7061706965726d616368652077697468206361736865777320616e64

ASCII 形式の事前共有鍵を必要とするシステムでは、パスフレーズが事前共有鍵になります。Solaris システムの管理者は、相手の管理者に電話し、パスフレーズ papiermache with cashews and を伝えます。

ProcedureIKE の事前共有鍵を更新する方法

この手順では、一定の間隔で既存の事前共有鍵を置き換えたい場合を想定しています。

  1. システムコンソール上で、Primary Administrator の役割を引き受けるか、スーパーユーザーになります。

    Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

    注 –

    リモートログインすると、セキュリティー上重要なトラフィックが盗聴される恐れがあります。何らかの方法でリモートログインを保護していても、システムのセキュリティーがリモートログインセッションレベルに低下します。セキュリティー保護されたリモートログインには、ssh コマンドを使用してください。

  2. 乱数を生成し、適切な長さのキーを作成します。

    詳細については、「Solaris System で乱数を生成するには」を参照してください。Solaris システムが ASCII 形式を必要とするオペレーティングシステムと通信する場合、事前共有鍵を生成する方法については、例 23–1 を参照してください。

  3. 現在の鍵を新しい鍵で置き換えます。

    たとえば、ホスト enigma と partym において、 /etc/inet/secret/ike.preshared ファイルの key の値を、同じ長さの新しい番号で置き換えます。

  4. 新しい鍵をカーネルに読み込みます。

    • Solaris 10 4/09 リリース以降では、ike サービスを更新します。


      # svcadm refresh ike

    • Solaris 10 4/09 リリースより前のリリースを実行している場合は、in.iked デーモンを強制終了および再起動します。

      1. in.iked デーモンの特権レベルをチェックします。


        # /usr/sbin/ikeadm get priv
Current privilege level is 0x0, base privileges enabled

        コマンドから 0x1 または 0x2 の特権レベルが戻された場合には、鍵情報を変更できます。0x0 の特権レベルでは、鍵情報を変更または表示する操作を行うことはできません。デフォルトでは、in.iked デーモンは 0x0 の特権レベルで実行されます。

      2. 特権レベルが 0x0 の場合、デーモンを強制終了および再起動します。

        デーモンを再起動すると、ike.preshared ファイルの新しいバージョンを読み取ります。


        # pkill in.iked
# /usr/lib/inet/in.iked

      3. 特権レベルが 0x1 または 0x2 である場合、ike.preshared ファイルの新しいバージョンを読み取ります。


        # ikeadm read preshared

ProcedureIKE の事前共有鍵を表示する方法

デフォルトでは、ikeadm コマンドではフェーズ 1 SA のダンプに実際の鍵を表示できないようになっています。鍵を表示するとデバッグに役立ちます。

実際の鍵を表示するには、デーモンの特権レベルを高くする必要があります。特権レベルについては、「IKE 管理コマンド」を参照してください。

注 –

Solaris 10 4/09 リリースより前のリリースでこの手順を実行するには、例 23–2 を参照してください。

始める前に

IKE は構成済みで、ike サービスは実行中です。

  1. IKE の事前共有鍵を表示します。


    # ikeadm
ikeadm> dump preshared

  2. エラーが発生する場合は、in.iked デーモンの特権レベルを高くします。

    1. SMF リポジトリの in.iked デーモンの特権レベルを高くします。


      # svcprop -p config/admin_privilege ike
base
# svccfg -s ike setprop config/admin_privilege=keymat

    2. 実行中の in.iked デーモンの特権レベルを高くします。


      # svcadm refresh ike ; svcadm restart ike

    3. (省略可能) 特権レベルが keymat であることを確認します。


      # svcprop -p config/admin_privilege ike
keymat

    4. 手順 1 をもう一度実行して鍵を表示します。

  3. IKE デーモンを基本の特権レベルに戻します。

    1. 鍵を表示したあと、特権レベルをデフォルトに戻します。


      # svccfg -s ike setprop config/admin_privilege=base

    2. IKE を更新してから再起動します。


      # svcadm refresh ike ; svcadm restart ike
例 23–2 Solaris 10 4/09 リリースより前のリリースで IKE の事前共有鍵を確認する

次の例では、現在の Solaris リリースが稼働していない Solaris システムで管理者が鍵を表示しようとしています。管理者は、このシステムの鍵が通信先のシステムの鍵と同じであることを確認する必要があります。2 つのシステムの鍵が同じであることを確認したあと、管理者は特権レベルを 0 に戻します。

Procedureipsecinit.conf の新しいポリシーエントリ用に IKE 事前共有鍵を追加する方法

IPsec と IKE の実行中に IPsec ポリシーのエントリを追加した場合は、新しいポリシーおよび IKE ルールをカーネルに読み込む必要があります。Solaris 10 4/09 リリース以降では、新しい鍵を追加したあと policy サービスを再起動し、ike サービスを更新します。

注 –

Solaris 10 4/09 リリースより前のリリースでこの手順を実行するには、例 23–3 を参照してください。

始める前に

この手順では、次のように仮定しています。

  1. システムコンソール上で、Primary Administrator の役割を引き受けるか、スーパーユーザーになります。

    Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

    注 –

    リモートログインすると、セキュリティー上重要なトラフィックが盗聴される恐れがあります。何らかの方法でリモートログインを保護していても、システムのセキュリティーがリモートログインセッションレベルに低下します。セキュリティー保護されたリモートログインには、ssh コマンドを使用してください。

  2. このシステムで乱数を生成し、64 から 448 ビットの鍵を作成します。

    詳細については、「Solaris System で乱数を生成するには」を参照してください。Solaris システムが ASCII 形式を必要とするオペレーティングシステムと通信する場合、事前共有鍵を生成する方法については、例 23–1 を参照してください。

  3. このキーを何らかの方法でリモートシステムの管理者に送信します。

    両者は、同じ事前共有鍵を同時に追加する必要があります。この鍵の安全性は転送機構の安全性と同じです。登録済みメールや保護済み FAX マシンなど、帯域外機構を使用することが最良です。ssh セッションを使用して両方のシステムを管理することもできます。

  4. enigma と ada の鍵を管理するための IKE の規則を作成します。

    1. enigma システムで、次の規則を /etc/inet/ike/config ファイルに追加します。


      ### ike/config file on enigma, 192.168.116.16
 
## The rule to communicate with ada

{label "enigma-to-ada"
 local_addr 192.168.116.16
 remote_addr 192.168.15.7
 p1_xform
 {auth_method preshared oakley_group 5 auth_alg sha1 encr_alg blowfish}
 p2_pfs 5
	}

    2. ada システムで、次の規則を追加します。


      ### ike/config file on ada, 192.168.15.7
 
## The rule to communicate with enigma

{label "ada-to-enigma"
 local_addr 192.168.15.7
 remote_addr 192.168.116.16
 p1_xform
 {auth_method preshared oakley_group 5 auth_alg sha1 encr_alg blowfish}
 p2_pfs 5
}

  5. リブート時に IKE 事前共有鍵が利用できることを確認します。

    1. enigma システムで、次の情報を /etc/inet/secret/ike.preshared ファイルに追加します。


      # ike.preshared on enigma for the ada interface
# 
{ localidtype IP
  localid 192.168.116.16
  remoteidtype IP
  remoteid 192.168.15.7
  # enigma and ada's shared key in hex (32 - 448 bits required)
  key 8d1fb4ee500e2bea071deb2e781cb48374411af5a9671714672bb1749ad9364d
}

    2. ada システムで、次の情報を ike.preshared ファイルに追加します。


      # ike.preshared on ada for the enigma interface
# 
{ localidtype IP
  localid 192.168.15.7
  remoteidtype IP
  remoteid 192.168.116.16
  # ada and enigma's shared key in hex (32 - 448 bits required)
  key 8d1fb4ee500e2bea071deb2e781cb48374411af5a9671714672bb1749ad9364d
}

  6. 各システムで、IPsec ポリシーサービスを再起動して、追加したインタフェースをセキュリティー保護します。


    # svcadm restart policy

  7. 各システムで、ike サービスを更新します。


    # svcadm refresh ike

  8. 両システムが通信できることを確認します。

    詳細は、「事前共有鍵が同一であることを確認する方法」を参照してください。

例 23–3 新しい IPsec ポリシーエントリに IKE 事前共有鍵を追加する

次の例では、現在の Solaris リリースが稼働していない Solaris システムに管理者が事前共有鍵を追加しようとしています。管理者は前の手順に従って ike/config ファイルと ike.preshared ファイルを変更し、鍵を生成し、リモートシステムに接続します。管理者は各種のコマンドを使用して、新しい IPsec ポリシーおよび IKE ルールをカーネルに読み込みます。

Procedure事前共有鍵が同一であることを確認する方法

通信するシステム上の事前共有鍵が同一でない場合、それらのシステムは認証できません。

始める前に

テストしている 2 つのシステム間では IPsec が設定されており、有効になっています。現在の Solaris 10 リリースが稼働しています。

注 –

Solaris 10 4/09 リリースより前のリリースでこの手順を実行するには、例 23–2 を参照してください。

  1. システムコンソール上で、Primary Administrator の役割を引き受けるか、スーパーユーザーになります。

    Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

    注 –

    リモートログインすると、セキュリティー上重要なトラフィックが盗聴される恐れがあります。何らかの方法でリモートログインを保護していても、システムのセキュリティーがリモートログインセッションレベルに低下します。セキュリティー保護されたリモートログインには、ssh コマンドを使用してください。

  2. 各システムで、in.iked デーモンの特権レベルをチェックします。


    # svcprop -p config/admin_privilege ike
base

    • 特権レベルが keymat であれば、手順 3 に進みます。

    • 特権レベルが base または modkeys の場合は、特権レベルを高くします。

      その後、ike サービスを更新してから再起動します。


      # svccfg -s ike setprop config/admin_privilege=keymat
# svcadm refresh ike ; svcadm restart ike
# svcprop -p config/admin_privilege ike
keymat

  3. システムごとに、事前共有鍵情報を表示します。


    # ikeadm dump preshared
PSKEY: Preshared key (24 bytes): f47cb…/192
LOCIP: AF_INET: port 0, 192.168.116.16 (enigma).
REMIP: AF_INET: port 0, 192.168.13.213 (partym).

  4. 両方のダンプを比較します。

    事前共有鍵が同一でない場合は、/etc/inet/secret/ike.preshared ファイルで、一方のキーを他方のキーで置き換えます。

  5. 確認が終わったら、各システム上で特権レベルをデフォルトに戻します。


    # svccfg -s ike setprop config/admin_privilege=base
# svcadm restart ike

公開鍵証明書による IKE の設定 (作業マップ)

次の表に、IKE の公開鍵証明書を作成する手順を示します。これらの手順には、接続されたハードウェア上で証明書を高速化および格納する方法が含まれます。

タスク 

説明 

説明 

自己署名付き公開鍵証明書で IKE を設定します 

システムごとに 2 つの証明書を作成および格納します。 

  • 自己署名付き証明書

  • リモートシステムからの公開鍵証明書

「自己署名付き公開鍵証明書により IKE を設定する方法」

PKI 認証局で IKE を設定します 

1 つの証明書要求を作成して、そのあと、システムごとに次の 3 つの証明書を格納します。 

  • 証明書要求に応じて認証局 (CA) が作成した証明書

  • CA からの公開鍵証明書

  • CA からの CRL

「CA からの署名付き証明書により IKE を設定する方法」

ローカルハードウェア上で公開鍵証明書を設定します 

次のいずれかの作業を行います。  

  • ローカルハードウェア上で自己署名付き証明書を生成し、リモートシステムの公開鍵をハードウェアに追加する。

  • ローカルハードウェア上で証明書要求を生成し、CA から取得した公開鍵証明書をハードウェアに追加する。

「ハードウェア上で公開鍵証明書を生成、格納する方法」

PKI からの証明書失効リスト CRL を更新します 

中央の配布ポイントから CRL にアクセスします。 

「証明書失効リストを処理する方法」

公開鍵証明書による IKE の設定

公開鍵証明書を使用すると、通信するシステムは秘密鍵情報を帯域外で共有する必要がなくなります。事前共有鍵とは異なり、公開鍵証明書は、移動体システムなど、番号が変更される可能性があるシステムでも使用できます。

公開鍵証明書はまた、接続されたハードウェアに格納できます。手順については、「接続したハードウェアを検出するための IKE の設定 (作業マップ)」を参照してください。

Procedure自己署名付き公開鍵証明書により IKE を設定する方法

自己署名付き証明書は、CA からの公開鍵証明書よりもオーバーヘッドが少ないのですが、あまり簡単には拡大できません。

  1. システムコンソール上で、Primary Administrator の役割を引き受けるか、スーパーユーザーになります。

    Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

    注 –

    リモートログインすると、セキュリティー上重要なトラフィックが盗聴される恐れがあります。何らかの方法でリモートログインを保護していても、システムのセキュリティーがリモートログインセッションレベルに低下します。セキュリティー保護されたリモートログインには、ssh コマンドを使用してください。

  2. 自己署名付き証明書を ike.privatekeys データベースに追加します。 


    # ikecert certlocal -ks|-kc -m keysize -t keytype \
-D dname -A altname \
[-S validity-start-time] [-F validity-end-time] [-T token-ID]
    -ks

    自己署名付き証明書を作成します。

    -kc

    証明書要求を作成します。手順については、「CA からの署名付き証明書により IKE を設定する方法」を参照してください。

    -m keysize

    キーのサイズです。keysize は、512、1024、2048、3072、4096 のいずれかです。

    -t keytype

    使用するアルゴリズムのタイプを指定します。keytype は rsa-sha1、rsa-md5、dsa-sha1 のいずれかです。

    -D dname

    証明書主体の X.509 識別名です。dname の一般的な形式は次のとおりです。 C = country (国)、O = organization (組織)、OU = organizational unit (組織単位)、CN = common name (共通名)。有効なタグは、C、O、OU、CN です。

    -A altname

    証明書の代替名です。altname の形式は tag=value です。有効なタグは IP、DNS、email、および DN です。

    -S validity-start-time

    証明書の有効期間の開始時間を絶対値または相対値で指定します。

    -F validity-end-time

    証明書の有効期間の終了時間を絶対値または相対値で指定します。

    -T token-ID

    PKCS #11 ハードウェアトークンで鍵を生成できるようにします。その後、証明書はハードウェアに格納されます。

    1. たとえば、partym システムでは、コマンドは次のようになります。


      # ikecert certlocal -ks -m 1024 -t rsa-md5 \
-D "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" \
-A IP=192.168.13.213
Creating software private keys.
  Writing private key to file /etc/inet/secret/ike.privatekeys/0.
Enabling external key providers - done.
Acquiring private keys for signing - done.
Certificate: 
 Proceeding with the signing operation.
 Certificate generated successfully (…/publickeys/0)
Finished successfully.
Certificate added to database.
-----BEGIN X509 CERTIFICATE-----
MIICLTCCAZagAwIBAgIBATANBgkqhkiG9w0BAQQFADBNMQswCQYDVQQGEwJVUzEX
…
6sKTxpg4GP3GkQGcd0r1rhW/3yaWBkDwOdFCqEUyffzU
-----END X509 CERTIFICATE-----

    2. enigma システムでは、コマンドは次のようになります。


      # ikecert certlocal -ks -m 1024 -t rsa-md5 \
-D "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax" \
-A IP=192.168.116.16
Creating software private keys.
  …
Certificate added to database.
-----BEGIN X509 CERTIFICATE-----
MIICKDCCAZGgAwIBAgIBATANBgkqhkiG9w0BAQQFADBJMQswCQYDVQQGEwJVUzEV
…
jpxfLM98xyFVyLCbkr3dZ3Tvxvi732BXePKF2A==
-----END X509 CERTIFICATE-----

  3. 証明書を保存し、リモートシステムに送信します。

    証明書は、電子メールに貼り付けることもできます。

    1. たとえば、次の partym 証明書を enigma の管理者に送信します。


      To: admin@ja.enigmaexample.com
From: admin@us.partyexample.com
Message: -----BEGIN X509 CERTIFICATE-----
MIICLTCCAZagAwIBAgIBATANBgkqhkiG9w0BAQQFADBNMQswCQYDVQQGEwJVUzEX
…
6sKTxpg4GP3GkQGcd0r1rhW/3yaWBkDwOdFCqEUyffzU
-----END X509 CERTIFICATE-----

    2. enigma の管理者は、次の enigma 証明書を送信してきます。


      To: admin@us.partyexample.com
From: admin@ja.enigmaexample.com
Message: -----BEGIN X509 CERTIFICATE-----
MIICKDCCAZGgAwIBAgIBATANBgkqhkiG9w0BAQQFADBJMQswCQYDVQQGEwJVUzEV
…
jpxfLM98xyFVyLCbkr3dZ3Tvxvi732BXePKF2A==
-----END X509 CERTIFICATE-----

  4. システムごとに、受信した証明書を追加します。

    1. 管理者の電子メールから公開鍵をコピーします。

    2. ikecert certdb -a コマンドを入力して、Return キーを押します。

      Return キーを押してもプロンプトは表示されません。


      # ikecert certdb -a Press the Return key

    3. 公開鍵を貼り付けます。続いて Return キーを押します。Control-D キーを押して入力を終了します。


      -----BEGIN X509 CERTIFICATE-----
MIIC…
…
----END X509 CERTIFICATE----- Press the Return key
<Control>-D

  5. 通信するシステムの管理者と一緒に、証明書がその管理者のものであることを確認します。

    たとえば、その管理者に電話で連絡して次に示す公開鍵ハッシュの値を比較できます。共有の証明書の公開鍵ハッシュは、両システムで同一でなければなりません。

    1. システムに格納されている証明書のリストを表示します。

      たとえば、partym システムでは、公開鍵証明書はスロット 1 に格納されており、非公開鍵証明書はスロット 0 に格納されています。


      partym # ikecert certdb -l
Certificate Slot Name: 0   Type: rsa-md5 Private Key
    Subject Name: <C=US, O=PartyCompany, OU=US-Partym, CN=Partym>
    Key Size: 1024
    Public key hash: B2BD13FCE95FD27ECE6D2DCD0DE760E2

Certificate Slot Name: 1   Type: rsa-md5 Public Certificate
    (Private key in certlocal slot 0) Points to certificate's private key
    Subject Name: <C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax>
    Key Size: 1024
    Public key hash: 2239A6A127F88EE0CB40F7C24A65B818

    2. この値と enigma システムの公開鍵ハッシュを比較します。

      公開鍵ハッシュは電話で伝えることができます。


      enigma # ikecert certdb -l
Certificate Slot Name: 4   Type: rsa-md5 Private Key
    Subject Name: <C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax>
    Key Size: 1024
    Public key hash: DF3F108F6AC669C88C6BD026B0FCE3A0

Certificate Slot Name: 5   Type: rsa-md5 Public Certificate
    (Private key in certlocal slot 4)
    Subject Name: <C=US, O=PartyCompany, OU=US-Partym, CN=Partym>
    Key Size: 1024
    Public key hash: 2239A6A127F88EE0CB40F7C24A65B818

  6. システムごとに、両方の証明書を信頼します。

    /etc/inet/ike/config ファイルを編集して、証明書を認識します。

    パラメータ cert_trust、remote_addr、および remote_id の値は、リモートシステムの管理者が提供します。

    1. たとえば、partym システム上の ike/config ファイルは次のようになります。


      # Explicitly trust the following self-signed certs
# Use the Subject Alternate Name to identify the cert

# Verified remote address and remote ID
# Verified public key hash per telephone call from administrator
cert_trust "192.168.13.213" Local system's certificate Subject Alt Name
cert_trust "192.168.116.16" Remote system's certificate Subject Alt Name

## Parameters that may also show up in rules.

p1_xform 
  { auth_method preshared oakley_group 5 auth_alg sha encr_alg des }
p2_pfs 5

{
 label "US-partym to JA-enigmax"
 local_id_type dn
 local_id "C=US, O=PartyCompany, OU=US-Partym, CN=Partym"
 remote_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax"

 local_addr  192.168.13.213
 remote_addr 192.168.116.16

 p1_xform
  {auth_method rsa_sig oakley_group 2 auth_alg sha1 encr_alg aes}
}

    2. enigma システムで、ike/config ファイルにローカルパラメータの enigma 値を追加します。

      リモートパラメータには、partym 値を使用します。キーワード label の値が一意であることを確認します。この値は、リモートシステムの label 値とは異なる値でなくてはなりません。


      …
{
 label "JA-enigmax to US-partym"
 local_id_type dn
 local_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax"
 remote_id "C=US, O=PartyCompany, OU=US-Partym, CN=Partym"

 local_addr  192.168.116.16
 remote_addr 192.168.13.213
…
例 23–4 別の管理者の証明書が有効かどうかを確認する

この例で、管理者は被認証者名 (Subject Name) を使用して証明書が同一であることを確認します。

最初の管理者は、証明書の生成と一覧表示の出力をファイルに保存します。ikecert コマンドの出力は標準エラーに書き込まれるため、管理者は標準エラーをファイルにリダイレクトします。


sys1# cd /
sys1# ikecert certlocal -ks -m1024 -t rsa-md5 \
-D"C=US, O=TestCo, CN=Co2Sys" 2>/tmp/for_co2sys
Certificate added to database.
sys1# ikecert certdb -l "C=US, O=TestCo, CN=Co2Sys" 2>>/tmp/for_co2sys

管理者はファイルの内容を確認します。


sys1# cat /tmp/for_co2sys
Creating private key.
-----BEGIN X509 CERTIFICATE-----
MIIB7TCCAVagAwIBAgIEZkHfOTANBgkqhkiG9w0BAQQFADAxMQwwCgYDVQQGEwNV
U0ExEDAOBgNVBAoMB3Rlc3RfY28xDzANBgNVBAMTBkVuaWdtYTAeFw0wODAxMTUx
OTI1MjBaFw0xMjAxMTUxOTI1MjBaMDExDDAKBgNVBAYTA1VTQTEQMA4GA1UECgwH
dGVzdF9jbzEPMA0GA1UEAxMGRW5pZ21hMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB
iQKBgQCPxGv0rUzHMnFtkx9uwYuPiWbftmWfa9iDt6ELOEuw3zlboy2qtuRUZohz
FIbCxAJevdCY6a+pktvYy3/2nJL0WATObO5T0FKn3F0bphajinLYbyCrYhEzD9E2
gkiT2D9/ttbSiMvi9usphprEDcLAFaWgCJiHnKPBEkjC0vhA3wIDAQABoxIwEDAO
BgNVHQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEEBQADgYEAL/q6xgweylGQylqLCwzN
5PIpjfzsNPf3saTyh3VplwEOW6WTHwRQT17IO/1Oc6Jnz9Mr0ZrbHWDXq+1sx180
F8+DMW1Qv1UR/lGMq3ufDG3qedmSN6txDF8qLlPCUML0YL8m4oGdewqGb+78aPyE
Y/cJRsK1hWbYyseqcIkjj5k=
-----END X509 CERTIFICATE-----
Certificate Slot Name: 2   Key Type: rsa
        (Private key in certlocal slot 2)
        Subject Name: <C=US, O=TestCo, CN=Co2Sys>
        Key Size: 1024
        Public key hash: C46DE77EF09084CE2B7D9C70479D77FF

次に、管理者はこのファイルを電子メールで 2 番目の管理者に送信します。

2 番目の管理者は、セキュリティー保護されたディレクトリにファイルを格納し、ファイルから証明書をインポートします。


sys2# cd /
sys2# ikecert certdb -a < /sec/co2sys

ikecert コマンドは、-----BEGIN 行と -----END 行の間にあるテキストだけをインポートします。管理者は、ローカルの証明書の公開鍵ハッシュが co2sys ファイル内の公開鍵ハッシュと同じであることを確認します。


sys2# ikecert certdb -l
Certificate Slot Name: 1   Key Type: rsa
        (Private key in certlocal slot 1)
        Subject Name: <C=US, O=TestCo, CN=Co2Sys>
        Key Size: 1024
        Public key hash: C46DE77EF09084CE2B7D9C70479D77FF

この電子メールを送信したのが最初の管理者であることを確認するために、2 番目の管理者は最初の管理者に電話して、証明書の被認証者名 (Subject Name) を確認します。

例 23–5 証明書の開始時間と終了時間を指定する

この例では、partym システムの管理者が、証明書の有効期間の日付を設定します。証明書は、2.5 日前の発効とし、作成日から 4 年 6 か月間有効とします。


# ikecert certlocal -ks -m 1024 -t rsa-md5 \
-D "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" \
-A IP=192.168.13.213 \
-S -2d12h -F +4y6m

enigma システムの管理者が、証明書の有効期間の日付を設定します。証明書は、2 日前の発効とし、2010 年 12 月 31 日の午前 0 時まで有効とします。


# ikecert certlocal -ks -m 1024 -t rsa-md5 \
-D "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax" \
-A IP=192.168.116.16 \
-S -2d -F "12/31/2010 12:00 AM"

ProcedureCA からの署名付き証明書により IKE を設定する方法

認証局 (CA) からの公開鍵証明書では、外部機関とのネゴシエーションが必要となります。この証明書は非常に簡単に拡大できるため、通信するシステムを数多く保護できます。

  1. システムコンソール上で、Primary Administrator の役割を引き受けるか、スーパーユーザーになります。

    Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

    注 –

    リモートログインすると、セキュリティー上重要なトラフィックが盗聴される恐れがあります。何らかの方法でリモートログインを保護していても、システムのセキュリティーがリモートログインセッションレベルに低下します。セキュリティー保護されたリモートログインには、ssh コマンドを使用してください。

  2. ikecert certlocal -kc コマンドを使用して、証明書要求を作成します。

    コマンドの引数については、「自己署名付き公開鍵証明書により IKE を設定する方法」の手順 2 を参照してください。


    # ikecert certlocal -kc -m keysize -t keytype \
-D dname -A altname

    1. たとえば、次のコマンドでは、partym システム上に証明書要求が作成されます。


      # ikecert certlocal -kc -m 1024 -t rsa-md5 \
> -D "C=US, O=PartyCompany\, Inc., OU=US-Partym, CN=Partym" \
> -A "DN=C=US, O=PartyCompany\, Inc., OU=US-Partym"
Creating software private keys.
  Writing private key to file /etc/inet/secret/ike.privatekeys/2.
Enabling external key providers - done.
Certificate Request: 
  Proceeding with the signing operation.
  Certificate request generated successfully (…/publickeys/0)
Finished successfully.
-----BEGIN CERTIFICATE REQUEST-----
MIIByjCCATMCAQAwUzELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFEV4YW1wbGVDb21w
…
lcM+tw0ThRrfuJX9t/Qa1R/KxRlMA3zckO80mO9X
-----END CERTIFICATE REQUEST-----

    2. 次のコマンドでは、enigma システム上に証明書要求が作成されます。


      # ikecert certlocal -kc -m 1024 -t rsa-md5 \
> -D "C=JA, O=EnigmaCo\, Inc., OU=JA-Enigmax, CN=Enigmax" \
> -A "DN=C=JA, O=EnigmaCo\, Inc., OU=JA-Enigmax"
Creating software private keys.
…
Finished successfully.
-----BEGIN CERTIFICATE REQUEST-----
MIIBuDCCASECAQAwSTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDFBhcnR5Q29tcGFu
…
8qlqdjaStLGfhDOO
-----END CERTIFICATE REQUEST-----

  3. この証明書要求を PKI 機関に送信します。

    証明書要求の送信方法については PKI に問い合わせてください。ほとんどの機関は、Web サイトに送信フォームを掲載しています。フォームの記入に当たっては、その送信が正当なものであることを証明する必要があります。通常は、証明書要求をフォームに貼り付けます。要求を受け取った機関は、それをチェックしてから、次の 2 つの証明書オブジェクトと、証明書失効リストを発行します。

    • 公開鍵証明書 – この証明書は機関に送信した要求に基づいて作成されます。送信した証明書要求も、公開鍵証明書の一部として含まれます。この証明書によって一意に識別されます。

    • 認証局 – 機関の署名。CA によって公開鍵証明書が正規のものであることが確認されます。

    • 証明書失効リスト (CRL) – 機関が無効にした証明書の最新リストです。CRL へのアクセスが公開鍵証明書に組み込まれている場合には、CRL が別個の証明書オブジェクトとして送信されることはありません。

      CRL の URI が公開鍵証明書に組み込まれている場合には、IKE は CRL を自動的に取り出すことができます。同様に、DN (LDAP サーバー上のディレクトリ名) エントリが公開鍵証明書に組み込まれている場合には、IKE は、指定された LDAP サーバーから CRL を取得し、キャッシュできます。

      公開鍵証明書に組み込まれている URI と DN エントリの例については、「証明書失効リストを処理する方法」を参照してください。

  4. 各証明書をシステムに追加します。

    ikecert certdb -a コマンドの -a オプションは、張り付けられたオブジェクトをシステムの適切な証明書データベースに追加します。 詳細については、「IKE と公開鍵証明書」を参照してください。

    1. システムコンソール上で、Primary Administrator の役割を引き受けるか、スーパーユーザーになります。

    2. PKI 機関から受け取った公開鍵証明書を追加します。


      # ikecert certdb -a
Press the Return key
Paste the certificate:
-----BEGIN X509 CERTIFICATE-----
…
-----END X509 CERTIFICATE----
Press the Return key
<Control>-D

    3. PKI 機関の CA を追加します。


      # ikecert certdb -a
Press the Return key
Paste the CA:
-----BEGIN X509 CERTIFICATE-----
…
-----END X509 CERTIFICATE----
Press the Return key
<Control>-D

    4. PKI 機関が証明書失効リスト (CRL) を送信してきている場合は、これを certrldb データベースに追加します。


      # ikecert certrldb -a
Press the Return key
Paste the CRL:
-----BEGIN CRL-----
…
-----END CRL----
Press the Return key
<Control>-D

  5. cert_root キーワードを使用して、/etc/inet/ike/config ファイルの PKI 機関を識別します。

    PKI 機関が提供する名前を使用します。

    1. たとえば、partym システムの ike/config ファイルは次のようになります。


      # Trusted root cert
# This certificate is from Example PKI
# This is the X.509 distinguished name for the CA that it issues.

cert_root "C=US, O=ExamplePKI\, Inc., OU=PKI-Example, CN=Example PKI"

## Parameters that may also show up in rules.

p1_xform 
 { auth_method rsa_sig oakley_group 1 auth_alg sha1 encr_alg des }
p2_pfs 2

{
 label "US-partym to JA-enigmax - Example PKI"
 local_id_type dn
 local_id  "C=US, O=PartyCompany, OU=US-Partym, CN=Partym"
 remote_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax"

 local_addr  192.168.13.213
 remote_addr 192.168.116.16

 p1_xform
  {auth_method rsa_sig oakley_group 2 auth_alg sha1 encr_alg aes}
}
      注 –

      auth_method パラメータのすべての引数は同じ行になければなりません。

    2. enigma システム上で、同様なファイルを作成します。

      特に、enigma ike/config ファイルは、次の条件を満たしている必要があります。

      • cert_root には同じ値を使用する。

      • ローカルパラメータには enigma 値を使用する。

      • リモートパラメータには partym 値を使用する。

      • labelキーワードには一意の値を作成する。この値は、リモートシステムの label 値とは異なる値でなくてはなりません。


      …
cert_root "C=US, O=ExamplePKI\, Inc., OU=PKI-Example, CN=Example PKI"
…
{
 label "JA-enigmax to US-partym - Example PKI"
 local_id_type dn
 local_id   "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax"
 remote_id  "C=US, O=PartyCompany, OU=US-Partym, CN=Partym"
 
 local_addr  192.168.116.16
 remote_addr 192.168.13.213
…

  6. CRL を処理する方法を IKE に伝えます。

    適切なオプションを選択します。

    • No CRL available

      PKI 機関が CRL を提供しない場合、キーワード ignore_crls を ike/config ファイルに追加します。


      # Trusted root cert
…
cert_root "C=US, O=ExamplePKI\, Inc., OU=PKI-Example,…
ignore_crls
…

      ignore_crls キーワードにより、IKE は CRL を検索しなくなります。

    • CRL available

      PKI 機関から CRL の一元的な配布ポイントを知らされている場合は、ike/config ファイルを変更してこの場所を指定できます。

      例については、「証明書失効リストを処理する方法」を参照してください。

例 23–6 IKE の設定時における rsa_encrypt の使用

    ike/config ファイルで auth_method rsa_encrypt を使用する場合には、ピアの証明書を publickeys データベースに追加する必要があります。

  1. その証明書をリモートシステムの管理者に送信します。

    証明書は、電子メールに貼り付けることもできます。

    たとえば、partym の管理者は次のような電子メールを送信します。


    To: admin@ja.enigmaexample.com
From: admin@us.partyexample.com
Message: -----BEGIN X509 CERTIFICATE-----
MII…
----END X509 CERTIFICATE-----

    enigma の管理者は次のような電子メールを送信します。


    To: admin@us.partyexample.com
From: admin@ja.enigmaexample.com
Message: -----BEGIN X509 CERTIFICATE-----
MII
…
-----END X509 CERTIFICATE-----

  2. システムごとに、電子メールで送信された証明書をローカルの publickeys データベースに追加します。 


    # ikecert certdb -a
Press the Return key
-----BEGIN X509 CERTIFICATE-----
MII…
-----END X509 CERTIFICATE-----
Press the Return key
<Control>-D

RSA 暗号化の認証方法は、IKE 内の識別子を盗聴者から隠します。rsa_encrypt メソッドはピアの識別子を隠すため、IKE はピアの証明書を取得できません。結果として、rsa_encrypt メソッドでは、IKE ピアが互いの公開鍵を知っておく必要があります。

よって、/etc/inet/ike/config ファイルの auth_method に rsa_encrypt を指定する場合には、ピアの証明書を publickeys データベースに追加する必要があります。この結果、publickeys データベースには、通信するシステムペアごとに 3 つの証明書が存在することになります。

障害追跡 – IKE ペイロードは 3 つの証明書を持っており、大きくなりすぎて、rsa_encrypt が暗号化できないことがあります。「authorization failed (承認に失敗しました)」や「malformed payload (ペイロードが不正です)」などのエラーは、rsa_encrypt メソッドがペイロード全体を暗号化できないことを示します。証明書を 2 つしか必要としない rsa_sig などのメソッドを使用して、ペイロードのサイズを減らします。

Procedureハードウェア上で公開鍵証明書を生成、格納する方法

ハードウェア上で公開鍵証明書を生成および格納することは、システム上で公開鍵証明書を生成および格納することと似ています。ハードウェア上では、ikecert certlocal および ikecert certdb コマンドがハードウェアを識別しなければなりません。トークン ID に -T オプションを指定すると、コマンドがハードウェアを識別するようになります。

始める前に

  1. システムコンソール上で、Primary Administrator の役割を引き受けるか、スーパーユーザーになります。

    Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

    注 –

    リモートログインすると、セキュリティー上重要なトラフィックが盗聴される恐れがあります。何らかの方法でリモートログインを保護していても、システムのセキュリティーがリモートログインセッションレベルに低下します。セキュリティー保護されたリモートログインには、ssh コマンドを使用してください。

  2. 自己署名付き証明書または証明書要求を作成して、トークン ID を指定します。

    次のオプションのいずれかを選択します。

    注 –

    Sun Crypto Accelerator 4000 ボードは、RSA で最大 2048 ビットのキーをサポートします。DSA の場合は最大 1024 ビットになります。

    • 自己署名付き証明書の場合、次の構文を使用する


      # ikecert certlocal -ks -m 1024 -t rsa-md5 \
> -D "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" \
> -a -T dca0-accel-stor IP=192.168.116.16
Creating hardware private keys.
Enter PIN for PKCS#11 token: Type user:password

      -T オプションの引数は、Sun Crypto Accelerator 4000 ボードのトークン ID

    • 証明書要求の場合、次の構文を使用します。


      # ikecert certlocal -kc -m 1024 -t rsa-md5 \
> -D "C=US, O=PartyCompany, OU=US-Partym, CN=Partym" \
> -a -T dca0-accel-stor IP=192.168.116.16
Creating hardware private keys.
Enter PIN for PKCS#11 token: Type user:password

    ikecert コマンドの引数の詳細については、ikecert(1M) のマニュアルページを参照してください。

  3. PIN のプロンプトに、Sun Crypto Accelerator 4000 ユーザー、コロン、ユーザーのパスワードを入力します。

    Sun Crypto Accelerator 4000 ボードのユーザー ikemgr のパスワードが rgm4tigt の場合、次のように入力します。


    Enter PIN for PKCS#11 token: ikemgr:rgm4tigt
    注 –

    PIN の応答は、ディスク上に「クリアテキストとして」格納されます。

    パスワードの入力後、証明書が印刷されます。


    Enter PIN for PKCS#11 token: ikemgr:rgm4tigt
-----BEGIN X509 CERTIFICATE-----
MIIBuDCCASECAQAwSTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDFBhcnR5Q29tcGFu
…
oKUDBbZ9O/pLWYGr
-----END X509 CERTIFICATE-----

  4. 通信先に証明書を送信します。

    次のオプションのいずれかを選択します。

    • リモートシステムに自己署名付き証明書を送信します。

      証明書は、電子メールに貼り付けることもできます。

    • PKI を処理する機関に証明書要求を送信します。

      証明書要求は、PKI 機関の指示に従って送信します。詳細については、「CA からの署名付き証明書により IKE を設定する方法」の手順 3 を参照してください。

  5. システム上で、/etc/inet/ike/config ファイルを編集して、証明書が認識されるようにします。

    次のオプションのどちらか 1 つを選択します。

    • 自己署名付き証明書

      リモートシステムの管理者がパラメータ cert_trust、remote_id、および remote_addr 用に提供する値を使用します。たとえば、enigma システムの ike/config ファイルは次のようになります。


      # Explicitly trust the following self-signed certs
# Use the Subject Alternate Name to identify the cert

cert_trust "192.168.116.16"  Local system's certificate Subject Alt Name
cert_trust "192.168.13.213"  Remote system's certificate Subject Alt name


# Solaris 10 1/06 release: default path does not have to be typed in
#pkcs11_path "/usr/lib/libpkcs11.so" Hardware connection

# Solaris 10 release: use this path
#pkcs11_path "/opt/SUNWconn/cryptov2/lib/libvpkcs11.so"
…
{
 label "JA-enigmax to US-partym"
 local_id_type dn
 local_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax"
 remote_id "C=US, O=PartyCompany, OU=US-Partym, CN=Partym"

 local_addr  192.168.116.16
 remote_addr 192.168.13.213

 p1_xform
  {auth_method rsa_sig oakley_group 2 auth_alg sha1 encr_alg aes}
}

    • 証明書要求

      PKI 機関が cert_root キーワードの値として提供する名前を入力します。たとえば、enigma システムの ike/config ファイルは次のようになります。


      # Trusted root cert
# This certificate is from Example PKI
# This is the X.509 distinguished name for the CA that it issues.

cert_root "C=US, O=ExamplePKI\, Inc., OU=PKI-Example, CN=Example PKI"

# Solaris 10 1/06 release: default path does not have to be typed in
#pkcs11_path "/usr/lib/libpkcs11.so" Hardware connection

# Solaris 10 release: use this path
#pkcs11_path "/opt/SUNWconn/cryptov2/lib/libvpkcs11.so"
…
{
 label "JA-enigmax to US-partym - Example PKI"
 local_id_type dn
 local_id "C=JA, O=EnigmaCo, OU=JA-Enigmax, CN=Enigmax"
 remote_id  "C=US, O=PartyCompany, OU=US-Partym, CN=Partym"

 local_addr  192.168.116.16
 remote_addr 192.168.13.213

 p1_xform
  {auth_method rsa_sig oakley_group 2 auth_alg sha1 encr_alg aes}
}

  6. 通信先から受け取った証明書をハードウェアに格納します。

    手順 3 で応答したように、PIN 要求に応答します。

    注 –

    公開鍵証明書は、公開鍵を生成したハードウェアに追加する必要があります。

    • 自己署名付き証明書

      リモートシステムの自己署名付き証明書を追加します。この例では、証明書は DCA.ACCEL.STOR.CERT ファイルに格納されています。


      # ikecert certdb -a -T dca0-accel-stor < DCA.ACCEL.STOR.CERT
Enter PIN for PKCS#11 token: Type user:password

      自己署名付き証明書が rsa_encrypt を auth_method パラメータの値として使用していた場合、ピアの証明書をハードウェア格納場所に追加します。

    • PKI 機関からの証明書

      機関が証明書要求から生成した証明書を追加して、認証局 (CA) を追加します。


      # ikecert certdb -a -T dca0-accel-stor < DCA.ACCEL.STOR.CERT
Enter PIN for PKCS#11 token: Type user:password


      # ikecert certdb -a -T dca0-accel-stor < DCA.ACCEL.STOR.CA.CERT
Enter PIN for PKCS#11 token: Type user:password

      PKI 機関からの証明書失効リスト (CRL) を追加する方法については、「証明書失効リストを処理する方法」を参照してください。

Procedure証明書失効リストを処理する方法

証明書失効リスト (CRL) には、認証局が発行した証明書のうち、期限切れになったりセキュリティーが低下したりした証明書が含まれます。CRL を処理する方法には、次の 4 つがあります。

次の手順に、中央の配布ポイントから CRL を使用するように IKE に指示する手順を示します。

  1. CA から受信した証明書を表示する


    # ikecert certdb -lv certspec
    -l

    IKE 証明書データベースにある証明書を一覧表示します。

    -v

    証明書を冗長モードで一覧表示します。このオプションは慎重に使用してください。

    certspec

    IKE 証明書データベース内の証明書と一致するパターンです。

    たとえば、次の証明書は Sun Microsystems が発行しています。詳細は変更されています。


    # ikecert certdb -lv example-protect.sun.com
Certificate Slot Name: 0   Type: dsa-sha1
   (Private key in certlocal slot 0)
 Subject Name: <O=Sun Microsystems Inc, CN=example-protect.sun.com>
 Issuer Name: <CN=Sun Microsystems Inc CA (Cl B), O=Sun Microsystems Inc>
 SerialNumber: 14000D93
   Validity:
      Not Valid Before: 2002 Jul 19th, 21:11:11 GMT
      Not Valid After:  2005 Jul 18th, 21:11:11 GMT
   Public Key Info:
      Public Modulus  (n) (2048 bits): C575A…A5
      Public Exponent (e) (  24 bits): 010001
   Extensions:
      Subject Alternative Names:
              DNS = example-protect.sun.com
      Key Usage: DigitalSignature KeyEncipherment
      [CRITICAL]
   CRL Distribution Points:
      Full Name:
         URI = #Ihttp://www.sun.com/pki/pkismica.crl#i
         DN = <CN=Sun Microsystems Inc CA (Cl B), O=Sun Microsystems Inc>
      CRL Issuer: 
      Authority Key ID:
      Key ID:              4F … 6B
      SubjectKeyID:        A5 … FD
      Certificate Policies
      Authority Information Access

    CRL Distribution Points エントリに注目してください。URI エントリは、この機関の CRL が Web 上にあることを示しています。DN エントリは、CRL が LDAP サーバー上にあることを示しています。一度、IKE がアクセスすると、CRL は将来に備えてキャッシュに格納されます。

    CRL にアクセスするには、配布ポイントまで到達する必要があります。

  2. 中央の配布ポイントから CRL にアクセスするには、次のメソッドのうちの 1 つを選択します。

    • URI を使用します。

      キーワード use_http をホストの /etc/inet/ike/config ファイルに追加します。たとえば、ike/config ファイルは次のようになります。


      # Use CRL from organization's URI
use_http
…

    • Web プロキシを使用します。

      キーワード proxy を ike/config ファイルに追加します。キーワード proxy は、次のように引数として URL を取ります。


      # Use own web proxy
proxy "http://proxy1:8080"

    • LDAP サーバーを使用します。

      ホストの /etc/inet/ike/config ファイルの ldap-list キーワードに LDAP サーバーの名前を指定します。LDAP サーバーの名前は、使用する機関にたずねてください。ike/config ファイルのエントリは次のようになります。


      # Use CRL from organization's LDAP
ldap-list "ldap1.sun.com:389,ldap2.sun.com"
…

    IKE は CRL を取り出し、証明書の期限が切れるまで CRL を保持します。

例 23–7 CRL をローカルの certrldb データベースに貼り付ける

使用する機関の証明書に一元的な配布ポイントが含まれていない場合は、機関の CRL を手動でローカルの certrldb データベースに追加できます。機関の説明に従って CRL をファイルに抽出し、それを ikecert certrldb -a コマンドでデータベースに追加します。


# ikecert certrldb -a < Sun.Cert.CRL

移動体システム用の IKE の設定 (作業マップ)

次の表に、中央サイトにリモートからログインするシステムを処理するように、IKE を設定する手順を示します。

タスク 

説明 

説明 

オフサイトから中央サイトへ通信します 

遠隔地のシステムが中央サイトと通信できるようにします。遠隔地のシステムは移動体システムの可能性もあります。 

「遠隔地のシステム用に IKE を構成する方法」

移動体システムからのトラフィックを受信する中央システムでルート証明書と IKE を使用します 

固定 IP アドレスを持たないシステムからの IPsec トラフィックを受信するゲートウェイシステムを設定します。 

例 23–8

固定 IP アドレスを持たないシステムでルート証明書と IKE を使用します 

中央サイト (会社の本社など) とのトラフィックを保護するように、移動体システムを設定します。 

例 23–9

移動体システムからのトラフィックを受信する中央システムで自己署名付き証明書と IKE を使用します 

移動体システムから IPsec トラフィックを受信するように、ゲートウェイシステムを自己署名付き証明書で設定します。 

例 23–10

固定 IP アドレスを持たないシステムで自己署名付き証明書と IKE を使用します 

中央サイトとのトラフィックを保護するように、移動体システムを自己署名付き証明書で設定します。 

例 23–11

移動体システム用の IKE の設定

適切に設定することで、ホームオフィスやノートブックから IPsec と IKE を使用して、会社の中央コンピュータと通信できます。公開鍵認証方法と結びついたブランケット IPsec ポリシーを使用すると、遠隔地のシステムは中央システムとのトラフィックを保護できます。

Procedure遠隔地のシステム用に IKE を構成する方法

ソースと宛先を識別するために、IPsec と IKE は一意の ID を必要とします。一意の IP アドレスを持たない遠隔地のシステムまたは移動体システムの場合、別の種類の ID を使用する必要があります。システムを一意に識別するために、DNS、DN、または email などの ID の種類を使用できます。

一意の IP アドレスを持つ遠隔地のシステムまたは移動体システムで、別の種類の ID で設定するようにします。たとえば、システムが NAT 越しに中央システムに接続しようとした場合、そのシステムの一意なアドレスは使用されません。NAT ボックスが任意の IP アドレスを割り当てるため、中央システムは認識できません。

事前共有鍵は固定 IP アドレスを必要とするため、事前共有鍵も移動体システム用の認証機構としては機能しません。自己署名付き証明書 (または PKI からの証明書) を使用すると、移動体システムは中央サイトと通信できます。

  1. システムコンソール上で、Primary Administrator の役割を引き受けるか、スーパーユーザーになります。

    Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

    注 –

    リモートログインすると、セキュリティー上重要なトラフィックが盗聴される恐れがあります。何らかの方法でリモートログインを保護していても、システムのセキュリティーがリモートログインセッションレベルに低下します。セキュリティー保護されたリモートログインには、ssh コマンドを使用してください。

  2. 移動体システムを認識するように、中央システムを設定します。

    1. /etc/hosts ファイルを設定します。

      中央システムは、移動体システムの固有のアドレスを認識する必要はありません。


      # /etc/hosts on central
central 192.xxx.xxx.x

    2. ipsecinit.conf ファイルを設定します。

      中央システムには、IP アドレスの広い範囲を許可するポリシーを必要とします。そのあと、IKE ポリシーの証明書で接続システムが合法であることを確認します。


      # /etc/inet/ipsecinit.conf on central
# Keep everyone out unless they use this IPsec policy:
{} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

    3. ike.config ファイルを設定します。

      DNS は中央システムを識別します。証明書を使用して、システムを認証します。


      ## /etc/inet/ike/ike.config on central
# Global parameters
#
# Find CRLs by URI, URL, or LDAP
# Use CRL from organization's URI
use_http
#
# Use web proxy
proxy "http://somecache.domain:port/"
#
# Use LDAP server
ldap_server   "ldap-server1.domain.org,ldap2.domain.org:port"
#
# List CA-signed certificates
cert_root    "C=US, O=Domain Org, CN=Domain STATE"
#
# List self-signed certificates - trust server and enumerated others
#cert_trust    "DNS=central.domain.org"
#cert_trust    "DNS=mobile.domain.org"
#cert_trust    "DN=CN=Domain Org STATE (CLASS), O=Domain Org
#cert_trust    "email=root@central.domain.org"
#cert_trust    "email=user1@mobile.domain.org"
#

# Rule for mobile systems with certificate
{
  label "Mobile systems with certificate"
  local_id_type DNS

# Any mobile system who knows my DNS or IP can find me.

  local_id "central.domain.org"
  local_addr 192.xxx.xxx.x

# Root certificate ensures trust,
# so allow any remote_id and any remote IP address.
  remote_id ""
  remote_addr 0.0.0.0/0

p2_pfs 5

p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1 }
}

  3. 各移動体システムにログインして、中央システムを見つけるように構成します。

    1. /etc/hosts ファイルを設定します。

      /etc/hosts ファイルは、移動体システムのアドレスを必要としませんが、提供することは可能です。このファイルは、中央システムの公開 IP アドレスを含んでいる必要があります。


      # /etc/hosts on mobile
mobile 10.x.x.xx
central 192.xxx.xxx.x

    2. ipsecinit.conf ファイルを設定します。

      移動体システムは、公開 IP アドレスで中央システムを見つける必要があります。システムは同じ IPsec ポリシーで設定する必要があります。


      # /etc/inet/ipsecinit.conf on mobile
# Find central
{raddr 192.xxx.xxx.x} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

    3. ike.config ファイルを設定します。

      識別子は IP アドレスであってはなりません。移動体システムに有効な識別子は次のとおりです。

      • DN=ldap-directory-name

      • DNS=domain-name-server-address

      • email=email-address

      証明書を使用して、移動体システムを認証します。


      ## /etc/inet/ike/ike.config on mobile
# Global parameters
#
# Find CRLs by URI, URL, or LDAP
# Use CRL from organization's URI
use_http
#
# Use web proxy
proxy "http://somecache.domain:port/"
#
# Use LDAP server
ldap_server   "ldap-server1.domain.org,ldap2.domain.org:port"
#
# List CA-signed certificates
cert_root    "C=US, O=Domain Org, CN=Domain STATE"
#
# Self-signed certificates - trust me and enumerated others
#cert_trust    "DNS=mobile.domain.org"
#cert_trust    "DNS=central.domain.org"
#cert_trust    "DN=CN=Domain Org STATE (CLASS), O=Domain Org
#cert_trust    "email=user1@domain.org"
#cert_trust    "email=root@central.domain.org"
#
# Rule for off-site systems with root certificate
{
	label "Off-site mobile with certificate"
	local_id_type DNS

# NAT-T can translate local_addr into any public IP address
# central knows me by my DNS

	local_id "mobile.domain.org"
	local_addr 0.0.0.0/0

# Find central and trust the root certificate
	remote_id "central.domain.org"
	remote_addr 192.xxx.xxx.x

p2_pfs 5

p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1 }
}

  4. IKE の設定をカーネルに読み込みます。

    • Solaris 10 4/09 リリース以降では、ike サービスを使用可能にします。


      # svcadm enable svc:/network/ipsec/ike

    • Solaris 10 4/09 リリースより前のリリースを実行している場合は、システムを再起動します。


      # init 6

      あるいは、in.iked デーモンを停止および起動します。

例 23–8 移動体システムからの IPsec トラフィックを受信するための中央コンピュータの設定

IKE は、NAT ボックス越しのネゴシエーションを開始できます。しかし、IKE の理想的な設定は NAT ボックスをはさまないことです。次の例では、ルート証明書は CA によって発行されています。CA 証明書は、移動体システムと中央システムに格納されています。中央システムは NAT 越しのシステムからの IPsec ネゴシエーションを受け入れます。main1 は、遠隔地のシステムからの接続を受け入れることができる会社のシステムです。遠隔地のシステムを設定する方法については、例 23–9 を参照してください。


## /etc/hosts on main1
main1 192.168.0.100
 

## /etc/inet/ipsecinit.conf on main1
# Keep everyone out unless they use this IPsec policy:
{} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}
 

## /etc/inet/ike/ike.config on main1
# Global parameters
#
# Find CRLs by URI, URL, or LDAP
# Use CRL from organization's URI
use_http
#
# Use web proxy
proxy "http://cache1.domain.org:8080/"
#
# Use LDAP server
ldap_server   "ldap1.domain.org,ldap2.domain.org:389"
#
# List CA-signed certificate
cert_root "C=US, O=ExamplePKI Inc, OU=PKI-Example, CN=Example PKI"
#
# Rule for off-site systems with root certificate
{
  label "Off-site system with root certificate"
  local_id_type DNS
  local_id "main1.domain.org"
  local_addr 192.168.0.100

# Root certificate ensures trust,
# so allow any remote_id and any remote IP address.
  remote_id ""
  remote_addr 0.0.0.0/0

p2_pfs 5

p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1}
p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg aes auth_alg sha1}
p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1}
p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg aes auth_alg sha1}
}
例 23–9 NAT 越しのシステムの IPsec による設定

次の例では、ルート証明書は CA によって発行されており、移動体システムと中央システムに格納されています。mobile1 は、家から会社の本社に接続しています。インターネットサービスプロバイダ (ISP) ネットワークは NAT ボックスを使用しているため、ISP はmobile1 に非公開アドレスを割り当てることができます。NAT ボックスは、非公開アドレスを公開 IP アドレスに変換します。この公開アドレスは、ほかの ISP ネットワークノードと共有されます。企業の本社は NAT を越えません。企業の本社のコンピュータを設定する方法については、例 23–8 を参照してください。


## /etc/hosts on mobile1
mobile1 10.1.3.3
main1 192.168.0.100
 

## /etc/inet/ipsecinit.conf on mobile1
# Find main1
{raddr 192.168.0.100} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}
 

## /etc/inet/ike/ike.config on mobile1
# Global parameters
#
# Find CRLs by URI, URL, or LDAP
# Use CRL from organization's URI
use_http
#
# Use web proxy
proxy "http://cache1.domain.org:8080/"
#
# Use LDAP server
ldap_server   "ldap1.domain.org,ldap2.domain.org:389"
#
# List CA-signed certificate
cert_root "C=US, O=ExamplePKI Inc, OU=PKI-Example, CN=Example PKI"
#
# Rule for off-site systems with root certificate
{
  label "Off-site mobile1 with root certificate"
  local_id_type DNS
  local_id "mobile1.domain.org"
  local_addr 0.0.0.0/0

# Find main1 and trust the root certificate
  remote_id "main1.domain.org"
  remote_addr 192.168.0.100

p2_pfs 5

p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1 }
}
例 23–10 移動体システムからの自己署名付き証明書の受け入れ

次の例では、自己署名付き証明書が発行されており、移動体システムと中央システムに格納されています。main1 は、遠隔地のシステムからの接続を受け入れることができる会社のシステムです。遠隔地のシステムを設定する方法については、例 23–11 を参照してください。


## /etc/hosts on main1
main1 192.168.0.100
 

## /etc/inet/ipsecinit.conf on main1
# Keep everyone out unless they use this IPsec policy:
{} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}
 

## /etc/inet/ike/ike.config on main1
# Global parameters
#
# Self-signed certificates - trust me and enumerated others
cert_trust    "DNS=main1.domain.org"
cert_trust    "jdoe@domain.org"
cert_trust    "user2@domain.org"
cert_trust    "user3@domain.org"
#
# Rule for off-site systems with trusted certificate
{
  label "Off-site systems with trusted certificates"
  local_id_type DNS
  local_id "main1.domain.org"
  local_addr 192.168.0.100

# Trust the self-signed certificates
# so allow any remote_id and any remote IP address.
  remote_id ""
  remote_addr 0.0.0.0/0

p2_pfs 5

p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1 }
}
例 23–11 自己署名付き証明書による中央システムとの接続

次の例では、mobile1 は家から会社の本社に接続しています。自己署名付き証明書が発行されており、移動体システムと中央システムに格納されています。ISP ネットワークは NAT ボックスを使用しているため、ISP は mobile1 に非公開アドレスを割り当てることができます。NAT ボックスは、非公開アドレスを公開 IP アドレスに変換します。この公開アドレスは、ほかの ISP ネットワークノードと共有されます。企業の本社は NAT を越えません。企業の本社のコンピュータを設定する方法については、例 23–10 を参照してください。


## /etc/hosts on mobile1
mobile1 10.1.3.3
main1 192.168.0.100
 

## /etc/inet/ipsecinit.conf on mobile1
# Find main1
{raddr 192.168.0.100} ipsec {encr_algs aes encr_auth_algs sha1 sa shared}
 

## /etc/inet/ike/ike.config on mobile1
# Global parameters

# Self-signed certificates - trust me and the central system
cert_trust    "jdoe@domain.org"
cert_trust    "DNS=main1.domain.org"
#
# Rule for off-site systems with trusted certificate
{
  label "Off-site mobile1 with trusted certificate"
  local_id_type email
  local_id "jdoe@domain.org"
  local_addr 0.0.0.0/0

# Find main1 and trust the certificate
  remote_id "main1.domain.org"
  remote_addr 192.168.0.100

p2_pfs 5

p1_xform
{auth_method rsa_sig oakley_group 5 encr_alg blowfish auth_alg sha1 }
}

接続したハードウェアを検出するための IKE の設定 (作業マップ)

次の表に、接続したハードウェアを IKE に伝える手順を示します。IKE がハードウェアを使用できるようにするには、接続したハードウェアを IKE に伝える必要があります。ハードウェアを使用する手順については、「公開鍵証明書による IKE の設定」を参照してください。

注 –

オンチップハードウェアについては、IKE に通知する必要はありません。たとえば、UltraSPARC® T2 プロセッサには暗号化促進機能がありますが、オンチップアクセラレータを検出するよう IKE を構成する必要はありません。

作業 

説明 

説明 

IKE キーの操作を Sun Crypto Accelerator 1000 ボードで行います 

IKE を PKCS #11 ライブラリにリンクする 

「Sun Crypto Accelerator 1000 ボードを検出するように IKE を設定する方法」

IKE キーの操作とキーの格納を Sun Crypto Accelerator 4000 ボードで行います 

IKE を PKCS #11 ライブラリにリンクして、接続されたハードウェアの名前のリストを表示する 

「Sun Crypto Accelerator 4000 ボードを検出するように IKE を設定する方法」

接続したハードウェアを検出するように IKE を設定する

公開鍵証明書は、接続されたハードウェアに格納することもできます。Sun Crypto Accelerator 1000 ボードが提供するのはストレージのみです。Sun Crypto Accelerator 4000 および Sun Crypto Accelerator 6000 ボードによってストレージが提供され、公開鍵の操作をシステムからこのボードに移行することができます。

ProcedureSun Crypto Accelerator 1000 ボードを検出するように IKE を設定する方法

始める前に

次の手順では、Sun Crypto Accelerator 1000 ボードがシステムに接続されていると仮定します。さらに、ボードに必要なソフトウェアがすでにインストールされ、構成されているものとします。手順については、『Sun Crypto Accelerator 1000 Board Version 2.0 Installation and User’s Guide 』を参照してください。

  1. システムコンソール上で、Primary Administrator の役割を引き受けるか、スーパーユーザーになります。

    Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

    注 –

    リモートログインすると、セキュリティー上重要なトラフィックが盗聴される恐れがあります。何らかの方法でリモートログインを保護していても、システムのセキュリティーがリモートログインセッションレベルに低下します。セキュリティー保護されたリモートログインには、ssh コマンドを使用してください。

  2. PKCS #11 ライブラリがリンクされていることを確認します。

    PKCS #11 ライブラリがリンクされていることを確認するには、次のコマンドを実行します。


    # ikeadm get stats
Phase 1 SA counts:
Current:   initiator:          0   responder:          0
Total:     initiator:          0   responder:          0
Attempted: initiator:          0   responder:          0
Failed:    initiator:          0   responder:          0
           initiator fails include 0 time-out(s)
PKCS#11 library linked in from /usr/lib/libpkcs11.so
#

  3. Solaris 10 1/06: このリリース以降では、ソフトトークンキーストアにキーを格納できます。

    Solaris 暗号化フレームワークが提供するキーストアについては、cryptoadm(1M) のマニュアルページを参照してください。キーストアを使用する例については、Example 23–12 を参照してください。

ProcedureSun Crypto Accelerator 4000 ボードを検出するように IKE を設定する方法

始める前に

次の手順では、Sun Crypto Accelerator 4000 ボードがシステムに接続されていると仮定します。さらに、ボードに必要なソフトウェアがすでにインストールされ、構成されているものとします。手順については、『Sun Crypto Accelerator 4000 Board Version 1.1 Installation and User’s Guide』を参照してください。

Sun Crypto Accelerator 6000 ボードを使用している場合、手順については、『Sun Crypto Accelerator 6000 Board Version 1.1 User’s Guide』を参照してください。

  1. システムコンソール上で、Primary Administrator の役割を引き受けるか、スーパーユーザーになります。

    Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

    注 –

    リモートログインすると、セキュリティー上重要なトラフィックが盗聴される恐れがあります。何らかの方法でリモートログインを保護していても、システムのセキュリティーがリモートログインセッションレベルに低下します。セキュリティー保護されたリモートログインには、ssh コマンドを使用してください。

  2. PKCS #11 ライブラリがリンクされていることを確認します。

    IKE はライブラリのルーチンを使用して、Sun Crypto Accelerator 4000 ボード上でキーの生成および格納処理を行います。PKCS #11 ライブラリがリンクされていることを確認するには、次のコマンドを実行します。


    $ ikeadm get stats
…
PKCS#11 library linked in from /usr/lib/libpkcs11.so
$
    注 –

    Sun Crypto Accelerator 4000 ボードは、RSA で最大 2048 ビットのキーをサポートします。DSA の場合は最大 1024 ビットになります。

  3. 接続された Sun Crypto Accelerator 4000 ボードのトークン ID を見つけます。


    $ ikecert tokens
Available tokens with library "/usr/lib/libpkcs11.so":

"Sun Metaslot                     "

    ライブラリは、32 文字のトークン ID (キーストア名 とも呼ぶ) を戻します。この例では、ikecert コマンドに Sun Metaslot トークンを使用すると、IKE 鍵を格納および高速化できます。

    トークンを使用する手順については、「ハードウェア上で公開鍵証明書を生成、格納する方法」を参照してください。

    ikecert コマンドにより、後続スペースが自動的に付加されます。

例 23–12 メタスロットトークンの検索と使用

トークンは、ディスク、接続されたボード、または Solaris 暗号化フレームワークが提供するソフトトークンキーストアに格納できます。次に、ソフトトークンキーストアのトークン ID の例を示します。


$ ikecert tokens
Available tokens with library "/usr/lib/libpkcs11.so":

"Sun Metaslot                   "

ソフトトークンキーストアのパスフレーズを作成する方法については、pktool(1) のマニュアルページを参照してください。

次に、ソフトトークンキーストアに証明書を追加するコマンドの例を示します。Sun.Metaslot.cert は、CA 証明書を格納しているファイルです。


# ikecert certdb -a -T "Sun Metaslot" < Sun.Metaslot.cert
Enter PIN for PKCS#11 token: Type user:passphrase

IKE 転送パラメータの変更 (作業マップ)

次の表に、IKE 用の転送パラメータを構成する手順を示します。

タスク 

説明 

説明 

鍵ネゴシエーションをより効率的にします 

鍵ネゴシエーションパラメータを変更します。 

「フェーズ 1 IKE 鍵ネゴシエーションの持続時間を変更する方法」

転送で遅延を許可するように鍵ネゴシエーションを構成します 

鍵ネゴシエーションパラメータを長くします。 

例 23–13

すばやく成功したり、すばやく障害を見つけるように鍵ネゴシエーションを構成します 

鍵ネゴシエーションパラメータを短くします。 

例 23–14

IKE 転送パラメータの変更

IKE が鍵ネゴシエーションを行うとき、転送速度がネゴシエーションの成功に影響します。通常、IKE 転送パラメータのデフォルト値を変更する必要はありません。しかし、非常に悪い回線で鍵ネゴシエーションを最適化したり、問題を再現したりするときには、転送パラメータの値を変更してもかまいません。

持続時間を長くすると、信頼性の低い転送回線で鍵ネゴシエーションを行うことができます。初期試行が成功するためには、特定のパラメータを長くします。初期試行が成功しない場合、後続の試行の間を空けることによって、ネゴシエーション全体が成功する時間を提供できます。

持続時間を短くすると、信頼性の高い転送回線で鍵ネゴシエーションを行うことができます。 持続時間が短くなると、ネゴシエーションが失敗したときに素早く再試行するため、ネゴシエーション全体の速度が上がります。問題を診断するときにも、ネゴシエーションの速度を上げると、障害をすばやく再現できます。持続時間を短くすると、フェーズ 1 SA が自分の寿命に使用できるようになります。

Procedureフェーズ 1 IKE 鍵ネゴシエーションの持続時間を変更する方法

  1. システムコンソール上で、Primary Administrator の役割を引き受けるか、スーパーユーザーになります。

    Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

    注 –

    リモートログインすると、セキュリティー上重要なトラフィックが盗聴される恐れがあります。何らかの方法でリモートログインを保護していても、システムのセキュリティーがリモートログインセッションレベルに低下します。セキュリティー保護されたリモートログインには、ssh コマンドを使用してください。

  2. 各システムのグローバル転送パラメータのデフォルト値を変更します。

    システムごとに、/etc/inet/ike/config ファイルのフェーズ 1 持続時間パラメータを変更します。


    ### ike/config file on system

## Global parameters
#
## Phase 1 transform defaults
#
#expire_timer      300
#retry_limit         5
#retry_timer_init    0.5 (integer or float)
#retry_timer_max    30   (integer or float)
    expire_timer

    完了していない IKE フェーズ 1 ネゴシエーションを残しておく秒数。この時間が過ぎると、ネゴシエーションの試行は削除されます。デフォルトは 30 秒です。

    retry_limit

    再転送の最大数。この回数を過ぎると、IKE ネゴシエーションは中断されます。デフォルトは 5 回です。

    retry_timer_init

    再転送の間隔の初期値。retry_timer_max 値に到達するまで、再転送ごとに、その間隔は 2 倍にされます。デフォルトは 0.5 秒です。

    retry_timer_max

    再転送の間隔の最大値。再転送の間隔は、この値より大きくはなりません。デフォルトは 30 秒です。

  3. 変更した設定をカーネルに読み込みます。

    • Solaris 10 4/09 リリース以降では、ike サービスを更新します。


      # svcadm refresh svc:/network/ipsec/ike

    • Solaris 10 4/09 リリースより前のリリースを実行している場合は、システムを再起動します。


      # init 6

      あるいは、in.iked デーモンを停止および起動します。

例 23–13 IKE フェーズ 1 ネゴシエーションの時間を長くする

次の例では、システムと IKE ピアはトラフィックが多い転送回線で接続されています。オリジナルの設定は、ファイルのコメント行にあります。新しい設定は、ネゴシエーションの時間を長くしています。


### ike/config file on partym
## Global Parameters
#
## Phase 1 transform defaults
#expire_timer   300
#retry_limit      5
#retry_timer_init 0.5 (integer or float)
#retry_timer_max 30   (integer or float)
#
expire_timer  600
retry_limit  10
retry_timer_init  2.5
retry_timer_max  180
例 23–14 IKE フェーズ 1 ネゴシエーションの時間を短くする

次の例では、システムと IKE ピアはトラフィックが少ない高速回線で接続されています。オリジナルの設定は、ファイルのコメント行にあります。新しい設定は、ネゴシエーションの時間を短くしています。


### ike/config file on partym
## Global Parameters
#
## Phase 1 transform defaults
#expire_timer   300
#retry_limit      5
#retry_timer_init 0.5 (integer or float)
#retry_timer_max 30   (integer or float)
#
expire_timer  120
retry_timer_init  0.20

第 24 章 インターネットキー交換 (リファレンス)

この章では、IKE に関する次のリファレンス情報について説明します。

IKE の実装方法については、第 23 章IKE の設定 (手順)を参照してください。概要については、第 22 章インターネットキー交換 (概要)を参照してください。

サービス管理機能

svc:/network/ipsec/ike:default サービス – service サービス管理機能 (SMF) では、IKE を管理するための ike サービスが提供されています。デフォルトでは、このサービスは無効になっています。このサービスを有効にする前に、IKE 構成ファイル /etc/inet/ike/config を作成する必要があります。

次に示す ike サービスのプロパティーは構成可能です。

SMF の詳細については、『Solaris のシステム管理 (基本編)』の第 18 章「サービスの管理 (概要)」を参照してください。smf(5)、svcadm(1M)、および svccfg(1M) のマニュアルページも参照してください。

IKE デーモン

in.iked デーモンは、Solaris システム上で IPsec の暗号化キーの管理を自動化します。また、同じプロトコルを実行するリモートシステムとのネゴシエーションを行い、認証された鍵情報が、保護された方法でセキュリティーアソシエーション (SA) に提供されます。そのデーモンは、セキュリティー保護された通信を行うすべてのシステムで実行する必要があります。

デフォルトでは、svc:/network/ipsec/ike:default サービスは無効になっています。/etc/inet/ike/config ファイルを設定し、ike サービスを有効にしたら、システム起動時に in.iked デーモンが実行されます。

IKE デーモンを実行すると、システムは、フェーズ 1 交換でそのピア IKE エンティティーに対してそのシステム自体を認証します。そのピアは、認証方式として IKE ポリシーファイルに定義されています。そのあと、デーモンはフェーズ 2 のキーが設定します。ポリシーファイルで指定した時間間隔で、IKE キーが自動的に更新されます。in.iked デーモンを実行すると、ネットワークからの着信 IKE 要求と PF_KEY ソケット経由の出力トラフィックの要求を待機します。詳細は、pf_key(7P) のマニュアルページを参照してください。

2 つのコマンドが IKE デーモンをサポートします。ikeadm コマンドを使用すると、IKE ポリシーの表示および一時的な変更を行うことができます。IKE ポリシーを永続的に変更するには、ike サービスのプロパティーを変更する必要があります。手順については、「IKE の事前共有鍵を表示する方法」を参照してください。

ikecert コマンドを実行すると、公開鍵データベースを表示および変更できます。このコマンドでは、ローカルデータベース ike.privatekeys と publickeys を管理します。公開鍵の操作とハードウェア上の公開鍵の記憶領域も管理します。

IKE ポリシーファイル

IKE ポリシー用の構成ファイル /etc/inet/ike/config は、IPsec ポリシーファイル /etc/inet/ipsecinit.conf の中で保護されているインタフェースのキーを管理します。IKE ポリシーファイルは、IKE のキーと IPsec SA のキーを管理します。IKE デーモン自体は、フェーズ 1 交換で鍵情報を要求します。

IKE での鍵管理には、ルールとグローバルパラメータが関係します。IKE ルールは、その鍵情報で保護するシステムやネットワークを識別します。さらに、ルールは認証方式も指定します。グローバルパラメータには、接続されたハードウェアアクセラレータへのパスなどがあります。IKE ポリシーファイルの例については、「事前共有鍵による IKE の設定 (作業マップ)」を参照してください。IKE ポリシーエントリの例と説明については、ike.config(4) のマニュアルページを参照してください。

IKE がサポートする IPsec SA は、IPsec ポリシーの設定ファイル /etc/inet/ipsecinit.conf で設定されるポリシーに従って IP データグラムを保護します。IPsec SA の作成時に perfect forward security (PFS) を使用するかどうかは、IKE ポリシーファイルで決まります。

ike/config ファイルには、 RSA Security Inc. PKCS #11 Cryptographic Token Interface (Cryptoki) に準拠して実装されているライブラリへのパスを含めることができます。IKE は、この PKCS #11 ライブラリを使って、アクセラレータおよびキーストレージハードウェアにアクセスします。

ike/config ファイルのセキュリティーに関する注意点は、ipsecinit.conf ファイルのセキュリティーと同様です。詳細は、「ipsecinit.conf と ipsecconf のセキュリティーについて」を参照してください。

IKE 管理コマンド

ikeadm コマンドを実行すると、次のことができます。

このコマンドのオプションの例と詳しい説明については、ikeadm(1M) のマニュアルページを参照してください。

実行する IKE デーモンの特権レベルにより、表示および変更可能な IKE デーモンの要素が決まります。使用可能な特権レベルは 3 つあります。

base レベル

鍵情報を表示したり変更したりすることはできません。base レベルはデフォルトの特権レベルです。

modkeys レベル

事前共有鍵の削除、変更、追加ができます。

keymat レベル

ikeadm コマンドで実際の鍵情報を表示できます。

特権を一時的に変更する場合は、ikeadm コマンドを使用できます。永続的に変更する場合は、ike サービスの admin_privilege プロパティーを変更します。手順については、「IKE および IPsec サービスを管理する方法」を参照してください。

ikeadm コマンドのセキュリティーについては、ipseckey コマンドのセキュリティーと同様です。詳細は、「ipseckey におけるセキュリティーについて」を参照してください。

IKE 事前共有鍵ファイル

事前共有鍵を手動で作成すると、キーは、/etc/inet/secret ディレクトリのファイルに格納されます。ike.preshared ファイルに Internet Security Association and Key Management Protocol (ISAKMP) SA の事前共有鍵が含まれ、ipseckeys ファイルに IPsec SA の事前共有鍵が含まれます。これらのファイルは 0600 で保護されます。secret ディレクトリは 0700 で保護されます。

注 –

事前共有鍵は、ハードウェア記憶領域を利用できません。事前共有鍵は、生成後、システムに格納されます。

IKE 公開鍵のデータベースおよびコマンド

ikecert コマンドを実行すると、ローカルシステムの公開鍵データベースを操作できます。このコマンドは、ike/config ファイルが公開鍵証明書を要求するときに使用します。IKE ではそれらのデータベースを使用してフェーズ 1 交換を認証するため、in.iked デーモンを起動する前に、それらのデータベースに必要な情報が含まれていなければなりません。3 つのサブコマンド certlocal、certdb、certrldb をそれぞれ実行して、3 つのデータベースを処理します。

ikecert コマンドはキーの格納処理も行います。キーは、ディスク、接続された Sun Crypto Accelerator 6000、&sca 4; ボード、またはソフトトークンキーストアに格納できます。ソフトトークンキーストアは、ハードウェアデバイスと通信するために、Solaris 暗号化フレームワークのメタスロットを使用しているときに使用できます。ikecert コマンドは、PKCS #11 ライブラリを使用してキーの格納場所を見つけます。

詳細は、ikecert(1M) のマニュアルページを参照してください。メタスロットとソフトトークンキーストアについては、cryptoadm(1M) のマニュアルページを参照してください。

ikecert tokens コマンド

tokens 引数を使用すると、使用可能なトークン ID がリストされます。トークン ID により、ikecert certlocal コマンドと ikecert certdb コマンドは、公開鍵証明書と証明書要求を生成します。これらの証明書と証明書要求は、暗号化フレームワークによってソフトトークンキーストアに格納するか、接続された Sun Crypto Accelerator 6000 または &sca 4; ボードに格納することができます。ikecert コマンドは、PKCS #11 ライブラリを使用して証明書の格納場所を見つけます。

ikecert certlocal コマンド

certlocal サブコマンドは非公開鍵データベースを管理します。このサブコマンドを選択すると、非公開鍵の追加、表示、および削除を行うことができます。また、自己署名付き証明書または証明書要求のいずれかを作成できます。-ks オプションを選択すると、自己署名付き証明書が作成されます。-kc オプションを選択すると、証明書要求が作成されます。鍵はシステムの /etc/inet/secret/ike.privatekeys ディレクトリに格納されます。-T オプションを指定した場合は、システムに接続されたハードウェアに格納されます。

非公開鍵を作成する場合は、ikecert certlocal コマンドへのサブコマンドに関連するエントリが ike/config ファイルに存在しなければなりません。ikecert オプションと ike/config エントリの対応を次の表に示します。

表 24–1 ikecert オプションと ike/config エントリの対応表

ikecert オプション

ike/config エントリ

説明 

-A subject-alternate-name

cert_trust subject-alternate-name

証明書を一意に識別するニックネーム。指定可能な値は IP アドレス、電子メールアドレス、およびドメイン名です。 

-D X.509-distinguished-name

X.509-distinguished-name

国 (C)、組織名 (ON)、組織単位 (OU)、共通名 (CN) を含む認証局のフルネーム。 

-t dsa-sha1

auth_method dss_sig

RSAよりもわずかに遅い認証方式。

-t rsa-md5 および

-t rsa-sha1

auth_method rsa_sig

DSAよりもわずかに速い認証方式。

RSA 公開鍵は、最大ペイロードを暗号化するのに十分な長さが必要。通常、X.509 識別名などの ID ペイロードが最大ペイロードになります。

-t rsa-md5 および

-t rsa-sha1

auth_method rsa_encrypt

RSA 暗号化により、IKE にある ID が不正侵入者から保護されますが、IKE ピアには互いの公開鍵の認識が要求されます。 

-T

pkcs11_path

PKCS #11 ライブラリは、Sun Crypto Accelerator 1000 ボード、Sun Crypto Accelerator 6000 ボード、および Sun Crypto Accelerator 4000 ボード上のアクセラレータを処理します。また、このライブラリは、Sun Crypto Accelerator 6000 および Sun Crypto Accelerator 4000 ボード上のキーストレージを処理するトークンも提供します。

ikecert certlocal -kc コマンドを指定して証明書要求を実行する場合、そのコマンド出力を PKI 機関または認証局 (CA) に送信します。会社が独自の PKI を運営している場合は、出力を PKI 管理者に送信します。PKI 機関、CA、または PKI の管理者はこれに基づいて証明書を作成します。PKI または CA から返された証明書は、certdb サブコマンドに渡されます。PKI から返された証明書失効リスト (CRL) は、certrldb サブコマンドに渡されます。

ikecert certdb コマンド

certdb サブコマンドは、公開鍵データベースを管理します。そのサブコマンドを選択すると、公開鍵と証明書を追加、表示、および削除できます。また、リモートシステムで ikecert certlocal -ks コマンドを実行して作成された証明書を入力として受け入れます。手順については、「自己署名付き公開鍵証明書により IKE を設定する方法」を参照してください。さらに、PKI または CA から受信する証明書も入力として受け入れます。手順については、「CA からの署名付き証明書により IKE を設定する方法」を参照してください。

証明書と公開鍵は、システムの /etc/inet/ike/publickeys ディレクトリに格納されます。-T オプションを指定した場合、証明書、非公開鍵、公開鍵は、システムに接続されたハードウェアに格納されます。

ikecert certrldb コマンド

certrldb サブコマンドは、証明書失効リスト (CRL) データベース /etc/inet/ike/crls を管理します。CRL データベースには、公開鍵の失効リストが保存されています。よって、このリストには、すでに有効でない証明書が明記されます。PKI によって CRL が提供されるときに、ikecert certrldb コマンドを指定して CRL データベースにその CRL を格納します。手順については、「証明書失効リストを処理する方法」を参照してください。

/etc/inet/ike/publickeys ディレクトリ

/etc/inet/ike/publickeys ディレクトリの複数のファイルまたは「スロット」には、公開鍵と非公開鍵のペアの公開部分とその証明書が含まれています。このディレクトリは 0755 で保護されています。ikecert certdb コマンドを使用して、そのディレクトリを読み込みます。-T オプションを指定すると、鍵は publickeys ディレクトリではなく Sun Crypto Accelerator 6000 または &sca 4; ボード上に格納されます。

スロットには、別のシステムで生成された証明書の X.509 識別名が符号化された形式で含まれます。自己署名付き証明書を使用する場合、そのコマンドへの入力として、リモートシステムの管理者から受信する証明書を使用します。CA からの証明書を使用する場合、CA から受け取る 2 つの署名付き証明書をこのデータベースに格納します。CA に送信した証明書署名要求に基づいた証明書を格納します。また、CA の証明書も格納します。

/etc/inet/secret/ike.privatekeys ディレクトリ

/etc/inet/secret/ike.privatekeys ディレクトリには、公開鍵非公開鍵ペアの一部である公開鍵ファイルが入っています。このペアはISAKMP SA の鍵情報です。このディレクトリは 0700 で保護されています。ikecert certlocal コマンドを実行して、ike.privatekeys ディレクトリを読み込みます。非公開鍵は、ペアとなる公開鍵、自己署名付き証明書や CA が格納されてから有効になります。ペアとなる公開鍵は、/etc/inet/ike/publickeys ディレクトリか、Sun Crypto Accelerator 6000 または Sun Crypto Accelerator 4000 ボードに格納されます。

/etc/inet/ike/crls ディレクトリ

/etc/inet/ike/crls ディレクトリには、証明書失効リスト (CRL) ファイルが含まれています。各ファイルは、/etc/inet/ike/publickeys ディレクトリにある公開鍵証明書ファイルに対応しています。PKI 機関により、それらの証明書の CRL が提供されます。ikecert certrldb コマンドを使用して、そのデータベースを読み込むことができます。

第 25 章 Oracle Solaris IP フィルタ (概要)

この章では、Oracle Solaris IP フィルタの概要を紹介します。Oracle Solaris IP フィルタを使用した作業については、第 26 章Oracle Solaris IP フィルタ (作業)を参照してください。

この章では、次の内容について説明します。

Oracle Solaris IP フィルタの新機能

この節では、Oracle Solaris IP フィルタの新しい機能について説明します。

新機能の完全な一覧や各 Oracle Solaris リリースの説明については、『Oracle Solaris 10 9/10 の新機能』を参照してください。

パケットフィルタリングフック

Solaris 10 7/07 リリース以降では、Oracle Solaris でのパケットフィルタリングにパケットフィルタリングフックが使用されるようになりました。この機能は、システム管理に次のような利点をもたらします。

これらのフックの詳細については、「パケットフィルタリングフック」を参照してください。パケットフィルタリングフックに関する作業については、第 26 章Oracle Solaris IP フィルタ (作業)を参照してください。

Oracle Solaris IP フィルタの IPv6 パケットフィルタリング

Solaris 10 6/06: ネットワークインフラストラクチャーの全部または一部を IPv6 で構成しているシステム管理者のために、Oracle Solaris IP フィルタが IPv6 パケットフィルタリングに対応できるように拡張されています。IPv6 パケットフィルタリングでは、発信元または宛先の IPv6 アドレス、IPv6 アドレスを含むプール、および IPv6 拡張ヘッダーに基づいて、パケットを取り出すことができます。

ipf コマンドと ipfstat コマンドを IPv6 に使用できるように、-6 オプションが追加されています。ipmon コマンドと ippool コマンドのコマンド行インタフェースに変更はありませんが、これらのコマンドは IPv6 でも使用することができます。ipmon コマンドは、IPv6 パケットのログを記録できるように拡張されており、ippool コマンドは、IPv6 アドレスをプールに格納することができます。

詳細は、「IPv6 と Oracle Solaris IP フィルタ」を参照してください。IPv6 パケットフィルタリングに関する作業については、第 26 章Oracle Solaris IP フィルタ (作業)を参照してください。

Oracle Solaris IP フィルタとは

Oracle Solaris IP フィルタは、Oracle Solaris のファイアウォールソフトウェアとして SunScreen ファイアウォールを置き換えます。SunScreen ファイアウォール同様、Oracle Solaris IP フィルタは、ステートフルパケットフィルタリングとネットワークアドレス変換 (NAT) を行います。Oracle Solaris IP フィルタには、ステートレスパケットのフィルタリングとアドレスプールの作成と管理を行う機能もあります。

パケットのフィルタリングは、ネットワークベースの攻撃に対する基本的な保護を提供します。Oracle Solaris IP フィルタは、IP アドレス、ポート、プロトコル、ネットワークインタフェース、およびトラフィックの転送方向を元にフィルタリングを行うことができます。また、発信元 IP アドレス、宛先 IP アドレス、IP アドレスの範囲、またはアドレスプールによってもフィルタリングを行うことができます。

Oracle Solaris IP フィルタは、オープンソースの IP Filter ソフトウェアをベースにしています。オープンソースの IP Filter のライセンス契約、作者、および著作権宣言文を参照するためのデフォルトパスは、/usr/lib/ipf/IPFILTER.LICENCE です。Oracle Solaris がデフォルト以外の場所にインストールされている場合は、所定のパスを修正して、インストールした場所にあるファイルにアクセスします。

オープンソースの IP Filter の情報源

Darren Reed によるオープンソースの IP Filter ソフトウェアのホームページは、http://coombs.anu.edu.au/~avalon/ip-filter.html にあります。このサイトには、オープンソースの IP Filter に関する情報が含まれており、チュートリアル「IP Filter Based Firewalls HOWTO」(Brendan Conoboy および Erik Fichtner、2002) へのリンクも含まれています。このチュートリアルは、BSD UNIX 環境でファイアウォールを作成する方法を手順ごとに説明しています。このチュートリアルは BSD UNIX 環境向けに書かれていますが、Oracle Solaris IP フィルタの構成にも関連しています。

Oracle Solaris IP フィルタのパケット処理

Oracle Solaris IP フィルタは、パケットが処理されるときに一連の手順を実行します。次の図は、パケット処理の段階と、フィルタが TCP/IP プロトコルスタックとどのように統合されるかを示しています。

図 25–1 パケット処理の順序

Oracle Solaris IP フィルタのパケット処理に関連する手順の順序を示しています。

パケット処理には次の手順が含まれます。

OpenSolaris IP フィルタの使用ガイドライン

Oracle Solaris IP フィルタの構成ファイルの使用

Oracle Solaris IP フィルタを使用して、ファイアウォールサービスまたはネットワークアドレス変換 (NAT) を提供できます。Oracle Solaris IP フィルタは、ロード可能な構成ファイルを使用して実行できます。Oracle Solaris IP フィルタには、/etc/ipf というディレクトリがあります。/etc/ipf ディレクトリには、ipf.conf、ipnat.conf および ippool.conf と呼ばれる構成ファイルを作成して、保存できます。 /etc/ipf ディレクトリに保存されている場合、これらのファイルは、起動プロセスで自動的にロードされます。構成ファイルを別の場所に保存して、これらのファイルを手動でロードすることも可能です。構成ファイルの例については、「Oracle Solaris IP フィルタ構成ファイルの作成と編集」を参照してください。

Oracle Solaris IP フィルタ規則セットの処理

ファイアウォールを管理するために、Oracle Solaris IP フィルタを使用して、ネットワークトラフィックをフィルタリングするために使用する規則セットを指定します。次の種類の規則セットを作成できます。

さらに、まとまった IP アドレスを参照するために、アドレスプールを作成することもできます。作成したプールは、あとで規則セット内で使用できます。アドレスプールは、規則処理を速めるために役立ちます。また、アドレスプールによって、大きなまとまりのアドレスをより簡単に管理できます。

Oracle Solaris IP フィルタのパケットフィルタリング機能の使用

パケットフィルタリング規則セットを使用して、パケットのフィルタリングを設定します。ipf コマンドで、パケットフィルタリング規則セットを処理します。ipf コマンドの詳細については、ipf(1M) コマンドを参照してください。

パケットフィルタリング規則は、ipf コマンドによってコマンド行で作成することも、パケットフィルタリングの構成ファイル内で作成することもできます。起動時にパケットフィルタリング規則をロードする場合は、パケットフィルタリング規則を保存する /etc/ipf/ipf.conf という構成ファイルを作成します。 起動時にパケットフィルタリング規則をロードしない場合は、適当な場所に ipf.conf ファイルを保存し、 ipf コマンドによってパケットフィルタリングを手動でアクティブ化します。

Oracle Solaris IP フィルタには、アクティブ規則セットと非アクティブ規則セットの 2 つのパケットフィルタリング規則セットを格納できます。大部分の場合、作業ではアクティブ規則セットを使用します。ただし、ipf -I コマンドを使用すると、コマンドアクションを非アクティブ規則リストに適用できます。非アクティブ規則リストは、ユーザーが選択しない限り、Oracle Solaris IP フィルタによって使用されることはありません。非アクティブ規則リストによって、アクティブなパケットのフィルタリングに影響を与えずに、規則を保存できます。

Oracle Solaris IP フィルタは、パケットを通過させる、またはブロックする前に、設定された規則リストの最初から最後まで規則を処理します。Oracle Solaris IP フィルタは、パケットを通過させるかどうかを決めるフラグを格納しています。フラグは、規則セット全体を調べ、最後に一致した規則を基にパケットを通過させるか、ブロックするかを決定します。

このプロセスには、2 つの例外があります。最初の例外は、パケットが quick キーワードを含む規則に一致した場合です。規則が quick キーワードを含む場合は、その規則に対する処理が実行され、それ以降の規則はチェックされません。2 番目の例外は、パケットが group キーワードを含む規則に一致した場合です。パケットがグループに一致すると、グループでタグ付けされた規則だけがチェックされます。

パケットのフィルタリング規則の構成

パケットのフィルタリング規則を作成するには、次の構文を使用します。

action [in|out] option keyword, keyword...

  1. 各規則がアクションを開始します。Oracle Solaris IP フィルタは、パケットが規則に一致する場合、アクションを実行します。次の一覧に、パケットに対して実行される一般的なアクションを示します。

    block

    パケットはフィルタを通過できません。

    pass

    パケットはフィルタを通過します。

    log

    パケットをロギングしますが、パケットをブロックするか、通過させるかの決定は行いません。ログを参照するには、ipmon コマンドを使用します。

    count

    フィルタの統計にパケットを含めます。統計を参照するには、 ipfstat コマンドを使用します。

    skip number

    フィルタは number フィルタリング規則をスキップします。

    auth

    パケット情報を確認するユーザープログラムが実行するパケット認証を要求します。このプログラムは、パケットを通過させるか、ブロックするかを決定します。

    preauth

    パケットの処理を決定するにあたって、フィルタが事前認証リストを参照するように要求します。

  2. アクション後の出力は、in または out のはずです。ユーザーの選択により、パケットのフィルタリング規則が、受信パケットと発信パケットのどちらに適用されるのかが決定されます。

  3. 次に、オプションの一覧からオプションを選択します。複数のオプションを使用する場合は、次の順序で使用してください。

    log

    規則が最後に一致した規則の場合、パケットをロギングします。ログを参照するには、ipmon コマンドを使用します。

    quick

    パケットが一致した場合、quick オプションを含む規則を実行します。これ以上の規則チェックは行われません。

    on interface-name

    パケットが指定したインタフェースを出入りする場合だけ、規則を適用します。

    dup-to interface-name

    パケットをコピーし、interface-name 上の複製を任意で指定した IP アドレスに送信します。

    to interface-name

    パケットを interface-name の出力キューに移動します。

  4. オプションの指定後、パケットが規則に一致するかどうかを決定するさまざまなキーワードを選択できます。次のキーワードは、以下の順序で使用してください。

    注 –

    デフォルトでは、構成ファイルのいずれの規則にも一致しないパケットは、すべてフィルタを通過します。

    tos

    16 進数または 10 進数の整数で表されたサービスタイプの値を基に、パケットをフィルタリングします。

    ttl

    生存期間の値を基に、パケットの一致を取ります。パケットに保存されている生存期間の値は、破棄される前にパケットがネットワーク上に存在できる期間を示します。

    proto

    特定のプロトコルに対して一致を取ります。/etc/protocols ファイルに指定されている任意のプロトコル名を使用したり、そのプロトコルを表す 10 進数の数を指定したりできます。キーワード tcp/udp は、TCP または UDP パケットとの一致を取るために使用できます。

    from/to/all/ any

    発信元 IP アドレス、宛先 IP アドレス およびポート番号のいずれか、 またはすべてに対して一致を取ります。all キーワードは、すべての発信元からのパケットおよびすべての宛先へのパケットを受諾するために使用します。

    with

    パケットに関連する指定された属性に対して一致を取ります。オプションがない場合にパケットを一致させるには、キーワードの前に not または no と記述します。

    flags

    設定されている TCP フラグを基にフィルタリングを行う TCP で使用します。TCP フラグについては、ipf(4) のマニュアルページを参照してください。

    icmp-type

    ICMP のタイプによってフィルタリングを行います。このキーワードは proto オプションが icmp に設定されているときに使用され、flags オプションが指定されているときは使用されません。

    keep keep-options

    保存しておくパケットの情報を決定します。使用可能な keep-options には、state オプションと frags オプションなどがあります。state オプションは、セッションに関する情報を、TCP、UDP、および ICMP パケットで保存できます。frags オプションは、パケットのフラグメントに関する情報を保存し、後のフラグメントにその情報を適用します。keep-options は、一致したパケットをアクセス制御リストのチェックなしで、通過させます。

    head number

    番号 number で指定されるフィルタリング規則に対して、新しいグループを作成します。

    group number

    デフォルトグループではなく、グループ番号 number のグループに規則を追加します。ほかのグループを指定しない場合は、すべてのフィルタリング規則がグループ 0 に保存されます。

次の例は、規則を作成するためにパケットのフィルタリング規則構文をまとめる方法を示しています。IP アドレス 192.168.0.0/16 からの受信トラフィックをブロックするには、規則リストに次の規則を含めます。


block in quick from 192.168.0.0/16 to any

パケットフィルタリング規則を記述するときの詳細な文法および構文については、ipf(4) のマニュアルページを参照してください。パケットのフィルタリングに関する作業については、「Oracle Solaris IP フィルタのパケットフィルタリング規則セットの管理」を参照してください。この例の IP アドレススキーム (192.168.0.0/16 ) については、 第 2 章TCP/IP ネットワークの計画 (手順)を参照してください。

Oracle Solaris IP フィルタの NAT 機能の使用

NAT は、発信元 IP アドレスと宛先 IP アドレスをほかのインターネットアドレスまたはイントラネットアドレスに変換するマッピング規則を設定します。これらの規則は、受信 IP パケットまたは発信 IP パケットの 発信元アドレスおよび宛先アドレスを変更し、パケットを送信します。また、NAT を使用して、あるポートから別のポートにトラフィックの方向を変更することもできます。NAT は、パケットに修正または方向の変更が行われても、パケットの完全性を維持します。

ipnat コマンドは、NAT 規則リストを処理するために使用します。ipnat コマンドの詳細については、ipnat(1M) コマンドを参照してください。

NAT 規則は、 ipnat コマンドを使用してコマンド行で作成することもNAT 構成ファイルで作成することもできます。NAT 構成規則は、ipnat.conf ファイルに保存されます。ネットワークアドレス変換を使用する場合は、ipnat.conf ファイルを作成します。 起動時に NAT 規則をロードしない場合は、適当な場所に ipnat.conf ファイルを保存し、ipnat コマンドによってパケットフィルタリングを手動でアクティブ化します。

NAT 規則の構成

次の構文で NAT 規則を作成します。

command interface-name parameters

  1. 各規則の冒頭には、次のコマンドのいずれかが記述されています。

    map

    ある IP アドレスまたはネットワークを規制のないラウンドロビン方式で別の IP アドレスまたはネットワークにマッピングします。

    rdr

    ある IP アドレスとポートのペアから別の IP アドレスとポートのペアにパケットの方向を変更します。

    bimap

    外部 IP アドレスと内部 IP アドレス間で双方向の NAT を確立します。

    map-block

    静的 IP アドレスをベースにした変換を確立します。このコマンドは、アドレスを指定の範囲に変換するアルゴリズムに基づいています。

  2. このコマンドのあとには、hme0 などのインタフェース名を記述します。

  3. 次に、NAT 構成を決定するさまざまなパラメータを選択します。次に、この種のパラメータの例をいくつか挙げます。

    ipmask

    ネットワークマスクを指定します。

    dstipmask

    ipmask が変換されるアドレスを指定します。

    mapport

    ポート番号の範囲と tcp、udp または tcp/udp プロトコルを指定します。

次の例は、NAT 規則を作成するために NAT 規則の構文をまとめる方法を示しています。発信元アドレスが 192.168.1.0/24 のデバイス de0 から発信されるパケットを書き換え、外部に対して発信元アドレスが 10.1.0.0/16 であることを示すには、NAT 規則セットに次の規則を含めます。


map de0 192.168.1.0/24 -> 10.1.0.0/16

NAT 規則を記述する際の詳細な文法と形式については、ipnat(4) のマニュアルページを参照してください。

Oracle Solaris IP フィルタのアドレスプール機能の使用

アドレスプールは、アドレスとネットマスクのペアのまとまりに名前付けを行います。アドレスプールは、IP アドレスと規則の一致を取るために必要な時間を短縮します。また、アドレスプールによって、大きなまとまりのアドレスをより簡単に管理できます。

アドレスプール構成規則は、ippool.conf ファイルに保存されます。起動時にアドレスプール規則をロードする場合は、アドレスプールの規則を保存する /etc/ipf/ippool.conf というファイルを作成します。 起動時に アドレスプール規則をロードしない場合は、適当な場所に ippool.conf ファイルを保存し、ippool コマンドによってパケットフィルタリングを手動でアクティブ化します。

アドレスプールの構成

次の構文でアドレスプールを作成します。


table role = role-name type = storage-format number = reference-number
table

複数のアドレスへの参照を定義します。

role

Oracle Solaris IP フィルタでプールの役割を指定します。この時点で、参照できる役割は ipf だけです。

type

プールの保存形式を指定します。

number

フィルタリング規則が使用する参照番号を指定します。

たとえば、アドレスが 10.1.1.1 および 10.1.1.2 でネットワークが 192.16.1.0 のグループをプール番号 13 で参照する場合、アドレスプールの構成ファイルに次の規則を含めます。

table role = ipf type = tree number = 13 
{ 10.1.1.1/32, 10.1.1.2/32, 192.168.1.0/24 };

次に、フィルタリング規則のプール番号 13 を参照するには、次の例のような規則を構築します。


pass in from pool/13 to any

なお、プールへの参照を含む規則ファイルをロードする前に、プールファイルをロードする必要があります。プールファイルをロードしていない場合、次の出力のようにプールは未定義となります。


# ipfstat -io
empty list for ipfilter(out)
block in from pool/13(!) to any

プールをあとで追加しても、そのプールの追加によってカーネルの規則セットが更新されることはありません。そのプールを参照する規則ファイルも再ロードする必要があります。

パケットフィルタリング規則を記述するときの詳細な文法および構文については、ippool(4) のマニュアルページを参照してください。

パケットフィルタリングフック

Solaris 10 7/07 リリース以降では、pfil モジュールの代わりにパケットフィルタリングフックを使用して Oracle Solaris IP フィルタを有効にします。以前の Oracle Solaris リリースでは、Oracle Solaris IP フィルタを設定するには、追加手順として pfil モジュールの構成が必要でした。この追加の構成が必要であったため間違いが発生しやすく、Oracle Solaris IP フィルタが正しく動作しない場合がありました。pfil STREAMS モジュールが IP とデバイスドライバの間に挿入されることも、パフォーマンス低下の原因となっていました。さらに、pfil モジュールはゾーン間のパケット傍受を実行できませんでした。

パケットフィルタリングフックを使用することにより、Oracle Solaris IP フィルタを有効にする手順が簡素化されます。これらのフックを介して、Oracle Solaris IP フィルタはルーティング前 (入力) およびルーティング後 (出力) のフィルタタップを使用して、Oracle Solaris システムに対する入出力パケットフローを制御できます。

パケットフィルタリングフックによって pfil モジュールは不要になります。したがって、このモジュールに関連する次のコンポーネントも削除されます。

Oracle Solaris IP フィルタを有効にするための作業については、第 26 章Oracle Solaris IP フィルタ (作業)を参照してください。

Oracle Solaris IP フィルタと pfil STREAMS モジュール

注 –

pfil モジュールが Oracle Solaris IP フィルタに使用されるのは、次の Oracle Solaris 10 リリースのみです。

Solaris 10 7/07 リリース以降では、pfil モジュールはパケットフィルタリングフックで置き換えられ、Oracle Solaris IP フィルタには使用されなくなりました。

pfil STREAMS モジュールは、Oracle Solaris IP フィルタを有効にするために使用されます。ただし、Oracle Solaris IP フィルタは、モジュールを各インタフェースに転送する自動メカニズムを提供していません。そのかわり、pfil STREAMS モジュールは SMF サービス svc:/network/pfil によって管理されます。ネットワークインタフェースでフィルタリングをアクティブにするには、まず pfil.ap ファイルを構成します。そのあと svc:/network/pfil サービスをアクティブ化して、pfil STREAMS モジュールをネットワークインタフェースに転送します。STREAMS モジュールを有効にするには、システムをリブートするか、ifconfig コマンドを使用して、フィルタリングする各ネットワークインタフェースを unplumb したあと、再度 plumb します。IPv6 パケットフィルタリング機能をアクティブ化するには、inet6 バージョンのインタフェースを plumb する必要があります。

ネットワークインタフェースの pfil モジュールが見つからない場合、SMF サービスは保守状態になります。この状態をもたらすもっとも一般的な原因は、/etc/ipf/pfil.ap ファイルが正しく編集されていないことです。サービスが保守モードになると、フィルタのログファイルにそのことが記録されます。

Oracle Solaris IP フィルタをアクティブ化するための作業については、「Oracle Solaris IP フィルタの構成」を参照してください。

IPv6 と Oracle Solaris IP フィルタ

Solaris 10 6/06 リリース以降の Oracle Solaris IP フィルタでは、IPv6 がサポートされています。IPv6 パケットフィルタリングでは、発信元または宛先の IPv6 アドレス、IPv6 アドレスを含むプール、および IPv6 拡張ヘッダーに基づいて、パケットを取り出すことができます。

IPv6 は、多くの点で IPv4 に似ています。ただし、これら 2 つの IP バージョンは、ヘッダーとパケットサイズが異なっています。IP フィルタでは、これらは重要な要素です。IPv6 パケットには、「ジャンボグラム」と呼ばれる、65,535 バイトより大きなデータグラムが含まれています。Oracle Solaris IP フィルタでは、IPv6 ジャンボグラムはサポートされていません。IPv6 のその他の機能の詳細については、「IPv6 の主な特長」を参照してください。

注 –

ジャンボグラムの詳細については、Internet Engineering Task Force (IETF) の RFC 2675、『IPv6 Jumbograms』のドキュメントを参照してください。 http://www.ietf.org/rfc/rfc2675.txt

IPv6 に関連する IP フィルタの作業は、IPv4 とほとんど変わりません。もっとも大きな違いは、特定のコマンドで -6 オプションを使用することです。ipf コマンドと ipfstat コマンドには、IPv6 パケットフィルタリングを使用するために、-6 オプションが用意されています。IPv6 パケットフィルタリング規則をロードおよびフラッシュするときは、ipf コマンドで -6 オプションを使用します。IPv6 統計を表示するときは、ipfstat コマンドに -6 オプションを使用します。ipmon コマンドと ippool コマンドでも IPv6 がサポートされますが、IPv6 をサポートするためのオプションは指定しません。ipmon コマンドは、IPv6 パケットのログを記録できるように拡張されています。ippool コマンドでは、IPv6 アドレスをプールに格納できます。IPv4 アドレスまたは IPv6 アドレスのみのプールを作成したり、IPv4 アドレスと IPv6 アドレスを同じプールに含めたりできます。

ipf6.conf ファイルを使用して、IPv6 用のパケットフィルタリング規則セットを作成できます。デフォルトでは、ipf6.conf 構成ファイルは /etc/ipf ディレクトリに含まれています。ほかのフィルタリング構成ファイルと同様に、/etc/ipf ディレクトリに保存されている ipf6.conf ファイルは、起動時に自動的にロードされます。作成した IPv6 構成ファイルを別の場所に保存し、そのファイルを手動でロードすることもできます。

注 –

ネットワークアドレス変換 (NAT) では、IPv6 はサポートされていません。

IPv6 用のパケットフィルタリング規則を設定したら、inet6 バージョンのインタフェースを plumb して IPv6 パケットフィルタリング機能をアクティブにしてください。

IPv6 の詳細については、第 3 章IPv6 の紹介(概要)を参照してください。Oracle Solaris IP フィルタに関する作業については、第 26 章Oracle Solaris IP フィルタ (作業)を参照してください。

Oracle Solaris IP フィルタのマニュアルページ

次の表に Oracle Solaris IP フィルタに関するマニュアルページを示します。

マニュアルページ 

説明 

ipf(1M)

ipf コマンドを実行して次の作業を行う

  • パケットフィルタリング規則セットの処理

  • フィルタリングの無効化と有効化

  • 統計のリセットと現在のインタフェースステータスリストとカーネル内インタフェースリストの再同期化

ipf(4)

Oracle Solaris IP フィルタパケットのフィルタリング規則を作成するための文法と構文を含む 

ipfilter(5)

オープンソースの IP フィルタのライセンス情報を提供する 

ipfs(1M)

ipfs コマンドを実行して、NAT 情報と状態テーブル情報を保存し、リブート後に復元する

ipfstat(1M)

ipfstat コマンドを実行して、パケット処理の統計を検索し、表示する

ipmon(1M)

ipmon コマンドを使用してログデバイスを開き、パケットのフィルタリングと NAT の両方に対してロギングされたパケットを参照する

ipnat(1M)

ipnat コマンドを実行して次の作業を行う

  • NAT 規則の処理

  • NAT 統計の検索と表示

ipnat(4)

NAT 規則を作成するための文法と構文を含む 

ippool(1M)

ippool コマンドを実行して、アドレスプールの作成と管理を行う

ippool(4)

Oracle Solaris IP フィルタアドレスプールを作成するための文法と構文を含む 

ndd(1M)

pfil STREAMS モジュールの現在のフィルタリングパラメータおよび調整可能なパラメータの現在値を表示する

第 26 章 Oracle Solaris IP フィルタ (作業)

この章では、Solaris IP フィルタを使用する作業を手順ごとに説明します。Oracle Solaris IP フィルタの概要情報については、第 25 章Oracle Solaris IP フィルタ (概要)を参照してください。

この章では、次の内容について説明します。

Oracle Solaris IP フィルタの構成

次の作業マップに、Oracle Solaris IP フィルタを構成するための手順を示します。

表 26–1 Oracle Solaris IP フィルタの構成 (作業マップ)

作業 

説明 

参照先 

Oracle Solaris IP フィルタを初期段階で有効にします。 

Oracle Solaris IP フィルタは、デフォルトでは無効です。Solaris IP フィルタを手動で有効にするか /etc/ipf/ ディレクトリにある構成ファイルを使用して、システムをリブートする必要があります。Solaris 10 7/07 リリース以降では、pfil モジュールの代わりにパケットフィルタリングフックを使用して Oracle Solaris IP フィルタを有効にします。

「Oracle Solaris IP フィルタを有効にする方法」

Oracle Solaris IP フィルタを再度有効にします。 

Oracle Solaris IP フィルタが非アクティブ化された、または無効になった場合は、システムをリブートするか、ipf コマンドを使用して、Oracle Solaris IP フィルタを再度有効にできます。

「Oracle Solaris IP フィルタを再度有効にする方法」

ループバックフィルタリングを有効にします。 

オプションとして、ループバックフィルタリングを有効にすると、ゾーン間のトラフィックのフィルタリングなどを行うことができます。 

「ループバックフィルタリングを有効にする方法」

ProcedureOracle Solaris IP フィルタを有効にする方法

Solaris 10 7/07 以降の OS を実行しているシステムで Oracle Solaris IP フィルタを有効にするには、次の手順に従います。Solaris 10 7/07 OS より前の Oracle Solaris 10 を実行しているシステムで Oracle Solaris IP フィルタを有効にする場合は、「pfil モジュールの使用」を参照してください。

  1. IP Filter Management の権利プロファイルを持つ役割またはスーパーユーザーになります。

    IP Filter Management の権利プロファイルは、ユーザーが作成した役割に割り当てることができます。役割の作成と役割のユーザーへの割り当てについては、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

  2. パケットフィルタリング構成ファイルを作成します。

    パケットフィルタリング構成ファイルには、Oracle Solaris IP フィルタが使用するパケットフィルタリング規則が含まれています。起動時にパケットフィルタリング規則をロードする場合は、/etc/ipf/ipf.conf ファイルを編集して IPv4 パケットフィルタリングを実装します。IPv6 パケットフィルタリング規則には /etc/ipf/ipf6.conf ファイルを使用します。起動時にパケットフィルタリング規則をロードしない場合は、適当な場所に ipf.conf ファイルを保存し、パケットフィルタリングを手動でアクティブ化します。パケットのフィルタリングについては、「Oracle Solaris IP フィルタのパケットフィルタリング機能の使用」を参照してください。構成ファイルの処理については、「Oracle Solaris IP フィルタ構成ファイルの作成と編集」を参照してください。

  3. (省略可能) ネットワークアドレス変換 (NAT) 構成ファイルを作成します。

    注 –

    ネットワークアドレス変換 (NAT) では、IPv6 はサポートされていません。

    ネットワークアドレス変換を使用する場合は、ipnat.conf ファイルを作成します。ネットワークアドレス変換を使用する場合は、ipnat.conf ファイルを作成します。 起動時に NAT 規則をロードしない場合は、適当な場所に ipnat.conf ファイルを保存し、NAT 規則を手動でアクティブ化します。

    NAT については、「Oracle Solaris IP フィルタの NAT 機能の使用」を参照してください。

  4. (省略可能) アドレスプール構成ファイルを作成します。

    ひとかたまりのアドレスを単一のアドレスプールとして参照する場合は、ipool.conf ファイルを作成します。起動時にアドレスプール構成ファイルをロードする場合は、アドレスプールを保存する /etc/ipf/ippool.conf というファイルを作成します。起動時にアドレスプール構成ファイルをロードしない場合は、適当な場所に ippool.conf ファイルを保存し、規則を手動でアクティブ化します。

    アドレスプールは、IPv4 アドレスだけまたは IPv6 アドレスだけを含むことができます。IPv4 アドレスと IPv6 アドレスの両方を含むこともできます。

    アドレスプールについては、「Oracle Solaris IP フィルタのアドレスプール機能の使用」を参照してください。

  5. (省略可能) ループバックトラフィックのフィルタリングを有効にします。

    システムに構成されているゾーン間のトラフィックのフィルタリングを行う場合は、ループバックフィルタリングを有効にする必要があります。「ループバックフィルタリングを有効にする方法」を参照してください。ゾーンに適用する適切な規則セットも必ず定義してください。

  6. Oracle Solaris IP フィルタをアクティブにします。


    # svcadm enable network/ipfilter

ProcedureOracle Solaris IP フィルタを再度有効にする方法

Solaris IP フィルタがアクティブでない場合は、再度有効にできます。

  1. IP Filter Management の権利プロファイルを持つ役割またはスーパーユーザーになります。

    IP Filter Management の権利プロファイルは、ユーザーが作成した役割に割り当てることができます。役割の作成と役割のユーザーへの割り当てについては、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

  2. Oracle Solaris IP フィルタを有効にし、次のいずれかの方法でフィルタリングをアクティブにします。

    • マシンをリブートします。


      # reboot
      注 –

      IP フィルタが有効になっているときに次のファイルが存在する場合は、リブート後にそれらのファイルがロードされます。 /etc/ipf/ipf.conf ファイル (IPv6 を使用している場合は /etc/ipf/ipf6.conf ファイル) または /etc/ipf/ipnat.conf ファイル。

    • 次の一連のコマンドを実行して、Oracle Solaris IP フィルタを有効にし、フィルタリングをアクティブにします。

      1. Oracle Solaris IP フィルタを有効にします。


        # ipf -E

      2. パケットフィルタリングのアクティブ化


        # ipf -f filename

      3. (省略可能) NAT のアクティブ化


        # ipnat -f filename
        注 –

        ネットワークアドレス変換 (NAT) では、IPv6 はサポートされていません。

Procedureループバックフィルタリングを有効にする方法

注 –

ループバックトラフィックをフィルタリングできるのは、システムで Solaris 10 7/07 リリース以降が実行されている場合のみです。以前の Oracle Solaris 10 リリースでは、ループバックフィルタリングはサポートされません。

  1. IP Filter Management の権利プロファイルを持つ役割またはスーパーユーザーになります。

    IP Filter Management の権利プロファイルは、ユーザーが作成した役割に割り当てることができます。役割の作成と役割のユーザーへの割り当てについては、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

  2. Oracle Solaris IP フィルタが実行中の場合は、IP フィルタを停止します。


    # svcadm disable network/ipfilter

  3. /etc/ipf.conf ファイルまたは /etc/ipf6.conf ファイルを編集して、ファイルの先頭に次の行を追加します。


    set intercept_loopback true;

    この行は、ファイル内で定義されるどの IP フィルタ規則よりも前に置く必要があります。ただし、この行の前にコメントを挿入することはできます。次に例を示します。


    # 
# Enable loopback filtering to filter between zones 
# 
set intercept_loopback true; 
# 
# Define policy 
# 
block in all 
block out all 
<other rules>
...

  4. Oracle Solaris IP フィルタを起動します。


    # svcadm enable network/ipfilter

  5. ループバックフィルタリングの状態を確認するには、次のコマンドを使用します。


    # ipf —T ipf_loopback
ipf_loopback    min 0   max 0x1 current 1
#

    ループバックフィルタリングが無効になっている場合、このコマンドは次の出力を生成します。


    ipf_loopback    min 0   max 0x1 current 0

Oracle Solaris IP フィルタの非アクティブ化と無効化

次のような場合、パケットフィルタリングと NAT を非アクティブ化または無効にしたほうがよいこともあります。

次の作業マップに、Oracle Solaris IP フィルタの機能を非アクティブ化または無効にする手順を示します。

表 26–2 Oracle Solaris IP フィルタの非アクティブ化と無効化 (作業マップ)

作業 

説明 

説明 

パケットフィルタリングの非アクティブ化 

ipf コマンドでパケットフィルタリングを非アクティブにする

「パケットフィルタリングを非アクティブにする方法」

NAT の非アクティブ化 

ipnat コマンドで NAT を非アクティブにする

「NAT を非アクティブにする方法」

パケットフィルタリングと NAT の無効化 

ipf コマンドでパケットフィルタリングと NAT を無効にする

「パケットフィルタリングを無効にする方法」

Procedureパケットフィルタリングを非アクティブにする方法

次の手順は、パケットフィルタリング規則をアクティブなフィルタリング規則セットから消去することによって、Oracle Solaris IP フィルタのパケットフィルタリングを非アクティブにします。この手順では、Oracle Solaris IP フィルタは無効になりません。規則を規則セットに追加することによって、Oracle Solaris IP フィルタを再度アクティブ化することもできます。

  1. IP Filter Management の権利プロファイルを持つ役割またはスーパーユーザーになります。

    IP Filter Management の権利プロファイルは、ユーザーが作成した役割に割り当てることができます。役割の作成と役割のユーザーへの割り当てについては、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

  2. 次のいずれかの方法で Oracle Solaris IP フィルタ規則を非アクティブにします。

    • アクティブな規則セットをカーネルから削除します。


      # ipf -Fa

      このコマンドは、すべてのパケットフィルタリング規則を非アクティブにします。

    • 受信パケットのフィルタリング規則を削除します。


      # ipf -Fi

      このコマンドは、 受信パケットのパケットフィルタリング規則を非アクティブにします。

    • 送信パケットのフィルタリング規則を削除します。


      # ipf -Fo

      このコマンドは、 送信パケットのパケットフィルタリング規則を非アクティブにします。

ProcedureNAT を非アクティブにする方法

次の手順は、NAT 規則をアクティブな NAT 規則セットから消去することで、Oracle Solaris IP フィルタの NAT 規則を非アクティブにします。この手順では、Oracle Solaris IP フィルタは無効になりません。規則を規則セットに追加することによって、Oracle Solaris IP フィルタを再度アクティブ化することもできます。

  1. IP Filter Management の権利プロファイルを持つ役割またはスーパーユーザーになります。

    IP Filter Management の権利プロファイルは、ユーザーが作成した役割に割り当てることができます。役割の作成と役割のユーザーへの割り当てについては、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

  2. NAT をカーネルから削除します。


    # ipnat -FC

    -C オプションは、現在の NAT 規則リストのすべてのエントリを削除します。-F オプションは、現在アクティブな NAT マッピングを示す現在の NAT 変換テーブルのすべてのアクティブなエントリを削除します。

Procedureパケットフィルタリングを無効にする方法

この手順を実行すると、パケットフィルタリングと NAT の両方がカーネルから削除されます。この手順を使用する場合は、パケットフィルタリングと NAT を再度有効にするには、Solaris IP フィルタを有効する必要があります。詳細については、「Oracle Solaris IP フィルタを再度有効にする方法」を参照してください。

  1. IP Filter Management の権利プロファイルを持つ役割またはスーパーユーザーになります。

    IP Filter Management の権利プロファイルは、ユーザーが作成した役割に割り当てることができます。役割の作成と役割のユーザーへの割り当てについては、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

  2. パケットフィルタリングを無効にし、すべてのパケットがネットワークを通過できるようにします。


    # ipf –D
    注 –

    ipf -D コマンドは、規則セットから規則を消去します。フィルタリングを再び有効にするときには、規則セットに規則を追加する必要があります。

pfil モジュールの使用

この節では、pfil STREAMS モジュールを使用して Oracle Solaris IP フィルタをアクティブまたは非アクティブにする方法と、pfil 統計を参照する方法について説明します。これらの手順は、次の Oracle Solaris 10 リリースのいずれかを実行しているシステムでのみ使用できます。

次の作業マップに、pfil モジュールを構成するための作業を示します。

表 26–3 pfil モジュールの使用 (作業マップ)

タスク 

説明 

参照先 

Oracle Solaris IP フィルタの有効化 

Oracle Solaris IP フィルタは、デフォルトでは無効です。Solaris IP フィルタを手動で有効にするか /etc/ipf/ ディレクトリにある構成ファイルを使用して、システムをリブートする必要があります。

「以前の Oracle Solaris 10 リリースで Oracle Solaris IP フィルタを有効にする方法」

NIC でのパケットフィルタリングのアクティブ化 

pfil モジュールを構成して、NIC でのパケットフィルタリングをアクティブにします

「NIC でパケットフィルタリングをアクティブにする方法」

NIC の Oracle Solaris IP フィルタの非アクティブ化 

NIC を削除し、すべてのパケットが NIC を通過できるようにします。 

「NIC の Oracle Solaris IP フィルタを非アクティブにする方法」

pfil 統計の参照

pfil モジュールの統計を参照すると、ndd コマンドで Oracle Solaris IP フィルタのトラブルシューティングを行う際に役立ちます。

「Oracle Solaris IP フィルタの pfil 統計を参照する方法」

Procedure以前の Oracle Solaris 10 リリースで Oracle Solaris IP フィルタを有効にする方法

Oracle Solaris IP フィルタは Oracle Solaris とともにインストールされます。ただし、パケットフィルタリングはデフォルトでは有効になっていません。次の手順で Oracle Solaris IP フィルタをアクティブ化してください。

注 –

システムで Solaris 10 7/07 リリース以降が実行されている場合は、「Oracle Solaris IP フィルタを有効にする方法」の、パケットフィルタリングフックを使用する手順に従ってください。

  1. IP Filter Management の権利プロファイルを持つ役割またはスーパーユーザーになります。

    IP Filter Management の権利プロファイルは、ユーザーが作成した役割に割り当てることができます。役割の作成と役割のユーザーへの割り当てについては、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

  2. 適当なファイルエディタを起動して、 /etc/ipf/pfil.ap ファイルを編集します。

    このファイルには、ホスト上のネットワークインタフェースカード (NIC) の名前が含まれています。デフォルトでは、名前はコメントとされます。フィルタリングを実行するネットワークトラフィックのデバイス名をコメントから外してください。システムの NIC の名前が含まれていない場合は、NIC を指定する行を追加してください。


    # vi /etc/ipf/pfil.ap
# IP Filter pfil autopush setup
#
# See autopush(1M) manpage for more information.
#
# Format of the entries in this file is:
#
#major  minor lastminor modules

#le     -1      0       pfil
#qe     -1      0       pfil
hme     -1      0       pfil (Device has been uncommented for filtering)
#qfe    -1      0       pfil
#eri    -1      0       pfil
#ce     -1      0       pfil
#bge    -1      0       pfil
#be     -1      0       pfil
#vge    -1      0       pfil
#ge     -1      0       pfil
#nf     -1      0       pfil
#fa     -1      0       pfil
#ci     -1      0       pfil
#el     -1      0       pfil
#ipdptp -1      0       pfil
#lane   -1      0       pfil
#dmfe   -1      0       pfil

  3. network/pfil サービスインスタンスを再起動することによって、/etc/ipf/pfil.ap ファイルの変更内容を有効にします。


    # svcadm restart network/pfil

  4. パケットフィルタリング構成ファイルを作成します。

    パケットフィルタリング構成ファイルには、Oracle Solaris IP フィルタが使用するパケットフィルタリング規則が含まれています。起動時にパケットフィルタリング規則をロードする場合は、/etc/ipf/ipf.conf ファイルを編集して IPv4 パケットフィルタリングを実装します。IPv6 パケットフィルタリング規則には /etc/ipf/ipf6.conf ファイルを使用します。起動時にパケットフィルタリング規則をロードしない場合は、適当な場所に ipf.conf ファイルを保存し、パケットフィルタリングを手動でアクティブ化します。パケットのフィルタリングについては、「Oracle Solaris IP フィルタのパケットフィルタリング機能の使用」を参照してください。構成ファイルの処理については、「Oracle Solaris IP フィルタ構成ファイルの作成と編集」を参照してください。

  5. (省略可能) ネットワークアドレス変換 (NAT) 構成ファイルを作成します。

    注 –

    ネットワークアドレス変換 (NAT) では、IPv6 はサポートされていません。

    ネットワークアドレス変換を使用する場合は、ipnat.conf ファイルを作成します。ネットワークアドレス変換を使用する場合は、ipnat.conf ファイルを作成します。 起動時に NAT 規則をロードしない場合は、適当な場所に ipnat.conf ファイルを保存し、NAT 規則を手動でアクティブ化します。

    NAT については、「Oracle Solaris IP フィルタの NAT 機能の使用」を参照してください。

  6. (省略可能) アドレスプール構成ファイルを作成します。

    ひとかたまりのアドレスを単一のアドレスプールとして参照する場合は、ipool.conf ファイルを作成します。起動時にアドレスプール構成ファイルをロードする場合は、アドレスプールを保存する /etc/ipf/ippool.conf というファイルを作成します。起動時にアドレスプール構成ファイルをロードしない場合は、適当な場所に ippool.conf ファイルを保存し、規則を手動でアクティブ化します。

    アドレスプールは、IPv4 アドレスだけまたは IPv6 アドレスだけを含むことができます。IPv4 アドレスと IPv6 アドレスの両方を含むこともできます。

    アドレスプールについては、「Oracle Solaris IP フィルタのアドレスプール機能の使用」を参照してください。

  7. 次のいずれかの方法で Oracle Solaris IP フィルタをアクティブにします。

    • IP フィルタを有効にして、マシンを再起動します。


      # svcadm enable network/ipfilter
# reboot
      注 –

      NIC で ifconfig unplumb コマンドと ifconfig plumb コマンドを安全に使用できない場合は、リブートが必要です。

    • ifconfig unplumb コマンドと ifconfig plumb コマンドを使用して、NIC を有効にします。次に、IP フィルタを有効にします。IPv6 パケットフィルタリングを実装するには、inet6 バージョンのインタフェースが plumb されている必要があります。


      # ifconfig hme0 unplumb
# ifconfig hme0 plumb 192.168.1.20 netmask 255.255.255.0 up
# ifconfig hme0 inte6 unplumb
# ifconfig hme0 inet6 plumb fec3:f849::1/96 up
# svcadm enable network/ipfilter

      ifconfig コマンドの詳細については、ifconfig(1m) のマニュアルページを参照してください。

ProcedureNIC でパケットフィルタリングをアクティブにする方法

/etc/ipf/ipf.conf ファイル (IPv6 を使用している場合は /etc/ipf/ipf6.conf ファイル) が存在する場合は、Oracle Solaris IP フィルタは起動時に有効になります。Oracle Solaris IP フィルタを有効にしたあと、NIC でフィルタリングを有効にする必要がある場合は、次の手順で行います。

  1. IP Filter Management の権利プロファイルを持つ役割またはスーパーユーザーになります。

    IP Filter Management の権利プロファイルは、ユーザーが作成した役割に割り当てることができます。役割の作成と役割のユーザーへの割り当てについては、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

  2. 適当なファイルエディタを起動して、 /etc/ipf/pfil.ap ファイルを編集します。

    このファイルには、ホスト上の NIC の名前が含まれています。デフォルトでは、名前はコメントとされます。フィルタリングを実行するネットワークトラフィックのデバイス名をコメントから外してください。システムの NIC の名前が含まれていない場合は、NIC を指定する行を追加してください。


    # vi /etc/ipf/pfil.ap
# IP Filter pfil autopush setup
#
# See autopush(1M) manpage for more information.
#
# Format of the entries in this file is:
#
#major  minor lastminor modules

#le     -1      0       pfil
#qe     -1      0       pfil
hme     -1      0       pfil (Device has been uncommented for filtering)
#qfe    -1      0       pfil
#eri    -1      0       pfil
#ce     -1      0       pfil
#bge    -1      0       pfil
#be     -1      0       pfil
#vge    -1      0       pfil
#ge     -1      0       pfil
#nf     -1      0       pfil
#fa     -1      0       pfil
#ci     -1      0       pfil
#el     -1      0       pfil
#ipdptp -1      0       pfil
#lane   -1      0       pfil
#dmfe   -1      0       pfil

  3. network/pfil サービスインスタンスを再起動することによって、/etc/ipf/pfil.ap ファイルの変更内容を有効にします。


    # svcadm restart network/pfil

  4. 次の方法のいずれかで NIC を有効にします。

    • マシンをリブートします。


      # reboot
      注 –

      NIC で ifconfig unplumb コマンドと ifconfig plumb コマンドを安全に使用できない場合は、リブートが必要です。

    • unplumb と plumb オプションを指定して ifconfig コマンドを実行し、フィルタリングする NIC を有効にします。IPv6 パケットフィルタリングを実装するには、inet6 バージョンの各インタフェースが plumb されている必要があります。


      # ifconfig hme0 unplumb
# ifconfig hme0 plumb 192.168.1.20  netmask 255.255.255.0  up
# ifconfig hme0 inet6 unplumb
# ifconfig hme0 inet6 plumb fec3:f840::1/96 up

      ifconfig コマンドの詳細については、ifconfig(1m) のマニュアルページを参照してください。

ProcedureNIC の Oracle Solaris IP フィルタを非アクティブにする方法

NIC でフィルタリングパケットを停止するには、次の手順を実行します。

  1. IP Filter Management の権利プロファイルを持つ役割またはスーパーユーザーになります。

    IP Filter Management の権利プロファイルは、ユーザーが作成した役割に割り当てることができます。役割の作成と役割のユーザーへの割り当てについては、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

  2. 適当なファイルエディタを起動して、 /etc/ipf/pfil.ap ファイルを編集します。

    このファイルには、ホスト上の NIC の名前が含まれています。ネットワークトラフィックのフィルタリングに使用されていた NIC は、コメントから外されます。ネットワークトラフィックのフィルタリングで使用しなくなったデバイスの名前をコメントにします。


    # vi /etc/ipf/pfil.ap
# IP Filter pfil autopush setup
#
# See autopush(1M) manpage for more information.
#
# Format of the entries in this file is:
#
#major  minor lastminor modules

#le     -1      0       pfil
#qe     -1      0       pfil
#hme    -1      0       pfil (Commented-out device no longer filters network traffic)
#qfe    -1      0       pfil
#eri    -1      0       pfil
#ce     -1      0       pfil
#bge    -1      0       pfil
#be     -1      0       pfil
#vge    -1      0       pfil
#ge     -1      0       pfil
#nf     -1      0       pfil
#fa     -1      0       pfil
#ci     -1      0       pfil
#el     -1      0       pfil
#ipdptp -1      0       pfil
#lane   -1      0       pfil
#dmfe   -1      0       pfil

  3. 次の方法のいずれかで NIC を非アクティブにします。

    • マシンをリブートします。


      # reboot
      注 –

      NIC で ifconfig unplumb コマンドと ifconfig plumb コマンドを安全に使用できない場合は、リブートが必要です。

    • unplumb と plumb オプションを指定して ifconfig コマンドを実行し、NIC を非アクティブにします。IPv6 パケットフィルタリングを非アクティブにするには、inet6 バージョンの各インタフェースを unplumb する必要があります。次の手順を実行します。システムのサンプルデバイスは hme です。

      1. 無効にするデバイスのメジャー番号を特定します。


        # grep hme /etc/name_to_major
hme 7

      2. hme0 の現在の autopush 構成を表示します。


        # autopush -g -M 7 -m 0
   Major     Minor     Lastminor       Modules
       7      ALL          -           pfil

      3. その autopush 構成を削除します。


        # autopush -r -M 7 -m 0

      4. デバイスを開いて IP アドレスを割り当てます。


        # ifconfig hme0 unplumb
# ifconfig hme0 plumb 192.168.1.20  netmask 255.255.255.0  up
# ifconfig hme0 inet6 unplumb
# ifconfig hme0 inet6 plumb fec3:f840::1/96 up

        ifconfig コマンドの詳細については、ifconfig(1m) のマニュアルページを参照してください。

ProcedureOracle Solaris IP フィルタの pfil 統計を参照する方法

Oracle Solaris IP フィルタをトラブルシューティングするときに pfil 統計を参照できます。

  1. IP Filter Management の権利プロファイルを持つ役割またはスーパーユーザーになります。

    IP Filter Management の権利プロファイルは、ユーザーが作成した役割に割り当てることができます。役割の作成と役割のユーザーへの割り当てについては、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

  2. pfil 統計の参照


    # ndd -get /dev/pfil qif_status
例 26–1 Oracle Solaris IP フィルタの pfil 統計の参照

次の例は、pfil 統計の参照方法を示しています。


# ndd -get /dev/pfil qif_status
ifname ill q OTHERQ num sap hl nr nw bad copy copyfail drop notip nodata
   notdata
QIF6 0 300011247b8 300011248b0 6 806 0 4 9 0 0 0 0 0 0 0
dmfe1 3000200a018 30002162a50 30002162b48 5 800 14 171 13681 0 0 0 0 0 0 0

Oracle Solaris IP フィルタ規則セットの処理

次の作業マップに、Oracle Solaris IP フィルタの規則セットに関する手順を示します。

表 26–4 Oracle Solaris IP フィルタ規則セットの処理 (作業マップ)

作業 

説明 

参照先 

Oracle Solaris IP フィルタのパケットフィルタリング規則セットの管理、参照、変更 

 

「Oracle Solaris IP フィルタのパケットフィルタリング規則セットの管理」

 

アクティブなパケットフィルタリング規則セットを参照する 

「アクティブなパケットフィルタリング規則セットを参照する方法」

 

アクティブでないパケットフィルタリング規則セットを参照する 

「アクティブでないパケットフィルタリング規則セットを参照する方法」

 

別のアクティブな規則セットをアクティブにする 

「別のパケットフィルタリング規則セット、または更新されたパケットフィルタリング規則セットをアクティブにする方法」

 

規則セットを削除する 

「パケットフィルタリング規則セットを削除する方法」

 

規則セットへ規則を追加する 

「アクティブなパケットフィルタリング規則セットに規則を追加する方法」

「アクティブでないパケットフィルタリング規則セットに規則を追加する方法」

 

アクティブな規則セットとアクティブでない規則セット間を移動する 

「アクティブなパケットフィルタリング規則セットとアクティブでないパケットフィルタリング規則セットを切り替える方法」

 

アクティブでない規則セットをカーネルから削除する 

「カーネルからアクティブでないパケットフィルタリング規則セットを削除する方法」

Oracle Solaris IP フィルタの NAT 規則の管理、参照、変更 

 

「Oracle Solaris IP フィルタ向け NAT 規則の管理」

 

アクティブな NAT 規則を参照する 

「アクティブな NAT 規則を参照する方法」

 

NAT 規則を削除する 

「NAT 規則を削除する方法」

 

NAT 規則へさらに規則を追加する 

「NAT 規則に規則を追加する方法」

Oracle Solaris IP フィルタのアドレスプールの管理、参照、変更 

 

「Oracle Solaris IP フィルタのアドレスプールの管理」

 

アクティブなアドレスプールを参照する 

「アクティブなアドレスプールを参照する方法」

 

アドレスプールを削除する 

「アドレスプールを削除する方法」

 

アドレスプールへさらに規則を追加する 

「規則をアドレスプールに追加する方法」

Oracle Solaris IP フィルタのパケットフィルタリング規則セットの管理

Solaris IP フィルタが有効な場合、アクティブなパケットフィルタリング規則セットとアクティブでないパケットフィルタリング規則セットの両方をカーネルに置くことができます。アクティブな規則セットによって、受信パケットと送信パケットに対して実行するフィルタリングが決まります。アクティブでない規則セットでも規則を格納します。アクティブでない規則セットは、アクティブな規則セットにしない限り、使用されることはありません。アクティブなパケットフィルタリング規則セットとアクティブでないパケットフィルタリング規則セットの両方を管理、参照、変更できます。

Procedureアクティブなパケットフィルタリング規則セットを参照する方法

  1. IP Filter Management の権利プロファイルを持つ役割またはスーパーユーザーになります。

    IP Filter Management の権利プロファイルは、ユーザーが作成した役割に割り当てることができます。役割の作成と役割のユーザーへの割り当てについては、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

  2. カーネルにロードされているアクティブなパケットフィルタリング規則セットを参照します。


    # ipfstat -io
例 26–2 アクティブなパケットフィルタリング規則セットの参照

次の例は、カーネルにロードされたアクティブなパケットフィルタリング規則セットからの出力を示しています。


# ipfstat -io
empty list for ipfilter(out)
pass in quick on dmfe1 from 192.168.1.0/24 to any
pass in all
block in on dmfe1 from 192.168.1.10/32 to any

Procedureアクティブでないパケットフィルタリング規則セットを参照する方法

  1. IP Filter Management の権利プロファイルを持つ役割またはスーパーユーザーになります。

    IP Filter Management の権利プロファイルは、ユーザーが作成した役割に割り当てることができます。役割の作成と役割のユーザーへの割り当てについては、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

  2. アクティブでないパケットフィルタリング規則セットを参照します。


    # ipfstat -I -io
例 26–3 アクティブでないパケットフィルタリング規則セットの参照

次の例は、アクティブでないパケットフィルタリング規則セットからの出力を示しています。


# ipfstat -I -io
pass out quick on dmfe1 all
pass in quick on dmfe1 all

Procedure別のパケットフィルタリング規則セット、または更新されたパケットフィルタリング規則セットをアクティブにする方法

次のいずれかのタスクを実行する場合には、ここで示す手順を実行します。

  1. IP Filter Management の権利プロファイルを持つ役割またはスーパーユーザーになります。

    IP Filter Management の権利プロファイルは、ユーザーが作成した役割に割り当てることができます。役割の作成と役割のユーザーへの割り当てについては、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

  2. 次の手順から 1 つを選択します。

    • まったく異なる規則セットをアクティブにする場合は、別個のファイルを選択し、そこに新規規則セットを作成します。

    • 規則セットを含む構成ファイルを編集して、現在の規則セットを更新します。

  3. 現在の規則セットを削除し、新しい規則セットをロードします。


    # ipf -Fa -f filename

    filename には、新しい規則セットを含む新規ファイル、またはアクティブな規則セットを含む更新されたファイルを指定できます。

    アクティブな規則セットがカーネルから削除されます。filename ファイル内の規則がアクティブな規則セットになります。

    注 –

    現在の構成ファイルの再読み込みをしていても、このコマンドを実行する必要があります。実行しないと、以前の規則セットがアクティブであり続けるため、更新した構成ファイル内の変更された規則セットが適用されません。

    更新した規則セットをロードするのに ipf -D や svcadm restart などのコマンドを使わないでください。これらのコマンドは、新しい規則セットをロードする前にファイアウォールを無効にするため、ネットワークが危険にさらされます。

例 26–4 別のパケットフィルタリング規則セットのアクティブ化

次の例は、あるパケットフィルタリング規則セットを、別の構成ファイル /etc/ipf/ipf.conf 内の別のパケットフィルタリング規則セットに置換する方法を示しています。


# ipfstat -io
empty list for ipfilter(out)
pass in quick on dmfe all
# ipf -Fa -f /etc/ipf/ipf.conf
# ipfstat -io
empty list for ipfilter(out)
block in log quick from 10.0.0.0/8 to any
例 26–5 更新したパケットフィルタリング規則セットの再読み込み

次の例は、現在アクティブでこれから更新するパケットフィルタリング規則セットを再読み込みする方法を示しています。この例で使用しているファイルは、/etc/ipf/ipf.conf です。


# ipfstat -io (Optional)
empty list for ipfilter (out)
block in log quick from 10.0.0.0/8 to any

(Edit the /etc/ipf/ipf.conf configuration file.)

# ip -Fa -f /etc/ipf/ipf.conf
# ipfstat -io (Optional)
empty list for ipfilter (out)
block in log quick from 10.0.0.0/8 to any
block in quick on elx10 from 192.168.0.0/12 to any

Procedureパケットフィルタリング規則セットを削除する方法

  1. IP Filter Management の権利プロファイルを持つ役割またはスーパーユーザーになります。

    IP Filter Management の権利プロファイルは、ユーザーが作成した役割に割り当てることができます。役割の作成と役割のユーザーへの割り当てについては、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

  2. 規則セットを削除します。


    # ipf -F [a|i|o]
    -a

    すべてのフィルタリング規則を規則セットから削除します。

    -i

    受信パケットのフィルタリング規則を削除します。

    -o

    送信パケットのフィルタリング規則を削除します。

例 26–6 パケットフィルタリング規則セットの削除

次の例は、すべてのフィルタリング規則をアクティブなフィルタリング規則セットから削除する方法を示しています。


# ipfstat -io
block out log on dmf0 all
block in log quick from 10.0.0.0/8 to any
# ipf -Fa
# ipfstat -io
empty list for ipfilter(out)
empty list for ipfilter(in)

Procedureアクティブなパケットフィルタリング規則セットに規則を追加する方法

  1. IP Filter Management の権利プロファイルを持つ役割またはスーパーユーザーになります。

    IP Filter Management の権利プロファイルは、ユーザーが作成した役割に割り当てることができます。役割の作成と役割のユーザーへの割り当てについては、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

  2. 次のいずれかの方法で規則をアクティブな規則セットに追加します。

    • ipf -f - コマンドを使用して、コマンド行で、規則セットに規則を追加します。


      # echo "block in on dmfe1 proto tcp from 10.1.1.1/32 to any" | ipf -f -

    • 次のコマンドを実行します。

      1. 適当なファイルに規則セットを作成します。

      2. 作成しておいた規則をアクティブな規則セットに追加します。


        # ipf -f filename

        filename の規則がアクティブな規則セットの最後に追加されます。Solaris IP フィルタは「最後に一致した規則を採用する」アルゴリズムを使用するため、quick キーワードを使用していないときは、追加した規則によってフィルタリングの優先順位が決まります。パケットが quick キーワードを含む規則に一致する場合は、その規則に対する処理が実行され、それ以降の規則はチェックされません。

例 26–7 アクティブなパケットフィルタリング規則セットへの規則の追加

次の例は、コマンド行から、アクティブなパケットフィルタリング規則セットに規則を追加する方法を示しています。


# ipfstat -io
empty list for ipfilter(out)
block in log quick from 10.0.0.0/8 to any
# echo "block in on dmfe1 proto tcp from 10.1.1.1/32 to any" | ipf -f -
# ipfstat -io
empty list for ipfilter(out)
block in log quick from 10.0.0.0/8 to any
block in on dmfe1 proto tcp from 10.1.1.1/32 to any

Procedureアクティブでないパケットフィルタリング規則セットに規則を追加する方法

  1. IP Filter Management の権利プロファイルを持つ役割またはスーパーユーザーになります。

    IP Filter Management の権利プロファイルは、ユーザーが作成した役割に割り当てることができます。役割の作成と役割のユーザーへの割り当てについては、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

  2. 適当なファイルに規則セットを作成します。

  3. 作成しておいた規則をアクティブでない規則セットに追加します。


    # ipf -I -f filename

    filename の規則がアクティブでない規則セットの最後に追加されます。Solaris IP フィルタは「最後に一致した規則を採用する」アルゴリズムを使用するため、quick キーワードを使用していないときは、追加した規則によってフィルタリングの優先順位が決まります。パケットが quick キーワードを含む規則に一致する場合は、その規則に対する処理が実行され、それ以降の規則はチェックされません。

例 26–8 アクティブでない規則セットへの規則の追加

次の例は、ファイルからアクティブでない規則セットに規則を追加する方法を示しています。


# ipfstat -I -io
pass out quick on dmfe1 all
pass in quick on dmfe1 all
# ipf -I -f /etc/ipf/ipf.conf
# ipfstat -I -io
pass out quick on dmfe1 all
pass in quick on dmfe1 all
block in log quick from 10.0.0.0/8 to any

Procedureアクティブなパケットフィルタリング規則セットとアクティブでないパケットフィルタリング規則セットを切り替える方法

  1. IP Filter Management の権利プロファイルを持つ役割またはスーパーユーザーになります。

    IP Filter Management の権利プロファイルは、ユーザーが作成した役割に割り当てることができます。役割の作成と役割のユーザーへの割り当てについては、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

  2. アクティブな規則セットとアクティブでない規則セットを切り替えます。


    # ipf -s

    このコマンドを使用すると、カーネル内のアクティブな規則セットとアクティブでない規則セットを切り替えることができます。なお、アクティブでない規則セットが空の場合は、パケットフィルタリングは行われません。

例 26–9 アクティブなパケットフィルタリング規則セットとアクティブでないパケットフィルタリング規則セットの切り替え

次の例は、ipf - s コマンドの使用によって、どのようにアクティブでない規則セットがアクティブな規則セットになり、アクティブな規則セットがアクティブでない規則セットになるのかを示しています。

Procedureカーネルからアクティブでないパケットフィルタリング規則セットを削除する方法

  1. IP Filter Management の権利プロファイルを持つ役割またはスーパーユーザーになります。

    IP Filter Management の権利プロファイルは、ユーザーが作成した役割に割り当てることができます。役割の作成と役割のユーザーへの割り当てについては、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

  2. 全削除コマンドで、アクティブでない規則セットを指定します。


    # ipf -I -Fa

    このコマンドが、アクティブでない規則セットをカーネルから消去します。

    注 –

    続けて ipf -s を実行すると、空のアクティブでない規則セットがアクティブな規則セットになります。アクティブな規則セットが空の場合は、フィルタリングが行われません。

例 26–10 カーネルからのアクティブでないパケットフィルタリング規則セットの削除

次の例は、すべての規則が削除されるように、アクティブでないパケットフィルタリング規則セットを消去する方法を示しています。


# ipfstat -I -io
empty list for inactive ipfilter(out)
block in log quick from 10.0.0.0/8 to any
block in on dmfe1 proto tcp from 10.1.1.1/32 to any
# ipf -I -Fa
# ipfstat -I -io
empty list for inactive ipfilter(out)
empty list for inactive ipfilter(in)

Oracle Solaris IP フィルタ向け NAT 規則の管理

次の手順で NAT 規則を管理、参照および変更します。

Procedureアクティブな NAT 規則を参照する方法

  1. IP Filter Management の権利プロファイルを持つ役割またはスーパーユーザーになります。

    IP Filter Management の権利プロファイルは、ユーザーが作成した役割に割り当てることができます。役割の作成と役割のユーザーへの割り当てについては、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

  2. アクティブな NAT 規則を参照します。


    # ipnat -l
例 26–11 アクティブな NAT 規則の参照

次の例は、アクティブな NAT 規則セットからの出力を示しています。


# ipnat -l
List of active MAP/Redirect filters:
map dmfe0 192.168.1.0/24 -> 20.20.20.1/32

List of active sessions:

ProcedureNAT 規則を削除する方法

  1. IP Filter Management の権利プロファイルを持つ役割またはスーパーユーザーになります。

    IP Filter Management の権利プロファイルは、ユーザーが作成した役割に割り当てることができます。役割の作成と役割のユーザーへの割り当てについては、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

  2. 現在の NAT 規則を削除します。


    # ipnat -C
例 26–12 NAT 規則の削除

次の例は、現在の NAT 規則のエントリを削除する方法を示してます。


# ipnat -l
List of active MAP/Redirect filters:
map dmfe0 192.168.1.0/24 -> 20.20.20.1/32

List of active sessions:
# ipnat -C
1 entries flushed from NAT list
# ipnat -l
List of active MAP/Redirect filters:

List of active sessions:

ProcedureNAT 規則に規則を追加する方法

  1. IP Filter Management の権利プロファイルを持つ役割またはスーパーユーザーになります。

    IP Filter Management の権利プロファイルは、ユーザーが作成した役割に割り当てることができます。役割の作成と役割のユーザーへの割り当てについては、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

  2. 次のいずれかの方法で規則をアクティブな規則セットに追加します。

    • ipnat-f - コマンドを使用して、コマンド行で、NAT 規則セットに規則を追加します。


      # echo "map dmfe0 192.168.1.0/24 -> 20.20.20.1/32" | ipnat -f -

    • 次のコマンドを実行します。

      1. 適当なファイルに追加の NAT 規則を作成します。

      2. 作成しておいた規則をアクティブな NAT 規則に追加します。


        # ipnat -f filename

        filename の規則がアクティブな NAT 規則の最後に追加されます。

例 26–13 NAT 規則セットへの規則の追加

次の例は、コマンド行から、NAT 規則セットに規則を追加する方法を示しています。


# ipnat -l
List of active MAP/Redirect filters:

List of active sessions:
# echo "map dmfe0 192.168.1.0/24 -> 20.20.20.1/32" | ipnat -f -
# ipnat -l
List of active MAP/Redirect filters:
map dmfe0 192.168.1.0/24 -> 20.20.20.1/32

List of active sessions:

Oracle Solaris IP フィルタのアドレスプールの管理

次の手順でアドレスプールを管理、参照および変更します。

Procedureアクティブなアドレスプールを参照する方法

  1. IP Filter Management の権利プロファイルを持つ役割またはスーパーユーザーになります。

    IP Filter Management の権利プロファイルは、ユーザーが作成した役割に割り当てることができます。役割の作成と役割のユーザーへの割り当てについては、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

  2. アクティブなアドレスプールを参照します。


    # ippool -l
例 26–14 アクティブなアドレスプールの参照

次の例は、アクティブなアドレスプールの内容を参照する方法を示しています。


# ippool -l
table role = ipf type = tree number = 13
        { 10.1.1.1/32, 10.1.1.2/32, 192.168.1.0/24; };

Procedureアドレスプールを削除する方法

  1. IP Filter Management の権利プロファイルを持つ役割またはスーパーユーザーになります。

    IP Filter Management の権利プロファイルは、ユーザーが作成した役割に割り当てることができます。役割の作成と役割のユーザーへの割り当てについては、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

  2. 現在のアドレスプールのエントリを削除します。


    # ippool -F
例 26–15 アドレスプールの削除

次の例は、アドレスプールを削除する方法を示しています。


# ippool -l
table role = ipf type = tree number = 13
        { 10.1.1.1/32, 10.1.1.2/32, 192.168.1.0/24; };
# ippool -F
1 object flushed
# ippool -l

Procedure規則をアドレスプールに追加する方法

  1. IP Filter Management の権利プロファイルを持つ役割またはスーパーユーザーになります。

    IP Filter Management の権利プロファイルは、ユーザーが作成した役割に割り当てることができます。役割の作成と役割のユーザーへの割り当てについては、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

  2. 次のいずれかの方法で規則をアクティブな規則セットに追加します。

    • ippool-f - コマンドを使用して、コマンド行で、規則セットに規則を追加します。


      # echo "table role = ipf type = tree number = 13 
{10.1.1.1/32, 10.1.1.2/32, 192.168.1.0/24};" | ippool -f -

    • 次のコマンドを実行します。

      1. 適当なファイルに追加のアドレスプールを作成します。

      2. 作成しておいた規則をアクティブなアドレスプールに追加します。


        # ippool -f filename

        filename の規則がアクティブなアドレスプールの最後に追加されます。

例 26–16 アドレスプールへの規則の追加

次の例は、コマンド行から、アドレスプール規則セットにアドレスプールを追加する方法を示しています。


# ippool -l
table role = ipf type = tree number = 13
        { 10.1.1.1/32, 10.1.1.2/32, 192.168.1.0/24; };
# echo "table role = ipf type = tree number = 100
 {10.0.0.0/32, 172.16.1.2/32, 192.168.1.0/24};" | ippool -f -
# ippool -l
table role = ipf type = tree number = 100
        { 10.0.0.0/32, 172.16.1.2/32, 192.168.1.0/24; };
table role = ipf type = tree number = 13
        { 10.1.1.1/32, 10.1.1.2/32, 192.168.1.0/24; };

Oracle Solaris IP フィルタの統計および情報の表示

表 26–5 Oracle Solaris IP フィルタの統計および情報の表示 (作業マップ)

作業 

説明 

説明 

状態テーブルの参照 

ipfstat コマンドで、パケットフィルタリングに関する情報を取得する

「Oracle Solaris IP フィルタの状態テーブルを参照する方法」

状態統計の参照 

ipfstat -s コマンドでパケット状態情報の統計を参照する

「Oracle Solaris IP フィルタの状態統計を参照する方法」

NAT 統計の参照 

ipnat -s コマンドで NAT 統計を参照する

「Oracle Solaris IP フィルタの NAT 統計を参照する方法」

アドレスプール統計の参照 

ippool - s コマンドでアドレスプール統計を参照する

「Oracle Solaris IP フィルタのアドレスプール統計情報を表示する方法」

ProcedureOracle Solaris IP フィルタの状態テーブルを参照する方法

  1. IP Filter Management の権利プロファイルを持つ役割またはスーパーユーザーになります。

    IP Filter Management の権利プロファイルは、ユーザーが作成した役割に割り当てることができます。役割の作成と役割のユーザーへの割り当てについては、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

  2. 状態テーブルを参照します。


    # ipfstat
    注 –

    -t オプションを使用すると、状態テーブルをトップユーティリティー形式で参照できます。

例 26–17 Oracle Solaris IP フィルタの状態テーブルの参照

次の例は、状態テーブルの参照方法を示しています。


# ipfstat
bad packets:            in 0    out 0
 input packets:         blocked 160 passed 11 nomatch 1 counted 0 short 0
output packets:         blocked 0 passed 13681 nomatch 6844 counted 0 short 0
 input packets logged:  blocked 0 passed 0
output packets logged:  blocked 0 passed 0
 packets logged:        input 0 output 0
 log failures:          input 0 output 0
fragment state(in):     kept 0  lost 0
fragment state(out):    kept 0  lost 0
packet state(in):       kept 0  lost 0
packet state(out):      kept 0  lost 0
ICMP replies:   0       TCP RSTs sent:  0
Invalid source(in):     0
Result cache hits(in):  152     (out):  6837
IN Pullups succeeded:   0       failed: 0
OUT Pullups succeeded:  0       failed: 0
Fastroute successes:    0       failures:       0
TCP cksum fails(in):    0       (out):  0
IPF Ticks:      14341469
Packet log flags set: (0)
        none

ProcedureOracle Solaris IP フィルタの状態統計を参照する方法

  1. IP Filter Management の権利プロファイルを持つ役割またはスーパーユーザーになります。

    IP Filter Management の権利プロファイルは、ユーザーが作成した役割に割り当てることができます。役割の作成と役割のユーザーへの割り当てについては、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

  2. 状態統計を参照します。


    # ipfstat -s
例 26–18 Oracle Solaris IP フィルタの状態統計の参照

次の例は、状態統計の参照方法を示しています。


# ipfstat -s
IP states added:
        0 TCP
        0 UDP
        0 ICMP
        0 hits
        0 misses
        0 maximum
        0 no memory
        0 max bucket
        0 active
        0 expired
        0 closed
State logging enabled

State table bucket statistics:
        0 in use        
        0.00% bucket usage
        0 minimal length
        0 maximal length
        0.000 average length

ProcedureOracle Solaris IP フィルタの NAT 統計を参照する方法

  1. IP Filter Management の権利プロファイルを持つ役割またはスーパーユーザーになります。

    IP Filter Management の権利プロファイルは、ユーザーが作成した役割に割り当てることができます。役割の作成と役割のユーザーへの割り当てについては、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

  2. NAT 統計の参照


    # ipnat -s
例 26–19 Oracle Solaris IP フィルタの NAT 統計の参照

次の例は、NAT 統計の参照方法を示しています。


# ipnat -s
mapped  in      0       out     0
added   0       expired 0
no memory       0       bad nat 0
inuse   0
rules   1
wilds   0

ProcedureOracle Solaris IP フィルタのアドレスプール統計情報を表示する方法

  1. IP Filter Management の権利プロファイルを持つ役割またはスーパーユーザーになります。

    IP Filter Management の権利プロファイルは、ユーザーが作成した役割に割り当てることができます。役割の作成と役割のユーザーへの割り当てについては、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

  2. アドレスプール統計の参照


    # ippool -s
例 26–20 Oracle Solaris IP フィルタのアドレスプール統計の参照

次の例は、アドレスプール統計の参照方法を示しています。


# ippool -s
Pools:  3
Hash Tables:    0
Nodes:  0

Oracle Solaris IP フィルタ用ログファイルの処理

表 26–6 Oracle Solaris IP フィルタログファイルの処理 (作業マップ)

作業 

説明 

説明 

ログファイルの作成 

別個の Oracle Solaris IP フィルタログファイルを作成する 

「Oracle Solaris IP フィルタのログファイルを設定する方法」

ログファイルの参照 

ipmon コマンドで、状態、NAT、通常のログファイルを参照する

「Oracle Solaris IP フィルタのログファイルを参照する方法」

パケットログバッファーの消去 

ipmon -F コマンドでパケットログバッファーの内容を削除する

「パケットログファイルを消去する方法」

ロギングされたパケットのファイルへの保存 

あとで参照できるようにロギングされたパケットをファイルに保存する 

「ロギングされたパケットをファイルに保存する方法」

ProcedureOracle Solaris IP フィルタのログファイルを設定する方法

デフォルトでは、Oracle Solaris IP フィルタのすべてのログ情報が syslogd ファイルに記録されます。Oracle Solaris IP フィルタのトラフィック情報を、デフォルトログファイルに記録される可能性のあるほかのデータとは別個に記録するため、ログファイルを設定することをお勧めします。次の手順を実行します。

  1. IP Filter Management の権利プロファイルを持つ役割またはスーパーユーザーになります。

    IP Filter Management の権利プロファイルは、ユーザーが作成した役割に割り当てることができます。役割の作成と役割のユーザーへの割り当てについては、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

  2. /etc/syslog.conf を編集して、次の 2 行を追加します。


    # Save IPFilter log output to its own file 
local0.debug             /var/log/log-name
    注 –

    2 番目の行の local0.debug と /var/log/log-name との区切りには、Space バーではなく Tab キーを必ず使用してください。

  3. 新規ログファイルを作成します。


    # touch /var/log/log-name

  4. system-log サービスを再起動します。


    # svcadm restart system-log
例 26–21 Oracle Solaris IP フィルタログの作成

次の例は、ipmon.log を作成して IP フィルタ情報を保存する方法を示しています。

/etc/syslog.conf に、次の記述を追加します。


# Save IPFilter log output to its own file 
local0.debug             /var/log/ipmon.log

コマンド行で、次のコマンドを実行します。


# touch /var/log/ipmon.log
# svcadm restart system-log

ProcedureOracle Solaris IP フィルタのログファイルを参照する方法

始める前に

Oracle Solaris IP フィルタデータの記録用に、別個のログファイルを作成することをお勧めします。詳細は、「Oracle Solaris IP フィルタのログファイルを設定する方法」を参照してください。

  1. IP Filter Management の権利プロファイルを持つ役割またはスーパーユーザーになります。

    IP Filter Management の権利プロファイルは、ユーザーが作成した役割に割り当てることができます。役割の作成と役割のユーザーへの割り当てについては、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

  2. 状態、NAT、または通常のログファイルを参照します。ログファイルを参照するには、適切なオプションと共に次のコマンドを入力してください。


    # ipmon -o [S|N|I] filename
    S

    状態ログファイルを表示します。

    N

    NAT ログファイルを表示します。

    I

    通常の IP ログファイルを表示します。

    状態、NAT、および通常のログファイルをすべて表示するには、すべてのオプションを使用します。


    # ipmon -o SNI filename

    • ipmon デーモンを最初に手動で停止した場合は、次のコマンドを使って状態、NAT、および Oracle Solaris IP フィルタログファイルを表示することもできます。


      # ipmon -a filename
      注 –

      ipmon デーモンが実行中の場合は、ipmon -a 構文を使用しないでください。通常、このデーモンは、システムのブート時に自動的に起動されます。ipmon -a コマンドを実行すると、ipmon の別のコピーも開かれます。この場合、両方のコピーが同じログ情報を読み取るため、一方だけが特定のログメッセージを取得します。

    ログファイルの参照については、ipmon(1M) のマニュアルページを参照してください。

例 26–22 Oracle Solaris IP フィルタのログファイルの参照

次の例は、/var/ipmon.log からの出力を示しています。


# ipmon -o SNI /var/ipmon.log
02/09/2004 15:27:20.606626 hme0 @0:1 p 129.146.157.149 -> 
129.146.157.145 PR icmp len 20 84 icmp echo/0 IN

または


# pkill ipmon
# ipmon -aD /var/ipmon.log
02/09/2004 15:27:20.606626 hme0 @0:1 p 129.146.157.149 -> 
129.146.157.145 PR icmp len 20 84 icmp echo/0 IN

Procedureパケットログファイルを消去する方法

  1. IP Filter Management の権利プロファイルを持つ役割またはスーパーユーザーになります。

    IP Filter Management の権利プロファイルは、ユーザーが作成した役割に割り当てることができます。役割の作成と役割のユーザーへの割り当てについては、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

  2. パケットログバッファーを消去します。


    # ipmon -F
例 26–23 パケットログファイルの消去

次の例は、ログファイルが削除されたときの出力を示しています。ログファイルに何も保存されていない場合も、この例のようなレポートが出力されます。


# ipmon -F
0 bytes flushed from log buffer
0 bytes flushed from log buffer
0 bytes flushed from log buffer

Procedureロギングされたパケットをファイルに保存する方法

  1. IP Filter Management の権利プロファイルを持つ役割またはスーパーユーザーになります。

    IP Filter Management の権利プロファイルは、ユーザーが作成した役割に割り当てることができます。役割の作成と役割のユーザーへの割り当てについては、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

  2. ロギングされたパケットをファイルへ保存します。


    # cat /dev/ipl > filename

    Control-C を入力して、コマンド行のプロンプトに戻って、このプロシージャーを中断するまで、パケットは filename ファイルに継続的にロギングされます。

例 26–24 ファイルへのロギングされたパケットの保存

次の例は、ロギングされたパケットがファイルに保存されたときの結果を表します。


# cat /dev/ipl > /tmp/logfile
^C#

# ipmon -f /tmp/logfile
02/09/2004 15:30:28.708294 hme0 @0:1 p 129.146.157.149,33923 -> 
  129.146.157.145,23 PR tcp len 20 52 -S IN
02/09/2004 15:30:28.708708 hme0 @0:1 p 129.146.157.149,33923 -> 
  129.146.157.145,23 PR tcp len 20 40 -A IN
02/09/2004 15:30:28.792611 hme0 @0:1 p 129.146.157.149,33923 -> 
  129.146.157.145,23 PR tcp len 20 70 -AP IN
02/09/2004 15:30:28.872000 hme0 @0:1 p 129.146.157.149,33923 -> 
 129.146.157.145,23 PR tcp len 20 40 -A IN
02/09/2004 15:30:28.872142 hme0 @0:1 p 129.146.157.149,33923 -> 
  129.146.157.145,23 PR tcp len 20 43 -AP IN
02/09/2004 15:30:28.872808 hme0 @0:1 p 129.146.157.149,33923 -> 
  129.146.157.145,23 PR tcp len 20 40 -A IN
02/09/2004 15:30:28.872951 hme0 @0:1 p 129.146.157.149,33923 -> 
  129.146.157.145,23 PR tcp len 20 47 -AP IN
02/09/2004 15:30:28.926792 hme0 @0:1 p 129.146.157.149,33923 -> 
  129.146.157.145,23 PR tcp len 20 40 -A IN 
.
.
(output truncated)

Oracle Solaris IP フィルタ構成ファイルの作成と編集

規則セットとアドレスプールを作成および変更するには、構成ファイルを直接編集する必要があります。構成ファイルは、次のような標準的な UNIX 構文規則に従っています。

ProcedureOracle Solaris IP フィルタの構成ファイルを作成する方法

次の手順では、次のファイルの設定方法を説明します。

  1. IP Filter Management の権利プロファイルを持つ役割またはスーパーユーザーになります。

    IP Filter Management の権利プロファイルは、ユーザーが作成した役割に割り当てることができます。役割の作成と役割のユーザーへの割り当てについては、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

  2. 適当なファイルエディタを起動します。構成したい機能の構成ファイルを作成または編集します。

    • パケットフィルタリング規則の構成ファイルを作成するには、ipf.conf ファイルを編集します。

      Oracle Solaris IP フィルタは、ipf.conf ファイルに保存したパケットフィルタリング規則を使用します。パケットフィルタリングの規則ファイルを /etc/ipf/ipf.conf ファイルに保存した場合は、システムの起動時に、このファイルがロードされます。フィルタリング規則を起動時にロードしない場合は、このファイルを別の場所に保存します。次に、ipf コマンドで規則をアクティブにします (「別のパケットフィルタリング規則セット、または更新されたパケットフィルタリング規則セットをアクティブにする方法」を参照)。

      パケットフィルタリング規則を作成する方法については、「Oracle Solaris IP フィルタのパケットフィルタリング機能の使用」を参照してください。

      注 –

      ipf.conf ファイルが空の場合は、フィルタリングは行われません。空の ipf.conf ファイルは、次のような規則セットを持っているのと同じです。


      pass in all
pass out all

    • NAT 規則の構成ファイルを作成するには、 ipnat.conf ファイルを編集します。

      Oracle Solaris IP フィルタは、ipnat.conf ファイルに保存した NAT 規則を使用します。NAT の規則ファイルを /etc/ipf/ipnat.conf ファイルに保存した場合は、システムの起動時に、このファイルがロードされます。NAT 規則を起動時にロードしない場合は、適当な場所に ipnat.conf ファイルを保存します。次に、 ipnat コマンドで NAT 規則をアクティブ化します。

      NAT の規則の作成については、「Oracle Solaris IP フィルタの NAT 機能の使用」を参照してください。

    • アドレスプールの構成ファイルを作成するには、ippool.conf ファイルを編集します。

      Oracle Solaris IP フィルタは、ippool.conf ファイルに保存したアドレスプールを使用します。アドレスプールの規則ファイルを /etc/ipf/ippool.conf ファイルに保存した場合は、システムの起動時に、このファイルがロードされます。アドレスプールを起動時にロードしない場合は、適当な場所に ippool.conf ファイルを保存します。次に、ippool コマンドでアドレスプールをアクティブ化できます。

      アドレスプールの作成については、「Oracle Solaris IP フィルタのアドレスプール機能の使用」を参照してください。

Oracle Solaris IP フィルタの構成ファイルの例

次の例は、フィルタリング構成で使用されるパケットフィルタリング規則を示しています。

例 26–25 Oracle Solaris IP フィルタのホスト構成

この例は、 elxl ネットワークインタフェースを備えたホストマシンの構成を示しています。


# pass and log everything by default
pass in log on elxl0 all
pass out log on elxl0 all

# block, but don't log, incoming packets from other reserved addresses
block in quick on elxl0 from 10.0.0.0/8 to any
block in quick on elxl0 from 172.16.0.0/12 to any

# block and log untrusted internal IPs. 0/32 is notation that replaces 
# address of the machine running Solaris IP Filter.
block in log quick from 192.168.1.15 to <thishost>
block in log quick from 192.168.1.43 to <thishost>

# block and log X11 (port 6000) and remote procedure call 
# and portmapper (port 111) attempts
block in log quick on elxl0 proto tcp from any to elxl0/32 port = 6000 keep state
block in log quick on elxl0 proto tcp/udp from any to elxl0/32 port = 111 keep state

この規則セットは、最初の段階では、すべてのデータが elxl インタフェースを出入りできる制限なしの規則です。2 番目の規則セットは、プライベートアドレス空間 10.0.0.0 および 172.16.0.0 からの受信パケットがファイアウォールの中に入るのをブロックします。次の規則セットは、ホストマシンからの特定の内部アドレスをブロックします。そして、最後の規則セットは、ポート 6000 およびポート 111 から受信されるパケットをブロックします。

例 26–26 Oracle Solaris IP フィルタのサーバー構成

この例は、Web サーバーとして機能するホストマシンの構成を示しています。このマシンには、eri ネットワークインタフェースがあります。


# web server with an eri interface
# block and log everything by default; then allow specific services
# group 100 - inbound rules
# group 200 - outbound rules
# (0/32) resolves to our IP address)
*** FTP proxy ***


# block short packets which are packets fragmented too short to be real.
block in log quick all with short


# block and log inbound and outbound by default, group by destination
block in log on eri0 from any to any head 100
block out log on eri0 from any to any head 200


# web rules that get hit most often
pass in quick on eri0 proto tcp from any \
to eri0/32 port = http flags S keep state group 100
pass in quick on eri0 proto tcp from any \
to eri0/32 port = https flags S keep state group 100


# inbound traffic - ssh, auth
pass in quick on eri0 proto tcp from any \
to eri0/32 port = 22 flags S keep state group 100
pass in log quick on eri0 proto tcp from any \
to eri0/32 port = 113 flags S keep state group 100
pass in log quick on eri0 proto tcp from any port = 113 \
to eri0/32 flags S keep state group 100


# outbound traffic - DNS, auth, NTP, ssh, WWW, smtp
pass out quick on eri0 proto tcp/udp from eri0/32 \
to any port = domain flags S keep state group 200
pass in quick on eri0 proto udp from any port = domain to eri0/32 group 100

pass out quick on eri0 proto tcp from eri0/32 \
to any port = 113 flags S keep state group 200
pass out quick on eri0 proto tcp from eri0/32 port = 113 \
to any flags S keep state group 200

pass out quick on eri0 proto udp from eri0/32 to any port = ntp group 200
pass in quick on eri0 proto udp from any port = ntp to eri0/32 port = ntp group 100

pass out quick on eri0 proto tcp from eri0/32 \
to any port = ssh flags S keep state group 200

pass out quick on eri0 proto tcp from eri0/32 \
to any port = http flags S keep state group 200
pass out quick on eri0 proto tcp from eri0/32 \
to any port = https flags S keep state group 200

pass out quick on eri0 proto tcp from eri0/32 \
to any port = smtp flags S keep state group 200


# pass icmp packets in and out
pass in quick on eri0 proto icmp from any to eri0/32  keep state group 100
pass out quick on eri0 proto icmp from eri0/32 to any keep state group 200


# block and ignore NETBIOS packets
block in quick on eri0 proto tcp from any \
to any port = 135 flags S keep state group 100

block in quick on eri0 proto tcp from any port = 137 \
to any flags S keep state group 100
block in quick on eri0 proto udp from any to any port = 137 group 100
block in quick on eri0 proto udp from any port = 137 to any group 100

block in quick on eri0 proto tcp from any port = 138 \
to any flags S keep state group 100
block in quick on eri0 proto udp from any port = 138 to any group 100

block in quick on eri0 proto tcp from any port = 139 to any flags S keep state
group 100
block in quick on eri0 proto udp from any port = 139 to any group 100
例 26–27 Oracle Solaris IP フィルタのルーター構成

この例は、内部インタフェース ce0 と外部インタフェース ce1 を備えるルーターの構成を示しています。


# internal interface is ce0 at 192.168.1.1
# external interface is ce1 IP obtained via DHCP
# block all packets and allow specific services
*** NAT ***
*** POOLS ***


# Short packets which are fragmented too short to be real.
block in log quick all with short


# By default, block and log everything.
block in log on ce0 all
block in log on ce1 all
block out log on ce0 all
block out log on ce1 all


# Packets going in/out of network interfaces that aren't on the loopback
# interface should not exist.
block in log quick on ce0 from 127.0.0.0/8 to any
block in log quick on ce0 from any to 127.0.0.0/8
block in log quick on ce1 from 127.0.0.0/8 to any
block in log quick on ce1 from any to 127.0.0.0/8


# Deny reserved addresses.
block in quick on ce1 from 10.0.0.0/8 to any
block in quick on ce1 from 172.16.0.0/12 to any
block in log quick on ce1 from 192.168.1.0/24 to any
block in quick on ce1 from 192.168.0.0/16 to any


# Allow internal traffic
pass in quick on ce0 from 192.168.1.0/24 to 192.168.1.0/24
pass out quick on ce0 from 192.168.1.0/24 to 192.168.1.0/24


# Allow outgoing DNS requests from our servers on .1, .2, and .3
pass out quick on ce1 proto tcp/udp from ce1/32 to any port = domain keep state
pass in quick on ce0 proto tcp/udp from 192.168.1.2 to any port = domain keep state
pass in quick on ce0 proto tcp/udp from 192.168.1.3 to any port = domain keep state


# Allow NTP from any internal hosts to any external NTP server.
pass in quick on ce0 proto udp from 192.168.1.0/24 to any port = 123 keep state
pass out quick on ce1 proto udp from any to any port = 123 keep state


# Allow incoming mail
pass in quick on ce1 proto tcp from any to ce1/32 port = smtp keep state
pass in quick on ce1 proto tcp from any to ce1/32 port = smtp keep state
pass out quick on ce1 proto tcp from 192.168.1.0/24 to any port = smtp keep state


# Allow outgoing connections: SSH, WWW, NNTP, mail, whois
pass in quick on ce0 proto tcp from 192.168.1.0/24 to any port = 22 keep state
pass out quick on ce1 proto tcp from 192.168.1.0/24 to any port = 22 keep state

pass in quick on ce0 proto tcp from 192.168.1.0/24 to any port = 80 keep state
pass out quick on ce1 proto tcp from 192.168.1.0/24 to any port = 80 keep state
pass in quick on ce0 proto tcp from 192.168.1.0/24 to any port = 443 keep state
pass out quick on ce1 proto tcp from 192.168.1.0/24 to any port = 443 keep state

pass in quick on ce0 proto tcp from 192.168.1.0/24 to any port = nntp keep state
block in quick on ce1 proto tcp from any to any port = nntp keep state
pass out quick on ce1 proto tcp from 192.168.1.0/24 to any port = nntp keep state

pass in quick on ce0 proto tcp from 192.168.1.0/24 to any port = smtp keep state

pass in quick on ce0 proto tcp from 192.168.1.0/24 to any port = whois keep state
pass out quick on ce1 proto tcp from any to any port = whois keep state


# Allow ssh from offsite
pass in quick on ce1 proto tcp from any to ce1/32 port = 22 keep state


# Allow ping out
pass in quick on ce0 proto icmp all keep state
pass out quick on ce1 proto icmp all keep state


# allow auth out
pass out quick on ce1 proto tcp from ce1/32 to any port = 113 keep state
pass out quick on ce1 proto tcp from ce1/32 port = 113 to any keep state


# return rst for incoming auth
block return-rst in quick on ce1 proto tcp from any to any port = 113 flags S/SA


# log and return reset for any TCP packets with S/SA
block return-rst in log on ce1 proto tcp from any to any flags S/SA


# return ICMP error packets for invalid UDP packets
block return-icmp(net-unr) in proto udp all