Go to main content
Oracle® Solaris 11.3 でのネットワークのセキュリティー保護

印刷ビューの終了

更新: 2016 年 11 月
 
 

IPsec によって 2 つのサーバー間でネットワークトラフィックをセキュリティー保護する方法

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

  • システムに静的 IP アドレスがアサイン済みで、ネットワーク構成プロファイル DefaultFixed を実行している。netadm list コマンドが Automatic を返す場合は、netcfg(1M) のマニュアルページで詳細を確認してください。

  • 2 つのシステムが host1 および host2 と名付けられている。

  • 各システムが IP アドレスを持っています。これは、IPv4 アドレス、IPv6 アドレスのどちらでもかまいませんし、その両方でもかまいません。この手順では、IPv4 アドレスを使用します。

  • 各システムは大域ゾーンまたは排他的 IP ゾーンである。詳細は、IPsec と Oracle Solaris ゾーンを参照してください。

  • 各システムはトラフィックを AES アルゴリズムで暗号化し、SHA-2 で認証する。


    注 -  一部のサイトでは SHA-2 アルゴリズムが要求される場合があります。
  • 各システムは、共有セキュリティーアソシエーションを使用します。

    共有セキュリティーアソシエーションでは、2 つのシステムを保護するのに必要なのは 1 組だけの SA です。


注 -  Trusted Extensions システムのラベルと一緒に IPsec を使用するには、Trusted Extensions 構成と管理 の マルチレベル Trusted Extensions ネットワークで IPsec 保護を適用するにあるこの手順の拡張を参照してください。

始める前に

    特定の権利を持つユーザーは、root でなくても次のコマンドを実行できます。

  • 構成コマンドを実行するには、Network IPsec Management 権利プロファイルが割り当てられている管理者になる必要があります。

  • この管理役割では、IPsec 関連のシステムファイルを編集し、pfedit コマンドを使用して鍵を作成できます。

  • hosts ファイルを編集するには、root 役割になるか、そのファイルを編集するための明示的なアクセス権を持っている必要があります。使用例 35を参照してください。

詳細は、Oracle Solaris 11.3 でのユーザーとプロセスのセキュリティー保護 の 割り当てられている管理権利の使用を参照してください。

リモートで管理する場合は、セキュアなリモートログイン手順について、使用例 27およびOracle Solaris 11.3 での Secure Shell アクセスの管理 の Secure Shell を使用して ZFS をリモートで管理する方法を参照してください。

  1. 各システム上で、/etc/inet/hosts ファイルにホストエントリを追加します。

    この手順により、ローカルネームサービスがネットワークに接続されたネームサービスに依存することなくシステム名を IP アドレスに解決できるようになります。

    1. host2 という名前のシステムでは、hosts ファイルに次のように入力します。
      ## Secure communication with host1
      192.168.116.16 host1
    2. host1 という名前のシステムでは、hosts ファイルに次のように入力します。
      ## Secure communication with sytem2
      192.168.13.213 host2
  2. 各システムで、IPsec ポリシーファイルを作成します。

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

    # pfedit /etc/inet/ipsecinit.conf
  3. IPsec ポリシーエントリを ipsecinit.conf ファイルに追加します。

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

    1. host1 システムで、次のポリシーを追加します。
      {laddr host1 raddr host2} ipsec {encr_algs aes encr_auth_algs sha512 sa shared}

      dir キーワードが使用されていないため、ポリシーはアウトバウンドとインバウンド両方のパケットに適用されます。

    2. host2 システムで、同じポリシーを追加します。
      {laddr host2 raddr host1} ipsec {encr_algs aes encr_auth_algs sha512 sa shared}
  4. 各システムで、IPsec SA を管理するための IKE を構成します。

    IKEv2 の構成の構成手順のいずれかに従います。IKE 構成ファイルの構文については、ikev2.config(4) のマニュアルページを参照してください。IKEv1 プロトコルのみをサポートしているシステムと通信している場合は、IKEv1 の構成および ike.config(4) のマニュアルページを参照してください。


    注 -  鍵を手動で生成して維持する必要がある場合は、IPsec の鍵を手動で作成する方法を参照してください。
  5. IPsec ポリシーファイルの構文を確認します。
    % pfbash
    # /usr/sbin/ipsecconf -c /etc/inet/ipsecinit.conf

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

  6. IPsec ポリシーをリフレッシュします。
    # svcadm refresh ipsec/policy:default

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

    # svcadm enable ipsec/policy:default
  7. IPsec の鍵をアクティブ化します。
    • ike サービスが有効になっていない場合は有効にします。

      注 -  IKEv1 プロトコルのみを実行できるシステムと通信している場合は、ike:default インスタンスを指定します。
      # svcadm enable ipsec/ike:ikev2
    • ike サービスが有効になっている場合は再起動します。
      # svcadm restart ike:ikev2

    Step 4 で鍵を手動で構成した場合は、IPsec の鍵を手動で作成する方法の手順を実行して鍵をアクティブ化します。

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

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

