test

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

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 のセキュリティーについて」を参照してください。