使用例 27  ssh 接続を使用した IPsec ポリシーのリモート構成

この例では、root 役割の管理者が 2 番目のシステムにアクセスするための ssh コマンドを使用して、2 つのシステム上で IPsec ポリシーと鍵を構成します。管理者は両方のシステムで同じように定義されています。詳細は、ssh(1) のマニュアルページを参照してください。

  1. 管理者はIPsec によって 2 つのサーバー間でネットワークトラフィックをセキュリティー保護する方法Step 1 からStep 5 を実行することによって最初のシステムを構成します。

  2. 別の端末ウィンドウで、管理者は同じように定義されたユーザー名と ID を使用して、ssh コマンドによってリモートでログインします。

    local-system % ssh -l jdoe other-system
    other-system # su - root 
    Enter password: xxxxxxxx
    other-system #
  3. ssh セッションの端末ウィンドウで、管理者はStep 1 からStep 7 までを実行することによって、2 番目のシステムの IPsec ポリシーと鍵を構成します。

  4. 管理者は ssh セッションを終了します。

    other-system # exit
    local-system 
    # exit
  5. 管理者は、Step 6 およびStep 7 を実行することによって、最初のシステムの IPsec ポリシーを有効にします。

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

使用例 28  FIPS 140-2 承認アルゴリズムを使用した IPsec ポリシーの構成

この例では、管理者が、鍵の長さが 256 ビットの対称アルゴリズムを必要とするサイトのセキュリティーポリシーに従うように、FIPS 140-2 対応システムの IPsec ポリシーを構成します。

管理者は 2 つの使用可能な IPsec ポリシーを指定します。最初のポリシーは、暗号用に 256 ビットの鍵の長さで CCM モードで AES を指定します。2 番目のポリシーは、暗号用に 256 ビットの鍵の長さで AES を指定し、認証用に SHA384 を指定します。

 {laddr host1 raddr host2} ipsec {encr_algs aes-ccm(256) sa shared} or ipsec
 {laddr host1 raddr host2} ipsec {encr_algs aes(256) encr_auth_algs sha384 sa shared}
使用例 29  IKEv2 プロトコルのみを使用する IPsec ポリシーの構成

この例では、管理者は、IKEv1 プロトコルを無視するように、サーバー上の IPsec ポリシーを構成します。すべての SA は IKEv2 で作成されます。IKEv1 とのネゴシエーションの試みは失敗します。管理者は対応する IKEv2 構成ファイルを作成します。

## ipsecinit.conf
{raddr 10.1.2.0/24 dir both } ipsec {encr_algs aes-ccm sa shared ike_version 2}

このルールは、10.1.2.0/24 サブネット上の任意のホストが、複合モードの aes-ccm アルゴリズムを使用してサーバーと通信できることを示しています。

対応する IKEv2 構成ファイルでは、server1.example.com サーバーに接続するために、証明書がサーバーと同じトラストチェーンで署名されているアドレス範囲を有効にします。

## ikev2.config 
        ikesa_xform { dh_group 21 auth_alg sha256 encr_alg aes }

{
        label "IKEv2-only certificate"

        request_http_certs yes
        auth_method cert
        local_id DNS = "server1.example.com"
        remote_id ANY
        local_addr 0.0.0.0/0
        remote_addr 0.0.0.0/0
}

server1 サーバーの構成が完了します。証明書がインストールされ、IPsec と IKEv2 が構成されているクライアントシステムは server1 と通信できます。

使用例 30  サーバーの or pass アクションを使用した、IPsec を使用するクライアントシステムへの移行

この例では、管理者はサブネット上のすべてのクライアントが IPsec を使用するように徐々に構成します。or pass {} アクションを使用すると、サブネット上のすべてのクライアント (IPsec で構成されていないクライアントを含む) からサーバーがパケットを受信できます。

## ipsecinit.conf
{raddr 10.1.2.0/24 dir both } ipsec {encr_algs aes-ccm sa shared} or pass {}

or pass {} アクションは、指定された暗号化メカニズムによって暗号化されていないがそれ以外のルールを満たしているすべてのトラフィック、およびルールに一致する IPsec トラフィックを通過させます。or pass ルールを持つサーバーへの接続は、クライアントから開始される必要があります。アクションは接続が最初に確立されたときにキャッシュされます。

10.1.2.0 サブネット上のすべてのクライアントは、サーバーへの接続を確立できます。